A Camada de Execução do Ethereum num Ponto de Inflexão: Por que a Arquitetura RISC-V Está a Tornar-se Inevitável

O Ethereum encontra-se numa encruzilhada crítica. A arquitetura fundamental que impulsionou a revolução DeFi e possibilitou o ecossistema NFT enfrenta restrições crescentes de desempenho que a otimização tradicional já não consegue resolver. A resposta emergente da comunidade não é um remendo—é uma reestruturação fundamental: a transição da Máquina Virtual Ethereum (EVM) para RISC-V como ambiente de execução principal.

Isto não é especulação. Nove em cada dez implementações de zkVM atualmente direcionadas a blocos Ethereum já padronizaram o RISC-V. Este consenso de mercado indica o que os desenvolvedores de protocolos concluíram silenciosamente: o design da EVM, embora inovador há uma década, acumulou dívida técnica incompatível com sistemas de provas de conhecimento zero que representam o futuro computacional do Ethereum.

A Crise de Desempenho em Sistemas de Conhecimento Zero

O problema raiz é elegante na sua simplicidade: o Ethereum não prova diretamente a EVM. Em vez disso, projetos constroem interpretadores que traduzem o bytecode EVM em instruções compatíveis com provas—que, em última análise, são compiladas para RISC-V de qualquer forma. Esta camada arquitetural acrescenta uma sobrecarga devastadora.

Implementações atuais de zkEVM sofrem uma degradação de desempenho de 50 a 800 vezes em comparação com a execução de instruções nativas. Mesmo após otimizações agressivas de operações criptográficas (como a troca para hashing Poseidon), a execução de blocos continua a ser o gargalo, consumindo 80–90% do tempo total de geração de provas. Eliminando completamente a camada de interpretador, os investigadores de protocolo estimam que a eficiência de execução poderia melhorar em um fator de 100—transformando a geração de provas de economicamente inviável para prática.

As ineficiências vão além da sobrecarga do interpretador. A arquitetura de pilha de 256 bits da EVM foi desenhada para operações criptográficas, mas desperdiça recursos em lógica de contratos inteligentes típica envolvendo inteiros de 32 ou 64 bits. Em sistemas de provas de conhecimento zero, cada operação requer gerar evidência criptográfica de correção; esse desperdício multiplica-se exponencialmente. A arquitetura baseada em registos do RISC-V, por outro lado, alinha-se com princípios modernos de design de CPU e permite otimizações de compilador que o modelo de pilha impede fundamentalmente.

Dívida Técnica: A Armadilha do Pré-compilado

Para compensar as limitações computacionais da EVM, o Ethereum introduziu contratos pré-compilados—funções codificadas embutidas diretamente no protocolo para operações caras, como criptografia de curvas elípticas ou exponenciação modular. Esta solução pragmática de curto prazo transformou-se numa dor de cabeça de manutenção.

Cada nova adição de pré-compilado requer um hard fork controverso. A “base de código confiável” do protocolo—código que os validadores devem executar e verificar—cresceu para proporções perigosas. A lógica de wrapper para um único pré-compilado (como o modexp) ultrapassa a complexidade de um interpretador completo de RISC-V. Esta acumulação levou a Ethereum a incidentes de falha de consenso várias vezes, evitados por pouco através de coordenação de emergência.

Os desenvolvedores de protocolo chegaram a um consenso: sem novos pré-compilados. O caminho arquitetural passa por mover-se para um sistema onde inovações criptográficas possam ser implantadas através de código programável e verificável, em vez de alterações ao nível do protocolo.

Por que RISC-V, Não Outra Alternativa

RISC-V não é uma invenção nativa de criptomoedas. É um padrão de conjunto de instruções de código aberto que foi testado ao longo de décadas de pesquisa em ciência da computação. Essa maturidade oferece três vantagens decisivas:

Fundação Minimalista: O conjunto de instruções base contém aproximadamente 47 instruções. Esta simplicidade radical cria uma superfície suficientemente pequena para ser verificada formalmente usando sistemas de provas matemáticas—um luxo que a especificação extensa da EVM nunca permite. A especificação RISC-V SAIL existe em formato legível por máquina, ao contrário de linguagem natural ambígua, permitindo que circuitos zkVM verifiquem diretamente contra padrões oficiais.

Herança do Ecossistema: Ao adotar RISC-V, o Ethereum ganha acesso à cadeia de ferramentas do compilador LLVM—representando décadas de esforço coletivo de engenharia. Desenvolvedores que usam Rust, Go, C++ ou Python podem compilar diretamente para RISC-V através de ferramentas maduras e de produção. Isso elimina a necessidade de construir um ecossistema de software paralelo do zero, uma carga que atrasaria a adoção por anos.

Padrão ZK de Facto: O mercado já decidiu. Nove dos principais projetos de zkVM (incluindo implementações da Succinct Labs, Nervos, Cartesi, entre outros) convergiram para RISC-V de forma independente. Isto não é consenso—é uma inevitabilidade tecnológica. A adoção do RISC-V pelo Ethereum alinha o protocolo com infraestruturas que já começaram a ser construídas.

A Estratégia de Transição em Três Fases

Em vez de uma substituição revolucionária, o Ethereum executará uma migração cuidadosamente sequenciada, projetada para manter compatibilidade retroativa e estabilidade operacional:

Fase 1: Substituição do Pré-compilado

Novas capacidades criptográficas anteriormente requerendo pré-compilados ao nível do protocolo podem ser implementadas como programas RISC-V na lista de permissões. Isto introduz o ambiente de execução na mainnet sob condições de baixo risco, fornecendo dados de testes reais antes de uma implantação mais ampla. A transição é gerida inteiramente ao nível do cliente, sem mudanças na camada de consenso.

Fase 2: Coexistência de Duas Máquinas Virtuais

Contratos inteligentes declaram explicitamente se seu bytecode destina-se à execução em EVM ou RISC-V através de um sistema de tags. Os dois ambientes alcançam interoperabilidade perfeita via chamadas de sistema (ECALL), permitindo invocação de funções entre camadas de execução. Este período permite à ecossistema migrar gradualmente sem decisões imediatas forçadas.

Fase 3: EVM como Contrato Implementado

A etapa final trata a EVM legada como especificações formais que rodam dentro do ambiente RISC-V—semelhante a como o Linux pode rodar em RISC-V apesar de originalmente ter como alvo o x86. O protocolo mantém suporte permanente às aplicações existentes, enquanto os desenvolvedores de clientes mantêm um motor de execução único e simplificado. A dívida técnica transforma-se em código implementável, ao invés de bagagem ao nível do protocolo.

Reorganização do Ecossistema: A Divergência das Rollups

A mudança para execução nativa em RISC-V cria resultados radicalmente diferentes para arquiteturas de Layer 2 concorrentes:

Rollups Otimistas Sob Pressão

Rollups Otimistas (Arbitrum, Optimism) garantem sua segurança reexecutando transações contestadas via L1, usando a EVM como ambiente de resolução de disputas. Se o modelo de execução do L1 mudar fundamentalmente, esse mecanismo de segurança colapsa. Estes projetos enfrentam uma reconstrução de engenharia—ou construindo sistemas de prova de fraude compatíveis com execução RISC-V, ou desacoplando garantias de segurança do consenso do Ethereum completamente.

Vantagem Estratégica dos Rollups de Conhecimento Zero

ZK Rollups já operam nativamente em arquiteturas RISC-V. Um L1 que “fala a mesma língua” possibilita o que Justin Drake chama de “Rollups nativos”—instâncias de L2 que funcionam como configurações especializadas do ambiente de execução do L1. As implicações práticas são substanciais:

• Velocidade de Desenvolvimento: Equipes de L2 eliminam códigos complexos de ponte entre execução RISC-V interna e camadas de liquidação externas. Ferramentas de compilação, depuradores e utilitários de verificação desenvolvidos para L1 tornam-se diretamente aplicáveis ao L2 sem modificação.
• Alinhamento Econômico: O custo de gás no L1 reflete diretamente os custos computacionais da verificação ZK baseada em RISC-V, ao invés da operação EVM. Isto cria incentivos mais precisos e elimina distorções econômicas entre camadas.
• Economia das Provas: Gerar a evidência criptográfica que garante a liquidação do L2 torna-se drasticamente mais barato. Os custos de liquidação no L1 caem de vários dólares por transação para centavos, possibilitando novos modelos econômicos para aplicações de alta frequência.

Experiência do Desenvolvedor: Do Sandbox ao Ecossistema

A transformação democratiza o desenvolvimento on-chain. Atualmente, Solidity e Vyper representam as únicas linguagens práticas de contratos inteligentes—ferramentas específicas de domínio que os desenvolvedores precisam aprender para trabalhar com blockchain. Com RISC-V, os desenvolvedores escrevem em Rust, Go ou Python usando as mesmas bibliotecas, frameworks e ferramentas de depuração utilizados no desenvolvimento de software tradicional.

Vitalik Buterin descreveu isso como alcançar uma experiência “ao estilo Node.js”—onde desenvolvedores escrevem lógica on-chain e off-chain na mesma linguagem, usando as mesmas cadeias de ferramentas. A fricção psicológica e prática de “desenvolvimento blockchain” como domínio especializado praticamente desaparece. Novos desenvolvedores podem aplicar conhecimentos existentes diretamente, sem necessidade de requalificação.

Para desenvolvedores Solidity existentes, o cronograma de transição se estende por anos. As abstrações elegantes de contratos inteligentes da linguagem permanecerão populares. Mas a opção de construir máquinas de estado complexas e lógica computacional em linguagens de sistemas convencionais transforma o que é viável construir on-chain—especialmente para aplicações que requerem computação intensiva ou estruturas de dados sofisticadas.

O Ponto de Prova da Succinct Labs

A teoria transforma-se em realidade através do SP1, um zkVM de alto desempenho desenvolvido pela Succinct Labs, operando nativamente em RISC-V. O SP1 valida toda a tese técnica por meio de implementação de produção, não apenas artigo acadêmico. Demonstra que a execução em RISC-V gera provas a custos economicamente viáveis, mantendo a compatibilidade com o modelo de segurança do Ethereum.

Mais importante, o produto OP Succinct da Succinct mostra o benefício prático imediato: Rollups Otimistas usando o OP Stack podem implantar verificação de provas de conhecimento zero, reduzindo o tempo de retirada de sete dias para uma hora. Este avanço resolve simultaneamente dois pontos problemáticos do ecossistema—a lentidão na finalização de confirmações de sistemas otimistas e a complexidade de integração da verificação zk.

A Prover Network da Succinct opera como um mercado descentralizado para geração de provas, estabelecendo o modelo econômico para computação verificável em escala. O modelo funciona: validadores competem para gerar provas, usuários recebem serviço de qualidade, e o mercado descobre preços eficientes. Isto não é conceitual—é infraestrutura operacional processando transações reais hoje.

Segurança Através da Simplicidade e Formalização

Uma das vantagens subestimadas do RISC-V é a simplicidade arquitetural que permite verificação formal—provar matematicamente a correção do sistema, ao invés de confiar que as implementações estão livres de bugs. As especificações do Yellow Paper da EVM existem em linguagem natural, criando ambiguidades irreduzíveis. A especificação RISC-V SAIL é legível por máquina, fornecendo o que os pesquisadores de segurança chamam de uma “referência dourada” para comportamento correto.

Pesquisadores da Ethereum Foundation já extraem circuitos zkVM para verificação formal contra as especificações oficiais do RISC-V usando provadores de teoremas Lean. Isto representa uma melhoria de segurança geracional: transferir a confiança de implementações humanas falíveis para provas matematicamente verificáveis.

A arquitetura privilegiada do RISC-V (distingue a execução de aplicações em modo usuário da operação do kernel em modo supervisor) fornece camadas adicionais de segurança. Contratos inteligentes em modo usuário não podem acessar diretamente o estado da blockchain; eles fazem requisições a kernels confiáveis via instruções ECALL padronizadas. Isto reforça limites de segurança ao nível arquitetural, ao invés de depender de implementações de sandbox de software, que têm um histórico mais longo de vulnerabilidades.

Navegando Riscos Reais

O caminho de transição inclui desafios não resolvidos que requerem atenção séria:

Complexidade na Contabilização de Gás

Criar um modelo de gás justo e determinístico para conjuntos de instruções de uso geral permanece sem solução. Contar instruções simples permite ataques de negação de serviço onde programas cuidadosamente elaborados acionam cache misses caros enquanto consomem gás mínimo. Os atacantes exploram essa arbitragem para esgotar recursos da rede a custos desprezíveis. A comunidade ainda não possui mecanismos estabelecidos para medir e precificar o custo computacional real de instruções arbitrárias sem reintroduzir uma especificação centralizada.

Segurança na Cadeia de Suprimento do Compilador

O modelo de segurança muda de confiar em máquinas virtuais on-chain para confiar em cadeias de ferramentas off-chain como LLVM. Compiladores são extremamente complexos—implementações de milhares de linhas de código que realizam otimizações criam superfícies de ataque. Um adversário explorando vulnerabilidades do compilador poderia transformar código fonte inofensivo em bytecode malicioso, indetectável por análise estática.

O problema de “build reproducível” agrava esse risco: desenvolvedores não podem verificar se o código binário na blockchain corresponde ao código fonte público sem reproduzir exatamente o ambiente de build. Pequenas diferenças de versão, flags do compilador ou variáveis ambientais produzem bytecode diferente, tornando as garantias de transparência inúteis.

Estes problemas representam desafios de engenharia genuínos, sem soluções simples, especialmente à medida que a maturidade do ecossistema e os incentivos de ataque aumentam.

Estratégia de Defesa em Múltiplas Camadas

Mitigar riscos requer abordagens abrangentes e em camadas, ao invés de soluções únicas:

Implantação Gradual

A linha do tempo de transição em três fases é uma estratégia central de gestão de risco. As fases iniciais introduzem RISC-V sob condições onde falhas têm impacto limitado. O ecossistema constrói experiência operacional e confiança de forma incremental, evitando compromissos irreversíveis antes de acumular evidências suficientes.

Testes e Verificações Agressivas

A verificação formal oferece segurança assintótica, mas requer anos para implementação completa. Enquanto isso, testes adversariais usando ferramentas de fuzzing (como a plataforma Argus da Diligence) já descobriram 11 vulnerabilidades críticas de robustez em principais implementações de zkVM. Combinar fuzzing contínuo com verificação formal fornece uma defesa em profundidade contra vulnerabilidades de implementação.

Configuração Padronizada

Ao invés de fragmentar em múltiplas configurações RISC-V, a comunidade deve convergir para RV64GC com ABI compatível com Linux. Essa configuração maximiza compatibilidade com linguagens de programação mainstream e ecossistemas de ferramentas existentes, reduzindo a superfície de ataque criada por extensões personalizadas.

A Camada Verificável da Internet

A transição da EVM para RISC-V representa a evolução estrutural do Ethereum de uma máquina virtual de contratos inteligentes especializada para algo fundamentalmente diferente: uma infraestrutura mínima e verificável de confiança para a própria internet.

Essa transformação incorpora trade-offs técnicos específicos: equilibrar os ganhos de desempenho de 100x da execução nativa ZK contra obrigações de compatibilidade retroativa; ponderar benefícios de simplificação contra os efeitos de rede que defendem a EVM atual; escolher a generalidade do ecossistema enquanto gerencia dependências de ferramentas de terceiros.

Coletivamente, essa reestruturação constitui o componente de execução do “Ethereum Lean”—uma visão mais ampla de simplificação do protocolo que modulariza de forma independente os níveis de consenso, disponibilidade de dados e execução. Ao seguir esse caminho, o Ethereum posiciona-se não como uma plataforma monolítica de contratos inteligentes, mas como a camada de liquidação e confiança para um ecossistema interconectado de sistemas de computação verificável e especializado.

Como diz o ditado: provar o mundo do software, abrir uma nova era da criptografia. A infraestrutura existe. O caso técnico é esmagador. A única variável remanescente é a execução.