Vitalik's Long-Term L1 Execution Layer Proposal Full Text: Replacing EVM with RISC-V

By: blockbeats|2025/04/21 13:15:04
0
Share
copy
Original Title: Long-term L1 execution layer proposal: replace the EVM with RISC-V
Original Source: Vitalik Buterin
Original Translation: KarenZ, Foresight News

On April 20, Vitalik Buterin proposed a significant proposal regarding Ethereum's long-term L1 execution layer on the Ethereum Magicians platform. He suggested adopting the RISC-V architecture to replace the existing EVM (Ethereum Virtual Machine) as the virtual machine language for writing smart contracts. The goal is to fundamentally improve the efficiency of the Ethereum execution layer, overcome one of the current major scalability bottlenecks, and greatly simplify the elegance of the execution layer.

Foresight News has provided a full translation of the proposal to help readers understand this technological vision. The following is the translated content of the original proposal:

This article presents a radical idea about the future of the Ethereum execution layer, with ambitions no less than the Beam Chain plan for the consensus layer. The proposal aims to significantly enhance the efficiency of the Ethereum execution layer, address a major scalability bottleneck, and substantially simplify the execution layer—indeed, this may be the only way to achieve this goal.

Core Concept: Replace the EVM with RISC-V as the virtual machine language for smart contract writing.

Important Notes:

· Concepts such as account system, cross-contract calls, storage, etc., will be fully retained. These abstract designs work well, and developers are already accustomed to using them. Opcodes like SLOAD, SSTORE, BALANCE, CALL will be transformed into RISC-V system calls.

· In this mode, smart contracts can be written in Rust, but I expect most developers will continue to use Solidity (or Vyper) to write contracts, and these languages will be adapted to RISC-V as the new backend. Because smart contracts written in Rust are actually less readable, while Solidity and Vyper are clearer and more readable. The development experience may be hardly affected, and developers may not even notice the change.

· Old version EVM contracts will continue to operate and will be fully interoperable with new RISC-V contracts. There are several ways to achieve this, which will be discussed in detail later in this article.

The Nervos CKB VM has set a precedent as it is essentially an implementation of RISC-V.

Why is this done?

In the short term, upcoming EIPs (such as Block Access Lists, Delayed Execution, Distributed History Store, and EIP-4444) will address Ethereum's L1 main scalability bottlenecks. In the medium term, more issues will be addressed through statelessness and ZK-EVM. In the long term, the main limiting factors for Ethereum L1 scalability will be:

1. The stability of data availability sampling and historical storage protocols

2. The need to maintain block production market competitiveness

3. The proof capability of ZK-EVM

I will argue that replacing ZK-EVM with RISC-V can address key bottlenecks in (2) and (3).

The table below shows the number of cycles required at each step of Succinct ZK-EVM proof of EVM execution layer:

Vitalik's Long-Term L1 Execution Layer Proposal Full Text: Replacing EVM with RISC-V

Chart Description: The four main time-consuming steps are deserialize_inputs, initialize_witness_db, state_root_computation, and block_execution

Where initialize_witness_db and state_root_computation are related to the state tree, deserialize_inputs involves the process of converting block and witness data into an internal representation—actually more than 50% proportional to the witness size.

By replacing the current keccak 16-ary Merkle Patricia Tree with a binary tree that uses hash functions easy to prove, these parts can be significantly optimized. If Poseidon is used, we can prove 2 million hash values per second on a laptop (compared to approximately 15,000 hash/sec for keccak). Besides Poseidon, there are many other options. Overall, these components have a lot of optimization potential. Additionally, we can eliminate accrue_logs_bloom by removing bloom.

The remaining block_execution accounts for about half of the current proof cycle. To achieve a 100x overall proof efficiency improvement, the EVM proof efficiency needs to be improved at least 50 times. One solution is to create a more efficient proof implementation for EVM, and another is to note that the current ZK-EVM prover actually proves the EVM by compiling it into RISC-V, allowing smart contract developers direct access to this RISC-V virtual machine.

Some data indicates that in specific scenarios, efficiency gains of over 100x are possible:

In practical applications, the remaining prover time may be predominantly taken up by the current precompiles operation. If RISC-V is used as the main virtual machine, the Gas schedule will reflect actual proving time, and economic pressures will prompt developers to reduce the use of high-cost precompiles. Even so, the gains will not be as significant, but we have good reason to believe that these gains will be substantial.

(It is worth noting that in a typical EVM execution, the time spent on "EVM operations" versus "other operations" is also close to 50/50, so we intuitively believe that removing the EVM as an "intermediate layer" will bring equally significant gains.)

Implementation Details

There are various ways to implement this proposal. The least disruptive approach is to support both virtual machines simultaneously, allowing contracts to choose one to write. Both types of contracts will have access to the same functionality: persistent storage (SLOAD/SSTORE), the ability to hold an ETH balance, initiate/receive calls, etc. EVM and RISC-V contracts can call each other— from the RISC-V perspective, calling an EVM contract is akin to performing a system call with special parameters; and an EVM contract receiving a message will interpret it as a CALL.

From a protocol perspective, a more aggressive approach is to convert existing EVM contracts into calls to an EVM interpreter contract written in RISC-V, running its existing EVM code. That is, if an EVM contract has code C, and the EVM interpreter is at address X, the contract will be replaced with top-level logic that, when called with external parameters D, calls X and passes (C, D), then waits for a return value and forwards it. If the EVM interpreter itself calls the contract, requesting to perform CALL or SLOAD/SSTORE, the contract carries out these operations.

A compromise approach is to adopt the second approach but explicitly support the concept of a "virtual machine interpreter" in the protocol, requiring its logic to be written in RISC-V. EVM will be the initial instance, with potential future support for other languages (Move may be a candidate).

The core advantage of the second and third approaches are that they can greatly simplify the execution layer specification. Considering that even the incremental simplification of removing SELFDESTRUCT is fraught with difficulties, this approach may be the only feasible path to simplification. Tinygrad adheres to the strict rule of "code not exceeding 10,000 lines," and the optimal blockchain base layer should easily meet this limit, further streamlining the process. The Beam Chain project is expected to significantly simplify the Ethereum consensus layer, and for the execution layer to achieve similar improvements, this radical change may be the only viable path forward.

Original Article Link

-- Price

--

You may also like

SK Hynix Reportedly Plans U.S. ADR Listing as Early as August, With SEC Approval Possible in Late June

SK Hynix may pursue a U.S. ADR listing as early as August, with SEC approval reportedly possible in late June amid strong AI chip supply chain demand.

SpaceX vs Tesla vs xAI: Which Elon Musk Trade Has the Biggest Upside in 2026?

SpaceX's IPO is days away, Tesla holds over 11,000 BTC, and xAI is betting big on AI. Here's how traders are comparing the three biggest Musk narratives.

OpenAI Reveals It Has Confidentially Submitted an S-1 to the SEC, Keeping the Door Open for a Future IPO

On June 9, according to an OpenAI announcement, the company recently confidentially submitted a draft S-1 registration statement to the U.S. Securities and Exchange Commission (SEC), beginning the preliminary compliance process for a potential initial public offering. OpenAI said it chose to disclose this proactively because it expected the news might leak; however, the company has not yet set a specific listing timeline, and related arrangements may still take some time.

Latest research from 13 top universities including Cornell University: The current state, challenges, and misconceptions of the fusion of Crypto and AI

The combination of AI and crypto is still in its early stages, with both serving as complementary "middleware": AI translates human intentions into executable programs, while cryptographic technology provides verifiable and tamper-proof guarantees for computational processes and results. In the dire...

Deconstructing Anthropic: The Best AI Company, Possibly Also a Type of Organizational Invention

Instead of competing with ambition, focusing on restraint, how does Anthropic leverage extreme strategic focus and an "counterintuitive" geek culture to counterattack OpenAI on the AI battlefield?

Apollo and Blackstone Reportedly Back $35 Billion Anthropic Chip Financing as Deal Details Remain Unclear

On June 9, according to currently available news alerts, Apollo and Blackstone Group participated in a $35 billion financing for an Anthropic “chip project.” Based on the original wording of the report, the funding has already been raised, but public information remains limited. The financing structure, use of proceeds, project entity, and whether Apollo and Blackstone participated through equity, debt, or project financing have not yet been disclosed.

Contents

Popular coins

Latest Crypto News

Read more
iconiconiconiconiconiconicon
Customer Support:@weikecs
Business Cooperation:@weikecs
Quant Trading & MM:bd@weex.com
VIP Program:support@weex.com