A Ethereum ativou a atualização Fusaka em 3/12/2025, expandindo significativamente a capacidade de disponibilidade de dados da rede através do mecanismo Blob Parameter Overrides. Este mecanismo permite ajustar gradualmente o objetivo e o limite máximo do blob – os pacotes de dados de transação comprimidos que os layer-2 rollups carregam na Ethereum para garantir segurança e integridade.
As duas próximas alterações ajustaram o objetivo de blobs por bloco de 6 para 10, e depois para 14, enquanto o limite máximo foi elevado para 21. O objetivo principal do Fusaka é reduzir os custos para os rollups aumentando a taxa de transferência de dados do blob.
No entanto, após três meses de coleta de dados, os resultados mostram uma discrepância clara entre a capacidade técnica e o uso real. Análises da MigaLabs em mais de 750.000 slots desde a ativação do Fusaka indicam que a rede ainda não atingiu o objetivo de 14 blobs por bloco.
Notavelmente, o uso mediano de blobs até mesmo diminuiu após a primeira alteração de parâmetro. Blocos contendo 16 blobs ou mais apresentam uma taxa de misses significativamente maior, indicando que a confiabilidade da rede diminui ao se aproximar do novo limite de capacidade.
A conclusão do relatório é bastante direta: não se deve continuar aumentando o parâmetro de blobs até que a taxa de misses em blocos com muitos blobs retorne a níveis normais e haja uma necessidade real de preencher a capacidade adicional criada.
O que o Fusaka mudou e quando aconteceu
Antes do Fusaka, de acordo com a EIP-7691, a Ethereum tinha como objetivo 6 blobs por bloco com um limite máximo de 9. A atualização Fusaka introduziu duas vezes consecutivas ajustes no Blob Parameter Override.
A primeira ativada em 9/12/2025, elevando o objetivo para 10 e o limite máximo para 15. A segunda ocorreu em 7/1/2026, aumentando o objetivo para 14 e o limite máximo para 21.
O roteiro de atualização do Fusaka da Ethereum mostra que os parâmetros de blob aumentaram de 6/9 para 12/15 e depois para 14/21 no período de dezembro de 2025 a janeiro de 2026. Essas mudanças não requereram hard fork, permitindo que a Ethereum ajuste a capacidade por meio de coordenação entre clientes, sem necessidade de atualização de protocolo.
Análises da MigaLabs, com código-fonte e métodos reproduzíveis, monitoraram o uso de blobs e o desempenho da rede durante essa fase de transição. Os resultados indicam que a mediana de blobs por bloco caiu de 6 para 4 após a primeira override, mesmo com a expansão da capacidade total. Blocos com 16 blobs ou mais são extremamente raros, ocorrendo entre 165 e 259 vezes ao longo de todo o período de observação.
Em outras palavras, a rede possui espaço ocioso ainda não explorado.
O relatório também aponta uma inconsistência: a descrição do cronograma indica que a primeira override elevou o objetivo de 6 para 12, enquanto o anúncio na mainnet e a documentação da Ethereum Foundation confirmam que o aumento foi de 6 para 10. Para essa análise, utilizamos os parâmetros oficiais da Ethereum Foundation, enquanto os dados empíricos de uso e taxa de misses da MigaLabs continuam sendo a base de análise.
Aumento expressivo na taxa de misses em blocos com muitos blobs
A confiabilidade da rede é avaliada por meio dos slots perdidos – blocos não propagados ou validados corretamente – que mostram uma tendência bastante clara.
Em blobs baixos, a taxa de misses fica em torno de 0,5%. Quando o bloco contém 16 blobs ou mais, essa taxa sobe para entre 0,77% e 1,79%. No limite máximo de 21 blobs, após a segunda override, a taxa de misses atinge 1,79%, mais de três vezes o nível base.
Análises por nível de blob de 10 a 21 mostram uma curva de queda na confiabilidade que se torna mais evidente ao ultrapassar o objetivo de 14 blobs.
Isso é especialmente importante porque indica que a infraestrutura atual da Ethereum – incluindo hardware de validadores, banda larga de rede e tempo de atestação – enfrenta dificuldades ao processar blocos próximos ao limite de capacidade elevado.
Se, no futuro, a demanda aumentar significativamente e frequentemente empurrar os blocos perto do limite de 21 blobs, a alta taxa de misses pode levar a atrasos na finalização ou aumento do risco de reorganizações (reorg). O relatório considera essa uma fronteira de estabilidade: a rede pode processar blocos com muitos blobs tecnicamente, mas sua manutenção de forma estável e confiável ainda é incerta.
A taxa de erro permanece abaixo de 0,75% para blocos com menos de 16 blobs, aumentando para mais de 1% em blocos com maior quantidade, atingindo 1,79% em 21 blobs.## Economia do blob e o papel do preço mínimo de reserva
Fusaka não apenas expandiu a capacidade, mas também alterou o mecanismo de precificação do blob via EIP-7918, que introduziu um preço mínimo de reserva para evitar que as leilões de blobs caiam para 1 wei.
Anteriormente, quando a demanda por blobs era baixa e os custos de execução predominavam, a taxa base (base fee) do blob podia diminuir a ponto de se aproximar de zero, tornando o sinal de preço sem significado. Por outro lado, os rollups layer-2 pagam taxas de blob para publicar dados de transação na Ethereum, e essa taxa deve refletir os custos computacionais e a carga de rede que o blob impõe.
Quando as taxas se aproximam de zero, o ciclo econômico de feedback é quebrado, incentivando comportamentos de consumo de capacidade sem custos proporcionais, o que prejudica a observabilidade da demanda real na rede.
O preço mínimo de reserva do EIP-7918 vincula a taxa de blob aos custos de execução, garantindo que, mesmo com baixa demanda, o preço continue sendo um sinal econômico relevante. Isso ajuda a evitar o problema do “free-rider” e fornece dados mais claros para decisões de expansão futura.
Dados iniciais do dashboard Dune de Hildobby mostram que as taxas de blob se estabilizaram após o Fusaka, ao contrário da tendência de queda acentuada observada em fases anteriores. A média de blobs por bloco também confirma a conclusão da MigaLabs de que o uso ainda não aumentou o suficiente para preencher a nova capacidade.
As taxas de transação de “blob” atingiram picos superiores a 2 milhões de dólares no início e no final de 2024, antes de declinar ao longo de 2025, permanecendo em níveis baixos em 2026.## Quão eficaz é o Fusaka?
Do ponto de vista técnico, o Fusaka conseguiu expandir a capacidade e demonstrou que o mecanismo Blob Parameter Override pode funcionar sem a necessidade de hard fork controverso. O preço mínimo de reserva também tem mostrado efeito, impedindo que as taxas de blob se tornem economicamente irrelevantes.
No entanto, o uso ainda é inferior à capacidade, e a confiabilidade diminui claramente na extremidade superior da nova capacidade. A curva de taxa de misses indica que a infraestrutura atual lida bem com os níveis pré-Fusaka e com os parâmetros 10/15 após a primeira override, mas começa a sofrer pressão ao ultrapassar 16 blobs.
Isso cria um perfil de risco claro: se atividades layer-2 aumentarem drasticamente e frequentemente empurrarem os blocos perto do limite de 21 blobs, a rede pode enfrentar altas taxas de misses, afetando a finalização e a resistência a reorgs.
Por outro lado, a redução da mediana de blobs após a primeira override, mesmo com a expansão da capacidade, indica que os rollups ainda não estão limitados pela disponibilidade de blobs. Talvez por volume de transações insuficiente, ou por estarem otimizando compressão e batching para se ajustarem à capacidade atual, ao invés de expandir seu uso.
Dados do Blobscan também mostram que os rollups individuais mantêm uma quantidade relativamente estável de blobs ao longo do tempo, ao invés de aproveitar rapidamente a capacidade ociosa recém-criada.
Próximos passos da Ethereum
O roteiro da Ethereum ainda inclui o PeerDAS, uma reformulação mais profunda de amostragem de disponibilidade de dados para ampliar a capacidade de blobs e melhorar a descentralização e segurança.
No entanto, os resultados do Fusaka indicam que a capacidade bruta atual ainda não é o principal gargalo. A rede ainda tem espaço para “crescer” até cerca de 14/21 antes de precisar de expansão adicional, enquanto os dados de taxa de misses em blobs altos mostram que a infraestrutura precisa ser aprimorada em paralelo.
A abordagem mais segura é deixar o uso aumentar gradualmente até atingir os objetivos atuais, monitorando se a taxa de misses melhora à medida que clientes e validadores otimizam para cargas altas de blob, e só ajustar os parâmetros quando a rede demonstrar capacidade de lidar de forma estável com casos limites.
O Fusaka criou espaço para crescimento futuro e estabilizou a economia do blob, mas ainda não provocou uma explosão de uso nem resolveu completamente os desafios de confiabilidade na capacidade máxima. A questão de se essa capacidade será totalmente utilizada ou não permanece em aberto, e os dados atuais ainda não oferecem uma resposta definitiva.
