A surpreendente queda no uso do Ethereum sugere que a rede resolveu o problema errado com a atualização Fusaka

Fonte: CryptoNewsNet Título Original: A surpreendente queda no uso do Ethereum sugere que a rede resolveu o problema errado com a atualização Fusaka Link Original: O Ethereum ativou a atualização Fusaka em 3 de Dezembro de 2025, aumentando a capacidade de disponibilidade de dados da rede através de Overrides de Parâmetros de Blob que expandiram incrementalmente os alvos e máximos de blob.

Duas ajustamentos subsequentes elevaram o alvo de 6 blobs por bloco para 10, depois para 14, com um teto máximo de 21. O objetivo era reduzir os custos de rollups de camada-2 aumentando a taxa de transferência de dados de blob, os pacotes de transações comprimidas que os rollups postam ao Ethereum para segurança e finalização.

Três meses após a coleta de dados, os resultados revelam uma lacuna entre capacidade e utilização. Uma análise da MigaLabs de mais de 750.000 slots desde a ativação do Fusaka mostra que a rede não está atingindo o alvo de 14 blobs.

O uso mediano de blobs na verdade diminuiu após o primeiro ajuste de parâmetro, e blocos contendo 16 ou mais blobs exibem taxas elevadas de falhas, sugerindo degradação na confiabilidade nas extremidades da nova capacidade.

A conclusão do relatório é direta: sem aumentos adicionais no parâmetro de blob até que as altas taxas de falha de blob se normalizem e a demanda se materialize para o espaço já criado.

O que o Fusaka mudou e quando aconteceu

A linha de base do Ethereum antes do Fusaka, estabelecida através do EIP-7691, fixava o alvo em 6 blobs por bloco com um máximo de 9. A atualização Fusaka introduziu dois ajustes sequenciais de Overrides de Parâmetros de Blob.

O primeiro foi ativado em 9 de Dezembro, elevando o alvo para 10 e o máximo para 15. O segundo foi ativado em 7 de Janeiro de 2026, elevando o alvo para 14 e o máximo para 21.

Essas mudanças não exigiram hard forks, e o mecanismo permite que o Ethereum ajuste a capacidade através de coordenação entre clientes, ao invés de atualizações no protocolo.

A análise da MigaLabs, que publicou código e metodologia reproduzíveis, acompanhou o uso de blobs e o desempenho da rede durante essa transição.

Ela constatou que a contagem mediana de blobs por bloco caiu de 6 antes do primeiro override para 4 após, apesar da expansão da capacidade da rede. Blocos contendo 16 ou mais blobs continuam extremamente raros, ocorrendo entre 165 e 259 vezes cada um na janela de observação, dependendo da contagem específica de blobs.

A rede possui espaço livre que não está utilizando.

Uma discrepância no parâmetro: o texto da linha do tempo do relatório descreve o primeiro override como elevando o alvo de 6 para 12, mas o anúncio da Ethereum Foundation e a documentação do cliente descrevem a alteração como de 6 para 10.

Usamos os parâmetros da Ethereum Foundation como fonte: linha de base 6/9, após o primeiro override 10/15, após o segundo 14/21. Ainda assim, tratamos o conjunto de dados do relatório para padrões de utilização observada e taxas de falha como a base empírica.

As taxas de falha aumentam em contagens altas de blobs

A confiabilidade da rede, medida por slots perdidos — blocos que falham ao propagar ou atestar corretamente — mostra um padrão claro.

Em contagens menores de blobs, a taxa de falha de base fica em torno de 0,5%. Quando os blocos atingem 16 ou mais blobs, as taxas de falha sobem para 0,77% a 1,79%. Em 21 blobs, a capacidade máxima introduzida na segunda override, a taxa de falha atinge 1,79%, mais de três vezes a taxa de base.

A análise detalha isso para contagens de blobs de 10 a 21, mostrando uma curva de degradação gradual que acelera após o alvo de 14 blobs.

Essa degradação é importante porque sugere que a infraestrutura da rede, como hardware de validadores, largura de banda de rede e tempo de atestação, tem dificuldades em lidar com blocos na extremidade superior da capacidade.

Se a demanda eventualmente aumentar para preencher o alvo de 14 blobs ou se aproximar do máximo de 21 blobs, as taxas de falha elevadas podem se traduzir em atrasos significativos na finalização ou risco de reorganizações. O relatório apresenta isso como um limite de estabilidade: a rede pode processar tecnicamente blocos de alto blob, mas fazê-lo de forma consistente e confiável ainda é uma questão em aberto.

Economia de blobs: por que o piso de preço de reserva importa

Fusaka não apenas expandiu a capacidade. Também alterou a precificação de blobs através do EIP-7918, que introduz um piso de preço de reserva para evitar que leilões de blobs colapsem para 1 wei.

Antes dessa mudança, quando os custos de execução dominavam e a demanda por blobs permanecia baixa, a taxa base de blobs podia despencar até desaparecer efetivamente como sinal de preço. Os rollups de camada-2 pagam taxas de blob para postar seus dados de transação ao Ethereum, e essas taxas devem refletir os custos computacionais e de rede que os blobs impõem.

Quando as taxas caem perto de zero, o ciclo de feedback econômico se rompe, e os rollups consomem capacidade sem pagar proporcionalmente. Isso faz com que a rede perca visibilidade sobre a demanda real.

O piso de preço de reserva do EIP-7918 vincula as taxas de blob aos custos de execução, garantindo que, mesmo quando a demanda estiver fraca, o preço permaneça como um sinal significativo.

Isso evita o problema do free-rider, onde blobs baratos incentivam uso desperdício, e fornece dados mais claros para decisões futuras de capacidade: se as taxas de blob permanecerem elevadas apesar do aumento da capacidade, a demanda é genuína; se colapsarem ao piso, há espaço livre.

Dados iniciais do painel Dune de Hildobby, que acompanha blobs do Ethereum, mostram que as taxas de blob se estabilizaram após Fusaka, ao invés de continuarem a espiral descendente vista em períodos anteriores.

A média de blobs por bloco confirma a constatação da MigaLabs de que a utilização não aumentou para preencher a nova capacidade. Blocos rotineiramente carregam menos do que o alvo de 14 blobs, e a distribuição permanece fortemente inclinada para contagens menores.

O que os dados revelam sobre a efetividade

Fusaka conseguiu expandir a capacidade técnica e provar que o mecanismo de Overrides de Parâmetros de Blob funciona sem a necessidade de hard forks controversos.

O piso de preço de reserva parece estar funcionando como esperado, impedindo que as taxas de blob se tornem economicamente irrelevantes. Mas a utilização fica atrás da capacidade, e a confiabilidade nas extremidades da nova capacidade mostra degradação mensurável.

A curva de taxa de falha sugere que a infraestrutura atual do Ethereum lida confortavelmente com a linha de base pré-Fusaka e os parâmetros de 10/15 do primeiro override, mas começa a ficar sobrecarregada após 16 blobs.

Isso cria um perfil de risco: se a atividade de camada-2 aumentar e empurrar os blocos regularmente para o máximo de 21 blobs, a rede pode enfrentar taxas de falha elevadas que comprometem a finalização e a resistência a reorganizações.

Padrões de demanda oferecem outro sinal. A queda na utilização mediana de blobs após o primeiro override, apesar do aumento de capacidade, sugere que os rollups de camada-2 atualmente não estão limitados pela disponibilidade de blobs.

Ou o volume de transações deles não cresceu o suficiente para exigir mais blobs por bloco, ou eles estão otimizando compressão e agrupamento para caber na capacidade existente, ao invés de expandir o uso.

Blobscan, um explorador dedicado de blobs, mostra que os rollups individuais postam contagens de blobs relativamente consistentes ao longo do tempo, ao invés de aumentarem para explorar o espaço livre.

A preocupação pré-Fusaka era que a capacidade limitada de blobs fosse um gargalo para a escalabilidade de Layer 2 e mantivesse as taxas de rollup elevadas enquanto as redes competiam por disponibilidade de dados escassa. Fusaka abordou a restrição de capacidade, mas o gargalo parece ter mudado.

Os rollups não estão preenchendo o espaço disponível, o que significa que ou a demanda ainda não chegou, ou fatores como a economia do sequenciador, atividade do usuário e fragmentação entre rollups estão limitando o crescimento mais do que a disponibilidade de blobs.

O que vem a seguir

O roteiro do Ethereum inclui o PeerDAS, uma reformulação mais fundamental do amostragem de disponibilidade de dados que expandiria ainda mais a capacidade de blobs, ao mesmo tempo que melhora propriedades de descentralização e segurança.

No entanto, os resultados de Fusaka sugerem que a capacidade bruta não é a restrição principal no momento.

A rede tem espaço para crescer até os parâmetros 14/21 antes de precisar de outra expansão, e a curva de confiabilidade em altas contagens de blobs indica que melhorias na infraestrutura podem precisar acontecer antes de aumentos adicionais na capacidade.

Os dados de taxas de falha fornecem uma condição limite clara. Se o Ethereum aumentar a capacidade enquanto blocos com 16+ blobs ainda apresentarem taxas de falha elevadas, corre-se o risco de introduzir instabilidade sistêmica que pode emergir em períodos de alta demanda.

O caminho mais seguro é permitir que a utilização aumente até o alvo atual, monitorar se as taxas de falha melhoram à medida que os clientes otimizam para cargas maiores de blobs, e ajustar os parâmetros somente quando a rede demonstrar que consegue lidar de forma confiável com casos extremos.

A efetividade do Fusaka depende da métrica. Expandiu a capacidade com sucesso e estabilizou o preço do blob através do piso de reserva. Não impulsionou aumentos imediatos na utilização nem resolveu os desafios de confiabilidade na capacidade máxima.

A atualização criou espaço para crescimento futuro, mas se esse crescimento se materializará ou não, permanece uma questão em aberto que os dados ainda não responderam.