protocols/gossipsub: Support peer exchange

[mxinden]

Implement the Gossipsub Peer Exchange mechanism, see specification.

Dependencies:

• Signed Envelope and Peer Record: Added via Implement the rendezvous protocol #2107

Today the mentions of Peer Exchange in the Gossipsub implementation are empty stubs.

See also #2397 (comment).

[Frederik-Baetens]

If I understand the spec correctly, peerexchange is performed as part of pruning, but what if I want peerexchange to occur without pruning nodes to make the network more robust against node failures? Would this also be useful there or is making new connections between nodes already in the network done through another mechanism?

[Frederik-Baetens]

Also, the linked comment makes mention of a requirement for "signed peer records". Has this been implemented? Or was that done as part of the rendezvous protocol implementation?

[AgeManning]

Yep looks like signed peer records have been implemented and we can now add peer exchange to gossipsub.

PR's are welcome, but if not, we will get to this.

[AgeManning]

Could you elaborate on when you would like peer exchange to occur?

It was designed so that if you get removed from someone's mesh they give you options to join others. It probably isn't best to try and use gossipsub as a full discovery mechanism as its not designed to be one. One of the main things discovery mechanisms give you is resistance against eclipse attacks. I'd be worried if you try and use only gossipsub you could be more susceptible

[Frederik-Baetens]

PR's are welcome

Great to hear. I might be interested in contributing if it turns out that libp2p peer exchange is actually what I need. It seems like peerexchange is not meant as a mechanism to make new connections between existing nodes in the network for increasing redundancy, but rather as a mechanism to refer nodes to other nodes when during pruning. And I don't think that would help me.

After re-reading the libp2p docs, what I'm asking for would probably require additions to the libp2p spec itself, so I shouldn't really be asking these questions here. But for those still interested, here's how I'd like it to work:

Could you elaborate on when you would like peer exchange to occur?

I'd like peer exchange to occur right after a new node connects.

What occurs now:
state 1: Node A
----node B dials node A
state 2: Node A & Node B connected
----node C dials node A
state 3: Node A & Node B connected; Node A & Node C connected
----node A blows up
state end: B and C don't know about each other, leaving behind a non functioning gossipsub network

What I'd like to happen:
state 1: Node A
----node B dials node A
state 2: Node A & Node B connected
----node C dials node A
state 3: Node A & Node B connected; Node A & Node C connected
----node A informs node B and C about each others existence.
state 4: Node A & Node B connected; Node A & Node C connected; Node B & Node C connected
----node A blows up
state end: B and C do know about each other, leaving behind a perfectly functional gossipsub network

I'm not worried at all about eclipse attacks, since all nodes in my network are perfectly trusted.

I'm attempting to build a hierarchical database where metadata about which data is stored on which nodes can be shared between database nodes, so requests between nodes don't have to travel all the way up the hierarchy. Idk if that explanation makes sense, but the important bit is that I'm trying to use libp2p as peer to peer communication between fully trusted nodes.

Mostly irrelevant tangent on the additional risk of eclipse attacks (expandable)

After briefly thinking about this, I'm not certain that what I want would increase the risk of eclipse attacks. What I want just lets a node that is already trusted introduce some more nodes in case the trusted node fails. I don't immediately see how this increases the risk of eclipse attacks, since without introducing new nodes, the trusted node to which the initial connection is made is the sole (or one of few) trusted nodes, so it already "eclipses" the nodes that connected to it.

I agree that using gossipsub as your sole peer discovery mechanism probably leaves you vulnerable to eclipse attacks, but the extra redundant connections I'd like don't make it worse. (if you only use the redundant connections when the more secure/trusted peer discovery mechanism hasn't recommended enough nodes for a reliable/redundant connection)

[douglaz]

What @Frederik-Baetens described makes sense. Is this scenario part of Gossipsub Peer Exchange?

[Frederik-Baetens]

From what I understood from briefly reading libp2p docs, peerexchange is only meant to keep the network equally robust when a peer is pruned, by offering it new nodes to connect to. It doesn't do anything to make the network more robust when new nodes are joining.

[AgeManning]

After briefly thinking about this, I'm not certain that what I want would increase the risk of eclipse attacks. What I want just lets a node that is already trusted introduce some more nodes in case the trusted node fails. I don't immediately see how this increases the risk of eclipse attacks, since without introducing new nodes, the trusted node to which the initial connection is made is the sole (or one of few) trusted nodes, so it already "eclipses" the nodes that connected to it.
I agree that using gossipsub as your sole peer discovery mechanism probably leaves you vulnerable to eclipse attacks, but the extra redundant connections I'd like don't make it worse. (if you only use the redundant connections when the more secure/trusted peer discovery mechanism hasn't recommended enough nodes for a reliable/redundant connection)

I think this would modify your trust model. Say you trusted 10 peers. If one of them was malicious, then you have 1/10 malcious peers and the majority of nodes are good so you could identify the bad node. In the changes you propose, (if I understand correctly), the 1 malicious node, could then send you 100 more malicious nodes. So then you'd be connected to 101/110 malicious peers and the malicious peers would be the majority.

The way peer exchange is designed to work, is that if Node A disconnects, rather than blowing up, it informs B and C about each other. I think to make gossipsub behave more like a discovery mechanism we'd need to change the gossipsub specs and it might be worth having a discussion on the libp2p-specs repo.

[nazar-pc]

Created libp2p/specs#391 to discuss suggestion from @Frederik-Baetens