Vitalik Apresenta a Ethereum EVM e State Tree: Uma Mudança Radical no Futuro

As últimas semanas provocaram uma profunda discussão na comunidade Ethereum sobre a parte mais importante da arquitetura do blockchain. No primeiro trimestre de 2025, Vitalik Buterin lançou uma análise abrangente de como a Ethereum deve ser mudada desde a sua base. Sua tese é direta: a EVM e a estrutura da árvore de estado não são suficientes para o futuro da Ethereum na era das provas de conhecimento zero. A comunidade de desenvolvedores profissionais reagiu em diferentes níveis—desde apoio até rejeição direta às propostas principais.

Por que é preciso mudar a EVM? O grande gargalo de desempenho

Para entender a urgência da mudança, é preciso saber onde está o problema atualmente. Ao longo de mais de dez anos, a EVM (Máquina Virtual do Ethereum) foi o centro do ecossistema Ethereum. Mas, à medida que a rede cresce e tecnologias avançadas como as ZK proofs surgem, suas limitações tornam-se mais evidentes.

Vitalik forneceu um diagnóstico concreto: a árvore de estado e a arquitetura da máquina virtual representam mais de 80% do gargalo computacional para provas de blockchain. Em outras palavras, mesmo que outras partes do sistema sejam eficientes, se esses dois aspectos não forem resolvidos, o Ethereum não conseguirá escalar bem no futuro. É como tentar acelerar um carro pesado com um motor antigo e sem potência.

Dois passos principais: revisão estrutural da árvore de estado e substituição completa da EVM

Vitalik propôs duas soluções interligadas que não devem ser vistas apenas como uma. Cada uma aborda diferentes aspectos do problema de desempenho.

Primeiro passo: substituição da árvore de estado por uma estrutura binária

Atualmente, o Ethereum usa uma estrutura complexa chamada “árvore Merkle Patricia hexária”—o nome reflete sua complexidade. A proposta EIP-7864 visa substituí-la por uma estrutura de árvore binária mais simples.

A implicação prática é significativa. No sistema atual, ao precisar identificar uma transação ou saldo específicos, é necessário fazer várias decisões em cada nível da árvore—seis possibilidades em cada nó. Com uma árvore binária, há apenas duas opções: esquerda ou direita. O resultado é direto: o comprimento do ramo Merkle reduz-se até quatro vezes.

Para clientes leves e sistemas de verificação distribuída, isso é revolucionário. A demanda de banda para verificar dados diminui bastante. Para os usuários finais, significa verificações de transações mais rápidas e menor custo computacional.

Mas Vitalik não parou por aí. A proposta também inclui uma mudança na função de hash—o “tipo” de computação, por assim dizer. Existem duas candidatas: Blake3 e Poseidon. Blake3 oferece melhorias de desempenho consistentes. Poseidon é mais agressivo e, teoricamente, pode aumentar a eficiência das provas em várias dezenas de vezes—mas ainda precisa de mais auditorias de segurança antes de ser aprovada.

Essa escolha também sinaliza indiretamente: a Ethereum abandonou a abordagem das Árvores Verkle, que vinha sendo discutida há tempos na comunidade. Em 2024, as ameaças de computação quântica à criptografia de curvas elípticas reduziram o apetite por soluções Verkle, tornando a estrutura de árvore binária mais popular.

Segundo passo: migrar a EVM para a arquitetura RISC-V

A segunda proposta é mais abrangente e controversa: a substituição de longo prazo da EVM pelo conjunto de instruções RISC-V.

RISC-V é um conjunto de instruções open-source, eficiente energeticamente, originado de pesquisa acadêmica e que agora é padrão em todos os sistemas de provas de conhecimento zero. A lógica de Vitalik é elegante: se os geradores de provas ZK falam a linguagem RISC-V, por que a máquina virtual do blockchain deveria falar outra linguagem e precisar de uma camada de tradução? Eliminando essa camada redundante, a eficiência aumenta imediatamente.

A implementação técnica não é tão complexa quanto se pensa. Um interpretador RISC-V pode ser escrito em algumas centenas de linhas de código. Para Vitalik, essa é a filosofia de design correta para o blockchain: simplicidade focada em desempenho.

O plano de transição tem três fases:

1. Usar a máquina virtual RISC-V para executar contratos pré-compilados. Os 80% de contratos pré-compilados existentes podem ser reescritos em código RISC-V.

2. Permitir que desenvolvedores implantem contratos diretamente na nova VM. O novo sistema e a EVM rodarão simultaneamente, permitindo uma migração gradual.

3. Eventualmente, remover a EVM—mas ela não desaparece completamente. Ela será convertida em um contrato inteligente que roda na VM RISC-V, garantindo compatibilidade total. A imagem de Vitalik é poética: o volante permanece o mesmo, mas o motor debaixo dele foi silenciosamente substituído.

O gargalo de produção: sem mudança na EVM, não há escalabilidade

O argumento central baseia-se em um número: 80%. Essa é a porcentagem do gargalo de provas do Ethereum que vem diretamente da arquitetura da árvore de estado e da máquina virtual. Na prática, isso significa que todas as outras otimizações terão efeito limitado se esses dois aspectos não forem resolvidos.

Na era da escalabilidade com ZK, essa limitação arquitetural será um calcanhar de Aquiles. O Ethereum vê-se como precisando evoluir além de melhorias pontuais.

A contraproposta: o desafio da Arbitrum à estratégia RISC-V

Porém, a história não é de consenso simples. Em novembro do ano passado, a equipe Offchain Labs—principal desenvolvedora do Arbitrum—publicou uma refutação técnica detalhada.

A principal observação deles é sutil e importante: sim, o RISC-V é perfeito para provas ZK, mas não deve ser o “formato de execução” para contratos inteligentes. Eles fizeram uma distinção crítica: “conjunto de instruções de entrega” (dISA) e “conjunto de instruções de prova” (pISA) não precisam ser iguais.

A analogia prática é: um armazém pode ser mais eficiente usando um empilhador, mas isso não significa que o entregador de pacotes deva usar o mesmo empilhador para entregar na sua porta. Cada ferramenta tem seu contexto adequado.

Para a camada de execução de contratos, Offchain Labs defende o uso do WebAssembly (WASM) como solução melhor. Sua justificativa técnica é sólida:

• O WASM tem alta eficiência comprovada em hardware padrão. A maioria dos nós Ethereum não roda chips especializados RISC-V, e emular isso traria overhead grande.

• O WASM possui um mecanismo de verificação tipada maduro, comprovado em milhões de ambientes de execução ao redor do mundo.

• O ecossistema de ferramentas do WASM já está estabelecido, com amplo suporte de desenvolvedores.

Mais importante, eles não apenas teorizam. Offchain Labs já criou um protótipo no Arbitrum: usa WASM como formato de entrega de contratos, que depois é compilado para RISC-V para provas ZK. Cada camada realiza tarefas específicas sem conflito.

Eles também destacam um risco crítico: a tecnologia ZK está evoluindo rapidamente. A implementação de RISC-V passou de 32 bits para 64 bits recentemente. Se travar agora o RISC-V na camada L1 do Ethereum, o que acontecerá se uma arquitetura de prova superior surgir em dois anos? Apostar em uma tecnologia em movimento não é o estilo do Ethereum.

Uma mudança industrial maior: Ethereum e Layer 2 se afastam

Para entender melhor esse debate técnico, é preciso olhar para as dinâmicas industriais mais amplas.

Poucos meses atrás, Vitalik expressou ceticismo sobre a necessidade de uma “folha de rota dedicada de L2 para Ethereum”. Isso gerou uma resposta reflexiva profunda dos operadores de Layer 2.

Ben Fisch, CEO da Espresso Systems, explicou à mídia: o propósito original do Layer 2 era ajudar o Ethereum a escalar. Mas agora que o próprio Ethereum busca melhorias de escalabilidade, a posição do Layer 2 deve evoluir. Não mais uma camada auxiliar, mas um ecossistema mais independente.

Os operadores de Layer 2 não entraram em pânico. Pelo contrário, estão se reposicionando ativamente. O cofundador da OP Labs descreveu os Layer 2s como “sites independentes”, enquanto o Ethereum seria o padrão de liquidação periódica. O CEO da Polygon foi mais direto: o verdadeiro desafio não é só escalar, mas criar espaço de bloco especializado para casos de uso reais—como infraestrutura de pagamentos.

Em outras palavras, essa grande mudança técnica na camada de execução do Ethereum reflete uma tendência estrutural maior: o Ethereum volta a controlar suas competências centrais, enquanto os Layer 2s são empurrados ou descobrem sua própria razão de existir.

Será essa a realidade? Caminho a seguir e desafios

Vitalik mesmo admite que ainda não há consenso amplo na comunidade de desenvolvedores sobre a substituição da EVM. A reforma da árvore de estado tem uma base mais sólida—a EIP-7864 tem um rascunho concreto e equipes de desenvolvimento ativas.

Mas a substituição da EVM por RISC-V? Ainda está na fase de “roteiro”, longe de implementação de código real.

Porém, Vitalik deu uma declaração de confiança na semana passada: o Ethereum já realizou uma mudança de motor durante o “Merge”. Ainda pode fazer mais quatro grandes mudanças—otimizações na árvore de estado, consenso simplificado, verificação ZK-EVM e substituição da VM.

O cronograma começa a se desenhar. O Ethereum mira a atualização Glamsterdam na primeira metade de 2026, seguida de Hegota. Os detalhes técnicos ainda estão sendo finalizados, mas as reformas na árvore de estado e melhorias na camada de execução já são a direção principal.

A questão não é “é possível ou não”. O Ethereum já provou várias vezes sua capacidade—desde PoW até PoS, de uma abordagem total na camada L1 até um ecossistema centrado em Rollups. O desafio é que a arquitetura não é cosmética. É uma reconstrução da fundação enquanto o sistema ainda está em operação—não apenas uma adição de recursos, mas uma substituição fundamental da arquitetura antiga.

O próprio debate técnico—sobre se as mudanças são boas ou levam a uma complexidade infinita—pode ser mais valioso do que a resolução final. O Ethereum decidiu conscientemente não ser um “sistema legado patchado” na era ZK. Como quebrar as peças do motor e qual novo modelo será padrão só se verá em 2027.