Why did both Polkadot and Vitalik choose RISC-V independently?

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 of Ethereum with RISC-V.

Meanwhile, Polkadot has quietly launched a smart contract execution environment supporting RISC-V on the AseetHub Westend test network, allowing developers to continue using Solidity for development on Polkadot, although the contracts ultimately run on a brand 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 have both placed bets on RISC-V. What exactly do they see in it?

From chips to Blockchain, why has RISC-V emerged?

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's M chips use the ARM architecture.

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

It was originally an academic project at the University of California, Berkeley, and now an increasing number of chip companies recognize this architectural standard: it is simple in structure, flexible and customizable, available as open source, and can also mitigate risks brought by geopolitical issues.

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

A virtual machine (VM) is the "executive brain" of each blockchain, and all contracts must run on it. 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 model designed in 2015, making it difficult to align with modern CPUs. · Poor security, existing architecture is difficult to formalize verification, and cannot achieve true mathematical code security. · Multilingual support is limited, and developers cannot freely choose languages, but can only passively rely on the Solidity stack.

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

Stack-based vs Register-based Computing Model Comparison Diagram Ethereum's Choice: From Concept to Designing the Next Generation of ZK Native Virtual Machines

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

According to his description on the Ethereum Magicians forum, his vision is that the execution layer of Ethereum in the future should be minimal, secure, and mathematically provable. The EVM has become too complex and cannot be modified. Instead, it would be better to use RISC-V to build a completely new verifiable VM.

RISC-V has a clear structure 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 richer languages like Rust and C; more importantly, it can serve as the foundational execution layer for building "ZK native chains."

Of course, all of this is still in the conceptual stage. The Ethereum community currently has no concrete plans, but the direction is clear: it is not just about changing the virtual machine, but preparing for a future scalable, secure, and trustworthy Blockchain.

The path of Polkadot: Engineer-driven realism starting from the replacement of the underlying layer.

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 · The tools remain the same, Remix, Ethers.js, and MetaMask are all compatible. · Adjusted the compilation path, using the revive tool to compile Solidity into RISC-V bytecode. · Ultimately run on the new virtual machine PolkaVM, providing more efficient, secure, 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 aim of launching on Polkadot in Q3 2025. Developer's Perspective: The code you write remains unchanged, but the underlying structure is quietly being restructured.

Although Ethereum and Polkadot take different paths regarding RISC-V, one is ahead in vision while the other has already implemented it, the signal they send to developers is surprisingly consistent: this is not a transformation of the "writing layer", but a reconstruction of the underlying infrastructure.

For developers, regardless of which chain you are on, the sense of fragmentation is almost nonexistent 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 largely the same, everything feels as it did before.

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

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 the traditional EVM, PolkaVM performs better in execution efficiency and resource billing, especially 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 clearly stated that if we want to achieve truly mathematically provable on-chain execution logic in the future, the EVM is an unavoidable obstacle, while the clearly structured and predictable RISC-V is the ideal solution path.

More importantly, this architectural layer replacement is far more than just a performance improvement— a fundamental shift in the on-chain development paradigm is quietly taking place.

Security will shift from "human oversight" to "mathematically verifiable." Every instruction behavior of RISC-V can be formally modeled, which is beyond the reach of EVM. This means that future contract security will no longer rely on annual audits, but can obtain mathematical backing of "I won't make mistakes" at the compilation stage. You can write trustless code simply because "it can be proven."

Zero knowledge is moving from niche to default. In the past, writing ZK contracts was a skill only senior engineers could master. The RISC-V architecture itself is zk-friendly, with a structured execution process that easily transforms into circuits, making it a natural ideal backend for systems like zkEVM. Once the underlying switch is complete, ZK contracts may no longer be an option 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 be naturally compiled into formats that run on-chain. 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, which indicates that a contract world where different languages coexist is a reality, not a fantasy.

Written at the end

No matter which chain you are on now, whether you are using Solidity or Rust, writing contracts on Remix, or calling the front end 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 rebuilding of the foundation is never the first thing to be seen. But it will ultimately have an impact: future smart contracts will become stronger, freer, and more trustworthy without you even realizing it.

Reference link of this article: