Written by: jaehaerys.eth
Compiled by: Glendon, Techub News
TL;DR
Ethereum is undergoing the most significant architectural transformation since its inception: replacing the Ethereum Virtual Machine (EVM) with RISC-V. The fundamental reason driving this change is that, in the zero-knowledge proof (ZK) era, the EVM has become the biggest bottleneck.
The current zkEVM relies on interpreter execution, leading to a speed reduction of 50-800 times;
Precompiled contracts make the protocol overly complex and increase risk;
The 256-bit stack design is extremely inefficient in proofs.
RISC-V Can Solve These Problems:
Minimalism (about 47 base instructions) + a mature LLVM ecosystem (supporting Rust, C++, Go);
Has become the de facto standard for zkVM (90% of projects adopt it);
Formal SAIL specification (as opposed to the ambiguous Yellow Paper) can support rigorous validation;
Hardware proof paths (ASIC/FPGA) are already under testing (SP1, Nervos, Cartesi).
The migration will happen in three stages:
RISC-V as a Precompiled Contract Alternative (Low-Risk Testing);
Dual Virtual Machine Era: EVM + RISC-V have full interoperability;
EVM is reimplemented internally in RISC-V (similar to the Rosetta strategy).
Ecosystem Impact:
Optimistic Rollups are unaffected; the RISC-V mainnet won't eliminate fraud proofs, and existing proof programs can be compiled to adapt to RISC-V (currently based on MIPS); Migration Path: Extend current error-proofing infrastructure to target RISC-V rather than completely redesigning the system;
ZK Rollups will greatly benefit (Polygon, zkSync, Scroll → cheaper, faster, simpler);
Developers can directly use Rust/Go/Python libraries on L1;
Users can expect about 100 times cheaper proof costs, paving the way for Gigagas-level (approximately 10k TPS) L1.
Ultimately, Ethereum will evolve from an 'intelligent contract virtual machine' to a minimal, verifiable internet trust layer, with the ultimate goal being: 'Everything is ZK-Snarkified.'
Ethereum is at a crossroads
With the ultimate goal of 'ZK-Snarkifying everything' in mind, Ethereum is now at the threshold of its most important architectural evolution since its inception. This discussion has shifted from gradual upgrades to a fundamental reconstruction of its computational core—namely, the replacement of the Ethereum Virtual Machine (EVM). This initiative is the cornerstone of the broader vision of 'Lean Ethereum,' which aims to systematically simplify the entire protocol, breaking it down into three core components: Lean Consensus, Lean Data, and Lean Execution. The core issue of Lean Execution is whether the EVM, as the engine of the smart contract revolution, has now become the primary bottleneck for Ethereum's future development.
As Justin Drake from the Ethereum Foundation stated, Ethereum's long-term goal has always been 'to Snark everything,' which is a powerful tool for enhancing the various layers of the protocol. However, for a long time, this goal seemed more like a 'pipe dream' because achieving it requires real-time proofs of that concept. Today, as real-time proofs gradually become a reality, the theoretical inefficiency of EVM has transformed into an urgent practical problem.
This analysis will explore the technical and strategic arguments for Ethereum's migration to the RISC-V instruction set architecture (ISA), which promises to unleash unprecedented scalability, simplify protocol structures, and align Ethereum with the future of verifiable computing.
What Exactly Has Changed?
Before delving into the 'why,' it's essential to understand 'what' is changing.
EVM is the runtime environment for Ethereum smart contracts, serving as the 'world computer' that processes transactions and updates the blockchain state. For years, its design has been revolutionary, creating a permissionless platform and giving rise to the entire DeFi and NFT ecosystems. However, this nearly decade-old custom architecture has now accumulated heavy technical debt.
In contrast, RISC-V is not a product but an open standard—a free, general-purpose processor design 'alphabet.' As Jeremy Bruestle emphasized in the Ethproofs call, its key principles make it the best choice for this role:
Minimalism: The base instruction set is extremely concise, containing only about 40-47 instructions. Jeremy describes it as 'almost a perfect use case for the ultra-lean general-purpose machine we need.'
Modularity: Adding more complex functions through optional extensions. This is vital because it allows for a simple core that can be expanded on demand without imposing unnecessary complexity on the foundational protocol;
Open Ecosystem: It has a vast and mature toolchain support, including the LLVM compiler, allowing developers to use mainstream languages like Rust, C++, and Go. As Justin Drake said: 'There are many compiler-related tools, and building compilers is extremely difficult... therefore, having these compiler tools is incredibly valuable.' RISC-V enables Ethereum to inherit these ready-made tools for free.
Interpreter Overhead Issues
The necessity of replacing EVM does not stem from a single defect, but rather from a series of fundamental limitations that have become impossible to ignore in the context of a zero-knowledge proof (ZK) native future. These issues encompass severe performance bottlenecks in ZK proof systems, as well as the risks posed by the increasingly complex accumulation within the protocol.
Interpreter Overhead Issues
The most pressing driving force behind this transformation is the inherent inefficiency of EVM in zero-knowledge proof systems. As Ethereum gradually shifts to a model of validating L1 state through ZK proofs, the performance of the provers will become the ultimate bottleneck.
The issue lies with the current operation of zkEVMs. They do not directly apply zero-knowledge proofs to the EVM, but rather prove an interpreter of an EVM that has itself been compiled to RISC-V. Vitalik Buterin sharply pointed out this core issue:
'If the implementation of zkVM is to compile the execution of EVM into what ultimately becomes RISC-V code, then why not open up the underlying RISC-V directly to smart contract developers? This would entirely eliminate the overhead of the outer virtual machine.'
This additional layer of interpretation incurs significant performance losses. Estimates suggest that this layer may lead to a 50 to 800 times decrease in performance compared to proving native programs. Even after optimizing other bottlenecks (such as switching to the Poseidon hashing algorithm), this part of 'block execution' will still consume 80-90% of the proving time, making EVM the ultimate and most stubborn obstacle to scaling L1. If this layer were removed, Vitalik predicts that execution efficiency could improve by 100 times.
The Debt Trap of Precompiled Contracts
To address the performance shortcomings of EVM in specific cryptographic operations, Ethereum introduced precompiled contracts—hardcoding specialized functions directly into the protocol. While this was a pragmatic solution at the time, it has now led to what Vitalik Buterin describes as a 'disastrous' situation:
'Precompiles have been disastrous for us... they have greatly inflated Ethereum's trusted codebase... and on the verge of consensus failure, they have nearly caused us to crash several times.'
Its complexity is astonishing. Vitalik pointed out through a comparison of the wrapper code for a single precompiled contract (modexp) with a complete RISC-V interpreter that the logic of the precompiled contract is actually more complex. New precompiles must undergo a slow and politically charged hard fork process, which severely hinders application innovation that relies on new cryptographic primitives.
Thus, Vitalik reached a strong conclusion: 'I actually think we should immediately stop adding any new precompiled contracts.'
Technical Debt of Ethereum's Architecture
The core design of EVM reflects outdated demands of the era, but it can no longer adapt to modern computing. EVM chose a 256-bit architecture for handling cryptographic values, which is extremely inefficient for the 32-bit or 64-bit integers commonly used in smart contracts. This inefficiency is particularly costly in zero-knowledge proof systems.
As Vitalik explained: 'When using smaller numbers, each number doesn't actually save any resources, and complexity increases by 2 to 4 times.'
In addition, the stack architecture of the EVM is less efficient than the register architecture of RISC-V and modern CPUs. It requires more instructions to perform the same operation, complicating compiler optimization.
These combined factors, including the performance bottlenecks of ZK proofs, the complexities of precompiles, and outdated architectural choices, create a compelling and urgent case for Ethereum to move beyond EVM.
RISC-V Blueprint: Building a Stronger Foundation
The advantages of RISC-V come not only from the shortcomings of EVM but also from its intrinsic advantages rooted in 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 Better Than Custom Designs
Unlike a custom instruction set architecture (ISA) that requires building the entire software ecosystem from scratch, RISC-V is a mature open standard that can provide three key advantages:
Mature Ecosystem
By adopting RISC-V, Ethereum fully leverages decades of collective progress in the field of computer science. As Justin Drake explained, this provides Ethereum with a direct path to using world-class tools: 'There is an infrastructure component called LLVM, which is a compiler toolchain that allows developers to compile high-level programming languages to various backends. RISC-V is one of the supported backends. So if you support RISC-V, you can automatically support all high-level languages supported by LLVM.'
This greatly lowers the barrier to entry for millions of developers familiar with languages like Rust, C, and Go.
Minimalist Design Philosophy
The minimalism of RISC-V is a deliberate feature, not a limitation. Its base instruction set contains only about 47 instructions, making the core of the virtual machine extremely concise. This simplicity is a tremendous advantage for security, as a smaller trusted codebase is easier to audit and formally verify.
The de facto standard in the ZK realm
More importantly, the zkVM ecosystem has already made autonomous choices. As Justin Drake emphasized, a clear trend can be seen from Ethproofs data: 'RISC-V is the leading ISA for zkVM backends.'
Among the 10 zkVMs capable of proving Ethereum blocks, 9 have chosen RISC-V as their target architecture. This market convergence sends a powerful signal: Ethereum's adoption of RISC-V is not a speculative attempt, but rather a following of a market-validated standard.
Designed for Trust, Not Just Execution
Beyond the ecosystem, the internal architecture of RISC-V is also particularly well-suited for building secure and verifiable systems.
First, RISC-V has an official, machine-readable specification called SAIL. This represents a significant improvement over the Ethereum Virtual Machine (EVM) specification, which primarily exists in document form (the yellow paper) and may contain ambiguities. The SAIL specification provides a 'gold standard' that can offer mathematical proofs critical to protocol correctness, which is essential for protecting valuable protocols. As Alex Hicks from the Ethereum Foundation pointed out in the Ethproofs call, this allows zkVM circuits to be verified 'according to the official RISC-V specification.'
Secondly, RISC-V includes a privileged architecture, a feature often overlooked but critical for security. It defines different operational levels, mainly including user mode (for untrusted applications like smart contracts) and supervisor mode (for trusted 'execution kernels').
In the RISC-V model, smart contracts running in user mode cannot directly access the blockchain's state. Instead, they must issue requests to a trusted kernel running in supervisor mode through special ECALL (environment call) instructions. This mechanism builds a hardware-enforced security boundary that is much more robust and easier to verify than a purely software-based EVM sandbox model.
Vitalik's Vision
This transformation is envisioned as a gradual, multi-stage process to ensure system stability and backward compatibility. The approach outlined by Vitalik Buterin aims for incremental development rather than revolutionary change.
Step One: Precompile Replacement
In the initial phase, a conservative approach will be taken to introduce limited functionality of the new virtual machine (VM). As Vitalik suggested, 'We can start using the new virtual machine in limited scenarios, such as replacing precompiled functionality.' This will involve pausing new EVM precompiled functionalities and instead implementing the required features through whitelisted RISC-V programs. This approach allows the new virtual machine to conduct real-world testing in the mainnet under low-risk conditions while the Ethereum client serves as a mediator between the two execution environments.
Step Two: Coexistence of Dual Virtual Machines
The next stage will 'open the new virtual machine directly to users.' Smart contracts can add a flag upon deployment to indicate whether their bytecode is EVM or RISC-V. A key feature is ensuring seamless interoperability: 'The two types of contracts will be able to call each other.' This will be achieved through system calls (ECALL), with the Ethereum client serving as a mediator for the execution environment.
Step Three: EVM as a Simulated Contract ('Rosetta' Strategy)
The ultimate goal is to achieve the ultimate simplification of the protocol. In this phase, 'we will implement EVM as one implementation of the new virtual machine.' The normative EVM will become a formally verified smart contract running on native RISC-V L1. This not only ensures permanent support for legacy applications but also allows client developers to maintain a single streamlined execution engine.
The Chain Reaction for the Entire Ecosystem
The transition plan from EVM to RISC-V goes far beyond the core protocol; it will have profound impacts on the entire Ethereum ecosystem, likely reshaping the developer experience, fundamentally changing the competitive landscape of Layer-2 solutions, and opening up new proof economic models.
Reconstructing the Rollup Landscape: The Divergence of Optimistic and ZK Paths
The transition to the RISC-V execution layer on L1 will have drastically different impacts on the two main types of Rollups.
The security model of Optimistic Rollups (like Arbitrum, Optimism) relies on re-executing disputed transactions on Layer-1 to resolve fraud proofs. Even if Ethereum Layer-1 migrates to RISC-V, these systems will not undergo fundamental changes. As one co-founder of Optimism explained: 'If we migrate Ethereum to RISC-V, the Optimistic chain will not be interrupted. You just need to compile the RISC-V virtual machine into the proving program. You also don’t need to use Asterisc. Existing MIPS-based proving systems will also remain intact—you just need to compile the RISC-V virtual machine into MIPS.'
This means that the fraud-proof model remains intact. The adjustments are technical: compiling the new RISC-V virtual machine into the existing infrastructure rather than redesigning the system from scratch. The remaining challenges are engineering details such as gas metering, efficiency, and cost.
In contrast, ZK Rollups will gain a significant strategic advantage. The vast majority of ZK Rollups have already adopted RISC-V as their internal ISA. Using the same native language, L1 can achieve tighter and more efficient integration. Justin Drake described the future vision of 'native Rollups,' where L2 is essentially a specialized instance of L1's own execution environment, achieving seamless settlement using the built-in L1 VM. This integration will lead to the following changes:
Simplifying the Tech Stack: Eliminate the complex bridging between internal RISC-V execution in L2 and EVM;
Implementing Tool and Code Reuse: Compilers, debuggers, and formal verification tools developed for the L1 RISC-V environment can be directly utilized by L2 to reduce development costs.
Coordinating Economic Incentives: The Gas costs on L1 will more accurately reflect the actual costs of ZK proof RISC-V execution, thereby creating a more rational economic model.
A New Era for Developers and Users
For Ethereum ecosystem developers, this transition will be incremental rather than disruptive.
For developers, the key advantage is their ability to enter a broader and more mature software development world. As Vitalik Buterin pointed out, developers will 'be able to write contracts in Rust, and these two languages will begin to coexist.' At the same time, he predicts that 'Solidity and Vyper will remain popular for a long time,' as they have elegantly designed smart contract logic. The ability to use mainstream languages and their rich libraries through the LLVM toolchain will be revolutionary. Vitalik describes it as a 'Node.JS-like experience,' where developers can essentially use the same language to write both on-chain and off-chain code.
For users, the ultimate payoff is a more economical and powerful network. Proving costs are expected to decrease by about 100 times—from several dollars per transaction to a few cents—which will directly translate into lower Layer-1 and Layer-2 settlement fees. This economic feasibility will unlock the 'Gigagas L1' vision, aiming for around 10,000 TPS performance on L1, thereby supporting more complex and higher-value on-chain applications in the future.
Succinct Labs and SP1: The Future of Proofs is Now
The theoretical advantages of RISC-V have been put into practice by teams like Succinct Labs, whose work provides a strong case study for the entire proposal.
SP1, developed by Succinct Labs, is a high-performance, open-source zkVM built on RISC-V, validating the feasibility of the new architectural approach. It adopts a 'centralized precompile' design philosophy that perfectly solves the cryptographic bottleneck issues of EVM. Unlike traditional slow, hardcoded precompilation methods, SP1 offloads intensive operations like Keccak hashing to ZK circuits that are called through standard ECALL instructions and are specially designed and manually optimized. This provides the performance of custom hardware while maintaining the flexibility of software.
The practical impact of the team is becoming clear, with their OP Succinct product leveraging SP1 to achieve the 'ZK-ification' of Optimistic Rollup. As Uma Roy, co-founder of Succinct, explained:
'Your OP Stack Rollup doesn't have to wait 7 days for final confirmation and withdrawal... it can now be done in just 1 hour. This greatly enhances final confirmation speed, which is amazing.'
This addresses a key pain point for the entire OP Stack ecosystem. Additionally, Succinct's infrastructure 'Succinct Prover Network' is designed as a decentralized proof generation market, showcasing a viable economic model for the future of verifiable computing. Their work is not merely a proof of concept, but a feasible future blueprint as described in this article.
How Ethereum Reduces Risk
A key advantage of RISC-V is that it makes the ultimate goal of formal verification—proving the correctness of systems through mathematical proof—a feasible goal. The EVM specification is written in natural language in the Yellow Paper, making formalization extremely difficult. In contrast, RISC-V has an official, machine-readable SAIL specification that provides a clear 'golden reference' for its behavior.
This opens a clear path to stronger security. As Alex Hicks from the Ethereum Foundation pointed out, work is already underway to 'formalize the zkVM RISC-V circuits with the official RISC-V specification into Lean.' This is a milestone progress that shifts trust from error-prone human implementations to verifiable mathematical proofs, achieving breakthroughs in security.
The Major Risks of Transformation
Although the RISC-V architecture for L1 has many advantages, it will also face new complexities and challenges.
Gas Metering Issues: Creating a deterministic and fair Gas model for a general-purpose ISA is one of the hardest challenges to solve. Simple instruction counting methods are vulnerable to denial-of-service attacks. For instance, an attacker could design a program that repeatedly triggers cached programs, achieving high resource usage with extremely low Gas costs.
Toolchain Security and 'Reproducible Builds' Issues: This may be the most important and underestimated risk during the transition process. The security model shifts from trusting the virtual machine on the trust chain to trusting the off-chain compilers (such as LLVM) used by each developer, which are extremely complex and known to contain vulnerabilities. Attackers could exploit compiler vulnerabilities to transform seemingly harmless source code into malicious bytecode. Additionally, ensuring that the compiled binary files on-chain are exactly consistent with specific public source code, i.e., the 'reproducible builds' issue, is also extremely challenging, as subtle differences in the build environment can produce different binaries.
Mitigation Strategies
The way forward requires multi-layered defense strategies.
Phased Rollout: A gradual, multi-phase transition plan is the main risk mitigation strategy. By initially introducing RISC-V as a precompiled alternative and then deploying in a dual virtual machine environment, the community can accumulate operational experience and build confidence in a low-risk environment before any irreversible changes occur.
Comprehensive Auditing: Fuzz testing and formal verification. While formal verification is the ultimate goal, it must be complemented by continuous and intensive testing. As Valentine from Diligence Security demonstrated in the Ethproofs call, their Argus fuzzer has already discovered 11 critical soundness and integrity vulnerabilities in leading zkVMs. This proves that even the most well-designed systems have vulnerabilities that can only be uncovered through rigorous adversarial testing.
Standardization: To avoid fragmentation in the ecosystem, the community must unify around a single, standardized RISC-V profile. This will likely be a combination of RV64 GC and Linux-compatible ABI, as this combination can provide the broadest support from mainstream languages and tools, thereby maximizing the advantages of the new ecosystem.
