O Terremoto Arquitetónico do Ethereum: Por que o EVM Deve Dar Lugar ao RISC-V

O protocolo Ethereum enfrenta a sua transformação mais radical desde a génese — não uma mera atualização, mas uma revisão arquitetónica fundamental. A Máquina Virtual Ethereum (EVM), que impulsionou toda a revolução DeFi e NFT, está a tornar-se no maior gargalo de desempenho da rede num futuro dominado por provas de conhecimento zero. A solução: substituí-la por RISC-V.

A Crise de Desempenho de que Ninguém Está a Falar

Aqui está a dura verdade: as implementações atuais de EVM de conhecimento zero são 50 a 800 vezes mais lentas do que a execução nativa. Porquê? Porque não provam diretamente a EVM — provam um interpretador da EVM, que por sua vez compila para bytecode RISC-V de qualquer forma.

Como Vitalik Buterin próprio colocou a questão: Se estamos a compilar a execução da EVM para RISC-V por baixo, por que adicionar uma camada de abstração desnecessária entre os desenvolvedores e a camada de execução real? Remover essa sobrecarga do interpretador por si só poderia desbloquear ganhos de eficiência de 100 vezes na verificação de Camada 1.

As decisões de design atuais estão a criar problemas em cascata:

Contratos pré-compilados: Ethereum acrescentou funções criptográficas codificadas (modexp, ecrecover, etc.) como soluções temporárias para limitações de desempenho da EVM. Isto fez a base de código confiável crescer de forma catastrófica — o código de wrapper para um único pré-compilado é agora mais complexo do que todo o interpretador RISC-V. Adicionar novos requer hard forks controversos, sufocando a inovação.

Desalinhamento arquitetónico: O design de pilha de 256 bits da EVM fazia sentido para primitivas criptográficas em 2015. Hoje, é uma responsabilidade — a maioria das operações de contratos inteligentes usa inteiros de 32 ou 64 bits, mas a EVM ainda consome os mesmos recursos para valores menores, acrescentando 2-4x de complexidade desnecessária para provas de conhecimento zero.

Porque é que o RISC-V Vence: A Vantagem do Padrão Aberto

O RISC-V não é uma máquina virtual proprietária — é um padrão aberto de arquitetura de conjunto de instruções, disponível gratuitamente para qualquer um. Isto cria três vantagens decisivas:

Simplicidade radical: Apenas 47 instruções principais. Compara isso com os milhares do x86. Este minimalismo é intencional — significa menos superfícies de ataque, verificação formal mais fácil e limites menores de código confiável.

Ecossistema de software maduro: Ao adotar RISC-V, o Ethereum beneficia de décadas de infraestrutura de compiladores de graça. A cadeia de ferramentas LLVM já suporta Rust, Go, C++, Python, e dezenas de linguagens. Os desenvolvedores não precisarão aprender uma sintaxe nova — podem escrever contratos inteligentes na linguagem que já conhecem, e depois compilar diretamente para a camada de execução de Camada 1. Vitalik chama a isto a experiência “NodeJS” — escrever código do lado do cliente e do lado do servidor na mesma linguagem.

Convergência de mercado: 9 em cada 10 projetos zkVM já escolheram RISC-V como seu conjunto de instruções nativo. Isto não é teórico — é o padrão de facto do ecossistema de computação de conhecimento zero. A adoção de Camada 1 alinharia o núcleo do Ethereum com a infraestrutura que todo o seu ecossistema de Camada 2 está a construir.

O Plano de Migração: Três Etapas, Zero Revolução

Isto não é um Big Bang. Vitalik delineou uma abordagem deliberadamente cautelosa:

Fase 1: Substituição de Pré-Compilados
Funções RISC-V aparecem dentro da EVM através de programas na lista de permissões. Sem alterações no formato de bytecode. Os desenvolvedores não percebem. A rede ganha experiência operacional com a nova VM na mainnet sob condições controladas — o ambiente de teste de menor risco possível.

Fase 2: Era de Duas Máquinas Virtuais
Contratos EVM e RISC-V coexistirão. Os contratos inteligentes podem marcar o seu formato de bytecode. Inovação crítica: podem chamar-se mutuamente via chamadas de sistema (ECALL). Isto significa que pode ter um pool central do Uniswap V3 em RISC-V a chamar um oráculo legado baseado em EVM — interoperabilidade transparente.

Fase 3: EVM como Simulação (A Estratégia “Rosetta”)
A EVM clássica torna-se num contrato inteligente formalmente verificado a correr sobre RISC-V. É a simplificação máxima — em vez de manter dois motores de execução, os desenvolvedores principais mantêm uma única Camada 1 simplificada, com suporte legado construído como software de camada de aplicação. Esta fase pode levar anos, mas é inevitável.

Quem Ganha, Quem Perde: A Reorganização das Rollups

Esta mudança será sísmica para a infraestrutura de Camada 2:

Rollups Otimistas enfrentam uma ameaça existencial: Projetos como Arbitrum e Optimism dependem de mecanismos de prova de fraude que reexecutam transações contestadas através da EVM de Camada 1. Quando a EVM desaparecer de Camada 1, todo o seu modelo de segurança colapsa. Enfrentam duas escolhas brutais: (1) reconstruir sistemas de prova de fraude para RISC-V do zero, ou (2) abandonar completamente o modelo de segurança do Ethereum.

ZK Rollups terão uma oportunidade de ouro: Polygon, zkSync, Scroll, e outros construíram as suas L2s em torno de zkVMs RISC-V. Uma L1 que “fala a sua língua” permite rollups nativos — sem necessidade de camada de tradução. As equipas de L2 podem reutilizar compiladores, depuradores e ferramentas de verificação de L1. Isto transforma a economia de L2:

• Sem lógica de ponte personalizada entre RISC-V de L2 e VM de L1
• Os cálculos de gás tornam-se precisos — as taxas de L1 refletem com exatidão os custos reais de verificação RISC-V
• A liquidação torna-se atómica, não heurística

O resultado? A visão de Justin Drake de “rollups como instâncias especializadas de L1” — integração mais estreita, menor latência, capital mais eficiente.

Para Desenvolvedores e Utilizadores: O Verdadeiro Impacto

Experiência do desenvolvedor: Os desenvolvedores deixam de estar presos a Solidity/Vyper/Yul. Escrevem em Rust, Go, ou Python — usam as suas bibliotecas favoritas do npm ou crates.io — e executa-se diretamente na L1. A compilação é transparente. Vitalik prevê que Solidity sobreviverá de qualquer forma devido aos efeitos de rede do ecossistema, mas a válvula de escape é libertada.

Economia do utilizador: Os custos de prova caem ~100x (de dólares por transação para cêntimos). Isto não é teórico — os resultados do zkVM SP1 da Succinct Labs já demonstram isto. Combinado com confirmações mais rápidas na L2 (Rollups Otimistas atualmente obrigam janelas de retirada de 7 dias; OP Succinct reduz para 1 hora), a experiência do utilizador torna-se qualitativamente diferente.

O objetivo final é “Gigagas L1” — aproximadamente 10.000 transações por segundo na Camada 1, com finalização atómica. Isso desbloqueia aplicações on-chain atualmente impossíveis devido ao custo e à latência.

Os Riscos que Devem Ser Geridos

Caos na medição de gás: Contar instruções de forma justa numa ISA de uso geral é um problema não resolvido. Um atacante poderia criar código que desencadeia repetidamente misses de cache — alto custo de CPU, gás mínimo cobrado. Isto poderia permitir novos vetores de negação de serviço.

Explosão de confiança no compilador: O modelo de segurança muda de “provar execução na cadeia” para “confiar no compilador LLVM”. O LLVM é um código complexo com milhares de linhas e um histórico de vulnerabilidades. Se um atacante explorar um bug no compilador, pode esconder comportamentos maliciosos em código fonte aparentemente inofensivo. Pior ainda, o problema de “build reproducível” torna difícil provar que o binário na cadeia corresponde ao código fonte público — um pesadelo para a transparência.

Fragmentação do ecossistema: Se diferentes projetos adotarem configurações distintas de RISC-V (RV32I vs. RV64GC), diferentes padrões ABI(, o ecossistema fragmenta-se. A vantagem da cadeia de ferramentas desaparece.

A pilha de mitigação:

• Implementação faseada )pré-Fase 1( prova o modelo em cenários de baixo risco
• Testes adversariais contínuos )fuzz testing já encontrou 11 bugs críticos de solidez em zkVMs líderes(
• Verificação formal )especificação SAIL permite provas de correção matemática, ao contrário da ambiguidade do Yellow Paper(
• Uma configuração única e padronizada )provavelmente RV64GC + ABI Linux( para evitar fragmentação

O Futuro Verificável do Ethereum

Isto não é apenas sobre velocidade. A visão mais ampla é o Ethereum evoluir de uma “máquina de contratos inteligentes” para uma camada minimalista de liquidação e confiança para a internet. O roteiro “Ethereum Magro” )Lean Consensus + Lean Data + Lean Execution( foi desenhado especificamente para eliminar complexidade — e a Execução Magra é a mais profunda.

O zkVM SP1 da Succinct Labs prova que isto funciona na prática. O seu produto OP Succinct adapta provas zk a Rollups Otimistas, reduzindo o tempo de retirada 7x. A sua Rede de Provedores Succinct esboça o mercado de geração de provas. Não são artigos de investigação — são sistemas de produção.

O momento histórico está a cristalizar-se: as ferramentas de verificação formal estão a amadurecer )Prover de Teoremas Magro(, a aceleração de provas de hardware está a ser lançada )ASICs SP1 em teste, e 90% do ecossistema zkVM já escolheu RISC-V. A visão de Vitalik de “snarkificar tudo” já não é especulativa — é infraestrutura à espera de a Camada 1 acompanhar.

O Ethereum enfrenta uma escolha: evoluir arquitetonicamente agora, ou assistir ao seu teto de desempenho calcificar-se à medida que a computação de conhecimento zero se torna o padrão. Os dados sugerem que a rede escolherá a evolução — em fases cuidadosamente medidas, mas inevitáveis.

A base criptográfica da internet não está escrita em Solidity. Está escrita em RISC-V.