Em 27 de fevereiro de 2026, Vitalik Buterin publicou um artigo longo no Ethereum Research intitulado "Hyper-scaling state by creating new forms of state".
Neste artigo, Vitalik Buterin detalha ainda mais a rota de escalabilidade da Ethereum. Este artigo não aborda apenas a escalabilidade da Ethereum sob uma perspectiva técnica, mas também oferece, sob uma visão arquitetônica abrangente, um plano escalonado para expandir a capacidade da rede da Ethereum nos próximos anos.
Ao mesmo tempo, ele também publicou um tweet no X explicando mais detalhadamente o artigo. Tentamos compreender, de forma acessível, qual é exatamente a nova proposta de escala apresentada por Vitalik e por que ele fez isso.
Expansão de curto e longo prazo dos recursos de execução e dos recursos de dados
Vitalik observa no início do artigo longo: “Para expandir a Ethereum nos próximos cinco anos, é necessário expandir três recursos”:
- Recursos executados: cálculo EVM, verificação de assinatura, etc.
- Recursos de dados: remetente, destinatário, assinatura, etc. da transação
- Recursos de status: saldo da conta, código, armazenamento
Os dois primeiros possuem planos de expansão a curto e longo prazo.
Para recursos de execução, um aumento de aproximadamente 10 a 30 vezes será alcançado a curto prazo por meio da lista de acesso a blocos (BAL), ePBS e reprecificação do gás; a longo prazo, um aumento de cerca de 1000 vezes será alcançado por meio do ZK-EVM. Além disso, para certos tipos específicos de cálculos (assinaturas, SNARK/STARK), a agregação off-chain pode melhorar o desempenho em aproximadamente 10.000 vezes.
Para recursos de dados, um aumento de cerca de 10 a 20 vezes será alcançado a curto prazo por meio de melhorias P2P e Gas multidimensional, e um aumento de cerca de 500 vezes a longo prazo por meio de Blobs + PeerDAS.
A expansão de curto prazo visa tornar a Ethereum mais rápida. Atualmente, a Ethereum é lenta porque o método de validação atual é sequencial — as transações são verificadas uma após a outra. Se uma transação travar, todo o processo de validação é interrompido.
Portanto, a próxima atualização do Glamsterdam deste ano introduzirá a Lista de Acesso a Blocos (BAL) e o ePBS.
A lista de acesso a blocos permite que os agrupadores de blocos informem antecipadamente aos validadores: “As transações neste bloco acessarão estas contas e locais de armazenamento”. Com essa informação, os validadores podem se preparar antecipadamente, carregando esses dados do disco rígido para a memória. Em seguida, os validadores podem verificar várias transações em paralelo, em vez de verificar uma por uma. É como uma linha de produção de fábrica: antes, um único trabalhador era responsável por todo o produto; agora, vários trabalhadores processam diferentes partes simultaneamente.
O ePBS separa o processo de empacotamento e validação de blocos — os construtores de blocos são responsáveis por empacotar transações, os proponentes por propor blocos e os validadores por validar blocos. Cada papel desempenha sua função específica, e, ao fazer bem sua parte, os construtores de blocos podem empacotar ainda mais transações de forma mais agressiva, pois os proponentes e validadores verificarão por eles, eliminando preocupações com segurança.
Reprecificação da taxa de gás + gás multidimensional pode ser considerado um “movimento principal”. Atualmente, todas as operações na Ethereum usam a mesma taxa de gás. Mas a ideia de Vitalik é que operações diferentes devam ter preços diferentes.
Especificamente, a criação de novos estados (por exemplo, criar uma nova conta ou implantar um novo contrato) deve ter uma "taxa de criação de estado" especial, pois a criação de novos estados é a operação mais cara. Ela não apenas consome recursos de computação, mas também recursos de armazenamento. Além disso, esse custo é permanente — uma vez criado, esse estado permanecerá existindo.
Então, a ideia de Vitalik é: tornar a criação de novos estados mais cara, mas tornar as transações comuns mais baratas.
O método implementado é o "mecanismo de reservatório". Imagine dois baldes: um armazenando "taxas de criação de estado" e outro armazenando "taxas de gas normais". Quando contratos se chamam mutuamente, o gás é automaticamente emprestado dos dois reservatórios, garantindo que nada fique desorganizado.
As transações de usuários comuns se tornarão mais baratas, pois não exigirão a "taxa de criação de estado". Desenvolvedores que desejarem criar novos estados precisarão pagar taxas mais altas. Assim, a capacidade geral da rede aumenta drasticamente, enquanto o crescimento do estado é controlado, evitando que o disco rígido dos nós completos fique sobrecarregado.
A expansão de longo prazo consiste em fortalecer a própria rede principal, reduzindo a dependência da Layer 2. Isso inclui a implementação gradual de Blobs + PeerDAS e ZK-EVM.
Blobs, um armazenamento temporário de arquivos grandes, atualmente é usado principalmente por Layer 2. Futuramente, a rede principal da Ethereum também usará Blobs para armazenar dados. Mas surge um problema — se cada nó precisar baixar todos os Blobs, a rede será sobrecarregada.
Aqui entra o PeerDAS — você não precisa baixar todos os dados, apenas uma pequena parte. Assim como uma pesquisa por amostragem, não é necessário perguntar a todos, apenas a um pequeno grupo, para inferir a situação de todo o grupo. Combinado com provas ZK, mesmo baixando apenas 1/16 dos dados, você pode confirmar a integridade dos dados.
Em seguida, temos a implementação em fases do ZK-EVM, que torna desnecessário reexecutar todas as transações dentro de um bloco para validá-lo; os nós simplesmente confiam na prova ZK, reduzindo o custo de validação de "executar todas as transações" para "verificar uma prova ZK".
O plano de Vitalik é que, em 2026, alguns nós testem a verificação ZK. Em 2027, incentivar mais nós a utilizá-la. Por fim, para que um bloco seja válido, deve conter 3 dos 5 tipos de provas de diferentes sistemas de prova. Ele espera que, por fim, todos os nós (exceto os nós de índice) dependam de provas ZK-EVM.
Extensão de estado sem "pílula mágica"
Agora, vamos examinar os "recursos de estado" que ainda não foram abordados no curto e longo prazo. Embora, no curto prazo, ainda seja possível melhorar em cerca de 5 a 30 vezes por meio de sincronização com listas de acesso a blocos, melhorias p2p e otimizações de banco de dados, e no longo prazo?
A resposta de Vitalik é não.
Por que é tão difícil escalar os recursos de estado? O estado da Ethereum é como um enorme banco de dados. Esse banco de dados armazena os saldos de todas as contas, o código de todos os contratos e os dados de todos os locais de armazenamento.
Atualmente, esse banco de dados ainda é pequeno, com apenas cerca de 100 GB, mas se o estado for expandido 20 vezes, serão 2 TB. E se o tempo for ainda maior? 8 TB?
O problema não é que o disco rígido não tenha espaço, mas sim:
- A eficiência do banco de dados é afetada: bancos de dados modernos utilizam estruturas de árvore (como árvores Merkle) para organizar dados. Ao gravar um novo dado, é necessário atualizar toda a árvore. Isso significa que, se você fizer X atualizações, no nível do banco de dados serão X operações adicionais, em vez de apenas uma operação para atualizar uma vez. Quanto mais atualizações, mais operações serão necessárias, e a gravação pode desacelerar drasticamente.
- Dificuldade de sincronização: Um nó recém-adicionado à rede Ethereum precisa baixar todo o estado para validar novos blocos. Se o tamanho dos dados for de 8 TB, a maioria das pessoas terá que esperar muito tempo para baixar, considerando suas velocidades de internet atuais.
Existem soluções, mas Vitalik acha que todas têm problemas:
- “Estado forte sem estado”: os nós não precisam armazenar o estado completo, apenas exigir provas Merkle do usuário. Vitalik considera que este método apresenta problemas de centralização do armazenamento de estado, falhas de transação devido ao acesso dinâmico ao armazenamento e custos de largura de banda.
- "Estado expirado": estados não acessados com frequência são automaticamente removidos do estado ativo. Os nós precisam armazenar apenas os estados mais recentemente acessados, reduzindo significativamente o espaço de armazenamento. Vitalik considera que existe um problema fundamental: ao criar um novo estado, como provar que um determinado estado "nunca existiu"? Suponha que um novo endereço seja criado; será necessário provar que esse endereço nunca foi criado na Ethereum. Isso significa que a criação de cada novo endereço exigiria a verificação de 10 anos de dados históricos, tornando a criação de novos endereços complexa e cara.
O método final de Vitalik é combinar essas duas abordagens, propondo várias novas formas de estado, que representam uma mudança geral na arquitetura de recursos de estado do Ethereum:
- Armazenamento temporário: um armazenamento que expira automaticamente. Por exemplo, pode-se criar uma nova árvore que é automaticamente zerada a cada mês. Esse tipo de armazenamento é adequado para dados temporários, como livro de ordens, pools de liquidez e contadores temporários — dados que geralmente não precisam ser armazenados permanentemente. Após um mês, as ordens antigas expiram e novos pools de liquidez são criados.
- Armazenamento periódico: Semelhante ao armazenamento temporário, mas com um período mais longo, como 1 ano.
Armazenamento restrito: Certos armazenamentos só podem ser acessados de maneiras específicas. Por exemplo, o armazenamento do saldo de um token ERC20 pode ser acessado apenas por meio de uma interface específica. Isso permite que o sistema otimize esse armazenamento.
Ao mesmo tempo, mantenha o estado existente. Assim, a execução pode ser até 1.000 vezes mais barata (por meio do ZK-EVM), mas a criação de novo estado pode ser apenas 20 vezes mais barata.
Vitalik acredita que, com a nova forma de estado, os desenvolvedores têm escolha: continuar usando a forma de estado existente, mas pagando taxas mais altas, ou redesenhar os aplicativos para usar a nova forma de estado e obter taxas mais baixas. Para casos de uso comuns (como saldos ERC20, NFTs), haverá fluxos de trabalho padronizados, enquanto para casos de uso mais complexos (como DeFi), os desenvolvedores precisarão encontrar suas próprias soluções para otimização.
Essa estratégia é bastante interessante, parecendo um esforço dos desenvolvedores em reduzir custos com criatividade, beneficiando os usuários da Ethereum em geral.