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.