Vitalik's Long-term L1 Execution Layer Proposal in Full: Replacing EVM with RISC-V
TechFlow Selected TechFlow Selected
Vitalik's Long-term L1 Execution Layer Proposal in Full: Replacing EVM with RISC-V
The goal is to significantly improve execution layer efficiency and simplicity, as well as突破 the scalability bottleneck.
Navigating Web3 tides with focused insightsSource: Vitalik Buterin
Translation: KarenZ, Foresight News
On April 20, Vitalik Buterin proposed a significant long-term vision for Ethereum's L1 execution layer on the Ethereum Magicians forum. He suggested replacing the existing EVM (Ethereum Virtual Machine) with the RISC-V architecture as the virtual machine language for writing smart contracts, aiming to fundamentally improve the efficiency of Ethereum’s execution layer, overcome one of its major scalability bottlenecks, and greatly simplify the execution layer.
Foresight News has fully translated this proposal to help readers understand this technical vision. Below is the translated content of the original proposal:
This article presents a radical idea about the future of Ethereum’s execution layer—ambitious in scope, comparable to the Beam Chain initiative on the consensus layer. The proposal aims to dramatically increase the efficiency of Ethereum’s execution layer, resolve one of its primary scalability bottlenecks, and significantly simplify the execution layer—indeed, it may be the only viable path toward achieving these goals.
Core Idea: Replace the EVM with RISC-V as the virtual machine language for writing smart contracts.
Important Notes:
-
Concepts such as accounts, cross-contract calls, and storage will remain unchanged. These abstractions work well and are already familiar to developers. Opcodes like SLOAD, SSTORE, BALANCE, and CALL will become system calls within the RISC-V environment.
-
In this model, smart contracts could be written in Rust, but I expect most developers will continue using Solidity or Vyper, which would adapt RISC-V as a new backend. Contracts written directly in Rust tend to be less readable, whereas Solidity and Vyper offer clearer, more accessible syntax. Developer experience would remain largely unaffected, and most developers might not even notice the change.
-
Legacy EVM contracts will continue to run and maintain full bidirectional compatibility with new RISC-V-based contracts. There are several ways to achieve this, which will be discussed later in the text.
Nervos CKB VM has already set a precedent—it is essentially a RISC-V implementation.
Why Do This?
In the short term, upcoming EIPs—such as block-level access lists, delayed execution, distributed historical storage, and EIP-4444—can address key scalability bottlenecks at Ethereum’s L1. Mid-term improvements will come from statelessness and ZK-EVMs. In the long run, however, the main constraints on Ethereum L1 scalability will be:
-
The stability of data availability sampling and historical storage protocols
-
The need to preserve competitive block production
-
The proving capability of ZK-EVMs
I argue that replacing ZK-EVM with RISC-V can alleviate critical bottlenecks in (2) and (3).
The table below shows the number of cycles required by Succinct’s ZK-EVM to prove various components of EVM execution:
Chart note: The four major time-consuming components are deserialize_inputs, initialize_witness_db, state_root_computation, and block_execution
Among these, initialize_witness_db and state_root_computation relate to the state tree, while deserialize_inputs involves converting blocks and witness data into internal representations—over 50% of which scales linearly with the size of witness data.
These parts can be significantly optimized by replacing the current keccak 16-ary Merkle Patricia Tree with a binary tree using a provable-friendly hash function. With Poseidon, for example, we could prove 2 million hashes per second on a laptop (compared to ~15,000 hash/sec for keccak). Besides Poseidon, many other options exist. Overall, there is substantial room for optimization in these components. Additionally, we can eliminate accrue_logs_bloom by removing bloom filters.
The remaining component, block_execution, accounts for roughly half of the current prover cycles. To achieve a 100x improvement in overall proving efficiency, EVM proving efficiency must improve by at least 50x. One approach is creating more efficient proving implementations for the EVM. Another is recognizing that current ZK-EVM provers already work by compiling EVM into RISC-V—so why not let smart contract developers directly access this underlying RISC-V virtual machine?
Some data suggests efficiency gains could exceed 100x in certain cases:
In practice, the remaining prover time may be dominated by current precompiles. If RISC-V becomes the primary VM, gas schedules can reflect actual proving costs, creating economic incentives for developers to avoid expensive precompiles. Even so, gains may not reach theoretical maximums—but we have strong reasons to believe they will still be substantial.
(Notably, in regular EVM execution, the time split between "EVM operations" and "other operations" is also close to 50/50, suggesting intuitively that removing the EVM as an "intermediate layer" could yield similarly significant gains.)
Implementation Details
There are multiple ways to implement this proposal. The least disruptive approach is to support both virtual machines simultaneously, allowing contracts to be written in either. Both types would have access to the same features: persistent storage (SLOAD/SSTORE), ETH balance holding, initiating/receiving calls, etc. EVM and RISC-V contracts could call each other—calling an EVM contract from RISC-V would appear as a system call with special parameters, while the receiving EVM contract would interpret the message as a CALL.
A more radical protocol-level approach would involve converting existing EVM contracts into calls to an EVM interpreter contract written in RISC-V, which runs their original EVM code. That is, if an EVM contract has code C and the EVM interpreter resides at address X, then the contract is replaced with top-level logic: when called externally with input D, it invokes X with (C, D), waits for the result, and forwards it. If the EVM interpreter itself calls back into the contract requesting a CALL or SLOAD/SSTORE operation, the contract executes those actions.
A middle-ground option adopts the above approach but explicitly introduces the concept of a “virtual machine interpreter” at the protocol level, requiring such interpreters to be implemented in RISC-V. The EVM would be the first instance, but others—such as Move—could follow.
The key advantage of the second and third approaches is that they could drastically simplify the execution layer specification. Given how difficult even incremental simplifications—like removing SELFDESTRUCT—have proven, this kind of structural shift may be the only feasible way forward. Tinygrad follows a strict rule of "no more than 10,000 lines of code," and ideal blockchain base layers should easily meet—and go beyond—this constraint. While the Beam Chain initiative promises to greatly simplify Ethereum’s consensus layer, similar progress on the execution layer may require exactly this kind of radical transformation.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@VitalikButerin
