-
Notifications
You must be signed in to change notification settings - Fork 61
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
add 3rd batch of tech-terms and images
- Loading branch information
Showing
15 changed files
with
269 additions
and
17 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,92 @@ | ||
| --- | ||
| id: block | ||
| title: Block | ||
| --- | ||
|
|
||
| # Block | ||
|
|
||
| A block is a container of transactions, carrying the information required by consensus so the participants can verify and recognize the canonical chain. | ||
|
|
||
| <img src={"/img/tech_explanation/block-structure.png"} width={688} height={400} alt="Structure of Block" /> | ||
|
|
||
| ## Fields & Description | ||
|
|
||
| | Name | Type | Description | | ||
| | -------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | `header` | Header | Header contains the block’s metadata. For more, see [`header`](/docs/tech-explanation/header) | | ||
| | `transactions` | [Transaction] | An array of committed transactions contained in the block. For more, see [`transactions`](/docs/tech-explanation/transactions) | | ||
| | `uncles` | [UncleBlock] | An array of the block’s uncle blocks. For more, see [`uncles`](/docs/tech-explanation/uncles) | | ||
| | `proposals` | [H80] | An array of hex-encoded short transaction IDs of the proposed transactions. For more, see [`proposals`](/docs/tech-explanation/proposals) | | ||
|
|
||
| ## Example | ||
|
|
||
| ```json | ||
| { | ||
| "uncles": [ | ||
| { | ||
| "proposals": [], | ||
| "header": { | ||
| "compact_target": "0x1a9c7b1a", | ||
| "hash": "0x87764caf4a0e99302f1382421da1fe2f18382a49eac2d611220056b0854868e3", | ||
| "number": "0x129d3", | ||
| "parent_hash": "0x815ecf2140169b9d283332c7550ce8b6405a120d5c21a7aa99d8a75eb9e77ead", | ||
| "nonce": "0x78b105de64fc38a200000004139b0200", | ||
| "timestamp": "0x16e62df76ed", | ||
| "transactions_root": "0x66ab0046436f97aefefe0549772bf36d96502d14ad736f7f4b1be8274420ca0f", | ||
| "proposals_hash": "0x0000000000000000000000000000000000000000000000000000000000000000", | ||
| "uncles_hash": "0x0000000000000000000000000000000000000000000000000000000000000000", | ||
| "version": "0x0", | ||
| "epoch": "0x7080291000049", | ||
| "dao": "0x7088b3ee3e738900a9c257048aa129002cd43cd745100e000066ac8bd8850d00" | ||
| } | ||
| } | ||
| ], | ||
| "proposals": ["0x5b2c8121455362cf70ff"], | ||
| "transactions": [ | ||
| { | ||
| "version": "0x0", | ||
| "cell_deps": [], | ||
| "header_deps": [], | ||
| "inputs": [ | ||
| { | ||
| "previous_output": { | ||
| "tx_hash": "0x0000000000000000000000000000000000000000000000000000000000000000", | ||
| "index": "0xffffffff" | ||
| }, | ||
| "since": "0x129d5" | ||
| } | ||
| ], | ||
| "outputs": [ | ||
| { | ||
| "capacity": "0x1996822511", | ||
| "lock": { | ||
| "code_hash": "0x9bd7e06f3ecf4be0f2fcd2188b23f1b9fcc88e5d4b65a8637b17723bbda3cce8", | ||
| "args": "0x2ec3a5fb4098b14f4887555fe58d966cab2c6a63", | ||
| "hash_type": "type" | ||
| }, | ||
| "type": null | ||
| } | ||
| ], | ||
| "outputs_data": ["0x"], | ||
| "witnesses": [ | ||
| "0x590000000c00000055000000490000001000000030000000310000009bd7e06f3ecf4be0f2fcd2188b23f1b9fcc88e5d4b65a8637b17723bbda3cce801140000002ec3a5fb4098b14f4887555fe58d966cab2c6a6300000000" | ||
| ], | ||
| "hash": "0x84395bf085f48de9f8813df8181e33d5a43ab9d92df5c0e77d711e1d47e4746d" | ||
| } | ||
| ], | ||
| "header": { | ||
| "compact_target": "0x1a9c7b1a", | ||
| "hash": "0xf355b7bbb50627aa26839b9f4d65e83648b80c0a65354d78a782744ee7b0d12d", | ||
| "number": "0x129d5", | ||
| "parent_hash": "0x4dd7ae439977f1b01a8c9af7cd4be2d7bccce19fcc65b47559fe34b8f32917bf", | ||
| "nonce": "0x91c4b4746ffb69fe000000809a170200", | ||
| "timestamp": "0x16e62dfdb19", | ||
| "transactions_root": "0x03c72b4c2138309eb46342d4ab7b882271ac4a9a12d2dcd7238095c2d131caa6", | ||
| "proposals_hash": "0x0000000000000000000000000000000000000000000000000000000000000000", | ||
| "uncles_hash": "0x90eb89b87b4af4c391f3f25d0d9f59b8ef946d9627b7e86283c68476fee7328b", | ||
| "version": "0x0", | ||
| "epoch": "0x7080293000049", | ||
| "dao": "0xae6c356c8073890051f05bd38ea12900939dbc2754100e0000a0d962db850d00" | ||
| } | ||
| } | ||
| ``` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,56 @@ | ||
| --- | ||
| id: header | ||
| title: header | ||
| --- | ||
|
|
||
| # header | ||
|
|
||
| `header` is a sub-structure of `Block` and `UncleBlock`, including `raw` and `nonce`. | ||
|
|
||
| <img src={"/img/tech_explanation/header-structure.png"} width={688} height={391} alt="Structure of header" /> | ||
|
|
||
| ## Fields & Description | ||
|
|
||
| | Name | Type | Description | | ||
| | ------- | --------- | --------------------------------------------------------------------------------------------- | | ||
| | `raw` | RawHeader | The payload of the block header. For more, see [RawHeader](/docs/tech-explanation/rawheader). | | ||
| | `nonce` | uint128 | The solution of the PoW puzzle. Similar to [Bitcoin nonce](https://en.bitcoin.it/wiki/Nonce). | | ||
|
|
||
| ## Verification Process for Header | ||
|
|
||
| This following snippet describes the process to validate the PoW for a block header in the Nervos CKB blockchain: | ||
|
|
||
| 1. Serializing and hashing the block's raw data. | ||
| 2. Concatenating the hash with the nonce. | ||
| 3. Running the concatenated result through the Eaglesong algorithm. | ||
| 4. (Optional) Re-hashing for the Testnet. | ||
| 5. Converting the final output to an integer and ensuring it meets the required difficulty target. | ||
|
|
||
| ``` | ||
| pow_hash := ckbhash(molecule_serialize(raw)) | ||
| pow_message := pow_hash || to_le(nounce) | ||
| pow_output := eaglesong(pow_message) | ||
| // for Testnet, there is another round of hash | ||
| // pow_output = ckbhash(pow_output) | ||
| from_be(pow_output) <= compact_to_target(raw.compact_target) | ||
| ``` | ||
|
|
||
| Functions used in the pseudocode | ||
|
|
||
| - `:=`: assignment | ||
| - `||`: binary concatenation | ||
| - `ckbhash`: [Blake2b hash](https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0027-block-structure/0027-block-structure.md#ckbhash) with CKB specific configuration | ||
| - `to_le`: converts unsigned integer to bytes in little-endian. The bytes count is the same with the integer width. | ||
| - `from_be`: converts bytes encoded in big-endian to an unsigned integer | ||
| - `molecule_serialize`: serializes a structure into binary using its schema | ||
| - `eaglesong`: CKB’s Proof-of-Work consensus algorithm. See [RFC0010: Eaglesong](https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0010-eaglesong/0010-eaglesong.md) | ||
| - `compact_to_target`: restores the target from its compact form, which is the difficulty target encoded by `raw.compact_target` | ||
|
|
||
| ## Header Hash Derivation & Usage | ||
|
|
||
| The `header` is hashed to produce a unique `header_hash`. This `header_hash` is then used to reference the block. | ||
|
|
||
| ``` | ||
| header_hash := ckb_hash(molecule_serialize(header)) | ||
| ``` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,27 @@ | ||
| --- | ||
| id: proposals | ||
| title: proposals | ||
| --- | ||
|
|
||
| # proposals | ||
|
|
||
| `proposals` refer to an array of hex-encoded short transaction IDs that represent proposed transactions within a block or its uncle blocks. A transaction proposal ID is the first 10 bytes of the transaction hash. In CKB, the transaction proposal ID must be proposed before a transaction can be committed to the blockchain. | ||
|
|
||
| - A transaction is considered **proposed** if its proposal ID is listed in the `proposals` field of a block or an uncle of that block. | ||
| - A transaction is considered **committed** once it appears in a block’s `transactions` field. | ||
|
|
||
| <img src={"/img/tech_explanation/proposal-lifecycle.png"} width={688} height={362} alt="Lifecycle of proposals" /> | ||
|
|
||
| Two protocol parameters, `close` and `far`, specify the closest and farthest on-chain distances between a transaction's proposal and commitment. A non-cellbase transaction commit in block `c` must have been proposed in block `p`, where | ||
|
|
||
| ``` | ||
| close <= c - p <= far | ||
| ``` | ||
|
|
||
| In CKB's Mainnet, `close` is 2 and `far` is 10. Thus: | ||
|
|
||
| ``` | ||
| 2 <= c - p <= 10 | ||
| ``` | ||
|
|
||
| As shown above, when a transaction is committed in Block 23, it should have been proposed in the `tx_proposal_window` between Block 13 and Block 21. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,28 @@ | ||
| --- | ||
| id: rawheader | ||
| title: RawHeader | ||
| --- | ||
|
|
||
| # RawHeader | ||
|
|
||
| `RawHeader` is the payload of the block header. | ||
|
|
||
| <img src={"/img/tech_explanation/rawheader-structure.png"} width={688} height={568} alt="Structure of RawHeader" /> | ||
|
|
||
| ## Fields & Description | ||
|
|
||
| | Name | Type | Description | | ||
| | ------------------- | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | `version` | Uint32 | Version of the block, used to address potential compatibility issues that might arise after a fork | | ||
| | `compact_target` | Uint32 | PoW difficulty represented in compact target format | | ||
| | `timestamp` | Uint64 | A [Unix time](https://en.wikipedia.org/wiki/Unix_time) timestamp in milliseconds | | ||
| | `number` | Uint64 | Indicates block height | | ||
| | `epoch` | Uint64 | Information of the current epoch. Assuming `number` represents the current epoch number, `index` represents the index of the block in the current epoch (starting at 0), and length represents the length of the current epoch, the value must be `(number & 0xFFFFFF) \| ((index & 0xFFFF) << 24) \| ((length & 0xFFFF) << 40)` | | ||
| | `parent_hash` | H256 (hash) | Hash of the parent block | | ||
| | `transactions_root` | H256 (hash) | A hash obtained by concatenating the CBMT (Complete Binary Merkle Tree) root of the transaction hashes and the CBMT root of the transaction witness hashes | | ||
| | `proposals_hash` | H256 (hash) | Hash of the concatenated proposal IDs. Defaults to all zeros if no proposals exist. | | ||
| | `uncles_hash` | H256 (hash) | Hash of the concatenated hashes of uncle block headers. Defaults to all zeros if no proposals exist. | | ||
| | `dao` | Bytes | Contains DAO-related data. Refer to [RFC0023: Deposit and Withdraw in Nervos DAO](https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0023-dao-deposit-withdraw/0023-dao-deposit-withdraw.md) for details. | | ||
| | `nonce` | Uint128 | The solution of the PoW puzzle. Similar to [Bitcoin nonce](https://en.bitcoin.it/wiki/Nonce). | | ||
|
|
||
| Refer to the [RawHeader in RFC-0027](https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0027-block-structure/0027-block-structure.md#rawheader) for an in-depth explanation. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,10 @@ | ||
| --- | ||
| id: transactions | ||
| title: transactions | ||
| --- | ||
|
|
||
| import Tooltip from "@components/Tooltip"; | ||
|
|
||
| # transactions | ||
|
|
||
| An array of committed transactions contained in the block. Each element of this array has the same structure as the [transaction structure](/docs/tech-explanation/transaction). The first transaction must be the <Tooltip>cellbase</Tooltip>. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,33 @@ | ||
| --- | ||
| id: uncles | ||
| title: uncles | ||
| --- | ||
|
|
||
| import Tooltip from "@components/Tooltip"; | ||
|
|
||
| # uncles | ||
|
|
||
| `UncleBlock` is a sub-structure of `Block`. It is the ordered list of uncle blocks. | ||
|
|
||
| <img src={"/img/tech_explanation/uncleblock-structure.png"} width={688} height={304} alt="Structure of UncleBlock" /> | ||
|
|
||
| ## Fields & Description | ||
|
|
||
| | Name | Type | Description | | ||
| | ----------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | `header` | Header | Block header of the uncle block. The structure is the same as the [header](/docs/tech-explanation/header). | | ||
| | `proposals` | [H80] | An array of short transaction IDs of the proposed transactions in this uncle block. For more, see [`proposals`](/docs/tech-explanation/proposals) | | ||
|
|
||
| ## Uncle Block | ||
|
|
||
| Uncle blocks are created when 2 blocks are mined and submitted to the ledger at roughly the same time. Only 1 can enter the ledger as an included block, and the other does not. | ||
|
|
||
| <img src={"/img/tech_explanation/uncle-block-relationship.png"} width={688} height={271} alt="Uncle Block Condition" /> | ||
|
|
||
| Block B1 is considered to be the uncle of block B2 if all the following conditions are met: | ||
|
|
||
| - B1 should not be on the main chain. | ||
| - Both are in the same <Tooltip>epoch</Tooltip> with identical difficulty. | ||
| - B2 has higher block number/height than B1. | ||
| - B1's parent is either B2's ancestor or an uncle embedded in B2, or any of B2's ancestors. | ||
| - B2 is the first block in its chain to reference B1. |
Oops, something went wrong.