PREAMBLE and IMRECEIVING for Improved Large Message Handling in libp2p GossipSub

Daniel Kaiser; Muhammad Umar Farooq

REVIEW 4 major objections 6 minor 29 references

PREAMBLE and IMRECEIVING for Improved Large Message Handling in libp2p GossipSub

T0 review · 4 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read PREAMBLE and IMRECEIVING cut GossipSub bandwidth by up to 61%.

desk verdict Genuinely new protocol extension for large-message GossipSub; the simulation evidence is promising but needs error bars and a sensitivity analysis before the headline numbers are trusted. read the letter →

arxiv 2505.17337 v1 pith:RDX2X3Z5 submitted 2025-05-22 cs.NI

Muhammad Umar Farooq , Daniel Kaiser This is my paper · ORCID

classification cs.NI

keywords GossipSublibp2ppublish-subscribelargemessagedisseminationduplicatesuppressionbandwidthutilizationIMRECEIVINGPREAMBLE

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper identifies a timing blind spot in GossipSub: peers only learn that a message is in flight after the full payload arrives, so large-message transfers invite duplicate sends and redundant IWANT requests. It proposes two small protocol additions, a PREAMBLE sent before each large message and an IMRECEIVING message that tells mesh members an incoming message is already being received, so duplicate suppression can happen at the start of a transfer instead of at the end. The reported evaluations show up to 61% lower bandwidth utilization and up to 35% lower network-wide dissemination time under different traffic conditions. The changes matter because large messages, from hundreds of kilobytes to megabytes, are common in decentralized applications, and the existing IDONTWANT mechanism acts too late to stop redundant transfers.

What carries the argument

The engine of the proposal is the PREAMBLE: a short control message bearing a message ID and a length, sent immediately before a large data message and processed as soon as it arrives. Because the receiving peer learns the message's identity at the start of the transfer rather than at the end of the download, it can emit IMRECEIVING notifications to its mesh members almost immediately, cancelling duplicate transmissions that would otherwise begin during the long transfer. The same early knowledge suppresses unnecessary IWANT requests, since a peer no longer asks for a message it can see is already arriving.

What would settle it

Deliberately add a controllable queueing delay to PREAMBLE and IMRECEIVING at the transport layer while keeping payload conditions fixed, then measure bandwidth and dissemination time for 1MB messages. The stated mechanism predicts that the gains shrink as that control-message delay approaches the full message transfer time; if the bandwidth reduction remains at 61% even when those messages wait behind other traffic, the paper's explanation would need revision.

Watch

Extended reading notes

Core claim

GossipSub's forwarding logic treats all messages as if they arrive instantly, but for large messages the transfer time is long enough that peers start receiving the same message from several senders simultaneously and issue many duplicate IWANT requests. The paper's central discovery is that the fix is temporal: tell receivers what is coming before it arrives. PREAMBLE is a tiny control message carrying the message ID and length, sent immediately before a large message; the receiver then instantly tells its mesh members via IMRECEIVING that it is already receiving the message and they should not resend it. This shifts duplicate suppression from the end of a transfer, where IDONTWANT acts, to the start, while the PREAMBLE also lets peers stop firing IWANT requests for messages already in flight. In simulation, the combined GossipSub v1.4 protocol reduces bandwidth utilization by up to 45% for 400KB messages, up to 61% for messages larger than 1MB, and dissemination latency by up to 35% in high-publisher scenarios.

Load-bearing premise

The load-bearing premise is that the new control messages are processed instantly on arrival, so a peer learns about an incoming large message almost immediately instead of only after the whole payload has been downloaded.

Editorial extensions

If this is right

For messages above 1MB, the combined protocol reduces bandwidth utilization by up to 61% and brings average duplicates per peer down to about two.
For 400KB messages, the combined protocol reduces bandwidth by up to 45%, and for large messages in the evaluated scenarios it also reduces dissemination latency by up to 23%.
In high-publisher settings, the combined protocol cuts network-wide message dissemination latency by up to 35% by lowering the workload on peers along optimal forwarding paths.
The reduced-forwarding variant, which sends to a subset of mesh members and issues immediate IHAVE announcements to the rest, saves about 15-20% bandwidth but can increase latency, so the paper positions it as weaker than the full PREAMBLE plus IMRECEIVING design.
The proposed changes take effect only above a size threshold, so small-message behavior remains unchanged and normal GossipSub operation is preserved.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

We infer that the protocol's real-world impact hinges on control-plane timeliness: the measured gains should become more robust if PREAMBLE and IMRECEIVING are given explicit priority over payload traffic at the transport layer.
The announce-before-transfer pattern could be applied to other pubsub or gossip protocols where payload transfer time is non-negligible, not just libp2p GossipSub.
Because the evaluation uses IDONTWANT as the PREAMBLE, we infer that a dedicated PREAMBLE type could decouple the sender's commitment semantics from IDONTWANT and make the design easier to reason about.
Since the assessments assume a trusted environment, an immediate next test is whether an attacker sending PREAMBLEs without delivering the promised payload can disrupt propagation despite the proposed peer-scoring penalty.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Colleague, this paper is worth your time if you have any stake in libp2p or large-message pubsub. The core idea is simple and sound: before sending a large message, announce it with a PREAMBLE so receivers can immediately send IMRECEIVING notices to their mesh members to cancel duplicates. That directly attacks the well-known problem that IDONTWANT arrives too late because it's only sent after full download. The IMRECEIVING construct is new, as is using PREAMBLE to suppress IWANT requests. The authors also propose reduced forwarding with immediate IHAVEs, which is more derivative but reasonable.

Credit where due: they implemented this in nim-libp2p, have a PoC branch, and a spec PR under review. The evaluation in shadow covers three dimensions (message size, publisher count, network size) and reports bandwidth, latency, and duplicate counts. The reported gains—up to 45% bandwidth for 400KB, 61% above 1MB, and 35% latency at high publisher counts—are consistent with the mechanism.

The soft spots are real but not fatal. First, the evaluation is statistically bare: point estimates with no error bars, run counts, or seeds. For a simulation paper this is a serious omission and undermines the headline numbers. Second, the resilience claim is asserted, not tested; the paper admits a trusted environment. Third, the reduced-forwarding degree K is hand-picked in the same simulations that report its benefit, so that part is mildly circular.

On the stress-test concern: the gains do rely on PREAMBLE/IMRECEIVING arriving before duplicate transfers commit. The paper models a processing delay Δ and asserts Δ ≪ τ_D, but never measures the ratio. Section V honestly notes that transport-layer queues could delay these control messages, and the simulations run without prioritization. My read is that the reported numbers already reflect that lack of prioritization, so the mechanism survived in the tested scenarios; but without a sensitivity sweep over Δ/τ_D, we don't know how close to the edge the benefit sits. That's an empirical hole, not a conceptual one.

Who is the reader? Protocol designers and anyone deploying GossipSub for large payloads. It deserves a serious referee, but the referee should demand error bars and a sensitivity analysis before the numbers are trusted. I'd send it to review.

Referee Report

4 major / 6 minor

Summary. The paper addresses large-message performance in libp2p GossipSub. It identifies duplicate transmissions and IWANT-related overhead caused by long transfer times, and proposes: a PREAMBLE control message to identify incoming large messages, an IMRECEIVING notification sent at reception start, IWANT request reductions, and reduced forwarding to K mesh members with immediate IHAVE announcements. Using the shadow simulator with nim-libp2p, it compares GossipSub v1.2 against IMRECEIVING, IWANT improvements, the combined GossipSub v1.4, and reduced sending. It reports up to 61% bandwidth reduction and up to 35% latency reduction, with duplicate and bandwidth results across three scenarios.

Significance. The proposed mechanisms are simple, fit within GossipSub's existing message flow, and address a real operational problem; the performance gains are large and, if confirmed, would be practically valuable. The paper's strengths include a clear parameterized description of the protocol changes, a public PoC implementation link, and multi-scenario simulation covering varying message sizes, publisher counts, and network sizes. However, the quantitative claims rest on timing assumptions and point estimates that are not validated with error bars, confidence intervals, or sensitivity analysis; the manuscript itself acknowledges the transport-prioritization caveat. The contribution is promising, but the evidence presented is not yet sufficient for the stated headline claims.

major comments (4)

[Section III-B, Section V] The duplicate-cancellation mechanism requires PREAMBLE processing time Δ to satisfy Δ ≪ τD, but the paper never reports a measured distribution of Δ/τD or a sensitivity analysis over this ratio. Since the evaluation runs without transport-layer prioritization, and Section V concedes that the lack of prioritization mechanisms can delay the transmission of control messages, a PREAMBLE or IMRECEIVING message queued behind large-message data on a congested yamux connection could close the cancellation window before the duplicate transfer is prevented. Please add direct measurements of control-message delivery delay relative to τD and a sensitivity analysis with artificially delayed or prioritized control traffic; without this, the headline 61% bandwidth and 35% latency reductions remain conditional on an unverified queuing assumption.
[Section IV, Figs. 3-4] All performance results are reported as single point estimates with no error bars, confidence intervals, run counts, or random seeds. The 'up to' maxima are not supported by a distribution, so the reader cannot assess the variability or statistical reliability of the claimed improvements. Please report multiple independent simulation runs with specified seeds, show variability (e.g., boxplots or confidence intervals), and state the number of replications in Table I or the text.
[Section III-A, Section IV] The paper proposes PREAMBLE as a new control message transmitted immediately before every large message, but the evaluation 'uses IDONTWANT messages as PREAMBLEs' with modified semantics. The measured gains therefore test a modified IDONTWANT, not the dedicated PREAMBLE with the property of being sent immediately before the payload. The timing of IDONTWANT delivery relative to the data transfer may differ from a true PREAMBLE, so the mechanism's claimed benefit is not directly validated. Please evaluate the protocol as specified, or explicitly state that the implementation uses a proxy and analyze how the proxy affects the measured gains.
[Section III-D, Section V, Table II] The abstract and Section III claim that the proposed modifications preserve GossipSub resilience, but no resilience evaluation is presented. All experiments use a trusted environment, as Section V states, and the reduced-forwarding parameter K = Dlow − 1 is hand-picked on the basis of 'extensive simulations' without sensitivity analysis or adversarial/partition scenarios. The qualitative argument that immediate IHAVE announcements preserve redundancy is plausible but not empirically verified. Please add tests with non-conforming peers, churn, or network partitions, or at minimum a sensitivity analysis over K, and state explicitly what resilience properties are and are not covered by the evaluation.

minor comments (6)

[Section IV, first paragraph] There is a typo: 'GossipSup v1.2' should read 'GossipSub v1.2'.
[Reference [24]] Reference [24] contains garbled text: 'Omtermet Emgomeeromg Task Force' should be 'Internet Engineering Task Force'.
[Section II, Table I] The paper defines large messages as exceeding 50 KB, but Scenario 2 in Table I uses message size 50 KB exactly; please clarify whether 50 KB is considered large and why the proposed changes, which activate only above a threshold, are evaluated at this boundary size.
[Section III-D, Table II] The notation 'Reduced Send (K)' is listed in Table II as Dlow − 1, but the meaning of K and its role in forwarding are not explained until Section III-D; please add a forward reference from Table II to that discussion.
[Throughout] The spelling 'IWANT' versus 'IW ANT' is inconsistent throughout the text and figures; please choose one form and use it consistently.
[Figures 2-4] The figure labels and legends are shown at a very small size and are difficult to read in the PDF; please enlarge fonts or provide vector versions, and ensure protocol versions are clearly identified in every legend.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the reported gains are measured in a simulator against a baseline, and the hand-set forwarding parameter is not presented as a prediction.

full rationale

No circular step is present in the paper's derivation chain. The headline reductions (up to 61% bandwidth, 35% latency) are produced by a Shadow-simulator comparison of the proposed GossipSub v1.4 protocol against GossipSub v1.2, and the mechanisms (PREAMBLE, IMRECEIVING, IWANT improvements) are implemented and evaluated rather than derived from their own assumptions. The only hand-tuned parameter, K = Dlow - 1 for the reduced-forwarding variant, is explicitly chosen via 'Extensive simulations reveal that setting K = Dlow - 1 yields good performance'; it is not called a prediction, and the main v1.4 gains are separate from this tuning. The self-citation to the authors' prior work [19] supports background on fragmentation and staggering, but it is not load-bearing for the new protocol's measured results. The paper's acknowledged unquantified timing assumption (Delta << tau_D, and the lack of transport-layer prioritization) is a correctness or sensitivity risk, not circularity: the gains are not claimed to follow from that inequality by construction. The evaluation is self-contained against an external baseline and does not reduce to its inputs.

Assumptions & free parameters 2 free parameters · 5 assumptions · 2 invented entities

The central claim rests on the protocol design (PREAMBLE, IMRECEIVING, IWANT caps, reduced forwarding), which is evaluated in the shadow simulator. The only hand-fitted parameter is K = Dlow - 1. The main postulates are the protocol semantics and the ability to process control messages with negligible delay.

free parameters (2)

Reduced forwarding degree K = 5 (Dlow - 1)
Chosen by simulation tuning; Section III-D states 'Extensive simulations reveal that setting K = Dlow - 1 yields good performance.' The reported gains for reduced sending depend on this hand-picked value.
Large message threshold = 50 KB
The paper defines 'large messages' as exceeding 50 KB (Section I). All proposed mechanisms activate only above this threshold, so the threshold shapes which traffic sees the gains.

assumptions (5)

domain assumption GossipSub v1.1/v1.2 protocol semantics (optional IWANT replies, peer scoring, IDONTWANT) are correct as cited.
The proposed changes build directly on these protocol behaviors; if the cited specs are misrepresented, the problem analysis and the proposed extensions would be misguided.
domain assumption The simplified per-hop delay model tau_D ≈ D * S / R + tau_p and the cumulative model tau_N ≈ tau_D * h hold for the analyzed regime.
Used in Section II to motivate the problem and in Section III-A to estimate transfer times; the actual evaluation is simulation-based, but this model drives the qualitative claims about duplicate growth.
ad hoc to paper IDONTWANT can serve as PREAMBLE if its semantics are modified to commit to immediate transfer.
Section III-A states this explicitly. The performance evaluations use IDONTWANT-as-PREAMBLE, so the results rely on a protocol modification, not on the standard v1.2 behavior.
ad hoc to paper A receiving peer can immediately process a PREAMBLE without waiting for the full payload.
Section III-A requires that the multiplexer forward PREAMBLEs to the upper layer while the payload is still arriving. This is an implementation assumption that is not demonstrated in a real stack in the paper.
domain assumption Performance evaluation assumes a trusted environment.
Section V states 'The performance evaluations in this work assume a trusted environment.' The resilience claims are therefore not empirically supported under adversarial conditions.

invented entities (2)

PREAMBLE control message
purpose: A short message sent before a large data message, carrying msgID and length, so receivers can identify incoming messages immediately and maintain an 'ongoing receives' list.
Only evaluated within the authors' shadow simulations (and partially emulated by IDONTWANT). No independent implementation or independent measurement outside this paper is provided.
IMRECEIVING control message
purpose: Sent by a peer upon receiving a PREAMBLE to notify mesh members that the message is being received, asking them to refrain from resending it.
A new message type; evidence of its effectiveness comes only from the authors' simulations (GossipSub v1.4 PoC). No independent deployment or external reproduction is cited.

how reviews work

0 comments

Cite this review

Pith. "Pith review of PREAMBLE and IMRECEIVING for Improved Large Message Handling in libp2p GossipSub." pith.science (2026). https://pith.science/paper/RDX2X3Z5

@misc{pith2026250517337,
  author       = {Pith},
  title        = {Pith review of: PREAMBLE and IMRECEIVING for Improved Large Message Handling in libp2p GossipSub},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RDX2X3Z5}},
  note         = {Machine review of arXiv:2505.17337}
}

read the original abstract

Large message transmissions in libp2p GossipSub lead to longer than expected network-wide message dissemination times and very high bandwidth utilization. This article identifies key issues responsible for this behavior and proposes modifications to the protocol for transmitting large messages. These modifications preserve the GossipSub resilience and fit well into the current algorithm. The proposed changes are rigorously evaluated for performance using the shadow simulator. Results reveal that the suggested changes reduce bandwidth utilization by up to 61% and message dissemination time by up to 35% under different traffic conditions.

Figures

Figures reproduced from arXiv: 2505.17337 by the authors.

**Figure 2.** Average number of duplicates (d¯): impact of IDONTWANT and IWANT-reply messages We begin by discussing average duplicates ( ¯d). A network comprising N peers, each with a degree D, has a total of N×D 2 edges (links), as every link connects two peers. Assuming that a message traverses every link exactly once, networkwide dissemination requires at least N×D 2 transmissions. Only N − 1 transmissions are necessary for … view at source ↗

**Figure 3.** Performance against increasing message size: latency ( [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗

Figures from the paper (1 more)

**Figure 4.** Figure 4: Increasing number of publishers (a,c,e) and increasing number of nodes (b,d,f): latency ( [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

29 extracted references · 27 canonical work pages

[1]

M.-J. Lin, K. Marzullo, and S. Masini, Gossip versus deterministic flooding: Low message overhead and high reliability for broadcasting on small networks. Department of Computer Science and Engineering, University of California, 1999

work page 1999
[2]

Efficient flooding in peer-to-peer networks,

W. Ai, L. Xinsong, and L. Kejian, “Efficient flooding in peer-to-peer networks,” in 2006 7th International Conference on Computer-Aided Industrial Design and Conceptual Design . IEEE, 2006, pp. 1–6

work page 2006
[3]

A study on the redundancy of flooding in unstructured p2p networks,

S. V . Margariti and V . V . Dimakopoulos, “A study on the redundancy of flooding in unstructured p2p networks,” International Journal of Parallel, Emergent and Distributed Systems , vol. 28, no. 3, pp. 214– 229, 2013

work page 2013
[4]

Rng-based search- ing and broadcasting algorithms over internet graphs and peer-to-peer computing systems,

O. Escalante, T. P ´erez, J. Solano, and I. Stojmenovic, “Rng-based search- ing and broadcasting algorithms over internet graphs and peer-to-peer computing systems,” in The 3rd ACS/IEEE International Conference onComputer Systems and Applications, 2005. IEEE, 2005, p. 17

work page 2005
[5]

Probabilistic edge multicast routing for the xrp network,

V . Tumas, S. Rivera, D. Magoni, and R. State, “Probabilistic edge multicast routing for the xrp network,” in GLOBECOM 2022-2022 IEEE Global Communications Conference . IEEE, 2022, pp. 5129–5134

work page 2022
[6]

Scaling unstructured peer-to- peer networks with multi-tier capacity-aware overlay topologies,

M. Srivatsa, B. Gedik, and L. Liu, “Scaling unstructured peer-to- peer networks with multi-tier capacity-aware overlay topologies,” in Proceedings. Tenth International Conference on Parallel and Distributed Systems, 2004. ICPADS 2004. IEEE, 2004, pp. 17–24

work page 2004
[7]

Two-layer hybrid peer-to-peer networks,

Z. Duan, C. Tian, M. Zhou, X. Wang, N. Zhang, H. Du, and L. Wang, “Two-layer hybrid peer-to-peer networks,” Peer-to-Peer Networking and Applications, vol. 10, pp. 1304–1322, 2017

work page 2017
[8]

A geography-based p2p overlay network for fast and robust blockchain systems,

H. Qiu, T. Ji, S. Zhao, X. Chen, J. Qi, H. Cui, and S. Wang, “A geography-based p2p overlay network for fast and robust blockchain systems,” IEEE Transactions on Services Computing , 2022

work page 2022

Show all 29 references

[9]

The many faces of publish/subscribe,

P. T. Eugster, P. A. Felber, R. Guerraoui, and A.-M. Kermarrec, “The many faces of publish/subscribe,” ACM computing surveys (CSUR) , vol. 35, no. 2, pp. 114–131, 2003

2003
[10]

Take a look at pubsub on ipfs,

IPFS, “Take a look at pubsub on ipfs,” https://blog.ipfs.tech/25-pubsub/, 2017, accessed: 2025-01-28

2017
[11]

Pubsub interface for libp2p,

J. Johnson, D. Loerakker, raulk, and D. Vyzovitis, “Pubsub interface for libp2p,” https://github.com/libp2p/specs/blob/master/pubsub/README. md, 2020, accessed: 2025-01-28

2020
[12]

libp2p-floodsub,

J. Benet, “libp2p-floodsub,” https://github.com/libp2p/pubsub-notes/ blob/master/flooding/spec.md, 2016, accessed: 2025-01-28

2016
[13]

Episub: Proximity aware epidemic pubsub for libp2p,

vyzo, “Episub: Proximity aware epidemic pubsub for libp2p,” https: //github.com/libp2p/specs/blob/master/pubsub/gossipsub/episub.md, 2018, accessed: 2025-04-28

2018
[14]

Gossipsub: Attack-resilient message propagation in the filecoin and eth2. 0 networks,

D. Vyzovitis, Y . Napora, D. McCormick, D. Dias, and Y . Psaras, “Gossipsub: Attack-resilient message propagation in the filecoin and eth2. 0 networks,” arXiv preprint arXiv:2007.02754 , 2020

2007 arXiv
[15]

gossipsub v1.0: An extensible baseline pubsub protocol,

vyzo and n. yusef, “gossipsub v1.0: An extensible baseline pubsub protocol,” https://github.com/libp2p/specs/blob/master/pubsub/ gossipsub/gossipsub-v1.0.md, 2020, accessed: 2025-01-28

2020
[16]

gossipsub v1.1: Security extensions to improve on attack re- silience and bootstrapping,

vyzo, “gossipsub v1.1: Security extensions to improve on attack re- silience and bootstrapping,” https://github.com/libp2p/specs/blob/master/ pubsub/gossipsub/gossipsub-v1.1.md, 2021, accessed: 2025-01-28

2021
[17]

FullDAS: towards massive scalability with 32MB blocks and beyond,

C. Kiraly, “FullDAS: towards massive scalability with 32MB blocks and beyond,” 2024, accessed: 2025-04-28. [Online]. Available: https://ethresear.ch/t/ fulldas-towards-massive-scalability-with-32mb-blocks-and-beyond/ 19529

2024
[18]

gossipsub v1.2 minimal extension to the gossipsub v1.1 protocol,

A. Nashatyrev and T. Cizian, “gossipsub v1.2 minimal extension to the gossipsub v1.1 protocol,” https://github.com/libp2p/specs/blob/master/ pubsub/gossipsub/gossipsub-v1.2.md, 2023, accessed: 2025-01-28

2023
[19]

Staggering and fragmenta- tion for improved large message handling in libp2p gossipsub,

M. U. Farooq, T. Cizain, and D. Kaiser, “Staggering and fragmenta- tion for improved large message handling in libp2p gossipsub,” arXiv preprint arXiv:2504.10365, 2025

2025 arXiv
[20]

Number duplicate messages in ethereum’s gossipsub network,

Y . Psaras, “Number duplicate messages in ethereum’s gossipsub network,” https://ethresear.ch/t/ number-duplicate-messages-in-ethereums-gossipsub-network/19921, 2024, accessed: 2025-01-28

2024
[21]

Pppt: Fighting the gossipsub overhead with push-pull phase transition,

C. Kiraly, “Pppt: Fighting the gossipsub overhead with push-pull phase transition,” https://ethresear.ch/t/ pppt-fighting-the-gossipsub-overhead-with-push-pull-phase-transition/ 22118, 2025

2025
[22]

Gossipsub v1.3: Topic observation (PR 617),

P. Chunhapanya, “Gossipsub v1.3: Topic observation (PR 617),” https: //github.com/libp2p/specs/pull/617, 2024, accessed: 2025-01-28

2024
[23]

Gossipsub v2.0: Lower or zero duplicates by lazy mesh propagation (PR 653),

P. Chunhapanya, N. Das, and C. Parmar, “Gossipsub v2.0: Lower or zero duplicates by lazy mesh propagation (PR 653),” https://github.com/ libp2p/specs/pull/653, 2024, accessed: 2025-01-28

2024
[24]

Rfc 9000: Quic: A udp-based multiplexed and secure transport,

J. Iyengar and M. Thomson, “Rfc 9000: Quic: A udp-based multiplexed and secure transport,” Omtermet Emgomeeromg Task Force, 2021

2021
[25]

The nim implementation of the libp2p networking stack,

IFT V AC, “The nim implementation of the libp2p networking stack,” https://github.com/vacp2p/nim-libp2p, 2025

2025
[26]

GossipSub v1.4: PoC implementation,

M. U. Farooq, “GossipSub v1.4: PoC implementation,” https://github. com/vacp2p/nim-libp2p/tree/research gsub v1.4 PoC, 2025, accessed: 2025-05-23

2025
[27]

GossipSub v1.4: Message PREAMBLE + IMRECEIVING notification to considerably reduce bandwidth & latency for large messages,

M. U. Farooq and D. Kaiser, “GossipSub v1.4: Message PREAMBLE + IMRECEIVING notification to considerably reduce bandwidth & latency for large messages,” https://github.com/libp2p/specs/pull/654, 2024, accessed: 2025-04-28

2024
[28]

The shadow simulator,

J. Rob and N. Jim, “The shadow simulator,” https://github.com/shadow/ shadow, 2023, accessed: 2025-01-28

2023
[29]

The streamr network: Performance and scala- bility,

P. Savolainen, S. Juslenius, E. Andrews, M. Pokrovskii, S. Tarkoma, and H. Pihkala, “The streamr network: Performance and scala- bility,” url: https://streamrpublic.s3.amazonaws.com/streamr-network- scalability-whitepaper-2020-08-20.pdf, 2020

2020

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

M.-J. Lin, K. Marzullo, and S. Masini, Gossip versus deterministic flooding: Low message overhead and high reliability for broadcasting on small networks. Department of Computer Science and Engineering, University of California, 1999

work page 1999

[2] [2]

Efficient flooding in peer-to-peer networks,

W. Ai, L. Xinsong, and L. Kejian, “Efficient flooding in peer-to-peer networks,” in 2006 7th International Conference on Computer-Aided Industrial Design and Conceptual Design . IEEE, 2006, pp. 1–6

work page 2006

[3] [3]

A study on the redundancy of flooding in unstructured p2p networks,

S. V . Margariti and V . V . Dimakopoulos, “A study on the redundancy of flooding in unstructured p2p networks,” International Journal of Parallel, Emergent and Distributed Systems , vol. 28, no. 3, pp. 214– 229, 2013

work page 2013

[4] [4]

Rng-based search- ing and broadcasting algorithms over internet graphs and peer-to-peer computing systems,

O. Escalante, T. P ´erez, J. Solano, and I. Stojmenovic, “Rng-based search- ing and broadcasting algorithms over internet graphs and peer-to-peer computing systems,” in The 3rd ACS/IEEE International Conference onComputer Systems and Applications, 2005. IEEE, 2005, p. 17

work page 2005

[5] [5]

Probabilistic edge multicast routing for the xrp network,

V . Tumas, S. Rivera, D. Magoni, and R. State, “Probabilistic edge multicast routing for the xrp network,” in GLOBECOM 2022-2022 IEEE Global Communications Conference . IEEE, 2022, pp. 5129–5134

work page 2022

[6] [6]

Scaling unstructured peer-to- peer networks with multi-tier capacity-aware overlay topologies,

M. Srivatsa, B. Gedik, and L. Liu, “Scaling unstructured peer-to- peer networks with multi-tier capacity-aware overlay topologies,” in Proceedings. Tenth International Conference on Parallel and Distributed Systems, 2004. ICPADS 2004. IEEE, 2004, pp. 17–24

work page 2004

[7] [7]

Two-layer hybrid peer-to-peer networks,

Z. Duan, C. Tian, M. Zhou, X. Wang, N. Zhang, H. Du, and L. Wang, “Two-layer hybrid peer-to-peer networks,” Peer-to-Peer Networking and Applications, vol. 10, pp. 1304–1322, 2017

work page 2017

[8] [8]

A geography-based p2p overlay network for fast and robust blockchain systems,

H. Qiu, T. Ji, S. Zhao, X. Chen, J. Qi, H. Cui, and S. Wang, “A geography-based p2p overlay network for fast and robust blockchain systems,” IEEE Transactions on Services Computing , 2022

work page 2022