Escalabilidade do Ethereum: o aumento de Blob acaba por sobrecarregar a rede

A atualização Fusaka do Ethereum deveria ser uma bênção para o Layer2, mas após três meses revelou uma realidade embaraçosa: para aumentar a capacidade de Blob com o objetivo de escalar, o que aconteceu foi que a rede se tornou mais propensa a falhas sob alta carga. O relatório mais recente da instituição de pesquisa MigaLabs aponta que, atualmente, o Ethereum ainda enfrenta gargalos físicos e de rede ao lidar com grandes volumes de dados, e aumentar a capacidade de forma cega pode ter o efeito oposto.

A “armadilha reversa” da expansão de Blob

De 9 a 21 em rápidas iterações

A atualização Fusaka foi implementada em dezembro de 2025, com o objetivo principal de fornecer canais de dados mais eficientes para o Layer2. Antes da atualização, cada bloco do Ethereum podia carregar no máximo 9 pacotes de Blob. De acordo com o roteiro, essa capacidade poderia ser aumentada para 72 (oito vezes mais).

Porém, o ritmo de expansão após a atualização foi surpreendentemente rápido:

Executivos da Fundação Ethereum, como Alex Stokes, admitiram na época que se trata de uma tecnologia muito nova, e o desempenho da rede sob condições extremas ainda é incerto. Mas o entusiasmo do mercado parece ter superado essa cautela.

Problema emergente: quanto maior a capacidade, mais frágil fica a rede

As descobertas da MigaLabs desmascaram esse sonho. A instituição observou que, quando um bloco se aproxima do limite de Blob, frequentemente ocorre falha ou atraso na propagação dos blocos subsequentes. Em outras palavras, para que o Layer2 processe mais dados, o Ethereum às vezes se torna mais instável.

Leonardo Bautista Gomez, fundador da MigaLabs, afirmou diretamente que isso não é alarmismo, mas um aviso real aos desenvolvedores principais: antes de entender completamente o feedback da rede, não se deve continuar aumentando cegamente a capacidade de Blob.

A raiz do problema: gargalos físicos e incentivos de jogo

Pressão de propagação nos nós distribuídos

Sob alta carga de dados, os nós distribuídos enfrentam gargalos físicos e de rede ao sincronizar grandes volumes de informações. Simplificando, quando um bloco contém 21 Blobs, milhares de nós precisam baixar e validar esses dados em um curto espaço de tempo, e a topologia da rede e a largura de banda se tornam fatores limitantes.

O “jogo de tempo” que aumenta a instabilidade

O engenheiro Sam Calder-Mason, da equipe PandaOps da Fundação Ethereum, apontou outro problema: validadores, buscando maximizar seus lucros de MEV, têm motivação para atrasar a publicação de blocos. Em blocos com muitos Blobs, esse atraso se intensifica, agravando ainda mais a instabilidade da rede.

Este é um conflito de incentivos: escalar a capacidade exige maior throughput, mas os mecanismos atuais de incentivo de MEV entram em conflito com a estabilidade desejada.

Estado atual e direções futuras

A rede ainda está na zona de segurança, mas precisa evoluir

Sam Calder-Mason enfatiza que, por ora, a rede como um todo não está em perigo. Mas este é um momento crucial: antes de continuar a expansão, o Ethereum precisa implementar mecanismos de propagação de dados mais eficientes.

O que isso significa? Talvez seja necessário:

• Otimizar protocolos de sincronização de dados entre nós
• Melhorar a estrutura de incentivos dos validadores, reduzindo atrasos induzidos por MEV
• Aumentar a capacidade de Blob de forma gradual e não radical
• Aperfeiçoar mecanismos de monitoramento e resposta a emergências

Do ponto de vista do Layer2

Informações relacionadas indicam que o Ethereum está se transformando progressivamente em uma camada de liquidação e coordenação. O relatório da Bitfinex aponta que o volume médio diário de transações do Ethereum atingiu recordes históricos (cerca de 2,88 milhões de transações), enquanto as taxas médias permanecem baixas, o que demonstra a eficácia da expansão do Layer2.

Porém, essa mudança depende da estabilidade da rede principal. Se blocos com muitos Blobs frequentemente causarem falhas na propagação, os benefícios do Layer2 podem ser prejudicados.

Perspectivas futuras

Este jogo técnico envolvendo Blob e expansão do Layer2 tornou-se uma questão central no roteiro do Ethereum para 2026. A comunidade de desenvolvedores precisa equilibrar três aspectos:

1. Throughput: atender às crescentes demandas de dados do Layer2
2. Estabilidade: garantir confiabilidade da rede sob alta carga
3. Descentralização: evitar que a expansão aumente demais a barreira de participação dos nós

Se não for possível encontrar um equilíbrio entre esses três fatores, a expansão da camada de dados do Ethereum pode se tornar mais desafiadora do que o esperado. Os obstáculos técnicos atuais indicam que escalar não é apenas ajustar parâmetros, mas requer otimizações sistêmicas em infraestrutura, mecanismos de incentivo e topologia de rede.

Resumo

A intenção por trás da atualização Fusaka foi boa, mas a prática de três meses revelou um paradoxo de escalabilidade: quanto maior a capacidade, maior a pressão sobre a rede. Os alertas da MigaLabs e da PandaOps merecem atenção, pois apontam para uma questão mais profunda — a infraestrutura atual do Ethereum ainda não suporta um aumento agressivo na taxa de transferência.

O ponto crucial não está apenas no número de Blob, mas na capacidade do Ethereum de manter a descentralização enquanto resolve questões de propagação de dados, incentivos dos validadores e outros aspectos. Talvez, essa seja uma prova mais difícil para os desenvolvedores do que qualquer atualização técnica isolada.