In the recent evolution of blockchain technology, a term that was originally only popular among chip engineers has quietly become the new favorite of public chain developers: RISC-V.
On April 20, 2025, Ethereum founder Vitalik Buterin published a post on the community forum Ethereum Magicians, proposing an exploratory suggestion to replace Ethereum's long-used EVM virtual machine with RISC-V. At the same time, Polkadot has quietly launched a smart contract execution environment that supports RISC-V on the Westend testnet. Developers can even continue to use Solidity to try to develop on Polkadot, but the contract will eventually run on a brand new execution engine, PolkaVM.
Is it a coincidence? Why did an open source instruction set originally designed for chip design "break through" in the blockchain world?
Ethereum and Polkadot both bet on RISC-V. What do they see in 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 uses to tell 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 paying 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 architectural standard: simple structure, flexible and customizable, open source, and able to avoid geopolitical risks.
But what does RISC-V have to do with blockchain?
The virtual machine (VM) is the "executing brain" of each blockchain, and all contracts must run on it. However, the current mainstream virtual machine systems, such as Ethereum's EVM, Polkadot's WASM, and Solana's BPF, have some obvious problems:
The architecture is old, such as the EVM, which is a stack-based model designed in 2015 and is difficult to align with modern CPUs
Poor security. The existing architecture is difficult to formally verify and cannot achieve true mathematical-level code security.
Multi-language support is limited, developers cannot freely choose the language, and can only passively rely on the Solidity stack
So, when the "modern" architecture of RISC-V appeared in front of blockchain engineers, their intuition was: Can we also "RISC-Vize" the blockchain virtual machine?
Comparison chart of stack-based vs register-based computing models
Ethereum’s options:
Starting from the concept,
Envisioning the next generation ZK native virtual machine
Vitalik’s idea is very much in line with the Ethereum community’s style: not a 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 extremely simple, secure, and mathematically provable. However, the EVM is already too complex and cannot be changed. It is better to use RISC-V to build a brand 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 be used in conjunction with the LLVM compiler (although there are 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 a "ZK native 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 the virtual machine, but about preparing for a scalable, secure and reliable blockchain in the future.
Polkadot’s path:
Engineer driven,
Realism starts with replacing the underlying
Unlike Ethereum’s “conceptual vision”, Polkadot chose another pragmatic route.
As early as 2023, Parity's core engineer Jan Bujak began exploring alternatives to WASM, and eventually chose RISC-V, and then launched the PolkaVM project.
Polkadot’s approach is straightforward:
The language remains unchanged, and Solidity is still used.
The tools remain the same, Remix, Ethers.js, and MetaMask are all compatible
Adjust the compilation path and compile Solidity into RISC-V bytecode through the revive tool
Finally, it runs on the new virtual machine PolkaVM, providing more efficient, more secure 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 be run on the Asset Hub parachain westend testnet, with the goal of launching the mainnet in Q3 2025.
Developer perspective: The code you write remains unchanged, but the underlying layer is quietly refactored
Although Ethereum and Polkadot have different paths towards 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 any sense of disconnection 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 remains the same.
But at the bottom, the execution engine has been changed:
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 considered the most suitable foundation for the “ZK native chain”. Vitalik clearly stated that if we want to achieve truly mathematically provable on-chain execution logic 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 architectural layer is far more than just a performance improvement - a fundamental shift in the on-chain development paradigm is quietly happening.
Security will move from "relying on human supervision" 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 a niche to a 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 an option, 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 be naturally compiled into on-chain formats. You are no longer limited to Solidity. In the future, writing smart contracts will be as controllable and free as writing system modules. Polkadot is already promoting the migration of the ink! language to RISC-V, which shows that the contract world where different languages coexist is a reality, not a fantasy.
Last words
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 that 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 steadily, have clearer logic, and be more secure and reliable.
These changes may not be immediately apparent, just as the reconstruction of the foundation is never the first thing to be seen. But it will eventually have an impact: the smart contracts of the future will become more powerful, freer, and more trustworthy without you noticing.
Disclaimer: The materials provided by PaperMoon and included in this article are for educational purposes only. They do not constitute financial or investment advice and should not be interpreted as guidance for any business decision. We recommend that readers conduct independent research and consult professionals before making any investment or business-related decisions. PaperMoon assumes no liability for any actions taken based on the contents of this article.
refer to:
https://cset.georgetown.edu/article/risc-v-what-it-is-and-why-it-matters/
https://riscv.org/
https://ethereum-magicians.org/t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617
https://zh.wikipedia.org/wiki/%E6%8C%87%E4%BB%A4%E9%9B%86%E6%9E%B6%E6%A7%8B
https://docs.polkadot.com/develop/smart-contracts/evm/native-evm-contracts/
https://use.ink/docs/v6/background/why-riscv-and-polkavm-for-smart-contracts/
https://zhuanlan.zhihu.com/p/675517051
https://zhuanlan.zhihu.com/p/440356866
https://www.eefocus.com/article/1699454.html
https://solana.com/docs/programs/faq
https://www.anza.xyz/blog/the-solana-ebpf-virtual-machine
https://use.ink/docs/v6/current-state
