EVM 2.0: Why Blockchains Are Converging on RISC-V as the Next Smart Contract Bytecode
Current state of Ethereum Virtual Machine
For over a decade, the Ethereum Virtual Machine (EVM) has been the backbone of decentralized computation — powering millions of smart contracts and enabling the rise of decentralized applications. Its simple, stack-based architecture made it approachable and extensible, fueling the explosive growth of the Ethereum ecosystem.
However, as blockchain technology matured, the limitations of the EVM became increasingly apparent. High gas costs, difficulties with formal verification, and inefficient execution models have all exposed the cracks in its once-revolutionary design.
The EVM worked well in its early years as Ethereum’s execution environment. But the advent of rollups, parallelized blockchains, and zero-knowledge systems now demands a more efficient and verifiable virtual machine. Competing designs such as the SVM (Solana Virtual Machine) and MVM (Move Virtual Machine) showcase alternative philosophies — from parallel execution to resource-based safety — that make the legacy EVM look increasingly dated.
That said, the EVM remains dominant today, serving billions of transactions and wallets across multiple chains. Yet, the opportunity for innovation is clear — we can do better.
Vitalik’s Proposal for the Long-term L1 execution layer
With those problems in mind, the co-founder of Ethereum, Vitalik Buterin, has published a proposal on the Ethereum Magician’s discussion forum to discuss what a reasonable future for Ethereum’s execution layer is. The idea of the proposal is to replace the EVM with RISC-V as the virtual machine language. Long-term L1 execution layer proposal: replace the EVM with RISC-V
This idea isn’t unique to Ethereum. Across the blockchain landscape, RISC-V has been gaining attention as a potential next-generation execution environment.
In 2023, core developers in the Polkadot ecosystem discussed exploring RISC-V as an alternative to WASM for executing smart contracts. The discussion — Exploring alternatives to WASM for smart contracts — reflected similar motivations: simplification, performance, and verifiability. (For more, see the resource repository I compiled on the transition from WASM to PolkaVM for the upcoming JAM era: learn-jam).
The Nervos CKB blockchain has already implemented a RISC-V-based VM, demonstrating the feasibility and advantages of adopting RISC-V as a base instruction set for blockchain computation. Learn more about Nervos here.
The proposal itself is highly technical, and it wouldn’t be practical to dive into every low-level detail of the suggested changes within this article. On a high level, Vitalik mentions these key problems and changes to the current design.
Why are changes needed?
The current EVM is packed with precompiles, which increase the complexity when adding new features to the EVM. Compared with a simple blockchain like Bitcoin, the EVM is more general-purpose and complicated. (Reference: Simplifying the L1)
RISC-V provides a compelling alternative.
It is a standardized virtual machine language, similar in concept to EVM bytecode, but designed with minimalism (~47 base instructions) and backed by a mature LLVM ecosystem (Rust, C++, Go).
Other advantages of using RISC-V as the execution layer include:
Better tooling and developer familiarity.
Easier integration with zero-knowledge proving systems.
A strong path toward long-term optimization and formal verification.
More than that, RISC-V is an important piece for the zkEVM (Reference: Instruction Set Architecture -Ethereum zkEVM book). As mentioned in the handbook of the zkEVM, RISC-V brings a strong tooling ecosystem and developer familiarity. Different from the EVM bytecode, RISC-V is used widely in system programming as well.
How the VM migration will be executed?
Opcodes Evolve, Core Concepts Remain
This is a breaking change to the current execution layer, but it does not eliminate the entire thing we currently have on the EVM. Concepts of accounts, cross-contract calls, storage, etc, are not changed. But on a deeper level, like some Opcodes are eliminated and likely will be replaced by RISC-V syscalls (For reference only, RISC Linux syscall table).
RISC-V is compatible with smart contract languages
Developers can write smart contracts in Rust or in Solidity, but the expectation for the smart contract language would still be Solidity (or Vyper) as the common approach to writing smart contracts. Even though Rust is a strong and type-safe system language, it is not a beginner-friendly approach compared to scripting languages like Solidity and Vyper, which are relatively similar to JavaScript and Python.
As I am originally coming from the Polkadot ecosystem, the current design that Polkadot has for PolkaVM could be a good material to learn from how things would work if this proposal is passed.
Backward Compatibility is Ensured
Old-style EVM contracts will continue to work and will be fully two-way interoperable with new-style RISC-V contracts. There are a couple of ways to do this, which I will get into later in this post.
As confirmed by Vitalik, legacy smart contracts that are already deployed on Ethereum will continue to work without any changes. Think of it like Java bytecode evolving to run on modern JITs: the developer experience stays the same, but the engine underneath is radically better.
Vitalik also breaks it down further in Simplifying the L1 to identify the goal for a seamless VM transition, which does not break things but can still bring the EVM to a new state.
Lean Roadmap’s Execution Layer
Lean execution is EVM 2.0: a minimal, SNARK-friendly instruction set (possibly RISC-V; pronounced “risk five”), boosting performance while preserving EVM compatibility and its network effects - Lean Roadmap, Justin Drake: Lean Ethereum
A while ago, Elastic Hub also published an article about the Lean Roadmap and the vision of Justin Drake for the next decade of Ethereum’s protocol. In the aforementioned proposal, the execution layer will be replaced by RISC-V to tackle the challenging problems of the current EVM.
Ethereum’s move toward a RISC-V-based execution layer marks the next major evolutionary step for its virtual machine. The transition won’t abandon the EVM’s legacy but will refine it — simplifying the base layer, unlocking new performance potential, and positioning Ethereum for the next decade of innovation.