Peer Sharing - Which peers do we ask to?

[njd42]

Which of the current established peers do we select to ask?

We don't see any need to ask cold peers as the valency of the established peers is sufficiently high (if, in future, we decide that we do need this we can make peers 'warm' anyway). This means Peer Sharing does not require any additional peer promotion mechanisms.

We are not relying on Peer Sharing to ensure eclipse avoidance.

We need to provide mechanism to disallow Peer Sharing:

• for configured root peers
• as part of the peer handshake (so a remote peer can suppress their inclusion)
  • inbound case
  • outbound case

[njd42]

Need to consider:

• configuration (where, how global)
• handshake
• how quickly will a rich topology emerge from a 'cold' start (bounding worst case)
• when (in a node's operational startup) should Peer Sharing be enabled
  • how does this interact with the bootstrap peer set
• what information should be maintained across a node restart? (how does this interact with bootstrap peers? how does this interact with topographical optimisation?) [maybe orthogonal to Peer Sharing - separate issue?]

[bolt12]

For now Gossip is being idealized as a Request-Response type of protocol, that will happen asynchronously as a way for the node to obtain more known peers (cold in particular). As @njd42 said, only established peers should be picked to gossip to (i.e. start a request-response protocol). Being on the request-ing end of the protocol, one has to first decide a few things:

• When to Peer Share?
  A: Peer Sharing should be managed by peer selection governor, i.e. share requests should be made to fulfill some target. This target does not need to be explicit and we can probably reuse the current legacy-sharing implementation logic. However, there are a couple of requirements regarding this:

  • We probably do not want to Peer Share when in Bulk Sync mode; this might need a global runtime flag.
  • We do not want BPs participating in Peer Sharing; this might need a global configuration flag
  • One might want to explicitly disable Peer Sharing with a given root peer; this might need a local/scoped configuration flag

• Who to ask for peers?
  A: This is already decided: established peers. However, a possible source of established to-gossip peers are inbound connections, so we need a way to know if a given inbound connection is willing to participate in Peer Sharing (i.e. be asked/share); this requires a change in the handshake.

  We ought to make an effort to pick non-ledger peers

  One also needs to discuss if/when should a peer ask the same peer twice.

• How/how many to pick from the established peers to ask?
  A: This might depend on what's expected from the response end of the protocol, but picking should be random.

---

So to summarize:

When the node is making an outbound connection to some peer it should be communicated in the handshake whether we want to be share/be shared.

If the Peer Selection Governor decides it is a good idea to perform share requests to fetch more peers to our Known Set, the node should first (not by this particular order):

• Check the global configuration flag value;
• Check if we are in Bulk-sync mode;

If these first checks go through, all it's left is to pick a random set of peers from the established to-ask set according to some policy (e.g. 20% should be non-ledger peers).

If all requirements are met a Gossip request shall be initialized to all peers that were picked.

---

General comment after giving this some thought is that re-using a lot of the current legacy peer sharing system might be possible since it already takes targets into consideration

[bolt12]

from @njd42:

Let’s assume that, some how, every node is starting with an up-to-date set of ledger peers, root peers are only being used to connect block producing nodes to their relays (so are not creating connectivity outside that ‘strongly-connected-component’ [SCC - graph theory concept]).
Nodes start connecting - the bearer address of the sender (x), as seen at the receiving end (A) gets added to the A’s ‘share address pool’ (assuming for the moment that it verifies) - this is the base case mechanism by which a ‘shared address’ becomes ‘known’.
Another node (either one that initiated a connection to this node ‘A’, or one the was connected to by the node ‘A’) requests ‘please share peers’ - it gets […., x,….] (response containing ‘x’) which is added to its ‘shared address pool’ (after verification). This address is now eligible for 1) being shared to other peers; 2) inclusion in the cold set for this peer.
This process now iterates: In this (contrived) scenario the first iteration (assuming it is not immediately requested after initial connection) might return a handful of peers but each iteration of this approach increases the ‘path length’ of the potential overall to=share set. Remember, our network has a path length of 3 to 10, this is ‘quick’ (in our timescale of interest).
So the topology gets ‘richer’ each iteration - small world graph theory suggests that we would ‘know’ >50% in 2 or 3 iterations, and > 95% in 5 or 6.
Imagine a node performs a gossip request every 600 to 1000 seconds (maybe frequency decreasing as node is operating) eg a sequence of [ 60s±10s, 120±20s, 240±40s, 500±50s, (repeat 1000±100)] the overall system would be ‘extremely well connected’ in around 1000s from this (worst case) scenario described above.

[njd42]

We have concluded that we only need to request from Established Peers reducing network traffic and transient load.