Vitalik Buterin—Ethereum’s co-founder and spiritual leader—has called for an epochal shift in Ethereum’s foundation. He proposes substituting Ethereum’s Virtual Machine (EVM) for RISC-V architecture to increase Layer 1 scalability. The proposal, which we covered in this blog post on April 20, 2025, addresses two of the main bottlenecks curbing Ethereum’s performance. Its purpose is to support increasing block production capacity and development of zero-knowledge (zk-EVM) functionality. This ambitious overhaul could redefine how Ethereum handles transactions and computations, potentially leading to a more efficient and scalable network.
Buterin's proposal directly addresses two major challenges currently hindering Ethereum's Layer 1 scalability. These range from continuing to maintain competitive block production to enhancing zero-knowledge (zk-EVM) capabilities. By switching to RISC-V, Buterin believes Ethereum can overcome these limitations and pave the way for greater efficiency and faster transaction processing.
The Promise of RISC-V
Buterin said switching to RISC-V as the main VM would move the needle on proving times a lot.
In practice, I expect that the remaining prover time will become dominated by what today are precompiles. If we make RISC-V the primary VM, then the gas schedule will reflect proving times, and so there will be economic pressure to stop using more expensive precompiles; but even still the gains won’t be quite this impressive, but we have good reason to believe they will be very significant. - Vitalik Buterin
This means that the economic incentives are going to be different. As a result, it will encourage adoption of more streamlined processes and drastically reduce time spent on verification.
Members of the Ethereum community have recognized the value of these improvements. Many think it would speed and simplify ZK proving by avoiding the headaches of EVM execution. This limitation would allow quicker transaction validation and increased overall network performance.
Concerns and Considerations
Though the proposal has made headlines across the globe, the cutting edge proposal has led to alarming reactions from Ethereum developers and experts within the Ethereum environment. Ben Adams objected, warning this was going to cause a performance hit on naive implementations on normal hardware.
The risk here is that ZK-proving may get better, but blockbuilding and execution will deteriorate significantly. - Ben Adams
This underscores a real trade-off, seen in many instances where one set of improvements may worsen performance in another area, needing thoughtful balancing and maximization.
Daniel Marin, who works on the TurboETH project, noted that virtualizing the EVM with RISC-V would be a useful short-term stop gap measure. He argues it’s not the right choice for verifiable computation. In his presentation, Marin pointed out that RISC-V was not originally designed with an eye toward verifiable computation. He did however propose that in the long term, more bespoke architectures would be more fit for purpose.
Adam Cochran agrees that simplifying Ethereum's execution layer using RISC-V has merit, especially for improving L1 performance. Cochran argues that replacing EVM with RISC-V, while a positive development, should not be Ethereum’s highest priority at this moment.
Implementation and Alternatives
While Buterin has identified a number of ways to implement the RISC-V proposal, he has created a blueprint for continued research and development. These recommendations provide a key starting point for developers seeking to explore and test the feasibility of this important transition.
In fact, Nexus is already working on a similar proposal. This is just one indication of a huge growing interest in avm – or alternative virtual machine architectures – across the Ethereum ecosystem. This parallel effort indicates that the community is really looking for cutting edge solutions to address scalability challenges.
Daniel Marin suggests that true scalability and maintainability will require better ISAs tailored for ZK computation and carefully verified compiler correctness. This approach makes clear the value in what is an ongoing practice of research and development. We need to be able to build more specialized efficient solutions for verifiable computation out there.
