Autor: Lagosta Cinza, Deep潮 TechFlow
Desenvolvedores de Ethereum têm um hábito tácito: evitar o EVM sempre que possível.
Nos últimos anos, sempre que a cadeia exigia uma nova operação criptográfica, a primeira reação dos desenvolvedores não era implementá-la no EVM, mas sim solicitar a adição de um "contrato pré-compilado", uma maneira direta de contornar a máquina virtual e codificar diretamente no nível do protocolo.
Em 1º de março, Vitalik Buterin publicou uma postagem longa no X, revelando completamente essa questão. Seu comentário original, em essência, dizia: o propósito inteiro da Ethereum é sua universalidade; se o EVM não for bom o suficiente, devemos enfrentar diretamente esse problema e criar uma melhor máquina virtual.
Ele apresentou duas facas cirúrgicas específicas.
Primeiro corte: troque "estrutura de dados"
A primeira alteração refere-se à árvore de estado do Ethereum. Você pode entender isso como o "sistema de índice do livro-razão" do Ethereum, pelo qual todos os acessos ao saldo ou validação de transações precisam percorrer.
O problema é que esta árvore está muito "gorda". A Ethereum usa uma estrutura chamada "Árvore de Merkle Patricia de seis ramos Keccak" (o nome parece um feitiço). O EIP-7864 proposto por Vitalik pretende substituí-la por uma árvore binária mais simples.
Por exemplo: antes, ao consultar um dado, você precisava escolher continuamente entre seis caminhos; agora, só há opções de esquerda e direita. Qual é o resultado? O comprimento da ramificação Merkle é reduzido diretamente para um quarto do original. Para clientes leves, a largura de banda necessária para verificar dados diminui significativamente.
Mas Vitalik não se contenta em apenas mudar a forma das árvores. Ele também quer mudar a "fonte nas folhas", ou seja, a função de hash. As opções candidatas são duas: Blake3 e Poseidon.
- Blake3 pode proporcionar um aumento de velocidade estável;
- Poseidon é mais agressivo e, teoricamente, pode aumentar a eficiência da prova em dezenas de vezes, mas a segurança ainda precisa de mais auditorias.
É digno de nota que este plano na verdade substituiu as Verkle Trees, discutidas pela comunidade por muitos anos. As Verkle eram anteriormente a solução preferida para o hard fork de 2026, mas, devido às ameaças à criptografia de curva elíptica subjacente provenientes da computação quântica, começaram a perder popularidade a partir do meio de 2024, permitindo que a solução baseada em árvores binárias ganhasse terreno.
Segundo corte: troque "máquina virtual", transforme a EVM em um contrato inteligente
A segunda alteração é mais ousada e mais controversa: substituir o EVM pelo arquitetura RISC-V a longo prazo.
RISC-V é um conjunto de instruções aberto que originalmente não tinha relação com blockchain, mas agora é amplamente utilizado internamente em todos os sistemas de prova ZK. A lógica de Vitalik é direta: se os provadores já estão falando a linguagem RISC-V, por que a máquina virtual precisaria falar outra linguagem e exigir uma tradução intermediária? Removendo a camada de tradução, a eficiência aumenta naturalmente.
Um interpretador RISC-V requer apenas algumas centenas de linhas de código. Vitalik disse que este é o formato que uma máquina virtual de blockchain deveria ter.
Ele planejou uma abordagem em três etapas: primeiro, executar contratos pré-compilados na nova máquina virtual, reescrevendo 80% dos contratos pré-compilados existentes com o código da nova VM; segundo, permitir que desenvolvedores implantem contratos diretamente na nova máquina virtual, executando-os em paralelo com o EVM; terceiro, aposentar o EVM, mas não eliminá-lo — ele será reescrito como um contrato inteligente rodando na nova máquina virtual, garantindo total compatibilidade retroativa.
Os proprietários antigos não precisam trocar de carro. Apenas o motor foi trocado silenciosamente; o volante continua sendo o mesmo volante.
Quão importante é a combinação desses dois fatores? Vitalik forneceu um número: a árvore de estado e a máquina virtual juntas representam mais de 80% do gargalo de prova da Ethereum. Em outras palavras, se esses dois componentes não forem modificados, a escalabilidade da Ethereum na era ZK será apenas dar voltas no lugar.
Arbitrum discorda: você não pode exigir que o entregador dirija um empilhadeira só porque o armazém usa um
Mas esta não é uma história em que todos concordam.
Em novembro do ano passado, a equipe principal de desenvolvimento da Arbitrum, a Offchain Labs, publicou uma refutação técnica detalhada. A visão central dos quatro pesquisadores era que o RISC-V é de fato adequado para provas ZK, mas não é adequado como "formato de entrega" para contratos.
Eles fizeram uma distinção fundamental: o "conjunto de instruções de entrega" (dISA) e o "conjunto de instruções de prova" (pISA) não precisam ser a mesma coisa. Seu depósito opera com máxima eficiência usando empilhadeiras, mas isso não significa que o entregador precise dirigir uma empilhadeira até sua porta.
A Offchain Labs defende o uso do WebAssembly (WASM) para a camada de contratos, com argumentos sólidos: o WASM executa com alta eficiência em hardware padrão, enquanto a maioria dos nós da Ethereum não executa chips RISC-V, e uma mudança forçada exigiria emuladores; o WASM possui mecanismos maduros de verificação de segurança de tipos; a cadeia de ferramentas do WASM já foi testada na prática em bilhões de ambientes de execução.
Mais importante ainda, eles não apenas falam sobre isso. A Offchain Labs já implementou um protótipo no Arbitrum: usar o WASM como formato de entrega de contratos, depois compilar para RISC-V para prova ZK. Cada camada realiza sua própria função, sem interferência mútua.
Eles também levantaram um risco digno de reflexão: a tecnologia no campo das provas ZK evolui extremamente rápido, e recentemente a implementação do RISC-V passou de 32 bits para 64 bits. Se agora se fixar o RISC-V diretamente no Ethereum L1, e dois anos depois surgir uma arquitetura de prova superior? Apostar em um alvo em constante movimento não é o estilo do Ethereum.
Um contexto maior: as L2 estão começando a "desmamar"
Para entender esta proposta, é necessário um contexto mais amplo.
Há apenas um mês, Vitalik questionou publicamente se a Ethereum ainda precisava de um "plano de rota L2 dedicado", despertando uma resposta coletiva da comunidade L2. Ben Fisch, CEO da Espresso Systems, disse à CoinDesk uma frase muito acertada: o que Vitalik queria dizer, na verdade, é que o propósito original das L2 era ajudar a Ethereum a escalar; agora que a Ethereum está se tornando mais rápida por conta própria, a posição das L2 naturalmente precisa mudar.
Curiosamente, as L2s não entraram em pânico, mas começaram a se "desethereumizar" ativamente. Jing Wang, cofundador da OP Labs, comparou as L2s a sites independentes, com a Ethereum sendo o padrão aberto de liquidação subjacente. Marc Boiron, CEO da Polygon, foi ainda mais direto: o verdadeiro desafio não é a escalabilidade, mas criar espaço de bloco único para cenários reais, como pagamentos.
Em outras palavras, essa grande mudança de Vitalik na camada de execução é uma nota técnica para uma tendência maior: a Ethereum está retomando o controle sobre suas capacidades centrais, enquanto as L2s estão sendo forçadas — ou finalmente encontrando — sua própria razão de existência.
Will this work?
Vitalik também admitiu que ainda não há consenso amplo da comunidade de desenvolvedores sobre a substituição da máquina virtual. A reforma da árvore de estado é mais madura, e o EIP-7864 já possui um rascunho concreto e uma equipe de avanço. Mas substituir a EVM pelo RISC-V? Isso ainda está na fase de "roteiro", longe de ser implementado no código.
No entanto, Vitalik fez uma declaração impressionante na semana passada: a Ethereum já trocou um dos motores a jato enquanto estava em voo (referindo-se ao The Merge) e ainda poderá trocar cerca de mais quatro — árvore de estado, consenso simplificado, verificação ZK-EVM e substituição da máquina virtual.
A atualização Ethereum Glamsterdam está prevista para ser implementada no primeiro semestre de 2026, seguida pela Hegota. Os detalhes exatos das duas hard forks ainda não foram finalizados, mas a reforma da árvore de estado e a otimização da camada de execução são as linhas mestras confirmadas.
A história da Ethereum nunca foi sobre "se é possível". Ao migrar do PoW para o PoS, e de um modelo L1 all-in para um centro de Rollups, ela já demonstrou ter a capacidade e a coragem de desmontar motores a 10 mil metros de altitude.
O que está sendo alterado agora é algo mais profundo — não se trata de adicionar novas funcionalidades, mas de escavar e recastar as fundações antigas. Será esta uma renovação bem planejada ou um abismo cada vez mais complexo? A resposta provavelmente só será clara em 2027.
Mas pelo menos uma coisa é certa: a Ethereum não pretende ser um "sistema antigo com consertos" na era ZK. Quanto a como desmontar os consertos e qual motor substituir, o próprio debate pode ser mais valioso do que a conclusão.