Source: Vitalik Buterin, Ethereum Magicians; Translated by: Tao Zhu, Jinse Finance
This article proposes a radical idea for the future of Ethereum's execution layer, which is as ambitious as Beam's efforts on the consensus layer. It aims to significantly improve the efficiency of Ethereum's execution layer, address one of the primary scaling bottlenecks, and potentially greatly simplify the execution layer - in fact, this might be the only way.
Idea: Use RISC-V as the virtual machine language for writing EVM smart contracts.
Important Clarifications:
Concepts like accounts, cross-contract calls, storage, etc., will remain exactly the same. These abstractions work well, and developers are accustomed to them. Opcodes like SLOAD, SSTORE, BALANCE, CALL will become RISC-V system calls.
In such a world, smart contracts can be written in Rust, but I anticipate most developers will continue to write smart contracts in Solidity (or Vyper), which will adapt to add 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 dev experience will change very little, and developers might hardly notice this change.
Legacy EVM contracts will continue to be valid and will be fully bidirectionally interoperable with new RISC-V contracts. There are several ways to achieve this, which I will elaborate on later in this article.
A precedent is Nervos CKB VM, which is essentially RISC-V.
Why Do This?
In the short term, the main bottlenecks of Ethereum L1 scalability will be addressed by upcoming EIPs, such as block-level access lists, delayed execution, and distributed historical storage, as well as EIP-4444. In the medium term, we will address further stateless and ZK-EVM challenges. In the long term, the primary limiting factors for Ethereum Layer 1 expansion are:
Stability of data availability sampling and historical storage protocols
Desire to maintain competitiveness in block production markets
ZK-EVM verification capabilities
I believe replacing ZK-EVM with RISC-V can solve a key bottleneck in (2) and (3).
This is the loop count table for Succinct ZK-EVM proving different parts of the EVM execution layer:
Four parts consume a significant amount of time: deserialize_inputs, initialize_witness_db, state_root_computation, and block_execution.
initialize_witness_db and state_root_computation are related to the state tree, while deserialize_inputs refers to the process of converting block and witness data to internal representation; thus, actually over 50% is proportional to witness size.
These parts can be heavily optimized by replacing the current 16-way Merkle patricia tree with a binary tree using 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. In summary, we have an opportunity to significantly reduce these components. As a bonus, we can get rid of accrue_logs_bloom by eliminating bloom.
What remains is block_execution, which takes about half of today's proving cycles. If we want to improve overall prover efficiency by 100 times, we cannot avoid the fact that we need to improve the EVM prover efficiency by at least 50 times. One thing we can do is try to create a more efficient EVM implementation in terms of proving cycles. Another thing we can do is note that ZK-EVM provers already work by proving EVM implementations compiled to RISC-V, and let smart contract developers directly access that RISC-V VM.
Some data suggests that in limited cases, this can improve efficiency by over 100 times:
In reality, I expect the remaining proving time to be mainly dominated by today's precompiles. If we use RISC-V as the primary VM, the gas schedule will reflect proving time, so there will be economic pressure to stop using more expensive precompiles; but even so, the gains will not be as impressive, but we have good reason to believe the gains will be very significant.
(Incidentally, the roughly 50/50 split between "EVM" and "everything else" also appears in regular EVM execution, and we intuitively expect that the benefits of removing EVM as a "middleman" should be similarly large)
Implementation Details
There are multiple ways to implement such a proposal. The least disruptive method is to support two virtual machines and allow contracts to be written in either. Both types of contracts can use the same type of facilities: persistent storage (SLOAD and SSTORE), ability to hold ETH balance, ability to make and receive calls, etc. EVM and RISC-V contracts can freely call each other; from the RISC-V perspective, calling an EVM contract looks like making a system call with some special parameters; the receiving EVM contract will interpret this as a CALL.
From a protocol perspective, a more radical approach is 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, that contract would be replaced with top-level logic that, when called externally with call parameters D, calls X with (C, D), then waits for the return value and forwards it. If the EVM interpreter itself calls a contract requiring a CALL or SLOAD/SSTORE, the contract would do so.
A middle ground is to adopt the second option but create an explicit protocol feature for it - basically, elevating the concept of a "VM interpreter" and requiring its logic to be written in RISC-V. EVM would be the first, but there might be others (for example, Move 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 might be the only viable method, because even incremental simplifications like removing SELFDESTRUCT are very difficult. Tinygrad has a strict rule that code volume never exceeds 10,000 lines; the best blockchain base layer should be able to accommodate these boundaries, or even smaller. Beam's efforts hold great promise for significantly simplifying Ethereum's consensus layer. But for the execution layer to achieve similar gains, this radical change might be the only viable path.
