- Vitalik Buterin has proposed swapping Ethereum’s current Virtual Machine (EVM) with RISC-V to boost scalability and efficiency
- The proposed change could dramatically speed up zero-knowledge proof systems, improving performance by over 50 times
- Buterin’s plan retains support for current contracts while enabling a more modern, hardware-friendly execution environment
Ethereum co-founder Vitalik Buterin has floated a major update to the platform’s architecture: replacing its core execution engine—the Ethereum Virtual Machine (EVM)—with RISC-V, an open-source computer instruction set. This shift could vastly improve Ethereum’s performance, especially for technologies that rely on cryptographic proof systems. Crucially, the change would not break existing smart contracts or disrupt developer workflows, but the scale of the change has set alarm bells ringing within developer circles.
Understanding EVM vs. RISC-V
Ethereum currently uses the EVM, a purpose-built virtual machine designed in 2015 to execute smart contracts in a secure, platform-agnostic way. The EVM is optimized for Ethereum’s rules but isn’t particularly fast or efficient by today’s standards—especially when used in modern cryptographic systems like zero-knowledge proofs (ZKPs), which require simulating EVM execution in another virtual machine. This “double simulation” adds significant overhead.
RISC-V, on the other hand, is a general-purpose, low-level instruction set originally developed for computer hardware. Because it’s a real-world CPU architecture, it’s better supported by compilers and tools—and crucially, it’s much easier to simulate and prove mathematically, which is why many ZK systems already compile down to RISC-V internally. As Buterin points out, “ZK-EVM provers today already work by proving over implementations of the EVM compiled down to RISC-V.”
Why Replace the EVM?
The main motivation to replace EVM with RISC-V is performance. In current ZK rollups, most of the proving time is wasted simulating EVM behavior. By switching to RISC-V directly, Ethereum could potentially skip this inefficiency, resulting in 10x to 100x improvements in ZK proof generation times. This matters because ZK rollups are a central part of Ethereum’s scaling roadmap. Buterin also noted that most values used in Ethereum contracts are smaller than 256 bits and thus can be efficiently handled with standard RISC-V operations.
In his proposal on Ethereum Magicians, Buterin outlined three migration paths:
- Dual Support – run both EVM and RISC-V contracts in parallel, preserving full backward compatibility.
- EVM Wrapping – wrap old EVM contracts in a layer that interprets them inside a RISC-V context.
- Enshrined Interpreters – hardcode interpreters for both models directly into Ethereum’s protocol, allowing more flexibility for future execution formats.
The first option is the least risky and likely most appealing to developers, while the others trade compatibility for simplicity and speed.
Real-World Implications
If adopted, this would mark one of the biggest changes to Ethereum’s technical foundation in its history, signaling a shift from a blockchain-specific virtual machine to a more universal computing standard that’s already widely used in hardware and research. However, this shift also introduces risks, such as the complexity of rewriting compilers, rethinking gas models, and ensuring the new system is as secure and stable as the EVM.
Still, Buterin’s framing is pragmatic: the goal isn’t radical disruption, but long-term optimization. As he puts it, “Developers might barely notice the change at all.” If successful, Ethereum could become both faster and easier to scale—without losing its massive base of smart contracts and dApps.
The Ethereum community has responded with a mix of interest and caution to Buterin’s RISC-V proposal: supporters highlight major performance gains and compatibility with existing tools, especially for zero-knowledge proof systems, while critics worry about the technical complexity, potential disruption to the Layer 2 roadmap, and the maturity of RISC-V-based infrastructure.
