Author: jaehaerys.eth
Translation: Glendon, Techub News
TL;DR
Ethereum is undergoing the most significant architectural change since its inception: replacing the Ethereum Virtual Machine (EVM) with RISC-V. The fundamental reason driving this change is that the EVM has become the biggest bottleneck in the era of zero-knowledge proofs (ZK):
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 risks;
The 256-bit stack design is extremely inefficient in proofs.
RISC-V can address these issues:
Minimalism (about 47 basic instructions) + a mature LLVM ecosystem (supporting Rust, C++, Go);
It has become the de facto zkVM standard (90% of projects adopted);
Formal SAIL specifications (compared to the ambiguous yellow paper) can support rigorous verification;
Hardware proof paths (ASIC/FPGA) are already in testing (SP1, Nervos, Cartesi).
The migration is divided into three phases:
RISC-V as a replacement for precompiled contracts (low-risk testing);
Dual virtual machine era: EVM + RISC-V with full interoperability;
EVM re-implemented internally in RISC-V (similar to the Rosetta strategy).
Ecosystem impact:
Optimistic Rollups are unaffected; the RISC-V mainnet will not eliminate fraud proofs, and existing proof programs can be compiled to adapt to RISC-V (currently based on MIPS); migration path: extend the current fault-tolerant infrastructure to the target RISC-V rather than a complete overhaul;
ZK Rollup will benefit significantly (Polygon, zkSync, Scroll → cheaper, faster, simpler);
Developers can directly use Rust/Go/Python libraries on L1;
Users can achieve proof costs that are about 100 times cheaper, paving the way towards Gigagas-level (around 10k TPS) L1.
Ultimately, Ethereum will evolve from a "smart contract virtual machine" into 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 "Everything is ZK-Snarkified" in mind, Ethereum is now at the threshold of its most significant architectural evolution since its inception. This discussion is no longer limited to incremental upgrades but rather a fundamental reconstruction of its computational core—the replacement of the Ethereum Virtual Machine (EVM). This initiative is the cornerstone of the broader "Lean Ethereum" vision, which aims to systematically simplify the entire protocol by breaking it down into three core components: Lean Consensus, Lean Data, and Lean Execution. The core question of Lean Execution is whether the EVM, as the engine of the smart contract revolution, has now become the main bottleneck for Ethereum's future development.
As Justin Drake from the Ethereum Foundation stated, Ethereum's long-term goal has always been to "Snarkify everything," which is a powerful tool that can enhance all layers of the protocol. However, for a long time, this goal seemed more like a "castle in the air," as achieving it required real-time proof of the concept. Now, as real-time proof gradually becomes a reality, the theoretical inefficiency of the EVM has transformed into an urgent practical problem.
This analysis will explore the technical and strategic arguments for Ethereum L1's migration to the RISC-V instruction set architecture (ISA), a move expected to unleash unprecedented scalability, simplify protocol structure, and align Ethereum with the future of verifiable computing.
What Exactly is Changing?
Before delving into the "why," it is essential to understand "what" is changing.
The EVM is the execution environment for Ethereum smart contracts, serving as the "world computer" that processes transactions and updates the blockchain state. Over the years, its design has been revolutionary, creating a permissionless platform and spawning the entire DeFi and NFT ecosystems. However, this custom architecture, nearly a decade old, has now accumulated significant 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 conference call, its key principles make it the ideal choice for this role:
Minimalism: The instruction set is extremely concise, containing only about 40-47 instructions. Jeremy described it as "almost the perfect use case for the ultra-minimal general-purpose machine we need."
Modularity: More complex functions can be added through optional extensions. This is crucial as it allows for a simple core that can be expanded as needed without imposing unnecessary complexity on the base protocol;
Open ecosystem: It has a large and mature toolchain support, including the LLVM compiler, allowing developers to use mainstream languages like Rust, C++, and Go. As Justin Drake stated, "There are many compiler-related tools, and building compilers is extremely difficult… thus, having these compiler tools is of great value." RISC-V allows Ethereum to inherit these ready-made tools for free.
Interpreter Overhead Issue
The necessity to replace the EVM does not stem from a single flaw but 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 and the risks posed by the increasing complexity accumulating within the protocol.
Interpreter Overhead Issue
The most pressing driver for this transformation is the inherent inefficiency of the EVM in zero-knowledge proof systems. As Ethereum gradually shifts towards a model that verifies L1 state through ZK proofs, the performance of the prover will become the ultimate bottleneck.
The problem lies in how the current zkEVM operates. They do not directly perform zero-knowledge proofs on the EVM but rather on an interpreter of the EVM, which itself is compiled to RISC-V. Vitalik Buterin pointed out this core issue succinctly:
"If the implementation of the zkVM is to compile the execution of the EVM into something that ultimately becomes RISC-V code, then why not open up the underlying RISC-V directly to smart contract developers? This would completely eliminate the overhead of the entire outer virtual machine."
This additional layer of interpretation incurs a massive performance loss. Estimates suggest that this layer could lead to a performance drop of 50 to 800 times compared to proof-native programs. Even after optimizing other bottlenecks (such as switching to the Poseidon hashing algorithm), this portion of "block execution" will still consume 80–90% of the proof time, making the 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 EVM's performance shortcomings 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 are disastrous for us… they have greatly inflated Ethereum's trusted codebase… and on the brink of consensus failure, they have nearly caused us to crash several times."
The complexity is staggering. Vitalik pointed out that the wrapping code for a single precompiled contract (modexp) is actually more complex than the complete RISC-V interpreter. New precompiles must undergo a slow and politically fraught hard fork process, severely hindering application innovation that relies on new cryptographic primitives.
As a result, Vitalik reached a firm conclusion: "I actually think we should immediately stop adding any new precompiled contracts."
Architectural Technical Debt of Ethereum
The core design of the EVM reflects outdated demands of its time, but it can no longer adapt to modern computing. The 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. The cost of this inefficiency is particularly high in zero-knowledge proof systems.
As Vitalik explained: "When using smaller numbers, each number does not actually save any resources, while complexity increases by 2 to 4 times."
Additionally, 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, making compiler optimization more complex.
These combined factors, including performance bottlenecks in ZK proofs, the complexity of precompiles, and outdated architectural choices, collectively provide a compelling and urgent reason for Ethereum to move beyond the EVM.
RISC-V Blueprint: Building a Stronger Foundation
The advantages of RISC-V stem not only from the shortcomings of the EVM but also from its inherent 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 Custom Designs
Unlike custom instruction set architectures (ISAs) that require building an entire software ecosystem from scratch, RISC-V is a mature open standard that offers three key advantages:
Mature Ecosystem
By adopting RISC-V, Ethereum fully leverages decades of collective progress in computer science. As Justin Drake explained, this provides Ethereum with a direct pathway to utilize world-class tools: "There is an infrastructure component called LLVM, which is a set of compiler toolchains 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 automatically support all high-level languages that LLVM supports."
This significantly lowers the entry barrier for millions of developers familiar with languages like Rust, C, and Go.
Minimalist Design Philosophy
The minimalism of RISC-V is an intentional feature rather than a limitation. Its basic instruction set contains only about 47 instructions, making the core of the virtual machine extremely simple. 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 Space
More importantly, the zkVM ecosystem has made autonomous choices. As Justin Drake emphasized, a clear trend can be seen from the 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 a follow-up to a market-validated standard.
Designed for Trust, Not Just Execution
Beyond the ecosystem, RISC-V's internal architecture is particularly well-suited for building secure and verifiable systems.
First, RISC-V has a formal, machine-readable specification known as SAIL. This represents a significant improvement over the specification of the Ethereum Virtual Machine (EVM), which primarily exists in documentation (the yellow paper) and may contain ambiguities. The SAIL specification provides a "gold standard" that can offer mathematical proofs critical to the correctness of the protocol, which is essential for protecting valuable protocols. As Alex Hicks from the Ethereum Foundation pointed out in the Ethproofs conference call, this allows zkVM circuits to be verified "according to the official RISC-V specification."
Second, RISC-V includes a privileged architecture, a feature often overlooked but crucial 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").
In the RISC-V model, smart contracts running in user mode cannot directly access the state of the blockchain. 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 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-phase process to ensure system stability and backward compatibility. The approach outlined by Vitalik Buterin aims for incremental development rather than revolutionary change.
Step 1: Precompiled Replacement
The initial phase takes the most conservative approach, introducing 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 functions." This would involve pausing new EVM precompiled functionalities and instead implementing the required functions through whitelisted RISC-V programs. This approach allows the new virtual machine to undergo real-world testing in a low-risk environment while the Ethereum client acts as an intermediary between the two execution environments.
Step 2: Dual Virtual Machine Coexistence
The next phase will "open the new virtual machine directly to users." When deploying smart contracts, a flag can be added to indicate whether their bytecode is EVM or RISC-V. The key feature is to ensure seamless interoperability: "Both types of contracts will be able to call each other." This will be achieved through system calls (ECALL), with the Ethereum client serving as an intermediary for the execution environments.
Step 3: EVM as a Simulated Contract ("Rosetta" Strategy)
The ultimate goal is to achieve the ultimate simplification of the protocol. At this stage, "we will implement the EVM as an implementation of the new virtual machine." The standardized 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 Ripple Effect Across the Ecosystem
The transition plan from EVM to RISC-V extends far beyond the core protocol; it will have profound impacts on the entire Ethereum ecosystem, potentially reshaping the developer experience, fundamentally altering the competitive landscape of Layer-2 solutions, and opening up new proof economic models.
Rollup Landscape Restructuring: Divergence of Optimistic and ZK Paths
The shift to an RISC-V execution layer on L1 will have distinctly different impacts on the two main types of Rollups.
The security model of Optimistic Rollups (like Arbitrum and 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 of the co-founders 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 proof program. There is no need to use Asterisc. Existing MIPS-based proof systems will also remain intact—you just need to compile the RISC-V virtual machine into MIPS."
This means the anti-fraud 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 costs.
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 bring about the following changes:
Simplified technical stack: eliminating the complex bridging between internal RISC-V execution in L2 and EVM;
Enabling tool and code reuse: compilers, debuggers, and formal verification tools developed for the L1 RISC-V environment can be directly used by L2 to reduce development costs.
Coordinated economic incentives: L1's gas fees will more accurately reflect the actual costs of ZK proof RISC-V execution, creating a more rational economic model.
A New Era for Developers and Users
For developers in the Ethereum ecosystem, this transition will be gradual rather than disruptive.
For developers, the key advantage lies in 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 described 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. Proof costs are expected to decrease by about 100 times—from several dollars per transaction to a few cents—directly translating into lower Layer-1 and Layer-2 settlement fees. This economic viability will open up the "Gigagas L1" vision, aiming for performance of around 10,000 TPS on L1, thereby supporting more complex and higher-value on-chain applications in the future.
Succinct Labs and SP1: The Future of Proof 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 that validates the feasibility of the new architectural approach. It adopts a "precompiled centralization" design 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 provides the performance of custom hardware while retaining the flexibility of software.
The practical impact of the team is already evident, as their OP Succinct product utilizes SP1 to achieve the "ZK-ification" of Optimistic Rollup. As Succinct co-founder Uma Roy explained:
"Your OP Stack Rollup no longer needs to wait 7 days for final confirmation and withdrawal… now it only takes 1 hour to complete. This significantly improves the speed of final confirmation, which is fantastic."
This addresses a key pain point for the entire OP Stack ecosystem. Additionally, Succinct's infrastructure, the "Succinct Prover Network," is designed as a decentralized proof generation market, showcasing a viable economic model for the future of verifiable computation. Their work is not just 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 proofs—a realizable objective. The specification of the EVM 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 currently underway to "formalize the 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, achieving breakthroughs in security.
Main Risks of the Transition
Despite the many advantages of the RISC-V architecture on L1, it will also face new complex challenges.
Gas Metering Issues: Creating a deterministic and fair gas model for a general-purpose ISA is one of the most challenging problems to solve. Simple instruction counting methods are vulnerable to denial-of-service attacks. For example, an attacker could design a program that repeatedly triggers cached programs, achieving high resource consumption with very low gas fees.
Toolchain Security and "Reproducible Builds" Issues: This may be the most important and underestimated risk during the transition. The security model shifts from trusting the on-chain virtual machine to trusting the off-chain compilers (like 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 on-chain compiled binaries are exactly consistent with specific public source code—known as the "reproducible builds" problem—is also extremely difficult, as slight differences in the build environment can produce different binaries.
Mitigation Strategies
The path forward requires a multi-layered defense strategy.
Phased Rollout: A gradual, multi-phase transition plan is the primary risk mitigation strategy. By initially introducing RISC-V as a precompiled alternative and then deploying it 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 Audits: Fuzz testing and formal verification. While formal verification is the ultimate goal, it must be supplemented with continuous, high-intensity testing. As Valentine from Diligence Security demonstrated in the Ethproofs conference 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 of the ecosystem, the community must adopt a single, standardized RISC-V profile. This is likely to be a combination of RV64 GC and a Linux-compatible ABI, as this combination can provide the broadest support from mainstream languages and tools, maximizing the advantages of the new ecosystem.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
