Nov 2, 2024

One of the optimizations we implemented for checkpoint and milestone runs (slightly differently in each case) was to store strong_tx records in the thread where downloads are stored. This allows that to be performed concurrently, which is a material savings depending on platform. For checkpoints these records are logically irreversible. Milestone block validity is logically irreversible, but a milestone chain (or part of it) may not be a strong chain. So the reorganization of a milestone block reverses the strong_tx association. Since milestone block validity is irreversible, the status as a milestone is stored with the block header. Checkpoints don't require this storage, since they are identifiable by height alone (once headers have been validated, which precedes any storage). Consequently it is the case that a milestone block may end up in a branch that does not actually contain the configured milestone (though must have at one point). In other words, a block that is valid under milestone necessarily remains valid in any other context. This observation simplifies the reorg of a milestone branch, since blocks below the fork point are unaffected by the reorg (i.e. do not have to be validated).