RFC37: ckb2021 overview

README.md

@@ -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
 

rfcs/0037-ckb2021/0037-ckb2021.md

@@ -1 +1,108 @@
-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 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](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. 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](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 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.
+
+## Upgrade Strategies
+
+First, the SDK, Tool, and dApps authors must adapt to any 1.100.0 rc version.
+
+There are two strategies to upgrade to the CKB2021 consensus.
+
+- Release two different versions or use the feature switcher. Manually deploy the newer version or enable the feature CKB2022 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