Collection of checkpoints indexed by Slot .

Map of checkpoints. Always contains the genesis checkpoint.

Turn the list of checkpoints into a map of checkpoints.

FIXME LATER during ADP-1043: The database actually does not store the checkpoint at genesis, but the checkpoint after that. Hence, this function does not check whether the genesis checkpoint is in the list of checkpoints.

Begin with the genesis checkpoint.

Get the checkpoint with the largest SlotNo .

Find the nearest Checkpoint that is either at the given point or before.

Captures the configuration for the sparseCheckpoints function.

NOTE: large values of edgeSize aren't recommended as they would mean storing many unnecessary checkpoints. In Ouroboros Praos, there's a reasonable probability for small forks each a few blocks deep so it makes sense to maintain a small part that is denser near the edge.

A sensible default to use in production. See also SparseCheckpointsConfig

Storing EVERY checkpoints in the database is quite expensive and useless. We make the following assumptions:

• We can't rollback for more than `k=epochStability` blocks in the past
• It is pretty fast to re-sync a few hundred blocks
• Small rollbacks may occur more often than deep ones

So, as we insert checkpoints, we make sure to:

• Prune any checkpoint that more than k blocks in the past
• Keep only one checkpoint every 100 blocks
• But still keep ~10 most recent checkpoints to cope with small rollbacks

Example 1 : Inserting cp153

ℹ: cp142 is discarded and cp153 inserted.

 Currently in DB:
┌───┬───┬───┬─  ──┬───┐
│cp000 │cp100 │cp142 │..    ..│cp152 │
└───┴───┴───┴─  ──┴───┘
 Want in DB:
┌───┬───┬───┬─  ──┬───┐
│cp000 │cp100 │cp143 │..    ..│cp153 │
└───┴───┴───┴─  ──┴───┘
 

Example 2 : Inserting cp111

ℹ: cp100 is kept and cp111 inserted.

 Currently in DB:
┌───┬───┬───┬─  ──┬───┐
│cp000 │cp100 │cp101 │..    ..│cp110 │
└───┴───┴───┴─  ──┴───┘
 Want in DB:
┌───┬───┬───┬─  ──┬───┐
│cp000 │cp100 │cp101 │..    ..│cp111 │
└───┴───┴───┴─  ──┴───┘
 

NOTE: There might be cases where the chain following "fails" (because, for example, the node has switched to a different chain, different by more than k), and in such cases, we have no choice but rolling back from genesis. Therefore, we need to keep the very first checkpoint in the database, no matter what.

A reasonable gap size used internally in sparseCheckpoints .

Reasonable means that it's not _too frequent_ and it's not too large. A value that is too small in front of k would require generating much more checkpoints than necessary.

A value that is larger than k may have dramatic consequences in case of deep rollbacks.

As a middle ground, we current choose `k / 3`, which is justified by:

• The current speed of the network layer (several thousands blocks per seconds)
• The current value of k = 2160

So, `k / 3` = 720, which should remain around a second of time needed to catch up in case of large rollbacks.