Alguns meses atrás, 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 a EVM com novos contratos pré-compilados, talvez seja hora de repensar toda a arquitetura?

E ele propôs duas mudanças sérias. A primeira diz respeito à á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 muito volumosa. Para cada consulta, é preciso percorrer muitas 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 golpe é muito mais audacioso - uma substituição de 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 outra linguagem? Isso apenas adiciona uma tradução extra. O interpretador RISC-V precisa de apenas algumas centenas de linhas de código - exatamente o que deveria ser a interface do blockchain.

Estão planejadas três etapas: primeiro, lançar contratos pré-compilados na nova VM, depois permitir que desenvolvedores implantem contratos na nova máquina junto com a EVM, e por fim, desativar a EVM, mas não removê-la - apenas reescrevê-la como um contrato inteligente na nova plataforma. 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 escalabilidade 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 testados, e o ecossistema de ferramentas do WASM foi testado em bilhões de execuções.

Isso é interessante, porque aponta para 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 da 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 provavelmente sabe o que está fazendo. 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 reforma cuidadosamente planejada ou um buraco infinito de complexidade - a resposta provavelmente só aparecerá em 2027.