Quando o Ethereum Abandona o EVM por RISC-V: A Revisão da Arquitetura que Pode Redefinir o Computação em Blockchain

A Ethereum encontra-se num ponto de inflexão. Enquanto a Ethereum Virtual Machine (EVM) impulsionou uma década de inovação blockchain—criando a base para DeFi e NFTs—torna-se cada vez mais claro que esta camada de execução construída sob medida não foi concebida para o futuro computacional que agora chega. A mudança para a verificação de conhecimento zero (ZK) e o surgimento de uma estrutura de máquina geral nos padrões de programação de sistemas estão a forçar uma reflexão: A arquitetura envelhecida da Ethereum consegue adaptar-se ou necessita de uma reimaginação completa?

Segundo investigadores técnicos e lideranças da Fundação Ethereum, a resposta está a tornar-se inequívoca. O protocolo está a traçar um caminho para substituir a EVM por RISC-V, uma arquitetura de conjunto de instruções de código aberto que promete desbloquear escalabilidade, reduzir a complexidade e alinhar a Ethereum com o ecossistema mais amplo de computação verificável.

A Crise de Desempenho de que Ninguém Fala: Porque a EVM Não Consegue Acompanhar a ZK

O gargalo não é imediatamente óbvio, mas é fundamental. Quando a Ethereum começa a provar as suas transições de estado através de provas de conhecimento zero—um caminho essencial para escalar a camada L1—a implementação atual do zkEVM cria uma penalização de desempenho esmagadora.

Aqui está a realidade técnica: A zkEVM de hoje não prova diretamente a execução do EVM. Em vez disso, prova um interpretador que foi compilado para código RISC-V. Esta camada adicional de abstração é a culpada. O custo de desempenho? Estimativas variam entre 50 a 800 vezes mais lento do que a execução nativa. Mesmo após otimizar outros componentes—como a troca para algoritmos de hashing mais eficientes—a execução de blocos continua a ser o principal obstáculo, representando 80-90% de todo o tempo de geração de provas.

Como Vitalik Buterin resumiu de forma sucinta: Se a zkVM acaba por compilar tudo para RISC-V de qualquer forma, por que forçar os desenvolvedores de contratos inteligentes a trabalhar através de um intermediário EVM que não acrescenta nada além de overhead?

Isto não é teórico. A diferença de desempenho traduz-se diretamente em economia. Eliminar esta camada interpretativa poderia melhorar a eficiência de execução em cerca de 100 vezes—uma diferença que separa uma escalabilidade viável de uma congestão contínua.

Dívida Técnica Enterrada no Protocolo

As escolhas de design do EVM fizeram sentido em 2015, mas cristalizaram-se em limitações. Considere três problemas específicos:

Contratos pré-compilados como uma solução temporária que falhou. Quando o EVM não conseguiu lidar de forma eficiente com certas operações criptográficas, a Ethereum adicionou funções codificadas—contratos pré-compilados. Pareceu uma solução pragmática temporariamente. Hoje, criou o que Vitalik chama uma situação “má”: estes módulos aumentaram o código de confiança da Ethereum a níveis insustentáveis e introduziram riscos de segurança repetidos que se aproximaram perigosamente de causar falhas de consenso.

Adicionar novos pré-compilados requer forks difíceis e envolve código de wrapper mais complexo do que implementações inteiras de RISC-V. Conclusão de Vitalik: o protocolo deve deixar de adicionar pré-compilados completamente.

Arquitetura de 256 bits para o caso de uso errado. A pilha de 256 bits do EVM foi concebida para valores criptográficos, mas a maioria dos contratos inteligentes opera com inteiros de 32 ou 64 bits. Este desajuste cria uma equação cruel de eficiência: números menores não economizam recursos, enquanto duplicam ou quadruplicam a complexidade. Em sistemas de provas ZK, esta ineficiência é ainda mais acentuada.

Pilha vs. registos. A arquitetura baseada em pilha do EVM requer mais instruções do que o modelo de registos do RISC-V para realizar operações idênticas, complicando a otimização do compilador e aumentando a carga de geração de provas.

Estas escolhas de design acumuladas não são bugs—são restrições arquiteturais que fizeram sentido numa fase, mas tornaram-se incompatíveis com o futuro da Ethereum.

RISC-V: Porque um Padrão Aberto Supera o Design Personalizado

RISC-V não é uma tecnologia proprietária. É um padrão de conjunto de instruções de código aberto—uma espécie de projeto livre para o design de processadores. A sua adoção para este papel não é arbitrária nem experimental.

Porque a simplicidade é força. O conjunto de instruções fundamental do RISC-V contém aproximadamente 47 instruções. Este minimalismo radical é intencional. Menos instruções significam uma base de código de confiança menor—mais fácil de auditar, verificar formalmente e garantir a segurança. Como Jeremy Bruestle destacou em conferências do setor, este design é “quase perfeito para a máquina geral super-minimal que precisamos.”

Maturidade do ecossistema através do LLVM. Ao escolher um padrão estabelecido, a Ethereum ganha acesso a décadas de infraestrutura de compiladores. Com suporte LLVM, os desenvolvedores podem usar qualquer linguagem de programação mainstream—Rust, C++, Go, Python—e compilar diretamente para RISC-V. Isto elimina a necessidade de reconstruir um ecossistema de desenvolvimento do zero. Justin Drake articulou a vantagem estratégica: “Obtemos suporte a todas as linguagens de alto nível suportadas pelo LLVM de forma gratuita.”

A convergência do zkVM já está a acontecer. O mercado já votou. Entre as dez implementações de zkVM mais avançadas capazes de provar blocos Ethereum, nove escolheram RISC-V. Isto não é especulação—é validação prática. O ecossistema de conhecimento zero já padronizou o RISC-V como alvo de execução, tornando a adoção da Ethereum não um jogo de azar, mas um alinhamento com o rumo da indústria.

Verificação formal torna-se possível. Ao contrário da especificação do Yellow Paper do EVM—escrita em linguagem natural e sujeita a ambiguidades—o RISC-V tem uma especificação oficial SAIL que é legível por máquina. Este rigor matemático permite verificar circuitos zkVM diretamente contra a especificação, criando um caminho para a correção comprovável que o EVM nunca poderia oferecer.

Limites de segurança de hardware integrados. O RISC-V inclui uma arquitetura privilegiada com modo de utilizador e modo de supervisor. Os contratos inteligentes correm em modo de utilizador e não podem aceder diretamente ao estado da blockchain; em vez disso, enviam pedidos ECALL a um núcleo confiável. Isto cria uma fronteira de segurança reforçada pela própria arquitetura do processador—muito mais robusta do que o isolamento por software. Como explicou Diego da Cartesi, “Todos estes mecanismos de proteção fazem parte do padrão RISC-V.”

A Transição em Três Fases: Mitigação de Risco Através de Gradualismo

A Ethereum não planeia uma mudança repentina. A migração segue um roteiro deliberadamente conservador:

Fase 1: RISC-V como substituto de pré-compilados. Inicialmente, o protocolo deixa de adicionar novos pré-compilados EVM. Em vez disso, novas funcionalidades criptográficas são implementadas através de programas RISC-V na lista de permissões. Isto permite testar a nova arquitetura na mainnet num ambiente controlado e de baixo risco antes de uma adoção mais ampla.

Fase 2: Coexistência de duas máquinas virtuais. Os contratos inteligentes passam a poder declarar se o seu bytecode é dirigido ao EVM ou ao RISC-V. Crucialmente, contratos em ambos os ambientes podem chamar-se entre si através de chamadas de sistema ECALL padronizadas. Isto cria um período híbrido onde ambas as arquiteturas operam juntas, validando a interoperabilidade antes da migração total.

Fase 3: EVM como contrato simulado. O objetivo final trata o EVM como uma linguagem de alto nível—um contrato inteligente formalmente verificado a correr nativamente no RISC-V L1. As aplicações legadas permanecem suportadas permanentemente, mas a camada de execução principal do protocolo torna-se totalmente RISC-V, simplificando drasticamente o desenvolvimento e manutenção do cliente.

Esta abordagem faseada transforma uma migração potencialmente catastrófica numa evolução gerível.

O Realinhamento do Ecossistema: Vencedores e Perdedores

A mudança não afeta todos os Layer 2 de forma igual—cria vencedores e perdedores.

Rollups Otimistas enfrentam desafios arquiteturais. Projetos como Arbitrum e Optimism dependem de provas de fraude: contestar uma transação requer re-executá-la na L1. Se a VM da L1 passar de EVM para RISC-V, este modelo de segurança colapsa. Estes projetos enfrentam uma escolha: realizar esforços de engenharia massivos para redesenhar provas de fraude para a nova arquitetura, ou desvincular-se completamente do modelo de segurança da Ethereum. Ambas as opções são caras.

ZK Rollups ganham uma vantagem estratégica enorme. Projetos como Polygon, zkSync e Scroll já padronizaram internamente o RISC-V. Uma L1 que “fala a sua língua” elimina camadas de tradução. O que a Fundação Ethereum chama “Rollups nativos” torna-se possível: a L2 passa a ser uma instância especializada do ambiente de execução da L1, partilhando ferramentas, compiladores e infraestrutura de verificação formal. O resultado prático: as equipas de L2 deixam de construir pontes entre VMs incompatíveis, os custos de desenvolvimento caem drasticamente, e a economia de gás torna-se mais racional.

A experiência do desenvolvedor transforma-se. Em vez de aprender exclusivamente Solidity, os desenvolvedores escrevem em Rust, Go ou qualquer linguagem suportada pelo LLVM. Os contratos podem usar bibliotecas maduras do ecossistema de software mais amplo. Vitalik compara isto ao Node.js: código on-chain e off-chain unificado na mesma linguagem, com as mesmas ferramentas. Esta redução de barreiras provavelmente irá remodelar quem pode participar no desenvolvimento de blockchain.

A economia do utilizador melhora drasticamente. Os custos de prova caem aproximadamente 100 vezes. As taxas de transação para liquidação na L1 e L2 diminuem proporcionalmente. Isto desbloqueia o “Gigagas L1”—cerca de 10.000 transações por segundo—permitindo aplicações complexas que requerem tanto throughput como segurança.

Succinct Labs e SP1: A Prova de que a Visão Funciona Hoje

A transição não é apenas teórica. A Succinct Labs já demonstrou as vantagens práticas do RISC-V através do SP1, uma zkVM de código aberto que prova que a tese arquitetural funciona.

A inovação do SP1: adota um design “centrado em pré-compilados” que resolve o gargalo criptográfico do EVM sem criar o problema de complexidade. Operações intensivas como hashing Keccak correm em circuitos ZK especializados, chamados através de instruções padrão ECALL. Isto combina desempenho de hardware personalizado com flexibilidade de software.

O impacto prático é imediato. O produto OP Succinct da Succinct oferece capacidades de conhecimento zero aos Rollups Otimistas. O resultado: em vez de esperar sete dias por confirmação final e retirada, as transações finalizam em aproximadamente uma hora. Para todo o ecossistema OP Stack, esta melhoria de velocidade resolve um ponto de dor crítico.

A Succinct também opera uma Rede de Provedores descentralizada, criando um mercado para geração de provas. Isto não é um protótipo—é um projeto de modelo económico que irá governar a computação verificável em escala.

Os Riscos Ocultos: O Que Ainda Pode Dar Errado

Apesar das vantagens do RISC-V, a transformação introduz riscos novos:

Complexidade na medição de gás. Atribuir um custo de gás justo e determinista a instruções de uso geral é um problema não resolvido. Contar instruções simples é vulnerável a ataques de negação de serviço. Um atacante poderia criar programas que disparam repetidamente misses de cache, consumindo recursos massivos com custos mínimos de gás. Isto ameaça a estabilidade da rede e os modelos económicos.

Segurança da cadeia de ferramentas e builds reproduzíveis. Este é o risco mais perigoso e subestimado. A segurança passa de confiar em VMs on-chain para confiar em compiladores off-chain como LLVM—software complexo conhecido por conter vulnerabilidades. Um atacante que explore bugs no compilador poderia transformar código fonte aparentemente seguro em bytecode malicioso. Igualmente desafiante: garantir que os binários compilados correspondam ao código fonte público (o problema de builds reproduzíveis) em diferentes ambientes de build. Variações menores no ambiente produzem outputs diferentes, criando problemas de confiança e transparência.

Estes riscos são resolvíveis, mas não triviais.

Mitigação: Defesa em Profundidade

Implementação faseada como estratégia principal. Ao introduzir o RISC-V de forma gradual—primeiro através de pré-compilados, depois de duas VMs, e finalmente como substituição total—o protocolo constrói experiência operacional e confiança antes de um compromisso irreversível. Esta abordagem escalonada é a ferramenta fundamental de gestão de risco.

Testes agressivos e verificação formal. Embora a verificação formal seja o objetivo a longo prazo, deve ser combinada com testes contínuos de alta intensidade. Empresas de segurança como a Diligence já descobriram 11 vulnerabilidades críticas de solidez e integridade em zkVMs líderes através de fuzz testing. Este padrão—vulnerabilidades escondidas em sistemas bem desenhados—exige estratégias paralelas de testes e verificação, não sequenciais.

Padronização para evitar fragmentação. A comunidade deve adotar uma configuração padrão única do RISC-V, provavelmente RV64GC com ABI compatível com Linux. Isto maximiza o suporte ao ecossistema de ferramentas e evita a fragmentação, permitindo que os desenvolvedores beneficiem plenamente das vantagens do ecossistema LLVM.

A Camada Verificável da Internet: O Jogo Longo da Ethereum

A transição do EVM para RISC-V não é principalmente sobre ganhos incrementais de desempenho. Trata-se de reposicionar a Ethereum de uma “máquina virtual de contratos inteligentes” para se tornar a fundação de confiança verificável para a computação de internet de uso geral.

A visão de Vitalik captura o objetivo final: “O objetivo final inclui… tornar tudo ZK-snarkificado.”

Esta transformação aborda o pilar do “Execução Enxuta” da Ethereum—parte da visão mais ampla de “Ethereum Enxuto”. O protocolo simplifica-se de uma VM monolítica para uma camada minimalista de liquidação e disponibilidade de dados, otimizada para computação verificável. A aceleração de provas de hardware (ASICs e FPGAs de SP1, Nervos, Cartesi) torna-se viável assim que o conjunto de instruções estabilizar em torno do RISC-V.

A transição é inevitável não porque seja ótima isoladamente, mas porque alinha com o rumo do próprio cálculo. As provas ZK representam o terceiro primitivo criptográfico após hashes e assinaturas. A aposta da Ethereum é que quem fornecer a camada de confiança fundamental para a computação verificável—integração nativa de uma estrutura de máquina geral na programação de sistemas—controla a próxima era da internet.

Apesar de obstáculos técnicos e sociais consideráveis, esta reestruturação da camada de execução da Ethereum representa uma das decisões arquiteturais mais relevantes na história do blockchain. Troca os efeitos de rede da familiaridade com o EVM pela posição estratégica de liderar a revolução da computação verificável.

A transformação começa agora. Projetos como Ethproofs agregam os dados colaborativos necessários para executar esta mudança. Equipas como Succinct Labs fornecem os planos práticos. Dentro de 6-12 meses, espera-se as primeiras alternativas de pré-compilados a rodar código RISC-V na mainnet da Ethereum—marcando o início do fim para a Ethereum Virtual Machine como a conhecemos.