jakiro
Source: Vitalik Buterin, Ethereum Magicians; Compilation: Tao Zhu, Bitchain Vision
This article presents an aggressive idea for the future of Ethereum’s execution layer, which is as ambitious as the Beam Chain’s efforts toward the consensus layer.It aims to significantly increase the efficiency of the Ethereum execution layer, solve one of the major scaling bottlenecks, and also greatly improve the simplicity of the execution layer—in fact, this is perhaps 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 get used to them.SLOAD, SSTORE, BALANCE, CALL and other opcodes will become RISC-V system calls.
-
In a world like this, smart contracts can be written in Rust, but I expect most developers to continue writing 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 change in devex is small, and developers may hardly notice this change.
-
Old-style EVM contracts will continue to be valid and will be fully bidirectional interoperable with the new RISC-V contracts.There are several ways to do this, which I will cover later in this article.
One precedent is the Nervos CKB VM, which is basically RISC-V.
Why do this?
In the near term, the major bottlenecks in Ethereum L1 scalability will be addressed with upcoming EIPs such as block-level access lists, latency execution and distributed historic storage, and EIP-4444.In the medium term, we will address further issues of statelessness and ZK-EVM.In the long run, the main limiting factors for Ethereum Layer1 expansion are:
-
Data availability sampling and stability of historical storage protocols
-
Hope to keep the block production market competitive
-
ZK-EVM verification capability
I think replacing ZK-EVM with RISC-V can solve a key bottleneck in (2) and (3).
This is the number of loops used by Succinct ZK-EVM to prove different parts of the EVM execution layer:
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 state trees, and deserialize_inputs refers to the process of converting blocks and witness data into internal representations; therefore, in fact, more than 50% is proportional to the witness scale.
These parts can be heavily optimized by replacing the current keccak 16-member Merkle patricia tree with a binary tree that uses prover friendly hash functions.If we use Poseidon, we can prove 2 million hashes per second on our laptop (and keccak hashes about 15,000 hashes per second).There are many other options besides Poseidon.All in all, we have the opportunity to drastically reduce these components.As a bonus, we can get rid of accrue_logs_bloom by getting rid of bloom.
The rest is block_execution, which accounts for about half of the proof cycle spent today.If we want to increase 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 try to create EVM implementations that are more efficient in proof cycles.Another thing we can do is note that the ZK-EVM prover has worked today by proving that EVM implementation compiled into RISC-V and gives smart contract developers direct access to that RISC-V VM.
Some data suggest that this can increase efficiency by more than 100 times in limited cases:
In fact, I expect the remaining proof time will be dominated by today’s precompilation.If we use RISC-V as the primary virtual machine, the gas plan will reflect the proof time, so there will be economic pressure to stop using more expensive precompilers; but even so, the benefits will not be so impressive, but we have good reason to believe that the benefits will be very significant.
(By the way, the approximately 50/50 split between “EVM” and “other stuff” also appears in regular EVM execution, and we intuitively expect that the benefits of removing from EVM as “the middleman” should be equally large)
Implementation details
There are several ways to implement such suggestions.The least disruptive approach is to support two virtual machines and allow contracts to be written in either virtual machine.Both types of contracts can use the same type of facilities: persistent storage (SLOAD and SSTORE), the ability to hold ETH balances, the ability to make and receive calls, etc.The EVM and RISC-V contracts are free to call each other; from the RISC-V point of view, calling the EVM contract seems to be making a system call with some special parameters; the EVM contract receiving the message interprets it as a CALL.
From a protocol perspective, a more radical approach is to convert an existing EVM contract to a contract that calls an EVM interpreter contract written in RISC-V, which runs its existing EVM code.That is, if the EVM contract has code C and the EVM interpreter is at address X, the contract will be replaced with top-level logic, when called from outside using the call parameter D, X is called with (C, D), and then wait for the return value and forward it.If the EVM interpreter itself calls the contract and requires running CALL or SLOAD/SSTORE, the contract does so.
The intermediate route is to take the second option, but create a clear protocol function for it – basically, the concept of “virtual machine interpreter” is taken as a guide and its logic is required to be written in RISC-V.EVM will be the first, but there may be others (for example, Move may be a candidate).
One of the main benefits of the second and third proposals is that they greatly simplify the execution layer specifications—in fact, this idea may be the only viable approach, as even a progressive simplification like removing SELFDESTRUCT is very difficult.Tinygrad has a strict rule that the code volume never exceeds 10,000 lines; the best blockchain foundation layer should be able to adapt well to these boundaries, even smaller.The beam chain efforts have great hope for greatly simplifying the consensus layer of Ethereum.But for the execution layer, this radical change may be the only viable way to get similar benefits.
