From 11942c30bd69320e44c975e7db1a2c577db77819 Mon Sep 17 00:00:00 2001 From: ian Date: Wed, 14 Jul 2021 17:18:45 +0800 Subject: [PATCH 1/6] RFC37: ckb2021 overview --- README.md | 1 + rfcs/0037-ckb2021/0037-ckb2021.md | 11 ++++++++++- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 23362ad04..fa393d80e 100644 --- a/README.md +++ b/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 | Standards Track | Draft ## License diff --git a/rfcs/0037-ckb2021/0037-ckb2021.md b/rfcs/0037-ckb2021/0037-ckb2021.md index 335822386..353661396 100644 --- a/rfcs/0037-ckb2021/0037-ckb2021.md +++ b/rfcs/0037-ckb2021/0037-ckb2021.md @@ -1 +1,10 @@ -In review, see +--- +Number: "0037" +Category: +Status: +Author: +Organization: +Created: +--- + +# CKB2021 Overview From 2aabcb7cc89719464748d20bc4496606826ec7f4 Mon Sep 17 00:00:00 2001 From: ian Date: Sat, 24 Jul 2021 09:19:23 +0800 Subject: [PATCH 2/6] Update 0037-ckb2021.md --- rfcs/0037-ckb2021/0037-ckb2021.md | 99 +++++++++++++++++++++++++++++-- 1 file changed, 94 insertions(+), 5 deletions(-) diff --git a/rfcs/0037-ckb2021/0037-ckb2021.md b/rfcs/0037-ckb2021/0037-ckb2021.md index 353661396..24fa00522 100644 --- a/rfcs/0037-ckb2021/0037-ckb2021.md +++ b/rfcs/0037-ckb2021/0037-ckb2021.md @@ -1,10 +1,99 @@ --- Number: "0037" -Category: -Status: -Author: -Organization: -Created: +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. + +## 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 From 50e7572d69abcb8c5c788deb20df9aedaec5e0e8 Mon Sep 17 00:00:00 2001 From: ian Date: Sat, 24 Jul 2021 13:22:06 +0800 Subject: [PATCH 3/6] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index fa393d80e..8b2a8997f 100644 --- a/README.md +++ b/README.md @@ -80,7 +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 | Standards Track | Draft +| [37](rfcs/0037-ckb2021) | [CKB 2021](rfcs/0037-ckb2021/0037-ckb2021.md) | Ian Yang | Informational | Draft ## License From 35625b62161f9b12eea7b216b7fddd5f4ae2cb15 Mon Sep 17 00:00:00 2001 From: ian Date: Thu, 12 Aug 2021 18:24:18 +0800 Subject: [PATCH 4/6] add guideline about how to upgrade to ckb2021 --- rfcs/0037-ckb2021/0037-ckb2021.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/rfcs/0037-ckb2021/0037-ckb2021.md b/rfcs/0037-ckb2021/0037-ckb2021.md index 24fa00522..917ba887b 100644 --- a/rfcs/0037-ckb2021/0037-ckb2021.md +++ b/rfcs/0037-ckb2021/0037-ckb2021.md @@ -73,6 +73,15 @@ The mainnet upgrade will be divided into three phases. * **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 From 6403a6fd2387154359869133f7b05563061c9fd0 Mon Sep 17 00:00:00 2001 From: ian Date: Wed, 2 Mar 2022 11:46:50 +0800 Subject: [PATCH 5/6] Apply suggestions from code review Co-authored-by: busyforking <5958+janx@users.noreply.github.com> --- rfcs/0037-ckb2021/0037-ckb2021.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/rfcs/0037-ckb2021/0037-ckb2021.md b/rfcs/0037-ckb2021/0037-ckb2021.md index 917ba887b..2d412825a 100644 --- a/rfcs/0037-ckb2021/0037-ckb2021.md +++ b/rfcs/0037-ckb2021/0037-ckb2021.md @@ -9,13 +9,12 @@ 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. +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 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. +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. @@ -23,11 +22,11 @@ First, CKB VM gets a major upgrade. CKB2021 will bundle CKB VM v1, in addition t 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. +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] designs a mechanism to choose the CKB VM version. It uses the `hash_type` field in the Script structure. +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 | | ----------- | ---------- | ---------------- | ---------- | @@ -61,25 +60,25 @@ CKB2021 will not parse and verify the field after the activation. Instead, it en [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. +[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 will be divided into three phases. +The mainnet upgrade is 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 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** (Estimated in August): An updated RC version will activate CKB2021 on Aggron testnet about 1 week after the release. +* **Stage 2**: CKB 0.101.0 has been released to activate CKB2021 on Aggron on October 24th, 2021. -* **Stage 3** (Estimated in September): The final release 0.100.0 will activate CKB2021 on Lina mainnet about 4 weeks after the release. +* **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 1.100.0 rc version. +First, the SDK, Tool, and dApps authors must adapt to any 0.100.0 rc version. -There are two strategies to upgrade to the CKB2021 consensus. +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 CKB2022 after the fork activation. +- 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 From dbc28eea8f5ebca22badbe8aa51b413aa4cec1d3 Mon Sep 17 00:00:00 2001 From: ian Date: Thu, 3 Mar 2022 14:38:33 +0800 Subject: [PATCH 6/6] Apply suggestions from code review Co-authored-by: busyforking <5958+janx@users.noreply.github.com> --- rfcs/0037-ckb2021/0037-ckb2021.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/rfcs/0037-ckb2021/0037-ckb2021.md b/rfcs/0037-ckb2021/0037-ckb2021.md index 2d412825a..c85b0c021 100644 --- a/rfcs/0037-ckb2021/0037-ckb2021.md +++ b/rfcs/0037-ckb2021/0037-ckb2021.md @@ -9,7 +9,6 @@ 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 @@ -66,11 +65,11 @@ CKB2021 will not parse and verify the field after the activation. Instead, it en 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 1 - Code Preview**: 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 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** (Estimated in March 2022): The final release 0.102.0 will activate CKB2021 on Lina mainnet about 4 weeks after the release. +* **Stage 3 - Mainnet Activation**: With the release of CKB 0.102.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