The article below brings together some of the Q&A from our recent AMA on Reddit. Thanks so much for sending in your questions—we love chatting with you and being part of this awesome community!
Meepo Hardfork Features
What does Meepo bring to CKB, in simple terms?
Imagine upgrading from wooden blocks to LEGO bricks. That’s what the spawn syscall in Meepo does for CKB smart contracts, enabling script interoperability.
Spawn and a series of related syscalls are introduced as a major upgrade to CKB-VM, enabling interoperability, modularity, and better developer experience, by letting scripts call other scripts, like modular apps in an operating system.
Key features of the upgraded VM?
The upgraded CKB-VM Meepo version unlocks true decoupling and reuse of CKB scripts, enhancing modularity and reusability in smart contract development.
For instance, before Meepo, if developers wanted to build a new time lock in CKB, they had to bundle all necessary functionalities—like signature algorithms—directly into a single lock or type script. This often led to bloated scripts where most of the code was unrelated to the developer's original design goal (time lock). With the spawn syscall, scripts can now delegate tasks—such as signature checks—to other on-chain scripts. As new algorithms emerge, the time lock can adopt them without being redeployed—just by calling updated signature scripts, as long as a shared protocol is followed.
This separation allows developers to:
- Focus solely on their core logic.
- Reuse independently deployed signature verification scripts.
- Upgrade cryptographic components without modifying the original script.
- Embrace a more OS-like model where smart contracts can call each other to perform specialized tasks.
By enabling true decoupling and reuse, the spawn syscall makes CKB scripts significantly more composable, maintainable, and adaptable.
Besides Spawn, other improvements in Meepo include:
- Block Extension Fields: Enables reading extension fields in blocks, opening new possibilities like community voting on hardforks (as this ckb-zero-lock prototype). More use cases are expected.
- CKB-VM Optimization: Reduces cycle consumption for common compiler-generated code, making scripts faster and more efficient.
A practical example: IPC on Spawn
Here's an example building an entire Inter-Process Communication (IPC) layer on top of spawn syscalls:
What does “every wallet will become a CKB wallet because of ckb-auth” mean?
Current CKB-VM already comes with the power to build omnilock / ckb-auth, spawn just makes them easier to reuse in new scripts through decoupling and improved modularity.
Upgrade Compatibility Concerns
No. Meepo does not introduce breaking changes like address format switching. The only required upgrade is support for a new hash type (data2). We aim to keep upgrades smooth and backwards-compatible wherever possible.
RISC-V & CKB’s Long-Term Design Philosophy
Ethereum is exploring RISC-V—CKB has been doing this for years. What’s your take?
The discussion about RISC-V in Ethereum, is partly about the ease of building zk solutions on Ethereum. And it's easy to mix two different use cases of RISC-V in zk:
- Use RISC-V as the language to write programs running in a zk engine. In this case, we use zero knowledge algorithms to build a RISC-VM and prove programs running inside these RISC-V VMs.
- Use RISC-V as the underlying engine to run cryptographic algorithms, we then compile the verifier / prover code of zero knowledge algorithm into RISC-V, then we run those verifiers / provers inside RISC-V. Essentially, we run the verifying / proving algorithms of zero knowledge algorithms in RISC-V, the programs running inside ZK VMs can be written in other languages suiting the zk algorithms.
When most people talk about RISC-V in zk, they mean the first point above. As a result, we see a lot of arguments debating if RISC-V fits in zk circuits. I couldn't get a direct confirmation from Vitalik, but based on what I read, when Vitalik proposes the idea of RISC-V in Ethereum, he's at least partly thinking about the second point here. The original idea is to introduce RISC-V in Ethereum, so we can just compile zk verifiers / provers into RISC-V code, so there is no need to introduce any more precompiles so as to support different zk algorithms in Ethereum. This is indeed a rare taken path, but I believe it is a right path, it is also the path CKB chose 7 years ago for the initial design of CKB-VM.
CKB believes that a precompile-free approach is the only viable path if we’re serious about building a blockchain that can last for decades—or even centuries. Cryptographic algorithms evolve quickly; new ones emerge every few years, making it unsustainable for blockchains to keep adding them as precompiles. In contrast, hardware evolves more slowly and lives longer.
By choosing RISC-V, we’ve committed to a model that can better adapt to future cryptographic developments. CKB may be on an uncommon path, but I believe it's the right one—and it's encouraging to see Ethereum now moving in a similar direction. Hopefully, more will follow.
CKB already stands out as the only blockchain VM built on RISC-V and entirely free from cryptographic precompiles. Meepo, with its spawn syscall, builds on this foundation—pushing for even greater modularity and reuse. We're also closely watching progress in the RISC-V ecosystem, with the goal of integrating hardware advances into CKB-VM, making it even more future-proof and a state-of-the-art execution environment for blockchain applications.
Will CKB run directly on RISC-V chips? What are the implications?
The "CKB on RISC-V"comes in several stages:
- For now, CKB-VM can already be compiled into RISC-V architecture and run on a RISC-V CPU (e.g. StarFive board), though optimized native implementations are still in development.
- That said, one key issue in the previous stage was that CKB-VM lacks a high-performance, assembly based VM on RISC-V architecture. Ironically, despite CKB-VM being based on RISC-V, we ended up running a Rust-based VM interpreter on RISC-V CPUs—which is far from ideal.
The root of the problem is that RISC-V CPUs come in many configurations, each supporting a different set of extensions. Porting CKB-VM to run natively on real RISC-V chips isn’t trivial—some extensions used by CKB-VM might not be available on the target hardware. With enough time and effort, a performant native implementation could be built, but it’s a non-trivial challenge that still needs significant work.
How do you see the RISC-V narrative expanding?
We are delighted to see the growing recognition of RISC-V in the blockchain
space. For CKB, we firmly believe RISC-V is the best choice. Consensus is costly, so only essential data should be on-chain, with the chain serving as a universal verification layer—this is CKBʼs philosophy, and we have consistently designed and developed in this direction.
CKB Roadmap & Ecosystem Growth
Any plan to boost the usage of the CKB network in the next 6 - 24 months?
Growth starts with better developer experience. Spawn in Meepo significantly lowers the barrier to building complex apps. With better tools and documentation, more devs can experiment on CKB, leading to better apps and more users.
What would you focus on if the secondary issuance budget was huge?
If funding were abundant, we'd expand the Spark Program, support more grassroots projects, and even evolve toward a fully decentralized DAO structure—aligning with our long-term vision of a permissionless, community-owned network.
What’s next for Nervos after Meepo?
We're exploring new RISC-V extensions like CFI, which could boost script security and defend against ROP attacks. Still early-stage, but promising. Check out this: Against ROP Attacks: A Blockchain Architect’s Take on VM-Level Security.
Resources
Take a deeper look at the VM upgrades introduced in the Meepo hardfork:
Explore the CFI (Control Flow Integrity) extension on RISC-V:
Check out the Inter-Process Communication (IPC) layer built on top of spawn syscalls:
