By
Lyubomir Kiprov
March 4, 2026
6 minutes
.webp)
If you grew up in Eastern Europe like I did, you probably have a vivid memory of your grandmother’s living room. Specifically, that one glass cabinet where she kept the "good", only for guests porcelain and, inevitably, a set of Matryoshka dolls.
You know the ones. The wooden Russian nesting dolls. As a kid, you were only allowed to play with them on special occasions. There was something deeply satisfying about opening the big doll to find a smaller one, and then a smaller one, all the way down to that tiny, solid piece of wood in the center.
Recently, our R&D team at LimeChain got to play with that concept again. But instead of painted wood, we were working with virtual machines.
The Nervos Fоundation engaged us to answer a complex question: Is it possible to build a Zero-Knowledge Virtual Machine (zkVM) solution for block verification on Nervos’ blockchain the Common Knowledge Base (CKB)? And if so, how do we actually do it?
Here is the story of how we found the answer by nesting one machine inside another.
Nervos (CKB) stands apart in the blockchain landscape. It is a network with architectural similarities to Bitcoin, based on the UTXO model, but it extends this foundation with smart contract capabilities implemented as scripts. While Ethereum relies on the EVM—a virtual machine custom-built for the chain—Nervos is built on RISC-V, the same open-standard architecture that powers physical hardware. This alignment makes CKB inherently efficient and flexible, allowing it to execute complex logic without relying on precompiles (hardcoded shortcuts) common in other systems. If you’re new to precompilers, I recommend checking out Nervos article: What are Precompiles in Blockchain Technology?
Our goal was to figure out how to generate Zero-Knowledge proofs for CKB blocks. If we could do this, we could prove that a block is valid without everyone needing to re-run the transactions.
Our journey began by looking at the Reth Succinct Processor (RSP) for inspiration. RSP proves Ethereum blocks using a zkVM, and we wanted to see if we could structure a similar solution for CKB.
We evaluated two leading contenders: RISC Zero and SP1. While RISC Zero is a robust platform, we hit a wall: it lacked native 64-bit support. CKB is a 64-bit RISC-V interpreter, so that was a dealbreaker.
That led us to SP1 Hypercube, the latest iteration of Succinct's zkVM. It supports 64-bit RISC-V architecture and has even been formally verified by the Nethermind Security team.
Can we leverage this shared DNA to prove CKB blocks directly inside SP1?
Practically, this meant checking if CKB scripts could run natively within SP1. Think of it this way: EVM contracts are written in a 'foreign language' to the hardware, requiring translation. CKB scripts, however, are compiled directly to RISC-V—the exact language SP1 speaks.
If this worked, we could bypass emulation entirely. We envisioned a scenario where CKB scripts executed natively inside SP1, achieving near-native performance without the overhead.
As is often the case in engineering, the devil was in the details. If there are any "vibe coders" reading this, write this down: you cannot simply vibe your way through a missing instruction set extension, no matter how immaculate the architectural synergy feels.
CKB relies on Bit Manipulation (B) and Compressed Instructions (C) extensions for efficiency. SP1, however, currently only supports the base Integer (I) and Multiplication (M) sets.
All supported instructions in SP1 are executed directly at the circuit level, which is a key reason for its fast proof-generation performance. However, the absence of the B and C extensions in SP1 creates a fundamental incompatibility. When encountering an unsupported instruction, the proving process fails because the circuit cannot resolve unknown instructions.
Since we don’t want to go into modifying the circuit-level behaviour of SP1 (for example, by adding trap handlers or emulation logic for missing instructions), these discrepancies must be addressed at the software level. We considered 'expanding' the incompatible 16-bit instructions into 32-bit ones that SP1 could understand. But here is the catch: changing the instructions changes the binary. Changing the binary changes the transaction hash. And in a blockchain, if the hash changes, the consensus breaks. It was a dead end.
Beyond instruction set mismatches, we encountered three major system-level conflicts:
Taken together, these limitations prevent CKB scripts from being executed natively within SP1 to achieve performance gains, unless the CKB or SP1 codebases are significantly modified or adapted to accommodate these differences.
This is where the nesting dolls came back to me.
If the "outer doll" (SP1) couldn't understand the tiny doll (the CKB script) directly, maybe we needed a middle doll to translate.
We looked at how the Ethereum ecosystem handles this. We studied the RSP (Reth Succinct Processor) implementation. Instead of trying to make the zkVM understand smart contracts directly, they compiled the entire execution engine (reth) into RISC-V and ran that inside the zkVM. Because SP1 provides circuit-level implementations for most EVM cryptographic primitives, a large portion of execution happens directly in the circuit, significantly reducing proof-generation time.
We applied this same logic to Nervos. We took the ckb-vm crate (the actual CKB interpreter) and compiled it to run inside SP1. This solves the dialect problem instantly. The ckb-vm (our Middle Doll) executes the script, presenting simple instructions that SP1 (the Outer Doll) can prove.
The resulting architecture effectively runs an interpreter (ckb-vm) inside another interpreter (SP1). Instead of executing RISC-V scripts natively, transactions and their associated scripts are emulated. Consequently, block validation is performed as a sequence of RISC-V instructions interpreted by the zkVM. By definition, emulating CKB in this way cannot match the performance of native RISC-V execution, but it works out of the box and allows all required logic for CKB block verification to be expressed and proven inside the zkVM.
Here is the "nesting" in action:
Side note: While this VM-in-VM approach successfully proved the concept, Nervos’ work has since advanced. The team has now moved toward directly targeting CKB to the RV64IM instruction set, bypassing the emulation overhead to achieve much better efficiency.
You might be asking, "That’s a cool engineering trick, but what does it actually do for the network?".
This research opens the door to three major possibilities:
However, RISC-V is just a low-level hardware spec, while CKB-VM is a mature implementation with tooling already built up around a blockchain context. If we can prove the "no precompiles" design is highly feasible, it will strongly strengthen the case that builders in the wider ZK space should be taking a serious look at CKB-VM.
We are currently in the R&D phase, focused on optimizing the cryptographic overhead—ensuring our "dolls" nest together as smoothly as possible. But the path forward is clear. Sometimes, when you hit a wall, the solution isn't to break through it—it's to build a container that fits through the door.
The goal is to generate Zero-Knowledge (ZK) proofs for Nervos Common Knowledge Base (CKB) blocks. This allows the network to cryptographically prove that a block is valid without requiring network participants (nodes) to re-run and re-execute all the underlying transactions.
SP1 Hypercube was selected because it supports 64-bit RISC-V architecture, which is a fundamental requirement for the CKB interpreter. RISC Zero was evaluated but rejected because it lacked native 64-bit support.
Attempting native execution revealed four critical system and dialect incompatibilities:
To bypass the native execution incompatibilities, the team utilized a "VM-in-VM" emulation approach inspired by Ethereum's RSP. The architecture involves three nested layers:
While the VM-in-VM approach successfully proved the concept, the Nervos team is advancing toward targeting CKB directly to the RV64IM instruction set. This will eventually bypass the emulation overhead and achieve highly efficient, native execution.
It enables "Fully Verifying Light Clients." Devices with low hardware and storage capacity (like mobile wallets or IoT devices) can receive a tiny cryptographic proof confirming a block's validity. They can mathematically verify the state of the blockchain without downloading or re-executing the entire transaction history.
There are three major interoperability and ecosystem benefits:
