TLDR: In block header, we include only the output of claimed slot and future slot (proposal 1). Block justifications contain all outputs of all proofs since parent block (proposal 4)
(The following assumes slots come from PoT and one slot = 1 proof)
Slot numbers (except claimed slot), seed, key and injections are derived from the chain and not explicitly included.
Each block header contains the following proof-of-time information in the header:
passed: covers slots passed since the claimed slot of the parent block. Always covers at least one slot, the claimed slot m for the new block. May need to cover a long time since the parent block and so may need to be squashed to avoid potentially unbounded header size.future: contains the output of slot m+BLOCK_AUTHORING_DELAY to give slower farmers sufficient time to compute the proof-of-space.
Illustrates proposals 1 & 2
Let n be the slot claimed by the parent block, m be the slot of the new block and slots_passed = m-n be the number of slots passed between the two blocks.
PoT for passed contains only a single value - the output of the claimed slot m (that was used for the challenge).
future contains a single value as well - the output of slot m+BLOCK_AUTHORING_DELAY
Size: 128 bit passed + 128 bit future= 256 bit
(Optimization) To make sure block verification time doesn’t grow unbounded, we may add an additional slot output value after every 30 slots (if m-n > 30, 0.05% probability under normal operation). This way it should take less than 15s to verify blocks up to 240 slots (4 min) apart.
Such sparsity would allow us to fit an extreme 22 days of PoT without a block in 1MiB
Online nodes verify the new block’s PoT by comparison to their local pre-verified view of the claimed slot.
Nodes that need to sync older blocks can verify blocks in parallel. Each block verification requires pot_iterations * slots_passed. Injection needs to be handled on certain blocks.