The ideal blockchain should pursue ultimate simplicity, and the execution layer must undergo fundamental changes to achieve a breakthrough.
Original:Long-term L1 execution layer proposal: replace the EVM with RISC-V
Author:vitalik.eth
Translated by:Azuma, Odaily Planet Daily
In this article, I will propose a radical idea about the future of Ethereum's execution layer, which is as ambitious as the Beam Chain plan for the consensus layer. The goal of this plan is to significantly improve the efficiency of Ethereum's execution layer, address one of the main scaling bottlenecks, and greatly simplify the complexity of the execution layer - in fact, this might be the only way to achieve simplification.
The core idea of this article is to replace the EVM with RISC-V as the virtual machine language for smart contracts.
Important Notes:
- Concepts such as accounts, cross-contract calls, and storage will be completely preserved. These abstract mechanisms work well, and developers are already accustomed to using them. Opcodes like SLOAD, SSTORE, BALANCE, and CALL will become system calls for RISC-V.
- Developers can still choose Solidity or Vyper. While theoretically, smart contracts can be written in Rust, most developers are expected to continue using Solidity (or Vyper), which will be adapted to use RISC-V as a backend compilation target - because smart contracts written in Rust are less readable, while Solidity and Vyper are easier to understand. The development experience will hardly change, and developers may not notice any difference.
- New and old contracts will have bidirectional interoperability. Traditional EVM contracts will continue to run and can fully interact with new RISC-V contracts. The specific implementation will be detailed later.
- There is a precedent: Nervos CKB VM is essentially a RISC-V-based implementation.
Why is this transformation necessary?
In the short term, the main bottlenecks for Ethereum Layer 1 scaling will be addressed by 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:
- Stability of data availability sampling and historical storage protocols;
- The need to maintain competitiveness in block production markets;
- Proof capabilities of ZK-EVM.
This article will argue that replacing ZK-EVM with RISC-V can break through key bottlenecks in points 2 and 3.
Here is a table showing the number of cycles required by 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 calculation), and "block_execution" (block execution).
"Witness database initialization" and "state root calculation" are related to the state tree, and "data deserialization" refers to the process of converting block and witness data to internal representation. In fact, over 50% of the time is related to the size of witness data.
By replacing the current "keccak 16-ary Merkle patricia tree" with a "binary tree" using proof-friendly hash functions, these stages can be significantly optimized. If we use "Poseidon", we can prove 2 million hashes per second on a laptop (compared to about 15,000 hashes per second for keccak). There are many other options besides "Poseidon". Overall, there is an opportunity to significantly reduce the time for these stages. Additionally, we can further simplify the process by removing "accrue_logs_bloom".
Now only "block execution" remains, which currently takes about half of the proof cycle. If we want to improve overall proof efficiency by 100 times, we must improve EVM proof efficiency by at least 50 times. There are two paths: one is to try to create a more efficient EVM implementation to reduce proof cycles; the other is to directly have developers use the RISC-V virtual machine already adopted by ZK-EVM.
Some data shows that efficiency improvement can exceed 100 times in specific scenarios:
In practice, the remaining proof time will be mainly 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 be as good as the theoretical values, they are still expected to be significant.
It is worth noting that in conventional EVM execution, there is also a similar 50/50 time allocation between "EVM" and "other stages". We intuitively believe that removing the EVM as a "middle layer" should yield similar efficiency improvements.
Implementation Methods
There are multiple ways to implement the aforementioned proposal.
The least disruptive method is to support two virtual machines, allowing contracts to be written in either one. 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 call each other: calling an EVM contract from a RISC-V perspective will be treated as a system call with special parameters, while the receiving EVM contract will parse it as a normal CALL instruction.
A more radical approach would convert existing EVM contracts to call a RISC-V written EVM interpreter contract to execute its original EVM code. Specifically, assuming an EVM contract contains code C, and the EVM interpreter is located at address X, the contract would be replaced with top-level logic: when an external call is initiated with parameters D, this logic would send a (C, D) request to X, wait for the return value and forward it. If the EVM interpreter itself needs to call a contract to execute operations like CALL, SLOAD, or SSTORE, the contract will respond directly.
A compromise solution would be to explicitly support the "virtual machine interpreter" concept at the protocol layer based on the second approach - requiring the interpreter logic to be written in RISC-V. EVM would be the first official interpreter, with potential future introduction of other types (such as a Move language interpreter).
The core advantage of the second and third approaches is significantly simplifying the execution layer specification. Considering that even incremental simplifications like removing SELFDESTRUCT are challenging, such transformations might be the only realistic path to achieving simplification. The Tinygrad project strictly limits code volume to never exceed 10,000 lines, and the ideal blockchain base layer should pursue even more extreme simplicity. Beam Chain plans to point the direction for Ethereum consensus layer simplification, and for the execution layer to achieve a similar breakthrough, perhaps only through such fundamental changes.
Disclaimer: As a blockchain information platform, the articles published on this site represent only the personal views of the authors and guests, and are unrelated to Web3Caff's stance. The information in the article is for reference only and does not constitute any investment advice or offer. Please comply with the relevant laws and regulations of your country or region.
