Explicit Peering Agreement implementation

[thedevbirb]

🚀 Feature Request

Context

Prysm implements the concept of a “trusted”/”static” peer, which guarantees the ability to always remain connected to a peer ignoring defensive measures such as peer scoring, however it provides no guarantees of being part of their mesh or to send/receive full messages from them unconditionally.

Why explicit peering agreement

Gossipsub v1.1 introduces the concept of "Explicit Peering Agreement", which is an agreement that must be reached from a pair of nodes in order to “remain connected to and unconditionally forward messages to each other outside of the vagaries of the peer scoring system and other defensive measures”.

This feature if enabled in Prysm could allow nodes to explicitly connect to some relays networks such as Fiber or Bloxroute to boost the propagation of their blocks.

Possible implementation

In order to do that, we could simply mimic what has been done for trusted/static peers. In particular:

• set them from the command line
• allow them to be added and removed dynamically
• exclude them from peer scoring or other defensive measures

Lastly this list of nodes needs to be passed to the libp2p implementation.

If there is interest, we can open a PR that implements this functionality.

[nisdas]

We would have to think more on this, but a few things stand out. Dynamically configuring this isn't a good option, as you would have to reinitialize a new pubsub router each time you add/remove the trusted peer. Constantly doing this will lead to peering issues for the node and suboptimal mesh composition. This requires the remote peer to symmetrically reciprocate this as that is the only way the direct peering works.

Not sold on the usefulness of this for the average node as this is to primarily bypass gossip and use trusted relays to receive blocks

[mempirate]

Agreed on the dynamic configuration. As for the usefulness of this, it's not only useful to receive blocks, but also to broadcast them through a relay network, which can help with missed slots / reorgs. To do this reliably, the relay must either be part of the mesh (hard to force), or be an explicit (direct) peer. Explicit peers seem like the best option here since it's much more reliable.

[nisdas]

If this were to be implemented in Prysm, how do you plan to address dynamic addition/removal of trusted peers ? Or is this something that will only be initialized in startup for direct peers with the gossip router

[mempirate]

Since it's an option that can only be specified at startup in gossipsub, we won't support dynamic addition & removal of direct peers. If you agree, we can open a draft PR.

[nisdas]

Sure thing, a draft PR would be helpful to assess its impact

[thedevbirb]

Hi @nisdas, you can check out a draft PR of the implementation in #13773. Thank you!