Como a Próxima Grande Mudança do Ethereum Pode Remodelar Toda a Indústria de Blockchain

A Ethereum está a atravessar um ponto de inflexão tecnológica crítico. Após anos a depender da Máquina Virtual Ethereum (EVM) como sua espinha dorsal computacional, a rede enfrenta uma pressão crescente para transitar para um modelo de execução fundamentalmente diferente — um construído sobre a arquitetura RISC-V, especificamente otimizado para sistemas de provas de conhecimento zero.

Isto não é uma atualização menor de protocolo. É uma reestruturação completa de como a Ethereum processa transações e valida alterações de estado. E o timing é importante: à medida que as soluções Layer 2 se multiplicam e a tecnologia de conhecimento zero amadurece, a arquitetura atual da EVM começa a revelar suas limitações de formas que não eram óbvias há apenas dois anos.

Por que a EVM está a tornar-se um entrave

A EVM foi revolucionária quando foi lançada. Permitiu todo o ecossistema de contratos inteligentes. Mas um design com uma década de idade acumula dívida técnica, e o surgimento de sistemas de provas de conhecimento zero expôs ineficiências arquitetónicas que agora se tornam impossíveis de ignorar.

O problema central é simples: provar a execução da EVM através de circuitos ZK introduz uma sobrecarga enorme. As implementações atuais de zkEVM não provam diretamente a própria EVM. Em vez disso, provam um interpretador da EVM, que por sua vez compila para código RISC-V. Como Vitalik Buterin apontou, isto cria uma camada de abstração desnecessária que pode reduzir o desempenho entre 50 a 800 vezes em comparação com provas nativas de RISC-V.

Mesmo após otimizar outros componentes — trocando por funções de hash mais rápidas como Poseidon — a execução de blocos ainda representa entre 80-90% do tempo total de geração de provas. A sobrecarga do interpretador tornou-se o principal gargalo que impede a Ethereum de escalar através da verificação ZK na camada 1.

A armadilha da complexidade: dívida técnica acumulada

Para além do desempenho, a Ethereum acumulou outro problema: contratos pré-compilados. São funções codificadas que foram adicionadas para compensar ineficiências da EVM em operações criptográficas específicas. Cada adição resolveu temporariamente uma necessidade imediata, mas gradualmente inflacionou a base de código confiável da Ethereum com soluções especializadas e pontuais.

O código wrapper de um único contrato pré-compilado como o modexp é supostamente mais complexo do que toda a implementação do interpretador RISC-V. Adicionar novas funções pré-compiladas requer um processo de hard fork controverso, criando atritos políticos e atrasando a inovação de aplicações que necessitam de novos primitivas criptográficas.

O próprio design arquitetónico da EVM também apresenta vulnerabilidades. A sua arquitetura de pilha de 256 bits fazia sentido para valores criptográficos, mas é altamente ineficiente para inteiros de 32 ou 64 bits usados na maioria dos contratos inteligentes. Em sistemas de conhecimento zero, essas ineficiências são particularmente dispendiosas — números menores consomem os mesmos recursos, mas aumentam a complexidade de duas a quatro vezes.

Porque o RISC-V surge como a solução

O RISC-V não é uma invenção proprietária feita especificamente para a Ethereum. É um padrão de conjunto de instruções de código aberto que já se tornou a arquitetura de facto para máquinas virtuais de conhecimento zero. Entre as dez zkVMs capazes de provar blocos Ethereum, nove já padronizaram o RISC-V.

Este consenso de mercado indica algo importante: adotar o RISC-V não é um jogo de azar especulativo. É alinhar-se com uma infraestrutura que todo o ecossistema de conhecimento zero já validou através de implementações reais.

O apelo é multifacetado:

Design minimalista: O conjunto de instruções fundamental do RISC-V contém apenas cerca de 47 instruções principais, em comparação com a complexidade implícita da EVM. Uma base de código confiável menor é muito mais fácil de auditar, testar e verificar formalmente — algo crítico para proteger bilhões em valor na cadeia.

Ecossistema maduro: Ao adotar o RISC-V, a Ethereum ganha acesso imediato à infraestrutura do compilador LLVM. Isto significa que milhões de desenvolvedores já familiarizados com Rust, C++, Go e Python podem escrever diretamente para a camada 1, sem aprender uma nova linguagem ou ambiente. A experiência de desenvolvimento seria semelhante à de desenvolvimento cross-platform ao estilo NodeJS.

Vantagens na verificação formal: Ao contrário da especificação do Yellow Paper da EVM (escrita em linguagem natural com ambiguidades inerentes), o RISC-V possui uma especificação legível por máquina, a SAIL. Este “padrão ouro” permite provas matemáticas rigorosas de correção — o santo graal da segurança blockchain que transfere a confiança da implementação humana para uma prova verificável.

Caminho de otimização de hardware: A arquitetura suporta aceleração de hardware através de ASICs e FPGAs, permitindo infraestruturas especializadas de geração de provas (semelhantes ao trabalho em curso na Succinct Labs, Nervos e Cartesi).

O roteiro de migração em três fases

A transição da Ethereum não será revolucionária, mas evolutiva. Vitalik Buterin delineou uma abordagem cuidadosa e faseada:

Fase 1 - Implementação limitada: O RISC-V entra como uma alternativa pré-compilada, substituindo novas adições de contratos pré-compilados. Este ambiente de testes de baixo risco permite que a rede ganhe confiança no novo sistema, mantendo total compatibilidade com a EVM. Apenas programas específicos e pré-aprovados em RISC-V são executados através de caminhos de execução whitelist.

Fase 2 - Coexistência: Contratos inteligentes podem declarar seu bytecode como EVM ou RISC-V. Os dois sistemas coexistem e interagem perfeitamente através de chamadas de sistema (ECALL), permitindo que contratos de arquiteturas diferentes chamem uns aos outros. Este ambiente híbrido permite aos desenvolvedores migrar gradualmente, sem decisões imediatas obrigatórias.

Fase 3 - Camada nativa: A EVM torna-se um contrato simulado a correr sobre RISC-V (a estratégia “Rosetta”). Aplicações legadas continuam a correr inalteradas, mas o motor de execução subjacente simplifica-se para um único núcleo RISC-V, reduzindo drasticamente a complexidade e o esforço de manutenção para os desenvolvedores de clientes.

Quem ganha e quem enfrenta dificuldades nesta nova era

Esta mudança arquitetónica terá consequências muito diferentes para várias soluções Layer 2.

Rollups de conhecimento zero ganham vantagem estrutural. Projetos como Polygon, zkSync e Scroll já padronizaram internamente o RISC-V. Uma camada 1 que “fala a mesma língua” permite uma integração nativa com mínima complexidade de ponte. Reuso de ferramentas, compatibilidade de compiladores e alinhamento de incentivos económicos passam a trabalhar a seu favor. A co-fundadora da Succinct Labs, Uma Roy, demonstrou esta vantagem com OP Succinct, que adiciona capacidades de prova de conhecimento zero aos Rollups Otimistas — reduzindo o tempo de retirada de sete dias para aproximadamente uma hora.

Rollups Otimistas enfrentam escolhas mais difíceis. Arbitrum e Optimism dependem de provas de fraude executadas através da EVM da camada 1 para resolver disputas. Se a EVM desaparecer, todo este modelo de segurança precisará de ser reconstruído. Estas equipas terão de criar novos sistemas de provas de fraude direcionados à nova arquitetura de camada 1 ou desvincular-se fundamentalmente das garantias de segurança da Ethereum — nenhuma das opções é trivial.

Impacto económico: custos mais baixos, maior throughput

Para os utilizadores finais, a transição traduz-se em benefícios tangíveis.

Espera-se que os custos de geração de provas diminuam aproximadamente 100 vezes — de vários dólares por transação para cêntimos ou menos. Isto reduz diretamente as taxas na camada 1 e, mais importante, os custos de liquidação na camada 2. Os ganhos de eficiência possibilitam a visão de uma “Gigagas L1”: cerca de 10.000 TPS de throughput a custos razoáveis, desbloqueando aplicações atualmente demasiado caras para correr na cadeia.

Os desenvolvedores ganham acesso a uma cadeia de ferramentas significativamente mais ampla. Construir código na cadeia e fora dela na mesma linguagem torna-se prática padrão, em vez de uma exceção. Este “modelo NodeJS” para desenvolvimento blockchain atrai novos criadores e acelera a inovação de aplicações.

Os riscos críticos que ninguém deve ignorar

Esta transformação traz novos desafios que exigem atenção séria.

A medição de gás torna-se matematicamente mais difícil. Criar um modelo de gás justo e determinístico para conjuntos de instruções de uso geral ainda não foi resolvido. Contar instruções simples convida a ataques de negação de serviço — atacantes podem criar programas que desencadeiam falhas de cache repetidas, consumindo recursos massivos com gás mínimo. Isto ameaça a estabilidade da rede e a integridade económica.

A segurança da cadeia de ferramentas está agora no centro do risco. A responsabilidade de segurança passa das máquinas virtuais na cadeia para os compiladores off-chain, como o LLVM. Estes são sistemas de software extraordinariamente complexos, com vulnerabilidades conhecidas. Atacantes podem explorar bugs no compilador para transformar código fonte benigno em bytecode malicioso, indetectável através de auditorias padrão.

Construções reproduzíveis continuam por resolver. Garantir que os binários compilados correspondam exatamente ao código fonte público é tecnicamente desafiante. Pequenas variações ambientais produzem resultados diferentes, minando a transparência e a confiança — exatamente o que a blockchain deve resolver.

Estes riscos exigem uma defesa em múltiplas camadas: uma implementação faseada que minimize danos irreversíveis, testes contínuos de fuzz para descobrir vulnerabilidades (a firma de segurança Argus relatou ter encontrado 11 falhas críticas de solidez em zkVMs líderes), e verificação formal que eventualmente reforça garantias teóricas.

O caminho prático: o roteiro da Succinct Labs

Esta transformação não é apenas teórica. Equipas já estão a construir a infraestrutura. O SP1 da Succinct Labs é uma zkVM de produção, de código aberto, que demonstra que a geração de provas baseada em RISC-V funciona em escala. O SP1 adota uma filosofia “centrada em pré-compilados” — descarregando operações intensivas como hashing Keccak para circuitos ZK especializados, otimizados manualmente, chamados através de instruções padrão — combinando desempenho de hardware personalizado com flexibilidade de software.

O trabalho deles prova o conceito enquanto estabelece viabilidade económica através da Rede de Provedores Succinct, um mercado descentralizado para geração de provas que mostra como será a infraestrutura futura.

A visão maior: Ethereum como uma camada de computação verificável

Esta transição reformula o papel fundamental da Ethereum. Em vez de permanecer principalmente uma plataforma de execução de contratos inteligentes, a Ethereum torna-se na camada de confiança para computação verificável geral — o que Vitalik chama o “Snarkify everything” como objetivo final.

Isto alinha-se com a filosofia mais ampla do “Ethereum Lean”: simplificar sistematicamente o protocolo em três módulos limpos (Lean Consensus, Lean Data, Lean Execution). Ao remover a EVM e adotar o RISC-V, a Ethereum reforça o seu propósito central: liquidação eficiente e disponibilidade de dados para um universo de aplicações verificáveis.

A mudança reconhece uma verdade fundamental: num futuro dominado por provas de conhecimento zero, as primitivas computacionais importam. A Ethereum pode resistir à evolução tecnológica inevitável ou abraçá-la estrategicamente. O roteiro discutido nos conferências EthProofs e fóruns de pesquisa sugere que a Fundação Ethereum e a equipa principal escolheram o segundo caminho.

Não é uma mudança de um dia para o outro. É uma transformação de vários anos que requer coordenação, implementação faseada e uma verdadeira adesão da comunidade. Mas o caso técnico está a tornar-se cada vez mais difícil de contestar, e os incentivos competitivos de soluções Layer 2 já otimizadas para RISC-V criam uma pressão crescente para alinhar a arquitetura da camada 1 com o futuro que o ecossistema já está a construir.

A questão já não é se isto acontecerá, mas como a Ethereum gerirá cuidadosamente e deliberadamente a transição — e se a comunidade conseguirá executar esta reestruturação ambiciosa mantendo a confiança e estabilidade de que dependem bilhões em valor.