Autor: Gray Lobster, Deep Tide TechFlow
Os desenvolvedores do Ethereum têm um hábito tácito: se puder evitar usar EVM, evita-se usar EVM.
Nos últimos anos, sempre que uma nova operação criptográfica era necessária na cadeia, a primeira reação dos desenvolvedores não era implementá-la na EVM, mas solicitar a adição de um “contrato pré-compilado”, uma forma de contornar a máquina virtual, codificando diretamente na camada do protocolo.
Em 1 de março, Vitalik Buterin publicou um longo post no X, revelando essa camada de superficialidade. Sua mensagem principal foi: todo o significado do Ethereum reside na sua versatilidade; se a EVM não for suficiente, devemos resolver isso de frente, criando uma máquina virtual melhor.
Ele apresentou duas abordagens concretas.
Primeira abordagem: trocar a “estrutura de dados”
A primeira mudança é na árvore de estado do Ethereum. Pode-se entender isso como o “sistema de índice do livro-razão” do Ethereum, onde cada consulta de saldo ou validação de transação exige percorrer essa árvore.
O problema é que, agora, essa árvore está muito “gorda”. O Ethereum usa uma estrutura chamada “Árvore Merkle de Keccak de seis ramos” (nome longo como um feitiço). A proposta do Vitalik, EIP-7864, é substituí-la por uma árvore binária mais simples.
Para ilustrar: antes, consultar um dado envolvia escolher entre seis caminhos, agora só há esquerdo e direito. O resultado? O comprimento das ramificações Merkle é reduzido a um quarto do original. Para clientes leves, isso reduz drasticamente a largura de banda necessária para validação.
Mas Vitalik não quer apenas trocar a forma da árvore. Ele também quer trocar a “fonte dos hashes”, ou seja, a função de hash. As opções são duas: Blake3 e Poseidon.
- Blake3 oferece velocidade estável;
- Poseidon é mais agressivo, potencialmente aumentando a eficiência de provas dezenas de vezes, mas sua segurança ainda precisa de mais auditorias.
Vale destacar que essa solução substitui, na prática, as Verkle Trees, discutidas por anos na comunidade. As Verkle Trees eram a principal escolha para o hard fork de 2026, mas, devido à ameaça quântica na criptografia de curvas elípticas, começaram a perder popularidade a partir de meados de 2024, enquanto a abordagem de árvores binárias ganhou espaço.
Segunda abordagem: trocar a “máquina virtual”, transformando a EVM em um contrato inteligente
A segunda mudança é mais audaciosa e controversa: substituir a EVM por uma arquitetura RISC-V de longo prazo.
RISC-V é um conjunto de instruções de código aberto, inicialmente sem relação com blockchain, mas atualmente usado na maioria dos sistemas de provas ZK. A lógica de Vitalik é direta: já que os provadores usam RISC-V, por que manter uma máquina virtual que fala outra linguagem, com uma camada de tradução? Eliminando essa camada, a eficiência aumenta.
Um interpretador RISC-V precisa de apenas algumas centenas de linhas de código. Vitalik afirma que essa é a forma ideal de uma máquina virtual de blockchain.
Ele planeja três etapas: primeiro, usar a nova VM para executar contratos pré-compilados, reescrevendo 80% deles com a nova VM; segundo, permitir que desenvolvedores implantem contratos na nova VM paralelamente à EVM; terceiro, desativar a EVM, mas não eliminá-la — ela será reescrita como um contrato inteligente rodando na nova VM, garantindo compatibilidade total.
Os usuários antigos não precisam trocar de carro. Apenas o motor será substituído silenciosamente, mantendo o volante na mesma direção.
Qual a importância dessas mudanças? Vitalik fornece um número: a árvore de estado e a VM representam mais de 80% do gargalo de prova do Ethereum. Em outras palavras, sem mexer nessas duas áreas, a escalabilidade do Ethereum na era ZK ficará estagnada.
Discordância do Arbitrum: você não pode usar um empilhador na sua loja e esperar que o entregador também use um
Porém, essa não é uma história unânime.
Em novembro passado, a equipe principal do Arbitrum, Offchain Labs, publicou uma refutação técnica detalhada. Quatro pesquisadores argumentaram que: RISC-V é adequado para provas ZK, mas não para o “formato de entrega” de contratos.
Eles fizeram uma distinção importante: “conjunto de instruções de entrega” (dISA) e “conjunto de instruções de prova” (pISA) não precisam ser iguais. Usar um empilhador na loja é ótimo, mas isso não significa que o entregador também precise usar um.
Offchain Labs defende o uso de WebAssembly (WASM) como formato de entrega de contratos, com fundamentos sólidos: WASM é eficiente em hardware padrão; a maioria dos nós Ethereum não roda chips RISC-V, então seria necessário um emulador; WASM possui mecanismos maduros de validação de segurança de tipos; sua ecologia de ferramentas já foi testada em bilhões de ambientes de execução.
Mais importante, eles já testaram na prática: criaram um protótipo no Arbitrum usando WASM como formato de entrega, compilando para RISC-V para provas ZK. Assim, as duas camadas operam independentemente, sem interferir.
Eles também alertam para um risco: a tecnologia de provas ZK evolui rapidamente. Recentemente, a implementação de RISC-V passou de 32 bits para 64 bits. Se hoje travarmos o RISC-V na camada L1 do Ethereum, e daqui a dois anos surgir uma arquitetura melhor, estaremos presos a uma aposta em um alvo em rápida mudança — algo que não é típico do estilo do Ethereum.
Um contexto maior: as L2 estão começando a “se emancipar”
Para entender essa proposta, é preciso um panorama mais amplo.
Há um mês, Vitalik questionou publicamente se o Ethereum ainda precisa de um “roteiro específico para L2”, provocando uma resposta coletiva da comunidade L2. Ben Fisch, CEO da Espresso Systems, comentou ao CoinDesk que: o objetivo inicial do L2 era escalar o Ethereum; agora, com o Ethereum ficando mais rápido, o papel do L2 deve evoluir.
Curiosamente, as L2 não estão assustadas, mas sim começando a se “deseternizar”. Jing Wang, cofundador da OP Labs, comparou as L2 a sites independentes, enquanto o Ethereum é a camada de liquidação aberta. Marc Boiron, CEO da Polygon, foi mais direto: o verdadeiro desafio não é escalar, mas criar espaço de bloco exclusivo para cenários reais, como pagamentos.
Em outras palavras, a grande mudança na execução do Ethereum reflete uma tendência maior: o Ethereum está recuperando o controle de suas capacidades centrais, enquanto as L2 estão, por necessidade ou por escolha, encontrando razões para sua existência independente.
Isso pode dar certo?
Vitalik admite que: a substituição da VM ainda não tem consenso amplo na comunidade de desenvolvedores. A reforma na árvore de estado, com a EIP-7864, já possui um rascunho concreto e uma equipe de avanço. Mas a substituição do EVM por RISC-V? Ainda está no estágio de “roteiro”, longe de ser codificada.
Porém, Vitalik deu uma declaração impressionante na semana passada: o Ethereum já trocou seu motor a jato uma vez (referindo-se ao The Merge), e pode trocar mais cerca de quatro vezes — árvore de estado, consenso enxuto, validação ZK-EVM, substituição da VM.
A atualização Glamsterdam, prevista para o primeiro semestre de 2026, e a Hegota, logo após, ainda não têm detalhes finais, mas a reforma na árvore de estado e otimizações na camada de execução são as principais linhas de desenvolvimento.
A história do Ethereum nunca foi uma questão de “se é possível”. Desde a transição de PoW para PoS, passando por sua expansão de L1 para Rollups, ele já demonstrou capacidade e coragem para desmontar seu motor em alta altitude.
O que está em jogo agora é algo mais profundo — não adicionar novas funcionalidades, mas escavar e reconstruir a fundação antiga. Será uma renovação planejada ou um buraco sem fundo de complexidade crescente? A resposta só deve ficar clara em 2027.
Mas uma coisa é certa: o Ethereum não pretende ser apenas um “sistema antigo com patches” na era ZK. Quanto às atualizações, a discussão sobre como trocar o motor e quais componentes usar pode ser, talvez, mais valiosa do que a própria conclusão.
