TODO: Reorgs, undo data,
Bitcoin nodes should ultimately converge in consensus on the most-work chain. Being able to track and monitor multiple chain (tips) concurrently is a key requirement for this to take place. There are a number of different states which the client must be able to handle:
A single, most-work chain being followed
Stale blocks learned about but not used
Full reorganisation from one chain tip to another
BlockManager is tasked with maintaining a tree of all blocks learned about, along with their total work so that the most-work chain can be quickly determined.
CChainstate (renamed to
Chainstate in v24.0) is responsible for updating our local view of the best tip, including reading and writing blocks to disk, and updating the UTXO set. A single
BlockManager is shared between all instances of
ChainstateManager is tasked with managing multiple
CChainStates. Currently just a "regular" IBD chainstate and an optional snapshot chainstate, which might in the future be used as part of the assumeUTXO project.
When a new block is learned about (from
src/net_processing.cpp) it will call into
ProcessNewBlockHeaders method to validate it.