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

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:

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