Why did both Polkadot and Ethereum choose RISC-V?

Source: PolkaWorld

In the recent evolution of blockchain technology, a term that was originally popular only among chip engineers has quietly become the new favorite of blockchain developers: RISC-V.

On April 20, 2025, Ethereum founder Vitalik Buterin posted on the community forum Ethereum Magicians, proposing an exploratory suggestion to replace the long-used EVM virtual machine in Ethereum with RISC-V.

At the same time, Polkadot has quietly launched a smart contract execution environment that supports RISC-V on the AseetHub Westend test network, allowing developers to continue using Solidity to try developing on Polkadot, but the contracts ultimately run on a completely new execution engine called PolkaVM.

Is it a coincidence? Why has an open-source instruction set originally designed for chip design broken into the blockchain world?

Ethereum and Polkadot are both betting on RISC-V. What exactly do they see in it?

**From chips to blockchains, why did RISC-V come out? **

The "soul" of every computing device is its Instruction Set Architecture (ISA), which is the language that software uses to tell hardware what to do. The Intel CPUs we are familiar with use the x86 architecture, while Apple computers' M chips use the ARM architecture.

RISC-V is an open-source, free architecture standard that anyone can use to design CPUs without having to pay licensing fees to Intel or ARM.

It was originally an academic project at the University of California, Berkeley, and now more and more chip companies are recognizing this architectural standard: simple structure, flexible and customizable, available as open source, and able to avoid the risks brought by geopolitical issues.

But what is the relationship between RISC-V and blockchain?

A virtual machine (VM) is the "executive brain" of every blockchain, where all contracts must run. However, the mainstream virtual machine systems, such as Ethereum's EVM, Polkadot's WASM, and Solana's BPF, all have some obvious issues:

• The architecture is outdated, as EVM is a stack-based model designed in 2015, making it difficult to align with modern CPUs.
• Poor security, existing architecture is difficult to formally verify, and true mathematical code safety cannot be achieved.
• Multilingual support is limited, and developers cannot freely choose languages, but can only passively rely on the Solidity stack.

So, when the "modern" architecture of RISC-V appears before blockchain engineers, their instinct is: can we also "RISC-V-ify" the blockchain virtual machine?

Comparison chart of stack-based vs register-based computing models

The Choice of Ethereum: Conceptualizing the Next Generation of ZK Native Virtual Machines

Vitalik's ideas are very much in the style of the Ethereum community: not just simple optimization, but a redesign from a philosophical level.

According to his description on the Ethereum Magicians forum, his vision is that in the future, Ethereum's execution layer should be minimalist, secure, and mathematically provable. The EVM is already too complex to change. Why not use RISC-V to build a new verifiable VM.

RISC-V has a clear architecture and predictable execution behavior, making it very suitable for conversion into zero-knowledge proof circuits; in the future, it may also work with the LLVM compiler (although there are many comments about bugs), allowing for the development of contracts in more rich languages, such as Rust and C; more importantly, it can serve as the foundational execution layer for building "ZK native chains."

Of course, all this is still in the imagination stage. There are no plans for the Ethereum community to land yet, but the direction is clear: not just to change the virtual machine, but to prepare for a scalable, secure and trustworthy blockchain in the future.

Polkadot's Path: Engineer-Driven Realism Starting from Replacing the Underlying

Unlike Ethereum's "conceptual vision", Polkadot has chosen a more pragmatic approach.

As early as 2023, Parity's core engineer Jan Bujak began exploring alternatives to WASM and ultimately chose RISC-V, subsequently launching the PolkaVM project.

Polkadot's approach is very straightforward:

• The language remains unchanged, continue using Solidity
• Tools remain unchanged, Remix, Ethers.js, and MetaMask are all compatible.
• Compile path adjustment, using the revive tool to compile Solidity into RISC-V bytecode
• Ultimately runs on the new virtual machine PolkaVM, providing more efficient, safer, and verifiable execution capabilities.

This means that the developer experience remains largely unchanged, but the underlying execution has been completely overhauled. From WebAssembly to RISC-V, from stack-based to register-based, from traditional execution to ZK-friendly, this is a "quiet revolution."

Currently, PolkaVM can run on the Westend testnet of Asset Hub, with the goal of launching on Polkadot in Q3 2025.

!

Developer's Perspective: The code you write remains the same, but the underlying is quietly refactoring

Although Ethereum and Polkadot have different approaches to RISC-V, one being ahead in vision and the other already implemented, the signals they send to developers are surprisingly consistent: this is not a transformation at the "programming layer", but a reconstruction of the underlying infrastructure.

For developers, regardless of which chain you are on, there is almost no sense of fragmentation in the short term: you can still write contracts in Solidity, continue to use familiar tools like Remix, Ethers.js, MetaMask, and the deployment process is basically the same, everything remains unchanged.

But beneath the surface, the execution engine has already been upgraded!

In Polkadot, Solidity contracts can now be compiled into RISC-V bytecode using the revive tool and run on the new virtual machine PolkaVM. Compared to WASM and traditional EVM, PolkaVM shows better performance in execution efficiency and resource billing, especially being more friendly in controlling the running costs of complex contracts.

In the technical vision of Ethereum, RISC-V is also regarded as the most suitable foundation for a "ZK native chain." Vitalik has clearly stated that if we are to achieve truly mathematically provable on-chain execution logic in the future, the EVM is an insurmountable barrier, and RISC-V, with its clear structure and predictable behavior, is the ideal solution.

More importantly, this architectural change is far more than just a performance improvement — a fundamental shift in the paradigm of on-chain development is quietly occurring.

Security will move from "human staring" to "mathematically verifiable". Every instruction behavior of RISC-V can be formally modeled, which is beyond the reach of the EVM. This means that the future of contract security will no longer rely on audits year after year, but with the mathematical endorsement of "I can't go wrong" at the compilation stage. You can write code that doesn't require trust, just because "it's provable".

Zero-knowledge is moving from niche to default. In the past, writing ZK contracts was a skill that only advanced engineers could master. However, the RISC-V architecture itself is zk-friendly, with a structured execution process and easy circuit conversion, making it a natural ideal backend for systems like zkEVM. Once the underlying switch is completed, ZK contracts may no longer be optional but will become the "default security mode" for smart contracts.

The era of multilingual smart contracts is about to begin. RISC-V is connected to the LLVM tool ecosystem, which means that languages like Rust and C can naturally be compiled into on-chain running formats. You are no longer limited to Solidity; in the future, writing smart contracts will be as controllable and flexible as writing system modules. Polkadot is already promoting the migration of the ink! language to RISC-V, indicating that a contract world where different languages coexist is a reality, not a fantasy.

Final Thoughts

No matter which blockchain you are on right now, whether you are using Solidity or Rust, whether you are writing contracts on Remix or calling the frontend with Ethers.js, you will eventually realize: the evolution of the virtual machine is not to change the way you write code, but to make every line of code you write run faster, execute more stably, have clearer logic, and be more secure and trustworthy.

These changes may not be immediately apparent, just like the reconstruction of the foundation is never the first thing to be seen. But it will eventually have an impact: future smart contracts will become more powerful, more free, and more trustworthy without you even noticing.