Vitalik's full proposal for long-term L1 execution layer: replacing EVM with RISC-V

Source: Vitalik Buterin

Compiled by: KarenZ, Foresight News

On April 20, Vitalik Buterin proposed an important proposal regarding the long-term L1 execution layer of Ethereum 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, aiming to fundamentally enhance the operational efficiency of the Ethereum execution layer, break through one of the current major scalability bottlenecks, and significantly simplify the clarity of the execution layer.

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

This paper presents a radical idea about the future of Ethereum’s execution layer, no less ambitious than the consensus layer’s Beam Chain initiatives. The proposal aims to dramatically improve the efficiency of Ethereum’s 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: Use RISC-V to replace EVM as the virtual machine language for writing smart contracts.

Important Note:

The concepts of account system, cross-contract calls, storage, etc. will be fully retained. These abstract designs work well and developers are accustomed to using them. The opcodes such as SLOAD, SSTORE, BALANCE, and 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, as these languages will adapt RISC-V as the new backend. This is 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 hardly affected, and developers may not even notice the change.

The old version of the EVM contract will continue to operate and will be fully bi-directionally compatible with the new RISC-V contract. There are several implementation methods, which will be discussed in detail later in this article.

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

Why do this?

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

Stability of Data Availability Sampling and Historical Storage Protocols

Maintain the competitiveness of the block production market.

The proof capability of ZK-EVM

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

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

Chart Explanation: The four main time-consuming stages are deserialize_inputs, initialize_witness_db, state_root_computation, and block_execution.

Among them, initialize_witness_db and state_root_computation are related to the state tree, while deserialize_inputs involves the process of converting block and witness data into internal representations—actually more than 50% is proportional to the size of the witness data.

By replacing the current keccak 16-ary Merkle Patricia tree with a binary tree that uses easily provable hash functions, these components can be significantly optimized. If Poseidon is used, we can prove 2 million hashes per second on a laptop (in contrast, keccak is about 15,000 hash/sec). Besides Poseidon, there are many other options. Overall, there is significant room for optimization in these components. Additionally, 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 100-fold improvement in overall proof efficiency, the EVM proof efficiency needs to be improved by at least 50 times. One solution is to create a more efficient proof implementation for the EVM, while another solution is to note that the current ZK-EVM prover actually proves by compiling the EVM to RISC-V, allowing smart contract developers direct access to the RISC-V virtual machine.

Some data shows that efficiency improvements may exceed 100 times under certain conditions:

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

(It is worth noting that in regular EVM execution, the time consumption ratio of “EVM operations” to “other operations” is also close to 50/50. Therefore, we intuitively believe that removing EVM as an “intermediate layer” will bring equivalent significant gains.)

Implementation details

There are multiple ways to implement this proposal. The least disruptive option is to support both virtual machines simultaneously, allowing contracts to be written in either one. Both types of contracts can access the same functionalities: persistent storage (SLOAD/SSTORE), the ability to hold ETH balances, initiate/receive calls, etc. EVM and RISC-V contracts can call 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 into an EVM interpreter contract written in RISC-V to run its existing EVM code. That is, if an EVM contract has code C and the EVM interpreter is at address X, then the contract will be replaced with top-level logic that, when called from the outside with a call argument D, calls X and passes in (C, D), and then waits for the return value and forwards. If the EVM interpreter itself calls the contract, asking to run CALL or SLOAD/SSTORE, then the contract performs these operations.

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

The core advantage of the second and third options is that they greatly simplify the execution layer specification. GIVEN THE DIFFICULTY OF EVEN REMOVING INCREMENTAL SIMPLIFICATIONS LIKE SELFDESTRUCT, THIS LINE OF THINKING MAY BE THE ONLY VIABLE PATH TO SIMPLIFY. Tinygrad adheres to the hard and fast rule of “no more than 10,000 lines of code”, and the optimal underlying blockchain should be able to easily meet this limit and be further streamlined. The Beam Chain initiative promises to dramatically simplify Ethereum’s consensus layer, and such a radical change may be the only way to achieve a similar boost at the execution layer.