Vitalik Buterin revela plano de hyper‑scaling para o Ethereum

2026-02-27, Vitalik Buterin publicou no *Ethereum Research* um artigo extenso intitulado “Hyper‑scaling state by creating new forms of state” (Super‑escalando o estado ao criar novas formas de estado).

No texto, Vitalik Buterin detalha novamente a trajetória de escalabilidade do Ethereum. O artigo não só discute a expansão do ponto de vista técnico, como parte de uma visão de arquitetura global, apresentando um plano em fases para garantir que a rede possa aumentar sua capacidade nos próximos anos.

Ele posteriormente explicou o conteúdo em um tweet no X. A seguir, tentamos esclarecer de forma simples a proposta de escalabilidade apresentada por Vitalik e os motivos que a sustentam.

A partir da perspectiva da equipe de edição do BitRoot, analisamos o mais recente roadmap de cinco anos do Ethereum de Vitalik, aprofundando a lógica técnica e o impacto potencial da otimização de execução, fragmentação de dados e camada de estado, ajudando o leitor a entender as tendências chave de escalabilidade on‑chain. O texto a seguir desenvolve esses pontos. Também discutiremos o significado a longo prazo dessas soluções para o ecossistema.

Expansão de recursos de execução e de dados — curto e longo prazo

No início do artigo, Vitalik afirma: “Para escalar o Ethereum nos próximos cinco anos, é necessário ampliar três tipos de recursos”:

• Recursos de execução: cálculos da EVM, verificação de assinaturas etc.
• Recursos de dados: remetente, destinatário, assinatura das transações etc.
• Recursos de estado: saldos de contas, código, armazenamento

Os dois primeiros recursos possuem soluções de curto e longo prazo.

Recursos de execução

• Curto prazo: por meio de *Block Access Lists* (BAL), ePBS e reprecificação das taxas de Gas, alcançar cerca de 10‑30× de melhoria.
• Longo prazo: usar ZK‑EVM para obter aproximadamente 1000× de ganho; para cálculos específicos (assinaturas, SNARK/STARK), a agregação off‑chain pode elevar o desempenho em torno de 10 000×.

Recursos de dados

• Curto prazo: aproveitando melhorias p2p e Gas multidimensional, obter cerca de 10‑20× de crescimento.
• Longo prazo: através de *Blobs* + *PeerDAS* alcançar aproximadamente 500× de aumento.

O objetivo de curto prazo é tornar o Ethereum mais rápido. O método atual de validação é sequencial — cada transação é verificada uma a uma; se uma delas travar, todo o processo de validação é bloqueado.

Por isso, a atualização Glamsterdam deste ano introduzirá *Block Access Lists* (BAL) e ePBS.

• Block Access Lists permitem que o empacotador de blocos informe antecipadamente aos validadores quais contas e posições de armazenamento serão acessadas no bloco. Os validadores, então, pré‑carregam esses dados do disco para a memória, possibilitando a verificação paralela de várias transações, semelhante a uma linha de montagem: antes, um único trabalhador completava tudo; agora, vários trabalhadores processam etapas diferentes simultaneamente.
• ePBS separa a construção do bloco da sua validação — o construtor de blocos reúne as transações, o proponente propõe o bloco e o validador verifica. Cada função foca em sua responsabilidade; o construtor pode empacotar mais transações de forma agressiva, pois o proponente e o validador ajudam a garantir a segurança.
• Reprecificação de Gas + Gas multidimensional é o mecanismo central. Atualmente, todas as operações pagam a mesma taxa de Gas. Vitalik propõe que diferentes operações tenham custos diferentes. Em especial, a criação de novo estado (por exemplo, nova conta ou implantação de contrato) deveria ter uma “taxa de criação de estado” dedicada, já que consome tanto recursos computacionais quanto armazenamento permanente. A ideia é: aumentar a taxa de criação de estado e reduzir a taxa de Gas das transações comuns.

A implementação usa um “mecanismo de reservatório”. Imagine dois fundos — um para a “taxa de criação de estado” e outro para o Gas tradicional. Quando contratos se chamam, o Gas é deduzido automaticamente dos dois fundos, garantindo uma distribuição justa. Assim, as transações de usuários comuns ficam mais baratas, enquanto desenvolvedores que criam novo estado pagam mais, controlando o crescimento do estado e evitando que os discos dos nós completos se esgotem.

Expansão de longo prazo

O objetivo de longo prazo é tornar a camada base (mainnet) mais robusta, reduzindo a dependência de *Layer 2*. Isso inclui o rollout faseado de Blobs + PeerDAS e ZK‑EVM.

• Blobs hoje são arquivos grandes temporários usados por *Layer 2*. No futuro, a mainnet também os utilizará. Contudo, se cada nó precisar baixar todos os Blobs, a rede enfrentará enorme pressão de tráfego.
• PeerDAS permite o download por amostragem, obtendo apenas uma fração dos dados totais (por exemplo, 1/16). Com provas ZK, a integridade dos dados pode ser verificada, similar ao princípio de uma pesquisa por amostragem.
• O rollout faseado da ZK‑EVM faz com que os nós validem blocos sem reexecutar todas as transações; basta validar a prova ZK correspondente. O custo de validação cai de “executar todas as transações” para “verificar uma única prova”. Vitalik planeja que, em 2026, alguns nós experimentem a validação ZK; em 2027, a adoção será ampliada, e, finalmente, cada bloco válido deverá conter 3 dos 5 tipos de provas de diferentes sistemas. Ele prevê que, exceto os nós de indexação, todos os demais acabarão dependendo das provas ZK‑EVM.

Não há solução milagrosa para a expansão do estado

Agora analisaremos o recurso de estado, que não foi coberto nas soluções de curto e longo prazo acima. No curto prazo, ainda é possível melhorar cerca de 5‑30× sincronizando com *Block Access Lists*, aprimorando p2p e otimizando bancos de dados, mas como escalar a longo prazo?

A resposta de Vitalik: ainda não há solução viável.

Por que o recurso de estado é tão difícil de escalar?

O estado do Ethereum funciona como um gigantesco banco de dados que registra saldos, códigos de contrato e posições de armazenamento. O tamanho atual do banco de dados está em torno de 100 GB; expandir 20× levaria a 2 TB, e 80× a 8 TB.

O gargalo não é a capacidade de disco, mas sim:

1. Queda de eficiência do banco de dados: bancos modernos usam estruturas em árvore (como Merkle Trees). Cada inserção requer a atualização de toda a árvore, o que gera múltiplas operações de baixo nível; assim, a velocidade de gravação cresce exponencialmente com o número de atualizações, culminando em um gargalo de escrita.
2. Alto custo de sincronização: um novo nó precisa baixar o estado completo antes de validar blocos. Se o estado atingir vários terabytes, o tempo de download em conexões residenciais se torna impraticável.

Limitações das soluções existentes

• Fortemente stateless: nós não armazenam o estado completo, confiando apenas em provas Merkle fornecidas pelos usuários. Vitalik acredita que isso pode levar à centralização do armazenamento, falhas de transação devido a acessos dinâmicos e aumento dos custos de banda.
• Expiração de estado: eliminar estados que raramente são acessados, mantendo apenas os ativos recentemente. O grande desafio é provar que “um determinado estado nunca existiu”. Por exemplo, ao criar uma nova conta, seria necessário comprovar que o endereço nunca foi usado ao longo de toda a história, exigindo a verificação de anos de dados, o que seria extremamente custoso.

Novas formas de estado

Com base nas reflexões acima, Vitalik propõe várias novas formas de estado, representando uma mudança estrutural no modelo de recursos de estado do Ethereum:

• Armazenamento temporário: dados que expiram automaticamente, como uma árvore que zera a cada mês. Ideal para books de ordens, pools de liquidez, contadores transitórios etc., que não precisam ser preservados permanentemente.
• Armazenamento cíclico: semelhante ao temporário, porém com período de expiração maior, por exemplo 1 ano.
• Armazenamento restrito: acessível apenas via interfaces específicas; por exemplo, saldos de tokens ERC20 só podem ser lidos por consultas padrão, facilitando otimizações direcionadas.

Essas novas formas coexistiriam com o modelo de estado atual. Na camada de execução, a ZK‑EVM poderia oferecer cerca de 1000× de aceleração, enquanto a taxa de criação de estado poderia subir apenas em torno de 20×.

Desenvolvedores teriam a liberdade de escolher: continuar usando o estado tradicional pagando taxas mais altas, ou redesenhar contratos adotando as novas formas de estado para reduzir custos. Casos de uso comuns (como saldos ERC20 ou NFTs) provavelmente se padronizarão; cenários mais complexos de DeFi exigirão que os desenvolvedores explorem otimizações próprias.

Essa estratégia incentiva a criatividade dos desenvolvedores para reduzir custos, ao mesmo tempo que beneficia a comunidade de usuários do Ethereum.

💡 Cadastre-se na Binance com o código B2345 para o desconto máximo em taxas. Veja guia completo Binance.

⚠️ Aviso de risco: Os preços das criptomoedas são muito voláteis. Isso não é aconselhamento de investimento.