Full text of Vitalik's long-term L1 executive layer proposal: replacing the EVM with RISC-V

Source: Vitalik Buterin

Compilation: KarenZ, Foresight News

On April 20th, Vitalik Buterin presented an important proposal on the Ethereum Magicians platform for Ethereum's long-term L1 execution layer. He proposed replacing the existing EVM (Ethereum Virtual Machine) with the RISC-V architecture as a 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 major scaling bottlenecks, and greatly simplify the simplicity of the execution layer.

Foresight News has compiled the full text of the proposal to help readers understand this technical vision. The following is a compilation 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 idea: Replace EVM with RISC-V as a virtual machine language for smart contracts.

Important Notes:

• Concepts such as account system, cross-contract calling, storage, etc., will be fully retained. These abstract designs work well and developers are used to using them. OPCODES SUCH AS SLOAD, SSTORE, BALANCE, CALL, ETC., ARE CONVERTED INTO RISC-V SYSTEM CALLS.

• In this mode, smart contracts can be written in Rust, but I expect most developers to continue to write contracts in Solidity (or Vyper), which will adapt to RISC-V as the new backend. 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 barely affected, and developers may not even notice the change.

• The old EVM contract will continue to run and is fully bidirectionally compatible with the new RISC-V contract. There are several ways to do this, which will be discussed in more detail later in this article.

Nervos CKB VM has set a precedent and is essentially a RISC-V implementation.

Why?

In the short term, upcoming EIPs (e.g., block-level access lists, deferred execution, distributed history storage, and EIP-4444) will address the major scaling bottlenecks of Ethereum L1. More problems will be solved in the medium term with statelessness and ZK-EVM. 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. Maintain the demand for competition in the block production market

3. Proof of the ZK-EVM

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

The following table illustrates the number of cycles required for each step of the Succinct ZK-EVM Proof EVM execution layer:

Diagram description: The four main time-consuming segments are deserialize_inputs, initialize_witness_db, state_root_computation, and block_execution

initialize_witness_db and state_root_computation are related to state trees, and deserialize_inputs involve the process of converting block and witness data into internal representations – more than 50% of which is actually proportional to the size of the witness data.

These sections can be greatly optimized by replacing the current keccak 16-ary Merkle patricia tree with a binary tree that uses an easy-to-prove hash function. If we use Poseidon, we can prove 2 million hashes per second on a laptop (compared to about 15,000 hash/sec for keccak). In addition to Poseidon, there are many other options. Overall, there is a lot of room for optimization for these components. In addition, 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 100x increase in overall proof efficiency, an EVM proof efficiency of at least 50x is required. One solution is to create a more efficient proof implementation for the EVM, and the other is to notice that the current ZK-EVM prover actually compiles the EVM to RISC-V for proof, giving smart contract developers direct access to the RISC-V virtual machine.

Some data shows that efficiency gains of more than 100 times can occur in certain situations:

In practice, the remaining prover time may be mostly occupied by the current precompile operation. With RISC-V as the primary VM, the gas schedule will reflect the actual proof time, and the economic pressure will drive developers to reduce the use of high-cost precompilation. Even then, the gains won't be so significant, but we have good reason to believe that they will be substantial.

(It's worth noting that the time taken for "EVM operations" and "other operations" in regular EVM execution is also close to 50/50, so we intuitively assume that removing the EVM as an "intermediate layer" will bring an equally significant gain.)

Implementation details

There are several ways to implement this proposal. The least disruptive solution is to support both virtual machines and allow the contract to be written in one of them. Both types of contracts have access to the same features: persistent storage (SLOAD/SSTORE), the ability to hold ETH balances, initiate/receive calls, and more. EVM and RISC-V contracts can be called to each other - from a RISC-V perspective, calling the EVM contract is equivalent to executing a system call with special parameters; The EVM contract that receives the message will interpret it as a CALL.

A more radical approach from a protocol perspective is to convert an existing EVM contract to a call to 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), 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 is the second option, but with explicit support for the concept of a "virtual machine interpreter" through a protocol that requires its logic to be written in RISC-V. EVM will be the first instance, with support for other languages in the future (Move may be a candidate).

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 rule of "no more than 10,000 lines of code", and the optimal blockchain underlying should be able to easily meet this limit and streamline it further. 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.