libp2p / libp2p/go-libp2p-pubsub
GossipSub PX shares unreachable peers
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 364
- Forks
- 221
- PR merge metrics
- No merged PRs in 30d
Description
A few weeks ago we added GossipSub "crawling" support to Nebula [[link](https://github.com/dennis-tra/nebula/pull/92/)]. This works as follows:
1. Connect to a peer that supports GossipSub
2. Wait until the other peer opens the GossipSub (`/meshsub/...`) stream to us and send the hello RPC. This RPC contains the active subscriptions of the remote peer.
3. Send the same hello message back to the remote peer (containing the same subscriptions)
4. Send a graft message to the remote peer that contains all subscriptions
5. Wait for the other peer to send a prune message that then contains additional peers which we can dial.
We are only running this routine for the Filecoin network so far because that's the only network we know of that makes use of the PX feature.
With the above technique we were able to identify ~50% additional peers in the Filecoin network:
```
PX Disabled: crawlDuration=31.395986409s crawledPeers=684
PX Enabled: crawlDuration=51.537761043s crawledPeers=1015
```
However, virtually all of them are unreachable (>97%):
This graph shows the error distribution when trying to dial the peers that we have identified via GossipSub [[source](https://probelab.io/filecoin_mainnet/dht/2025-22/#dial_errors_over_7d_plot-plot)]. There are two error cases that stand out:
- `no_public_address` means that the set of multiaddresses which we have learned through PX does only contain addresses from private IP ranges, e.g., 127.0.0.1. Thus Nebula does not try to dial these peers.
- `io_timeout` means that connecting to the peer timed out (5s dial timeout)
I'm not super familiar with the internals of the GossipSub PX but I would propose to add:
1. Some configuration similar to the various DHT routing table/query/diversity filter [here](https://github.com/libp2p/go-libp2p-kad-dht/blob/2a7d79e9618a5b4148beaa41eb2d846e88a217d5/dht.go#L122) which checks that a peer satisfies some requirements before they are added to the PX pool (like: has at least one public IP address).
2. Periodically checks the pool of PX peers for reachability and removes them from the list (maybe that's already there?)
If both things would solve the problems, according to the above numbers, this would render PX in Filecoin basically useless because there would only be a handful peers being shared around.
I just wanted to start the discussion here and get some feedback 👍
References:
- maybe related https://github.com/libp2p/go-libp2p-pubsub/issues/446
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the Filecoin GossipSub crawl described in the issue and reviewing the referenced DHT configuration in dht.go. Compare PX peers with the no_public_address and io_timeout dial errors, then determine the desired reachability filtering or periodic removal behavior before defining what a fix would consider done.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- distributed-systems, networking
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100