This is an overview intended to provide an accessible introduction to the new Spawn feature introduced in CKB’S Meepo upgrade—what spawn is, how it works, and what it enables.
While this article doesn’t delve into implementation details, readers are expected to have basic familiarity with the following concepts:
Challenges in Previous CKB Contract Development
In previous CKB smart contract development, if you need to use a complex algorithm, it's typically to directly embed it into the Script. While straightforward, this approach introduces several problems:
Code becomes hard to maintain or update
Code size increases, leading to higher transaction fees
Dependency conflicts with required libraries
Performance limitation—or even the lack of a suitable implementation—in the target language
To address these issues, CKB introduced a new multiprocessing mechanism called Spawn via the Meepo hard fork.
ckb-spawn: Inspired by Unix Design
Back in 2021, as the initial attempt to solve on-chain inter-script interaction, CKB introduced a solution called ckb_exec. Inspired by Unix’s exec system call, its core idea was to destroy the current execution context and switch to another Script—a process switch. However, in practice, developers soon ran into limitations:
These issues made exec impractical for decoupling and code reuse.
To solve these problems, we drew further inspiration from Unix’s spawn mechanism, which allows a new subprocess to be created without terminating the original one. This multiprocessing model, implemented as ckb_spawn, consists of a set of APIs for spawning child processes and enabling interaction between them.
Note: For brevity, we’ll refer to ckb_spawn and ckb_exec simply as spawn and exec throughout the rest of this article, unless otherwise specified.
Spawn vs. Exec: Key Differences
Although both exec and spawn involve subprocesses, they differ fundamentally:
Exec: When a parent process calls exec, the current execution context is replaced. Once the child script finishes execution, the entire execution ends. There is no return to the parent.
Spawn: When a parent process calls spawn, it creates a child process running alongside the parent. After the child finishes, control can be returned to the parent process, which can then continue execution. Communication between the two can continue via Pipe.
In this sense, Spawn more closely resembles multiprocessing, whereas Exec simply replaces the current process with another one.
The diagram below illustrates the difference. With exec, the parent doesn’t really exit—it just gives up control to the child. With spawn, both processes can coexist and communicate via pipes, allowing for modular and cooperative execution.
Multiprocessing on CKB Explained
CKB does not natively support parallelism, and the Meepo hard fork does not introduce concurrent execution. Memory limit remains unchanged. However, through VM scheduling, CKB achieves a parallelism-like multiprocessing functionality—conceptually closer to Coroutines. Additionally, PIPE is used to enable Inter-Process Communication (IPC).
Multiprocessing via VM Scheduling
CKB’s multiprocessing model borrows from operating systems:
Each process has its own stack and memory space
Processes cannot access each other’s memory directly
A parent-child relationship exists between processes
Each process is assigned a unique PID (Process Identifier)
Resources are automatically reclaimed when a child exits
The key difference between CKB and traditional operating systems lies in the use (or absence) of Round-Robin Scheduling, where the CPU divides execution time into fixed-length time slices, and each process takes turns to run—ensuring fair CPU usage and enabling true parallelism and preemptive multitasking.
Traditional OS-level multiprocessing typically relies on this mechanism, but CKB does not. Instead.Instead, it relies on specific VM syscalls—such as ckb_spawn, ckb_read, ckb_write, and ckb_wait—to trigger process switching. In other words, CKB-VM simulates multiprocessing through syscall-driven context switching. Execution remains sequential and controlled, making it closer to coroutines than to preemptive multitasking.
Pipe
In CKB’s multiprocessing model, parent and child processes have isolated memory spaces and cannot share data directly, making IPC a key challenge. To address this, CKB introduces PIPEs as the communication mechanism.
Similar to the concept of pipes in OSs, CKB pipe is a form of IPC that allows one process to send data to another:
A pipe is unidirectional, consisting of an input end and an output end (File Descriptors, or FDs). One process writes data to the pipe, and another reads from it.
The parent process creates the pipe before spawning the child and pass the relevant FDs along.
Processes use these FDs to read from and write to the pipe, enabling data transmission.
Note: FDs are bound to the parent process creating them, and can only be transferred to the child process at the time of creation—the binding is passed along during spawning.
Pipes thus enable data exchange despite memory isolation between processes.
Spawn Scheduling Diagram
The diagram below illustrates a complete spawn scheduling process:
This process can be broken down into the following four steps:
spawn-parent launches a child process spawn-child using ckb_spawn (highlighted in red).
Child process writes data via Pipe (highlighted in blue).
Control is then switched back to spawn-parent, which continues executing the parent logic (highlighted in green).
After finishing execution, the process exits.
As shown in the diagram, there is no parallel execution at any point—everything runs sequentially. This clearly reflects CKB-VM’s design philosophy of simulating concurrency through scheduling.
Simplifying Development with ckb-script-ipc
Although the ckb_spawn API set is relatively small, working with process scheduling, IPC, and on-chain asset safety still involves a significant learning curve. To make development easier, we created the library ckb-script-ipc, designed to streamline spawn-based development.
ckb-script-ipc provides two layers of encapsulation:
Communication Model Encapsulation:
It abstracts PIPE-based communication into a more intuitive Client/Server model, where the the relationship between the Client and Server is similar to that between a browser and a web server in HTTP communication:
Server: Like an HTTP server, it provides interfaces but does not initiate requests.
Client: Like a browser, it decides when to initiate requests and waits for responses.
Typically, the parent process acts as the Client, while the child process as the Server.
Automatic Code Generation:
A procedural macro (available only in Rust) allows developers to define a trait, from which client-side code is automatically generated. The server only needs to implement the same trait.
With this macro-based approach, developers can focus purely on defining interfaces and implementing logic, without having to write boilerplate communication code—greatly reducing the complexity of using spawn.
With the introduction of Spawn and PIPE, CKB brings greater flexibility to smart contract (script ) development while maintaining on-chain safety. As a parallelism-like execution model, this mechanism offers a practical foundation for structing complex logic—and lays the groundwork for future optimizations. For developers, understanding this architecture opens the door to more powerful and maintainable contract systems.
In another article, I will introduce ckb-crypto-service: a cryptographic interface that allows contracts to invoke algorithms directly via IPC, without manual integration. Built on top of CKB’s multiprocessing and IPC capabilities, it provides a reliable, streamlined, and cross-language infrastructure for contracts.
🧑💻 Author: Han Zishuang, a developer and DevRel for CKB, L1 of the Nervos Network.
Follow him for more technical insights on CKB:
