Multiple chains

TODO: Reorgs, undo data, DisconnectBlock

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:

  1. A single, most-work chain being followed

  2. Stale blocks learned about but not used

  3. 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 CChainState.

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 ChainstateManagers ProcessNewBlockHeaders method to validate it.