Skip to main content

CKB Hard Fork History

This page contains a timeline of all the hard forks, and updates to the Nervos CKB.

2nd Hard Fork – CKB Edition Meepo (2024)​

Mainnet Launch

📅 Date: TBD
⏳ Epoch number: TBD

Testnet Launch

📅 Date: TBD
⏳ Epoch number: TBD

Meepo (2024) Summary​

The CKB Edition Meepo (2024) introduces a range of enhancements into CKB Script development, with one major innovation being Spawn. Spawn enables direct cross-script calls, simplifying development process while offering greater control and optimization. This update significantly enhances the flexibility of CKB Script.

Important Features​

CKB-VM V2
  • One notable addition is the inclusion of a new system call called "Spawn," which can be further explored in the RFC50: CKB-VM Syscalls 3. In essence, Spawn serves as an alternative to dynamic library calls and Exec. With Spawn, a Script can create a child Script with an independent memory area, and data can be passed between the parent and child Scripts without restriction.
  • Implemented more macro-op fusions to reduce cycle consumption, making Scripts run more efficiently.
  • Added a new data2 value in the Scripthash_type field to smoothly manage different VM versions, ensuring a seamless upgrade path.

Tools & Upgrade Requirements​

Below is a comprehensive checklist for updating tools, libraries, and SDKs related to the Meepo hardfork. Ensure all components are updated and tested as per the specified versions and notes below.

Core Components​

  • ckb (crate): v0.119.0 (supports data2 and Spawn)

Standard Libraries​

SDKs​

Development Tools​

Virtual Machines​

Resources​

1st Hard Fork – CKB Edition Mirana (2021)​

Mainnet Launch

📅 Date: May 10, 2022
⏳ Epoch number: 5414

Testnet Launch

📅 Date: Nov 24, 2021
⏳ Epoch number: 3113

Mirana (2021) Summary​

The CKB Edition Mirana (2021) introduces both new features and bug fixes. A major upgrade to the virtual machine, CKB-VM v1, was implemented, with Scripts now executing on this version by default unless specified otherwise. Additionally, a new extension field was added to block headers, reserved for future upgrades like Flyclient. Multiple consensus patches were also applied, fixing bugs and improving the network's robustness.

Important Features​

CKB-VM V1

A key feature of CKB-VM v1 is the support for the RISC-V B extension, which enables direct mapping of RISC-V instructions to native x86-64 CPU instructions. This enhancement significantly improves the efficiency of cryptographic algorithms, such as reducing the cycle consumption of BLS signature verification locks.

Additionally, CKB-VM v1 utilizes Macro-Operation Fusion (MOP) to merge adjacent instructions into single operations, further optimizing performance by exploiting modern CPU micro-architectures.

To manage multiple VM versions, CKB-VM v1 introduces a version selection mechanism utilizing the hash_type field in the Script structure. This mechanism allows developers to specify the desired VM version for script execution, facilitating a smooth transition to the updated virtual machine environment.

Different VM versions may result in varying cycle consumption and verification outcomes for the same transaction. To accommodate these differences, separate transaction relay protocols are proposed for each VM version, ensuring a seamless activation of CKB2021.

Extension Field

The hardfork introduces an optional variable-length field, termed the "extension field," into the block structure. Previously, the fixed-length block header lacked sufficient reserved bits to accommodate such extensions, and this addition addresses the need for incorporating new data into blocks.

The extension field is integrated into the block body, allowing nodes to synchronize the block header and this field concurrently without additional overhead. Post-activation of CKB2021, this field remains unparsed and unverified, serving as a placeholder for future soft forks to define its specific use cases. For instance, Flyclient can utilize the extension field to store its required hash data.

Consensus Patches

Several consensus patches were implemented to enhance the robustness and flexibility of the CKB:

  • Simplified the since field by using block timestamps as the start time.
  • Allowed multiple matches on dependency Cells via Type Script hash when Cells have identical data.
  • Ensured the index is less than the length in the since field using epoch.
  • Removed the header dependencies' immature rule, granting developers more flexibility.

Tools & Upgrade Requirements​

To ensure your project is fully compatible with the new network rules, the following tools and libraries need to be updated:

1. Update your CKB Node & CKB Indexer Node​

ToolsMinimum version required
CKB Nodev0.103.0
CKB Indexer Nodev0.3.2

Follow these steps to update your node:

  1. Download and decompress the latest stable binaries
  2. Shut down your node if it is running
  3. Replace the old binaries with the new binaries
  4. Start the node manually on the command line to complete the migration process, if necessary.
  5. Shut down and restart the node using your normal startup Script.
note

If the CKB node you are updating is running a version below v0.100.0, some code changes may be necessary to ensure compatibility. Breaking changes were introduced to the RPC, which are listed on the release page.

2. Update your supporting libraries​

ToolsMinimum version recommended
PW-SDKv0.4.1-alpha.1
Lumosv0.18.0-rc6
ckb-sdk-jsv0.102.3
ckb-sdk-javav1.0.0
ckb-sdk-gov1.0.0
ckb-sdk-rubyv0.101.0
CKITv0.2.0
ckb-js-toolkitv0.100.0-rc1

3. Update to support CKB2021 Addresses​

The CKB2021 address format replaces both short and long addresses from the past, offering improved flexibility and reduced maintenance. While old addresses will still work, it’s recommended to use CKB2021 for new features introduced in the CKB Edition Mirana (2021) hard fork.

  • PW-SDK and Lumos: Follow their respective guides to support new addresses.
  • Other libraries: refer to the Lumos guide and their official documentation.

4. Omnilock Migration​

After adding Omnilock support, users must migrate assets from their PW-Lock address to the new Omnilock address. While private keys remain unchanged, the addresses will be different.

Developers should guide their users through the migration process and provide tools and instructions for asset migration. The PW-UP Asset Migration Tool (available on GitHub) can be used for migrating sUDT assets.

  • PW-SDK and Lumos: Follow their respective guides for Omnilock support.
  • Other libraries: refer to the Lumos guide and their official documentation.

Resources​

  • Migration Guide
  • CKB2021: Overview
  • RFC28: Use Block Timestamp as Start Timestamp in Since.
  • RFC29: Allow multiple matches on dep cells via type script hash when these cells have the same data.
  • RFC30: Ensure that index is less than length in input since field using epoch.
  • RFC31: Add a variable length field in the block header.
  • RFC32: CKB VM version selection.
  • RFC33: CKB VM version1 changes.
  • RFC34: CKB VM syscalls bundle 2.
  • RFC35: P2P protocol upgrade.
  • RFC36: Remove header deps immature rule.