We are pleased to announce that the CKB light client has been deployed to the Pudge testnet! In preparation for activation on the Mirana mainnet, here is some important information about this soft fork and the activation process.
Note: In contrast to hard forks, soft forks are backward compatible. Protocol changes constrain existing valid block conditions, which means any previous software versions will accept new blocks post-soft fork.
Current versions of Neuron and CKB will continue to operate with no user action required.
Light Client soft fork
The CKB light client implements a sampling-based protocol (based on FlyClient), which eliminates the requirement to download and verify all blocks. This will allow users in resource-constrained environments (such as mobile devices or web browsers) to trustlessly and directly interact with CKB. More information can be found in RFC0044.
The CKB light client soft fork leverages the Extensible Block Header, added in the Mirana hard fork, an arbitrary data field in the block header to support future functionality.
The first use of this field will be carrying consensus information for the CKB light client. The soft fork prescribes that the first 32 bytes of the Extensible Block Header field must be a hash of the chain root value included in the preceding block. This field stores a Merkle Mountain Range (MMR) commitment to all previous block headers. A light client can use this value to quickly verify the longest (heaviest) PoW chain.
CKB Soft Fork process
The CKB Soft Fork process draws heavily on the processes used to implement Bitcoin’s BIP91 (SegWit) and BIP341 (Taproot) soft forks. Hash power is used as a coordination mechanism to coordinate a switch to new rules.
Soft forks are proposed through optional software updates and the version field of the CKB block is utilized by miners to express support for backward-compatible changes.
Multiple changes (up to 29) can be proposed in parallel. A period of time is allocated in which a support threshold (% of blocks expressing support) must be met within a period of 42 epochs (~1 week).
If the threshold is met across a period, the change is locked in and will be activated at a later date, after which blocks not conforming to the consensus rules will be rejected by miners.
If a change fails to meet the threshold in the period, the change is rejected.
In proposing a change, the following information is written into the node software, allowing all stakeholders to review the proposed consensus rule changes:
- name: a very brief description of the soft fork, reasonable for use as an identifier.
- bit: which bit in the version field of the block will be used to signal the soft fork lock-in and activation. It is chosen from the set {0,1,2,…,28}.
- start_epoch: the first epoch in which the bit gains meaning.
- timeout_epoch the epoch at which the miner signaling ends. If the soft fork is not locked in by the end of this epoch, the deployment is considered failed.
- period: length of epochs of the signaling period (at least 42 epochs, or ~1 week)
- threshold: the minimum ratio of block per period, which indicate if a soft fork is locked in (90% for mainnet, 75% for testnet)
- minimum_activation_epoch: the epoch at which the soft fork is allowed to become active.
The activation process is described in detail in RFC0043.
This soft fork will be a first for CKB and we look forward to this process of decentralized governance. The testnet signaling period started on Nov 1, mainnet signaling period is currently TBD, watch out for an announcement in the days to come!
To stay updated on all things Nervos:
Join our community: Discord — Github — Nervos Talk Forum — Twitter. For discussions or questions, join the conversation on Discord.