#go-libp2p peerdiscovery + pubsub questions

14 messages · Page 1 of 1 (latest)

native aspen
#

Ok so

#

The DHT is currently made of ~30k + ~200k computers. ( https://probelab.io/ipfsdht/ )
Bootstrap connects your node and register itself in the DHT Keyspace (this will find neighboring nodes by xoring some hash of your peerid, which does not map to anything concrete in the real world, but is a consistent way to order nodes).

#

The DHT has a concept of providers and keys.
Basically you can shout "Hey I have XYZ". Some hashes happen and 20 nodes in the DHT are selected to host this.

#

Theses 20 nodes will store the list of XYZ → [peer ids] of people that shouted this.

#

Gossipsub creates a mesh network between nodes intrested on similar topics.

#

The mesh will implement multicast by relying messages, you need validators if you want to work properly and be resistent but for a PoC you don't really need that.

#

The issue is that ok so your node just starts, there are ~300k potential computers you could talk with, but almost all of them don't care about your gossipsub channel, and have no idea about where your mesh is.

#

So what gossipsub is that it do a DHT query with "who have <insert channel name> ?" the goal here is to get the list, you start with the bootstrap nodes (or someone you discovered during your first DHT refresh) and they wont know because again there is ~30k nodes that could host this list, but due to how the DHT is layed out, they will know someone else that is closer in keyspace, so you repeat multiple times (~log20(30000) ~= 4 (can vary a bit)) then at this point you contacted one of the 20 final nodes and they transmit you the list of nodes that advertise to be intrested in the topic.

#

Finally gossipsub connects to other peoples in the topic and start doing the mesh thing.

#
  • new node starts and reports to some bootstrap node: hi i am interested in topics a, b ,c
  • another node starts, reports to the same bootstrap nodes: hi i am interested in topic b
  • then bootstrap node tells that node "hey earlier there was someone subscribed to the same topic, here is his address"

The bootstrap node has no idea who stores what.
This is a huge hashmap that is sharded on ~30k nodes, the bootstrap process use the bootstrap nodes to properly register yourself in the DHT keyspace.

#

Also:

  • hi i am interested in topic b

is not a message that exists as-is, there are two splited messages instead:

  1. I have XYZ (which can be a CID (hash of file), pubsub topic, or anything really it's just plain binary, ...)
  2. Do you know who has XYZ ?
#

TL;DR:

  • The DHT (Distributed Hash Table) is a network of right now ~30k reachable clients + servers and ~200k unreachable clients. It host a sharded hashmap of random hash → list of peers.
  • Bootstrap nodes aren't like torrent trackers, they don't have a list of everyone and what topics they are on, bootstrap nodes can actually be any node that is already integrated in the DHT. This allows you to seed your local buckets, you then do a multiple hop TRIE coloring process to select 20 nodes that for your precise topic who has what.
  • Running the Bootstrap process register yourself in the DHT keyspace and seed your local routing table with more nodes by querying random things.
  • Gossipsub need to connect to other peoples in the same topic to create the mesh and do peer exchanges, you can directly connect to other peers you want to chat with, but if you don't know them (because let's say they change) you can use the DHT to find them because you will all advertise and search for a commun topic hash, which maps to 20 peers in DHT keyspace which will store the list of nodes inside the topic.
#

BTW a single DHT server stores ~500MiB, records are duplicated ~20 times so:

  • 500MiB * 30000 / 20 ~= 732GiB, that would be big to store on a few bootstrap nodes. That why this is sharded accross random nodes in the network.
#

This could be optimised by using a more compact database but there are limits to that.