Vitalik's Radical New Article: Execution Layer Expansion "No Break, No Establishment", EVM Must Be Iterated in the Future

This article is from: Ethereum co-founder Vitalik

Compilation | Odaily Planet Daily (@OdailyChina)

Translator｜Azuma（@azuma_eth）

In this article, I will put forward a radical idea about the future of the Ethereum execution layer, which is as grand as the consensus layer's Beam Chain plan. The goal of this plan is to significantly enhance the efficiency of the Ethereum execution layer, addressing one of the main scaling bottlenecks while also greatly simplifying the complexity of the execution layer—indeed, this may be the only way to achieve simplification.

The core idea of this article is to replace EVM with RISC-V as the virtual machine language for smart contracts.

Important Note:

• The concepts of accounts, cross-contract calls, storage, etc. will be fully retained. These abstract mechanisms work well and developers have become accustomed to using them. Operations like SLOAD, SSTORE, BALANCE, CALL, etc. will become system calls in RISC-V.
• Developers can still choose Solidity or Vyper. Although it is theoretically possible to write smart contracts in Rust, it is expected that most developers will continue to use Solidity (or Vyper), as these languages will adapt RISC-V as the backend compilation target - this is because smart contracts written in Rust have poorer readability, while Solidity and Vyper are easier to understand. The development experience is unlikely to change significantly, and developers may not notice any difference at all.
• New and old contracts will achieve bidirectional interoperability. Traditional EVM contracts will continue to operate and will be able to fully interact with the new RISC-V contracts. Details of the implementation will be explained later.
• There are precedents to follow: Nervos CKB VM is essentially based on a RISC-V implementation.

Why is this transformation needed?

In the short term, the main bottlenecks for Ethereum Layer 1 scaling will be addressed through the upcoming EIPs (such as block-level access lists, delayed execution, distributed historical storage, and EIP-4444); in the medium term, we will solve more problems through statelessness and ZK-EVM; but in the long term, the main factors limiting Ethereum Layer 1 scaling will become:

1. Data availability sampling and the stability of historical storage protocols;
2. The demand to maintain market competitiveness in block production;
3. The proof capability of ZK-EVM.

This article will argue that replacing ZK-EVM with RISC-V can break through the key bottlenecks in points 2 and 3.

The following is a statistical table of the number of cycles required for the Succinct ZK-EVM to prove each stage of the EVM execution layer:

The four main time-consuming stages are: "deserialize_inputs" (data deserialization), "initialize_witness_db" (witness database initialization), "state_root_computation" (state root computation), and "block_execution" (block execution).

The "witness database initialization" and "state root calculation" are both related to the state tree, while "data deserialization" refers to the process of converting blocks and witness data into internal representations. Therefore, in reality, more than 50% of the time is related to the size of the witness data.

By replacing the current "keccak 16-ary Merkle patricia tree" with a "binary tree" that uses proof-friendly hash functions, these steps can be significantly optimized. If we use "Poseidon", we can prove 2 million hashes per second on a laptop (in contrast, keccak is about 15,000 hashes per second). Besides "Poseidon", there are many other options. Overall, there is an opportunity to greatly reduce the time taken for these steps. Additionally, we can further simplify the process by removing "accrue_logs_bloom".

Now only "block execution" remains, which accounts for about half of the current proof cycle. If we want to increase the overall proof efficiency by 100 times, we must at least improve the EVM proof efficiency by 50 times. There are currently two paths: one is to try to create a more efficient EVM implementation to reduce the proof cycle; the other is to allow developers to directly use the RISC-V virtual machine already adopted at the ZK-EVM layer.

Some data shows that efficiency improvement can exceed 100 times in specific scenarios:

In practice, the remaining proof time will mainly be consumed by precompiled contracts. If RISC-V is set as the main virtual machine, the gas fee mechanism will reflect the actual proof time, and economic pressure will encourage developers to reduce the use of high-cost precompiles. Although the actual benefits may not reach theoretical values, the expectations will still be very significant.

It is worth noting that there is also a similar 50/50 time distribution between "EVM" and "other links" in regular EVM execution. We intuitively believe that removing the EVM as an "intermediate layer" should achieve a comparable level of efficiency improvement.

Implementation Method

There are various ways to implement the above proposal.

The least destructive method is to support two types of virtual machines, allowing contracts to be written in either virtual machine. Both types of contracts can access the same functionalities: persistent storage (SLOAD/SSTORE), ETH balance management, initiating and receiving calls, etc. EVM and RISC-V contracts can freely interoperate: calling EVM contracts from the RISC-V perspective will be treated as a system call (syscall) with special parameters, while the EVM contract receiving the call will parse it as a normal CALL instruction.

A more radical approach would convert existing EVM contracts into contracts that call an EVM interpreter written in RISC-V to execute their original EVM code. Specifically, suppose an EVM contract contains code C, and the EVM interpreter is located at address X, then that contract will be replaced with the top-level logic: when an external call is initiated with parameters D, this logic will send a (C, D) request to X, wait for the return value, and forward it. If the EVM interpreter itself needs to call contracts to perform operations like CALL, SLOAD, or SSTORE, the contract will respond directly.

The compromise plan is based on the second option, explicitly supporting the concept of "virtual machine interpreter" at the protocol layer — that is, requiring the interpreter logic to be written in RISC-V. EVM will serve as the first official interpreter, and other types (such as the Move language interpreter) may be introduced in the future.

The core advantage of the second and third proposals lies in significantly simplifying the execution layer specifications. Considering that even incremental simplifications like the removal of SELFDESTRUCT are fraught with difficulties, such changes may be the only realistic way to achieve simplification. The Tinygrad project strictly stipulates that the code size should never exceed 10,000 lines; the ideal blockchain base layer should pursue even more extreme minimalism. The Beam Chain plan points the way for simplifying the Ethereum consensus layer, and for the execution layer to achieve similar breakthroughs, it may only be possible through such fundamental changes.