Bitcoin full node and query server

Nov 2, 2024

View in context in the libbitcoin Slack #general mirror.

A
Antoine Poinsot03:35
So the node is directly usable, for instance in your original 61min benchmark it would be able to process a 840,001th block and fully download+validate+confirm it?
2 replies · evoskuil · last Nov 02, 2024
evoskuil04:23
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).
evoskuil05:09
The final step is confirmation (as opposed to confirmability checks). strong_tx is associated for a block before the confirmability checks for that block occur. This allows the block to be identified as part of the candidate chain under check without identifying the candidate blocks above it as so. But confirmation is the process of reorganizing a confirmable candidate chain into the confirmed height index. Not until that point is any block in the candidate chain considered confirmed (despite being and "strong" and "confirmable"). Confirmable (unlike the strong association) is a terminal state. So a confirmable block never needs to be revalidated (i.e. for reorganization). The final step of confirmation is not necessary (or even used) for validating subsequent blocks, as that is all performed in the candidate chain, and organizing an entire 850k blocks as confirmed (push_confirmed) under milestone takes only a couple seconds.