Call for Review: CKB2021 Hardfork RFCs

English CKB Development & Technical Discussion
, , ,
1
  • Number: “0037”
  • Category: Informational
  • Status: Draft
  • Author: Ian Yang
  • Organization: Nervos Foundation
  • Created: 2021-07-24

CKB2021 Overview

The blockchain CKB is introducing a hard fork which will be complete by October, 2021. CKB2021 Overview outlines what you need to know for this upgrade.

This is the first hard fork planned when CKB launches. The idea of a hard fork is to update the rules that are set to the network. The changes are not backward compatible. CKB2021 refers to the new CKB edition after the hard fork, where the old edition before the fork is CKB2019.

What’s in CKB2021

CKB2021 brings many new features and bug fixes. As usual, these 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 reasonable.

CKB VM v1

Since CKB2021, there will be multiple VM versions available. RFC32 designs a mechanism to choose the CKB VM version. It uses 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. Now developers can choose how long to wait until a header can be used as a dep header.

CKB2021 Timeline

The mainnet upgrade will be divided into three phases.

  • Stage 1: An RC version of 0.100.0 is ready for preview on July 16 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 try them by running a dev chain locally.

  • Stage 2 (Estimated in August): An updated RC version will activate CKB2021 on Aggron testnet about 1 week after the release.

  • Stage 3 (Estimated in September): The final release 0.100.0 will activate CKB2021 on Lina mainnet about 4 weeks after the release.

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.
6 Likes