Vitalik's new proposal: RISC-V as a virtual machine language for EVM smart contracts

Source: Vitalik Buterin, Ethereum Magicians; Compiler: Tao Zhu, Golden Finance

This article proposes a radical idea for the future of Ethereum's execution layer, an idea that is as ambitious as Beam chain's efforts on the consensus layer.It aims to greatly improve the efficiency of Ethereum's execution layer, solve one of the main expansion bottlenecks, and also greatly improve the simplicity of the execution layer - in fact, this may be the only way.

Idea: Use RISC-V as the virtual machine language for writing EVM smart contracts.

Important clarification:

• The concepts of accounts, cross-contract calls, storage, etc. will remain exactly the same. These abstractions work well and developers are used to them. Opcodes such as SLOAD, SSTORE, BALANCE, CALL, etc. will become RISC-V system calls.

• In such a world, smart contracts could be written in Rust, but I expect most developers will continue to write smart contracts in Solidity (or Vyper), which will adapt to adding RISC-V as a backend. This is because smart contracts written in Rust are actually quite ugly, while Solidity and Vyper are much more readable. Perhaps the changes to devex are so minor that developers may barely notice the change.

• Old-style EVM contracts will continue to work and will be fully bidirectionally interoperable with new-style RISC-V contracts. There are several ways to do this, which I will describe later in this article.

One precedent is the Nervos CKB VM, which is basically RISC-V.

Why do this?

In the short term, the main bottlenecks to Ethereum L1 scalability will be addressed by upcoming EIPs such as block-level access lists, deferred execution, and distributed history storage, as well as EIP-4444. In the medium term, we will address further issues with statelessness and ZK-EVM. In the long term, the main limiting factors for Ethereum L1 scaling are:

• Data availability sampling and stability of history storage protocols

• Desire to keep the block production market competitive

• ZK-EVM verification capabilities

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

Here is a table of the number of cycles that Succinct ZK-EVM uses to prove different parts of the EVM execution layer:

Sponsored Business Content

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, and deserialize_inputs refers to the process of converting block and witness data into an internal representation; so in practice, more than 50% is proportional to the size of the witness.

These parts can be heavily optimized by replacing the current keccak 16-ary 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 for keccak). There are many other options besides Poseidon. All in all, we have the opportunity to significantly reduce these components. As a bonus, we can get rid of accrue_logs_bloom by getting rid of bloom.

What's left is block_execution, which accounts for about half of the proof cycles spent today. If we want to improve overall prover efficiency by 100x, then we can't get around the fact that we need to make the EVM prover at least 50x more efficient. One thing we can do is try to create an EVM implementation that is more efficient in terms of proof cycles. Another thing we can do is to note that the ZK-EVM prover already works today by proving an EVM implementation compiled to RISC-V, and giving smart contract developers direct access to that RISC-V VM.

Some data suggests that this can lead to over 100x efficiency gains in limited cases:

In practice, I expect the remaining proof times to be dominated by today's precompiles. If we were to use RISC-V as the primary VM, then the gas schedule would reflect the proof times, so there would be economic pressure to stop using more expensive precompiles; but even then the gains would not be as impressive, but there is good reason to believe that the gains would be significant.

(Incidentally, the roughly 50/50 split between "EVM" and "something else" also occurs in regular EVM execution, and we intuitively expect that the gains from removing the EVM as a "middleman" should be equally large)

Implementation Details

There are multiple ways to implement such a proposal. The least disruptive approach would be to support two VMs, and allow contracts to be written in either VM. Both types of contracts would have access to the same types of facilities: persistent storage (SLOAD and SSTORE), the ability to hold ETH balances, the ability to make and receive calls, etc. EVM and RISC-V contracts would be able to call each other freely; from the RISC-V perspective, calling an EVM contract would appear to be making a system call with some special arguments; an EVM contract receiving that message would interpret it as a CALL.

A more radical approach from a protocol perspective would be to convert existing EVM contracts into contracts that call an EVM interpreter contract written in RISC-V, which runs its existing EVM code. That is, if an EVM contract has code C, and the EVM interpreter is at address X, then the contract would be replaced with top-level logic that, when called from the outside with call arguments D, calls X with (C, D), then waits for the return value and forwards it. If the EVM interpreter itself calls the contract, asking it to run CALL or SLOAD/SSTORE, then the contract would do so.

A middle route would be to take the second option, but create an explicit protocol function for it - basically, enshrine the idea of ​​a "virtual machine interpreter" and require its logic to be written in RISC-V. EVM would be the first, but there could be others (Move, for example, could be a candidate).

A major benefit of the second and third proposals is that they greatly simplify the execution layer specification — in fact, this idea may be the only viable approach, as even incremental simplifications like removing SELFDESTRUCT are very difficult. Tinygrad has a strict rule that it should never be more than 10,000 lines of code; the best blockchain base layers should fit well within these boundaries, or even smaller. The Beamchain effort holds great promise for greatly simplifying Ethereum’s consensus layer. But for the execution layer, this kind of radical change may be the only viable path to similar gains.