De alguma forma, percebi que na Ethereum, nos últimos anos, criou-se uma tradição interessante: em vez de aprimorar a própria máquina virtual, os desenvolvedores simplesmente contornam-na através 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 da Ethereum. Simplificando, é como um sistema de índice, através do qual o sistema busca continuamente dados. O problema é que a estrutura atual — a mesma árvore Merkle de Keccak de 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 também 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. Este 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 deveria usar outra linguagem? Eliminando a camada de tradução, tudo acelera automaticamente. 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 removê-la, e sim reescrevê-la como um contrato inteligente na nova máquina. Contratos antigos continuarão a funcionar, como um motor com um motor substituível.

Vitalik afirmou que a árvore de estado e a máquina virtual representam juntas mais de 80% das limitações de escalabilidade da 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 (dISA) e o conjunto de instruções para prova (pISA). Na opinião deles, esses não devem ser o mesmo. 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 fixar o RISC-V na camada L1, o que será daqui a dois anos?

Essa discussão ocorre em meio a uma mudança maior. Vitalik recentemente questionou a necessidade de um roteiro separado de L2 para a Ethereum. Curiosamente, os L2 não entraram em pânico, mas começaram a repensar ativamente seu papel. Se a Ethereum se torna mais rápida, então os L2 devem 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 troca 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. 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 da 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 o próprio fundamento. 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: a 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.