gossipsub: add SPREAD extension spec

[MatheusFranco99]

Summary

Acknowledgement: This work was supported by a grant from the SSV Network DAO awarded to the University of Lisbon.

This PR adds SPREAD (Secure Peer-to-Peer Relay for Efficient Anonymous Dissemination) as a GossipSub extension spec, under pubsub/gossipsub/spread/.

SPREAD extends GossipSub to raise the bar against sender deanonymization while, at the same time, improving dissemination efficiency in geo-distributed networks. It is motivated by the well-documented result that GossipSub leaks enough timing and structural information for a small set of passive listeners to map validators to their network identities, and by the fact that existing anonymity proposals (e.g. Dandelion++) have been considered infeasible for latency-sensitive settings such as Ethereum's consensus layer.

Design

SPREAD combines two mechanisms. First, an intra-cluster random walk (a cobra walk) restricted to a node's nearby peers provides sender anonymity without a large performance penalty. Second, a topology-aware inter-cluster dissemination provides efficient global reach, using virtual coordinates (Vivaldi, secured by Newton checks) to avoid redundant long-distance hops. Clusters are formed locally — each node treats the closest t% of its neighbors as its cluster — so the protocol stays fully decentralized.

Extension Choice

SPREAD is opt-in and backwards compatible. It is advertised through the existing GossipSub control/handshake fields and becomes active on a connection only when both peers support it. SPREAD messages carry a marker in the standard RPC envelope (no new message type); peers that do not support the extension ignore the marker and fall back to standard GossipSub. This enables mixed deployments and an incremental adoption path, with partial anonymity and performance gains possible before network-wide adoption.

Evaluation highlights

SPREAD is evaluated by running the real go-libp2p-pubsub implementation over the simnet packet simulator with real-world Internet latencies, against GossipSub and Dandelion++ configured for equal expected per-node bandwidth:

• Anonymity: substantially reduces first-timestamp deanonymization accuracy relative to GossipSub, sitting between GossipSub and Dandelion++ on the anonymity spectrum.
• Performance: roughly 23% lower mean stretch than GossipSub and 67% lower than Dandelion++, with an even larger reduction in the tail (99th percentile).

Reference implementation

A reference implementation is available as an opt-in extension in go-libp2p-pubsub: libp2p/go-libp2p-pubsub#717.

EthResearch post: https://ethresear.ch/t/spread-extending-gossipsub-with-efficient-anonymous-dissemination/25343

[seetadev]

Thank you, @MatheusFranco99, for this excellent contribution. SPREAD tackles one of the key challenges in peer-to-peer networking, improving resistance to sender deanonymization while maintaining the low latency and efficiency required by production systems.

The combination of intra-cluster cobra walks for anonymity and topology-aware inter-cluster dissemination is a thoughtful approach, and it is great to see it backed by both a detailed specification and a reference implementation. The opt-in, backwards-compatible design also makes incremental adoption practical, which is especially valuable for the libp2p ecosystem.

One question we would be interested in discussing is whether SPREAD can be viewed as two complementary improvements to GossipSub 1.1, 1.2 and 1.3: (1) topology-aware clustering for dissemination efficiency and (2) cobra walks for publisher anonymity. If so, how much of the dissemination improvement comes from the clustering mechanism alone, and what additional performance tradeoffs are incurred to achieve the stronger anonymity guarantees?

Understanding that separation would be particularly valuable for initiatives like Lean Ethereum, Ethereum Consensus clients, where both efficient propagation and stronger privacy are important.

This is indeed an exciting direction for GossipSub and a great example of research translating into practical networking improvements. Looking forward to the discussion and experimentation across the broader libp2p community.

CCing @dozyio, @tabcat, @acul71, @johannamoran, @sumanjeet0012 and @Winter-Soren on this thread.
We discussed on your spec proposal today with friends at py-libp2p. Will discuss at tomorrow's js-libp2p meeting with @dozyio and @tabcat.

[MatheusFranco99]

Hey @seetadev ! Thanks for your comment.

One question we would be interested in discussing is whether SPREAD can be viewed as two complementary improvements to GossipSub 1.1, 1.2 and 1.3: (1) topology-aware clustering for dissemination efficiency and (2) cobra walks for publisher anonymity. If so, how much of the dissemination improvement comes from the clustering mechanism alone, and what additional performance tradeoffs are incurred to achieve the stronger anonymity guarantees?

Good question about the numbers, would definitely be interesting to see.
But, yes, it absolutely could be two used as two different improvements. One way I like to frame it is that SPREAD can be anywhere in the region between GossipSub and Dandelion regarding anonymity, while keeping performance better than both. But, as you said, we can fully optimize efficiency, but at the cost of reducing anonymity.

About the numbers, I’m running now the experiments for it and will report here as soon as I have it :)

[MatheusFranco99]

Hey @seetadev, following up with some numbers:

• Optimizing exclusively for dissemination: our best configuration improves on every performance metric against GossipSub (numbers in the table below), while suffering on the anonymity side with 41% of attacker accuracy (for when attackers control 10% of the network) vs. 38% from GossipSub.

Metric	mean latency	p95 latency	p99 latency	mean stretch	p95 stretch	p99 stretch
Lowered by	24%	26%	30%	38%	58%	60%

• For the "same or better anonymity than GossipSub": a tunned configuration can produce lower attacker accuracy (30% vs. GossipSub's 38%) while still improving considerably all performance metrics.

Metric	mean latency	p95 latency	p99 latency	mean stretch	p95 stretch	p99 stretch
Lowered by	22%	24%	25%	32%	51%	49%

• Dandelion-level anonymity: we can also configure SPREAD to match Dandelion's anonymity, beating it slightly on performance, though being considerably worse against the performance-optimized case. The pareto curve:

Configuration	Acc@10%	Mean Latency	Mean stretch
Best performance found, but worse than GossipSub on anonymity	41%	98 ms	1.54
Still high-performance, while beating GossipSub anonymity	30%	101 ms	1.69
Mid-point	28%	104 ms	1.74
Close to Dandelion	20%	143 ms	2.87
Dandelion-level anonymity, but worst performance	11%	207 ms	4.76

I ran these simulations overnight, but I plan to run these for a few more days to try to find even better configurations and increase the sample size.

[seetadev]

Hey @seetadev, following up with some numbers:

Thanks a lot, @MatheusFranco99. This is very much valuable, and I appreciate how quickly you followed up with concrete numbers. This is fantastic.

The results are quite encouraging. What stood out to me most is that the "same or better anonymity than GossipSub" configuration still improves latency and stretch across the board while reducing attacker accuracy. That is a very compelling point on the tradeoff curve and suggests there may be practical deployment configurations that provide meaningful privacy improvements without sacrificing network performance.

We will definitely experiment with SPREAD in py-libp2p and js-libp2p. It will be interesting to compare behavior across implementations and see how the results translate beyond the current reference implementation.

A few questions came to mind while reading the latest results:

• Wish to ask if you have noticed any "sweet spot" where relatively small parameter changes produce large gains in anonymity with only minimal impact on latency?
• How stable are these results under higher churn? We are curious whether the topology-aware clustering remains effective as peers join and leave more frequently.
• Do we expect the dissemination improvements to come primarily from the clustering mechanism itself, or is there a meaningful interaction between clustering and the cobra walks that contributes to the overall performance?
• Longer term, do we envision SPREAD exposing a few recommended operating profiles (for example, performance-focused, balanced, and privacy-focused), or do we see applications tuning these parameters directly based on their requirements?

Impressive work overall. It is great to see a proposal that combines a thoughtful design, a reference implementation, and quantitative evaluation. Looking forward to seeing the larger experimental dataset, and we are excited to continue the discussion as we begin experimenting with it in the other libp2p implementations too.

CCing @johannamoran, @Winter-Soren and @sumanjeet0012.

[gmelodie]

There's some nitpicking, so feel free to ignore where you see fit, but I found a lot of the wording to be excessively long and convoluted. Treid to make it more to the point.

Also, consider using the following structure instead:

1. Overview
2. Motivation
3. Terms and definitions
4. Design rationale
5. Protocol specification (incl. extension negotiation, coordinate maintenance)
6. Security considerations
7. Evaluation

[gmelodie]

Suggested change

GossipSub is the key communication infrastructure underlying societal-critical protocols in ecosystems such as Ethereum. Several characteristics of gossip protocols make this an interesting communication substrate, namely robustness, scalability, and simplicity. However, the important property of anonymity (hiding the true source of a message), is one that is sometimes cited as being desirable to avoid targeted attacks against the sender, but is in practice well-known that it cannot be attained by GossipSub.

[gmelodie]

Suggested change

	In this proposal we describe a protocol extension to GossipSub named SPREAD (Secure Peer-to-Peer Relay for Efficient Anonymous Dissemination), which aims for the best of both worlds: raising the bar against sender deanonymization while, at the same time, improving the efficiency of dissemination in geodistributed settings (i.e., the ability to reach nodes across the globe with low latency). Note that our goal is to raise the bar rather than to fully prevent deanonymization, since source indistinguishability is a quantitative property that depends on the adversary's observation power, rather than an absolute guarantee. These two properties are particularly important for the use of gossip protocols in systems like Ethereum, where targeted attacks can prevent nodes from meeting a certain deadline, such as fulfilling a duty in a given slot, and also where efficient, low-latency transmission is important for the protocols that layer on top of gossip as a communication substrate.
	SPREAD consists of two components: a local random walk to preserve anonymity, and a geographically directed propagation for efficient global dissemination, which gives preference to using nearby nodes as a stepping stone, to avoid costly long-distance hops. We are implementing SPREAD as a protocol extension on top of the go-libp2p-pubsub infrastructure. This document presents this proposal, detailing SPREAD's motivation, rationale, and protocol design.
	This document specifies SPREAD (Secure Peer-to-Peer Relay for Efficient Anonymous Dissemination), an extension to the GossipSub protocol. SPREAD raises the cost of sender deanonymization while improving dissemination efficiency in geo-distributed deployments. Both properties are relevant to systems such as Ethereum, where targeted attacks may prevent a node from meeting time-bound duties (e.g., fulfilling a duty within its assigned slot), and where low-latency delivery is required by protocols layered on top of the gossip substrate. SPREAD does not provide an absolute guarantee of source indistinguishability: sender anonymity is a quantitative property dependent on the adversary's observation capabilities, and the goal is therefore to raise the bar against deanonymization rather than to prevent it entirely.
	SPREAD consists of two mechanisms:
	1. a local random walk, which obscures the message origin prior to broad propagation; and
	2. geographically directed propagation, which prefers nearby peers as relay hops in order to avoid costly long-distance transmissions during global dissemination.
	SPREAD is implemented as a protocol extension on top of the go-libp2p-pubsub library. The remainder of this document details SPREAD's motivation, rationale, and protocol design.

[gmelodie]

Suggested change

	Gossip Protocol - A distributed communication protocol in which nodes repeatedly forward information to a subset of neighboring peers, leading to probabilistic but eventually broadcast of a given message.
	Gossip Protocol - A distributed communication protocol in which nodes repeatedly forward information to a subset of neighboring peers, resulting in probabilistic, eventual delivery to all nodes.

[gmelodie]

the propabilistic branching is already explained in "Cobra Walk"

Suggested change

	Random Walk - A forwarding strategy in which each node forwards a message to a single randomly selected peer (possibly with probabilistic branching).
	Random Walk - A forwarding strategy in which each node forwards a message to a single randomly selected peer.

[gmelodie]

Suggested change

	Bernoulli Trial - A probabilistic decision mechanism with two outcomes (success/failure), parameterized by the respective probability value.
	Bernoulli Trial - A random experiment with exactly two outcomes (success/failure), where success occurs with a fixed probability `p`.

[gmelodie]

Suggested change

To navigate this tradeoff effectively, we leverage the insight that the geographic distribution of nodes tends to naturally form clusters corresponding to the world’s most densely populated and economically developed regions (e.g., US East and West Coasts, Europe, Asia, etc.) This allows the design of SPREAD to organize nodes into clusters with the characteristic that the network latency between nodes in the same cluster is low, thus allowing for fast multi-hop dissemination inside a cluster. With this design decision in place, we can then leverage the intra-cluster communication to conduct random walks that allow for building privacy without a significant performance penalty, while occasionally turning to inter-cluster communication for global dissemination.

SPREAD navigates this tradeoff by exploiting the fact that nodes naturally cluster in some regions (e.g., the US coasts, Europe, Asia). Since latency within such a cluster is low, random walks can be confined to it, providing anonymity at little performance cost, while occasional inter-cluster hops handle global dissemination.

[gmelodie]

Suggested change

A second challenge is that the inter-cluster message steps can also be very penalizing for the end-to-end performance if not managed carefully. For instance, we would like to avoid having to send a message from Europe to the East Coast of the US via an overlay hop through Asia or the Middle East. To avoid this, we need to devise an efficient wide area dissemination, since this step is so crucial for performance, and our protocols already achieve anonymity through the intra-cluster communication. To this end, SPREAD attempts that inter-cluster message hops are conducted with nodes in adjacent clusters, so that they can be used as a stepping stone to reach more distant ones. In an idealized routing scenario, there is a single global view of the clusters and how they connect to each other through a high level overlay, which corresponds to a Dirichlet tessellation, dividing the space into regions according to the set of centroids of the clusters. This allows the idealized routing to only send inter-cluster messages to overlay peers in neighboring clusters according to the Dirichlet tessellation.

Inter-cluster hops pose a second challenge: chosen carelessly, they are just as penalizing, e.g., routing a message from Europe to the US East Coast via an overlay hop through Asia. Since anonymity is already provided by the intra-cluster walks, wide-area dissemination can be optimized purely for efficiency. SPREAD therefore directs inter-cluster hops toward adjacent clusters, using them as stepping stones to reach more distant ones. Ideally, with a global view, each cluster would be represented by its center, the space would be divided into regions according to which center is closest (a Voronoi diagram, as shown in Figure 1), and messages would cross cluster boundaries only between neighboring regions.

[gmelodie]

Suggested change

	## Overview / Summary
	## Overview

[gmelodie]

Suggested change

The protocol has two components that run in parallel: an algorithm for maintaining a set of overlay peers (or neighbors) and their respective secure virtual coordinates, and the main protocol for sending and propagating gossip messages. The overlay neighbors of node i are automatically partitioned into three subsets: cluster_i, occluded_remote_i, and unobstructed_remote_i, according to the criteria described before.

SPREAD comprises two components running in parallel: a maintenance algorithm that manages a node's overlay peers (neighbors) and their secure virtual coordinates, and the dissemination protocol that publishes and propagates gossip messages. Using the criteria described above, the maintenance algorithm partitions the neighbors of node i into three subsets: cluster_i, occluded_remote_i, and unobstructed_remote_i.

[gmelodie]

Suggested change

With this overlay state in place, we can now define the protocol for broadcasting messages in a simple manner, based on the intuition of combining intra-cluster random walks for ensuring anonymity with inter-cluster efficient dissemination through the unobstructed remote neighbors. The decision to incur in each of these two alternatives is made upon receiving a message to be propagated, simply by flipping a coin that is biased according to a system parameter. The pseudocode of the protocol is explained next, focusing on how to broadcast a message once the cluster information and overlay neighbor formation is in place.

Given this overlay state, the dissemination protocol combines intra-cluster random walks, which provide anonymity, with inter-cluster forwarding through unobstructed remote neighbors, which provides efficient global dissemination. Upon receiving or publishing a message, a node decides between these two behaviors by biased coin flips, with biases set by system parameters. The pseudocode below specifies how a message is broadcast once the overlay state is established.

[richard-ramos]

The usage of this extension would require StrictNoSign, right? Should this be mentioned?

[richard-ramos]

If this is meant to be included as an extension to gossipsub , this PR should extend the protobuffer defined in https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/extensions/extensions.proto similar to how it was done with the partial messages extension.

[richard-ramos]

If it's not meant to use extensions, the additional field the protobuffer field used for SPREAD messages should be defined. (otherwise at the moment the spec is not clear enough on how should this field be added to the message)

However i think it makes sense to use a new gossipsub extension (with the message type specific for the extension) instead of a new field due to semantics (as well as the advantage of extension negotiation being a mechanism that already exists in implementations), I'd structure roughly like this

message ControlExtensions {
  optional bool spread = 123456; // number to be defined
}

message RPC {
  repeated Message publish = 2;
  optional SpreadExtension spread = 123456; // number to be defined
}

message SpreadExtension {
  repeated uint32 publish_indices = 1;
}

with publish_indices identifying to which entries in RPC.publish does SPREAD apply.