A Aposta Final: Será que o Ethereum Sobrevive a Abandonar o EVM pelo RISC-V?

Quando Vitalik Buterin afirma que “o objetivo final inclui tornar tudo ZK-Snarkificado”, ele não fala de forma casual. A Ethereum está numa encruzilhada, e a decisão que se avizinha determinará se ela se torna a espinha dorsal de uma internet nativa ZK ou se desaparece gradualmente na irrelevância. A questão já não é teórica—é operacional: a Ethereum deve substituir a sua Máquina Virtual Ethereum (EVM) fundamental por RISC-V?

Porque a EVM Está a Tornar-se o Calcanhar de Aquiles da Ethereum

Durante mais de uma década, a EVM tem sido o motor revolucionário que impulsiona DeFi e NFTs. Mas revolucionário não significa ótimo. À medida que as provas de conhecimento zero passam de uma elegância teórica para uma necessidade prática, as limitações da EVM passaram de um incómodo para uma crise.

O problema central é brutal: as implementações atuais de zkEVM não provam diretamente a EVM—provam o interpretador que executa a EVM, que por sua vez compila para RISC-V. Isto acrescenta uma penalização catastrófica de desempenho. A avaliação direta de Vitalik: “Por que não expor diretamente o RISC-V subjacente?” Remover esta camada intermédia poderia melhorar a eficiência de execução em até 100 vezes. Sem ela, a execução de blocos consome sozinho 80-90% de todo o tempo de prova, mesmo após outras otimizações.

A inchação vai além do desempenho. Para compensar as ineficiências criptográficas da EVM, a Ethereum acumulou contratos pré-compilados—funções codificadas embutidas no próprio protocolo. Vitalik descreve isto como “catastrófico”: “Eles inflaram enormemente a base de código confiável da Ethereum… levando a problemas graves que quase resultaram em falhas de consenso.” O código de wrapper para um único pré-compilado (como modexp) é mais complexo do que um interpretador RISC-V inteiro.

A arquitetura de 256 bits agrava ainda mais a situação. Este design fazia sentido para operações criptográficas em 2015, mas os contratos inteligentes atuais normalmente usam inteiros de 32 ou 64 bits. Para estes, a pilha de 256 bits desperdiça recursos enquanto aumenta a complexidade em duas a quatro vezes nos sistemas ZK.

RISC-V: A Resposta Minimalista que Ninguém Esperava

RISC-V não é invenção da Ethereum—é um padrão aberto que o mundo da computação adotou. Isto importa muito mais do que a maioria percebe.

O conjunto de instruções contém aproximadamente 47 operações principais. O minimalismo não é uma limitação; é o objetivo principal. Uma base de código confiável menor é mais fácil de auditar, verificar formalmente e provar matematicamente como correta. Isto é crítico para assegurar um protocolo de mais de 100 mil milhões de dólares.

A vantagem do ecossistema é impressionante. Ao adotar RISC-V, a Ethereum herda décadas de avanços em ciência da computação. A infraestrutura do compilador LLVM significa que os desenvolvedores podem usar Rust, C++, Go, Python, e praticamente qualquer linguagem mainstream—automaticamente. Não é preciso reconstruir o universo de software do zero.

Dados da Ethproofs revelam consenso de mercado: Entre dez zkVMs capazes de provar blocos Ethereum, nove escolheram RISC-V. Isto não é ideológico—é uma convergência prática. Projetos como a Succinct Labs já validaram a arquitetura através do SP1, um zkVM de alto desempenho que demonstra a superioridade do RISC-V na geração de provas.

A especificação formal é a cereja no topo. RISC-V usa SAIL—uma especificação legível por máquina—em comparação com o Yellow Paper da Ethereum, que permanece ambígua em alguns pontos. Como observou Alex Hicks, da Ethereum Foundation, SAIL permite verificação direta: “os circuitos zkVM podem ser verificados contra a especificação oficial do RISC-V.” Isto transforma a segurança de uma dependência de implementação para algo matematicamente verificável.

O Plano de Êxodo em Três Fases

A Ethereum não vai simplesmente mudar de um dia para o outro. A estratégia de migração reflete lições duramente aprendidas sobre a gestão de mais de 100 mil milhões de dólares em valor bloqueado.

Fase Um: RISC-V como Substituto de Pré-compile Em vez de adicionar novos pré-compilados EVM (um processo lento e contencioso que requer forks duros), o protocolo introduz programas RISC-V na lista branca. Isto serve dois propósitos: testar o novo sistema na mainnet sob condições de baixo risco, enquanto substitui a armadilha do pré-compilado por algo nativo à camada de execução.

Fase Dois: Era de Coexistência Contratos inteligentes podem ser marcados como bytecode EVM ou RISC-V. A grande inovação: interoperabilidade perfeita através de chamadas de sistema (ECALL). Os contratos podem chamar-se entre si em diferentes ambientes de execução. Isto dá tempo ao ecossistema para migrar, garantindo compatibilidade retroativa.

Fase Três: EVM como Contrato Simulado A etapa final trata a EVM como um contrato inteligente formalmente verificado a correr em RISC-V nativo. Aplicações legadas funcionam indefinidamente, os desenvolvedores mantêm um único motor de execução, e a complexidade do protocolo diminui drasticamente.

A Mudança Tectónica nas Layer-2s

Esta transformação vai dividir o panorama Layer-2 de formas previsíveis.

Rollups Otimistas como Arbitrum e Optimism enfrentam um problema existencial. O seu modelo de segurança depende da reexecução na L1 de transações contestadas via EVM. Se a L1 deixar de executar EVM, o mecanismo de prova de fraude colapsa. Estes projetos enfrentam escolhas binárias: realizar reconstruções massivas de engenharia ou desvincular-se do modelo de segurança da Ethereum. Nenhuma das opções é atraente.

ZK Rollups efetivamente ganham na lotaria arquitetónica. Já padronizaram internamente o RISC-V. Uma L1 “que fala a mesma língua” desbloqueia o que Justin Drake chama de “Rollups nativos”—a L2 torna-se uma instância especializada do ambiente de execução da L1 com VM integrada para liquidação.

Os benefícios em cascata são imensos:

• Simplificação da pilha: Acabaram-se as ligações complexas entre RISC-V interno e EVM externo
• Reutilização de ferramentas: Compiladores, depuradores, ferramentas de verificação formal desenvolvidas para L1 transferem-se diretamente para L2
• Alinhamento económico: O preço do gás reflete os custos reais de verificação RISC-V, criando incentivos racionais em toda a pilha

Para utilizadores e desenvolvedores, o objetivo final é revolucionário: custos caem ~100x (de vários dólares para cêntimos por transação), possibilitando a visão “Gigagas L1” de ~10.000 TPS. Os desenvolvedores escrevem contratos em Rust ou Go usando toolchains LLVM padrão—Vitalik chama-lhe uma experiência “NodeJS” para blockchain, onde o código on-chain e off-chain vivem no mesmo ecossistema de linguagens.

O Campo Minado: Riscos de Que Ninguém Está a Discutir Bastante

Os desafios técnicos estão subestimados na maior parte da cobertura.

A medição do gás ainda não está resolvida. Como precificar de forma justa uma ISA de uso geral? Contar instruções simples é vulnerável a ataques DoS—atacantes podem criar programas que provocam misses na cache, consumindo recursos a custo mínimo de gás. Isto não é teórico; ameaça a estabilidade da rede e os modelos económicos.

A segurança do compilador é a bomba escondida. O modelo de confiança da Ethereum passa de VMs na cadeia para compiladores off-chain (LLVM), que são complexos e contêm vulnerabilidades conhecidas. Um atacante que explore uma falha no compilador poderia transformar código fonte inocente em bytecode malicioso. O problema do “build reproducível” agrava-se: garantir que os binários compilados correspondam exatamente ao código fonte público é tecnicamente difícil. Pequenas diferenças no ambiente de build produzem outputs diferentes, quebrando a transparência.

Defesa em Profundidade

As estratégias de mitigação devem ser em camadas:

Implementação gradual é inegociável. Uma migração em três fases constrói experiência operacional antes de um compromisso irreversível. A fase de pré-compilados de baixo risco permite à comunidade aprender com a exposição ao RISC-V em condições de produção.

Fuzz testing combinado com verificação formal funciona. A ferramenta Argus da Diligence Security encontrou 11 vulnerabilidades críticas em zkVMs líderes—prova de que mesmo sistemas bem desenhados escondem falhas. Testes adversariais rigorosos apanham o que a verificação formal não consegue detectar.

Padronização evita fragmentação. Uma única configuração RISC-V (provavelmente RV64GC com ABI compatível com Linux) maximiza o suporte às toolchains e simplifica a experiência do desenvolvedor. Isto não é burocracia; é disciplina arquitetónica.

Horizonte Verificável da Ethereum

A transição da EVM para RISC-V representa a decisão arquitetónica mais importante da Ethereum desde o lançamento da mainnet. Não é uma atualização incremental—é uma reestruturação fundamental.

As trocas são explícitas:

• Ganhos de desempenho com arquitetura ZK-nativa versus requisitos de compatibilidade retroativa
• Melhorias de segurança com simplificação do protocolo versus efeitos de rede da EVM
• Poder de um ecossistema de uso geral versus riscos de toolchains de terceiros complexos

Equipes como a Succinct Labs não estão a teorizar—estão a entregar. O seu produto OP Succinct já prova que o conceito funciona: Rollups Otimistas ganham capacidades ZK, reduzindo o tempo de finalização de 7 dias para 1 hora. Isto não é tecnologia do futuro; está a funcionar hoje.

Os dados da Ethproofs, a implementação open-source do SP1, e a convergência da indústria em torno do RISC-V sugerem que isto não é especulação. A Ethereum está a reformar-se numa camada de confiança verificável para a internet, com SNARK como a primitive criptográfica após hashes e assinaturas—o terceiro pilar do computing sem confiança.

Quer por migração faseada ou por um cronograma acelerado, esta reestruturação vai definir a próxima década da Ethereum. A EVM construiu o Web3; o RISC-V construirá a infraestrutura de provas que o sustenta.