Reconsider checkpoints during node initialization #1771
Description
During the 2025 November hard fork incident, one of the options that was discussed (but not acted upon, for multiple reasons) was to offer a new checkpointing file. There are three important reasons that this option was not preferred.
- It's a very centralized approach. However, in some crises, a disappointing option might be better than no options.
- It wouldn't have prevented subsequent problematic txs from starting another fork.
- The current implementation of checkpointing is not applied to blocks that are already in the VolDB (ie to blocks that are on the youngest 2160 blocks on the nodes selection immediately after the node is initialized).
This Issue is to investigate the elimination that second blocker and discuss it with the product owners of cardano-node: would it be as easy to enable this as I think it would be, and would we want the cardano-node to support this use case?
The checkpoints file was added during the Ouroboros Genesis work. It's original intention was to be able to prevent the node from ever considering known-undesirable alternate historical chains. If Praos has never been "too" unhealthy, then the checkpoint list is unnecessary. However, various outages etc might leave us unable to know whether Praos was healthy enough during some interval. Moreover, the historical chain includes a prefix that was not constructed via Praos. Checkpointing relieves Genesis of the obligation of avoiding alternative historical chains during such segments of the real historical chain.
In particular, that use case is enforced merely by validating incoming headers against the checkpoint list. That's a natural and localized change that achieves the above.
However, that mechanism does not allow checkpoints cause the node to abandon a block it had already downloaded; for example before the node was restarted to ingest a fresher checkpoints list. I suspect a small adjustment to the "reapply" logic within the LedgerDB could easily consult the checkpoints list even when applying a block known to have been validated before.
(I don't remember how the VolDB tracks which blocks have and have not been previously validated. If that set is not persisted to disk, then checkpointing actually can already do what this Issue assumed it could not. Work on this Issue could begin with that simple experiment: shutdown a node, add a checkpoint that's incompatible with a block in its VolDB, restart it and see what happens.)