"Vitalik’s Radical Proposal Explained: Why Replace EVM with RISC-V?"

Introduction
In a move that could redefine the future of Ethereum, co-founder Vitalik Buterin proposed in April 2025 replacing the Ethereum Virtual Machine (EVM)—the core of transaction processing and smart contract execution, with RISC-V as the new virtual machine language for writing smart contracts. The motivation behind Vitalik’s proposal was to optimize the execution layer and improve efficiency. This sparked debates among crypto enthusiasts and developers, raising questions about performance, limitations, and Ethereum’s long-term vision. But what would this shift really mean for the network?
What is RISC-V and why?
RISC-V (Reduced Instruction Set Computer – “Five”) is an open-source instruction set architecture (ISA), which is often described as the Linux of computer hardware. It's not a programming language, but rather a blueprint for building processors, defining the low-level instructions that chips understand and execute. RISC-V basically serves as the foundation for machine code which computers use to perform operations.
While the EVM has become a tangled web of opcodes over the years, RISC-V offers a fresh, streamlined foundation — it's lightweight, modular, and far easier to work with. That simplicity makes it a strong contender for long-term maintainability and performance tuning.
Vitalik proposed three reasons why this change is needed….
In the short term, Ethereum’s main scaling problems are being tackled by upcoming upgrades like better ways to access data in blocks, delaying some types of execution, and more efficient storage systems (including EIP-4444). In the medium term, Ethereum will improve further through stateless clients and zero-knowledge (ZK) technology like ZK-EVMs.
But in the long term, Ethereum’s growth will hit new limits, not from current bottlenecks but from deeper challenges like:
Making sure data availability and storage systems stay reliable
Keeping block production open and competitive
Improving how fast and efficiently ZK-EVMs can generate proofs
Potential Impact On The Ethereum Execution Layer
Vitalik outlined three key points that comes with this proposal:
1. "The concepts of accounts, cross-contract calls, storage, etc would stay exactly the same..."
What it means:
Even if the backend changes from EVM to RISC-V, the frontend abstractions stay the same:
You’d still have accounts, smart contracts, and ETH balances.
You’d still make **
CALL
**s to other contracts.You’d still use
SLOAD
/SSTORE
for reading/writing contract storage.
Everything developers are familiar with stays the same on the surface, even if it’s powered by a more efficient engine underneath.
2. "Smart contracts could be written in Rust, but most developers would keep using Solidity or Vyper..."
What it means:
Rust could become a direct option for writing smart contracts in a RISC-V world — because RISC-V is a standard instruction set that many compilers (like Rust’s) can target.
But most developers will likely stick with Solidity or Vyper, because:
They're designed specifically for smart contracts.
They’re more readable and higher-level, whereas Rust code for smart contracts tends to be clunky and verbose.
Toolchains for Solidity and Vyper would evolve to compile to RISC-V behind the scenes, so developers wouldn’t have to change much.
Overall dev experience ("devex") stays the same — so for most devs, the switch could feel almost invisible.
3. "Old-style EVM contracts will continue to work and will be fully interoperable with new-style RISC-V contracts..."
What it means:
Even if RISC-V becomes the new virtual machine:
Legacy EVM contracts won’t break.
RISC-V and EVM contracts will be able to call each other, pass data, share state, etc.
This ensures backward compatibility, smooth transitions, and protects the existing ecosystem.
Benefits Of This Proposal
As the demands on Ethereum grows, particularly with the increasing importance of ZK rollups and execution-layer efficiency, RISC-V offers a compelling alternative to traditional architectures. Its flexibility and performance advantages unlock new possibilities for the ecosystem. Below are three key benefits that highlight why this transition matters:
1. Improved Efficiency
Migrating to RISC-V introduces a cleaner, more optimized architecture that can directly enhance Ethereum's execution layer compared to the EVM. Its modular instruction set allows for leaner, more purpose-built processing, which reduces computational overhead and boosts throughput. This is especially relevant as Ethereum scales and demand on the network continues to grow.
2. Better ZK-EVM Performance
New technologies like the Zero-knowledge (ZK) proofs are a core part of Ethereum's long-term scalability strategy (ZK-EVM) and RISC-V is already used as a backend for proving systems. This means we're proving RISC-V programs anyway, and since many ZK-EVMs already convert EVM to RISC-V internally, why not cut out the middleman? Giving developers direct access to RISC-V could massively speed up proving times and make ZK rollups more efficient.
3. Better Developer Tooling And Language Support
RISC-V opens the door to writing contracts in more general-purpose languages like Rust or C, in addition to Solidity and Vyper. Developers would benefit from a mature tooling ecosystem with debugging, profiling, and testing tools that are already well-established in the native development world.
Challenges And Trade-Offs On This Proposal
While the proposal to replace the EVM with RISC-V offers solutions to existing bottlenecks, it’s not without its concerns — many of which have been actively debated within the Ethereum developer community. Some of the most pressing challenges include:
1. Low-Level Abstraction Concerns
One major concern is that RISC-V operates at a very low level — close to a physical CPU. Developers raised concerns that this could make the execution environment harder to optimize for Ethereum-specific needs. Unlike the EVM which was purpose-built for blockchain logic, RISC-V wasn’t designed with concepts like gas, deterministic execution, or smart contract safety in mind. This raises uncertainty that performance (especially for block building and execution) might initially degrade.
2. Interoperability with Existing EVM Contracts
Ethereum is home to millions of EVM-based contracts, many of which are deeply embedded in DeFi, NFTs, and infrastructure protocols. These contracts are used by thousands of users everyday and generate millions in revenue and ensuring seamless interoperability between EVM and RISC-V contracts is critical. While the proposal outlines solutions (like using RISC-V interpreters for EVM bytecode), ensuring this works reliably and securely is non-trivial and still needs thorough testing.
3. Security and Auditability
The EVM has been battle-tested for a decade now, and its quirks are well-known to auditors and developers. Introducing a new VM architecture would require the community to build a whole new set of security best practices, audit tools, and formal verification methods — all from scratch, because this new VM introduces the possibilities of writing smart contracts in Rust, C, C++ etc and this could cause friction for developers in the short term.
Conclusion
The proposal to replace the EVM to RISC-V as the core layer of Ethereum is a bold step in addressing the existing limitations of the chain, making new innovations like the ZK proofs, rollups to be easier to be built on. In addition to improving optimization and providing wider language support, this approach simplifies the Ethereum core layer and ensures long-term maintainability. However, there are trade-offs associated with this change. Developers will require time to adapt as well as new tools and best practices. Performance tuning and backward compatibility are still significant issues that need to be resolved among other possible concerns.
Although this adjustment won't occur right away, it shows that Ethereum's leadership is prepared to question presumptions, have a long-term perspective, and maintain its position as the number 1 chain over time. In the end, Ethereum might be better off constructing the new, one RISC-V instruction at a time, than patching up the old.
Subscribe to my newsletter
Read articles from 0xdonnie directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
