Source: PolkaWorld
In the recent evolution of blockchain technology, a term that was originally only popular in the chip engineer circle has quietly become the new favorite of blockchain developers: RISC-V.
On April 20, 2025, Ethereum founder Vitalik Buterin posted a post on the community forum Ethereum Magicians, proposing an exploratory suggestion to use RISC-V to replace the EVM virtual machine that Ethereum has used for a long time.

https://ethereum-magicians.org/t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617
At the same time, Polkadot has quietly launched a smart contract execution environment that supports RISC-V on the AseetHub Westend testnet. Developers can even continue to use Solidity to try to develop on Polkadot, but the contract ultimately runs on a brand new execution engine PolkaVM.
Coincidence? Why did an open source instruction set originally designed for chip design "break the circle" in the blockchain world?
Ethereum and Polkadot both bet on RISC-V. What do they see behind it?

From chips to blockchain, why did RISC-V emerge?
The "soul" of every computing device is its instruction set architecture (ISA), which is the language that software tells the hardware "what I want you to do". The Intel CPU we are familiar with uses the x86 architecture, and the M chip of Apple computers uses 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. Now more and more chip companies have recognized this architecture standard: it has a simple structure, is flexible and customizable, can be used as open source, and can avoid geopolitical risks.
But what does RISC-V have to do with blockchain?
The virtual machine (VM) is the "executive brain" of each blockchain, and all contracts must run on it. But the current mainstream virtual machine systems, such as Ethereum's EVM, Polkadot's WASM, and Solana's BPF all have some obvious problems:
The architecture is old. For example, EVM is a stack model designed in 2015, which is difficult to align with modern CPUs
Poor security, the existing architecture is difficult to formally verify, and true mathematical-level code security cannot be achieved
Multi-language support is limited. Developers cannot choose languages freely and can only passively rely on the Solidity stack
So, when RISC-V, a "modern" architecture, appeared in front of blockchain engineers, their intuition was: Can we also "RISC-Vize" the blockchain virtual machine?


Comparison chart of stack vs register computing models
Ethereum's choice: Starting from the concept, envisioning the next generation of ZK native virtual machine
Vitalik's idea is very much in the style of the Ethereum community: It's not a simple optimization, but a redesign from a philosophical level.
According to his description on the Ethereum Magicians forum, his vision is: The execution layer of Ethereum in the future should be extremely simple, secure, and mathematically provable. However, EVM is already too complex and cannot be changed. It is better to use RISC-V to build a new verifiable VM.
RISC-V has a clear structure and predictable execution behavior, which is very suitable for conversion into zero-knowledge proof circuits; in the future, it may also cooperate with the LLVM compiler (although I have seen many comments about bugs) to develop contracts in richer languages, such as Rust and C; more importantly, it can become the execution layer foundation for building "ZK protogenesis chain".
Of course, all this is still in the conceptual stage. The Ethereum community has no implementation plan yet, but the direction is clear: It is not just about changing a virtual machine, but preparing for a scalable, secure and reliable blockchain in the future.
Polkadot's path: engineer-driven, realism starting from replacing the underlying layer
Different from Ethereum's "conceptual vision", Polkadot chose another pragmatic route.
As early as 2023, Jan Bujak, a core engineer at Parity, began exploring alternatives to WASM, and eventually chose RISC-V, and then launched the PolkaVM project.

https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811
Polkadot's approach is very straightforward:
The language remains unchanged, and Solidity will continue to be used
The tools remain unchanged, Remix, Ethers.js, and MetaMask are all compatible
The compilation path is adjusted, and Solidity is compiled into RISC-V bytecode through the revive tool
Finally, it runs on the new virtual machine PolkaVM, providing more efficient, safer and more verifiable execution capabilities.
This means that the developer experience remains basically unchanged, but the underlying execution has been completely replaced. 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, and the expected goal is to launch Polkadot in Q3 2025.

Developer perspective: The code you write remains unchanged, but the underlying layer is quietly reconstructed
Although Ethereum and Polkadot have different paths for RISC-V, one is ahead of the vision and the other is already in implementation, the signals they send to developers are surprisingly consistent: this is not a change in the "writing layer", but a reconstruction of the underlying infrastructure.
For developers, no matter which chain you are on, you will hardly feel a sense of separation in the short term: you can still write contracts in Solidity, continue to use familiar tools such as Remix, Ethers.js, MetaMask, and the deployment process is basically the same, everything is the same as before.
But at the bottom, the execution engine has been replaced!
In Polkadot, Solidity contracts can be compiled into RISC-V bytecode through the revive tool and run on the new virtual machine PolkaVM. Compared with WASM and traditional EVM, PolkaVM performs better in execution efficiency and resource billing, especially for the cost control of complex contracts.
In Ethereum's technical vision, RISC-V is also regarded as the most suitable base for the "ZK native chain". Vitalik made it clear that if the on-chain execution logic that can be truly proven by mathematics is to be realized in the future, EVM is an obstacle that cannot be circumvented, and RISC-V with a clear structure and predictable behavior is an ideal solution.
More importantly, this change in the architecture layer is far more than just a simple performance improvement - a fundamental shift in the on-chain development paradigm is quietly happening.
Security will move from "relying on people" to "mathematically verifiable". Every instruction behavior of RISC-V can be formally modeled, which is beyond the reach of EVM. This means that the security of future contracts will no longer rely on audits year after year, but can obtain mathematical endorsement of "I will not make mistakes" at the compilation stage. You can write code that does not require trust in people, just because "it can be proven."
Zero-knowledge has gone from niche to default. In the past, writing ZK contracts was a skill that only senior engineers could master. The structure of RISC-V itself is zk-friendly, with a regular execution process and easy circuit conversion. It naturally becomes the ideal backend for systems such as zkEVM. Once the underlying switch is completed, ZK contracts may no longer be optional, but will become the "default security mode" of smart contracts.
The era of multi-language smart contracts is about to begin. RISC-V is connected to the LLVM tool ecosystem, which means that languages such as Rust and C can naturally be compiled into on-chain formats. You are no longer limited to Solidity. In the future, writing smart contracts will be as controllable and free and flexible as writing system modules. Polkadot is already promoting the migration of ink! language to RISC-V, which shows that the 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 adjusting 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 steadily, have clearer logic, and be more secure and reliable.
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: the future smart contracts will become more powerful, freer, and more trustworthy without you noticing.