Recentemente, percebi que Vitalik lançou uma série de propostas bastante audaciosas sobre a estrutura fundamental do Ethereum. O que é interessante aqui é que não se trata apenas de melhorias pontuais, mas de "desmontar o motor" enquanto a aeronave está voando a 10.000 metros de altitude.

O problema que Vitalik aponta é bastante interessante: há muito tempo, os desenvolvedores do Ethereum têm o hábito de evitar usar a EVM sempre que possível. Sempre que é necessário adicionar uma nova operação criptográfica, em vez de implementá-la na EVM, eles solicitam uma "contrato pré-compilado" para contornar a máquina virtual completamente. Isso mostra que a EVM está se tornando um gargalo real.

Vitalik propõe duas grandes mudanças. A primeira é uma reformulação da árvore de estado do Ethereum — o "sistema de indexação" que é verificado toda vez que se checa saldo ou valida uma transação. Atualmente, ela usa uma estrutura bastante complexa chamada Árvore Merkle Patricia Keccak. Vitalik quer substituí-la por uma árvore binária mais simples, reduzindo o comprimento dos ramos Merkle para cerca de um quarto. Ao mesmo tempo, propõe mudar a função de hash, podendo usar Blake3 ou Poseidon. Essa mudança reduzirá significativamente a largura de banda necessária para clientes leves.

Mas a segunda mudança é realmente o "big bang": substituir a EVM por uma arquitetura RISC-V a longo prazo. A lógica é bastante simples — se os sistemas de prova ZK já usam RISC-V, por que a máquina virtual deveria usar uma linguagem diferente e adicionar uma camada de tradução entre elas? Eliminar essa camada de tradução aumentará automaticamente o desempenho. Vitalik planeja três etapas: primeiro, executar contratos pré-compilados na nova máquina virtual, depois permitir a implantação direta, e por fim, "aposentar" a EVM, reescrevendo-a como um contrato inteligente rodando na nova VM para garantir compatibilidade total.

O que é interessante é que Vitalik fornece um número: a árvore de estado e a máquina virtual representam mais de 80% do gargalo de prova do Ethereum. Em outras palavras, se não mexermos nessas duas partes, a escalabilidade do Ethereum na era ZK ficará limitada a isso.

Porém, nem todos concordam. A Offchain Labs, equipe de desenvolvimento do Arbitrum, respondeu com bastante detalhe. Eles dizem que RISC-V é realmente adequado para criar provas ZK, mas não é adequado como "formato de entrega" para contratos. Eles fazem uma distinção entre "conjunto de instruções de entrega" e "conjunto de instruções de prova" — duas coisas que não precisam ser iguais. A Offchain Labs propõe usar WebAssembly (WASM) para a camada de contratos, pois o WASM funciona eficientemente em hardware padrão, possui mecanismos de verificação de tipo seguros, e seu ecossistema de ferramentas já foi testado bilhões de vezes na prática. Eles até implementaram um protótipo no Arbitrum: usar WASM como formato de transação, depois compilá-lo para RISC-V para criar provas ZK. Essas duas camadas operam de forma independente.

A Offchain Labs também aponta um risco importante: a tecnologia de provas ZK muda extremamente rápido, e recentemente o RISC-V passou de 32 bits para 64 bits. Se travarmos o RISC-V no Ethereum L1 agora, e daqui a dois anos surgir uma arquitetura melhor, o que acontecerá?

O contexto maior é que as L2 estão começando a "se libertar" do Ethereum. Um mês atrás, Vitalik questionou se o Ethereum ainda precisa de uma "estratégia L2 dedicada". Em vez de entrar em pânico, as L2 estão ativamente "se libertando do Ethereum", buscando razões para existirem de forma independente.

Vitalik também admite que substituir a EVM ainda não conta com consenso amplo entre os desenvolvedores. A reforma da árvore de estado está mais madura, com um rascunho concreto, mas substituir a EVM por RISC-V ainda está na fase de "roteiro". No entanto, Vitalik anunciou recentemente que o Ethereum já mudou seu motor de propulsão uma vez (The Merge), e pode fazer mais cerca de quatro mudanças — incluindo a árvore de estado, a simplificação do consenso, a validação ZK-EVM, e a substituição da máquina virtual.

O upgrade Glamsterdam está previsto para ser implementado na primeira metade de 2026, seguido pelo Hegota. Reformas na árvore de estado e otimizações na camada de execução são os principais rumos já definidos. A questão real não é "se é possível ou não", mas como remover as peças de conserto. O Ethereum já demonstrou essa capacidade ao migrar de PoW para PoS, de L1 tudo para o centro de Rollups. Desta vez, ele está escavando a fundação antiga para refazê-la, e não apenas adicionando novos recursos. Trata-se de uma reforma de visão de longo prazo, e a resposta provavelmente ficará clara até 2027. Mas uma coisa é certa: o Ethereum não pretende se tornar um "sistema antigo que precisa de correções" na era ZK.