Skip to content

Latest commit

 

History

History
105 lines (67 loc) · 7.34 KB

0037-ckb2021.md

File metadata and controls

105 lines (67 loc) · 7.34 KB
Number Category Status Author Created
0037
Informational
Draft
Ian Yang <@doitian>
2021-07-24

CKB Consensus Change (Edition CKB2021)

The current edition of CKB consensus rules is CKB2019. CKB2021 refers to the new edition of CKB consensus rules after its first hardfork. The purpose of a hard fork is to upgrade and update the rules encoded in the network. The changes are not backward compatible. This document outlines the changes in this upgrade.

What's in CKB2021

CKB2021 includes both new features and bug fixes. All changes are proposed via RFCs. The appendix has a list of all the RFCs related to CKB2021.

The upgrade is divided into three categories.

First, CKB VM gets a major upgrade. CKB2021 will bundle CKB VM v1, in addition to the v0 in CKB2019. Scripts will be executed on v1 unless users opt in to use v0 by setting the script hash type to data.

Second, CKB2021 adds a new field extension in the block. This is reserved for future upgrades such as flyclient.

Lastly, there are a bunch of consensus patches to fix bugs and make the consensus rules more robust.

CKB VM v1

Since CKB2021, there will be multiple VM versions available. RFC32 introduces a CKB VM version mechanism. It piggybacks on the hash_type field in the Script structure.

hash_type JSON representation matches by VM version
0 "data" data hash 0
1 "type" type script hash 1
2 "data1" data hash 1

RFC33 introduces what's new in CKB VM v1 and RFC34 adds new syscalls for VM v1.

The new VM version adds new features and performance optimizations. It has fixed identified bugs discovered in v0.

CKB VM v1 supports RISC-V B extension and macro-op fusion. One major rationale behind the changes in CKB-VM is about reducing overheads. RISC-V B extension allows developers to map RISC-V instructions directly with native instructions provided by x86-64 CPUs, while macro-op fusion goes even deeper to exploit modern micro-architectures in CPUs. All those efforts make crypto algorithms more efficiently on CKB-VM, unlocking more potential use cases of Nervos CKB. For example, the BLS signature verification lock consumes too many cycles on CKB now. With the help of B extension, together with macro-op, it's possible to bring the cycles consumption down to a feasible rate.

Given the same transaction, different VM versions may consume different cycles, even give different verification results. RFC35 proposes to use separate transaction relay protocols for each VM version to help the smooth transition of the CKB2021 activation.

Extension Field

RFC31 proposes adding an optional variable length field to the block.

Many extensions require adding new fields into the block. For example, PoA for testnet requires 65 bytes for each signature, and flyclient needs to add a 64 bytes hash. But there's not enough reserved bits in the header for these extensions. The RFC proposes a solution to add a variable length field in the block.

Although the field is added to the block body, nodes can synchronize the block header and this field together without overhead.

CKB2021 will not parse and verify the field after the activation. Instead, it enables a future soft fork to give the definition of the extension field. For example, flyclient can store the hash in the extension field.

Consensus Patches

RFC28 uses block timestamp as the start time for the relative timestamp since field, instead of the median of previous 37 blocks. This simplifies the since maturity calculation.

RFC29 allows multiple matches on dep cells via type script hash when these cells have the same data. It removes unnecessary restrictions when there's no ambiguity to choose matched script code.

RFC30 ensures that the index is less than the length in the since field using epoch as the time measure. It avoids the ambiguity because of the inconsistent behavior when using relative and absolute epoch since.

RFC36 removes header deps immature rule, allowing developers to choose how long to wait until a header can be used as a dep header.

CKB2021 Timeline

The mainnet upgrade is divided into three phases.

  • Stage 1 - Code Preview: An RC version of 0.100.0 is ready for preview on July 16 2021 via nervosnetwork/ckb releases. It will introduce the incompatible changes to help developers to adapt their tools and apps to CKB2021. But this version does not activate the consensus incompatible changes in CKB2021. Developers can test the new rules by running a dev chain locally.

  • Stage 2 - Testnet Activation: With the release of CKB 0.101.0, CKB2021 is set to activate on Aggron testnet on October 24th, 2021. Pudge is the successor guardian of the testnet after activation. Thank you Aggron, Ogre Magi! Look who's coming for dinner, Pudge!

  • Stage 3 - Mainnet Activation: With the release of CKB 0.103.0, CKB2021 will be set to activate on Lina mainnet. The exact mainnet activation time will be determined after Stage 2 passed successfully. Mirana will be the successor guardian of CKB mainnet after activation. Thank you Lina, our flame burns brighter. The moon lights our way, Mirana!

Upgrade Strategies

First, the SDK, Tool, and dApps authors must adapt to any 0.100.0 rc version.

There are two strategies for ecosystem developers to upgrade to the CKB2021 consensus. Choose the former one if the developers can pause the app during the fork activation, otherwise, use the latter one.

  • Release two different versions or use the feature switcher. Manually deploy the newer version or enable the feature CKB2021 after the fork activation.
  • Use feature switcher and enable the feature CKB2021 automatically when the chain grows into the activation epoch. The activation epoch is different in the testnet and the mainnet, which is available via the updated get_consensus RPC.

Appendix

CKB2021 RFCs List

  • 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.
  • RFC37: This RFC, CKB2021 overview.