PubSub is a messaging system that is used to enhance asynchronous communication between senders and receivers. In this system, a node can publish content to a topic while another node can subscribe to each topic of interest. In this system network traffic and bandwidth requirements are reduced as the the network subscriber's interest are matched to published events. In a p2p pubsub system, peers participate by delivering messages to the groups of interested receivers. The libp2p network has created a number of pubsub implementations that have enabled real time application development for example chat and file sharing applications all without reliance on centralized infrastructure. In this post we will explore each pubsub implementation and its unique take on this communication model. Floodsub This was the first pubsub implementation on libp2p. It's described as a baseline protocol, because it uses a simple but inefficient strategy of "network flooding" where messages are published to all the peers subscribed to a topic without a Casttree forming. The protocol combines the use of Distributed Hash Tables for ambient peer discovery and minimum latency to make it very robust even with high network churn rates. It's ideal for use in chat applications but lacks scaling properties due to its bandwidth and other resources inefficiency. Gossipsub Developed as a successor to Floodsub, Gossipsub is an extensible base protocol based on gossip and randomized topic meshes. It is designed with advanced routing properties, amplification factors and optimized properties to transmit messages and gossip for specific application profiles. With the release of gossipsub v1.1 peers use as the protocol string. This update offers users protocol modifications that make the network scalable and resilient for application development including: meshsub/1.1.0 With this, applications specify an explicit list of peers to remain connected to without consistent peer scoring. Valid messages between these explicit peers are unconditionally forwarded to and accepted by all direct peers. Peering Agreements: Designed to detect malicious or faulty behavior in misbehaving peers, individual peers use a mix of parameters to locally compute a real value score of other peers. By basing the score on observed behavior, malicious peers are penalized with a negative score weighted across all configured topics. Peer Scoring: When enabled, the network mesh is used to propagate messages to all connected & known peers in a topic with a score above a publish threshold. This is used to counter eclipse attacks when gossip is shared by a publishing peer not subscribed to a topic. Flood Publishing: Gossipsub has several other protocol extensions and spam protection measures that have been incorporated to counter messages that elicit responses or dispenses resources unnecessarily for example a. b. . These features and more make gossipsub more efficient than floodsub. With Graft messages for unknown topics are ignored, Iwant message responses are limited to a certain peer & can only be transmitted an X number of times Episub Although still at research phase, Episub is being developed as an extended gossipsub router, optimized for use as a multicast solution capable of broadcast to a large number of clients in a topic. When fully implemented, peers will use the protocol ID to advertise this upgrade. Gossipsub features and extensions will likely be evolved over time until the full scope of the Episub protocol has been attained. meshsub/2.0.0 By implementing the Plumtree algorithm, the protocol will come with several distinct features suggested by the original authors of Plumtree: Membership Management Protocol Fundamentally, this is a subscription management protocol used to manage how peers interact within each topic. The protocol will maintain active and passive peer lists which will enable it to run functions like directing new joins, replacing failed peers and optimizing overlay. Broadcast Protocol Using the active and passive listed maintained by the Membership Management Protocol, the Broadcast protocol, will construct and optimize a multicast tree where active (eager) peers form the edge of the multicast tree and passive (lazy) peers form a gossip mesh to support the tree. In this structure eager peers receive new message broadcasts while the lazy peers receive message summaries. Conclusion Since its launch libp2p has been used as a technology stack in some prominent P2P solutions. Some of these adopters include IPFS, 0x, ETH 2.0, Polkadot, Orbit, Filecoin, Cosmos and a host of independent developers. With launch of Testground, it will be interesting to see on the new ways libp2p will be simulated and implemented in the industry.
