New Diffusion-Consensus function for caught-up-ness

[nfrisby]

PR IntersectMBO/ouroboros-network#4555 adds a new function to the interface that the Diffusion Layer demands from the Consensus Layer. See Issue IntersectMBO/ouroboros-network#4530 for the underlying motivation.

This task is to implement that function.

The interface we discussed with the Networking Team serves two purposes simultaneously.

• It parses a recent ledger state in order to extract information about the registered stake pools (eg relative stake, relay node IP addresses, etc).

• It decides whether the Diffusion Layer can currently safely sample a root peer from those ledger peers instead of the trusted public root peers (since Genesis is not yet deployed).

We anticipate the parsing will be simple. But the exact decision rule deserves more discussion. It has three constraints:

1. The node should not sample its root peers from a ledger state that is too old, since the contained stake distribution, IP addresses, etc may no longer match the current state of the real world.

2. The node should not sample its root peers from a ledger state when the node's immutable tip is too old, since there's a significant probability that one of its peers is adversarial and so could be performing a long-range attack. (Genesis will supplant this concern.)

3. Otherwise, the node should sample its root peers from the ledger state when possible, to reduce load on the trusted public roots. (ChainSync Jumping will help this, but not supplant it.)

Constraint (2) dominates constraint (1), and constraint (3) is merely saying constraint (2) should not be excessively conservative. So it's really constraint (2) that this issue must design and implement.

See my contribution to the description of Issue IntersectMBO/ouroboros-network#4530 for the approach to satisfying constraint (2). I suspect the implementation will provide a specific threshold of the immutable tip age to use during each era.

Recall that the HFC can always determine the UTC time stamp of a block's ledger state: the ledger state itself must contain suffici information for the time translation to succeed. Thus the node can always determine the age of the immutable tip by mapping it to a UTC time and subtracting it from the wall clock.

[nfrisby]

cc @bolt12 @coot @dnadales

[nfrisby]

Should split this Issue in two: one for the design work, one for the implementation work. We've started the design work, but not the implementation work. EG It may end upthat two separate people do them.

[coot]

@nfrisby we will need a similar API when switching between Genesis and Praos mode to change the number of big ledger peers which the diffusion is using. The design could also answer if they differ or not (which is not obvious to me), or maybe this deserves a separate issue.