Technical debt accumulation, how does Ethereum rebuild its technical architecture with RISC-V to find a breakthrough?

Written by: jaehaerys.eth

Compiled by: 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, in the era of zero-knowledge proofs (ZK), the EVM has become the biggest bottleneck:

The current zkEVM relies on interpreter execution, resulting in a speed reduction of 50–800 times;

Precompiled contracts add complexity to the protocol and increase risks;

The 256-bit stack design is extremely inefficient in proof.

RISC-V can solve these problems:

Minimalism (approximately 47 basic instructions) + mature LLVM ecosystem (supports Rust, C++, Go);

Has become the de facto zkVM standard (90% of projects adopted);

The formal SAIL specification (as opposed to the ambiguous yellow paper) can support rigorous verification;

The hardware proof path (ASIC/FPGA) is under testing (SP1, Nervos, Cartesi).

The migration consists of three phases:

RISC-V as an alternative to precompiled contracts (low-risk testing);

Dual Virtual Machine Era: EVM + RISC-V has complete interoperability;

EVM is re-implemented internally in RISC-V (similar to the Rosetta strategy).

Ecosystem Impact:

Optimistic Rollups are not affected; 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: expand the current fault-tolerant infrastructure to the target RISC-V, rather than a complete reconstruction;

ZK Rollup will benefit significantly (Polygon, zkSync, Scroll → cheaper, faster, simpler);

Developers can directly use Rust/Go/Python libraries on L1;

Users can achieve approximately 100 times the proof cost savings, paving the way to Gigagas level (approximately 10k TPS) L1.

Ultimately, Ethereum will evolve from the "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 being ZK-Snarkified" as the vision, Ethereum is now at the threshold of the most significant architectural evolution since its inception. This discussion is no longer limited to incremental upgrades but is a fundamental reconstruction of its computational core—namely the replacement of the Ethereum Virtual Machine (EVM). This initiative is the cornerstone of a larger vision called "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: has the EVM, as the engine of the smart contract revolution, now become the main bottleneck for Ethereum's future development?

As Justin Drake of the Ethereum Foundation stated, the long-term goal of Ethereum 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 a "castle in the air" because 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 turned into a pressing practical issue.

This analysis will explore the technical and strategic arguments for the migration of Ethereum L1 to the RISC-V instruction set architecture (ISA), a move that promises to unlock unprecedented scalability, simplify the protocol structure, and align Ethereum with the future of verifiable computing.

What changes have actually occurred?

Before delving into the "why", it is essential to understand "what" is changing.

EVM is the execution environment for Ethereum smart contracts, functioning 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 giving rise to the entire DeFi and NFT ecosystem. However, this custom architecture, which is nearly a decade old, has now accumulated a 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 conference call, its key principles make it the best choice for this role:

Minimalism: The basic instruction set is extremely concise, containing only about 40-47 instructions. Jeremy describes it as "almost the perfect use case for the ultra-simplified general-purpose machine we need."

Modular: Add more complex features through optional extensions. This is crucial because it allows for a simple core, which can be expanded as needed without imposing unnecessary complexity on the underlying protocol.

Open Ecosystem: It has a large and mature toolchain support, including the LLVM compiler, allowing developers to use mainstream languages such as 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 of great value." RISC-V enables Ethereum to inherit these ready-made tools for free.

Interpreter overhead issue

The necessity to replace 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 serious performance bottlenecks within ZK proof systems, as well as the risks posed by the increasingly accumulated complexity within the protocol.

Interpreter overhead issue

The most pressing driving force behind this transformation is the inherent inefficiency of 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 the current working principle of zkEVM. They do not directly provide zero-knowledge proofs for EVM, but rather prove an interpreter of EVM, which itself is compiled into RISC-V. Vitalik Buterin pointed out this core issue succinctly:

"If the implementation of zkVM compiles the execution of EVM into RISC-V code, then why not directly open the underlying RISC-V 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 proof-native programs. After optimizing other bottlenecks (such as switching to the Poseidon hashing algorithm), this part of the "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 performance shortcomings of EVM in certain cryptographic operations, Ethereum introduced precompiled contracts—specialized functions hardcoded directly into the protocol. While this was a pragmatic solution at the time, it has now led to what Vitalik Buterin has referred to as a "catastrophic" situation:

"Precompilation is catastrophic for us... it has greatly inflated Ethereum's trusted codebase... and on the brink of consensus failure, it has nearly caused us to crash multiple times."

The complexity is astonishing. Vitalik pointed out, by comparing the wrapper code of a single precompiled contract (modexp) with a complete RISC-V interpreter, that the logic of the precompiled contract is actually more complex. The introduction of new precompiles must go through a slow and politically charged hard fork process, which severely hinders application innovation that relies on new cryptographic primitives.

Therefore, Vitalik came to a firm conclusion: "I actually think we should immediately stop adding any new precompiled contracts."

The architectural technical debt of Ethereum

The core design of the EVM reflects the outdated demands of its era, but it can no longer adapt to modern computing. The EVM has chosen a 256-bit architecture for handling cryptographic values, which is highly inefficient for the 32-bit or 64-bit integers typically used in smart contracts. This inefficiency comes at a particularly high cost in zero-knowledge proof systems.

As explained by Vitalik: "When using smaller numbers, each number actually does not save any resources, while the complexity increases by 2 to 4 times."

In addition, the stack architecture of EVM is less efficient than the register architectures of RISC-V and modern CPUs. It requires more instructions to perform the same operations, which also makes compiler optimization more complex.

These combined factors, including the performance bottlenecks of ZK proofs, the complexity of precompiles, and outdated architectural choices, together present a compelling and urgent case for Ethereum to move beyond the EVM.

RISC-V Blueprint: Building a Stronger Foundation

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

Why open standards are better than custom designs

Unlike the customized instruction set architecture (ISA) that requires 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 the field of computer science. As Justin Drake explained, this provides Ethereum with a direct way to use 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 supported by LLVM."

This greatly 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 huge advantage for security, as a smaller trusted codebase is easier to audit and formally verify.

Fact standard in the ZK field

More importantly, the zkVM ecosystem has made its own choices. As emphasized by Justin Drake, a clear trend can be seen from the Ethproofs data: "RISC-V is the leading ISA for zkVM backends."

In 10 zkVMs capable of proving Ethereum blocks, 9 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 rather a following of a market-validated standard.

Designed for trust, not just for execution

In addition to the ecosystem, the internal architecture of RISC-V is also particularly suited for building secure and verifiable systems.

First of all, RISC-V has a formal, machine-readable specification called SAIL. This represents a significant improvement over the specification of the Ethereum Virtual Machine (EVM), which mainly exists in the form of documentation (yellow paper) and may have 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 value-laden protocols. As Alex Hicks from the Ethereum Foundation (EF) pointed out during the Ethproofs conference call, this allows zkVM circuits to be verified directly "according to the official RISC-V specification."

Secondly, RISC-V includes a privileged architecture, a feature that is often overlooked but is crucial for security. It defines different operation levels, primarily including user mode (for untrusted applications, such as 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 make requests to a trusted kernel running in supervisor mode via a special ECALL (environment call) instruction. This mechanism establishes a security boundary enforced by hardware, which 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-stage process to ensure the stability of the system and backward compatibility. The approach outlined by Vitalik Buterin aims for incremental development rather than revolutionary change.

Step 1: Pre-compile replacement

In the initial stage, a conservative approach will be taken, introducing limited functionality of the new virtual machine (VM). As suggested by Vitalik, "We can start using the new VM from limited scenarios, such as replacing precompiled functions." This will involve pausing new EVM precompiled functions and instead implementing the required functionality through whitelisted RISC-V programs. This approach allows the new VM to conduct practical testing on the mainnet 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 "directly open the new virtual machine to users." When deploying smart contracts, a flag can be added to indicate whether its bytecode is EVM or RISC-V. The key feature is to ensure 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 acting as an intermediary for the execution environment.

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 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 of the entire ecosystem

The transition plan from EVM to RISC-V goes far beyond the core protocol; it will have a profound impact on the entire Ethereum ecosystem, promising to reshape the developer experience, fundamentally change the competitive landscape of Layer-2 solutions, and open up new proof economic models.

Rollup Architecture Reconstruction: The Path Divergence of Optimistic and ZK

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

The security model of Optimistic Rollups (such as 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, there will be no fundamental changes to these systems. As explained by one of the co-founders of Optimism: "If we migrate Ethereum to RISC-V, the Optimistic chain will not be disrupted. You just need to compile the RISC-V virtual machine into the proof program. There is no need to use Asterisc either. The existing MIPS-based proof systems will similarly remain unaffected—you just need to compile the RISC-V virtual machine into MIPS."

This means that the anti-fraud model remains intact. The adjustment is 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. L1s using the same native language 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 through the built-in L1 VM. This integration will bring about the following changes:

Simplified technology stack: eliminate the complex bridging between L2 internal RISC-V execution and EVM;

Achieve 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.

Coordinating Economic Incentives: The Gas fees for L1 will more accurately reflect the actual costs of ZK proof RISC-V execution, thereby creating a more reasonable economic model.

The New Era of Developers and Users

For Ethereum ecosystem developers, this change 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 start to coexist." At the same time, he predicts that "Solidity and Vyper will continue to be 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," in which developers can essentially use the same language to write both on-chain and off-chain code.

For users, the ultimate reward is a more economical and powerful network. It is expected that proof costs will decrease by about 100 times—from several dollars per transaction down to a few cents—which will directly translate into lower Layer-1 and Layer-2 settlement fees. This economic feasibility will unlock the vision of "Gigagas L1", aiming to achieve approximately 10,000 TPS performance on L1, thus supporting more complex and higher-value on-chain applications in the future.

Succinct Labs and SP1: Proving that the future is now

The theoretical advantages of RISC-V have been put into practice by teams such as Succinct Labs, whose work provides a strong case study for the entire proposal.

The SP1 developed by Succinct Labs is a high-performance, open-source zkVM built on RISC-V that validates the feasibility of a new architectural approach. It adopts a "precompiled centralized" design concept, perfectly addressing the cryptographic bottleneck issues of the EVM. Unlike traditional methods that rely on slow, hard-coded precompiled operations, SP1 offloads intensive operations like Keccak hashing to standard ECALL instruction calls and specially designed, manually optimized ZK circuits. This provides the performance of custom hardware while retaining the flexibility of software.

The practical impact of the team has become clear, as their OP Succinct product utilizes SP1 to achieve the "ZK-ification" of Optimistic Rollup. As explained by Uma Roy, the co-founder of Succinct:

"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 greatly improves the speed of final confirmation, it's amazing."

This addresses a key pain point in the entire OP Stack ecosystem. In addition, 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 computing. Their work is not just a proof of concept, but a feasible blueprint for the future as described in this article.

How Ethereum Reduces Risks

A key advantage of RISC-V is that it makes the ultimate goal of formal verification—proving the correctness of a system through mathematical methods—a feasible objective. The specification of EVM is written in natural language in the Yellow Paper, which poses significant formalization challenges. 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 for stronger security. As Alex Hicks from the Ethereum Foundation pointed out, work is currently underway to "extract zkVM RISC-V circuits 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, thus achieving breakthroughs in security.

The main risks of transformation

Despite the many advantages of the RISC-V architecture's L1, it will also face new complex challenges.

Gas Metering Issues: Creating a deterministic and fair Gas model for the universal ISA is one of the most challenging problems to solve. Simple instruction counting methods are vulnerable to denial-of-service attacks. For instance, an attacker could design a program that repeatedly triggers a cached program, thereby achieving high resource consumption at a very low Gas cost.

Toolchain security and the "reproducible builds" issue: This may be the most important and underestimated risk during the transformation process. The security model shifts from trusting the virtual machines on the trust chain to trusting the off-chain compilers (such as LLVM) used by each developer, and these compilers are extremely complex and known to contain vulnerabilities. Attackers may exploit compiler vulnerabilities to transform seemingly innocuous source code into malicious bytecode. Furthermore, ensuring that the on-chain compiled binaries are exactly consistent with specific public source code, i.e., the "reproducible builds" issue, is also extremely difficult to achieve, as slight differences in the build environment can produce different binaries.

Mitigation Strategy

The road ahead requires a multi-layered defense strategy.

Phased rollout: A gradual, multi-stage transition plan is the primary risk mitigation strategy. By initially introducing RISC-V as a pre-compiled 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 Audit: Fuzz Testing and Formal Verification. While formal verification is the ultimate goal, it must be complemented by continuous, high-intensity testing. As Valentine from Diligence Security demonstrated in the Ethproofs conference call, their Argus fuzz tester has already identified 11 critical soundness and integrity vulnerabilities in leading zkVMs. This proves that even the most well-designed systems have vulnerabilities, which can only be discovered 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 the RV64 GC and Linux-compatible ABI, as this combination can provide the widest support from mainstream languages and tools, thereby maximizing the advantages of the new ecosystem.