Há alguns meses, Vitalik lançou uma ideia muito interessante: o Ethereum na verdade tem problemas mais profundos do que parecem à primeira vista. Em vez de constantemente consertar o EVM com novos contratos pré-compilados, talvez seja hora de repensar a própria arquitetura?

E então ele propôs duas mudanças sérias. A primeira refere-se à árvore de estado - aquela mesma árvore Merkle, que o Ethereum usa como sistema de índice para todos os saldos e verificações. O problema é que a estrutura atual, a chamada árvore Merkle Patricia de seis ramos, é simplesmente demasiado volumosa. Para cada consulta, é preciso percorrer uma grande quantidade de ramificações.

Vitalik sugere o EIP-7864 - substituir isso por uma árvore binária. Parece simples, mas o efeito é impressionante: o comprimento da árvore Merkle é reduzido em quatro vezes. Para clientes leves, isso significa muito menos dados para verificar. Mas ele não parou por aí - quer também alterar a própria função hash. Blake3 ou Poseidon? Poseidon é mais ambiciosa, teoricamente pode aumentar a eficiência das provas em dezenas de vezes, mas a segurança ainda precisa ser verificada.

O segundo ponto é muito mais audacioso - uma substituição a longo prazo do EVM por RISC-V. A lógica é simples: se os sistemas de provas ZK já entendem RISC-V, por que a máquina virtual deveria usar uma linguagem diferente? Isso apenas adiciona uma tradução extra. O interpretador RISC-V requer apenas algumas centenas de linhas de código - exatamente o que deveria ser a interface do blockchain.

Estão planejadas três fases: primeiro, lançar contratos pré-compilados na nova VM, depois permitir que desenvolvedores implantem contratos na nova máquina ao lado do EVM, e finalmente retirar o EVM de operação, mas não excluí-lo - apenas reescrevê-lo como um contrato inteligente na nova plataforma. Os contratos antigos continuarão funcionando sem alterações.

Vitalik citou um número: a árvore de estado e a máquina virtual representam mais de 80% das limitações de prova do Ethereum. Sem essas mudanças, a escalabilidade na era ZK simplesmente ficará parada no lugar.

Mas nem todos concordam. A equipe da Arbitrum Offchain Labs publicou uma objeção séria. Eles dizem: sim, RISC-V é ótimo para provas ZK, mas isso não significa que os contratos devam ser escritos em RISC-V. Propuseram dividir isso - WebAssembly para contratos, e depois compilação para RISC-V para provas. O argumento deles: a maioria dos nós do Ethereum não roda em chips RISC-V, o WASM possui mecanismos de segurança comprovados, e o ecossistema de ferramentas WASM foi testado em bilhões de execuções.

Isso é interessante, porque indica uma tendência maior. As soluções L2 começaram a entender que seu papel está mudando. O próprio Ethereum está se tornando mais rápido, então as L2 buscam seu propósito único - não apenas escalabilidade, mas espaços especializados para cenários reais.

Sobre se isso será possível de implementar - não há consenso. A reforma da árvore Merkle é mais concreta, o EIP-7864 já tem uma equipe. Mas a substituição do EVM? Ainda está na fase de roteiro. Hard forks Glamsterdam e Hegota estão previstos para o primeiro semestre de 2026, mas os detalhes ainda não foram aprovados.

Mas Vitalik certamente sabe o que faz. O Ethereum já mudou um motor reativo durante o voo - o The Merge. Ele estava pronto para mudar mais cerca de quatro. Não se trata apenas de adicionar funções, mas de reformar o próprio fundamento. Se será uma manutenção cuidadosamente planejada ou um buraco infinito de complexidade - a resposta provavelmente só aparecerá em 2027.