Vitalik propõe grandes mudanças na Máquina Virtual e na Árvore de Estado do ethereum

Artigo por: Gray Lobster, Shenchao 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 lâminas cirúrgicas específicas.

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 devem percorrer.

O problema é que esta árvore está muito "gorda". A Ethereum usa uma estrutura chamada "hexadecimal Keccak Merkle Patricia Tree" (nome comprido como 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 repetidamente 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 da árvore. Ele também quer mudar a "fonte nas folhas", ou seja, a função de hash. As opções candidatas são Blake3 e Poseidon. Blake3 oferece um aumento estável de desempenho; Poseidon é mais ousada, teoricamente podendo aumentar a eficiência da prova em dezenas de vezes, mas sua 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 opção preferida para o hard fork de 2026, mas, devido às ameaças à criptografia de curva elíptica em que se baseiam provenientes da computação quântica, começaram a perder popularidade a partir do meio de 2024, permitindo que o esquema de árvore binária ganhasse terreno.

A segunda alteração é mais ousada e mais controversa: substituir o EVM pela arquitetura RISC-V a longo prazo.

RISC-V é um conjunto de instruções aberto, originalmente sem relação com blockchain, mas agora é amplamente utilizado dentro de quase 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 secretamente, mas o volante continua sendo o mesmo volante.

Quão importante é juntar essas duas coisas? Vitalik deu 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 essas duas partes não forem modificadas, a escalabilidade da Ethereum na era ZK estará apenas girando em círculos.

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 crucial: o "dISA" (conjunto de instruções de entrega) e o "pISA" (conjunto de instruções de prova) não precisam ser a mesma coisa. Seu armazém pode ser mais eficiente com empilhadeiras, mas isso não significa que o entregador também precise dirigir uma empilhadeira até sua porta.

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 falaram 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 tarefa, 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. E se agora se fixar o RISC-V diretamente no Ethereum L1, mas em dois anos surgir uma arquitetura de prova melhor? Apostar em um alvo em constante movimento não é o estilo do Ethereum.

Para entender esta proposta, ainda é 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", provocando 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.

Interessantemente, as L2s não apenas não entraram em pânico, mas começaram a ativamente "desethereumizar-se". 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 é um footnote técnico de uma tendência maior: a Ethereum está retomando o controle sobre suas capacidades centrais, enquanto as L2 estão sendo forçadas — ou finalmente encontrando — sua própria razão de existência.

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 aproximadamente 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 a capacidade e a coragem de desmontar motores a 10 mil metros de altitude.

O que está sendo alterado agora são coisas mais profundas — 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 patches" na era ZK. Quanto a como desmontar os patches e qual motor substituir, o próprio debate pode ser mais valioso do que a conclusão.