From a11231377aef1465d0344fb9a1e536d3e0c80a26 Mon Sep 17 00:00:00 2001 From: ian Date: Wed, 16 Jun 2021 19:38:39 +0800 Subject: [PATCH 1/8] RFC32: CKB VM version selection --- .../0032-ckb-vm-version-selection.md | 82 ++++++++++++++++++- 1 file changed, 81 insertions(+), 1 deletion(-) diff --git a/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md b/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md index 2fa066b3d..4da049c18 100644 --- a/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md +++ b/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md @@ -1 +1,81 @@ -In review, see , , and +--- +Number: "0032" +Category: Consensus (Hard Fork) +Status: Draft +Author: Ian Yang +Organization: Nervos Foundation +Created: 2021-04-26 +--- + +# CMB VM Version Selection + +## Abstract + +This RFC proposes a mechanism to choose the CKB VM version after the hard fork. What's included in the new CKB VM version is beyond the scope of this document. + +## Motivation + +It's essential to keep improving CKB VM because it is the computation bottleneck of the whole network. The upgrade packages can improve the performance, bring bug fixings and add new RISC-V extensions. However the upgrade should not break the old code, users must have the opt-in option to specify the VM version. + +This RFC proposes a general mechanism that determines how the CKB node chooses the CKB VM version for a transaction script group. + +## Specification + +The CKB VM upgrades via hard fork. The next scheduled hard fork is ckb2021, which is activated since a specific epoch. For all the transactions in the blocks before the activation epoch, they must run the CKB VM version 0 to verify all the script groups. In these transactions, the `hash_type` in cell lock and type script must be either 0 or 1 in the serialized molecule data. + +After ckb2021 is activated, CKB nodes must choose the CKB VM version for each script group. The allowed values for the `hash_type` field in the lock and type script are 0, 1, and 2. Cells are sorted into different groups if they have different `hash_type`. According to the value of `hash_type`: + +* When the `hash_type` is 0, the script group matches code via data hash and will run the code using the CKB VM version 0. +* When the `hash_type` is 1, the script group matches code via type script hash and will run the code using the CKB VM version 1. +* When the `hash_type` is 2, the script group matches code via data hash and will run the code using the CKB VM version 1. + +| `hash_type` | matches by | VM version | +| ----------- | ---------------- | ---------- | +| 0 | data hash | 0 | +| 1 | type script hash | 1 | +| 2 | data hash | 1 | + +See following sections about VM versions. + +The transaction is considered invalid if any `hash_type` is not in the allowed values 0, 1, and 2. + +Because the VM selection algorithm depends on which epoch the transaction belongs to, it is not deterministic for transactions still in the memory pool. The CKB node must run two versions of transaction relay protocols, one for the current CKB version C and another for the next fork version N. + +* Before the fork is activated, CKB node must relay transactions via relay protocol C and must drop all messages received via protocol N. +* After the fork is activated, CKB node must relay transactions via relay protocol N and must drop all messages received via protocol C. + +The relay protocol C will be dropped after the fork succeeds. See [rfc35] for details. + +[rfc35]: ../0035-ckb2021-p2p-protocol-upgrade/0035-ckb2021-p2p-protocol-upgrade.md + +When a new block is appended to the chain and the fork is activated, or a block is rolled back and the fork is deactivated, the CKB node must rerun the verification on all the transactions in the pool. + +In the [Rust implementation of CKB](https://github.com/nervosnetwork/ckb) provided by Nervos Foundation, the `hash_type` is returned as an enum. Now it has three allowed values: + +* 0: "data" +* 1: "type" +* 2: "data1" + +### CKB VM Versions + +The VM version 0 deployed with the Lina and Aggron genesis block is version 0. + +The VM version 1 will be deployed along ckb2021. The [rfc33] highlights the changes in this version, and [rfc34] lists the new syscalls only available since version 1. + +[rfc33]: ../0033-ckb-vm-version-1/0033-ckb-vm-version-1.md +[rfc34]: ../0034-vm-syscalls-2/0034-vm-syscalls-2.md + +## Rationale + +There are many other solutions to select VM versions. The current solution is the result of discussion and trade-off. Following are some example alternatives: + +* Always use the latest VM version. The users have no options to freeze the VM versions used in their transactions. +* Depend on the script code cell epoch. Use the old VM version if the code cell is deployed before the fork, and use the new one otherwise. The problem of this solution is that anyone can re-deploy the cell and construct the transaction using the new code cell to choose VM versions. + +## Backward compatibility + +For cell scripts which reference codes via data hash, they will use the same VM before and after the fork. For those referenced by type hash, they will use the different VM versions. The dApps developers must ensure the compatibility of their scripts and upgrade them if necessary. + +## Acknowledgments + +The authors would like to thank Jan (@janx) and Xuejie (@xxuejie) for their comments and insightful suggestions. The members in the CKB Dev team also helped by participating the discussion and review. Boyu (@yangby-cryptape) is the major author of the code changes, and his experiments and feedbacks are essential to complete this document. From 075273acc276ab556bc0210718375a2bcf9b26db Mon Sep 17 00:00:00 2001 From: ian Date: Sat, 24 Jul 2021 08:11:56 +0800 Subject: [PATCH 2/8] Update rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md Co-authored-by: Boyu Yang --- .../0032-ckb-vm-version-selection.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md b/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md index 4da049c18..ce1bc10b6 100644 --- a/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md +++ b/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md @@ -7,7 +7,7 @@ Organization: Nervos Foundation Created: 2021-04-26 --- -# CMB VM Version Selection +# CKB VM Version Selection ## Abstract From 1730abbd8d0e49278bc4e2167055f107fed0d66b Mon Sep 17 00:00:00 2001 From: ian Date: Tue, 3 Aug 2021 09:46:00 +0800 Subject: [PATCH 3/8] Update rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md --- .../0032-ckb-vm-version-selection.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md b/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md index ce1bc10b6..ea285fcd0 100644 --- a/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md +++ b/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md @@ -50,7 +50,7 @@ The relay protocol C will be dropped after the fork succeeds. See [rfc35] for de When a new block is appended to the chain and the fork is activated, or a block is rolled back and the fork is deactivated, the CKB node must rerun the verification on all the transactions in the pool. -In the [Rust implementation of CKB](https://github.com/nervosnetwork/ckb) provided by Nervos Foundation, the `hash_type` is returned as an enum. Now it has three allowed values: +In [nervosnetwork/ckb](https://github.com/nervosnetwork/ckb), the `hash_type` is returned in the JSON RPC as an enum. Now it has three allowed values: * 0: "data" * 1: "type" From dd5f26a02d3db1659f86c42bdbf52c49975a68bb Mon Sep 17 00:00:00 2001 From: ian Date: Tue, 3 Aug 2021 11:23:23 +0800 Subject: [PATCH 4/8] add cross references between rfc 22, 32, 33, 34, 35 --- .../0022-transaction-structure.md | 6 ++++- .../0032-ckb-vm-version-selection.md | 22 ++++++++++--------- 2 files changed, 17 insertions(+), 11 deletions(-) diff --git a/rfcs/0022-transaction-structure/0022-transaction-structure.md b/rfcs/0022-transaction-structure/0022-transaction-structure.md index 5dc2abf4d..5af8c104c 100644 --- a/rfcs/0022-transaction-structure/0022-transaction-structure.md +++ b/rfcs/0022-transaction-structure/0022-transaction-structure.md @@ -128,10 +128,14 @@ If you want to use a script in CKB, follow the code locating rules: - Compile your code into RISC-V binary. You can find some examples in the [repository](https://github.com/nervosnetwork/ckb-system-scripts) which builds the code for system cells. - Create a cell which stores the binary as data in a transaction, and send the transaction to the chain. -- Construct a script structure, which `hash_type` is "Data", and `code_hash` is just the hash of the built binary. +- Construct a script structure, which `hash_type` is "Data"[^1], and `code_hash` is just the hash of the built binary. - Use the script as the type or the lock script in a cell. - If the script has to run in a transaction, include the code cell's out point in the `cell_deps`. +[^1]: Or "Data1" after [rfc32] is activated. + +[rfc32]: ../0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md + The cells in `cell_deps` must be live, just like `inputs`. Unlike `inputs`, a cell only used in `cell_deps` is not considered dead. The following two chapters will talk about how the script is used in a transaction to lock the cells and establish contracts on cells. diff --git a/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md b/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md index ea285fcd0..f861768bc 100644 --- a/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md +++ b/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md @@ -35,10 +35,19 @@ After ckb2021 is activated, CKB nodes must choose the CKB VM version for each sc | 1 | type script hash | 1 | | 2 | data hash | 1 | -See following sections about VM versions. +The VM version 0 deployed with the Lina and Aggron genesis block is version 0. + +The VM version 1 will be deployed along ckb2021. The [rfc33] highlights the changes in this version, and [rfc34] lists the new syscalls only available since version 1. + +[rfc33]: ../0033-ckb-vm-version-1/0033-ckb-vm-version-1.md +[rfc34]: ../0034-vm-syscalls-2/0034-vm-syscalls-2.md The transaction is considered invalid if any `hash_type` is not in the allowed values 0, 1, and 2. +See more information about code locating using `hash_type` in [rfc22]. + +[rfc22]: ../0022-transaction-structure/0022-transaction-structure.md + Because the VM selection algorithm depends on which epoch the transaction belongs to, it is not deterministic for transactions still in the memory pool. The CKB node must run two versions of transaction relay protocols, one for the current CKB version C and another for the next fork version N. * Before the fork is activated, CKB node must relay transactions via relay protocol C and must drop all messages received via protocol N. @@ -48,6 +57,8 @@ The relay protocol C will be dropped after the fork succeeds. See [rfc35] for de [rfc35]: ../0035-ckb2021-p2p-protocol-upgrade/0035-ckb2021-p2p-protocol-upgrade.md +Attention that, [rfc33], [rfc34], and [rfc35] must be activated together with this one starting at the same epoch. + When a new block is appended to the chain and the fork is activated, or a block is rolled back and the fork is deactivated, the CKB node must rerun the verification on all the transactions in the pool. In [nervosnetwork/ckb](https://github.com/nervosnetwork/ckb), the `hash_type` is returned in the JSON RPC as an enum. Now it has three allowed values: @@ -56,15 +67,6 @@ In [nervosnetwork/ckb](https://github.com/nervosnetwork/ckb), the `hash_type` is * 1: "type" * 2: "data1" -### CKB VM Versions - -The VM version 0 deployed with the Lina and Aggron genesis block is version 0. - -The VM version 1 will be deployed along ckb2021. The [rfc33] highlights the changes in this version, and [rfc34] lists the new syscalls only available since version 1. - -[rfc33]: ../0033-ckb-vm-version-1/0033-ckb-vm-version-1.md -[rfc34]: ../0034-vm-syscalls-2/0034-vm-syscalls-2.md - ## Rationale There are many other solutions to select VM versions. The current solution is the result of discussion and trade-off. Following are some example alternatives: From c0aacf775a347ec44b3b0c02ba6dd67a5a47128c Mon Sep 17 00:00:00 2001 From: ian Date: Thu, 12 Aug 2021 18:37:21 +0800 Subject: [PATCH 5/8] add transaction hash test vectors for data1 hash type --- .../0032-ckb-vm-version-selection.md | 74 +++++++++++++++++++ 1 file changed, 74 insertions(+) diff --git a/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md b/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md index f861768bc..94b318057 100644 --- a/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md +++ b/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md @@ -78,6 +78,80 @@ There are many other solutions to select VM versions. The current solution is th For cell scripts which reference codes via data hash, they will use the same VM before and after the fork. For those referenced by type hash, they will use the different VM versions. The dApps developers must ensure the compatibility of their scripts and upgrade them if necessary. +## Test Vectors + +### Transaction Hash + +This is a transaction containing `data1` hash type. + +
JSON + +```json +{ + "version": "0x0", + "cell_deps": [ + { + "out_point": { + "tx_hash": "0xace5ea83c478bb866edf122ff862085789158f5cbff155b7bb5f13058555b708", + "index": "0x0" + }, + "dep_type": "dep_group" + } + ], + "header_deps": [], + "inputs": [ + { + "since": "0x0", + "previous_output": { + "tx_hash": "0xa563884b3686078ec7e7677a5f86449b15cf2693f3c1241766c6996f206cc541", + "index": "0x7" + } + } + ], + "outputs": [ + { + "capacity": "0x2540be400", + "lock": { + "code_hash": "0x709f3fda12f561cfacf92273c57a98fede188a3f1a59b1f888d113f9cce08649", + "hash_type": "data", + "args": "0xc8328aabcd9b9e8e64fbc566c4385c3bdeb219d7" + }, + "type": null + }, + { + "capacity": "0x2540be400", + "lock": { + "code_hash": "0x9bd7e06f3ecf4be0f2fcd2188b23f1b9fcc88e5d4b65a8637b17723bbda3cce8", + "hash_type": "type", + "args": "0xc8328aabcd9b9e8e64fbc566c4385c3bdeb219d7" + }, + "type": null + }, + { + "capacity": "0x2540be400", + "lock": { + "code_hash": "0x709f3fda12f561cfacf92273c57a98fede188a3f1a59b1f888d113f9cce08649", + "hash_type": "data1", + "args": "0xc8328aabcd9b9e8e64fbc566c4385c3bdeb219d7" + }, + "type": null + } + ], + "outputs_data": [ + "0x", + "0x", + "0x" + ], + "witnesses": [ + "0x550000001000000055000000550000004100000070b823564f7d1f814cc135ddd56fd8e8931b3a7040eaf1fb828adae29736a3cb0bc7f65021135b293d10a22da61fcc64f7cb660bf2c3276ad63630dad0b6099001" + ] +} +``` + +
+ +The Transaction Hash is `0x9110ca9266f89938f09ae6f93cc914b2c856cc842440d56fda6d16ee62543f5c`. + ## Acknowledgments The authors would like to thank Jan (@janx) and Xuejie (@xxuejie) for their comments and insightful suggestions. The members in the CKB Dev team also helped by participating the discussion and review. Boyu (@yangby-cryptape) is the major author of the code changes, and his experiments and feedbacks are essential to complete this document. From 4a5c536ee598a4c5403578020abaa4d5b609c5c5 Mon Sep 17 00:00:00 2001 From: ian Date: Tue, 15 Mar 2022 17:44:12 +0800 Subject: [PATCH 6/8] revise rfc32 according to the review comment --- .../0032-ckb-vm-version-selection.md | 43 +++++++++++++------ 1 file changed, 31 insertions(+), 12 deletions(-) diff --git a/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md b/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md index 94b318057..31e2bfaaa 100644 --- a/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md +++ b/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md @@ -11,7 +11,7 @@ Created: 2021-04-26 ## Abstract -This RFC proposes a mechanism to choose the CKB VM version after the hard fork. What's included in the new CKB VM version is beyond the scope of this document. +This RFC proposes a mechanism to decide on the CKB VM version to execute the transaction scripts. ## Motivation @@ -21,9 +21,20 @@ This RFC proposes a general mechanism that determines how the CKB node chooses t ## Specification -The CKB VM upgrades via hard fork. The next scheduled hard fork is ckb2021, which is activated since a specific epoch. For all the transactions in the blocks before the activation epoch, they must run the CKB VM version 0 to verify all the script groups. In these transactions, the `hash_type` in cell lock and type script must be either 0 or 1 in the serialized molecule data. +When CKB launches the testnet Lina, it only has one VM version, the version 0. The first hard fork will bring VM version 1 which coexists with version 0. Users have the opt-in option to specify which VM version to run the script of a cell by setting the `hash_type` field. -After ckb2021 is activated, CKB nodes must choose the CKB VM version for each script group. The allowed values for the `hash_type` field in the lock and type script are 0, 1, and 2. Cells are sorted into different groups if they have different `hash_type`. According to the value of `hash_type`: +In CKB, each VM version also has its bundled instruction set, syscalls and cost model. The [rfc3], [rfc5], [rfc9] and [rfc14] have defined what is VM version 0. VM version 1 is version 0 plus the revisions mentioned in [rfc33] and [rfc34]. + +[rfc3]: ../0003-ckb-vm/0003-ckb-vm.md +[rfc5]: ../0005-priviledged-mode/0005-priviledged-mode.md +[rfc9]: ../0009-vm-syscalls/0009-vm-syscalls.md +[rfc14]: ../0014-vm-cycle-limits/0014-vm-cycle-limits.md +[rfc33]: ../0033-ckb-vm-version-1/0033-ckb-vm-version-1.md +[rfc34]: ../0034-vm-syscalls-2/0034-vm-syscalls-2.md + +The first hard fork takes effect from an epoch decided by the community consensus. For all the transactions in the blocks before the activation epoch, they must run the CKB VM version 0 to verify all the script groups. In these transactions, the `hash_type` in cell lock and type script must be 0 or 1 in the serialized molecule data. + +After the fork is activated, CKB nodes must choose the CKB VM version for each script group. The allowed values for the `hash_type` field in the lock and type script are 0, 1, and 2. Cells are sorted into different groups if they have different `hash_type`. According to the value of `hash_type`: * When the `hash_type` is 0, the script group matches code via data hash and will run the code using the CKB VM version 0. * When the `hash_type` is 1, the script group matches code via type script hash and will run the code using the CKB VM version 1. @@ -35,18 +46,26 @@ After ckb2021 is activated, CKB nodes must choose the CKB VM version for each sc | 1 | type script hash | 1 | | 2 | data hash | 1 | -The VM version 0 deployed with the Lina and Aggron genesis block is version 0. +The transaction is invalid if any `hash_type` is not in the allowed values 0, 1, and 2. -The VM version 1 will be deployed along ckb2021. The [rfc33] highlights the changes in this version, and [rfc34] lists the new syscalls only available since version 1. +See more information about code locating using `hash_type` in [rfc22]. -[rfc33]: ../0033-ckb-vm-version-1/0033-ckb-vm-version-1.md -[rfc34]: ../0034-vm-syscalls-2/0034-vm-syscalls-2.md +[rfc22]: ../0022-transaction-structure/0022-transaction-structure.md -The transaction is considered invalid if any `hash_type` is not in the allowed values 0, 1, and 2. +The `hash_type` encoding pattern ensures that if a script matches code via type hash, CKB always uses the latest available version of VM depending when the script is executed. But if the script matches code via data hash, the VM version to execute is determined when the cell is created. -See more information about code locating using `hash_type` in [rfc22]. +Here is an example of when VM version 2 is available: -[rfc22]: ../0022-transaction-structure/0022-transaction-structure.md +| `hash_type` | matches by | VM version | +| ----------- | ---------------- | ---------- | +| 0 | data hash | 0 | +| 1 | type script hash | 2 | +| 2 | data hash | 1 | +| \* | data hash | 2 | + +> \* The actual value to represent data hash plus VM version 2 is undecided yet. + +User can trade off between the determination and VM performance boost when creating the cell. Choose data hash for determination, and type hash for the latest VM techniques. Because the VM selection algorithm depends on which epoch the transaction belongs to, it is not deterministic for transactions still in the memory pool. The CKB node must run two versions of transaction relay protocols, one for the current CKB version C and another for the next fork version N. @@ -69,10 +88,10 @@ In [nervosnetwork/ckb](https://github.com/nervosnetwork/ckb), the `hash_type` is ## Rationale -There are many other solutions to select VM versions. The current solution is the result of discussion and trade-off. Following are some example alternatives: +There are many other solutions to select VM versions. The current solution results from discussion and trade-off. Following are some example alternatives: * Always use the latest VM version. The users have no options to freeze the VM versions used in their transactions. -* Depend on the script code cell epoch. Use the old VM version if the code cell is deployed before the fork, and use the new one otherwise. The problem of this solution is that anyone can re-deploy the cell and construct the transaction using the new code cell to choose VM versions. +* Depend on the script code cell epoch. Use the old VM version if the code cell is deployed before the fork, and use the new one otherwise. The problem with this solution is that anyone can re-deploy the cell and construct the transaction using the new code cell to choose VM versions. ## Backward compatibility From 5ed4dfffe3da42318bd0f65a84b797e0076cdfd4 Mon Sep 17 00:00:00 2001 From: ian Date: Tue, 15 Mar 2022 17:54:19 +0800 Subject: [PATCH 7/8] revise rfc32 according to the review comment --- .../0032-ckb-vm-version-selection.md | 23 ++++++++----------- 1 file changed, 9 insertions(+), 14 deletions(-) diff --git a/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md b/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md index 31e2bfaaa..f050bb031 100644 --- a/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md +++ b/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md @@ -65,20 +65,7 @@ Here is an example of when VM version 2 is available: > \* The actual value to represent data hash plus VM version 2 is undecided yet. -User can trade off between the determination and VM performance boost when creating the cell. Choose data hash for determination, and type hash for the latest VM techniques. - -Because the VM selection algorithm depends on which epoch the transaction belongs to, it is not deterministic for transactions still in the memory pool. The CKB node must run two versions of transaction relay protocols, one for the current CKB version C and another for the next fork version N. - -* Before the fork is activated, CKB node must relay transactions via relay protocol C and must drop all messages received via protocol N. -* After the fork is activated, CKB node must relay transactions via relay protocol N and must drop all messages received via protocol C. - -The relay protocol C will be dropped after the fork succeeds. See [rfc35] for details. - -[rfc35]: ../0035-ckb2021-p2p-protocol-upgrade/0035-ckb2021-p2p-protocol-upgrade.md - -Attention that, [rfc33], [rfc34], and [rfc35] must be activated together with this one starting at the same epoch. - -When a new block is appended to the chain and the fork is activated, or a block is rolled back and the fork is deactivated, the CKB node must rerun the verification on all the transactions in the pool. +Cell owners can trade off between the determination and VM performance boost when creating the cell. They should use data hash for determination, and type hash for the latest VM techniques. In [nervosnetwork/ckb](https://github.com/nervosnetwork/ckb), the `hash_type` is returned in the JSON RPC as an enum. Now it has three allowed values: @@ -86,6 +73,14 @@ In [nervosnetwork/ckb](https://github.com/nervosnetwork/ckb), the `hash_type` is * 1: "type" * 2: "data1" +## RFC Dependencies + +This RFC depends on [rfc33], [rfc34], and [rfc35]. The 4 RFCs must be activated together at the same epoch. + +[rfc35]: ../0035-ckb2021-p2p-protocol-upgrade/0035-ckb2021-p2p-protocol-upgrade.md + +The first two RFCs, [rfc33] and [rfc34] are the specification of VM version 1. The [rfc35] proposes to run two versions of transaction relay protocols during the fork, because the VM selection algorithm depends on which epoch the transaction belongs to, thus it is not deterministic for transactions still in the memory pool. + ## Rationale There are many other solutions to select VM versions. The current solution results from discussion and trade-off. Following are some example alternatives: From b72ca1eee0be40ea8347f76eebdf1a1829c5821c Mon Sep 17 00:00:00 2001 From: ian Date: Tue, 15 Mar 2022 17:55:00 +0800 Subject: [PATCH 8/8] Apply suggestions from code review Co-authored-by: zhangsoledad <787953403@qq.com> --- .../0032-ckb-vm-version-selection.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md b/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md index f050bb031..1b590518b 100644 --- a/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md +++ b/rfcs/0032-ckb-vm-version-selection/0032-ckb-vm-version-selection.md @@ -85,7 +85,7 @@ The first two RFCs, [rfc33] and [rfc34] are the specification of VM version 1. T There are many other solutions to select VM versions. The current solution results from discussion and trade-off. Following are some example alternatives: -* Always use the latest VM version. The users have no options to freeze the VM versions used in their transactions. +Consistently uses the latest VM version. The users cannot specify the VM versions for transactions, and the version selection will be non-determine cause it will depend on the chain state. * Depend on the script code cell epoch. Use the old VM version if the code cell is deployed before the fork, and use the new one otherwise. The problem with this solution is that anyone can re-deploy the cell and construct the transaction using the new code cell to choose VM versions. ## Backward compatibility @@ -168,4 +168,4 @@ The Transaction Hash is `0x9110ca9266f89938f09ae6f93cc914b2c856cc842440d56fda6d1 ## Acknowledgments -The authors would like to thank Jan (@janx) and Xuejie (@xxuejie) for their comments and insightful suggestions. The members in the CKB Dev team also helped by participating the discussion and review. Boyu (@yangby-cryptape) is the major author of the code changes, and his experiments and feedbacks are essential to complete this document. +The authors would like to thank Jan (@janx) and Xuejie (@xxuejie) for their comments and insightful suggestions. The members of the CKB Dev team also helped by participating in the discussion and review. Boyu (@yangby-cryptape) is the primary author of the code changes, and his experiments and feedbacks are essential to complete this document.