Technical debt is overwhelming, and Ethereum chooses to "start over" with RISC-V.

Author: jaehaerys.eth

Compiled by: Shenchao TechFlow

Abstract

Ethereum is preparing for the most significant architectural transformation since its inception: replacing the EVM with RISC-V.

The reason is simple - in a future centered around zero-knowledge (ZK), the EVM has become a performance bottleneck:

• The current zkEVM relies on an interpreter, resulting in a 50–800 times slowdown in performance;
• The precompiled module makes the protocol more complex and increases risks;
• The 256-bit stack design is extremely inefficient when generating proofs.

RISC-V Solutions:

• Minimalist design (about 47 basic instructions) + mature LLVM ecosystem (supports languages such as Rust, C++, Go);
• Has become the de facto zkVM standard (90% of projects adopted);
• Possesses formal SAIL specifications (compared to the ambiguous yellow paper) → Achieves strict verification;
• Hardware proof paths (ASICs/FPGAs) are under testing (SP1, Nervos, Cartesi, etc.).

The migration process is divided into three stages:

1. Replace RISC-V with a precompiled module (low-risk testing);
2. Dual Virtual Machine Era: EVM and RISC-V coexist and are fully interoperable;
3. Reimplement EVM in RISC-V (Rosetta strategy).

Ecosystem Impact:

• Optimistic Rollups (such as Arbitrum and Optimism) need to rebuild the fraud proof mechanism;
• Zero-knowledge Rollups (such as Polygon, zkSync, Scroll) will gain huge advantages → cheaper, faster, simpler;
• Developers can directly use language libraries such as Rust, Go, and Python on the L1 layer;
• Users will enjoy approximately 100 times lower costs for proof → leading to Gigagas L1 (approximately 10,000 TPS).

Ultimately, Ethereum will evolve from a “smart contract virtual machine” to a minimal, verifiable trust layer of the internet, with the ultimate goal of “making everything ZK-Snarked.”

Ethereum Crossroads

Vitalik Buterin once said: “The end goal includes… making everything ZK-Snarked.”

The endgame of zero-knowledge proofs (ZK) is inevitable, and its core argument is quite simple: Ethereum is starting from scratch, rebuilding itself based on zero-knowledge proofs. This marks the technical endpoint of the protocol - achieving its final form through the reconstruction of L1, driven by a high-performance zkVM supported by core development teams such as Succinct.

With this vision as the destination, Ethereum is at the most significant architectural transformation point since its inception. This discussion is no longer about gradual upgrades, but rather a comprehensive reconstruction of its computational core - replacing the Ethereum Virtual Machine (EVM). This initiative is the cornerstone of the broader “Lean Ethereum” vision.

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. Among the core issues of Lean Execution, the most critical point is: Has the EVM, as the engine driving the smart contract revolution, become the main bottleneck for the future development of Ethereum?

As Justin Drake of the Ethereum Foundation stated, Ethereum’s long-term goal has always been to “Snarkify everything,” which is a powerful tool that can enhance the various layers of the protocol. However, for a long time, this goal seemed more like an “elusive blueprint” because achieving it required the concept of real-time proving. Now, as real-time proving gradually becomes a reality, the theoretical inefficiencies of the EVM have turned into a pressing practical issue.

This article will delve into the technical and strategic arguments for migrating Ethereum L1 to the RISC-V instruction set architecture (ISA). This initiative not only promises to unleash unprecedented scalability but also simplifies the protocol structure and aligns Ethereum with the future of verifiable computing.

What changes have actually occurred?

Before exploring the “why”, it is essential to clarify “what” is changing.

EVM (Ethereum Virtual Machine) is the runtime environment for Ethereum smart contracts, referred to as the “world computer” that processes transactions and updates the blockchain state. Over the years, its design has been revolutionary, laying the foundation for the birth of decentralized finance (DeFi) and the NFT ecosystem. However, this custom architecture, nearly a decade old, has now accumulated a significant amount of 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 basic instruction set of RISC-V is extremely simple, containing only about 40 to 47 instructions. As Jeremy said, this makes it “almost perfectly suited for the use case of the super minimalist general-purpose machine we need.”
• Modular design: More complex features are added through optional extensions. This feature is crucial as it allows the core to remain simple while expanding functionality based on demand, without imposing unnecessary complexity on the underlying protocol.
• Open Ecosystem: RISC-V has a large and mature toolchain support, including the LLVM compiler, allowing 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… Therefore, the value of having these compiler toolchains is very high.” RISC-V enables Ethereum to inherit these ready-made tools for free.

interpreter overhead issue

The reasons for promoting the replacement of EVM are not due to a single flaw, but rather a convergence of multiple fundamental limitations that can no longer be ignored in the future context centered around zero-knowledge proofs. These limitations include performance bottlenecks in zero-knowledge proof systems, as well as the risks posed by the increasing complexity accumulated within the protocol.

Interpreter overhead issue

The most pressing driver of this transformation is the inherent inefficiency of EVM in zero-knowledge proof systems. As Ethereum gradually shifts towards a model of validating L1 state through ZK proofs, the performance of provers becomes the biggest bottleneck.

The problem lies in the current working method of zkEVMs. They do not directly provide zero-knowledge proofs for the EVM, but rather for the interpreter of the EVM, which is itself compiled to RISC-V. Vitalik Buterin candidly pointed out this core issue:

“…If the implementation of zkVM is to compile the execution of EVM into content that ultimately becomes RISC-V code, then why not expose 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 explanation brings significant performance loss. Estimates suggest that this layer could lead to a performance decrease 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 EVM the ultimate and most challenging obstacle to scaling L1. By removing this layer, Vitalik expects execution efficiency could improve by 100 times.

Technical Debt Trap

To compensate for the performance shortcomings of EVM in specific cryptographic operations, Ethereum introduced precompiled contracts—specialized functions hardcoded directly into the protocol. While this solution seemed pragmatic at the time, it has now led to what Vitalik Buterin describes as a “bad” situation:

“Precompiles are catastrophic for us… they greatly inflate the trusted codebase of Ethereum… and they have led to several serious issues that nearly caused consensus failures.”

This complexity is shocking. Vitalik illustrated that the wrapper code for a single precompiled contract (like modexp) is more complex than the entire RISC-V interpreter, while the logic of precompilations is actually more cumbersome. Adding new precompiled contracts requires a slow and politically contentious hard fork process, which severely hinders application innovation that needs new cryptographic primitives. In this regard, Vitalik reached a clear conclusion:

“I think we should stop adding any new precompiled contracts starting today.”

Ethereum’s architectural technology debt

The core design of the EVM reflects the priorities of a past era, but it is no longer suitable for modern computational needs. The EVM has opted for a 256-bit architecture to handle cryptographic values, but this architecture is extremely inefficient for the 32-bit or 64-bit integers commonly used in smart contracts. This inefficiency is particularly costly in ZK systems. As explained by Vitalik:

“When using smaller numbers, each digit does not actually save any resources, and the complexity increases by two to four 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 complete the same operation, which also complicates compiler optimization.

These issues—including the performance bottlenecks of ZK proofs, the complexity of precompiles, and outdated architectural choices—collectively 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 the Future of Ethereum with a Stronger Foundation

The advantages of RISC-V lie not only in the shortcomings of EVM but also in the inherent strength of its design philosophy. Its architecture provides a robust, simple, and verifiable foundation, making it very suitable for high-risk environments like Ethereum.

Why are open standards better than custom designs?

Unlike customized instruction set architectures (ISA) that require building an entire software ecosystem from scratch, RISC-V is a mature open standard with the following three key advantages:

Mature Ecosystem

By adopting RISC-V, Ethereum is able to leverage decades of collective progress in the field of computer science. As Justin Drake explains, this provides Ethereum with 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 can automatically support all high-level languages that LLVM supports.”

This greatly lowers the development threshold, allowing millions of developers familiar with languages like Rust, C++, and Go to easily get started.

The minimalist design philosophy of RISC-V is an intentional feature rather than 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 codebase is easier to audit and formally verify.

The factual standard in the field of zero-knowledge proofs is that, more importantly, the zkVM ecosystem has made its choices. As Justin Drake pointed out, a clear trend can be seen from the Ethproofs data:

“RISC-V is the leading instruction set architecture (ISA) for the zkVM backend.”

Among the ten zkVMs capable of proving Ethereum blocks, nine have chosen RISC-V as their target architecture. This market convergence releases a strong signal: Ethereum’s adoption of RISC-V is not a speculative attempt, but rather aligns with a standard recognized by a project that has already been practically validated and built its zero-knowledge future.

is born for trust, not just execution.

In addition to its extensive ecosystem, the internal architecture of RISC-V is particularly 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 specification of the EVM (which primarily exists in textual form in the “Yellow Paper”), as the “Yellow Paper” has certain ambiguities, while the SAIL specification provides a “gold standard” that supports critical mathematical correctness proofs, which are essential for protecting high-value protocols. As Alex Hicks from the Ethereum Foundation (EF) mentioned at the Ethproofs conference, this enables zkVM circuits to be directly “verified against the official RISC-V specification.” Secondly, RISC-V includes a privileged architecture, which is a commonly overlooked but crucial feature for security. It defines different operational levels, mainly including user mode (for untrusted applications, such as smart contracts) and supervisor mode (for trusted “execution kernels”). Diego from Cartesi elaborated on this in depth:

“The operating system itself must protect itself from the influence of other codes. 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 blockchain’s state. Instead, they need to issue a request to a trusted kernel running in Supervisor Mode through a special ECALL (environment call) instruction. This mechanism establishes a security boundary enforced by hardware, which is more robust and easier to verify than the model that purely relies on a software sandbox like the EVM.

Vitalik’s vision

This transformation is envisioned as a gradual, multi-stage process to ensure the stability of the system and backward compatibility. As Ethereum founder Vitalik Buterin has articulated, this approach aims to achieve an “evolutionary” development rather than a complete “revolutionary” change.

Step 1: Precompile Alternative

The initial phase adopts the most conservative approach, introducing a limited functionality for the new virtual machine (VM). As suggested by Vitalik Buterin: “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 through whitelisted RISC-V programs. This approach allows the new VM to conduct practical testing in the mainnet within 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 VM directly to users.” Smart contracts can indicate whether their bytecode is EVM or RISC-V through tags. The key feature is to achieve seamless interoperability: “the two types of contracts are able to call each other.” This functionality will be realized through system calls (ECALL), enabling the two virtual machines to collaborate within the same ecosystem.

Step 3: EVM as a simulated contract (“Rosetta” strategy)

The ultimate goal is to achieve the simplification of the protocol. At this stage, “we will treat the EVM as an implementation within the new VM.” The standardized EVM will become a formally verified smart contract running on the native RISC-V L1. This not only ensures permanent support for legacy applications but also allows client developers to maintain only a simplified execution engine, significantly reducing complexity and maintenance costs.

ripple effect of the ecosystem

The transition from EVM to RISC-V is not just a change in the core protocol; it will have a profound impact on the entire Ethereum ecosystem. This transformation will not only reshape the developer experience but also fundamentally alter the competitive landscape of Layer-2 solutions, unlocking new economic validation models.

The Repositioning of Rollups: The Battle Between Optimistic and ZK

The use of the RISC-V execution layer on the L1 layer will have distinctly different impacts on the two main types of Rollups.

Optimistic Rollups (such as Arbitrum and Optimism) face architectural challenges. Their security model relies on resolving fraudulent proofs by re-executing disputed transactions through the L1 EVM. If the EVM of L1 is replaced, this model will completely collapse. These projects will face a tough choice: either undergo a massive engineering overhaul to design a fraudulent proof system for the new L1 VM, or completely detach from Ethereum’s security model.

In contrast, ZK Rollups will gain significant strategic advantages. 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 essentially becomes a specialized instance of L1’s own execution environment, leveraging L1’s built-in VM for seamless settlement. This alignment will bring about the following changes:

Tech stack simplification: The L2 team 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: The Gas fees of L1 will more accurately reflect the actual costs of RISC-V based ZK verification, thereby forming a more reasonable economic model.

A New Era for Developers and Users

For Ethereum developers, this transition will be gradual rather than disruptive.

For developers, they will be able to access 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 remain popular for a long time due to their elegant design in smart contract logic.” This shift, using mainstream programming languages and their vast library resources through the LLVM toolchain, will be revolutionary. Vitalik likened it to a “NodeJS-like experience,” where developers can write both on-chain and off-chain code in the same language, achieving integration in development.

For users, this transformation will ultimately bring a lower cost and higher performance network experience. The proof costs are expected to decrease by about 100 times, from several dollars per transaction to a few cents or even less. This directly translates to lower L1 fees and L2 settlement costs. This economic feasibility will unlock the vision of “Gigagas L1”, aiming to achieve 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 Proof of the Future Today

Ethereum is gearing up. “Scaling L1, scaling blocks” is a strategic imperative within the EF protocol cluster. Significant performance improvements are expected to be achieved in the next 6 to 12 months.

Teams like Succinct Labs have demonstrated the theoretical advantages of RISC-V in practice, and their work serves as a strong case for validating this proposal.

The SP1 developed by Succinct Labs is a high-performance, open-source zkVM based on RISC-V, which validates the feasibility of the new architectural approach. SP1 adopts a “precompile-centric” philosophy, perfectly addressing the cryptographic bottleneck issues of the EVM. Unlike traditional methods that rely on slow, hard-coded precompiles, SP1 offloads intensive operations like Keccak hashing to specially designed, manually optimized ZK circuits, which are 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 actual impact of Succinct Labs has already become evident. Their OP Succinct product leverages SP1 to give Optimistic Rollups zero-knowledge proof capabilities (ZK-ify). As explained by Succinct co-founder Uma Roy:

“Using Rollup with OP Stack no longer requires a seven-day wait for final confirmation and withdrawal… now it only takes one hour to complete the confirmation. This speed improvement is fantastic.”

This breakthrough addresses a key pain point in the entire OP Stack ecosystem. Additionally, Succinct’s infrastructure—Succinct Prover Network—was designed as a decentralized proof generation marketplace, showcasing a viable economic model for verifiable computing in the future. Their work is not only a proof of concept but also a practical blueprint for the future, as described in this article.

How to reduce risks in Ethereum

One of the major advantages of RISC-V is that it makes the holy grail of formal verification—mathematically proving the correctness of a system—an achievable goal. The specification of the EVM is written in natural language in the Yellow Paper, making it difficult to formalize. In contrast, RISC-V 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 currently underway to “extract the zkVM RISC-V circuit and the official RISC-V specification into Lean for formal verification.” This is a milestone progress that shifts trust from error-prone human implementations to verifiable mathematical proofs, opening new heights for blockchain security.

Main Risks of Transformation

Despite the many advantages of the RISC-V architecture’s L1, it also brings new complexities and challenges.

Gas Metering Issues

Creating a deterministic and fair Gas model for a general-purpose instruction set architecture (ISA) is an unsolved 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, resulting in high resource consumption at a very low Gas cost. This issue poses severe challenges to network stability and economic models.

Toolchain Security and the “Reproducible Build” Issue

This is the most important and often underestimated risk in the transformation process. The security model shifts from relying on on-chain virtual machines to relying on off-chain compilers (like LLVM), which are extremely complex and known to contain vulnerabilities. Attackers may exploit compiler vulnerabilities to transform seemingly harmless source code into malicious bytecode. Furthermore, ensuring that the on-chain compiled binaries match the publicly available source code exactly, known as the “reproducible builds” problem, is also extremely difficult. Minor differences in the build environment can lead to the generation of different binaries, thus affecting transparency and trust. These issues pose significant challenges to the security of developers and users.

Mitigation Strategy

The road ahead requires a multi-layered defense strategy.

Phased Promotion

Adopting a gradual, multi-phase transition plan is a core strategy for managing risks. By initially introducing RISC-V as a pre-compiled alternative and then running it in a dual virtual machine environment, the community can accumulate operational experience and build confidence in a low-risk environment, avoiding any irreversible changes. This incremental approach provides a stable foundation for technological transformation.

Comprehensive Audit: Fuzz Testing and Formal Verification

Although formal verification is the ultimate goal, it must be combined with continuous, high-intensity testing. As demonstrated by Valentine from Diligence Security in the Ethproofs conference call, their Argus fuzzing tool has discovered 11 critical soundness and integrity vulnerabilities in leading zkVMs. This indicates that even the most well-designed systems may have vulnerabilities that can only be revealed 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 an ABI compatible with Linux, as this combination has the broadest support in mainstream programming languages and tools, maximizing the advantages of the new ecosystem. Standardization not only enhances developers’ efficiency but also lays a solid foundation for the long-term development of the ecosystem.

The verifiable future of Ethereum

The proposal to replace the Ethereum Virtual Machine (EVM) with RISC-V is not just a gradual upgrade, but a fundamental restructuring of the Ethereum execution layer. This ambitious vision aims to address deep-rooted scalability bottlenecks, simplify protocol complexity, and align the platform with a broader ecosystem in the field of general-purpose computing. Although this transformation faces enormous technical and social challenges, its long-term strategic benefits are sufficient to justify this bold endeavor.

This transformation focuses on a series of core trade-offs:

• The balance between the significant performance improvements brought by the ZK native architecture and the urgent need for backward compatibility;
• The trade-off between the security advantages brought by simplified protocols and the inertia of the large network effects of EVM;
• The choice between the powerful capabilities of a universal ecosystem and the risks of relying on complex third-party toolchains.

Ultimately, this architectural transformation will be key to fulfilling the commitment to “Lean Execution” and an important component of the vision for “Lean Ethereum.” It will transform Ethereum’s L1 from a simple smart contract platform into an efficient and secure settlement and data availability layer, designed specifically to support the vast universe of verifiable computation.

As Vitalik Buterin said, “The endpoint is… to provide ZK-snark for everything.”

Projects like Ethproofs provide objective data and collaborative platforms for this transformation, while the Succinct Labs team offers an actionable blueprint for this future through the practical application of their SP1 zkVM. By embracing RISC-V, Ethereum not only addresses its own scalability bottlenecks but also positions itself as the foundational trust layer of the next generation of the internet—driven by the third major cryptographic primitive, SNARK, following hashes and signatures.

Proving the software of the world, opening a new era of encryption.

Learn more:

Vitalik’s interpretation: Click to watch

ETHProofs Fourth Discussion: Click to Watch