Fork Smarter, Not Harder: CKB's Forking Philosophy Explained 1/ In most blockchains, hardforks often imply discontinuity, where: 😕 Users risk losing access to assets. 🤨 Developers are forced to upgrade—like it or not. CKB takes a different approach: it decouples upgradeability from forced consensus. 🔐 Assets remain safe during upgrades. ⛓️ Users aren't forced to adopt new protocols. Here's how it works: 2/ Protocol-Level Flexibility: Fork Without Split CKB is built on the UTXO Cell model, where each user's assets are stored in the discrete Cells—each with its own versioned Lock Script. After a hardfork, each Cell continues to use the VM version it was deployed with, where: - Existing Cells remain on the old VM version. - Users are not forced to upgrade the Scripts. - They opt in new features — if and when they want to. This is made possible by introducing multiple hash_type variants (type, data, data1, data2, ...), each pointing to a different version of the code. 🤝 Multiple versions of Scripts and VMs coexist on the same chain. ⛓️ Upgrades won't split the network. 🔐 Users keep full control over both the assets, and the rules that govern them as well. 3/ Why It Matters 💡 Most chains treat a hardfork as a reset — override old logic and force everyone to upgrade. CKB avoids this. Multiple versions run side by side on the same chain. This eliminates the tension between network evolution and asset preservation. 4/ Script-Level Upgrade Workflow: Type ID + Lock Script CKB provides Type ID + Lock Script model for managing script upgrades: 1️⃣ Initial Deployment: A Script developer deploys Scripts with upgrade plans in mind: Using Type ID to assign a stable identity but allows future updates. 2️⃣ Iterative Upgrade: Fix bugs, add new features, and change rules—the deployed code may undergo several upgrades using Type ID. 3️⃣ Code Freezing: At any point, one can freeze the code by modifying the Lock Script to be immutable. 5/ Script Developer & dApp Developer: Separate Roles CKB separates two responsibilities: - Script Developers: Deploy the Script and decide if it is upgradeable, via Type ID + Lock Script. - dApp Developers: Choose how to reference a Script in their applications—fixed or upgradable. Their options: 🔹Reference by type hash → Auto-follow the latest upgrades 🔹Reference by data / data1 / data2 hash → Stay fixed to the trusted version, ignoring the new one Either way, dApp devs don't need to fear upstream changes breaking their logic or being kicked out of the network. 6/ This separation enables: - Reusable Scripts across multiple dApps - Opt-in upgrades — no forced coordination - Long-term stability where needed, flexibility where desired 7/ Example: UDT Script Upgrade Suppose someone deployed a UDT (User-Defined Token) Script using Type ID and created two tokens: - UDT A uses type as hash_type - UDT B uses data2 as hash_type Later, the UDT Script is upgraded from Version 1 to Version 2: - UDT A automatically adopts Version 2 - UDT B keeps running on Version 1 8/ Even if Version 1 is no longer present in a live Cell, it's not lost. You can retrieve it from chain history, redeploy it, and use it again. Old logic remains accessible—by design. 9/ A Better Forking Philosophy CKB doesn't follow the rigid "hard vs. soft forks" binary. Instead, it offers: ✅ User autonomy ✅ Developer control Assets stay protected. Scripts remain stable—or upgradeable. No one is forced to choose between safety and progress. It's a better way to fork. And it works. 10/ Reference Links Rethinking Forks: The Philosophy Behind CKB's Network Upgrade Design: https://docs.nervos.org/docs/history-and-hard-forks/rethinking-forks Recommended Workflow for Script Upgrades: https://docs.nervos.org/docs/script/script-upgrade-workflow How CKB Turns User Defined Cryptos Into First-Class Assets: https://blog.cryptape.com/how-ckb-turns-user-defined-cryptos-into-first-class-assets CKB, Version Control and Blockchain Evolution: https://talk.nervos.org/t/ckb-version-control-and-blockchain-evolution/4819 CKB VM Version Selection: https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md

Fuzzing CKB-VM Into Shape: The Hidden Work Behind Meepo Do you know that a big part of Meepo’s development time went into fuzzing test, rather than writing new features? To ensure the reliability and consistency of CKB-VM upgrades on mainnet and testnet, we fuzzed both valid and invalid transactions to catch any subtle compatibility issues early. The goal was to: - Ensure stable and consist transaction execution - Prevent panics - Verify compatibility in aspects like cycle consumption and error handling across different versions and hardforks Here’s how fuzzing helped. 1/ Initial Verification: Transaction Replay 🔁 We began by replaying historical on-chain transactions (via `replay`) from mainnet and testnet to check if `cycle` consumption remained consistent in the upgraded CKB-VM. This caught several mismatches: As the chain only contains valid transactions, this method verifies past compatibility but not future cases. To broaden coverage, we turned to fuzzing to simulate diverse transaction inputs and assess compatibility across versions, including error handling in invalid transactions. 2/ First Fuzzing Attempt 🧪 We compared the execution results of `data0` and `data1` of the pre- and post-upgrade VM versions: However, most generated test cases were invalid. The test only compared whether the errors matched, but skipped the cycle consumption for valid cases—not enough to meet our goals. 3/ Improved Fuzzing 🔧 To increase valid transaction input coverage, we refined the strategy: - Corpus Optimization: Added valid transaction data from CKB-VM tests and CKB debugger binaries to the fuzzing corpus. - Input Filtering: Modified fuzzing logic to only keep valid transactions in the corpus, further increasing the frequency of valid samples and enhancing `cycle` verification. 4/ Findings 😃 Improved fuzzing uncovered bugs, including: - Crash caused by an invalid syscall parameter. Fix: github.com/libraries/ckb/commit/38279e118d3fda3c52f1d47d2062f80e19a2d523 - Instruction reordering led to mismatched `cycle` cost and memory out-of-bounds errors. Fix: github.com/libraries/ckb/commit/ea4aea7fa4cd87ce5df6dee6616466458ff5a86e - Inconsistent error handling due to mismatched `DataPieceId` behavior. Fix: github.com/libraries/ckb/commit/af87dd355a653eaca19a643866300cc5cd907cf5 - Address truncation in x64. Fix: github.com/nervosnetwork/ckb-vm/commit/f6df535bbf8864fd14684c133b1aa8026a0b0868 - Inconsistencies in memory tracking. Fix: github.com/nervosnetwork/ckb-vm/commit/065a6457d06aa17da4f7dfa1954a2601fc7d288b All issues were reproduced, analyzed, and added to the test corpus and the fuzzing crash directory for regression testing. 5/ Went Deeper: ISA-Level Fuzzing 🦾 In addition to compatibility testing, we fuzzed the instruction set to prevent unexpected VM panics. See: github.com/nervosnetwork/ckb-vm-fuzzing-test 6/ Fuzzing isn’t flashy, but it pays off. 🛡️ As we know reliability is what gives developers confidence to build. We’ll gladly keep things safe and steady—and maybe a little boring—so you don’t have to. 😎 8/ Reference Links 🔗 Fuzzing and tools: - github.com/nervosnetwork/ckb-vm/tree/develop/fuzz - github.com/libraries/schedfuzz - github.com/nervosnetwork/ckb-vm-fuzzing-test On VM 2: - github.com/nervosnetwork/rfcs/blob/master/rfcs/0049-ckb-vm-version-2/0049-ckb-vm-version-2.md

Satoshi Scoop Weekly is here 🧂 CKB completed its Meepo hardfork. Big step forward for us. Meanwhile, Bitcoin scaling experiments keep rolling: BRC upgrade, BitVM variants, new bridges... - CKB unlocks multiple VM support and modular script interactions - BRC20 set for an upgrade: BRC2.0 coming to Bitcoin mainnet mid-August - Garbled circuits: The key and cost of BitVMX scalability - GOAT network uses Label Forward Propagation to overcome BitVM3 scalability limits - BitVM2 paper updated with mainnet-proven production implementation - Union Bridge: Trust-minimized BTC-Rootstock bridge via BitVMX - From BitVM1 & 2 to BitVM3 and Garbled Circuits: David Tse on Bitcoin bottlenecks and off-chain optimization - Bitcoin mining environmental debate rekindled as DARI rebuts hot papers and calls for data-driven analysis - Podcast | Eli Ben-Sasson on the history of ZKPs and their role in Bitcoin Catch up here👇 EN: https://yakihonne.com/naddr1qvzqqqr4gupzq046tm6pkgrtr4y73vd7wfqa06k4mkrmwdexrknycw7quf637gawqq24xe2nxe35zens24nxcve32ejh53njvayyj39kyvx CN: https://yakihonne.com/naddr1qvzqqqr4gupzq046tm6pkgrtr4y73vd7wfqa06k4mkrmwdexrknycw7quf637gawqq2kx7rdf3rnxeze2f692wz3x9rxkjpkwefrxskz0ld

✅ Meepo Hardfork completed at epoch 12293. Spawn syscall and CKB-VM v2 now live. https://explorer.nervos.org/hardfork If your node isn’t syncing blocks, please upgrade to the latest version. ⚙️ Upgrade: https://github.com/nervosnetwork/ckb/releases

Meepo hardfork hits tomorrow at Epoch 12293. Multi-version VM goes live. 🛎️ Last call to upgrade your node to v0.200.0+: https://github.com/nervosnetwork/ckb/releases Countdown: https://explorer.nervos.org/hardfork Node distribution & version status: https://nodes.ckb.dev

Current Epoch: 12,279 Target Epoch: 12,293 🛠 Upgrade your node: https://github.com/nervosnetwork/ckb/releases ⏳ See the countdown: https://explorer.nervos.org/hardfork 🌐 Check node status: https://nodes.ckb.dev

Hey, 3️⃣ days to Meepo. Current epoch: 12273 Target epoch: 12293 Make sure your nodes are ready on v0.200.0+ version! 🔹Upgrade now: https://github.com/nervosnetwork/ckb/releases 🔹Countdown: https://explorer.nervos.org/hardfork 🔹Node status: https://nodes.ckb.dev

🍽️ Satoshi Scoop is back with a serving of this week’s freshest takes! On the plate: - Should Bitcoin core development shift to a private collab Model? Developer calls for safer environment - Using cluster mempool & set reconciliation to prevent filtering of high-fee txs - Selfish mining's profit threshold: the 33% secret - Private pond: the most advanced Payjoin system? - Bitcoin core affirms commitment to user freedom and censorship resistance - Nostr game engine: decentralized game engine with Nostr integration - Chorus.community: censorship-resistant social app for activists - Transfer of Ownership Protocol (TOOP): a solution to BitVM bridge unlock limitations - BitVM bridge executes asset withdrawal and fraud protection use cases on Bitcoin - Cardinal protocol enables BTC/Ordinals to Cardano cross-chain via BitVMX and MuSig2 Full plate here 👇 ENG: https://yakihonne.com/naddr1qvzqqqr4gupzq046tm6pkgrtr4y73vd7wfqa06k4mkrmwdexrknycw7quf637gawqq2kw5zywarxzcj9f3pkxjtrx9vngmzxvf44y80sz0w CHN https://yakihonne.com/naddr1qvzqqqr4gupzq046tm6pkgrtr4y73vd7wfqa06k4mkrmwdexrknycw7quf637gawqq2kzsnrvgcnzdfstajy2unz2qm5w56hxe3yug4gj0s

Mainchain mains, L2 sides—Satoshi Scoop brings you what’s simmering in the Bitcoin kitchen 🍲 This weekend’s special menu: - Skipping witness sync for pruned nodes? A look at Bitcoin sync optimization and security tradeoffs - Capping tx weight to improve decentralization and relay efficiency - Pruning dust UTXOs to ease network burden - Ark vs. LSP: comparing liquidity models for different use cases - Citrea & Babylon advance cross-chain verification - How the DelBrag protocol works - Bitcoin testing is a ghost town: bad UX, rotten interfaces, and bugs - 8 years in, is Lightning still a hobbyist’s playground? - Gemini’s global crypto report: holding increases, memecoins as onboarding gateway ENG: https://yakihonne.com/naddr1qvzqqqr4gupzq046tm6pkgrtr4y73vd7wfqa06k4mkrmwdexrknycw7quf637gawqq24qcmnf4r4zcmpxp392wt8tfn9zerkd3zkxuhn2a3 CHN: https://yakihonne.com/article/naddr1qvzqqqr4gupzq046tm6pkgrtr4y73vd7wfqa06k4mkrmwdexrknycw7quf637gawqq2kwdfndfvkkuzlf94kyn6e243nzennxp9y7hhde2u

This week in Satoshi Scoop: Fresh insights from Bitcoin and beyond — from Sybil attacks and quantum threats to cross-chain bridges and blockchain governance. Dig in 👇 EN: https://yakihonne.com/naddr1qvzqqqr4gupzq046tm6pkgrtr4y73vd7wfqa06k4mkrmwdexrknycw7quf637gawqq2h2vnvwenxv562w42yumtwxpmr2un9dp5r20as53d CN: https://yakihonne.com/naddr1qvzqqqr4gupzq046tm6pkgrtr4y73vd7wfqa06k4mkrmwdexrknycw7quf637gawqq24j6teg3ty5jzevfpnqjm3gayrgvzh2ex9qqgh2t6

What Unix Taught Us About Designing a Blockchain VM CKB’s Meepo hardfork introduces a new syscall: spawn. But this is more than just a feature. It's a reflection of deeper computing ideas — ones we’ve borrowed from Unix. And it’s part of a larger goal: making smart contract development on CKB feel like building with LEGO — modular, composable, and fun. Let’s talk about processes, modularity, and what they mean for blockchain VMs. In Unix, you typically have two ways to start a program: - exec: replaces the current process with a new program (no new process is created). - spawn: creates a new child process to run a program, allowing the original process to continue. That reflects a core philosophy of program control. Exec was introduced in CKB-VM in 2021 as part of our first try to solve inter-script interaction. But developers quickly ran into limitations: “No return values.” “State is wiped.” “Hard to compose.” 😤 Sound familiar? So we asked ourselves: What if blockchain scripts were treated more like processes? What if they could coexist, communicate, and be composed — just like the child processes commonly used in Rust or NodeJS? 🧐 That’s the idea behind spawn. Inspired by Unix process management, spawn in CKB-VM: - Creates a child process, without terminating the parent, enabling concurrent script execution. - Keeps the parent script to wait for and retrieve results from the child process, supporting inter-script communication. - Provides IPC-like features (pipes, file descriptors) for message passing between parent and child processes. It brings multi-process scripting on-chain. ⛓️ Why does this matter? It enables: - Modular contract design - Clean separation of logic (e.g. separate signature verifiers) - Message-passing between Scripts - Reusable protocol components (like IPC) Most blockchain VMs, such as Ethereum’s EVM and Solana’s SVM, rely on function-style inter-contract calls: Contract A calls B, gets a return value. 😕 This model is simple, but limited in flexibility and composability. CKB-VM adopts a fundamentally different approach inspired by operating system process management: - Scripts run as isolated processes rather than tightly coupled function calls. - Communication between Scripts is explicit and message-based, not implicit via returns. - Routing and coordination happen at the Script level, giving developers fine-grained control. ⛓️🧩🛰️ This enables capabilities that are difficult or impossible on other blockchains: - True multi-process scripting on-chain. - Modular, composable contracts running concurrently. - Rich inter-script communication resembling IPC in traditional OSes. We’re not chasing VM performance for its own sake. We’re building a Layer 1 where smart contracts are modular, composable, and maintainable — like building with LEGO. Developers can snap together reusable pieces to build complex dApps that are easy to upgrade and extend. 🧱😃 Reference Links: - Syscalls introduced after Meepo: https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0050-vm-syscalls-3/0050-vm-syscalls-3.md - Spawn caller example: https://github.com/nervosnetwork/ckb-std/blob/master/contracts/spawn-caller/src/entry.rs - Spawn callee example: https://github.com/nervosnetwork/ckb-std/blob/master/contracts/spawn-callee/src/entry.rs - IPC on GitHub: https://github.com/XuJiandong/ckb-script-ipc - Transforming IPC in CKB On-Chain Script: Spawn and the Custom Library for Simplified Communication: https://blog.cryptape.com/transforming-ipc-in-ckb-on-chain-script #hardfork #nervos #ckb #web5 #vm #blockchain #UNIX