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

The goal is to significantly improve the efficiency of the execution layer and its conciseness, as well as breakthrough the scaling bottlenecks.

Source:Vitalik Buterin

Compiled by: KarenZ, Foresight News

On April 20, Vitalik Buterin proposed an important proposal for Ethereum's long-term L1 execution layer 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 improve the operational efficiency of Ethereum's execution layer, break through one of the current main scaling bottlenecks, and significantly simplify the execution layer.

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

This article proposes a radical idea about the future of Ethereum's execution layer, with ambitions no less than the Beam Chain plan for the consensus layer. The proposal aims to significantly improve the efficiency of Ethereum's execution layer, address one of the main scaling bottlenecks, and significantly simplify the execution layer - in fact, 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:

• Concepts such as account system, cross-contract calls, and storage will be completely preserved. These abstract designs work well and developers are already accustomed to using them. Opcodes like 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 anticipate that most developers will continue to use Solidity (or Vyper) to write contracts, with these languages adapting RISC-V as a 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 bidirectionally compatible with new RISC-V contracts. 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 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 solve the main scaling bottlenecks of Ethereum L1. In the medium term, statelessness and ZK-EVM will solve more problems. In the long term, the main limiting factors for Ethereum L1 scaling will become:

1. Stability of data availability sampling and historical storage protocols
2. The need to maintain competitiveness in block production markets
3. Proof capabilities of ZK-EVM

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