Percebi algo interessante ultimamente. Vitalik volta com propostas bastante radicais sobre a arquitetura do Ethereum, e sinceramente, isso merece ser discutido.

Então, aqui vai, há anos, os desenvolvedores do Ethereum têm um tipo de hábito ruim. Sempre que precisavam de uma nova operação criptográfica na cadeia, ao invés de implementá-la corretamente na EVM, eles simplesmente contornavam o problema adicionando contratos pré-compilados ao nível do protocolo. É como se estivessem improvisando constantemente ao invés de refazer as fundações. Vitalik basicamente disse: pare, isso já deu. Se a EVM não é boa o suficiente, não vamos continuar empilhando remendos. Vamos substituí-la.

Ele propôs duas mudanças principais. A primeira diz respeito à árvore de estado do Ethereum, que você pode ver como o sistema de indexação do registro. Atualmente, é uma estrutura complicada chamada árvore de Merkle Patricia sextupla Keccak (sim, o nome é meio louco). A ideia é substituí-la por uma árvore binária simples. Concretamente, ao invés de escolher sua direção em um cruzamento de seis ramos, você teria apenas duas opções: esquerda ou direita. Resultado? O comprimento dos ramos Merkle diminui cerca de 75%. Para clientes leves, isso é enorme em termos de largura de banda.

Mas Vitalik não para por aí. Ele também quer mudar a função de hash. Dois candidatos: Blake3 ou Poseidon. Blake3 é seguro, clássico. Poseidon é mais ambicioso, teoricamente poderia multiplicar a eficiência das provas por várias dezenas de vezes, mas precisa de mais auditorias de segurança.

A segunda mudança é mais controversa: substituir a EVM por RISC-V a longo prazo. RISC-V é um conjunto de instruções open source, inicialmente criado para outra coisa, mas agora usado em todos os sistemas de prova ZK. A lógica é simples: já que todos os provadores já falam RISC-V, por que a máquina virtual usaria outra linguagem com uma camada de tradução intermediária? Isso é ineficiente. Um interpretador RISC-V exige apenas algumas centenas de linhas de código.

Vitalik apresentou um plano em três etapas: primeiro, executar os contratos pré-compilados na nova máquina virtual, depois permitir que os desenvolvedores implantem diretamente nesta nova arquitetura em paralelo com a EVM existente, e por fim, remover a EVM, mas reescrevê-la como contrato inteligente na nova máquina virtual. Zero ruptura de compatibilidade. É elegante.

Os números que ele forneceu são impressionantes: a árvore de estado e a máquina virtual representam juntas mais de 80% do gargalo de prova do Ethereum. Em outras palavras, sem mexer nesses dois componentes, você pode esquecer a verdadeira escalabilidade na era ZK.

Mas claro, não é unânime. Offchain Labs, a equipe por trás do Arbitrum, publicou uma refutação técnica detalhada. O argumento deles: RISC-V é bom para provas ZK, mas não para servir como formato de entrega de contratos. Eles fazem uma distinção importante: você não precisa que o entregador conduza um empilhador só porque seu depósito usa um. Eles defendem o WebAssembly (WASM) para a camada de contratos, e sinceramente, seus argumentos são sólidos. WASM é executado eficientemente em hardware padrão, enquanto a maioria dos nós do Ethereum não roda em chips RISC-V. Offchain Labs já implementou um protótipo: WASM para contratos, compilado em RISC-V para prova ZK. Duas camadas, cada uma fazendo seu trabalho.

O que é interessante é o contexto mais amplo. Alguns meses atrás, Vitalik questionou a necessidade do Ethereum ter uma folha de rota L2 dedicada. E os L2 não entram em pânico, eles começam ativamente a se "des-ethereumizar". Polygon e OP Labs agora falam do Ethereum como um padrão de liquidação subjacente, não como sua infraestrutura principal. É uma mudança de orientação.

O próprio Vitalik reconhece que ainda não há um consenso amplo sobre a substituição da EVM. A reforma da árvore de estado está mais avançada com o EIP-7864, que já tem um projeto concreto. Mas substituir a EVM por RISC-V? Ainda está na fase do plano estratégico, longe de ser integrado ao código.

O que me impressionou foi o que ele declarou recentemente: o Ethereum já trocou um motor a jato em voo com o The Merge, e ainda pode fazer isso cerca de quatro vezes mais. A árvore de estado, o consenso simplificado, a verificação ZK-EVM, a substituição da máquina virtual. É ambicioso.

A verdadeira questão é: isso é uma renovação pensada ou um buraco sem fundo que só cresce? Impossível dizer por enquanto. Mas uma coisa é certa: o Ethereum não pretende se tornar um sistema antigo remendado na era ZK. Como desmontar os remendos e qual modelo implementar, esse próprio debate pode ser mais valioso do que a resposta final.