Optionally support lightweight checkpointing

[amesgen]

Description

Closes #5730

This PR adds optional support for lightweight checkpointing. Concretely, a file can contain a list of checkpoints (each consisting of a block number and a corresponding block hash). When validating a header/block with a block number with a corresponding checkpoint, we consider the header/block to be invalid if their actual hash does not coincide with the hash from the checkpoint.

This is only expected to be used in certain disaster recovery scenarios, so ideally never. See CIP-0135 for more details.

Warning

Specifying a checkpoints file requires great care; incorrect entries can lead the node to be stuck on adversarial chains forever!

Concretely, the node configuration file has two new optional entries:

CheckpointsFile: "/path/to/checkpoints.json"
CheckpointsFileHash: "a71c47262163947daaefb6aa1112acf34cb5ded6841d51e27dd642eb2de355a3"

The checkpoints.json file has the following format:

{
  "checkpoints": [
    {"blockNo": 3, "hash": "52b7912de176ab76c233d6e08ccdece53ac1863c08cc59d3c5dec8d924d9b536"}
  ]
}

Testing

Component-level tests for this feature already exist in Consensus, but end-to-end tests might still be useful. I manually tested this PR locally, but a test in CI would be nice. I am not familiar with the various tests in this repo; maybe a test under Cardano.Testnet.Test could work?

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated. These may include:
  • golden tests
  • property tests
  • roundtrip tests
  • integration tests
    See Runnings tests for more details
• Any changes are noted in the CHANGELOG.md for affected package
• The version bounds in .cabal files are updated
• CI passes. See note on CI. The following CI checks are required:
  • Code is linted with hlint. See .github/workflows/check-hlint.yml to get the hlint version
  • Code is formatted with stylish-haskell. See .github/workflows/stylish-haskell.yml to get the stylish-haskell version
  • Code builds on Linux, MacOS and Windows for ghc-8.10.7 and ghc-9.2.7
• Self-reviewed the diff

Note on CI

If your PR is from a fork, the necessary CI jobs won't trigger automatically for security reasons.
You will need to get someone with write privileges. Please contact IOG node developers to do this
for you.

[nfrisby]

This all looks great to me, thanks. I'm not Approving since I'm not a code reviewer for this repository.

[nfrisby]

Maybe some genesis hash config field parser already has this logic somewhere?

[nfrisby]

Personally I'd consider a {blockNoHashPairs: [[3, "abcdef"], [100, "32cdef"]]} format, to avoid the obnoxious per-entry repetition of the field names. But I don't have a lot of experience regarding the widely-expected UX for this sort of thing.

[amesgen]

Yeah 👍, I have no strong opinions here; one tiny advantage of the current format is that it is impossible to forgot that the numbers are referring to block numbers (and not e.g. slot numbers), even when looking at individual checkpoints only; but that is not a major thing.