- Vitalik Buterin proposes replacing the Ethereum Virtual Machine (EVM) with a RISC-V architecture.
- The idea could accelerate zero-disclosure proof-of-concept processing, but has sparked discussion about the impact on performance, ecosystem, and engineering complexity.
- The proposal is ambitious and has the potential to set a precedent for a fundamental redesign of Ethereum for the sake of making the execution environment more efficient.
April 20, 2025 Ethereum co-founder Vitalik Buterin has put forward a proposal that could be one of the most profound changes to the blockchain's architecture ever. The programmer is considering replacing the Ethereum Virtual Machine (EVM) with RISC-V, the standard instruction architecture used in modern processors.
According to Buterin, the idea aims to address a fundamental bottleneck in Tier 1 solutions that inhibits scalability and increases verification costs. Especially in the context of zero disclosure (ZK).
The Coinpaper team learned the developer's proposal and also analyzed the reaction of Ethereum programmers and users to the potential network redesign.
As of this writing, Ethereum is betting on scaling via a roadmap, oriented on rollups. That said, L1 remains a kind of foundation that should be as simple, verifiable, and efficient as possible. According to Buterin, further improvement of the execution level requires radical measures, as traditional EVM optimization attempts have reached their complexity limit.
For example, even the idea of removing the SELFDESTRUCT function sparked a long debate among developers. At issue was one of the key opcodes in the Solidity programming language that was used to revoke a contract, remove bytecode from Ethereum, and send any funds to a specified address.
SELFDESTRUCT was abolished after the Shanghai update was deployed, as required by the EIP-6049 proposal. And in doing so, the question was about a specific function, while the idea of replacing EVM with RISC-V is not just "technical tuning" but an attempt to rethink low-level runtime-level implementation.
Efficiency and verifiability
As Buterin stated, the key motivation for replacing EVMs is to dramatically improve performance and simplify verifiability of execution using the zk-SNARK cryptographic protocol. He noted that one of the fastest solutions on the network - Succinct zkEVM - spends the bulk of its verification time on four components:
- deserialize_inputs;
- initialize_witness_db;
- state_root_computation;
- block_execution.
The last of these, the execution of the EVM operations themselves, takes about 50% of the total time.
This is where EVM, according to the programmer, turns out to be the weak link. He is sure that this architecture loses a lot in terms of efficiency in terms of ZK application. Its complex logic, many additional instructions, and illogical structure make it "difficult to provably execute".
RISC-V, on the other hand, is an architecture with an open standard, an understandable instruction set and a generally accepted specification, Buterin noted. The developer believes it is suitable for building a provable VM, especially if you use hash functions (Poseidon, Rescue and others) and replace the existing Merkle tree (hash tree) with a simpler structure.
"Some numbers show that in limited cases this can yield efficiency improvements of more than 100 times," emphasized the Ethereum co-founder.
As the programmer noted, efficiency gains are particularly important in the context of danksharding and economic pressure to reduce compilation costs in tier-one solutions. In addition, the RISC-V architecture will allow gas costs to be tied to actual "proof-of-concept cost," rather than just computational cost as they are now, Buterin said.
Difficulties of transition
The Ethereum co-founder described several scenarios for realizing his idea. According to him, the mildest one is parallel support of two virtual machines: EVM and RISC-V. In this case, developers can write contracts on either platform, and the systems remain compatible;
The programmer emphasized that smart contracts are thus given the ability to freely "call" each other, regardless of the execution platform. This model preserves interoperability and reduces the risk of a "gap" in the ecosystem.
The second, more radical approach is to use an EVM interpreter written in RISC-V. In this case, the existing Ethereum Virtual Machine smart contracts are converted into some form of additional solution call. This interpreter, according to Buterin's idea, will simplify the basic implementation of the execution layer and allow us to focus on uniformity.
The third way is to fix at the protocol level the concept of a "virtual interpreter" implemented on RISC-V. EVM will be the first such solution, but later, according to the programmer, it will be possible to add others. As an example, he mentioned projects based on the Move language. The developer noted that this approach brings the Ethereum architecture closer to a modular, extensible model with formalized VMs and a single runtime language.
"The key advantage of the second and third proposals is that they greatly simplify runtime level specification - in fact, this type of idea may be the only practical way to implement something like this," Buterin wrote. ;
When there are enough "buts" ;
The proposal has sparked an active discussion among Ethereum developers and users. Programmer Ben Adams noted that moving to a 64-bit architecture such as RISC-V could degrade the actual runtime performance on x86/ARM CPUs;
In his opinion, there is a risk of problems with low-level code when it is translated back into SIMD instructions (instruction stream). This will lead to increased overhead in block mining, Adams allowed.
A developer under the pseudonym pcaversaccio asked a different question.
"Is there a risk that even if the proof of basic instructions becomes faster, the necessary additions could become new bottlenecks? Essentially new hot spots that dominate proof times?" asked Adams
CEHV Foundation partner Adam Cochran was also not left out. He raised the topic of project priorities. According to his thoughts, efforts to improve the level of execution in the Layer 1 network in isolation from the development of L2 solutions may run counter to Ethereum's overall strategy. Cochran suggested focusing on more comprehensive and coherent solutions, from dunksharding to unified cryptography.
In addition, Nexus Labs developer Daniel Marin remembered that RISC-V was not designed for verifiable computing. A new ISA standard specialized for ZK, like TinyRAM, may need to be created.
In his opinion, formal proof of correctness of the VM and all supporting mechanisms will be needed for a full-fledged transition. As the developer noted, the main problem is that this requires many years of work.
Social network X (formerly Twitter) was more optimistic about Buterin's proposal. Projects that already use RISC-V welcomed the idea. Among them are the Nervos Network, mentioned by the programmer himself, and the blockchain Polkadot. The latter created its own virtual machine based on this architecture.
The idea requires clarity
Moving to RISC-V is an ambitious idea that could be a milestone for Ethereum. According to Buterin, it promises radical simplification, increased efficiency, and faster processing of zero-disclosure evidence. However, at the same time, realizing such a transition raises complex engineering, strategic, and infrastructure issues;
As the aforementioned programmers noted, it is necessary to understand whether developers are willing to invest years in rethinking how the L1 runtime layer works.
Apparently, the answer to this question does not only lie on the technical plane. It requires the consent of the community and a change in Ethereum's goals for many years to come. In this context, Buterin's proposal is not so much a call to action as a reason to start a big discussion about the future of blockchain.
