Collation header optimisations

Sharding
6

I may have an optimal solution regarding period_start_prevhash: replace it by the hash of the receipt in the main shard for the transaction that adds the parent collation header. Reasons this is optimal:

  1. It allows for the collation’s validity to only depend on the collation itself, while minimising unnecessary constraints for adding new collation headers. For example, main shard reorgs in the current expected period would no longer force validators to rebroadcast collation headers. Also, notice that including period_start_prevhash prevents two consecutive collation headers from being included in the same block which impedes optimisations such as loose periods.
  2. It allows for the removal of parent_root as it would be Merklelised under the parent receipt hash. The duplication of hashes in the hash chain (once as root, once as parent_root) always felt a bit “wasteful” to me. We now simultaneously only have one “parent” hash, and the collation header hashchain is optimally granular.

The fourth iteration on the collation header is looking something like:

[
    shard: uint256
    number: uint256
    period: uint256
    root: bytes32
    parent_receipt: bytes32
]

with the optional packing of (shard, number, period) under a single uint256 called locator.