O Ethereum está passando pela mudança arquitetônica mais importante desde a sua criação: a substituição da Máquina Virtual Ethereum (EVM) pelo RISC-V. A razão fundamental para essa mudança é que, na era das provas de conhecimento zero (ZK), a EVM se tornou o maior gargalo:
A zkEVM atual depende da execução do interpretador, resultando em uma redução de velocidade de 50 a 800 vezes;
Os contratos pré-compilados (Precompiles) tornam o protocolo excessivamente complexo e aumentam o risco;
O design de pilha de 256 bits é extremamente ineficiente na prova.
O RISC-V pode resolver esses problemas:
Minimalismo (cerca de 47 comandos básicos) + ecossistema LLVM maduro (suporte a Rust, C++, Go);
Já se tornou o padrão de fato para zkVM (90% dos projetos adotam);
A norma SAIL formalizada (em relação ao ambíguo livro amarelo) pode suportar uma verificação rigorosa;
O caminho de prova de hardware (ASIC/FPGA) está em teste (SP1, Nervos, Cartesi).
A migração é dividida em três fases:
RISC-V como alternativa a contratos pré-compilados (teste de baixo risco);
Era das Duas Máquinas Virtuais: EVM + RISC-V possuem total interoperabilidade;
EVM implementado internamente no RISC-V (semelhante à estratégia Rosetta).
Impacto do ecossistema:
As Rollups otimistas não são afetados; a mainnet RISC-V não eliminará as provas de fraude, os programas de prova existentes podem ser compilados para RISC-V (atualmente baseados em MIPS); caminho de migração: expandir a infraestrutura de tolerância a falhas atual para o RISC-V alvo, em vez de uma reestruturação completa;
ZK Rollup irá beneficiar-se enormemente (Polygon, zkSync, Scroll → mais barato, mais rápido, mais simples);
Os desenvolvedores podem usar diretamente bibliotecas Rust/Go/Python no L1;
Os usuários podem obter um custo de prova cerca de 100 vezes mais barato, avançando assim para o nível Gigagas (cerca de 10k TPS) na camada L1.
No final, o Ethereum irá evoluir de uma "máquina virtual de contratos inteligentes" para um nível de confiança na internet minimamente verificável, cujo objetivo final é: "tudo será ZK-Snark".
O Ethereum está em uma encruzilhada
Com o objetivo final de "tudo ser ZK-Snarkificado" como visão, o Ethereum está atualmente na iminência da mais importante evolução arquitetônica desde sua criação. Esta discussão não se limita mais a upgrades incrementais, mas envolve uma reestruturação fundamental de seu núcleo computacional — ou seja, a substituição da Máquina Virtual Ethereum (EVM). Esta iniciativa é a pedra angular de uma visão mais ampla chamada "Ethereum Lean" (Ethereum Enxuto), que pretende simplificar sistematicamente todo o protocolo, dividindo-o em três componentes principais: Consenso Enxuto (Lean Consensus), Dados Enxutos (Lean Data) e Execução Enxuta (Lean Execution). E a questão central da Execução Enxuta é: a EVM, como motor da revolução dos contratos inteligentes, tornou-se agora o principal gargalo para o desenvolvimento futuro do Ethereum?
Como disse Justin Drake da Fundação Ethereum, o objetivo de longo prazo do Ethereum sempre foi "snarkizar tudo", uma ferramenta poderosa que pode fortalecer as várias camadas do protocolo. Mas, por muito tempo, esse objetivo parecia mais uma "castelo no ar", pois sua realização exigia provas em tempo real desse conceito. E agora, à medida que a prova em tempo real se torna uma realidade, a ineficiência teórica do EVM se transformou em um problema prático que precisa ser resolvido.
Esta análise irá explorar os argumentos técnicos e estratégicos para a migração do L1 do Ethereum para a arquitetura de conjunto de instruções RISC-V (ISA), uma medida que promete liberar uma escalabilidade sem precedentes, simplificar a estrutura do protocolo e alinhar o Ethereum com o futuro da computação verificável.
O que exatamente mudou?
Antes de aprofundar a discussão sobre o "porquê", é primeiro necessário entender o "o que" está a mudar.
EVM é o ambiente de execução de contratos inteligentes do Ethereum, sendo o "computador mundial" que processa transações e atualiza o estado da blockchain. Ao longo dos anos, seu design foi revolucionário, criando uma plataforma sem permissões e dando origem a todo o ecossistema DeFi e NFT. No entanto, essa arquitetura personalizada, que remonta a quase uma década, acumulou uma pesada dívida técnica.
Em comparação, o RISC-V não é um produto, mas sim um padrão aberto — um "alfabeto" de design de processador gratuito e genérico. Como Jeremy Bruestle enfatizou na conferência telefônica da Ethproofs, seus princípios fundamentais fazem dele a escolha ideal para esse papel:
Minimalismo: o conjunto de instruções básico é extremamente simples, contendo apenas cerca de 40-47 instruções. Jeremy descreve-o como "quase o caso perfeito de uma máquina universal super simplificada que precisamos."
Modular: Adicionando funcionalidades mais complexas através de extensões opcionais. Isso é crucial, pois permite um núcleo simples que pode ser expandido conforme necessário, sem impor complexidade desnecessária ao protocolo base;
Ecossistema aberto: ele possui um vasto e maduro suporte de ferramentas, incluindo o compilador LLVM, permitindo que os desenvolvedores utilizem linguagens populares como Rust, C++ e Go. Como disse Justin Drake: "Existem muitas ferramentas relacionadas a compiladores, e a construção de compiladores é extremamente difícil... Portanto, ter essas ferramentas de compilador é de grande valor." RISC-V permite que o Ethereum herde gratuitamente essas ferramentas prontas.
Problema de custo do interpretador
A necessidade de substituir o EVM não decorre de uma única falha, mas de uma série de limitações fundamentais que, no contexto do futuro nativo da prova de conhecimento zero (ZK), tornaram-se impossíveis de ignorar. Esses problemas abrangem gargalos de desempenho severos nos sistemas de prova ZK, bem como os riscos associados à complexidade crescente acumulada dentro dos protocolos.
Problema de custo do interpretador
O principal motor de transformação mais urgente é a ineficiência inerente do EVM nos sistemas de prova de zero conhecimento. À medida que o Ethereum avança gradualmente para um modelo em que o estado L1 é validado por provas ZK, o desempenho do provador se tornará o gargalo final.
O problema reside na forma como o zkEVM atual funciona. Eles não realizam provas de conhecimento zero diretamente sobre o EVM, mas sim sobre um interpretador do EVM que, por sua vez, é compilado para RISC-V. Vitalik Buterin apontou de forma direta este problema central:
"Se a implementação do zkVM consiste em compilar a execução do EVM em conteúdo que eventualmente se torna código RISC-V, por que não abrir diretamente o RISC-V subjacente para os desenvolvedores de contratos inteligentes? Isso poderia eliminar completamente a sobrecarga de toda a máquina virtual externa."
Esta camada adicional de explicação trouxe uma enorme perda de desempenho. De acordo com estimativas, em comparação com a prova de programas nativos, esta camada pode resultar em uma queda de desempenho de 50 a 800 vezes. Após otimizar outros gargalos (como mudar para o algoritmo de hash Poseidon), esta parte de "execução de bloco" ainda consumirá 80-90% do tempo de prova, tornando o EVM o obstáculo final e mais teimoso à expansão do L1. Se esta camada for removida, Vitalik prevê que a eficiência de execução pode aumentar em 100 vezes.
A armadilha da dívida dos contratos pré-compilados
Para resolver o problema de desempenho insuficiente do EVM em operações criptográficas específicas, o Ethereum introduziu contratos pré-compilados - funções dedicadas codificadas diretamente no protocolo. Embora essa tenha sido uma solução pragmática na época, hoje ela gerou o que Vitalik Buterin chamou de "situação catastrófica":
"A pré-compilação é catastrófica para nós... ela expandiu enormemente a biblioteca de código confiável do Ethereum... e, na beira de uma falha de consenso, ela nos fez quase capotar várias vezes."
O seu nível de complexidade é de deixar qualquer um boquiaberto. Vitalik aponta, ao comparar o código de embalagem de um único contrato pré-compilado (modexp) com um interpretador RISC-V completo, que a lógica do pré-compilado é na verdade mais complexa. A nova pré-compilação deve passar por um processo de hard fork lento e cheio de jogos políticos, o que prejudica seriamente a inovação em aplicações que dependem de novos primitivos criptográficos.
Portanto, Vitalik chegou a uma conclusão firme: "Na verdade, eu acho que devemos parar imediatamente de adicionar qualquer contrato pré-compilado."
Dívida técnica da arquitetura do Ethereum
O design central do EVM reflete as necessidades de uma era ultrapassada, mas não consegue se adaptar à computação moderna. O EVM optou por uma arquitetura de 256 bits para processar valores criptográficos, o que é extremamente ineficiente para inteiros de 32 ou 64 bits geralmente utilizados em contratos inteligentes. O custo dessa ineficiência é especialmente alto em sistemas de prova de conhecimento zero.
Como Vitalik explicou: "Quando números menores são usados, cada número na verdade não economiza nenhum recurso, enquanto a complexidade aumenta de 2 a 4 vezes."
Além disso, a arquitetura de pilha do EVM é menos eficiente do que a arquitetura de registradores do RISC-V e das CPUs modernas. Ela requer mais instruções para executar a mesma operação, o que também torna a otimização do compilador mais complexa.
Esses fatores combinados incluem os gargalos de desempenho das provas ZK, a complexidade da pré-compilação e as escolhas de arquitetura obsoletas, que juntos constituem uma razão convincente e urgente para que o Ethereum vá além da EVM.
RISC-V Blueprint: Construir uma base mais sólida
As vantagens do RISC-V não derivam apenas das deficiências do EVM, mas também da sua filosofia de design e das suas vantagens intrínsecas. A sua arquitetura oferece uma base robusta, simples e verificável, tornando-se muito adequada para ambientes de alto risco como o Ethereum.
Por que os padrões abertos são superiores ao design personalizado
Ao contrário da arquitetura de conjunto de instruções (ISA) personalizada que precisa ser construída do zero para criar todo um ecossistema de software, o RISC-V é um padrão aberto maduro que pode oferecer três vantagens chave:
ecossistema maduro
Ao adotar o RISC-V, o Ethereum aproveitou os avanços coletivos no campo da ciência da computação ao longo de décadas. Como Justin Drake explicou, isso oferece ao Ethereum uma maneira de utilizar ferramentas de classe mundial diretamente: "Há um componente de infraestrutura chamado LLVM, que é um conjunto de ferramentas de compiladores que permite aos desenvolvedores compilar linguagens de programação de alto nível para várias backends. O RISC-V é um dos backends suportados. Portanto, se você suporta o RISC-V, pode automaticamente suportar todas as linguagens de alto nível suportadas pelo LLVM."
Isto reduziu significativamente a barreira de entrada para milhões de desenvolvedores familiarizados com linguagens como Rust, C e Go.
Filosofia de design minimalista
O minimalismo do RISC-V é uma característica intencional, e não uma limitação. O seu conjunto de instruções base contém apenas cerca de 47 instruções, tornando o núcleo da máquina virtual extremamente simples. Esta simplicidade é uma grande vantagem para a segurança, pois um repositório de código confiável menor é mais fácil de auditar e verificar formalmente.
Padrão de fato no campo ZK
Mais importante ainda, o ecossistema zkVM já fez uma escolha autônoma. Como Justin Drake enfatizou, a partir dos dados do Ethproofs, pode-se ver uma tendência clara: "RISC-V é a ISA líder do backend zkVM."
Em 10 zkVM capazes de provar blocos Ethereum, 9 escolheram RISC-V como arquitetura alvo. Essa convergência de mercado libera um forte sinal: a adoção do RISC-V pelo Ethereum não é uma tentativa especulativa, mas sim um seguimento de um padrão validado pelo mercado.
Projetado para confiança, não apenas para execução
Além do ecossistema, a arquitetura interna da RISC-V também é particularmente adequada para construir sistemas seguros e verificáveis.
Primeiro, o RISC-V tem uma especificação formal e legível por máquina, chamada SAIL. Isso representa uma enorme melhoria em relação à especificação da Máquina Virtual Ethereum (EVM), que existe principalmente na forma de documentação (livro amarelo) e pode ter ambiguidades. A especificação SAIL fornece um "padrão de ouro" que pode oferecer provas matemáticas cruciais para a correção do protocolo, o que é vital para proteger protocolos de grande valor. Como Alex Hicks da Ethereum Foundation (EF) apontou na chamada de Ethproofs, isso permite que os circuitos zkVM sejam verificados diretamente "de acordo com a especificação oficial do RISC-V".
Além disso, o RISC-V inclui uma arquitetura de privilégio, uma característica que muitas vezes é ignorada, mas que é crucial para a segurança. Ela define diferentes níveis de operação, incluindo principalmente o modo de usuário (para aplicações não confiáveis, como contratos inteligentes) e o modo regulado (para um "núcleo de execução" confiável).
No modelo RISC-V, os contratos inteligentes que são executados em modo de usuário não podem acessar diretamente o estado da blockchain. Em vez disso, eles devem emitir um pedido ao núcleo confiável que é executado em modo de supervisão através de uma instrução ECALL (chamada de ambiente) especial. Este mecanismo constrói uma fronteira de segurança imposta pelo hardware, que é mais robusta e mais fácil de verificar do que o modelo de sandbox EVM puramente baseado em software.
A visão de Vitalik
Esta transformação foi concebida como um processo gradual e em múltiplas fases, para garantir a estabilidade do sistema e a compatibilidade retroativa. O método descrito por Vitalik Buterin visa alcançar um desenvolvimento progressivo, em vez de uma mudança revolucionária.
Primeiro passo: substituição de pré-compilação
Na fase inicial, adota-se a abordagem mais conservadora, introduzindo funcionalidades limitadas na nova Máquina Virtual (VM). Como sugerido por Vitalik, "podemos começar a usar a nova máquina virtual em cenários limitados, como substituir funcionalidades pré-compiladas." Isso envolverá a suspensão das novas funcionalidades pré-compiladas do EVM, substituindo-as pela implementação das funcionalidades necessárias através de programas RISC-V aprovados por lista branca. Essa abordagem permite que a nova máquina virtual realize testes práticos na mainnet em um ambiente de baixo risco, enquanto os clientes Ethereum atuam como intermediários entre os dois ambientes de execução.
Passo dois: coexistência de duas máquinas virtuais
A próxima fase abrirá "novas máquinas virtuais diretamente para os usuários". Ao implantar contratos inteligentes, pode-se adicionar uma marca para indicar se seu bytecode é EVM ou RISC-V. A característica chave é garantir a interoperabilidade sem costura: "dois tipos de contratos poderão chamar um ao outro". Isso será realizado por meio de chamadas de sistema (ECALL), com o cliente Ethereum atuando como intermediário do ambiente de execução.
Passo três: EVM como contrato simulado (estratégia "Rosetta")
O objetivo final é alcançar a simplificação máxima do protocolo. Nesta fase, "vamos implementar o EVM como uma implementação de uma nova máquina virtual". O EVM padronizado se tornará um contrato inteligente verificado formalmente que roda nativamente no RISC-V L1. Isso não só garante suporte permanente para aplicativos legados, mas também permite que desenvolvedores de clientes mantenham apenas um único mecanismo de execução simplificado.
A reação em cadeia de todo o ecossistema
O plano de transição do EVM para o RISC-V vai muito além do protocolo central, terá um impacto profundo em todo o ecossistema Ethereum, prometendo reformular a experiência dos desenvolvedores, mudando fundamentalmente o cenário competitivo das soluções Layer-2 e abrindo novos modelos de economia de prova.
Reestruturação do Rollup: Divergência de caminhos entre Optimistic e ZK
A transição para a camada de execução RISC-V no L1 terá um impacto radicalmente diferente em dois tipos principais de Rollups.
O modelo de segurança das Rollups Otimistas (como Arbitrum, Optimism) depende da reexecução de transações controversas no Layer-1 para resolver provas de fraude. Mesmo que o Layer-1 do Ethereum migre para RISC-V, esses sistemas não sofrerão mudanças fundamentais. Como explicou um dos cofundadores da Optimism: "Se migrarmos o Ethereum para RISC-V, a cadeia Optimistic também não será interrompida. Você só precisa compilar a máquina virtual RISC-V no programa de prova. E não há necessidade de usar Asterisc. Os sistemas de prova existentes baseados em MIPS também não serão interrompidos - você só precisa compilar a máquina virtual RISC-V no MIPS."
Isso significa que o modelo de prevenção de fraudes ainda está intacto. O ajuste é técnico: compilar a nova máquina virtual RISC-V na infraestrutura existente, em vez de redesenhar o sistema do zero. O que resta é o desafio dos detalhes de engenharia, como medição de Gas, eficiência e custo.
Em comparação, os ZK Rollups obterão uma enorme vantagem estratégica. A grande maioria dos ZK Rollups já adotou o RISC-V como seu ISA interno. O uso da mesma linguagem nativa no L1 pode resultar em uma integração mais estreita e eficiente. Justin Drake descreveu a visão futura dos "Rollups nativos", onde o L2 é essencialmente uma instância especializada do ambiente de execução do próprio L1, utilizando a VM L1 embutida para uma liquidação sem costura. Essa integração trará as seguintes mudanças:
Simplificação da pilha tecnológica: eliminar a complexa ponte entre a execução interna RISC-V do L2 e o EVM;
Implementar reutilização de ferramentas e código: compiladores, depuradores e ferramentas de verificação formal desenvolvidos para o ambiente L1 RISC-V podem ser utilizados diretamente pelo L2, para reduzir os custos de desenvolvimento.
Incentivos econômicos coordenados: as taxas de Gas do L1 refletirão de forma mais precisa os custos reais da execução do RISC-V com prova ZK, criando assim um modelo econômico mais razoável.
A nova era para desenvolvedores e usuários
Para os desenvolvedores do ecossistema Ethereum, essa mudança será gradual, e não disruptiva.
Para os desenvolvedores, a vantagem chave é que eles podem entrar em um mundo de desenvolvimento de software mais amplo e maduro. Como Vitalik Buterin apontou, os desenvolvedores «poderão escrever contratos em Rust, e essas duas linguagens começarão a coexistir». Ao mesmo tempo, ele previu que «Solidity e Vyper continuarão populares por um longo tempo», pois possuem uma lógica de contratos inteligentes elegantemente projetada. A capacidade de usar linguagens mainstream e suas ricas bibliotecas através da cadeia de ferramentas LLVM, essa mudança será revolucionária. Vitalik descreveu isso como uma «experiência semelhante ao Node.JS», onde os desenvolvedores basicamente podem usar a mesma linguagem para escrever código on-chain e off-chain.
Para os usuários, o retorno final é uma rede mais econômica e poderosa. Espera-se que o custo de prova diminua cerca de 100 vezes - de alguns dólares por transação para alguns centavos - o que se traduz diretamente em taxas de liquidação mais baixas no Layer-1 e Layer-2. Essa viabilidade econômica abrirá a visão do "Gigagas L1", com o objetivo de alcançar cerca de 10000 TPS de desempenho no L1, apoiando assim aplicações on-chain mais complexas e de maior valor no futuro.
Succinct Labs e SP1: provar que o futuro está no presente
As vantagens teóricas do RISC-V foram colocadas em prática por equipes como a Succinct Labs, cujos resultados de trabalho fornecem estudos de caso sólidos para toda a proposta.
O SP1 desenvolvido pela Succinct Labs é uma zkVM de alto desempenho e código aberto baseada em RISC-V, que valida a viabilidade de uma nova abordagem arquitetônica. Adota o conceito de design "pré-compilação centralizada", resolvendo perfeitamente o problema do gargalo criptográfico do EVM. Ao contrário dos métodos de pré-compilação tradicionais, que dependem de abordagens lentas e codificadas, o SP1 descarrega operações intensivas, como a função de hash Keccak, para chamadas através de instruções ECALL padrão, além de ZK circuitos projetados especificamente e otimizados manualmente. Isso não só oferece o desempenho de hardware personalizado, mas também mantém a flexibilidade do software.
A influência prática da equipe já é claramente visível, o seu produto OP Succinct utiliza o SP1 para realizar a "ZK-ificação" (ZK-ify) do Optimistic Rollup. Como explicou a co-fundadora da Succinct, Uma Roy:
"A sua OP Stack Rollup não precisa de esperar 7 dias para concluir a confirmação final e a retirada... agora leva apenas 1 hora a concluir. Isto aumenta significativamente a velocidade da confirmação final, é realmente incrível."
Isto resolve um ponto crítico em todo o ecossistema OP Stack. Além disso, a infraestrutura da Succinct, a "Succinct Prover Network", foi projetada como um mercado descentralizado de geração de provas, apresentando um modelo econômico viável para o futuro da computação verificável. O trabalho deles não é apenas uma prova de conceito, mas sim um plano futuro viável descrito neste documento.
Como o Ethereum reduz o risco
Uma das principais vantagens do RISC-V é que torna o objetivo final da verificação formal — provar matematicamente a correção do sistema — um objetivo alcançável. A especificação do EVM está escrita em linguagem natural no Yellow Paper, o que torna a formalização extremamente difícil. Por outro lado, o RISC-V possui uma especificação oficial, legível por máquina, em SAIL, que fornece uma "referência de ouro" clara para seu comportamento.
Isto abre um caminho claro para uma segurança mais robusta. Como Alex Hicks da Fundação Ethereum apontou, já está a decorrer o trabalho de "extrair circuitos zkVM RISC-V da especificação oficial RISC-V para verificação formal no Lean". Este é um avanço marcante que transfere a confiança de implementações humanas propensas a erros para provas matemáticas verificáveis, resultando numa ruptura em termos de segurança.
Os principais riscos da transformação
Apesar de a arquitetura RISC-V ter muitas vantagens na L1, também enfrentará novos desafios complexos.
Problemas de medição de Gas: criar um modelo de Gas determinístico e justo para o ISA genérico é um dos problemas mais difíceis de resolver. Métodos simples de contagem de instruções estão sujeitos à ameaça de ataques de negação de serviço. Por exemplo, um atacante pode projetar um programa que aciona repetidamente um programa em cache, resultando em um alto consumo de recursos com um custo de Gas muito baixo.
Segurança da cadeia de ferramentas e o problema da "construção reproduzível": este pode ser o risco mais importante e subestimado durante o processo de transformação. O modelo de segurança passou de máquinas virtuais de uma cadeia de confiança para confiar em compiladores fora da cadeia usados por cada desenvolvedor (por exemplo, LLVM), e esses compiladores são extremamente complexos e sabe-se que contêm vulnerabilidades. Os atacantes podem explorar as vulnerabilidades dos compiladores para transformar código-fonte aparentemente inofensivo em bytecode malicioso. Além disso, garantir que os binários compilados na cadeia sejam idênticos ao código-fonte público específico, ou seja, o problema da "construção reproduzível", é também extremamente difícil de realizar, pois pequenas diferenças no ambiente de construção podem resultar em binários diferentes.
Estratégia de alívio
O caminho a seguir requer uma estratégia de defesa em múltiplas camadas.
Lançamento em fases: Um plano de transição gradual e em múltiplas etapas é a principal estratégia de mitigação de riscos. Ao introduzir primeiro o RISC-V como uma solução pré-compilada e, em seguida, implementar em um ambiente de máquinas virtuais duplas, a comunidade pode acumular experiência operacional e construir confiança em um ambiente de baixo risco antes que quaisquer mudanças irreversíveis ocorram.
Auditoria abrangente: teste de fuzzing e verificação formal. Embora a verificação formal seja o objetivo final, ela deve ser acompanhada de testes contínuos e de alta intensidade. Como demonstrou Valentine da Diligence Security na conferência telefônica da Ethproofs, seu testador de fuzzing Argus já identificou 11 vulnerabilidades críticas de solidez e integridade em um dos principais zkVM. Isso prova que mesmo os sistemas mais bem projetados têm falhas, que só podem ser descobertas por meio de testes adversariais rigorosos.
Normalização: Para evitar a fragmentação do ecossistema, a comunidade deve adotar um único perfil RISC-V padronizado. É provável que esta seja uma combinação do ABI RV64 GC e compatível com Linux, uma vez que esta combinação pode oferecer o suporte mais amplo de linguagens e ferramentas populares, maximizando assim as vantagens do novo ecossistema.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
Dívida técnica acumulada, como o Ethereum pode reconstruir a arquitetura técnica com RISC-V e encontrar uma solução?
Escrito por: jaehaerys.eth
Compilado por: Glendon, Techub News
TL;DR
O Ethereum está passando pela mudança arquitetônica mais importante desde a sua criação: a substituição da Máquina Virtual Ethereum (EVM) pelo RISC-V. A razão fundamental para essa mudança é que, na era das provas de conhecimento zero (ZK), a EVM se tornou o maior gargalo:
A zkEVM atual depende da execução do interpretador, resultando em uma redução de velocidade de 50 a 800 vezes;
Os contratos pré-compilados (Precompiles) tornam o protocolo excessivamente complexo e aumentam o risco;
O design de pilha de 256 bits é extremamente ineficiente na prova.
O RISC-V pode resolver esses problemas:
Minimalismo (cerca de 47 comandos básicos) + ecossistema LLVM maduro (suporte a Rust, C++, Go);
Já se tornou o padrão de fato para zkVM (90% dos projetos adotam);
A norma SAIL formalizada (em relação ao ambíguo livro amarelo) pode suportar uma verificação rigorosa;
O caminho de prova de hardware (ASIC/FPGA) está em teste (SP1, Nervos, Cartesi).
A migração é dividida em três fases:
RISC-V como alternativa a contratos pré-compilados (teste de baixo risco);
Era das Duas Máquinas Virtuais: EVM + RISC-V possuem total interoperabilidade;
EVM implementado internamente no RISC-V (semelhante à estratégia Rosetta).
Impacto do ecossistema:
As Rollups otimistas não são afetados; a mainnet RISC-V não eliminará as provas de fraude, os programas de prova existentes podem ser compilados para RISC-V (atualmente baseados em MIPS); caminho de migração: expandir a infraestrutura de tolerância a falhas atual para o RISC-V alvo, em vez de uma reestruturação completa;
ZK Rollup irá beneficiar-se enormemente (Polygon, zkSync, Scroll → mais barato, mais rápido, mais simples);
Os desenvolvedores podem usar diretamente bibliotecas Rust/Go/Python no L1;
Os usuários podem obter um custo de prova cerca de 100 vezes mais barato, avançando assim para o nível Gigagas (cerca de 10k TPS) na camada L1.
No final, o Ethereum irá evoluir de uma "máquina virtual de contratos inteligentes" para um nível de confiança na internet minimamente verificável, cujo objetivo final é: "tudo será ZK-Snark".
O Ethereum está em uma encruzilhada
Com o objetivo final de "tudo ser ZK-Snarkificado" como visão, o Ethereum está atualmente na iminência da mais importante evolução arquitetônica desde sua criação. Esta discussão não se limita mais a upgrades incrementais, mas envolve uma reestruturação fundamental de seu núcleo computacional — ou seja, a substituição da Máquina Virtual Ethereum (EVM). Esta iniciativa é a pedra angular de uma visão mais ampla chamada "Ethereum Lean" (Ethereum Enxuto), que pretende simplificar sistematicamente todo o protocolo, dividindo-o em três componentes principais: Consenso Enxuto (Lean Consensus), Dados Enxutos (Lean Data) e Execução Enxuta (Lean Execution). E a questão central da Execução Enxuta é: a EVM, como motor da revolução dos contratos inteligentes, tornou-se agora o principal gargalo para o desenvolvimento futuro do Ethereum?
Como disse Justin Drake da Fundação Ethereum, o objetivo de longo prazo do Ethereum sempre foi "snarkizar tudo", uma ferramenta poderosa que pode fortalecer as várias camadas do protocolo. Mas, por muito tempo, esse objetivo parecia mais uma "castelo no ar", pois sua realização exigia provas em tempo real desse conceito. E agora, à medida que a prova em tempo real se torna uma realidade, a ineficiência teórica do EVM se transformou em um problema prático que precisa ser resolvido.
Esta análise irá explorar os argumentos técnicos e estratégicos para a migração do L1 do Ethereum para a arquitetura de conjunto de instruções RISC-V (ISA), uma medida que promete liberar uma escalabilidade sem precedentes, simplificar a estrutura do protocolo e alinhar o Ethereum com o futuro da computação verificável.
O que exatamente mudou?
Antes de aprofundar a discussão sobre o "porquê", é primeiro necessário entender o "o que" está a mudar.
EVM é o ambiente de execução de contratos inteligentes do Ethereum, sendo o "computador mundial" que processa transações e atualiza o estado da blockchain. Ao longo dos anos, seu design foi revolucionário, criando uma plataforma sem permissões e dando origem a todo o ecossistema DeFi e NFT. No entanto, essa arquitetura personalizada, que remonta a quase uma década, acumulou uma pesada dívida técnica.
Em comparação, o RISC-V não é um produto, mas sim um padrão aberto — um "alfabeto" de design de processador gratuito e genérico. Como Jeremy Bruestle enfatizou na conferência telefônica da Ethproofs, seus princípios fundamentais fazem dele a escolha ideal para esse papel:
Minimalismo: o conjunto de instruções básico é extremamente simples, contendo apenas cerca de 40-47 instruções. Jeremy descreve-o como "quase o caso perfeito de uma máquina universal super simplificada que precisamos."
Modular: Adicionando funcionalidades mais complexas através de extensões opcionais. Isso é crucial, pois permite um núcleo simples que pode ser expandido conforme necessário, sem impor complexidade desnecessária ao protocolo base;
Ecossistema aberto: ele possui um vasto e maduro suporte de ferramentas, incluindo o compilador LLVM, permitindo que os desenvolvedores utilizem linguagens populares como Rust, C++ e Go. Como disse Justin Drake: "Existem muitas ferramentas relacionadas a compiladores, e a construção de compiladores é extremamente difícil... Portanto, ter essas ferramentas de compilador é de grande valor." RISC-V permite que o Ethereum herde gratuitamente essas ferramentas prontas.
Problema de custo do interpretador
A necessidade de substituir o EVM não decorre de uma única falha, mas de uma série de limitações fundamentais que, no contexto do futuro nativo da prova de conhecimento zero (ZK), tornaram-se impossíveis de ignorar. Esses problemas abrangem gargalos de desempenho severos nos sistemas de prova ZK, bem como os riscos associados à complexidade crescente acumulada dentro dos protocolos.
Problema de custo do interpretador
O principal motor de transformação mais urgente é a ineficiência inerente do EVM nos sistemas de prova de zero conhecimento. À medida que o Ethereum avança gradualmente para um modelo em que o estado L1 é validado por provas ZK, o desempenho do provador se tornará o gargalo final.
O problema reside na forma como o zkEVM atual funciona. Eles não realizam provas de conhecimento zero diretamente sobre o EVM, mas sim sobre um interpretador do EVM que, por sua vez, é compilado para RISC-V. Vitalik Buterin apontou de forma direta este problema central:
"Se a implementação do zkVM consiste em compilar a execução do EVM em conteúdo que eventualmente se torna código RISC-V, por que não abrir diretamente o RISC-V subjacente para os desenvolvedores de contratos inteligentes? Isso poderia eliminar completamente a sobrecarga de toda a máquina virtual externa."
Esta camada adicional de explicação trouxe uma enorme perda de desempenho. De acordo com estimativas, em comparação com a prova de programas nativos, esta camada pode resultar em uma queda de desempenho de 50 a 800 vezes. Após otimizar outros gargalos (como mudar para o algoritmo de hash Poseidon), esta parte de "execução de bloco" ainda consumirá 80-90% do tempo de prova, tornando o EVM o obstáculo final e mais teimoso à expansão do L1. Se esta camada for removida, Vitalik prevê que a eficiência de execução pode aumentar em 100 vezes.
A armadilha da dívida dos contratos pré-compilados
Para resolver o problema de desempenho insuficiente do EVM em operações criptográficas específicas, o Ethereum introduziu contratos pré-compilados - funções dedicadas codificadas diretamente no protocolo. Embora essa tenha sido uma solução pragmática na época, hoje ela gerou o que Vitalik Buterin chamou de "situação catastrófica":
"A pré-compilação é catastrófica para nós... ela expandiu enormemente a biblioteca de código confiável do Ethereum... e, na beira de uma falha de consenso, ela nos fez quase capotar várias vezes."
O seu nível de complexidade é de deixar qualquer um boquiaberto. Vitalik aponta, ao comparar o código de embalagem de um único contrato pré-compilado (modexp) com um interpretador RISC-V completo, que a lógica do pré-compilado é na verdade mais complexa. A nova pré-compilação deve passar por um processo de hard fork lento e cheio de jogos políticos, o que prejudica seriamente a inovação em aplicações que dependem de novos primitivos criptográficos.
Portanto, Vitalik chegou a uma conclusão firme: "Na verdade, eu acho que devemos parar imediatamente de adicionar qualquer contrato pré-compilado."
Dívida técnica da arquitetura do Ethereum
O design central do EVM reflete as necessidades de uma era ultrapassada, mas não consegue se adaptar à computação moderna. O EVM optou por uma arquitetura de 256 bits para processar valores criptográficos, o que é extremamente ineficiente para inteiros de 32 ou 64 bits geralmente utilizados em contratos inteligentes. O custo dessa ineficiência é especialmente alto em sistemas de prova de conhecimento zero.
Como Vitalik explicou: "Quando números menores são usados, cada número na verdade não economiza nenhum recurso, enquanto a complexidade aumenta de 2 a 4 vezes."
Além disso, a arquitetura de pilha do EVM é menos eficiente do que a arquitetura de registradores do RISC-V e das CPUs modernas. Ela requer mais instruções para executar a mesma operação, o que também torna a otimização do compilador mais complexa.
Esses fatores combinados incluem os gargalos de desempenho das provas ZK, a complexidade da pré-compilação e as escolhas de arquitetura obsoletas, que juntos constituem uma razão convincente e urgente para que o Ethereum vá além da EVM.
RISC-V Blueprint: Construir uma base mais sólida
As vantagens do RISC-V não derivam apenas das deficiências do EVM, mas também da sua filosofia de design e das suas vantagens intrínsecas. A sua arquitetura oferece uma base robusta, simples e verificável, tornando-se muito adequada para ambientes de alto risco como o Ethereum.
Por que os padrões abertos são superiores ao design personalizado
Ao contrário da arquitetura de conjunto de instruções (ISA) personalizada que precisa ser construída do zero para criar todo um ecossistema de software, o RISC-V é um padrão aberto maduro que pode oferecer três vantagens chave:
ecossistema maduro
Ao adotar o RISC-V, o Ethereum aproveitou os avanços coletivos no campo da ciência da computação ao longo de décadas. Como Justin Drake explicou, isso oferece ao Ethereum uma maneira de utilizar ferramentas de classe mundial diretamente: "Há um componente de infraestrutura chamado LLVM, que é um conjunto de ferramentas de compiladores que permite aos desenvolvedores compilar linguagens de programação de alto nível para várias backends. O RISC-V é um dos backends suportados. Portanto, se você suporta o RISC-V, pode automaticamente suportar todas as linguagens de alto nível suportadas pelo LLVM."
Isto reduziu significativamente a barreira de entrada para milhões de desenvolvedores familiarizados com linguagens como Rust, C e Go.
Filosofia de design minimalista
O minimalismo do RISC-V é uma característica intencional, e não uma limitação. O seu conjunto de instruções base contém apenas cerca de 47 instruções, tornando o núcleo da máquina virtual extremamente simples. Esta simplicidade é uma grande vantagem para a segurança, pois um repositório de código confiável menor é mais fácil de auditar e verificar formalmente.
Padrão de fato no campo ZK
Mais importante ainda, o ecossistema zkVM já fez uma escolha autônoma. Como Justin Drake enfatizou, a partir dos dados do Ethproofs, pode-se ver uma tendência clara: "RISC-V é a ISA líder do backend zkVM."
Em 10 zkVM capazes de provar blocos Ethereum, 9 escolheram RISC-V como arquitetura alvo. Essa convergência de mercado libera um forte sinal: a adoção do RISC-V pelo Ethereum não é uma tentativa especulativa, mas sim um seguimento de um padrão validado pelo mercado.
Projetado para confiança, não apenas para execução
Além do ecossistema, a arquitetura interna da RISC-V também é particularmente adequada para construir sistemas seguros e verificáveis.
Primeiro, o RISC-V tem uma especificação formal e legível por máquina, chamada SAIL. Isso representa uma enorme melhoria em relação à especificação da Máquina Virtual Ethereum (EVM), que existe principalmente na forma de documentação (livro amarelo) e pode ter ambiguidades. A especificação SAIL fornece um "padrão de ouro" que pode oferecer provas matemáticas cruciais para a correção do protocolo, o que é vital para proteger protocolos de grande valor. Como Alex Hicks da Ethereum Foundation (EF) apontou na chamada de Ethproofs, isso permite que os circuitos zkVM sejam verificados diretamente "de acordo com a especificação oficial do RISC-V".
Além disso, o RISC-V inclui uma arquitetura de privilégio, uma característica que muitas vezes é ignorada, mas que é crucial para a segurança. Ela define diferentes níveis de operação, incluindo principalmente o modo de usuário (para aplicações não confiáveis, como contratos inteligentes) e o modo regulado (para um "núcleo de execução" confiável).
No modelo RISC-V, os contratos inteligentes que são executados em modo de usuário não podem acessar diretamente o estado da blockchain. Em vez disso, eles devem emitir um pedido ao núcleo confiável que é executado em modo de supervisão através de uma instrução ECALL (chamada de ambiente) especial. Este mecanismo constrói uma fronteira de segurança imposta pelo hardware, que é mais robusta e mais fácil de verificar do que o modelo de sandbox EVM puramente baseado em software.
A visão de Vitalik
Esta transformação foi concebida como um processo gradual e em múltiplas fases, para garantir a estabilidade do sistema e a compatibilidade retroativa. O método descrito por Vitalik Buterin visa alcançar um desenvolvimento progressivo, em vez de uma mudança revolucionária.
Primeiro passo: substituição de pré-compilação
Na fase inicial, adota-se a abordagem mais conservadora, introduzindo funcionalidades limitadas na nova Máquina Virtual (VM). Como sugerido por Vitalik, "podemos começar a usar a nova máquina virtual em cenários limitados, como substituir funcionalidades pré-compiladas." Isso envolverá a suspensão das novas funcionalidades pré-compiladas do EVM, substituindo-as pela implementação das funcionalidades necessárias através de programas RISC-V aprovados por lista branca. Essa abordagem permite que a nova máquina virtual realize testes práticos na mainnet em um ambiente de baixo risco, enquanto os clientes Ethereum atuam como intermediários entre os dois ambientes de execução.
Passo dois: coexistência de duas máquinas virtuais
A próxima fase abrirá "novas máquinas virtuais diretamente para os usuários". Ao implantar contratos inteligentes, pode-se adicionar uma marca para indicar se seu bytecode é EVM ou RISC-V. A característica chave é garantir a interoperabilidade sem costura: "dois tipos de contratos poderão chamar um ao outro". Isso será realizado por meio de chamadas de sistema (ECALL), com o cliente Ethereum atuando como intermediário do ambiente de execução.
Passo três: EVM como contrato simulado (estratégia "Rosetta")
O objetivo final é alcançar a simplificação máxima do protocolo. Nesta fase, "vamos implementar o EVM como uma implementação de uma nova máquina virtual". O EVM padronizado se tornará um contrato inteligente verificado formalmente que roda nativamente no RISC-V L1. Isso não só garante suporte permanente para aplicativos legados, mas também permite que desenvolvedores de clientes mantenham apenas um único mecanismo de execução simplificado.
A reação em cadeia de todo o ecossistema
O plano de transição do EVM para o RISC-V vai muito além do protocolo central, terá um impacto profundo em todo o ecossistema Ethereum, prometendo reformular a experiência dos desenvolvedores, mudando fundamentalmente o cenário competitivo das soluções Layer-2 e abrindo novos modelos de economia de prova.
Reestruturação do Rollup: Divergência de caminhos entre Optimistic e ZK
A transição para a camada de execução RISC-V no L1 terá um impacto radicalmente diferente em dois tipos principais de Rollups.
O modelo de segurança das Rollups Otimistas (como Arbitrum, Optimism) depende da reexecução de transações controversas no Layer-1 para resolver provas de fraude. Mesmo que o Layer-1 do Ethereum migre para RISC-V, esses sistemas não sofrerão mudanças fundamentais. Como explicou um dos cofundadores da Optimism: "Se migrarmos o Ethereum para RISC-V, a cadeia Optimistic também não será interrompida. Você só precisa compilar a máquina virtual RISC-V no programa de prova. E não há necessidade de usar Asterisc. Os sistemas de prova existentes baseados em MIPS também não serão interrompidos - você só precisa compilar a máquina virtual RISC-V no MIPS."
Isso significa que o modelo de prevenção de fraudes ainda está intacto. O ajuste é técnico: compilar a nova máquina virtual RISC-V na infraestrutura existente, em vez de redesenhar o sistema do zero. O que resta é o desafio dos detalhes de engenharia, como medição de Gas, eficiência e custo.
Em comparação, os ZK Rollups obterão uma enorme vantagem estratégica. A grande maioria dos ZK Rollups já adotou o RISC-V como seu ISA interno. O uso da mesma linguagem nativa no L1 pode resultar em uma integração mais estreita e eficiente. Justin Drake descreveu a visão futura dos "Rollups nativos", onde o L2 é essencialmente uma instância especializada do ambiente de execução do próprio L1, utilizando a VM L1 embutida para uma liquidação sem costura. Essa integração trará as seguintes mudanças:
Simplificação da pilha tecnológica: eliminar a complexa ponte entre a execução interna RISC-V do L2 e o EVM;
Implementar reutilização de ferramentas e código: compiladores, depuradores e ferramentas de verificação formal desenvolvidos para o ambiente L1 RISC-V podem ser utilizados diretamente pelo L2, para reduzir os custos de desenvolvimento.
Incentivos econômicos coordenados: as taxas de Gas do L1 refletirão de forma mais precisa os custos reais da execução do RISC-V com prova ZK, criando assim um modelo econômico mais razoável.
A nova era para desenvolvedores e usuários
Para os desenvolvedores do ecossistema Ethereum, essa mudança será gradual, e não disruptiva.
Para os desenvolvedores, a vantagem chave é que eles podem entrar em um mundo de desenvolvimento de software mais amplo e maduro. Como Vitalik Buterin apontou, os desenvolvedores «poderão escrever contratos em Rust, e essas duas linguagens começarão a coexistir». Ao mesmo tempo, ele previu que «Solidity e Vyper continuarão populares por um longo tempo», pois possuem uma lógica de contratos inteligentes elegantemente projetada. A capacidade de usar linguagens mainstream e suas ricas bibliotecas através da cadeia de ferramentas LLVM, essa mudança será revolucionária. Vitalik descreveu isso como uma «experiência semelhante ao Node.JS», onde os desenvolvedores basicamente podem usar a mesma linguagem para escrever código on-chain e off-chain.
Para os usuários, o retorno final é uma rede mais econômica e poderosa. Espera-se que o custo de prova diminua cerca de 100 vezes - de alguns dólares por transação para alguns centavos - o que se traduz diretamente em taxas de liquidação mais baixas no Layer-1 e Layer-2. Essa viabilidade econômica abrirá a visão do "Gigagas L1", com o objetivo de alcançar cerca de 10000 TPS de desempenho no L1, apoiando assim aplicações on-chain mais complexas e de maior valor no futuro.
Succinct Labs e SP1: provar que o futuro está no presente
As vantagens teóricas do RISC-V foram colocadas em prática por equipes como a Succinct Labs, cujos resultados de trabalho fornecem estudos de caso sólidos para toda a proposta.
O SP1 desenvolvido pela Succinct Labs é uma zkVM de alto desempenho e código aberto baseada em RISC-V, que valida a viabilidade de uma nova abordagem arquitetônica. Adota o conceito de design "pré-compilação centralizada", resolvendo perfeitamente o problema do gargalo criptográfico do EVM. Ao contrário dos métodos de pré-compilação tradicionais, que dependem de abordagens lentas e codificadas, o SP1 descarrega operações intensivas, como a função de hash Keccak, para chamadas através de instruções ECALL padrão, além de ZK circuitos projetados especificamente e otimizados manualmente. Isso não só oferece o desempenho de hardware personalizado, mas também mantém a flexibilidade do software.
A influência prática da equipe já é claramente visível, o seu produto OP Succinct utiliza o SP1 para realizar a "ZK-ificação" (ZK-ify) do Optimistic Rollup. Como explicou a co-fundadora da Succinct, Uma Roy:
"A sua OP Stack Rollup não precisa de esperar 7 dias para concluir a confirmação final e a retirada... agora leva apenas 1 hora a concluir. Isto aumenta significativamente a velocidade da confirmação final, é realmente incrível."
Isto resolve um ponto crítico em todo o ecossistema OP Stack. Além disso, a infraestrutura da Succinct, a "Succinct Prover Network", foi projetada como um mercado descentralizado de geração de provas, apresentando um modelo econômico viável para o futuro da computação verificável. O trabalho deles não é apenas uma prova de conceito, mas sim um plano futuro viável descrito neste documento.
Como o Ethereum reduz o risco
Uma das principais vantagens do RISC-V é que torna o objetivo final da verificação formal — provar matematicamente a correção do sistema — um objetivo alcançável. A especificação do EVM está escrita em linguagem natural no Yellow Paper, o que torna a formalização extremamente difícil. Por outro lado, o RISC-V possui uma especificação oficial, legível por máquina, em SAIL, que fornece uma "referência de ouro" clara para seu comportamento.
Isto abre um caminho claro para uma segurança mais robusta. Como Alex Hicks da Fundação Ethereum apontou, já está a decorrer o trabalho de "extrair circuitos zkVM RISC-V da especificação oficial RISC-V para verificação formal no Lean". Este é um avanço marcante que transfere a confiança de implementações humanas propensas a erros para provas matemáticas verificáveis, resultando numa ruptura em termos de segurança.
Os principais riscos da transformação
Apesar de a arquitetura RISC-V ter muitas vantagens na L1, também enfrentará novos desafios complexos.
Problemas de medição de Gas: criar um modelo de Gas determinístico e justo para o ISA genérico é um dos problemas mais difíceis de resolver. Métodos simples de contagem de instruções estão sujeitos à ameaça de ataques de negação de serviço. Por exemplo, um atacante pode projetar um programa que aciona repetidamente um programa em cache, resultando em um alto consumo de recursos com um custo de Gas muito baixo.
Segurança da cadeia de ferramentas e o problema da "construção reproduzível": este pode ser o risco mais importante e subestimado durante o processo de transformação. O modelo de segurança passou de máquinas virtuais de uma cadeia de confiança para confiar em compiladores fora da cadeia usados por cada desenvolvedor (por exemplo, LLVM), e esses compiladores são extremamente complexos e sabe-se que contêm vulnerabilidades. Os atacantes podem explorar as vulnerabilidades dos compiladores para transformar código-fonte aparentemente inofensivo em bytecode malicioso. Além disso, garantir que os binários compilados na cadeia sejam idênticos ao código-fonte público específico, ou seja, o problema da "construção reproduzível", é também extremamente difícil de realizar, pois pequenas diferenças no ambiente de construção podem resultar em binários diferentes.
Estratégia de alívio
O caminho a seguir requer uma estratégia de defesa em múltiplas camadas.
Lançamento em fases: Um plano de transição gradual e em múltiplas etapas é a principal estratégia de mitigação de riscos. Ao introduzir primeiro o RISC-V como uma solução pré-compilada e, em seguida, implementar em um ambiente de máquinas virtuais duplas, a comunidade pode acumular experiência operacional e construir confiança em um ambiente de baixo risco antes que quaisquer mudanças irreversíveis ocorram.
Auditoria abrangente: teste de fuzzing e verificação formal. Embora a verificação formal seja o objetivo final, ela deve ser acompanhada de testes contínuos e de alta intensidade. Como demonstrou Valentine da Diligence Security na conferência telefônica da Ethproofs, seu testador de fuzzing Argus já identificou 11 vulnerabilidades críticas de solidez e integridade em um dos principais zkVM. Isso prova que mesmo os sistemas mais bem projetados têm falhas, que só podem ser descobertas por meio de testes adversariais rigorosos.
Normalização: Para evitar a fragmentação do ecossistema, a comunidade deve adotar um único perfil RISC-V padronizado. É provável que esta seja uma combinação do ABI RV64 GC e compatível com Linux, uma vez que esta combinação pode oferecer o suporte mais amplo de linguagens e ferramentas populares, maximizando assim as vantagens do novo ecossistema.