O Gambito RISC-V da Ethereum: Por Que Vitalik Quer Remover a EVM e o Que Isso Significa para Cada Desenvolvedor dApp

E se o motor que alimenta US$ 600 bilhões em contratos inteligentes estivesse atrasando o Ethereum em ordens de magnitude? Essa é a tese provocativa que Vitalik Buterin apresentou em abril de 2025 — e reforçou em março de 2026 — quando propôs substituir gradualmente a Ethereum Virtual Machine (EVM) pelo RISC-V, uma arquitetura de conjunto de instruções (ISA) de CPU de código aberto. A mudança poderia desbloquear ganhos de eficiência de 100x na geração de provas de conhecimento zero, mas também ameaça reformular a experiência do desenvolvedor, desencadear uma guerra de arquitetura com os defensores do WebAssembly e forçar todo o ecossistema Ethereum a repensar como deve ser uma máquina virtual de blockchain.

O Imposto Oculto da EVM

A EVM foi revolucionária em 2015. Uma máquina de pilha de 256 bits projetada para computação trustless, ela deu origem a um ecossistema de mais de 4.000 aplicações descentralizadas e tornou o termo "contrato inteligente" um nome familiar. Mas uma década de uso em produção expôs limitações estruturais que nenhuma quantidade de otimização incremental pode resolver.

O problema central é o overhead. A EVM opera como um intérprete de software em CPUs modernas de 64 bits, traduzindo cada opcode através de uma camada de abstração que nunca foi projetada para desempenho bruto. Para a execução de transações comuns, esse overhead é gerenciável. Para a geração de provas de conhecimento zero (ZK) — tecnologia da qual o roadmap do Ethereum depende cada vez mais — ele é devastador.

Os provadores ZK de hoje já trabalham traduzindo internamente o bytecode da EVM para RISC-V antes de gerar as provas. Essa tradução dupla introduz o que Buterin descreve como um "overhead de 800x" nos tempos de prova de zkVM. A árvore de estados e a VM juntas representam mais de 80 % do gargalo no provimento eficiente, o que significa que, não importa quão rápidos os provadores se tornem, a própria EVM continua sendo o teto.

Entre no RISC-V: A Oportunidade de 100x

O RISC-V é uma arquitetura de conjunto de instruções (ISA) de código aberto nascida de duas décadas de pesquisa de CPU na UC Berkeley. Ao contrário das arquiteturas proprietárias da ARM ou Intel, o RISC-V é modular, extensível e livre de royalties. Seu design baseado em registradores mapeia de forma limpa para o hardware moderno, e sua simplicidade — um intérprete RISC-V minimalista pode ser escrito em poucas centenas de linhas de código — o torna ideal para verificação formal.

O caso de desempenho é convincente. Ao executar contratos inteligentes nativamente em RISC-V em vez de interpretar bytecode da EVM, o Ethereum poderia:

• Eliminar a penalidade de tradução dupla: Os provadores ZK não precisariam mais converter EVM para RISC-V antes de gerar as provas, reduzindo potencialmente o overhead de prova em 50–100x.
• Simplificar o protocolo: Operações de sistema como SLOAD e CALL se tornariam syscalls em vez de opcodes personalizados, reduzindo a superfície de ataque e a carga de manutenção.
• Aproveitar o ferramental existente: O RISC-V já possui compiladores GCC e LLVM maduros, emuladores QEMU e toolchains formalmente verificadas — um ecossistema de suporte que a EVM nunca poderá igualar.
• Alinhar-se com o ecossistema ZK: As principais zkVMs, incluindo a SP1 da Succinct, RISC Zero, Jolt da a16z, OpenVM da Axiom e Miden da Polygon, são todas construídas sobre RISC-V, criando um ponto de convergência natural.

Os números de sistemas em produção confirmam isso. O SP1 Hypercube da Succinct pode gerar provas de conhecimento zero para blocos do Ethereum em menos de 12 segundos em 16 GPUs NVIDIA RTX 5090. O R0VM 2.0 da RISC Zero reduziu os tempos de prova de 35 minutos para 44 segundos. Esses ganhos foram alcançados ainda trabalhando através da camada de tradução da EVM — a execução nativa de RISC-V os ampliaria ainda mais.

O Plano de Migração em Três Fases

A proposta de Buterin não é uma reescrita imprudente. É uma migração cuidadosamente encenada, projetada para manter a compatibilidade reversa durante todo o processo:

Fase 1 — Substituição de Pré-compilados: O código RISC-V substitui cerca de 80 % dos contratos pré-compilados existentes do Ethereum. Estas são as operações criptográficas e aritméticas (como emparelhamentos de curvas elípticas e hashing SHA-256) que existem atualmente como funções nativas codificadas (hardcoded). Ao implementá-las em RISC-V, o protocolo torna-se mais auditável e extensível sem sacrificar o desempenho.

Fase 2 — Implantação de VM Dupla: Os desenvolvedores ganham a capacidade de implantar contratos inteligentes compilados para bytecode RISC-V ao lado dos contratos EVM existentes. Códigos Solidity e Vyper seriam compilados para RISC-V em vez de bytecode EVM — a experiência do desenvolvedor permanece familiar, mas a camada de execução muda por baixo.

Fase 3 — Aposentadoria da EVM: A própria EVM torna-se um contrato inteligente escrito em RISC-V. Cada contrato EVM existente continua a funcionar exatamente como antes, executado por este intérprete "EVM-em-RISC-V". A única mudança visível para o usuário seriam alterações nos custos de gás à medida que a nova arquitetura refaz os preços das operações.

Esta fase final é a parte mais elegante da proposta. Em vez de quebrar a compatibilidade reversa, ela a preserva inteiramente — a EVM não desaparece; ela se torna uma biblioteca rodando sobre uma fundação mais eficiente.

O Companheiro do EIP-7864: Árvores de Estado Binárias

Em março de 2026, Buterin expandiu a proposta com o EIP-7864, que aborda a outra metade do gargalo de prova: a árvore de estado do Ethereum. A atual Árvore Merkle Patricia Keccak hexária seria substituída por uma árvore binária usando uma função de hash mais eficiente — seja a Blake3 ou uma variante da Poseidon.

O impacto é substancial:

• Os ramos Merkle tornam-se quatro vezes mais curtos, reduzindo a largura de banda de dados para clientes leves como o Helios
• A substituição da função de hash proporciona uma melhoria adicional de 3 a 100 vezes na eficiência de prova
• Combinadas com a mudança na VM, as duas atualizações visam os mais de 80% dos custos de prova que atualmente restringem a escalabilidade do Ethereum

O sequenciamento de Buterin é deliberado: árvores binárias primeiro (potencialmente nas atualizações Glamsterdam ou Hegota em 2026), seguidas pela substituição da VM assim que a infraestrutura de prova amadurecer.

O Contra-argumento do WASM

Nem todos estão convencidos de que o RISC-V é a resposta certa. Em novembro de 2025, pesquisadores da Offchain Labs — a equipe por trás da Arbitrum — publicaram uma contestação técnica detalhada argumentando que o WebAssembly (WASM) é a melhor escolha a longo prazo.

O argumento central deles baseia-se em uma distinção importante: a "ISA de Entrega" (o formato no qual os contratos são armazenados e distribuídos) e a "ISA de Prova" (o formato usado para provas ZK) não precisam ser as mesmas. A Offchain Labs já está demonstrando isso na prática — os blocos da Arbitrum, incluindo os contratos inteligentes Stylus baseados em WASM, são provados por ZK através da compilação de WASM para RISC-V no momento da prova.

O campo do WASM levanta várias preocupações:

• Compatibilidade de hardware: A maioria dos nós do Ethereum carece de CPUs RISC-V e exigiria emulação, enquanto o WASM roda nativamente em bilhões de ambientes de execução.
• Lock-in do ecossistema: Consagrar o RISC-V na L1 poderia prender o Ethereum a uma tecnologia de prova específica justamente quando alternativas melhores estão surgindo.
• Maturidade das ferramentas: O ecossistema de ferramentas do WASM é testado em batalha em navegadores web, infraestrutura de nuvem e computação de borda.
• Alternativas emergentes: ZK-VMs baseadas em WASM, como a Ligetron da Ligero, já estão demonstrando vantagens que as ISAs focadas em hardware podem não igualar.

O debate está longe de terminar. Ambos os lados concordam que a EVM precisa evoluir; eles discordam se o formato de execução deve ser otimizado para prova (RISC-V) ou para flexibilidade de implantação (WASM).

A Aposta Paralela da Polkadot

O Ethereum não é a única blockchain a adotar o RISC-V. O protocolo JAM da Polkadot, progredindo em direção à sua especificação 1.0, usa a PolkaVM — um recompilador ahead-of-time baseado em RISC-V — como seu mecanismo de execução. A atualização da rede principal JAM está prevista para o primeiro trimestre de 2026, com a velocidade dos blocos aumentando 10 vezes para blocos de 500 milissegundos.

O projeto Revive da Polkadot combina o backend RISC-V da PolkaVM com um intérprete EVM totalmente compatível, permitindo que os desenvolvedores escolham entre a compatibilidade com o Ethereum e o desempenho máximo da Polkadot. Essa abordagem de modo duplo espelha o período de transição que Buterin vislumbra para a Fase 2 do Ethereum.

A convergência é notável: dois dos maiores ecossistemas de blockchain concluíram independentemente que o RISC-V oferece o melhor caminho para a execução de contratos inteligentes de alto desempenho.

O que Muda para os Desenvolvedores

Para o desenvolvedor comum de Solidity, o impacto imediato é surpreendentemente pequeno. No futuro RISC-V:

• Solidity e Vyper sobrevivem: Os desenvolvedores continuam escrevendo em linguagens familiares. O backend do compilador muda de bytecode EVM para bytecode RISC-V, mas o código-fonte e o fluxo de trabalho de desenvolvimento permanecem basicamente os mesmos.
• Novas opções de linguagem surgem: Rust — a linguagem já dominante no desenvolvimento de Solana, Polkadot e NEAR — torna-se um cidadão de primeira classe para contratos inteligentes do Ethereum. Isso pode atrair desenvolvedores de ecossistemas concorrentes.
• Os custos de gas mudam: As operações serão precificadas novamente para refletir os custos de execução do RISC-V em vez dos custos de opcode da EVM. Algumas operações tornam-se mais baratas; outras podem tornar-se mais caras.
• Testes e ferramentas se adaptam: Frameworks como Hardhat e Foundry precisariam de alvos de compilação RISC-V, embora a infraestrutura LLVM existente torne isso mais tratável do que construir ferramentas EVM do zero.

A mudança maior é filosófica. A camada de execução do Ethereum passa de uma máquina virtual personalizada e específica para blockchain para uma arquitetura de computação de propósito geral, apoiada por décadas de pesquisa acadêmica e ferramentas industriais. Isso não é apenas uma atualização de desempenho — é uma aposta de que as blockchains devem convergir com a computação convencional em vez de manter uma infraestrutura separada.

O Caminho pela Frente

A proposta RISC-V ainda não tem consenso dentro da comunidade de desenvolvimento do Ethereum. As atualizações Glamsterdam e Hegota esperadas para 2026 provavelmente priorizarão as mudanças na árvore de estado do EIP-7864, com a substituição da VM permanecendo como um objetivo de longo prazo.

Mas a direção da viagem é clara. O ecossistema de prova ZK já se padronizou no RISC-V. Os dados de desempenho são inequívocos. E o design de retrocompatibilidade significa que o Ethereum pode fazer essa transição sem quebrar um único contrato existente.

A verdadeira questão não é se o Ethereum acabará indo além da EVM, mas quão rápido a comunidade conseguirá se alinhar quanto à substituição — e se o RISC-V ou o WASM vencerá esse debate. Para os desenvolvedores que constroem no Ethereum hoje, a mensagem é tranquilizadora: seus contratos Solidity continuarão funcionando independentemente de tudo. Mas os construtores mais astutos já estão se preparando para um mundo onde o Ethereum fala RISC-V nativamente, e para a eficiência de prova de 100x que vem com ele.

BlockEden.xyz fornece infraestrutura de RPC e API de nível empresarial para Ethereum e as principais redes de Camada 2. À medida que a camada de execução evolui, nossa infraestrutura se adapta — garantindo que os desenvolvedores possam construir na vanguarda sem gerenciar a complexidade subjacente. Explore nossos serviços de API Ethereum para preparar a infraestrutura do seu dApp para o futuro.