update block format documentation #80
Conversation
✅ Deploy Preview for developer-center ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
ines-toupeira
requested review from
jsdanielh,
hrxi and
nibhar
and removed request for
ii-cruz,
nibhar and
jsdanielh
| | `body_root` | `Blake2sHash` | The root of the Merkle tree representing the body of the block, serving as a commitment to its content | | ||
| | `diff_root` | `Blake2bHash` | The root of the trie diff tree proof, authenticating the state changes between blocks | | ||
| | `history_root` | `Blake2bHash` | The root of a Merkle Mountain Range covering all transactions in the current epoch | | ||
| | `cached_hash` | `Option<Blake2bHash>` | The cached hash of the block header, stored temporarily for performance optimization and not transmitted over the network | |
There was a problem hiding this comment.
The cached_hash should be omitted, since it's an implementation detail and not seen by any program interacting with the nimiq chain.
There was a problem hiding this comment.
What are the arrows supposed to represent?
I think it might be good to add a second micro block there, maybe like a short chain. This would be to show that the parent hash of a micro block can also refer to another micro block.
There are no arrows from parent hash in the macro header, parent election hash, interlink and seed in the macro block.
Why is there an arrow from the election macro header to the micro header?
Maybe election macro header should instead just be a normal macro header?
Macro blocks don't really have transactions in their body, only reward transactions.
| | `history_root` | `Blake2bHash` | The root of a Merkle Mountain Range covering all transactions that occurred in the current epoch | | ||
| | `validators` | `Option<Validators>` | Information about the upcoming validator list. Present only in election macro blocks | | ||
| | `next_batch_initial_punished_set` | `BitSet` | A bitset representing validator slots that are banned from producing blocks in the next batch due to misbehavior | | ||
| | `cached_hash` | `Option<Blake2bHash>` | A cached hash of the block header, used to optimize performance. Not transmitted over the network | |
There was a problem hiding this comment.
Most of the comments on the micro block header also apply to the macro block header.
|
|
||
| A skip block is a [micro block](/learn/protocol/block-format.md) with some differences: it doesn't hold transactions, and consequently, neither a body nor a body root; the VRF seed of this block is the entropy of the random seed of the previous block, as for a new seed to be generated would require a new block leader, and the skip block is leaderless. | ||
| Skip blocks are canonical and fully recognized as part of the main chain. Once a skip block is added, the chain resumes regular micro block production with one validator per block. There is no maximum limit on the number of skip blocks, as skip blocks adapt to the chain’s continuity. |
There was a problem hiding this comment.
Maybe explain what "canonical" means here. Namely that it's always clear how the skip block after any given block has to look like, there are no choices.
| | --- | --- | --- | | ||
| | **Transactions** | None – skip blocks contain no transactions | Contains transactions that update the blockchain state | | ||
| | **Body** | Empty – skip blocks have no transaction or equivocation proof data | Contains transaction data and possibly equivocation proofs | | ||
| | **Body Root** | Empty – since the body is empty, the `body_root` field in the block header is also empty | Contains the Merkle root of the transactions | |
There was a problem hiding this comment.
The skip block's body root seems to be the hash of the empty body instead.
I think there's no Merkle tree for the transactions in a micro body.
| | `body_root` | `Blake2sHash` | The Merkle root representing the body of the block, serving as a commitment to its content | | ||
| | `diff_root` | `Blake2bHash` | The root of the trie diff tree proof, which authenticates the state transitions or changes between blocks | | ||
| | `history_root` | `Blake2bHash` | The root of a Merkle Mountain Range covering all transactions that occurred in the current epoch | | ||
| | `validators` | `Option<Validators>` | Information about the upcoming validator list. Present only in election macro blocks | |
There was a problem hiding this comment.
Is it interesting for the documentation what's in here?
There was a problem hiding this comment.
I also don't get the arrows. And aren't we missing checkpoint macro blocks? Also I believe that the cached hash shouldn't be there since it doesn't go to the serialized representation
There was a problem hiding this comment.
As I mentioned, I don't think cashed hash should be there since it is not serialized
| | `seed` | `VrfSeed` | The BLS signature derived from the seed of the previous block, using the validator key of the block proposer | | ||
| | `extra_data` | `Vec<u8>` | Space reserved for arbitrary data (currently unused) | | ||
| | `state_root` | `Blake2bHash` | The Merkle root representing the blockchain state, acting as a commitment to the current state | | ||
| | `body_root` | `Blake2sHash` | The Merkle root representing the body of the block, serving as a commitment to its content | |
There was a problem hiding this comment.
I don't think this is a Merkle root
Co-authored-by: José Daniel Hernández <[email protected]> Co-authored-by: hrxi <[email protected]>
No description provided.