Ledger peers options

[coot]

data FallbackToRoots = FallbackToRoots SlotId | DontFallbackToRoots
data UseLedgerPeers = UseLedgerPeers | DontUseLedgerPeers
data BootStrapPeers peer = BootstrapPeers [peer] | NoBootstrapPeers

Post-Genesis (no bootstrap peers)

Genesis doesn't require bootstrap peers (we can assume NoBootstrapPeers), so this is the simplest case

	FallbackToRoots SlotId	DontFallbackToRoots
UseLedgerPeers	edge nodes, relays	relays
DontUseLedgerPeers	misconfiguration	BPs

In particular the UseLedgerPeers & DontFallbackToRoots can be used by relays which already synced. Unless a relay get's disconnected from the network it needs to sync, while there's available snapshot which is more recent than it's own chain.

edge nodes: for example a full node wallet which runs on an end-consumer hardware which can be turned off periodically.

Pre-Genesis (with bootstrap peers)

Before genesis we can be given bootstrap peers. If they are not given it should work as above, however when BootstrapPeers peers are given then

	FallbackToRoots SlotId	DontFallbackToRoots
UseLedgerPeers	note 1	relays, edge nodes
DontUseLedgerPeers	misconfiguration	BPs

note 1

Consider UseLedgerPeers, FallbackToRoots & BootstrapPeers. This would mean we want to use LedgerPeers after a given slot but use bootstrap peers if we are far from the tip, so it means we will be using ledger peers if we are after the given slot and synced. But the condition to be synced is stronger than be after the given slot. So the meaning is the same as UseLedgerPeers, DontFallbackToRoots & BootstrapPeers.

I think we should still support this configuration (even though it's meaning is the same as the other configuration), because it will give clean transition for edge nodes from pre-genesis to post-genesis era.

[bolt12]

Thanks for writing this up @coot. This distinction makes it easier to wrap my head around 😄

I just have one question. You mentioned the existence of bootstrap peers as one of the conditions (the other being pre/post-genesis) to how things should behave, however you can have NoBootstrapPeers but have trusted local root peers configured, should those count as bootstrap peers, if say, BootstrapPeers is configured with [] or even NoBootstrapPeers ?

[coot]

That's a good question, but I would rephrase it. When should we take into account the trusted flag for local root peers:

• post-genesis: it could be ignored, but we also could take it into account when we are far from the tip (neither will have safety repercussions);
• pre-genesis: we must take it into account when one is using bootstrap peers; if bootstrap peers are not given I would do the same as post-genesis

For simplicity, I would first only took the trusted flag into account when one is using bootstrap peers. Afterwards, we can modify it also in other cases, e.g. remove non-trusted ones when we are far from the tip.

[bolt12]

So we chatted about this and we believe this was very confusing. To mitigate that consider the following data types:

data UseBootstrapPeers domain = DontUseBootstrapPeers
                              | FallbackToPublicRootPeersBefore SlotId
                              | AlwaysUsePublicRootPeers

Essentially this is the UseLedgerAfter data type, but renamed and with a new constructor DontUseBootstrapPeers. This type captures the same semantics that the original post above, but makes explaining it a little bit clearer:

• DontUseBootstrapPeers: This is the new constructor and needed to be added, since Block Producers should not use bootstrap peers. So if a node sets this option pre-genesis, it will ignore the IER (i.e. it won't detect any ledger state judgement changes and act on it). Post-genesis the FallbackToPublicRootPeers and DontFallbackToPublicRootPeers will be renamed to something like FallbackToSnapshotPeers and DontFallbackToSnapshotPeers.

• FallbackToPublicRootPeersBefore SlotId: This is equivalent to UseLedgerAfter SlotId, but renamed. SlotId ought to be positive (i.e. >= 0), which means that the node will use Public Root Peers before the given slot id. When the current slot is after the given slot id, it will start using ledger peers.

• AlwaysUsePublicRootPeers: This is equivalent to DontUseLedgerAfter, but renamed. This can also be the result of parsing a negative slot id. Basically this option means that we won't be using ledger peers and always use Public Root Peers.