How to efficiently manage peer discovery in a dynamic libp2p network?

Hi everyone,

I am currently building a decentralized app using libp2p and running into challenges with peer discovery in a highly dynamic environment. I am using the JavaScript implementation.., and while the built-in mDNS and bootstrap nodes help initially, things get unreliable as peers frequently join and leave.

My goal is to maintain a more stable view of the network without depending on centralized coordination. I have explored DHT for peer routing…, but sometimes it adds noticeable latency. I also noticed peers occasionally get “stuck,” not discovering new ones unless restarted.

Does anyone have recommendations or best practices on:

Improving peer discovery refresh cycles

Handling churn gracefully

Balancing discovery and performance in real-time apps

Would also appreciate any examples or insights from your projects. I am aiming to keep things lightweight but resilient. Open to trying out other discovery modules or configurations if it leads to better stability. I have also searched on the forum and got this one thread https://discuss.libp2p.io/t/small-group-use-case-10-peers-optimal-peer-discovery-protocol-salesforce-training-in-pune but couldn’t get enough help.

Thanks in advance for any guidance !!

With Regards,
Marcelo

1 Like

Hi Marcelo,

Have you made progress regarding this? In practice it’s very hard to provide high resilience in an open P2P network, especially when there are no incentives. One way of doing it would be to use bootnodes which maintain a healthy set of peers on top of request/response where some node may ask “please send me nodes” and the bootnodes will respond with 5 random nodes.

You may augment this design by using a bloom filter to allow asking for nodes which are not part of the bloom filter, as this data structure is great to efficiently check for elements which are not included. Here are the problems with this approach:

  • bootnodes are a central point of failure, and if they go down then this discovery path is not working.
  • bootnodes are trusted to provide good peers, if they don’t then it could maliciously connect the victim node to an “island” of nodes, segregated from the rest of the network. Also known as an eclipse attack.

The problem with relying on the DHT only is that it is vulnerable to spam attacks, since generating IDs is cheap.