Oct 28, 2024

Not a difference, just a bit more detail than is available in the doc. The header height indices (candidate and confirmed) exist at trivial cost, almost zero. These are the final step in exposing a confirmation (remember the store is always fully read exposed). We have headers and transactions. The only thing that constitutes a "block" is the txs association table, that associates a header to the transactions it "contains". headers are populated first, then when blocks are downloaded, transactions are populated, and then the txs association, and then the indexation of the txs association. At that point the block is archived. So all "blocks" are headers that associate their txs. However these txs do not associate their headers. That would require a costly one to many association, for which there isn't a significant use case. So we implement the 1:0..1 association between a tx and its confirming block (or no block). These associations are set in order, block block by block, during confirmation.