Ethereum's "V God" proposes the EVM shift to RISC-V, a scalable future or a risky reboot?

More than a year after the Dencun upgrade brought a significant boost to the second-layer network, and just a few months before the highly anticipated Fusaka release, Ethereum co-founder Vitalik Buterin proposed a bold idea. In an April forum post, he stated that the network could eventually replace its long-standing market maker Ethereum Virtual Machine (EVM) with the low-level open-source instruction set architecture RISC-V. This proposal sparked heated discussions in the community: RISC-V could provide faster zk-rollup proofs for Ethereum, but the challenges of migration include rewriting smart contracts and security resets. Is this the scalable future of Ethereum or a reckless reboot?

1. The Appeal of the New Foundation: Technical Advantages of RISC-V

For those who are unfamiliar, the EVM is the execution engine for all smart contracts on Ethereum. It converts Solidity code into machine-level instructions and governs how contracts interact. Since the birth of Ethereum, it has been a pillar of the platform. Therefore, when Buterin proposed the idea of replacing the EVM, it caused quite a stir in the community.

His reasoning is rooted in long-term scalability: he wrote, "The efforts of Beam Chain have tremendous potential for simplifying the consensus layer. But for the execution layer to gain similar benefits, such a radical change may be the only feasible path." Buterin believes that a RISC-V based Virtual Machine could significantly increase the speed of zero-knowledge proof generation by 100 times. This could fundamentally change the landscape of zk-rollups, which are seen as the best solution for Ethereum's secure scaling. RISC-V eliminates the need to convert code from Solidity to EVM and then to a format that supports zero-knowledge proofs, thereby simplifying proof generation and reducing computational costs.

The technical advantages of RISC-V are beyond doubt. It is open, customizable, and has already been applied in projects such as Nervos. It is also friendly to parallel execution and zero-knowledge applications. The anonymous developer Block.nm pointed out: "ZK-STARK and ZK-SNARK aggregations can reduce proof time and cost. Writing provable programs becomes easier through register-based execution."

2. Migration Challenges: A Complete Restart of the Ecosystem

However, proposing an idea is one thing, completely transforming the core of the Ethereum ecosystem is another. Stuart Popejoy, co-founder and CEO of the PoW Layer 1 blockchain Kadena, bluntly discussed the scale of this disruption: he told CryptoPotato, "A large-scale disruption is impossible in the short term because it cannot happen quickly. A 'better' system must run in parallel for years and accumulate the network effects of the EVM." The Chainweb EVM testnet of the Popejoy platform was recently launched. He believes that replacing the EVM is not like changing a database or upgrading a protocol. It's like asking the internet to replace HTTP; theoretically feasible, but practically absurd.

Integrating RISC-V into Ethereum is not just a software upgrade; it is a comprehensive reboot of the ecosystem. First, smart contracts are immutable. You cannot simply migrate them. As Popejoy explained, "The existing state is cryptographically bound to a specific address on the EVM." Rewriting the contracts from scratch will be mandatory, as will re-auditing the contracts. And there are deeper challenges involved: losing the security insights accumulated over a decade. "We will reset the security knowledge accumulated over ten years," Popejoy warned. "We have learned a lot about the EVM; all of that will become irrelevant."

Compatibility issues have also extended to the Layer-2 layer of Ethereum. The error proofs on Optimism and Arbitrum rely on Layer-1 executing EVM bytecode to verify rollup transactions. If the EVM is changed, it would undermine the performance of Layer-1. Popejoy pointed out: "You have to build a complete EVM interpreter with RISC-V. This goes against the intention of reducing costs and increasing speed." If this is not feasible, then L2 may be forced to become a sovereign chain, thereby splitting the ecosystem and undermining composability.

3. The Path Forward: Dual Virtual Machines and Incremental Improvements

Most experts agree: there is no clear dividing line. Some believe the only realistic solution is to support dual Virtual Machines for at least the next decade. New contracts can utilize the faster RISC-V architecture, while old contracts will continue to run on the EVM. Over time, if the advantages are apparent and the tools are powerful, developers may voluntarily migrate.

"The dual virtual machine support will provide flexibility for developers," Onuogu said. "It offers adaptable timing and ensures continuity." She emphasized that a gradual rollout is needed, similar to the introduction of zk-rollups, without disrupting existing applications. At the same time, L2 developers should be prepared. Block.nm recommends investing in modular architecture immediately, abstracting proof systems, decoupling settlement layers, and experimenting with alternative compilers like LLVM IR and WebAssembly. "Do not rely solely on Solidity," they warned.

But even with preparation, migration is not an easy task. Ethereum has tens of thousands of applications, billions of dollars in value, and millions of users. Each application has different dependencies. The new Virtual Machine must respect these relationships in some way, or there is a risk of splitting the community. However, the discussions around replacing the EVM reflect a larger truth: Ethereum must evolve.

Although the Dencun and Pectra upgrades have addressed critical bottlenecks, their scalability is currently still temporary. The underlying network is still plagued by complexity, slow execution, and monolithic design. As Buterin and others have pointed out, long-term sustainability may require a simpler and clearer architecture, especially as competitors like Solana, Sui, and modular rollup frameworks are eroding Ethereum's dominance.

It is precisely for this reason that proposals like EIP-7983, which restrict the Gas usage per transaction, have been able to thrive. These proposals promise greater predictability, faster block propagation, and better support for zero-knowledge proof execution, while minimizing interference. These incremental improvements reflect the emerging design concept of Ethereum: to simplify as much as possible and to retain when necessary.

However, RISC-V is not a panacea. As Popejoy mentioned, it may never replace the EVM. But it opens the door for experimentation. If Ethereum wants to maintain its position as the world's leading programmable blockchain, it cannot remain stagnant on its original stack.

"The evolution of Ethereum is not meant to replace everything we have already built," Onuogu summarized. "Rather, it is to carefully and openly construct the future, with a focus on the entire ecosystem."

Conclusion:

RISC-V on Ethereum is an ambitious proposal aimed at enhancing the performance and security of Ethereum to meet future challenges. Although the migration process is fraught with challenges, the potential gains, especially in zk-rollup proof improvements, could pave the way for a scalable future for Ethereum. This technological innovation will test the consensus and execution capabilities of the Ethereum community, but its ultimate goal is to ensure that Ethereum maintains its leading position in the ever-changing blockchain landscape.

ETH2.7%
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • Reward
  • Comment
  • Share
Comment
0/400
No comments
Trade Crypto Anywhere Anytime
qrCode
Scan to download Gate app
Community
English
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)