nervosnetwork · doitian · Mar 18, 2022 · Jul 14, 2021 · Jul 24, 2021 · Jul 24, 2021
@@ -80,6 +80,7 @@ The maintainers of RFCs will review the proposal, ask if there's any objections,
 | [25](rfcs/0025-simple-udt) | [Simple UDT](rfcs/0025-simple-udt/0025-simple-udt.md) | Xuejie Xiao | Standards Track | Proposal
 | [26](rfcs/0026-anyone-can-pay) | [Anyone-Can-Pay Lock](rfcs/0026-anyone-can-pay/0026-anyone-can-pay.md) | Xuejie Xiao | Standards Track | Proposal
 | [27](rfcs/0027-block-structure) | [CKB Block Structure](rfcs/0027-block-structure/0027-block-structure.md) | Ian Yang | Informational | Draft
+| [37](rfcs/0037-ckb2021) | [CKB 2021](rfcs/0037-ckb2021/0037-ckb2021.md) | Ian Yang | Informational | Draft
 
 ## License
 

@@ -1 +1,107 @@
-In review, see <https://github.com/nervosnetwork/rfcs/pull/242>
+---
+Number: "0037"
+Category: Informational
+Status: Draft
+Author: Ian Yang
+Organization: Nervos Foundation
+Created: 2021-07-24
+---
+
+# CKB2021 Overview
+
+
+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](https://github.com/riscv/riscv-bitmanip) and [macro-op fusion](https://en.wikichip.org/wiki/macro-operation_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**: An RC version of 0.100.0 is ready for preview on July 16 2021 via nervosnetwork/ckb [releases](https://github.com/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**: CKB 0.101.0 has been released to activate CKB2021 on Aggron on October 24th, 2021.
+
+* **Stage 3** (Estimated in March 2022): The final release 0.102.0 will activate CKB2021 on Lina mainnet about 4 weeks after the release.
+
+## 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.
+
+[RFC28]: ../0028-change-since-relative-timestamp/0028-change-since-relative-timestamp.md
+[RFC29]: ../0029-allow-script-multiple-matches-on-identical-code/0029-allow-script-multiple-matches-on-identical-code.md
+[RFC30]: ../0030-ensure-index-less-than-length-in-since/0030-ensure-index-less-than-length-in-since.md
+[RFC31]: ../0031-variable-length-header-field/0031-variable-length-header-field.md
+[RFC32]: ../0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md
+[RFC33]: ../0033-ckb-vm-version-1/0033-ckb-vm-version-1.md
+[RFC34]: ../0034-vm-syscalls-2/0034-vm-syscalls-2.md
+[RFC35]: ../0035-ckb2021-p2p-protocol-upgrade/0035-ckb2021-p2p-protocol-upgrade.md
+[RFC36]: ../0036-remove-header-deps-immature-rule/0036-remove-header-deps-immature-rule.md