Ethereum pode passar pela maior atualização da história: EVM será desativada e RISC-V assumirá o controle

Título original: Goodbye EVM, Hello RISC-V

Autor original: jaehaerys.eth, pesquisador de cripto

Tradução original: TechFlow

Resumo

O Ethereum está se preparando para a transformação arquitetônica mais importante desde sua criação: substituir a EVM por RISC-V.

O motivo é simples — em um futuro centrado em zero-knowledge (ZK), a EVM já se tornou um gargalo de desempenho:

· Atualmente, zkEVM depende de interpretadores, causando uma desaceleração de 50–800 vezes no desempenho;

· Módulos pré-compilados tornam o protocolo mais complexo e aumentam o risco;

· O design da pilha de 256 bits é extremamente ineficiente na geração de provas.

Soluções do RISC-V:

· Design minimalista (cerca de 47 instruções básicas) + ecossistema maduro do LLVM (suporte a Rust, C++, Go e outras linguagens);

· Já se tornou o padrão de fato para zkVM (adotado por 90% dos projetos);

· Possui especificação formal SAIL (em comparação ao ambíguo Yellow Paper) → permite verificação rigorosa;

· Caminho de prova em hardware (ASICs/FPGAs) já em teste (SP1, Nervos, Cartesi, etc.).

O processo de migração ocorre em três fases:

· Substituição por RISC-V como módulo pré-compilado (teste de baixo risco);

· Era de dupla máquina virtual: EVM e RISC-V coexistem e são totalmente interoperáveis;

· Reimplementação da EVM dentro do RISC-V (estratégia Rosetta).

Impacto no ecossistema:

· Rollups otimistas (como Arbitrum e Optimism) precisarão reconstruir o mecanismo de prova de fraude;

· Rollups de zero-knowledge (como Polygon, zkSync, Scroll) terão enorme vantagem → mais barato, mais rápido, mais simples;

· Desenvolvedores poderão usar diretamente bibliotecas de Rust, Go e Python na camada L1;

· Usuários desfrutarão de custos de prova cerca de 100 vezes menores → caminho para Gigagas L1 (cerca de 10.000 TPS).

No final, o Ethereum evoluirá de uma “máquina virtual de contratos inteligentes” para uma camada de confiança minimalista e verificável da internet, com o objetivo final de “ZK-Snarkificar tudo”.

O cruzamento do Ethereum

Vitalik Buterin já disse: “O objetivo final inclui... ZK-Snarkificar tudo.”

O fim do jogo dos zero-knowledge proofs (ZK) é inevitável, e o argumento central é simples: o Ethereum está se reconstruindo do zero com base em provas de conhecimento zero. Isso marca o ponto final técnico do protocolo — uma reconstrução do L1, impulsionada por um zkVM de alto desempenho apoiado por equipes centrais de desenvolvimento (como a Succinct).

Com essa visão como destino, o Ethereum está no limiar de sua transformação arquitetônica mais importante desde o nascimento. A discussão não é mais sobre atualizações incrementais, mas sobre uma reconstrução completa do núcleo computacional — a substituição da Ethereum Virtual Machine (EVM). Essa medida é a pedra angular da visão mais ampla do “Lean Ethereum”.

A visão do Lean Ethereum busca simplificar sistematicamente todo o protocolo, dividindo-o em três módulos principais: Lean Consensus, Lean Data e Lean Execution. No cerne da Lean Execution, a questão mais crítica é: como o motor que impulsionou a revolução dos contratos inteligentes, a EVM se tornou o principal gargalo para o futuro do Ethereum?

Como disse Justin Drake da Ethereum Foundation, o objetivo de longo prazo do Ethereum sempre foi “Snarkificar tudo”, uma poderosa ferramenta para fortalecer todas as camadas do protocolo. No entanto, por muito tempo, esse objetivo parecia um “plano distante”, pois exigia o conceito de real-time proving. Agora, com a realização do real-time proving se tornando realidade, a ineficiência teórica da EVM tornou-se um problema prático urgente.

Este artigo analisa profundamente os argumentos técnicos e estratégicos para migrar o Ethereum L1 para a arquitetura de conjunto de instruções RISC-V (ISA). Essa medida não só promete liberar uma escalabilidade sem precedentes, mas também simplificar a estrutura do protocolo e alinhar o Ethereum com o futuro da computação verificável.

O que mudou, afinal?

Antes de discutir o “porquê”, é preciso esclarecer o “o quê” está mudando.

A EVM (Ethereum Virtual Machine) é o ambiente de execução dos contratos inteligentes do Ethereum, conhecida como o “computador mundial” que processa transações e atualiza o estado da blockchain. Por anos, seu design foi revolucionário, lançando as bases para o DeFi e o ecossistema NFT. No entanto, essa arquitetura personalizada de quase uma década acumulou uma grande dívida técnica.

Em contraste, RISC-V não é um produto, mas um padrão aberto — um “alfabeto” gratuito e universal de design de processadores. Como Jeremy Bruestle destacou na conferência Ethproofs, seus princípios-chave o tornam uma escolha ideal para esse papel:

· Minimalismo: O conjunto de instruções básico do RISC-V é extremamente simples, com cerca de 40 a 47 instruções. Como Jeremy disse, isso o torna “quase perfeito para o caso de uso de uma máquina universal super minimalista que precisamos”.

· Design modular: Funcionalidades mais complexas são adicionadas por meio de extensões opcionais. Isso é crucial, pois permite que o núcleo permaneça simples, enquanto funcionalidades podem ser expandidas conforme necessário, sem impor complexidade desnecessária ao protocolo base.

· Ecossistema aberto: O RISC-V possui uma vasta e madura cadeia de ferramentas, incluindo o compilador LLVM, permitindo que desenvolvedores usem linguagens populares como Rust, C++ e Go. Como Justin Drake mencionou: “As ferramentas em torno dos compiladores são muito ricas, e construir compiladores é extremamente difícil... então ter essas cadeias de ferramentas é extremamente valioso.” O RISC-V permite que o Ethereum herde essas ferramentas gratuitamente.

O problema do overhead do interpretador

A motivação para substituir a EVM não é um único defeito, mas a convergência de várias limitações fundamentais, que se tornaram impossíveis de ignorar em um futuro centrado em provas de conhecimento zero. Essas limitações incluem gargalos de desempenho nos sistemas de provas ZK e o risco crescente devido à complexidade acumulada dentro do protocolo.

O principal motor dessa transformação é a ineficiência inerente da EVM nos sistemas de provas ZK. À medida que o Ethereum migra para um modelo em que o estado do L1 é verificado por provas ZK, o desempenho do provador se torna o maior gargalo.

O problema está na forma como os zkEVMs atuais funcionam. Eles não provam diretamente a EVM, mas sim o interpretador da EVM, que por sua vez é compilado para RISC-V. Vitalik Buterin apontou claramente esse problema central:

“...se a implementação do zkVM é compilar a execução da EVM para algo que acaba virando código RISC-V, por que não expor diretamente o RISC-V subjacente aos desenvolvedores de contratos inteligentes? Assim, eliminamos todo o overhead da camada externa da VM.”

Essa camada extra de interpretação traz uma enorme perda de desempenho. Estimativas mostram que, em comparação com provar programas nativos, essa camada pode causar uma queda de desempenho de 50 a 800 vezes. Mesmo otimizando outros gargalos (como mudando para o hash Poseidon), essa parte da “execução do bloco” ainda consome 80-90% de todo o tempo de prova, tornando a EVM o obstáculo final e mais difícil para escalar o L1. Ao remover essa camada, Vitalik prevê um aumento de eficiência de até 100 vezes.

Armadilha da dívida técnica

Para compensar a baixa performance da EVM em operações criptográficas específicas, o Ethereum introduziu contratos pré-compilados — funções especializadas codificadas diretamente no protocolo. Embora essa solução tenha sido pragmática na época, hoje ela leva ao que Vitalik Buterin chama de situação “ruim”:

“Pré-compilados foram desastrosos para nós... eles inflaram enormemente a base de código confiável do Ethereum... e já causaram quase falhas de consenso sérias algumas vezes.”

A complexidade é chocante. Vitalik exemplifica que o código wrapper de um único contrato pré-compilado (como modexp) é mais complexo do que todo o interpretador RISC-V, e a lógica do pré-compilado é ainda mais complicada. Adicionar novos pré-compilados exige um processo de hard fork lento e politicamente controverso, dificultando a inovação de aplicações que precisam de novos primitivos criptográficos. Vitalik conclui:

“Acho que devemos parar de adicionar qualquer novo pré-compilado a partir de hoje.”

Dívida técnica arquitetônica do Ethereum

O design central da EVM reflete prioridades de uma era passada, mas não atende mais às demandas da computação moderna. A EVM escolheu uma arquitetura de 256 bits para lidar com valores criptográficos, mas para inteiros de 32 ou 64 bits, comuns em contratos inteligentes, essa arquitetura é extremamente ineficiente. Essa ineficiência é especialmente cara em sistemas ZK. Como Vitalik explica:

“Quando se usam números menores, cada número na verdade não economiza recursos, e a complexidade aumenta de duas a quatro vezes.”

Além disso, a arquitetura de pilha da EVM é menos eficiente do que a arquitetura de registradores do RISC-V e CPUs modernas. Ela exige mais instruções para realizar as mesmas operações e dificulta otimizações de compilador.

Esses problemas — incluindo o gargalo de desempenho das provas ZK, a complexidade dos pré-compilados e escolhas arquitetônicas obsoletas — formam um argumento convincente e urgente: o Ethereum precisa ir além da EVM e abraçar uma arquitetura tecnológica mais adequada ao futuro.

O plano RISC-V: remodelando o futuro do Ethereum com uma base mais forte

As vantagens do RISC-V não estão apenas nas deficiências da EVM, mas também na força inerente de sua filosofia de design. Sua arquitetura oferece uma base robusta, simples e verificável, ideal para ambientes de alto risco como o Ethereum.

Por que padrões abertos superam designs personalizados?

Diferente de arquiteturas de conjunto de instruções (ISA) personalizadas, que exigem construir todo o ecossistema de software do zero, o RISC-V é um padrão aberto maduro, com três vantagens principais:

Ecossistema maduro

Ao adotar o RISC-V, o Ethereum pode aproveitar décadas de progresso coletivo da ciência da computação. Como Justin Drake explica, isso permite ao Ethereum usar ferramentas de classe mundial diretamente:

“Existe um componente de infraestrutura chamado LLVM, uma cadeia de ferramentas de compilador que permite compilar linguagens de alto nível para vários backends. Um dos backends suportados é o RISC-V. Então, se você suporta RISC-V, automaticamente suporta todas as linguagens de alto nível suportadas pelo LLVM.”

Isso reduz drasticamente a barreira de entrada, permitindo que milhões de desenvolvedores familiarizados com Rust, C++ e Go comecem a trabalhar facilmente.

Filosofia de design minimalista O minimalismo do RISC-V é uma característica intencional, não uma limitação. Seu conjunto básico de instruções tem cerca de 47 instruções, mantendo o núcleo da VM extremamente enxuto. Essa simplicidade traz vantagens significativas de segurança, pois uma base de código confiável menor é mais fácil de auditar e formalizar.

Padrão de fato no campo das provas ZK Mais importante, o ecossistema zkVM já fez sua escolha. Como Justin Drake aponta, os dados do Ethproofs mostram uma tendência clara:

“O RISC-V é a principal arquitetura de conjunto de instruções (ISA) para backends zkVM.”

Entre dez zkVMs capazes de provar blocos do Ethereum, nove já escolheram o RISC-V como arquitetura alvo. Essa convergência de mercado envia um sinal forte: ao adotar o RISC-V, o Ethereum não está fazendo uma aposta especulativa, mas alinhando-se a um padrão já validado e reconhecido por projetos que constroem o futuro ZK.

Nascido para a confiança, não apenas execução

Além do ecossistema amplo, a arquitetura interna do RISC-V é especialmente adequada para construir sistemas seguros e verificáveis. Primeiro, o RISC-V possui uma especificação formal e legível por máquina — SAIL. Isso é um grande avanço em relação à especificação da EVM (principalmente textual no Yellow Paper). O Yellow Paper é ambíguo, enquanto a especificação SAIL fornece um “padrão ouro” que suporta provas matemáticas de correção, essenciais para proteger protocolos de alto valor. Como Alex Hicks da Ethereum Foundation mencionou na Ethproofs, isso permite que circuitos zkVM sejam verificados diretamente “contra a especificação oficial do RISC-V”. Em segundo lugar, o RISC-V inclui uma arquitetura privilegiada, um recurso frequentemente ignorado, mas crucial para a segurança. Ela define diferentes níveis de operação, principalmente o modo usuário (para aplicações não confiáveis, como contratos inteligentes) e o modo supervisor (para o “kernel de execução” confiável). Diego, da Cartesi, explica:

“O sistema operacional precisa se proteger de outros códigos. Ele precisa isolar diferentes programas, e todos esses mecanismos fazem parte do padrão RISC-V.”

Na arquitetura RISC-V, contratos inteligentes rodando no modo usuário não podem acessar diretamente o estado da blockchain. Em vez disso, precisam fazer uma solicitação via instrução ECALL ao kernel confiável rodando no modo supervisor. Esse mecanismo constrói uma barreira de segurança reforçada por hardware, mais robusta e fácil de verificar do que o modelo de sandbox puramente de software da EVM.

A visão de Vitalik

Essa transformação é planejada como um processo gradual e em múltiplas fases, para garantir estabilidade do sistema e compatibilidade retroativa. Como Vitalik Buterin explicou, essa abordagem busca uma evolução “evolutiva”, não uma revolução completa.

Primeiro passo: substituição dos pré-compilados

A fase inicial adota a abordagem mais conservadora, introduzindo funcionalidades limitadas da nova VM. Como Vitalik Buterin sugere: “Podemos começar usando a nova VM em cenários limitados, como substituir funções pré-compiladas.” Especificamente, isso suspenderá a adição de novos pré-compilados EVM, substituindo-os por programas RISC-V aprovados por whitelist. Esse método permite que a nova VM seja testada em produção com baixo risco, enquanto clientes Ethereum atuam como intermediários entre os dois ambientes de execução.

Segundo passo: coexistência de duas máquinas virtuais

A próxima fase “abre a nova VM diretamente para os usuários”. Contratos inteligentes podem indicar, por marcação, se seu bytecode é EVM ou RISC-V. O recurso chave é a interoperabilidade perfeita: “os dois tipos de contratos podem se chamar mutuamente.” Isso será realizado via chamadas de sistema (ECALL), permitindo que as duas VMs colaborem no mesmo ecossistema.

Terceiro passo: EVM como contrato simulado (estratégia “Rosetta”)

O objetivo final é a máxima simplificação do protocolo. Nesta fase, “a EVM será uma implementação dentro da nova VM”. A EVM padronizada se tornará um contrato inteligente formalmente verificado rodando nativamente no RISC-V L1. Isso garante suporte permanente a aplicações legadas, enquanto permite que desenvolvedores de clientes mantenham apenas um mecanismo de execução simplificado, reduzindo drasticamente a complexidade e o custo de manutenção.

O efeito dominó no ecossistema

A transição da EVM para o RISC-V não é apenas uma mudança no protocolo central, mas terá impacto profundo em todo o ecossistema Ethereum. Essa transformação remodelará a experiência do desenvolvedor, mudará fundamentalmente o cenário competitivo das soluções Layer-2 e desbloqueará novos modelos de validação econômica.

Reposicionamento dos Rollups: Optimistic vs ZK

A adoção do RISC-V na camada de execução do L1 terá impactos distintos nos dois principais tipos de Rollup.

Optimistic Rollups (como Arbitrum, Optimism) enfrentam desafios arquitetônicos. Seu modelo de segurança depende da reexecução de transações contestadas no L1 EVM para resolver provas de fraude. Se a EVM do L1 for substituída, esse modelo colapsa. Esses projetos terão que escolher: ou fazem uma grande reengenharia para criar um sistema de provas de fraude para a nova VM do L1, ou abandonam completamente o modelo de segurança do Ethereum.

Em contraste, ZK Rollups terão uma vantagem estratégica enorme. A maioria dos ZK Rollups já usa RISC-V como sua arquitetura interna de instruções (ISA). Um L1 “falando a mesma língua” permitirá integração mais próxima e eficiente. Justin Drake propõe a visão de “Rollups nativos”: L2s se tornam instâncias especializadas do ambiente de execução do próprio L1, usando a VM embutida do L1 para liquidação perfeita. Esse alinhamento trará as seguintes mudanças:

· Simplificação da stack técnica: Equipes de L2 não precisarão mais construir pontes complexas entre o ambiente de execução RISC-V interno e a EVM.

· Reutilização de ferramentas e código: Compiladores, depuradores e ferramentas de verificação formal desenvolvidos para o ambiente RISC-V do L1 poderão ser usados diretamente no L2, reduzindo drasticamente o custo de desenvolvimento.

· Alinhamento de incentivos econômicos: As taxas de Gas do L1 refletirão com mais precisão o custo real da verificação ZK baseada em RISC-V, criando um modelo econômico mais racional.

Uma nova era para desenvolvedores e usuários

Para os desenvolvedores Ethereum, essa transformação será gradual, não disruptiva.

Para os desenvolvedores, será possível acessar um ecossistema de desenvolvimento de software mais amplo e maduro. Como Vitalik Buterin aponta, os desenvolvedores “poderão escrever contratos em Rust, e essas opções podem coexistir”. Ao mesmo tempo, ele prevê que “Solidity e Vyper continuarão populares por muito tempo devido ao seu design elegante para lógica de contratos inteligentes”. Usar linguagens populares e suas vastas bibliotecas via LLVM será revolucionário. Vitalik compara isso a uma “experiência estilo NodeJS”, onde desenvolvedores podem escrever código on-chain e off-chain na mesma linguagem, unificando o desenvolvimento.

Para os usuários, essa transformação trará custos mais baixos e desempenho superior. Espera-se que o custo de prova caia cerca de 100 vezes, de alguns dólares por transação para alguns centavos ou menos. Isso se traduz diretamente em taxas L1 e custos de liquidação L2 mais baixos. Essa viabilidade econômica abrirá caminho para a visão do “Gigagas L1”, com meta de cerca de 10.000 TPS, preparando o terreno para aplicações on-chain mais complexas e valiosas no futuro.

Succinct Labs e SP1: construindo o futuro das provas agora

O Ethereum está pronto para decolar. “Escalar o L1, escalar o bloco” é uma tarefa estratégica urgente dentro do cluster de protocolos da EF. Espera-se um aumento significativo de desempenho nos próximos 6 a 12 meses.

Equipes como a Succinct Labs já demonstram na prática as vantagens teóricas do RISC-V, tornando seu trabalho um caso poderoso para validar essa proposta.

O SP1, desenvolvido pela Succinct Labs, é um zkVM de alto desempenho e código aberto baseado em RISC-V, que valida a viabilidade da nova abordagem arquitetônica. O SP1 adota a filosofia “precompile-centric”, resolvendo perfeitamente o gargalo criptográfico da EVM. Diferente do método tradicional, que depende de pré-compilados lentos e hardcoded, o SP1 descarrega operações intensivas como o hash Keccak para circuitos ZK especializados e otimizados manualmente, chamados via instrução padrão ECALL. Essa abordagem combina o desempenho de hardware personalizado com a flexibilidade do software, oferecendo aos desenvolvedores uma solução mais eficiente e escalável.

O impacto prático da Succinct Labs já é visível. Seu produto OP Succinct usa o SP1 para dar capacidade de zero-knowledge proof aos Optimistic Rollups (ZK-ify). Como explica Uma Roy, cofundador da Succinct:

“Rollups que usam o OP Stack não precisam mais esperar sete dias para confirmação final e saque... agora, a confirmação leva apenas uma hora. Esse aumento de velocidade é incrível.”

Essa inovação resolve um ponto crítico em todo o ecossistema OP Stack. Além disso, a infraestrutura da Succinct — Succinct Prover Network — foi projetada como um mercado descentralizado de geração de provas, mostrando um modelo econômico viável para a computação verificável do futuro. Seu trabalho não é apenas uma prova de conceito, mas um roteiro prático para o futuro, como descrito neste artigo.

Como o Ethereum reduz riscos

Uma grande vantagem do RISC-V é tornar possível o “cálice sagrado” da verificação formal — provar matematicamente a correção do sistema. A especificação da EVM está escrita em linguagem natural no Yellow Paper, difícil de formalizar. O RISC-V, por outro lado, possui uma especificação SAIL oficial e legível por máquina, fornecendo uma referência “padrão ouro” para seu comportamento.

Isso abre caminho para maior segurança. Como Alex Hicks da Ethereum Foundation aponta, já está em andamento o trabalho de “verificar formalmente os circuitos zkVM RISC-V contra a especificação oficial do RISC-V extraída para Lean”. Esse é um marco que transfere a confiança de implementações humanas propensas a erros para provas matemáticas verificáveis, elevando a segurança do blockchain a um novo patamar.

Principais riscos da transformação

Apesar das muitas vantagens do L1 baseado em RISC-V, ele também traz novos desafios complexos.

Problema de medição de Gas

Criar um modelo de Gas determinístico e justo para uma arquitetura de conjunto de instruções (ISA) genérica é um problema ainda não resolvido. Métodos simples de contagem de instruções são vulneráveis a ataques de negação de serviço. Por exemplo, um atacante pode criar um programa que aciona repetidamente cache misses, consumindo muitos recursos com baixo custo de Gas. Esse problema desafia a estabilidade da rede e o modelo econômico.

Segurança da cadeia de ferramentas e problema de “builds reproduzíveis”

Esse é o risco mais importante e frequentemente subestimado do processo de transformação. O modelo de segurança muda de depender da VM on-chain para depender do compilador off-chain (como LLVM), que é altamente complexo e conhecido por conter bugs. Atacantes podem explorar vulnerabilidades do compilador para transformar código-fonte aparentemente inofensivo em bytecode malicioso. Além disso, garantir que o binário compilado on-chain seja idêntico ao código-fonte público — o problema do “build reproduzível” — é extremamente difícil. Pequenas diferenças no ambiente de build podem gerar binários diferentes, afetando a transparência e a confiança. Esses problemas desafiam seriamente a segurança de desenvolvedores e usuários.

Estratégias de mitigação

O caminho adiante exige estratégias de defesa em múltiplas camadas.

Implementação em fases

Adotar um plano de transição gradual e em múltiplas fases é a principal estratégia para mitigar riscos. Ao introduzir primeiro o RISC-V como substituto dos pré-compilados e depois operar em um ambiente de dupla VM, a comunidade pode ganhar experiência operacional em ambientes de baixo risco, evitando mudanças irreversíveis. Esse método progressivo fornece uma base estável para a transformação técnica.

Auditoria abrangente: fuzzing e verificação formal

Embora a verificação formal seja o objetivo final, ela deve ser combinada com testes contínuos e intensivos. Como Valentine, da Diligence Security, mostrou na chamada Ethproofs, sua ferramenta de fuzzing Argus já encontrou 11 vulnerabilidades críticas de solidez e integridade em zkVMs líderes. Isso mostra que mesmo sistemas bem projetados podem ter falhas só detectáveis por testes adversariais rigorosos. A combinação de fuzzing e verificação formal oferece uma segurança mais forte ao sistema.

Padronização

Para evitar a fragmentação do ecossistema, a comunidade deve adotar uma configuração única e padronizada do RISC-V. Provavelmente será a combinação RV64GC com ABI compatível com Linux, pois essa combinação tem o suporte mais amplo em linguagens e ferramentas populares, maximizando as vantagens do novo ecossistema. A padronização não só aumenta a eficiência dos desenvolvedores, mas também estabelece uma base sólida para o desenvolvimento de longo prazo do ecossistema.

O futuro verificável do Ethereum

A proposta de substituir a Ethereum Virtual Machine (EVM) pelo RISC-V não é apenas uma atualização incremental, mas uma reconstrução fundamental da camada de execução do Ethereum. Essa visão ambiciosa busca resolver gargalos profundos de escalabilidade, simplificar a complexidade do protocolo e alinhar a plataforma com o ecossistema mais amplo da computação geral. Apesar dos enormes desafios técnicos e sociais, os benefícios estratégicos de longo prazo justificam esse esforço ousado.

Essa transformação foca em uma série de trade-offs centrais:

· O enorme ganho de desempenho da arquitetura ZK nativa versus a necessidade urgente de compatibilidade retroativa;

· As vantagens de segurança da simplificação do protocolo versus a inércia do efeito de rede massivo da EVM;

· O poder do ecossistema universal versus o risco de depender de cadeias de ferramentas de terceiros complexas.

No fim, essa transformação arquitetônica será fundamental para cumprir a promessa de “Lean Execution” e é parte essencial da visão do “Lean Ethereum”. Ela transforma o L1 do Ethereum de uma simples plataforma de contratos inteligentes para uma camada eficiente e segura de liquidação e disponibilidade de dados, projetada para suportar o vasto universo da computação verificável.

Como disse Vitalik Buterin, “o objetivo final é... fornecer ZK-snark para tudo.”

Projetos como Ethproofs fornecem dados objetivos e uma plataforma colaborativa para essa transformação, enquanto a equipe da Succinct Labs, com a aplicação prática do SP1 zkVM, oferece um roteiro operacional para esse futuro. Ao adotar o RISC-V, o Ethereum não só resolve seu próprio gargalo de escalabilidade, mas também se posiciona como a camada fundamental de confiança da próxima geração da internet — impulsionada pelo terceiro grande primitivo criptográfico após hash e assinatura: o SNARK.

Prove o software do mundo, inaugure uma nova era cripto.

Saiba mais: