Os programadores de Ethereum seguem uma regra tácita: evitar a EVM sempre que possível.
Nos últimos anos, sempre que era necessário implementar uma nova operação criptográfica na cadeia, os programadores optaram por não a integrar na EVM, preferindo solicitar um “contrato pré-compilado”—um atalho que contorna a máquina virtual e codifica diretamente a operação na camada do protocolo.
No dia 1 de março, Vitalik Buterin publicou uma longa thread no X, quebrando abertamente esta regra não escrita. Defendeu, em essência, que o valor de Ethereum reside na sua generalidade. Se a EVM for insuficiente, devemos enfrentar o problema diretamente e construir uma máquina virtual superior.
Propôs duas soluções concretas.
Primeira solução: Alterar a “estrutura de dados”
A primeira alteração incide sobre a árvore de estado de Ethereum, que funciona como sistema de indexação do livro-razão da rede. Sempre que alguém consulta um saldo ou verifica uma transação, percorre esta árvore.
O problema é que a árvore atual é demasiado “volumosa”. Ethereum utiliza uma estrutura denominada “árvore hexária Keccak Merkle Patricia” (o nome soa a feitiço). A EIP-7864 de Vitalik propõe substituí-la por uma árvore binária mais eficiente.
Para comparação: anteriormente, consultar um dado implicava escolher repetidamente entre seis direções em cada interseção. Agora, está reduzido apenas a esquerda ou direita. O resultado? O comprimento dos ramos Merkle reduz-se a um quarto do tamanho original. Para clientes leves, os requisitos de largura de banda para verificação de dados diminuem significativamente.
Vitalik não se limita a remodelar a árvore. Pretende também alterar a “fonte nas folhas”—a função hash. Os dois candidatos são Blake3 e Poseidon. Blake3 oferece melhorias consistentes de velocidade; Poseidon é mais radical e poderá teoricamente aumentar a eficiência das provas em dezenas de vezes, embora a sua segurança ainda careça de auditoria adicional.
Importa salientar que esta proposta substitui as Verkle Trees anteriormente discutidas. Verkle era o principal candidato para o hard fork de 2026, mas a sua criptografia de curvas elípticas subjacente enfrenta ameaças da computação quântica. Desde meados de 2024, Verkle perdeu relevância, permitindo que a solução da árvore binária ganhe força.
A segunda alteração é ainda mais ousada e controversa: substituir a EVM pela arquitetura RISC-V a longo prazo.
RISC-V é um conjunto de instruções open-source, originalmente sem ligação à blockchain, mas atualmente quase todos os sistemas de provas ZK utilizam-no internamente. A lógica de Vitalik é clara: se os provadores já usam RISC-V, porque deveria a máquina virtual usar algo diferente, exigindo uma camada de tradução? Eliminar essa camada melhora naturalmente a eficiência.
Um interpretador RISC-V requer apenas algumas centenas de linhas de código. Vitalik argumenta que é isto que uma máquina virtual blockchain deve ser.
O seu plano tem três etapas: primeiro, usar a nova máquina virtual para contratos pré-compilados, reescrevendo 80% dos pré-compilados existentes com novo código de VM; segundo, permitir aos programadores implementar contratos para a nova VM, funcionando em paralelo com a EVM; terceiro, aposentar a EVM—não eliminando-a, mas reescrevendo-a como um contrato inteligente a correr na nova máquina virtual, garantindo total compatibilidade retroativa.
Os utilizadores existentes não precisam de trocar de carro—apenas o motor é silenciosamente substituído, mantendo o volante igual.
Qual é a importância destas duas alterações em conjunto? Vitalik apresentou um número: a árvore de estado e a máquina virtual representam mais de 80% do gargalo das provas em Ethereum. Sem abordar estas duas áreas, a escalabilidade de Ethereum na era ZK estagnaria.
Arbitrum discorda: Só porque o armazém usa empilhadores não significa que os estafetas devam conduzi-los
Mas nem todos concordam.
Em novembro do ano passado, a equipa principal de desenvolvimento de Arbitrum, Offchain Labs, publicou uma refutação técnica detalhada. Os seus quatro investigadores argumentaram que, embora o RISC-V seja adequado para provas ZK, não é apropriado como “formato de entrega” para contratos.
Introduziram uma distinção fundamental: o “conjunto de instruções de entrega” (dISA) e o “conjunto de instruções de prova” (pISA) não precisam de ser iguais. Utilizar empilhadores no armazém pode maximizar a eficiência, mas isso não significa que os estafetas devam usá-los para entregar encomendas à porta.
A Offchain Labs defende a utilização de WebAssembly (WASM) na camada de contratos, apresentando razões sólidas: WASM executa eficientemente em hardware padrão, e a maioria dos nós de Ethereum não utiliza chips RISC-V—obrigar a mudança exigiria emuladores; WASM oferece verificação madura de segurança de tipos; o ecossistema de ferramentas de WASM foi testado em milhares de milhões de ambientes de execução.
Importa salientar que não estão apenas a teorizar. A Offchain Labs já implementou um protótipo em Arbitrum: usando WASM como formato de entrega de contratos, compilando depois para RISC-V para provas ZK. As duas camadas operam de forma independente.
Também levantaram um risco pertinente: a tecnologia de provas ZK evolui rapidamente, e recentemente as implementações de RISC-V passaram de 32 para 64 bits. Se o RISC-V for integrado no Ethereum L1 agora, o que acontece se surgir uma arquitetura de provas superior daqui a dois anos? Apostar num alvo em constante mudança não é o estilo de Ethereum.
Um contexto mais amplo: L2s começam a “desmamar”
Compreender esta proposta exige uma perspetiva mais abrangente.
Há apenas um mês, Vitalik questionou publicamente se Ethereum ainda necessita de um “roteiro dedicado para L2”, provocando uma resposta coletiva do ecossistema L2. Ben Fisch, CEO da Espresso Systems, disse à CoinDesk: O ponto de Vitalik é que as L2s foram originalmente concebidas para ajudar Ethereum a escalar, mas agora que Ethereum está a ficar mais rápido, o papel das L2s muda naturalmente.
Curiosamente, em vez de entrar em pânico, as L2s estão a “desethereumizar” de forma proativa. Jing Wang, cofundador da OP Labs, comparou as L2s a sites independentes, com Ethereum como o padrão aberto de liquidação subjacente. Marc Boiron, CEO da Polygon, foi direto: o verdadeiro desafio não é escalar, mas criar espaço de bloco único para cenários reais, como pagamentos.
Ou seja, a revisão da camada de execução por Vitalik é uma nota técnica num fenómeno maior: Ethereum está a recuperar o controlo das suas capacidades centrais, enquanto as L2s são forçadas—ou finalmente encontram—motivos para existirem de forma independente.
Pode isto ter sucesso?
O próprio Vitalik admite que substituir a máquina virtual ainda não reúne consenso entre os programadores. A reforma da árvore de estado está mais madura, com a EIP-7864 já em rascunho e uma equipa dedicada. Mas substituir a EVM por RISC-V? Ainda está na fase de “roteiro”, longe de ser implementada.
No entanto, na semana passada, Vitalik fez uma afirmação memorável: Ethereum já trocou um motor a jato em pleno voo (referindo-se ao The Merge), e pode fazê-lo mais quatro vezes—árvore de estado, consenso simplificado, verificação ZK-EVM e substituição da máquina virtual.
A atualização Glamsterdam de Ethereum é esperada para o primeiro semestre de 2026, com Hegota logo a seguir. O conteúdo exato dos dois hard forks ainda não está definido, mas a reforma da árvore de estado e a otimização da camada de execução estão confirmadas como temas principais.
A história de Ethereum nunca foi sobre “será que é possível”. Do PoW ao PoS, do L1 ao Rollup-centric, provou a sua capacidade e coragem para desmontar motores em altitude de cruzeiro.
Desta vez, trata-se de algo mais profundo—não adicionar novas funcionalidades, mas rasgar as fundações antigas e reconstruí-las. Será uma renovação ponderada, ou um abismo de complexidade cada vez maior? A resposta provavelmente só será clara em 2027.
Mas pelo menos uma coisa é certa: Ethereum não pretende ser um “sistema velho remendado” na era ZK. Quanto à forma de remover os remendos e ao tipo de motor a instalar, o debate poderá ser mais valioso do que a conclusão.
Aviso:
-
Este artigo foi republicado a partir de TechFlow, com direitos de autor pertencentes ao autor original [Gray Lobster]. Caso tenha alguma objeção a esta republicação, contacte a equipa Gate Learn, que tratará do assunto de acordo com os procedimentos relevantes.
-
Aviso: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem aconselhamento de investimento.
-
As versões noutras línguas deste artigo foram traduzidas pela equipa Gate Learn. Sem menção explícita a Gate, não copie, distribua ou plagie artigos traduzidos.
