Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editorial review for CKB hardfork CKB2021 documents #334

Closed
wants to merge 5 commits into from
Closed

Editorial review for CKB hardfork CKB2021 documents #334

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
f33cd68
Editorial review updates
xying21 Apr 22, 2022
e3a06dd
Update 0037-ckb2021.md
xying21 Apr 22, 2022
b367baf
Update 0028-change-since-relative-timestamp.md
xying21 Apr 24, 2022
661ab84
Update according to Ian's suggestion
xying21 Apr 28, 2022
bce9747
Add code tags
xying21 Apr 28, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 19 additions & 15 deletions rfcs/0028-change-since-relative-timestamp/0028-change-since-relative-timestamp.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,16 +11,18 @@ Created: 2021-02-03

## Abstract

This document proposes a transaction verification consensus change. When the `since` field of the transaction input uses a relative timestamp, the referenced cell committing block timestamp is used instead of the median timestamp.
The document proposes a consensus change for transaction verification. When the `since` field of the transaction input uses a relative timestamp, the referenced cell committing block timestamp is used instead of the median timestamp.

This is a modification to the RFC17 [Transaction valid since](../0017-tx-valid-since/0017-tx-valid-since.md).
This is a modification to RFC17, [Transaction Valid Since](../0017-tx-valid-since/0017-tx-valid-since.md).

## Motivation

The current consensus rule uses the median of the timestamps in the 37 blocks preceding the referenced cell committing block. Getting the median timestamp is resource consuming because it requires either getting 37 block headers or caching the median timestamp for each block. The intention of using median time was to prevent miners from manipulating block timestamp to include more transactions. But it is safe to use the committing block timestamp as the start time because of two reasons:
The current consensus rule uses the median of the timestamps in the 37 blocks preceding the committing block of the referenced cell. The intention of using the median timestamp was to prevent miners from manipulating block timestamps in order to include more transactions. It is resource-consuming to get the median timestamp because it requires either getting 37 block headers or caching the median timestamp for each block.

1. The timestamp in the block header has already been verified by the network that it must be larger than the median of the previous 37 blocks and less than or equal to the current time plus 15 seconds. (See [RFC27](../0027-block-structure/0027-block-structure.md#timestamp-uint64))
2. The transaction consuming a cell with the `since` requirement must wait until the cell is mature. During this waiting time, the transaction that created the cell has accumulated enough confirmations that it is difficult for the miner to manipulate it.
It is safe to use the committing block timestamp as the start time for two reasons:

1. The timestamp in the block header has already been verified by the network, and it must exceed the median timestamp of the previous 37 blocks and be less than or equal to the current time plus 15 seconds. (See [RFC27](../0027-block-structure/0027-block-structure.md#timestamp-uint64))
2. The transaction that consumes a cell with the `since` requirement must wait until the cell is mature. During this waiting period, the transaction that created the cell has accumulated enough confirmations that it is difficult for the miner to manipulate it.

## Specification

Expand All @@ -39,38 +41,40 @@ where

* `StartTime` is the block timestamp that commits the cell consumed by the input.
* `SinceValue` is the `value` part of the `since` field.
* `MedianTimestamp` is the median timestamp of the previous 37 blocks preceding the block if the transaction is in the block, or the latest 37 blocks if the transaction is in the pool.
* `MedianTimestamp`
* If the transaction is in a block, `MedianTimestamp` is the median timestamp of the previous 37 blocks preceding the block.
* If the transaction is in the pool, `MedianTimestamp` is the median timestamp of the latest 37 blocks.

The transaction verification fails if the transaction is immature.
If the transaction is immature, the transaction verification fails.

The only change is `StartTime`, which was the median of the previous 37 blocks preceding the one that has committed the consumed cell. Because block timestamp must be larger than the median of its previous 37 blocks, the new consensus rule is more strict than the old rule. A transaction that is mature under the old rule may be immature under the new rule, but a transaction that is mature under the new rule must be mature under the old rule.
The only change is `StartTime`, which was the median of the previous 37 blocks preceding the one that committed the consumed cell. Because the block timestamp must be larger than the median of its previous 37 blocks, the new consensus rule is more strict than the old rule. Transactions that are mature under the old rule may be immature under the new rule, but transactions that are mature under the new rule must also be mature under the old rule.

## Test Vectors

Following is an example that a transaction is mature using the new rule but is immature using the old rule.
The following is an example of a mature transaction using the new rule, but an immature transaction using the old rule.

Assuming that:

* A transaction consumes a cell in block S and is about to be committed into block T with a since requirement that:
* A transaction consumes a cell in block S and is about to be committed into block T with the since requirement that:
* The `metric_flag` is block timestamp (10).
* The `relative_flag` is relative (1).
* The `value` is 600,000 (10 minutes).
* The median of the previous 37 blocks preceding block S is 10,000.
* The timestamp of block S is 20,000.
* The median of the previous 37 blocks preceding block T is 615,000
* The median of the previous 37 blocks preceding block T is 615,000.

In the old consensus, `StartTime` + `SinceValue` = 10,000 + 600,000 = 610,000, which is less than the `MedianTimestamp` 615,000, thus the transaction is mature.
In the old consensus rule, `StartTime` + `SinceValue` = 10,000 + 600,000 = 610,000, which is less than the `MedianTimestamp` 615,000, thus the transaction is mature.

But in the new rule, `StartTime` + `SinceValue` = 20,000 + 600,000 = 620,000 ≥ 615,000, so the transaction is still immature.

## Deployment

The deployment can be performed in two stages.

The first stage will activate the new consensus rule starting from a specific epoch. The mainnet and testnet will use different starting epochs and all other chains will use the new rule from epoch 0.
In the first stage, the new consensus rule will be activated from a specific epoch. Mainnet and testnet will use different epochs, whereas all other chains will use the new rule from epoch 0.

After the fork is activated, and if the transactions in the old epochs all satisfy the new rule, the old consensus rule will be removed and the new rule will be applied from the genesis block.
The second stage occurs after the fork is activated, after which, if the transactions in the old epochs all comply with the new rule, the old consensus rule will be removed and the new rule will take effect from the genesis block.

## Backward compatibility
## Backward Compatibility

Because the new consensus rule is more strict than the old one, this proposal can be deployed via a soft fork.
34 changes: 21 additions & 13 deletions ...tches-on-identical-code/0029-allow-script-multiple-matches-on-identical-code.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,18 +11,18 @@ Created: 2021-02-03

## Abstract

This document proposes a transaction verification consensus change to allow multiple cell dep matches on type script hash when all the matches are resolved to the same script code.
This document proposes a consensus change for transaction verification. This change allows multiple cell dep matches on type script hash when all the matches are resolved to the same script code.

## Motivation

CKB locates the code for lock and type script to execute via data hash or type script hash.
By using data hash or type script hash, CKB finds the code for lock and type script to execute.

CKB allows multiple matches on data hash because it is safe. Data hash is the hash on the code, thus multiple matches must have the same code. This does not hold for type hash. Two cells with the same type script hash may have different contents.
CKB allows multiple matches on data hash because it is safe. Data hash is the hash of the code, so multiple matches must have the same code. Type script hash does not conform to this rule. Cells with the same type script hash may have different contents.

Currently, CKB does not allow multiple matches on type script hash. But in many cases, multiple matches on type script hash do not introduce ambiguity if all the matches have the same data hash as well. Because in the most scenarios, the cause is that the transaction uses two dep groups which contain duplicated cells, the multiple matches on type script hash really point to the same cell.
Currently, CKB does not allow multiple matches on type script hash. However, in many cases, multiple matches on type script hash do not introduce ambiguity if all the matches have the same data hash as well. In most scenarios, the transaction uses two dep groups that contain duplicate cells, so the multiple matches on type script hash actually point to the same cell.

```
# An example that multiple matches on the type script hash really are the same cell.
# An example that multiple matches on the type script hash actually are the same cell.
cell_deps:
- out_point: ...
# Expands to
Expand All @@ -42,17 +42,23 @@ inputs:
hash_type: Type
```

Based on the observation above, this RFC proposes to allow the multiple matches on the type script hash if they all have the same data.
Based on the observation above, this RFC proposes to allow multiple matches on type script hash if they all have the same data.

## Specification

When the transaction verifier locates script code in dep cell via data hash, multiple matches are allowed. This is the same as before.
The same as before, multiple matches are allowed when the transaction verifier locates the script code in the dep cell via data hash.

When the verifier locates code via type hash, multiple matches are allowed if all the matched cells have the same data, otherwise, the transaction is invalid and the verification fails. This is the modification introduced by this RFC.
This RFC introduces the following modification to the case where the verifier locates the code via type hash:

- If all the matched cells have the same data, multiple matches are allowed;

- Otherwise, the transaction is invalid and the verification fails.

## Test Vectors

Multiple matches of data hash. This works in both the old rule and the new one.
**Multiple matches of data hash**

This works in both the old rule and the new one.

```
# hash(Cell B.data) equals to hash(Cell A.data)
Expand All @@ -74,7 +80,9 @@ inputs:
hash_type: Data
```

Multiple matches of type hash which all resolve to the same code. This transaction is invalid using the old rule but valid using the new rule.
**Multiple matches of type hash that all resolved to the same code**

The transaction is invalid under the old rule, but valid under the new rule.

```
# hash(Cell B.data) equals to hash(Cell A.data)
Expand Down Expand Up @@ -102,10 +110,10 @@ inputs:

The deployment can be performed in two stages.

The first stage will activate the new consensus rule starting from a specific epoch. The mainnet and testnet will use different starting epochs and all the development chains initialized via the default settings in this stage will use the new rule from epoch 0.
In the first stage, the new consensus rule will be activated from a specific epoch. The mainnet and testnet will use different starting epochs. All the development chains initialized with the default settings will use the new rule from epoch 0.

After the fork is activated, the old rule will be replaced by the new rule starting from the genesis block by new CKB node versions.

## Backward compatibility
## Backward Compatibility

The consensus rule proposed in this document is looser, so it must be activated via a hard fork. The blocks accepted by new version clients may be rejected by the old versions.
The consensus rule proposed in this document is looser, so it must be activated via a hard fork. The blocks accepted by the new version of clients may be rejected by old versions.
22 changes: 11 additions & 11 deletions ...-index-less-than-length-in-since/0030-ensure-index-less-than-length-in-since.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ Created: 2021-02-04

This document proposes adding a new consensus rule to verify the `since` field in the transaction.

As described in the RFC17, [Transaction valid since](../0017-tx-valid-since/0017-tx-valid-since.md), when a transaction input uses the epoch with fraction in the `since` field, the `value` is an encoded rational number `E + I / L`, where
As described in RFC17, [Transaction valid since](../0017-tx-valid-since/0017-tx-valid-since.md), when a transaction input uses the epoch with fraction in the `since` field, the `value` is an encoded rational number `E + I / L`, where

- `E` is the epoch number.
- `I` is the block index in the epoch.
Expand All @@ -30,32 +30,32 @@ If any `since` field is invalid, the transaction is rejected.

The `since` field prevents the transaction from being mined before an absolute or relative time.

When the `since` field uses epoch with fraction number as the unit, the `value` is an encoded rational number `E + I / L`. If it is a relative time, the rational number is used as it is. But when it is the absolute time, the special rule, **Absolute Epoch With Fraction Value Normalization** as mentioned in RFC17, requires normalizing the number to `E + 1 + 0 / 1` when `I` equals to or is larger than `L`.
This document suggests adding a new rule to verify that when `since` uses epoch as the unit, it must ensure that the index `I` is less than the length `L`.
When the `since` field uses the epoch with a fraction number as the unit, the `value` is an encoded rational number `E + I / L`. If it is a relative time, the rational number is used as it is. But when it is an absolute time, the special rule, **Absolute Epoch With Fraction Value Normalization** as mentioned in RFC17, requires normalizing the number to `E + 1 + 0 / 1` when `I` equals to or is larger than `L`.
This document suggests adding a new rule to ensure that, when `since` uses epoch as the unit, the index `I` must be less than the length `L`.

## Specification

This RFC adds a new verification requirement on the transaction `since` field.
This RFC adds a new verification requirement to the transaction `since` field.

When an input `since` field is present, and the `metric_flag` is epoch (01), the `value` part is the encoded number `E + I / L`. No matter whether the relative flag is `relative` or `absolute`, the number is valid if and only if
When an input `since` field is present, and the `metric_flag` is epoch (01), the `value` part is the encoded number `E + I / L`. No matter whether the relative flag is `relative` or `absolute`, the number is valid only if

- `I` is less than `L`, or
- `I` and `L` are both zero.

There are no changes to the rules in RFC17, except that **Absolute Epoch With Fraction Value Normalization** is no longer needed.
In RFC17, the only rule change is the elimination of **Absolute Epoch With Fraction Value Normalization**.

## Test Vectors

When `since` uses the absolute epoch `99 + 360 / 180`, and the current epoch is `100 + 0 / 180`, the transaction is mature using the old consensus rule but is invalid using the new rule.
When `since` uses the absolute epoch `99 + 360 / 180`, and the current epoch is `100 + 0 / 180`, the transaction is mature under the old consensus rule but is invalid under the new rule.

## Deployment

The deployment can advance in two stages.

The first stage will activate the new consensus rule, starting from a specific epoch. The mainnet and testnet will use different starting epochs and all other chains will use the new rule from epoch 0.
In the first stage, the new consensus rule will be activated from a specific epoch. The mainnet and testnet will use different epochs, whereas all other chains will use the new rule from epoch 0.

The second stage is optional. After the new rule is active, and the blocks in the chain before activation can also pass the new consensus rule, the old rule is redundant and can be safely removed.
The second stage is optional. After the new rule is activated, and the blocks in the chain before activation can also pass the new consensus rule, the old rule is redundant and can be safely removed.

## Backward compatibility
## Backward Compatibility

The new rule is stricter than the old one thus it can be deployed via a soft fork. When most mining nodes have upgraded to the new version, the old version full nodes can keep up to date. Blocks generated by old version mining nodes may be rejected by new version full nodes.
The new rule is stricter than the old one, so it can be deployed via a soft fork. Once most mining nodes have been upgraded to the new version, old full nodes can keep up with it. Old version mining nodes may reject blocks generated by new version full nodes.
Loading