Source: PolkaWorld
In the recent evolution of blockchain technology, a noun that was originally only popular in the circle of chip engineers has quietly become the new favorite of blockchain developers:RISC-V。
On April 20, 2025, Ethereum founder Vitalik Buterin published an article on the community forum Ethereum Magicians, proposing a useExploring suggestions for RISC-V to replace Ethereum’s long-used EVM virtual machines。
https://ethereum-magicians.org/t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617
And at the same time,Polkadot has quietly launched a smart contract execution environment that supports RISC-V on the AseetHub Westend test network, developers can even continue to use Solidity to try to develop in Polkadot, except that the contract ends up running on a brand new execution engine, PolkaVM.
A coincidence? Why did an open source instruction set originally created for chip design "break the circle" in the blockchain world?
Ethereum and Polkadot both bet on RISC-V, what do you like behind it?
From chips to blockchain, why did RISC-V come out?
The "soul" of every computing device is its instruction set architecture (ISA), which is the language in which software tells the hardware "what I want you to do." The Intel CPU we are familiar with uses the x86 architecture, while the M chip of Apple computers uses the ARM architecture.
And RISC-V is an open source, free architectural standard, anyone can use it to design a CPU without paying licensing fees to Intel or ARM.
It was originally an academic project at the University of Berkeley, California, and now more and more chip companies agree with this architectural standard: simple structure, flexible and cutable, open source, and can also avoid the risks brought by geopoliticality.
But what does RISC-V have to do with blockchain?
A virtual machine (VM) is the "execution brain" of every blockchain, and all contracts must be run on it. However, the current mainstream virtual machine systems, such as Ethereum's EVM, Polkadot's WASM, and Solana's BPF, all have some obvious problems:
Old architecture, like EVM, is a stacked model designed in 2015, which is difficult to align with modern CPUs
Poor safety, The existing architecture is difficult to formally verify and cannot achieve true mathematical code security
Multilingual support is limited, developers cannot choose language freely, and can only passively rely on the Solidity stack
So, when RISC-V, a "modern" architecture appears in front of blockchain engineers, their intuition is: Can we also "RISC-V" the blockchain virtual machines?
Comparison diagram of stack vs register computing model
Ethereum’s Choice: Conceive the next generation of ZK native virtual machines from the concept
Vitalik's idea is very much the style of the Ethereum community:It is not a simple optimization, but a redesign from the philosophical level.
According to his description on the Ethereum Magicians forum, his vision is:In the future, the execution layer of Ethereum should be minimal, secure, and mathematically proven.. And EVM is too complicated and cannot be changed. It’s better to use RISC-V to build a brand new verifiable VM.
RISC-V has a clear structure and predictable execution behavior, which is very suitable for converting into a zero-knowledge proof circuit; it may also cooperate with the LLVM compiler in the future (although I have seen a lot of comments about bugs) to develop contracts in richer languages, such as Rust and C; more importantly, it can become the basis for the execution layer for building "ZK native chains".
Of course, this is still in the conceivable stage. The Ethereum community has no plans to implement, but the direction has been clear:It is not just about changing a virtual machine, but about preparing for a scalable, secure and trustworthy blockchain in the future.
Polkadot's Path: Engineer-driven, Realism starting from replacing the underlying
Unlike Ethereum’s “conceptualization”, Polkadot chose another pragmatic route.
Back in 2023, Jan Bujak, a core engineer at Parity, began exploring alternatives to WASM and eventually chose RISC-V, which later 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 straightforward:
The language remains unchanged, continue to use Solidity
The tool remains unchanged, Remix, Ethers.js, and MetaMask are all compatible
Compile path adjustment, compile Solidity into RISC-V bytecode through revive tool
Finally run on the new virtual machine PolkaVM, providing more efficient, secure, and more verifiable execution capabilities.
This means that the developer's experience remains basically unchanged, but the execution layer has been completely replaced. From WebAssembly to RISC-V, from stack to register, from traditional execution to ZK-friendly, it is a "quiet revolution".
at present,PolkaVM can run on Asset Hub's Westend testnet, with the expected goal of launching Polkadot in Q3 2025。
Developer perspective: The code you write remains unchanged, but the underlying layer is quietly reconstructing
Although Ethereum and Polkadot have different paths to treat RISC-V, one is ahead of the vision and the other is already implementing it, the signal they send to developers is surprisingly consistent: this is not a "writing layer" change, but a reconstruction of the underlying infrastructure.
For developers, no matter which chain you are in, you will almost never feel the sense of separation in the short term: you can still write contracts with Solidity, continue to use familiar tools such as Remix, Ethers.js, and MetaMask. The deployment process is basically the same, and everything is as usual.
But at the invisible bottom layer, the execution engine has been replaced!
In Polkadot, the Solidity contract can be compiled into RISC-V bytecode through the revive tool and run on the brand new virtual machine PolkaVM.Compared with WASM and traditional EVM, PolkaVM performs better in execution efficiency and resource billing, especially more friendly to the operation 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 we want to implement on-chain execution logic that can be truly proven mathematically, EVM is an obstacle that cannot be avoided, and RISC-V with clear structure and predictable behavior is the ideal solution.
More importantly, this change in the architecture layer is far more than just performance improvement - the fundamental change in the on-chain development paradigm is happening quietly.
Security will move from "relying on people" to "mathematically verified". Every instruction behavior of RISC-V can be formally modeled, which is beyond the reach of EVM. This means that future contracts are safe and no longer rely on year-on-year audits, but can obtain "I won't make mistakes" mathematical endorsement at the compilation stage. You can write code that doesn't require someone to trust, just because "it can be proven".
Zero knowledge moves from niche to default. In the past, writing ZK contracts was a skill that only senior engineers could play. The structure of RISC-V itself is zk-friendly, with regular execution and easy-to-turn circuits. It naturally becomes the ideal backend for systems such as zkEVM. Once the underlying switching is completed, the ZK contract may no longer be an optional, but will become the "default security mode" of the smart contract.
The era of multilingual smart contracts is about to begin. RISC-V connects to the LLVM tool ecosystem, which means that languages such as 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 pushing for ink! language migration to RISC-V, This shows that the contract world where different languages coexist is reality, not fantasy.
Written at the end
No matter which chain you are on now, whether you use Solidity or Rust, write contracts on Remix, or use Ethers.js to adjust the front end, you will eventually realize:The evolution of virtual machines is not to change the way you write code, but to make every line of code you write - run faster, execute more stably, clearer logic, safer and more trustworthy.
These changes may not appear immediately, just as the reconstruction of the foundation was never the first to be seen. But it will eventually have an impact: future smart contracts will become stronger, more free, and more worthy of entrusting without you realizing them.
No comments yet