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 regarding Ethereum's long-term L1 execution layer on the Ethereum Magicians platform. He suggested replacing the existing EVM (Ethereum Virtual Machine) with the RISC-V architecture as the virtual machine language for writing smart contracts, aiming to fundamentally enhance the operational efficiency of Ethereum's execution layer, break through one of the current major scalability bottlenecks, and significantly simplify the execution layer's design.

Foresight News has compiled the full text of this proposal to help readers understand this technical concept. Below is the compiled content of the original proposal:

This article presents a radical idea about the future of Ethereum's execution layer, with ambitions comparable to the consensus layer's Beam Chain plan. The proposal aims to significantly improve the efficiency of Ethereum's execution layer, address one of the major scalability bottlenecks, and greatly simplify the execution layer—indeed, this may be the only way to achieve this goal.

Core Concept: Replace EVM with RISC-V as the virtual machine language for writing smart contracts.

Important Notes:

• The account system, cross-contract calls, storage, and other concepts will be fully retained. These abstract designs work well and developers are accustomed to using them. Opcodes like SLOAD, SSTORE, BALANCE, CALL, etc., will be transformed into RISC-V system calls.
• In this model, 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 almost unaffected, and developers may not even notice the change.
• Old EVM contracts will continue to run and will be fully bi-directionally compatible with the 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, which is essentially a RISC-V implementation.

Why Do This?

In the short term, 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 Ethereum L1 scalability will become:

1. The stability of data availability sampling and historical storage protocols
2. The need to maintain competitiveness in the block production market
3. The proof capabilities 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 Succinct ZK-EVM to prove each part of the EVM execution layer:

Chart Explanation: The four main time-consuming parts are deserializeinputs, initializewitnessdb, staterootcomputation, and blockexecution.

Among these, initializewitnessdb and staterootcomputation are related to the state tree, while deserialize_inputs involves the process of converting block and witness data into internal representations—actually over 50% is proportional to the size of the witness data.

By replacing the current keccak 16-ary Merkle Patricia tree with a binary tree using easily provable hash functions, these parts 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 accruelogsbloom by removing bloom.

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

Some data shows that efficiency improvements may exceed 100 times in specific cases:

In practical applications, the remaining prover time may mainly be occupied by current precompiled 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 considerable.

(Note that in regular EVM execution, the time consumption ratio of "EVM operations" to "other operations" is also close to 50/50, so we intuitively believe that removing EVM as an "intermediate layer" will bring equally significant gains.)

Implementation Details

There are various ways to implement this proposal. The least disruptive option is to support both virtual machines simultaneously, allowing contracts to be written in either. 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—viewed from RISC-V, calling an EVM contract is equivalent to executing a system call with special parameters; while the EVM contract receiving the message will interpret it as CALL.

A more radical approach from a protocol perspective is to convert existing EVM contracts to call EVM interpreter contracts written in RISC-V, running their existing EVM code. That is, if an EVM contract has code C and the EVM interpreter is located at address X, then the contract will be replaced with top-level logic that, when called externally with parameters D, calls X and passes (C, D), then waits for the return value and forwards it. If the EVM interpreter itself calls the contract, requesting to execute CALL or SLOAD/SSTORE, then the contract executes those operations.

A compromise solution is to adopt the second option 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 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 can greatly simplify the execution layer specification. Considering that even the removal of something like SELFDESTRUCT as a progressive simplification is fraught with difficulties, this line of thinking may be the only feasible path to simplification. Tinygrad follows a strict rule of "no more than 10,000 lines of code," and the optimal blockchain infrastructure should easily meet this limit and further streamline. The Beam Chain plan is expected to significantly simplify Ethereum's consensus layer, and if the execution layer wants to achieve similar improvements, such a radical transformation may be the only viable path.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。