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.

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

ckb2021: fix load_cell_data_hash syscall #228

Closed
wants to merge 2 commits into from

Conversation

doitian
Copy link
Member

@doitian doitian commented Apr 25, 2021

No description provided.

@doitian doitian added b:p2p Break P2P protocols soft-fork ckb2021 Hard fork scheduled in 2021 labels Apr 26, 2021
@doitian doitian mentioned this pull request Apr 26, 2021
10 tasks
@doitian doitian marked this pull request as ready for review May 18, 2021 01:21
@doitian doitian requested a review from a team as a code owner May 18, 2021 01:21
@doitian doitian requested review from quake and xxuejie May 18, 2021 01:21

## Abstract

When the syscalls `load_cell_data` and `load_cell_data_hash` load cell from a transaction still in the pool, they should load correct data and hash as the transaction is already in the chain.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are no load_cell_data_hash syscall in current version, it should be load_cell_by_field with the field value 1:
https://github.com/nervosnetwork/rfcs/blob/f0bf9fd6c627f5669e471543d3ba5d62667b592e/rfcs/0009-vm-syscalls/0009-vm-syscalls.md#load-cell-by-field


The syscall `load_cell_data` has bee fixed in [this security advisory](https://github.com/nervosnetwork/ckb/security/advisories/GHSA-29c2-65rj-h343). It now can load data of the cell that is in the pool.

But the syscall `load_cell_data_hash` will fail if it tries to load the hash of a cell not in the chain. The fixing is easy but it will lead to nodes running new version blocked by nodes running the old version.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

accroding to unit test, the syscall wil fail even the cell in the chain, can we confirm this behavior:
https://github.com/nervosnetwork/ckb/blob/develop/chain/src/tests/load_input_data_hash_cell.rs#L90

Comment on lines +20 to +21
Because of a bug, the syscalls `load_cell_data` and `load_cell_data_hash` have wrong behaviors when the referenced cell is from a transaction still in the transaction pool.

Copy link
Member

@zhangsoledad zhangsoledad Jun 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Because of a bug, the syscalls `load_cell_data` and `load_cell_data_hash` have wrong behaviors when the referenced cell is from a transaction still in the transaction pool.
Because of a bug, the syscalls `load_cell_data_hash` has wrong behaviors. It will fail except in the following situations, the referenced transaction still in the transaction pool for an unconfirmed transaction, or the referenced transaction packaged in the same block. It's non-deterministic.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, load_cell_data has no problem. it is forbidden by mistake in GHSA-29c2-65rj-h343, recovered in nervosnetwork/ckb#2382


Because of a bug, the syscalls `load_cell_data` and `load_cell_data_hash` have wrong behaviors when the referenced cell is from a transaction still in the transaction pool.

The syscall `load_cell_data` has bee fixed in [this security advisory](https://github.com/nervosnetwork/ckb/security/advisories/GHSA-29c2-65rj-h343). It now can load data of the cell that is in the pool.
Copy link
Member

@zhangsoledad zhangsoledad Jun 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The syscall `load_cell_data` has bee fixed in [this security advisory](https://github.com/nervosnetwork/ckb/security/advisories/GHSA-29c2-65rj-h343). It now can load data of the cell that is in the pool.
Trasaction pool temporary forbidden syscall `load_cell_data_hash` in [this security advisory](https://github.com/nervosnetwork/ckb/security/advisories/GHSA-q73f-w3h7-7wcc). `load_cell_data_hash` transaction will be rejected by `rpc` or `network`, but on-chain verification is not affected.


The syscall `load_cell_data` has bee fixed in [this security advisory](https://github.com/nervosnetwork/ckb/security/advisories/GHSA-29c2-65rj-h343). It now can load data of the cell that is in the pool.

But the syscall `load_cell_data_hash` will fail if it tries to load the hash of a cell not in the chain. The fixing is easy but it will lead to nodes running new version blocked by nodes running the old version.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
But the syscall `load_cell_data_hash` will fail if it tries to load the hash of a cell not in the chain. The fixing is easy but it will lead to nodes running new version blocked by nodes running the old version.

bors bot added a commit to nervosnetwork/ckb that referenced this pull request Jun 15, 2021
2715: feat(hardfork): ckb2021 hardfork features r=yangby-cryptape a=yangby-cryptape

### Suggestions for Review

**The best way to review this PR is reviewing each commit independently.**

### Brief introduction for Commits

#### New hardfork Features

**All following features can be found in RFC PRs.**

- feat(hardfork): in the "since epoch", the index should be less than length

  Ref: [CKB-RFCs PR 223: Ensure that index < length in input since field using epoch](nervosnetwork/rfcs#223)

- feat(hardfork): use block timestamp of input cells as relative since start timestamp

  Ref: [CKB-RFCs PR 221: Use Block Timestamp as Start Timestamp in Since](nervosnetwork/rfcs#221)

- **[Reverted]** ~~feat(hardfork): allow unknown block versions and transactions versions~~

  ~~Ref: [CKB-RFCs PR 230: Allow unknown tx & block version](nervosnetwork/rfcs#230

- feat(hardfork): allow script multiple matches on identical data for type hash-type scripts

  Ref: [CKB-RFCs PR 222: Allow script multiple matches on identical code](nervosnetwork/rfcs#222)

- feat(hardfork): reuse the uncles hash in the header as the extra hash

  Ref: [CKB-RFCs PR 224: Add a variable length field in the block header](nervosnetwork/rfcs#224)

- **[Reverted]** ~~feat(hardfork): allow loading uncommitted cell data hashes from tx pool~~

  ~~Ref: [CKB-RFCs PR 228: ckb2021: fix load_cell_data_hash syscall](nervosnetwork/rfcs#228

#### Other Important Commits

- feat(hardfork): setup the components for hard fork features

- refactor: let verifiers know the real environment that the transaction is in

  Almost all features require this refactor commit.

- refactor: remove useless parameter "with_data" because it always be true (tricky)

  So I can change less APIs and less code to apply the feature: allow loading uncommitted cell data hashes from tx pool.

### About Tests

Almost all features have detailed integration tests (or unit tests):
- Many blocks before hardfork;
- Only one block before hardfork;
- The block at hardfork;
- Many blocks after hardfork.

All commits can passed all integration tests and unit tests.

Co-authored-by: zhangsoledad <787953403@qq.com>
Co-authored-by: Boyu Yang <yangby@cryptape.com>
bors bot added a commit to nervosnetwork/ckb that referenced this pull request Jun 15, 2021
2715: feat(hardfork): ckb2021 hardfork features r=quake,doitian,zhangsoledad a=yangby-cryptape

### Suggestions for Review

**The best way to review this PR is reviewing each commit independently.**

### Brief introduction for Commits

#### New hardfork Features

**All following features can be found in RFC PRs.**

- feat(hardfork): in the "since epoch", the index should be less than length

  Ref: [CKB-RFCs PR 223: Ensure that index < length in input since field using epoch](nervosnetwork/rfcs#223)

- feat(hardfork): use block timestamp of input cells as relative since start timestamp

  Ref: [CKB-RFCs PR 221: Use Block Timestamp as Start Timestamp in Since](nervosnetwork/rfcs#221)

- **[Reverted]** ~~feat(hardfork): allow unknown block versions and transactions versions~~

  ~~Ref: [CKB-RFCs PR 230: Allow unknown tx & block version](nervosnetwork/rfcs#230

- feat(hardfork): allow script multiple matches on identical data for type hash-type scripts

  Ref: [CKB-RFCs PR 222: Allow script multiple matches on identical code](nervosnetwork/rfcs#222)

- feat(hardfork): reuse the uncles hash in the header as the extra hash

  Ref: [CKB-RFCs PR 224: Add a variable length field in the block header](nervosnetwork/rfcs#224)

- **[Reverted]** ~~feat(hardfork): allow loading uncommitted cell data hashes from tx pool~~

  ~~Ref: [CKB-RFCs PR 228: ckb2021: fix load_cell_data_hash syscall](nervosnetwork/rfcs#228

#### Other Important Commits

- feat(hardfork): setup the components for hard fork features

- refactor: let verifiers know the real environment that the transaction is in

  Almost all features require this refactor commit.

- refactor: remove useless parameter "with_data" because it always be true (tricky)

  So I can change less APIs and less code to apply the feature: allow loading uncommitted cell data hashes from tx pool.

### About Tests

Almost all features have detailed integration tests (or unit tests):
- Many blocks before hardfork;
- Only one block before hardfork;
- The block at hardfork;
- Many blocks after hardfork.

All commits can passed all integration tests and unit tests.

Co-authored-by: zhangsoledad <787953403@qq.com>
Co-authored-by: Boyu Yang <yangby@cryptape.com>
@doitian doitian closed this Jun 23, 2021
@doitian doitian removed the ckb2021 Hard fork scheduled in 2021 label Jul 12, 2021
@doitian doitian deleted the fix-load-cell-data-hash branch February 23, 2023 06:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
b:p2p Break P2P protocols soft-fork
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants