Original Title: Goodbye EVM, Hello RISC-V
Original Author: jaehaerys.eth, crypto researcher
Original Translation: Deep Tide TechFlow
Summary
Ethereum is preparing for its most significant architectural transformation since its inception: replacing the EVM with RISC-V.
The reason is simple— in a zero-knowledge (ZK) centered future, the EVM has become a performance bottleneck:
· Current zkEVM relies on interpreters, leading to 50–800 times performance slowdown;
· Precompiled modules make the protocol complex and increase risks;
· The 256-bit stack design is extremely inefficient when generating proofs.
The Solutions of RISC-V:
· Minimalist Design (about 47 base instructions) + Mature LLVM Ecosystem (supports languages like Rust, C++, Go);
· Has become the de facto standard for zkVM (90% of projects adopt it);
· Features a formal SAIL specification (compared to the ambiguous Yellow Paper) → enables rigorous verification;
· Hardware proof paths (ASICs/FPGAs) are already being tested (SP1, Nervos, Cartesi, etc.).
The migration process is divided into three phases:
· Replace RISC-V as precompiled modules (low-risk testing);
· Dual Virtual Machine Era: EVM and RISC-V coexist and are fully interoperable;
· Reimplementing the EVM within RISC-V (Rosetta Strategy).
Ecosystem Impact:
· Optimistic Rollups (like Arbitrum and Optimism) need to rebuild fraud-proof mechanisms;
· Zero-knowledge Rollups (like Polygon, zkSync, Scroll) will gain huge advantages → cheaper, faster, simpler;
· Developers can directly use libraries in languages such as Rust, Go, and Python at the L1 layer;
· Users will enjoy about 100 times lower proof costs → Leading to Gigagas L1 (approximately 10,000 TPS).
Ultimately, Ethereum will evolve from a 'smart contract virtual machine' to a minimalist, verifiable trust layer for the internet, with the ultimate goal of 'Snarkifying everything.'
Ethereum’s Crossroads
Vitalik Buterin once said: 'The endpoint includes… Snarkifying everything.'
The endgame of zero-knowledge proofs (ZK) is inevitable, and its core argument is simple: Ethereum is rebuilding itself from the ground up based on zero-knowledge proofs. This marks the technical endpoint of the protocol—achieving its ultimate form through the reconstruction of L1, powered by high-performance zkVM supported by core development teams like Succinct.
With this vision as the endpoint, Ethereum stands at the most significant architectural transformation since its inception. This discussion is no longer about gradual upgrades but about a comprehensive reconstruction of its computational core—replacing the Ethereum Virtual Machine (EVM). This initiative is a cornerstone of the broader vision of 'Lean Ethereum.'
The vision of Lean Ethereum aims to systematically simplify the entire protocol by breaking it down into three core modules: Lean Consensus, Lean Data, and Lean Execution. In the core issue of Lean Execution, the most critical question is: has the EVM become the main bottleneck for Ethereum's future development as the engine driving the smart contract revolution?
As Justin Drake from the Ethereum Foundation said, Ethereum's long-term goal has always been to 'Snarkify everything,' which is a powerful tool that enhances all layers of the protocol. However, for a long time, this goal seemed more like a 'distant blueprint' because achieving it requires the concept of real-time proving. Now, as real-time proving gradually becomes a reality, the theoretical inefficiency of the EVM has transformed into an urgent practical problem.
This article will delve into the technical and strategic arguments for migrating Ethereum L1 to the RISC-V Instruction Set Architecture (ISA). This move is expected to unleash unprecedented scalability, simplify protocol structure, and align Ethereum with the future of verifiable computing.
What exactly has changed?
Before discussing 'why,' it's essential to clarify 'what' is changing.
The EVM (Ethereum Virtual Machine) is the execution environment for Ethereum smart contracts, known as the 'world computer' that processes transactions and updates the blockchain state. For years, its design has been revolutionary, laying the groundwork for the emergence of decentralized finance (DeFi) and the NFT ecosystem. However, this custom architecture from nearly a decade ago has now accumulated significant technical debt.
In contrast, RISC-V is not a product but an open standard—a free, universal processor design 'alphabet.' As Jeremy Bruestle emphasized at the Ethproofs conference, its key principles make it an excellent choice for this role:
· Minimalism: The base instruction set of RISC-V is extremely simple, containing only about 40 to 47 instructions. As Jeremy stated, this makes it ‘almost perfect for the use case of our super minimalist general-purpose machine.’
· Modular design: More complex functionalities can be added through optional extensions. This feature is crucial as it allows the core to remain simple while expanding functionality according to demand, without imposing unnecessary complexity on the underlying protocol.
· Open Ecosystem: RISC-V has a large and mature toolchain support, including the LLVM compiler, enabling developers to use mainstream programming languages such as Rust, C++, and Go. As Justin Drake mentioned, 'The tools around the compiler are very rich, while building the compiler is extremely difficult… thus, having these compiler toolchains is of high value.' RISC-V allows Ethereum to inherit these ready-made tools for free.
Interpreter Overhead Issues
The reason for replacing the EVM is not due to a single defect, but rather the convergence of multiple fundamental limitations that can no longer be ignored in the context of a zero-knowledge proof-centric future. These limitations include performance bottlenecks in zero-knowledge proof systems and the risks brought about by the ever-increasing complexity accumulated within the protocol.
The most pressing driver for this transformation is the inherent inefficiency of the EVM in zero-knowledge proof systems. As Ethereum gradually shifts to a model of verifying L1 states through ZK proofs, the performance of provers becomes the biggest bottleneck.
The problem lies in the way the current zkEVM operates. They do not directly prove the EVM but rather prove the interpreter of the EVM, which itself is compiled into RISC-V. Vitalik Buterin has pointed out this core issue bluntly:
‘... If the implementation of zkVM compiles the execution of EVM into content that ultimately becomes RISC-V code, why not expose the underlying RISC-V directly to smart contract developers? This can completely eliminate the overhead of the entire outer virtual machine.’
This additional layer of explanation brings significant performance losses. Estimates indicate that this layer may lead to a performance drop of 50 to 800 times compared to proving native programs. After optimizing other bottlenecks (such as switching to the Poseidon hashing algorithm), this part of 'block execution' still occupies 80-90% of all proof time, making the EVM the ultimate and most challenging obstacle to scaling L1. By removing this layer, Vitalik expects execution efficiency to improve by 100 times.
The Trap of Technical Debt
To compensate for the performance shortcomings of the EVM in certain cryptographic operations, Ethereum introduced precompiled contracts—specialized functions hardcoded into the protocol. While this solution seemed pragmatic at the time, it has now led to what Vitalik Buterin calls a 'bad' situation:
‘Precompiles have been disastrous for us… they have greatly expanded Ethereum's trusted code base… and they have led to several severe issues where we nearly faced consensus failures.’
This complexity is staggering. Vitalik illustrated that the wrapping code for a single precompiled contract (like modexp) is more complex than the entire RISC-V interpreter, while the logic of the precompiled contract is actually more cumbersome. Adding new precompiled contracts requires going through a slow and politically contentious hard fork process, severely hindering application innovation that requires new cryptographic primitives. In this regard, Vitalik reached a clear conclusion:
‘I think we should stop adding any new precompiled contracts starting today.’
Technical Debt of Ethereum's Architecture
The core design of the EVM reflects the priorities of a bygone era, but it is no longer suitable for modern computing needs. The EVM chose a 256-bit architecture to handle cryptographic values, but this architecture is highly inefficient for the 32-bit or 64-bit integers commonly used in smart contracts. This inefficiency is particularly costly in ZK systems. As Vitalik explained:
‘When using smaller numbers, each number doesn't actually save any resources, while complexity increases two to four times.’
Moreover, the stack architecture of the EVM is less efficient than the register architectures of RISC-V and modern CPUs. It requires more instructions to perform the same operations, complicating compiler optimizations.
These issues—including the performance bottlenecks of ZK proofs, the complexity of precompiled contracts, and outdated architectural choices—together form a compelling and urgent reason: Ethereum must move beyond the EVM and embrace a technology architecture better suited for the future.
RISC-V Blueprint: Reshaping Ethereum's Future with a Stronger Foundation
The advantages of RISC-V lie not only in the shortcomings of the EVM but also in the inherent strength of its design philosophy. Its architecture provides a robust, simple, and verifiable foundation, making it well-suited for high-risk environments like Ethereum.
Why open standards are superior to customized designs?
Unlike customized instruction set architectures (ISAs) that require building an entire software ecosystem from scratch, RISC-V is a mature open standard with three key advantages:
Mature Ecosystem
By adopting RISC-V, Ethereum can leverage decades of collective progress in the field of computer science. As Justin Drake explained, this gives Ethereum the opportunity to directly use world-class tools:
‘There is an infrastructure component called LLVM, which is a compiler toolchain that allows you to compile high-level programming languages into one of several backend targets. One of the supported backends is RISC-V. So if you support RISC-V, you automatically support all high-level languages that LLVM supports.’
This significantly lowers the development barrier, allowing millions of developers familiar with languages like Rust, C++, and Go to easily get started.
The minimalist design philosophy of RISC-V is a deliberate feature, not a limitation. Its base instruction set contains only about 47 instructions, keeping the core of the virtual machine extremely simple. This simplicity has significant advantages in terms of security, as a smaller trusted code base is easier to audit and formally verify.
The de facto standard in the field of zero-knowledge proofs. More importantly, the zkVM ecosystem has made a choice. As Justin Drake pointed out, the Ethproofs data shows a clear trend:
‘RISC-V is the leading instruction set architecture (ISA) for zkVM backends.’
Among the ten zkVMs capable of proving Ethereum blocks, nine have chosen RISC-V as their target architecture. This market convergence sends a strong signal: Ethereum's adoption of RISC-V is not a speculative attempt but aligns with a standard that has already been practically validated and recognized by projects building its zero-knowledge future.
Born for trust, not just execution
In addition to a broad ecosystem, the internal architecture of RISC-V is particularly well-suited for building secure and verifiable systems. First, RISC-V has a formalized, machine-readable specification—SAIL. This is a significant improvement compared to the EVM's specification (which primarily exists in text form in the Yellow Paper), which has some ambiguity. The SAIL specification provides a 'gold standard' that supports key mathematical correctness proofs, crucial for protecting valuable protocols. As Alex Hicks from the Ethereum Foundation mentioned at the Ethproofs conference, this allows zkVM circuits to be directly 'verified against the official RISC-V specification.' Second, RISC-V includes a privileged architecture, a feature often overlooked but vital for security. It defines different levels of operation, primarily including user mode (for untrusted applications like smart contracts) and supervisor mode (for trusted 'execution kernels'). Diego from Cartesi elaborated on this:
‘The operating system itself must protect itself from the influence of other code. It needs to isolate different programs from each other, and all these mechanisms are part of the RISC-V standard.’
In the RISC-V architecture, smart contracts running in user mode cannot directly access the state of the blockchain. Instead, they need to make a request to a trusted kernel running in supervisor mode via a special ECALL (environment call) instruction. This mechanism establishes a hardware-enforced security boundary, which is more robust and easier to verify than the EVM's model that relies purely on software sandboxing.
Vitalik’s Vision
This transformation is envisioned as a gradual, multi-phased process to ensure system stability and backward compatibility. As Ethereum founder Vitalik Buterin articulated, this approach aims for 'evolutionary' development rather than a radical 'revolutionary' change.
Step 1: Precompile Alternatives
In the initial phase, a conservative approach will be taken, introducing limited functionalities of the new virtual machine (VM). As Vitalik Buterin suggested, 'We can start using the new VM in limited scenarios, such as replacing precompiled functions.' Specifically, this will pause the addition of new EVM precompiled functions, replacing them with required functionalities implemented by whitelisted RISC-V programs. This approach allows the new VM to undergo practical testing in the mainnet in a low-risk environment while serving as an intermediary between the two execution environments through the Ethereum client.
Step 2: Dual Virtual Machine Coexistence
The next phase will 'open the new VM directly to users.' Smart contracts can indicate through tags whether their bytecode is EVM or RISC-V. A key feature is achieving seamless interoperability: 'Contracts of both types can call each other.' This functionality will be realized through system calls (ECALL), enabling both virtual machines to cooperate within the same ecosystem.
Step 3: EVM as a Simulated Contract ('Rosetta' Strategy)
The ultimate goal is to achieve a simplification of the protocol. At this stage, 'we will treat the EVM as one implementation in the new VM.' The standardized EVM will become formally verified smart contracts running on native RISC-V L1. This not only ensures permanent support for legacy applications but also allows client developers to maintain a single simplified execution engine, significantly reducing complexity and maintenance costs.
Ripple Effects in the Ecosystem
The transition from EVM to RISC-V is not just a transformation of the core protocol; it will have a profound impact on the entire Ethereum ecosystem. This shift will not only reshape developer experience but will fundamentally change the competitive landscape of Layer-2 solutions and unlock new economic verification models.
Repositioning of Rollups: The Duel of Optimistic and ZK
Adopting RISC-V at the L1 layer will have starkly different impacts on the two main types of Rollups.
Optimistic Rollups (like Arbitrum, Optimism) face architectural challenges. Their security models rely on resolving fraud proofs by re-executing disputed transactions through L1 EVM. If the L1 EVM is replaced, this model will collapse entirely. These projects will face tough choices: either undertake significant engineering overhauls to design a fraud-proof system targeting the new L1 VM or completely detach from Ethereum's security model.
In contrast, ZK Rollups will gain a significant strategic advantage. The vast majority of ZK Rollups have already adopted RISC-V as their internal instruction set architecture (ISA). An L1 that 'speaks the same language' will enable tighter and more efficient integration. Justin Drake proposed the future vision of 'native Rollups': L2 effectively becomes a specialized instance of L1's execution environment, achieving seamless settlement using L1's built-in VM. This alignment will bring the following changes:
· Simplification of the tech stack: L2 teams will no longer need to build complex bridging mechanisms between the internal RISC-V execution environment and the EVM.
· Tool and Code Reuse: Compilers, debuggers, and formal verification tools developed for the L1 RISC-V environment can be directly used by L2, significantly reducing development costs.
· Economic incentives alignment: L1's gas fees will more accurately reflect the actual costs of ZK verification based on RISC-V, leading to a more rational economic model.
A New Era for Developers and Users
For Ethereum developers, this transformation will be gradual rather than disruptive.
For developers, they will have access to a broader and more mature software development ecosystem. As Vitalik Buterin pointed out, developers will 'be able to write contracts in Rust, while these options can coexist.' Meanwhile, he predicts that 'Solidity and Vyper will still be popular for a long time due to their elegant design in smart contract logic.' This shift will be revolutionary, allowing the use of mainstream programming languages and their vast library resources through the LLVM toolchain. Vitalik likens it to a 'NodeJS-like experience,' where developers can write both on-chain and off-chain code in the same language, achieving an integrated development experience.
For users, this transformation will ultimately provide a network experience with lower costs and higher performance. The cost of proof is expected to decrease by about 100 times, from several dollars per transaction to a few cents or even less. This translates directly to lower L1 fees and L2 settlement costs. This economic viability will unlock the vision of 'Gigagas L1,' aiming for a performance of approximately 10,000 TPS, paving the way for more complex and higher-value on-chain applications in the future.
Succinct Labs and SP1: Building the Proof of the Future Now
Ethereum is gearing up. 'Scaling L1, scaling blocks' is a strategic imperative within the EF protocol cluster. Significant performance improvements are expected in the next 6 to 12 months.
https://blog.ethereum.org/2025/07/31/lean-ethereum
Teams like Succinct Labs have already demonstrated the theoretical advantages of RISC-V in practice, and their work serves as a strong case for validating this proposal.
SP1 developed by Succinct Labs is a high-performance, open-source zkVM based on RISC-V, validating the feasibility of the new architectural approach. SP1 adopts a 'precompile-centric' philosophy, perfectly addressing the cryptographic bottlenecks of the EVM. Unlike traditional methods that rely on slow, hardcoded precompiles, SP1 offloads intensive operations like Keccak hashing to specially designed, manually optimized ZK circuits, called through standard ECALL instructions. This approach combines the performance of custom hardware with the flexibility of software, providing developers with a more efficient and scalable solution.
The practical impact of Succinct Labs has already become evident. Their OP Succinct product endows Optimistic Rollups with zero-knowledge proof capabilities (ZK-ify) using SP1. As Uma Roy, co-founder of Succinct, explained:
‘With Rollups using the OP Stack, you no longer have to wait seven days for final confirmation and withdrawals… now it only takes an hour for confirmation. This speed increase is fantastic.’
This breakthrough resolves a critical pain point for the entire OP Stack ecosystem. Moreover, Succinct's infrastructure—the Succinct Prover Network—has been designed as a decentralized proof generation market, showcasing a viable economic model for the future of verifiable computing. Their work is not only a proof of concept but also a practical blueprint for the future, as described in this article.
How Ethereum Reduces Risk
One of RISC-V's significant advantages is that it makes the holy grail of formal verification—proving the correctness of systems through mathematical proof—an achievable goal. The specifications of the EVM are written in natural language in the Yellow Paper, making formalization difficult. RISC-V, however, has an official, machine-readable SAIL specification that provides a clear 'golden reference' for its behavior.
This paves the way for stronger security. As Alex Hicks from the Ethereum Foundation pointed out, work is already underway to 'formalize verify zkVM RISC-V circuits against the official RISC-V specification in Lean.' This is a milestone progress that shifts trust from error-prone human implementations to verifiable mathematical proofs, opening new heights for blockchain security.
The main risks of the transformation
Although the L1 architecture of RISC-V has many advantages, it also brings new complexities and challenges.
Gas Measurement Issues
Creating a deterministic and fair Gas model for general instruction set architectures (ISAs) is an unresolved challenge. Simple instruction counting methods are vulnerable to denial-of-service attacks. For example, an attacker could design a program that repeatedly triggers cache misses, causing high resource consumption at extremely low Gas costs. This issue poses severe challenges to network stability and economic models.
Toolchain Security and 'Reproducible Builds' Issues
This is the most critical and often underestimated risk during the transformation process. The security model shifts from relying on the on-chain virtual machine to depending on off-chain compilers (like LLVM), which are highly complex and known to contain vulnerabilities. Attackers may exploit compiler vulnerabilities to transform seemingly harmless source code into malicious bytecode. Additionally, ensuring that the on-chain compiled binary matches the public source code exactly, the 'reproducible build' problem, is also extremely challenging. Small differences in the build environment can lead to different binaries, affecting transparency and trust. These issues pose a severe challenge to the security of developers and users.
Mitigation Strategies
The path forward requires multi-layered defense strategies.
Phased Rollout
Adopting a gradual, multi-phase transition plan is a core strategy for managing risk. By first introducing RISC-V as a precompiled alternative and then operating in a dual virtual machine environment, the community can accumulate operational experience and build confidence in a low-risk setting, avoiding any irreversible changes. This gradual approach provides a stable foundation for the technical transformation.
Comprehensive Auditing: Fuzz Testing and Formal Verification
While formal verification is the ultimate goal, it must be combined with ongoing, high-intensity testing. As Valentine from Diligence Security demonstrated during the Ethproofs conference, their Argus fuzzing tool has already identified 11 critical soundness and integrity vulnerabilities in leading zkVMs. This shows that even the best-designed systems may have vulnerabilities that can only be discovered through rigorous adversarial testing. The combination of fuzzing and formal verification provides stronger assurance for system security.
Standardization
To avoid fragmentation of the ecosystem, the community needs to adopt a single, standardized RISC-V configuration. This could be a combination of RV64GC and the Linux-compatible ABI, as this combination has the broadest support in mainstream programming languages and tools, maximizing the advantages of the new ecosystem. Standardization not only enhances developer efficiency but also lays a solid foundation for the long-term development of the ecosystem.
Ethereum’s Verifiable Future
The proposal to replace the Ethereum Virtual Machine (EVM) with RISC-V is not just a gradual upgrade but a fundamental restructuring of Ethereum's execution layer. This ambitious vision aims to address deep-rooted scalability bottlenecks, simplify protocol complexity, and align the platform with a broader ecosystem in general computing. Despite the enormous technical and social challenges this transformation faces, its long-term strategic benefits are sufficient to justify this bold effort.
This transformation focuses on a series of core trade-offs:
· Balancing the enormous performance gains brought by the ZK-native architecture with the urgent need for backward compatibility;
· Balancing the security advantages of a simplified protocol with the inertia of the EVM's massive network effects;
· The trade-off between the powerful capabilities of a general ecosystem and the risks of relying on complex third-party toolchains.
Ultimately, this architectural transformation will be key to realizing the commitment to 'Lean Execution' and is an essential component of the 'Lean Ethereum' vision. It will transform Ethereum’s L1 from a simple smart contract platform into a highly efficient and secure settlement and data availability layer, designed to support a vast universe of verifiable computing.
As Vitalik Buterin stated, 'The endpoint is... providing ZK-snark for everything.'
Projects like Ethproofs provide objective data and collaborative platforms for this transformation, while the Succinct Labs team provides an actionable blueprint for this future through the practical applications of its SP1 zkVM. By embracing RISC-V, Ethereum not only addresses its scalability bottlenecks but also positions itself as the foundational trust layer for the next generation of the internet—powered by the third major cryptographic primitive after hashes and signatures: SNARK.
Proving the world’s software, opening a new era of encryption.