Vitalik Long-term L1 Execution Layer Proposal Full Text: Replace EVM with RISC-V

Original title: "Long-term L1 execution layer proposal: replace the EVM with RISC-V"

Author: Vitalik Buterin

Compiled by: KarenZ, Foresight News

On April 20, Vitalik Buterin proposed an important proposal on the long-term L1 execution layer of Ethereum on the Ethereum Magicians platform. He suggested using RISC-V architecture to replace the existing EVM (Ethereum Virtual Machine) as the virtual machine language for writing smart contracts, aiming to fundamentally improve the operation efficiency of the Ethereum execution layer, break through one of the current major expansion bottlenecks, and significantly simplify the simplicity of the execution layer.

Foresight News compiled the proposal in full text to help readers understand this technical idea. The following is the compiled content of the original proposal:

This article proposes a radical idea about the future of Ethereum execution layer, with ambitions that are no less than the consensus layer’s Beam Chain plan. The proposal aims to significantly increase the efficiency of the Ethereum execution layer, address one of the major scaling bottlenecks, and significantly simplify the execution layer—in fact, this may be the only way to achieve this.

Core concept: Replace EVM with RISC-V as a virtual machine language written in smart contracts.

Important Note:

• The concepts of account system, cross-contract calls, storage, etc. will be completely retained. These abstract designs work well and developers are used to it. SLOAD, SSTORE, BALANCE, CALL and other opcodes will be converted into RISC-V system calls.
• In this mode, smart contracts are available for writing in Rust, but I expect most developers to continue writing contracts using Solidity (or Vyper) that 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 easier to read. The development experience may be almost unaffected, and developers may not even notice changes.
• The old EVM contract will continue to run and will be fully two-way compatible with the new RISC-V contract. There are several implementation methods, which will be discussed in detail later in this article.

The Nervos CKB VM has set a precedent, which is essentially a RISC-V implementation .

Why do this?

In the short term, the upcoming EIP (such as block-level access lists , delayed execution , distributed historical storage and EIP-4444 ) can solve the main expansion bottlenecks of Ethereum L1. More issues will be solved in the medium term through statelessness and ZK-EVM. In the long run, the main limiting factors for Ethereum L1 expansion will become:

1. Data availability sampling and stability of historical storage protocols
2. Maintain competitive demand for block production market
3. ZK-EVM's proof capability

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

The following table shows the number of cycles required for Succinct ZK-EVM to prove each link of the EVM execution layer:

Chart description: The four main time-consuming links 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 blocks and witness data into internal representations—in fact, more than 50% are proportional to the witness data size.

These parts can be greatly optimized by replacing the current keccak 16-ary Merkle patricia tree with a binary tree that uses a hash function that is easy to prove. If using Poseidon, we can prove 2 million hashes per second on our laptop (in comparison, keccak is about 15,000 hash/sec). Apart from Poseidon, there are many other options. Overall, there is a lot of room for optimization for these components. In addition, we can eliminate accrue_logs_bloom by removing bloom .

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

Some data show that efficiency improvements may exceed 100 times in specific situations:

In actual applications, the remaining prover time may be mainly occupied by the current precompile operations. If RISC-V is used as the main virtual machine, the Gas schedule will reflect the actual proof time, and economic pressure will prompt developers to reduce the use of high-cost precompilation. Even so, the gains will not be so significant, but we have good reason to believe that these gains will be very considerable.

(It is worth noting that the time-consuming proportion of "EVM operations" and "other operations" in regular EVM execution is also close to 50/50, so we intuitively believe that removing EVM as the "middle layer" will bring equally significant gain)

Implementation details

This proposal has multiple ways to implement it. The least disruptive solution is to support both virtual machines at the same time, allowing contracts to be written with one choice. Both types of contracts can access the same functions: persistent storage (SLOAD/SSTORE), ability to hold ETH balances, initiating/receiving calls, etc. EVM and RISC-V contracts can be called from each other - from the perspective of RISC-V, calling an EVM contract is equivalent to executing a system call with special parameters; while the EVM contract receiving the message interprets it as a CALL.

A more radical approach from a protocol perspective is to convert an existing EVM contract to a call to an EVM interpreter contract written in RISC-V and run 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, when called from outside with parameter D, X is called and passed in (C, D), and then waits for the return value and forwarding. If the EVM interpreter itself calls the contract and requires running CALL or SLOAD/SSTORE, the contract performs these operations.

The compromise solution is to adopt the second solution, but the concept of "virtual machine interpreter" is clearly supported through the protocol, requiring its logic to be written in RISC-V. EVM will be the first instance and will also support other languages ​​in the future (Move may be a candidate).

The core advantage of the second and third solutions is that they greatly simplify execution layer specifications. Considering that even a progressive simplification like SELFDESTRUCT is difficult, this idea may be the only viable simplification path. Tinygrad follows the hard and rigid regulations of " no more than 10,000 lines of code ", and the optimal blockchain underlying layer should easily meet this limitation and further streamline it. Beam Chain plans to significantly simplify the Ethereum consensus layer, and if the execution layer wants to achieve similar improvements, such radical changes may be the only way to go.