You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After #375, the block_refs in the finality_core contain a record for every ancestor block up to and including the last final block (from the perspective of that block_header_state) in which the record contains the timestamp of the associated block and its block ID (from which the block number can be extracted).
We should also store the finality digest associated with the block in each record. Furthermore, when calculating a finality digest for a particular block_header_state, it should more directly commit to this sequence of block_ref data. Currently, it only commits to it indirectly via the base_digest. But for the convenience of finality violation proofs, we want the finality digest to commit (at some level) to the root digest of a Merkle tree (using our new Merkle tree semantics) over a sequence of records extracted from the sequence of block_refs in the block_refs. This Merkle root digest is called reversible_blocks_root.
The sequence the Merkle tree commits over should be one less than the sequence of block_refs. If there is are no block_refs or only 1 block_ref, then the Merkle root digest can just be the empty digest. Otherwise, the sequence is of records including the block number, finality digest, block timestamp, and the timestamp of the parent block. Because the timestamp of the parent block is part of the record, the first entry in the block_ref vector cannot be included in this sequence (only its timestamp is included as the parent block timestamp in the first record of the sequence).
The reversible_blocks_root should be added at to a struct called level_3_commitments which should also include the base_digest. The hash over this struct is then included in a struct level_2_commitments which also includes the last_pending_finalizer_policy_digest. The reversible_blocks_root should also be including in the finality_data provided through SHiP.
The text was updated successfully, but these errors were encountered:
After #375, the block_refs in the finality_core contain a record for every ancestor block up to and including the last final block (from the perspective of that block_header_state) in which the record contains the timestamp of the associated block and its block ID (from which the block number can be extracted).
We should also store the finality digest associated with the block in each record. Furthermore, when calculating a finality digest for a particular
block_header_state
, it should more directly commit to this sequence of block_ref data. Currently, it only commits to it indirectly via thebase_digest
. But for the convenience of finality violation proofs, we want the finality digest to commit (at some level) to the root digest of a Merkle tree (using our new Merkle tree semantics) over a sequence of records extracted from the sequence of block_refs in the block_refs. This Merkle root digest is calledreversible_blocks_root
.The sequence the Merkle tree commits over should be one less than the sequence of block_refs. If there is are no block_refs or only 1 block_ref, then the Merkle root digest can just be the empty digest. Otherwise, the sequence is of records including the block number, finality digest, block timestamp, and the timestamp of the parent block. Because the timestamp of the parent block is part of the record, the first entry in the block_ref vector cannot be included in this sequence (only its timestamp is included as the parent block timestamp in the first record of the sequence).
The
reversible_blocks_root
should be added at to a struct calledlevel_3_commitments
which should also include thebase_digest
. The hash over this struct is then included in a structlevel_2_commitments
which also includes thelast_pending_finalizer_policy_digest
. Thereversible_blocks_root
should also be including in thefinality_data
provided through SHiP.The text was updated successfully, but these errors were encountered: