How GossipSub Overlays Empower Ethereum's Consensus Layer

Peer-to-peer networks are characterized by the large-scale broadcast of messages between nodes.  Efficient broadcast is therefore essential for maintaining the integrity and performance of decentralized networks like Ethereum. Ethereum’s Beacon network employs a topic-based broadcast protocol called GossipSub to disseminate its protocol messages. In this blog post, we will explore GossipSub, how it works, and its role in the broader Ethereum ecosystem.

How GossipSub enables efficient communication

At its core, Gossipsub is a collection of P2P overlays, one per “topic”.  P2P overlays, as mentioned in Part 1 of this series, refer to the network topology formed by the interconnected nodes within Ethereum's network.  Nodes in a GossipSub network can “subscribe” to a topic–effectively joining its corresponding overlay– in order to receive messages that are “published” to it.  The key feature of GossipSub is that each of these overlays is self-optimizing, allowing each message to travel along the shortest path to each of its neighbors.  This property is at the heart of GossipSub’s efficiency at scale.

The self-optimizing behavior of each topic’s overlay is provided by a subprotocol called Plumtree (short for Push Lazy-pUsh Multicast Tree).  At its core, Plumtree is based on the concept of epidemic broadcast, where a peer randomly selects a subset of its neighbors and shares the message with them. Each of these neighbors then repeats the process, further propagating the message throughout the network. This random dissemination strategy ensures that messages quickly reach a large number of peers in an efficient and decentralized manner, but does not ensure messages travel efficiently; that is, it does not route messages along the optimal path, nor does it do a particularly good job of avoiding redundant messages.

To solve this problem, each node in a Plumtree network maintains two separate lists of peers:

1. Full-peers relay messages to each other through epidemic broadcast
2. Metadata-only peers exchange periodically “gossip” messages with each other, which are used to optimize the set of full peers

The key insight that underpins Plumtree is that receiving a duplicate message indicates a sub-optimal path segment (a shorter path already exists, which delivered the its message sooner than the duplicate), and that missed messages indicate the presence of a more optimal path.  In response to duplicates, plumtree simply downgrades the sub-optimal full peer to a metadata-only peer.  Meanwhile, it periodically polls metadata peers to see if it has seen any messages that have yet to be received.  If so, the peer is upgraded to a full peer.  Over time, this causes the overlay to converge on a minimum spanning tree.

Figure 1.  Minimum spanning tree in an overlay of 18 connections.  Source:  https://en.wikipedia.org/wiki/Minimum_spanning_tree#/media/File:Minimum_spanning_tree.svg 

Other Features & Benefits of GossipSub

1. Sybil Resistance.  GossipSub v1.1 introduces a peer-scoring mechanism that rewards well-behaved nodes and publishes nodes that are unresponsive or that violate the protocol.  In essence, nodes with a higher peer score are given a higher priority for propagating messages, and peers with sufficiently poor scores can be blacklisted altogether.  The preferential treatment of high-scoring peers has the added benefit of favoring long-lived peer identities, as these will be consistently favored above newly-created nodes.  Thus, it is more difficult to flood a network with sybils (a.k.a. “sock puppets”).
2. Eclipse Resistance.  GossipSub provides two mechanisms to harden against eclipse attacks.  Firstly, node operators can define permanent peering agreements with trusted nodes.  These nodes will always be included in the set of full-peers, and will therefore always deliver and relay messages, effectively diffusing a class of attacks in which a node is saturated with malicious peers.  Relatedly, nodes can perform “flood publishing”.  During a normal publishing operation, a node sends its message to a handful of full-peers.  With flood publishing, the message is transmitted to all peers, rendering eclipse attacks more difficult.
   
   

GossipSub and the Beacon Network

All coordination and communication relating to Validator duties are done through a collection of GossipSub topics called the Beacon network. 

From this artist’s rendering of the beacon network below we can see that each node maintains an aggregate set of peers across all protocols (including GossipSub) in which it participates. GossipSub performs unicast message exchange with peers in this “peer store” in order to perform high-level topic joining/leaving operations. In the layers above the peer store, we see how peers are grouped into various topics (the colored nodes). Each topic carries messages relating to a specific duty.

There are six topics on the beacon network which all validators must be subscribed to in order to perform their duties:

1. beacon_block: This is the core data type that our validator and node set are coming to consensus upon.
2. beacon_aggregate_and_proof: Aggregate proofs are generated to reduce verification time and overlay traffic
3. voluntary_exit: Both joining and exiting the network are tracked through the deposit and withdrawal contracts on ethereum. Messages from validators stating their intent to exit the network are propagated over this topic.
4. proposer_slashing and attester_slashing: When a slashable offense or “equivocation” has been detected, anyone who has witnessed a commitment to two different world states, via signed header or attestation, combines the two commitments into one object and propagates them over these two topics to slash the “misbehaving” validator. The last user submitted slashing can be seen here.
5. beacon_attestation_{subnet_id} (Attestation Subnets): A specific subsets of validators that collaborate to generate attestations for shard chains. These attestation subnets enable the decentralized and efficient validation of shard blocks and contribute to the overall security and consensus of the Ethereum network.
6. sync_committee_{subnet_id} (Sync Subnets): A specialized subsets of validators that participate in the synchronization and consensus of the beacon chain. Validators participating in a sync subnet are responsible for maintaining a synchronized view of the beacon chain. They actively participate in the synchronization process by exchanging beacon chain information, such as block headers and attestations, with other validators in their respective sync subnet

Deep Dive

For a deeper technical discussion, check out our Hitchhiker’s Guide to P2P Overlays in Ethereum. Feel free to leave a comment directly in HackMD or reach out to our team on Discord if you have any questions or want to discuss these topics further.