Vitalik's new proposal: Replace the current EVM with RISC-V

This article presents a radical idea for the future of Ethereum’s execution layer that is as ambitious as the Beam chain’s efforts at the consensus layer. It aims to dramatically improve the efficiency of Ethereum’s execution layer, solve one of the major scaling bottlenecks, and also dramatically improve the simplicity of the execution layer – in fact, it may be the only way to do it.

Idea: Replace EVM with RISC-V as the virtual machine language for writing smart contracts (Translator’s note: RISC-V refers to an open instruction set architecture based on the principles of Reduced Instruction Set Computing, where V denotes the fifth generation of RISC).

Important clarification:

• Concepts such as accounts, cross-contract calls, and storage will remain completely the same. These abstractions work well, and developers are accustomed to them. Operations like SLOAD, SSTORE, BALANCE, CALL, etc., will become RISC-V system calls.
• In such a world, smart contracts can be written in Rust, but I expect that most developers will continue to write smart contracts in Solidity (or Vyper), which will adapt to adding RISC-V as the backend. This is because smart contracts written in Rust are actually quite ugly, while the readability of Solidity and Vyper is much higher. Perhaps the changes in devex are minimal, and developers may hardly notice this change.
• Legacy EVM contracts will remain valid and will be fully bi-directionally interoperable with the new RISC-V contracts. There are several ways to achieve this, which I will introduce later in this article.

An example is Nervos CKB VM, which is essentially RISC-V.

Why do this?

In the short term, the main bottleneck for Ethereum L1 scalability will be addressed by the upcoming EIPs, such as block access lists, delayed execution, and distributed historical storage, as well as EIP-4444. In the medium term, we will tackle further issues with statelessness and ZK-EVM. In the long term, the main limiting factors for Ethereum Layer 1 expansion are:

• Stability of Data Availability Sampling and Historical Storage Protocols
• Hope to maintain the competitiveness of the block production market
• ZK-EVM Verification Capability

I believe that replacing ZK-EVM with RISC-V can solve a key bottleneck in (2) and (3).

This is the loop count table for proving different parts of the EVM execution layer using Succinct ZK-EVM:

There are four parts that take up a lot of time: deserialize_inputs, initialize_witness_db, state_root_computation, and block_execution.

initialize_witness_db and state_root_computation are both related to the state tree, while deserialize_inputs refers to the process of converting block and witness data into an internal representation; therefore, in reality, over 50% is proportional to the scale of witnesses.

A significant optimization can be achieved for these components by replacing the current keccak 16 Merkle Patricia tree with a binary tree that uses a prover-friendly hash function. If we use Poseidon, we can prove 2 million hashes per second on a laptop (compared to about 15,000 hashes per second with keccak). There are many other options besides Poseidon. In summary, we have the opportunity to significantly reduce these components. As a bonus, we can eliminate accrue_logs_bloom by getting rid of bloom.

The remaining part is block_execution, which accounts for about half of the proof cycle spent today. If we want to improve the overall prover efficiency by 100 times, we cannot avoid the fact that we need to increase the EVM prover efficiency by at least 50 times. One thing we can do is to try to create a more efficient EVM implementation in terms of proof cycles. Another thing we can do is to note that the ZK-EVM prover is already working today by compiling proofs to a RISC-V EVM implementation and allowing smart contract developers direct access to that RISC-V VM.

Some data indicates that under limited conditions, this can improve efficiency by more than 100 times:

! JuLOouHUiv8vXajoUnYsOnYyFtRiCpO8cvkOUhPu.jpeg actually, I expect that the remaining proof time will be dominated by today’s precompilation. If we take RISC-V as the primary virtual machine, then the gas plan will reflect the proof time, so there will be financial pressure to stop using the more expensive precompilation; But even then, the gains won’t be so impressive, but we have good reason to believe that they will be significant.

(By the way, a roughly 50/50 split between “EVM” and “other things” also appears in regular EVM execution, and we intuitively expect that the gains from removing EVM as an “intermediary” should be equally large.)

Implementation Details

There are several ways to implement such recommendations. The least disruptive method is to support two virtual machines and allow contracts to be written in either one. Both types of contracts can utilize the same types of facilities: persistent storage (SLOAD and SSTORE), the ability to hold an ETH balance, the ability to make and receive calls, etc. EVM and RISC-V contracts can freely call each other; from the perspective of RISC-V, calling an EVM contract appears to be making a system call with some special parameters; the EVM contract receiving the message interprets it as CALL.

From a protocol perspective, a more radical approach is to convert the existing EVM contracts into contracts that call an EVM interpreter contract written in RISC-V, which runs its existing EVM code. In other words, if the 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, will call X using (C, D) and then wait for a return value to forward it. If the EVM interpreter itself calls a contract that requires running CALL or SLOAD/SSTORE, then the contract will do so.

The middle route adopts the second option, but creates a clear protocol function for it—essentially venerating the concept of “virtual machine interpreter” as a standard, and requiring its logic to be written in RISC-V. EVM will be the first, but there may also be others (for example, Move could be a candidate).

A MAJOR BENEFIT OF THE SECOND AND THIRD PROPOSALS IS THAT THEY GREATLY SIMPLIFY THE EXECUTIVE LAYER SPECIFICATION - IN FACT, THIS IDEA MAY BE THE ONLY WAY TO GO, AS EVEN PROGRESSIVE SIMPLIFICATIONS LIKE REMOVING SELFDESTRUCT ARE VERY DIFFICULT. Tinygrad has a strict rule that the amount of code should never exceed 10,000 lines; The optimal blockchain base layer should be able to adapt well to these boundaries, or even smaller. BeamChain’s efforts hold a lot of promise for greatly simplifying Ethereum’s consensus layer. But for the executive side, such a radical change may be the only viable way to achieve similar benefits.