Support for responding to a LocalStateQuery demand for a snapshot of big ledger peers

[crocodile-dentist]

This change equips LocalStateQuery mini protocol app to respond to a request for a snapshot, taken from the current tip, of big ledger peers from a client, eg. cardano-cli. A new query tag GetBigLedgerPeerSnapshot is added to BlockQuery. This data can be loaded later by a node, and it may be leveraged by the network layer to facilitate syncing up a node from a blank or stale state. Diffusion layer is expected to make heavy use of these relays when bootstrapping from scratch in Genesis consensus mode.

[amesgen]

Looks good, only minor comments.

FTR: This builds on top of IntersectMBO/ouroboros-network#4850

[nfrisby]

This seems relatively inexpensive, but do you know roughly whether there's a risk of a CPU and/or allocation spike when handling this query, for example?

[crocodile-dentist]

I had not analyzed this - as far as calculating the big ledger peers from the whole, it is just some folds and sorting, with strictness applied where appropriate, so it should be well behaved for reasonable input. I'm not sure about the workload of fetching raw peers from the ledger. Should I take a closer overall look?

[nfrisby]

I'm not sure about the workload of fetching raw peers from the ledger. Should I take a closer overall look?

Perhaps other members of the Networking Team (eg Marcin? Armando?) have already worried about that being "too expensive", since "getting ledger peers" is pretty primary to the Diffusion Layer?

---

We don't need to pin it down exactly. But it'd be regrettable if some SPO's system was performing poorly because they didn't know that they shouldn't be sending this query too often. So we should be able to document the "rough cost" or some such if that sort of thing is a risk.

[amesgen]

The costs described in #1067 (comment) seem completely fine and in line (or below) what other queries require.

[crocodile-dentist]

I've looked into the performance impact on cpu and memory use of this query on a fully synced node without any peers connected, and results are as follows. Measurements are taken every second for a duration of 5 minutes on an [email protected] GHz with 32 GB of RAM.

5 minute baseline plot when idling:

5 minutes of snapshot requests, where to node is queried in random intervals every 0 to 1 seconds:

There isn't any discernable impact on memory use - no spikes or significant/unusual growth could be determined, and any memory use triggered by the query is neglibigle. Some minor CPU use in excess of the idling load is visible on the second plot, but nothing noteworthy can be concluded from it as it appears to be within reasonable limits.

The query itself executes in around 20ms on the node:
50-100 us to acquire ledger state in an atomic operation
<3 ms to calculate stake pool relays by getPeers (time complexity~ O(n log n) - almost, there is a square term due to removal of duplicate relays for each stake pool, but I assume that the number of relays for each pool is small and can be treated as a constant to simplify things)
<15 ms to calculate which are the big ledger peers (time complexity is O(n log n) with most likely bigger constant terms as there are multiple passes over the stake pools, eg. one pass to calculate the total stake and another to re-compute the relative stake of each pool, and another to sort things)

The resulting snapshot file size is ~50kb.

[jasagredo]

For the fs-sim error I see in ci, update to the CHaP index-state at 2024-06-06T15:28:08Z

[crocodile-dentist]

For the fs-sim error I see in ci, update to the CHaP index-state at 2024-06-06T15:28:08Z

Yes, that's what I figured

[amesgen]

Approving the code that is stacked on top of #1223 👍 (last two commits)

Looks great, only two trivial comments

[amesgen]

Ah, and the new golden files have to be checked in (that's why CI is red ATM). You can generate them locally via cabal build all and then cabal test all --test-options='-p Golden'.