De alguma forma, percebi que nos últimos anos, o Ethereum desenvolveu uma tradição interessante: em vez de aprimorar a própria máquina virtual, os desenvolvedores simplesmente a contornam por meio de contratos pré-compilados. Mas Vitalik não para por aí. Recentemente, ele apresentou um plano detalhado de como reformular tudo do zero.

A primeira parte do plano refere-se à árvore de estado do Ethereum. Simplificando, é como um sistema de índice pelo qual o sistema busca dados continuamente. O problema é que a estrutura atual — a mesma árvore Merkle de Keccak com seis ramos — é demasiado volumosa. O EIP-7864, proposto por Vitalik, substitui-a por uma árvore binária. Em vez de escolher entre seis direções, você simplesmente escolhe esquerda ou direita. O resultado? O comprimento da árvore Merkle é reduzido em quatro vezes. Para clientes leves, isso significa uma redução significativa na demanda de largura de banda.

Mas isso ainda não é tudo. Vitalik quer alterar a própria função hash. No palco, há dois candidatos: Blake3, que oferece uma aceleração estável, e Poseidon, que teoricamente pode aumentar a eficiência das provas em dezenas de vezes, embora a segurança ainda esteja sendo verificada. Esse plano efetivamente substitui as Árvores Verkle, que foram discutidas por anos pela comunidade, mas perderam popularidade devido à ameaça de cálculos quânticos.

O segundo passo é ainda mais ambicioso: substituir a arquitetura da EVM por uma arquitetura RISC-V. A lógica é simples — se os sistemas de provas ZK já entendem RISC-V, por que a máquina deve usar outra linguagem? Eliminando a camada de tradução, tudo automaticamente acelera. Vitalik planeja três etapas: primeiro, reescrever 80% dos contratos pré-compilados na nova VM; depois, permitir que os desenvolvedores implantem contratos diretamente; e, por fim, retirar a antiga EVM de operação — mas não excluí-la, e sim reescrevê-la como um contrato inteligente na nova máquina. Contratos antigos continuarão funcionando, como um motor com um motor substituível.

Vitalik afirmou que a árvore de estado e a máquina virtual representam mais de 80% das limitações na prova do Ethereum. Sem essas mudanças, a escalabilidade na era ZK simplesmente não avançará.

Mas nem todos concordam. A equipe da Arbitrum Offchain Labs publicou uma objeção técnica detalhada. Sua posição: RISC-V é bom para provas ZK, mas nem sempre é uma boa opção como formato para contratos. Eles fizeram uma distinção entre o conjunto de instruções para entrega de (dISA) e o conjunto para provas (pISA). Na opinião deles, isso não deve ser a mesma coisa. Propõem usar WebAssembly para o nível de contratos, seguido de compilação para RISC-V para provas. Já lançaram um protótipo na Arbitrum, e funciona. Além disso, apontaram um risco: as tecnologias ZK mudam rapidamente, e se agora fixarmos o RISC-V na camada L1, o que acontecerá daqui a dois anos?

Essa discussão ocorre em meio a uma mudança maior. Recentemente, Vitalik questionou a necessidade de um roteiro separado de L2 para o Ethereum. Curiosamente, as soluções L2 não entraram em pânico, mas começaram a repensar ativamente seu papel. Se o Ethereum se tornar mais rápido, então o L2 deve encontrar seus espaços únicos — não apenas escalabilidade, mas cenários de aplicação reais.

O próprio Vitalik reconheceu que ainda não há consenso sobre a substituição da EVM. A reforma da árvore de estado avançou — o EIP-7864 já possui um projeto concreto. Mas a substituição por RISC-V? Isso ainda está no nível do roteiro. O hard fork Glamsterdam está previsto para o primeiro semestre de 2026, seguido por Hegota. Os detalhes específicos ainda não foram aprovados, mas a reforma da árvore de estado e a otimização do nível de execução são direções definidas.

A história do Ethereum sempre foi sobre o que é possível. Da transição de PoW para PoS, de L1 para Rollup — o sistema já provou que está pronto para desmontar motores em altitudes de dez mil metros. Desta vez, trata-se de questões mais profundas: não de adicionar funções, mas de reformar a própria fundação. Será um reparo cuidadosamente planejado ou um poço que se torna mais difícil de escalar? A resposta só aparecerá antes de 2027. Mas uma coisa é certa: o Ethereum não pretende ser um sistema antigo com patches. Essa própria discussão sobre como desmontar patches e qual motor instalar talvez seja mais valiosa do que qualquer conclusão.