# Segmented payload diffusion, card by card *A reference for Informed Diffusion (segmented execution payload diffusion), one mechanism at a time. It accompanies the post [*Informed Diffusion: making home builders publish fast*](https://ethresear.ch/t/informed-diffusion-making-home-builders-publish-fast/26151) (*Informed Diffusion* below), and follows [EIP-8411: what segmented payload diffusion is made of](https://ethresear.ch/t/eip-8411-what-segmented-payload-diffusion-is-made-of/26025) (2026).* Segmented payload diffusion is built from small mechanisms, each added on top of the previous ones. We call them cards, numbered in the order they were added. This document describes each card in turn: what it does, why it is there, what it needs, what it costs, and when it matters. The posts tell the story of the cards, and the pseudocode companion, [*Informed Diffusion: the protocol in pseudocode*](https://github.com/cskiraly/informed-diffusion-spec/blob/main/protocol.md), specifies them exactly. This document sits in between, so that each card can be read alone. The cards describe the proposed protocol. The measurements come from a research implementation that differs from it in a few places; the pseudocode's §9 lists them, and the cards that are affected say so. Earlier posts in the series, with the short names used below: - [Wen fast payload broadcast? Segment, code, push, pull, and everything in between](https://ethresear.ch/t/wen-fast-payload-broadcast-segment-code-push-pull-and-everything-in-between/25913) (*Segment, code, push-pull*, 2026): the design space and the commitment; - [EIP-8411: what segmented payload diffusion is made of](https://ethresear.ch/t/eip-8411-what-segmented-payload-diffusion-is-made-of/26025) (*What segmented payload diffusion is made of*, 2026): tiers 1 to 3, cards 0 to 6; - [EIP-8411 payload segmentation under the Shadow simulator](https://ethresear.ch/t/eip-8411-payload-segmentation-under-the-shadow-simulator/26070) (2026): the cross-check. ## How to read this ### The tiers The cards come in four tiers. Each tier is a prefix of the next, and each is a place where one could stop. | tier | cards | in one line | |---|---|---| | base | 0 | the whole payload as one gossip message, as today | | 1 | 1, 2 | chunks with a commitment in the bid, batch publishing | | 2 | + 3, 4, 5 | announce instead of push, the phase, disciplined pulls | | 3 | + 6 | a rate-½ erasure code over the compressed payload, stop-pull | | 4 | + 7 to 17 | what a node knows about its neighbours (7–12), the source (13–15), aimed pushes (16, 17) | ### Each entry Every card follows the same outline, and a heading is left out where it has nothing to say: - **Rule:** what the node does, in one sentence. - **Problem:** what goes wrong without it. - **How it works:** the mechanism, in plain words. - **Where it acts:** in the consensus objects, on the wire (both ends must agree), or locally (a node's own choice, which a client can adopt alone). - **Depends on:** where a dependency needs explaining. The table below lists them all. - **Parameters:** the values used, and why. - **Costs and risks.** - **When it matters:** what the measurements show, qualitatively, for a 1 MiB payload in the all-home network and with a datacenter builder (Terms below). The table at the end gives numbers for the cards that can be removed one at a time. - **Lineage:** where the idea comes from. ### Terms - **Chunk:** one piece of the segmented and coded payload, with its Merkle proof. The earlier posts call these *segments*. We use the more generic *chunk*, EIP-8411's term, because compression, segmentation and coding can be combined in several orders, which *segment* did not fully cover, or at least made easy to misunderstand. - **Group:** the chunks of one payload: K data chunks and, with the code, as many parity chunks, N = 2K in all. A 1 MiB payload is K = 64 and N = 128. - **Mesh and connections:** in the measured networks a node holds about seventy connections, and gossipsub grafts eight of them (D = 8) into the topic's mesh. Nodes push within the mesh (card 13 lets the source push wider), and heartbeat gossip goes to a sample of the others. - **Push, announce, ask:** a push sends a chunk unasked. An announce (an IHAVE) says that the sender can serve a chunk, and an ask (an IWANT) requests it. - **Holder:** a peer that has said it holds a chunk, by IDONTWANT or by a HAVE bitmap (card 7). - **Push budget r:** the most mesh peers a node pushes a chunk to (card 3). Card 4 subtracts the peers already known to hold the chunk. - **Lanes:** each peer's send queue has an urgent lane, for control that must not wait (HAVEs, acknowledgements), and a normal lane, for chunks and the rest of the control. The urgent lane always goes first. - **Acknowledgement:** a receiver's HAVE sent back to the peer a chunk came from (card 14). - **The source:** the node that publishes the payload, normally the builder. Every other node is a **forwarding node**: it passes on what it receives. - **The two networks** measured, 500 nodes each, in three scenarios (Figure 1 uses all three, the removal table the all-home network and the datacenter builder): - **the all-home network:** every node, the builder included, on a home connection of 50 Mbps up and 100 down, what [EIP-7870](https://eips.ethereum.org/EIPS/eip-7870) recommends for a local block builder, and none faster. This is the operating point the protocol is meant to guarantee: it must work there without relying on faster nodes. Today's mainnet is fast enough largely because datacenter builders and high-bandwidth nodes carry the payload. - **the mixed-bandwidth network:** the same network with faster nodes, a fifth of the nodes in datacenters at 1 Gbps. This is closer to today's deployment. We run it **with a datacenter builder**, at 1 Gbps, and **with a home builder**, at 50 Mbps: a solo builder in a network that is otherwise today's. ### One thread through the cards A push is a pull with the round trip removed and a duplicate risk added. Either way the sender's uplink carries the chunk once. By pull, the chunk pays an announcement, a request and a wait in the answerer's queue. By push, it leaves at once, and it is wasted if the receiver gets it from someone else first. Most cards refine this trade: they push where a duplicate is unlikely, announce where it is likely, and cancel pushes that became duplicates while they waited. ### Where the ideas come from This work builds on twenty-five years of peer-to-peer research. Pieces verified against a hash tree, rarest-first, push-pull scheduling, erasure-coded streaming and rate control at the sender were worked out in file sharing, live streaming and data availability long before they met a beacon block. What is new is the setting: a payload that must reach every node within a second or two, verified against a commitment before it is forwarded, with a guarantee that holds when every node, the builder included, has only a set minimum bandwidth. Each card's lineage names the work it builds on, as far as we know it. Mapping out that literature is work in progress. A missing reference is more likely a gap in our survey than a claim of novelty, and where a lineage says *new in tier 4*, we have simply found no earlier source yet. Pointers are welcome. ### The cards at a glance | card | name | tier | acts in | needs | |---|---|---|---|---| | 0 | whole message | base | – | – | | 1 | segmentation | 1 | consensus (the bid) and wire (chunk, id) | – | | 2 | batch publishing | 1 | local (source) | 1 | | 3 | announce instead of push | 2 | local | 1 | | 4 | the phase | 2 | local | 3 | | 5 | disciplined pulls | 2 | local | 3 | | 6 | the erasure code, stop-pull | 3 | consensus (the commitment covers parity) and local | 1 | | 7 | HAVE bitmaps | 4 | wire | 1 | | 8 | cancel at dispatch | 4 | local | 7 | | 9 | rarest at pop | 4 | local | 7 | | 10 | decode claim | 4 | wire (card 7's encoding); the repair locally | 6, 7 | | 11 | a push budget of two | 4 | local | 4, 6 | | 12 | projection | 4 | local | 6, 7 | | 13 | striped publishing | 4 | local (source) | 2, 3; 16 to spread the stripes evenly | | 14 | the static window | 4 | local, with acks on the wire | 7, 8 | | 15 | paced gossip | 4 | local | – | | 16 | furthest behind first | 4 | local | 3, 7 | | 17 | push degree by uplink | 4 | local | 4 | The table lists what a card's rule needs. A card's measured benefit can also depend on later cards that use its information. Only cards 1, 6, 7, 10 and 14 put anything new on the wire or in the consensus objects. Card 1 changes the bid and the message format. Card 6 changes what the commitment covers. Cards 7, 10 and 14 use one encoding, a bitmap carried inside gossipsub's existing control messages. Everything else is a decision a node makes on its own. ### The cards on one figure  *Figure 1. The cards added one at a time, in the all-home network (blue: every node, the builder included, at 50 Mbps up and 100 down), and on the mixed-bandwidth network (the same network with a fifth of the nodes in datacenters at 1 Gbps) with a home builder (green) and with a 1 Gbps datacenter builder (red), 500 nodes, 1 MiB. Point n is card n added to everything before it; the key names every rung, the large points are the tiers. Horizontal: receiver p99, the time by which 99 % of nodes hold the payload. Vertical: bytes each node receives, data and control, in copies of the payload compressed whole. Lower left is better. Bars: one standard deviation across the simulated networks. Card 17 changes nothing in the all-home network, where no node is fast, so the blue line ends at 16.* Each card's "When it matters" describes its step in this figure. A step depends on the cards before it, so the figure is paired with a second reading at the end of this document: tier 4 with one card removed at a time. ## The base ### 0. Whole message **Rule.** Stock gossipsub v1.2: the payload travels as one message. **How it works.** A receiver tells its mesh peers that it has the message (IDONTWANT), validates the whole payload, and then pushes it to every mesh peer that has not said IDONTWANT in the meantime. At the next heartbeat it announces the message to a sample of its other peers, and a node that lacks an announced message asks for it. The go-libp2p implementation asks every peer that announced it. **Problem it leaves.** Nothing can be forwarded before the whole payload has arrived and been checked, so every hop adds a full payload-time (store and forward). At the source, a push to eight mesh peers sends eight copies in parallel, each at an eighth of the uplink. The heartbeat makes it worse: the source announces the payload to peers outside its mesh, they all ask, and each answer is the whole payload, on the same uplink as the mesh pushes. With a home builder **the source answers its own gossip**, uploading many times the payload in answers. **When it matters.** It is the reference every other card is measured against. In the all-home network the last nodes receive the payload several seconds after it is published. ## Tier 1: pipelining ### 1. Segmentation **Rule.** The builder cuts the payload into chunks, commits to them in its bid, and publishes each chunk as an ordinary gossip message that a node forwards as soon as it verifies. **Problem.** Store and forward (card 0). **How it works.** - **The commitment.** The builder builds a Merkle tree over the chunks. A descriptor names the layout (chunk count, chunk size, total length, encoding) and the tree's root. Its hash is the group id. The bid commits to the descriptor, so every chunk is authenticated through the block that carries the bid: installed block → bid → descriptor → Merkle proof → chunk. - **Getting the descriptor.** A receiver needs the descriptor itself, not only its hash, to check a chunk's proof. Two designs work, and the choice is open. Either the descriptor travels in every chunk, and the receiver checks its hash against the group id in the bid; or the bid carries the descriptor itself instead of its hash. At these chunk sizes the bytes do not decide it. - **The chunk.** Each chunk carries its slot, the block root, the group id, its index, its Merkle proof and its data, and in the first design the descriptor. - **The id.** A structured message id: the group, the chunk's index, and the usual 20-byte content hash, 56 bytes in all. A receiver can match an announcement to a group and an index before it holds the chunk. Two different byte strings claiming the same index still have different ids. - **What is segmented** is the content the builder holds at bid time: the execution payload and the execution requests. The envelope is rebuilt from it and the block. How the envelope's signature travels then is a question of its own (see [Who decides that a payload is revealed?](https://notes.ethereum.org/@cskiraly/eip-8411-envelope-signature)). **Where it acts.** In consensus: the bid gains the group id, or the descriptor. On the wire: a new message format and id on the payload's topic. Gossip messages carry no author, sequence number or signature, as Prysm already publishes them: authentication comes from the commitment. Validation rules: - do not forward a chunk whose block is not installed (validated and applied locally); hold it in a bounded buffer, with per-peer reservations, and validate it when the block arrives; - a receiver may decline to ask for a chunk it cannot yet authenticate, remembering the announcement and replaying it when the block installs. **What a forwarding node can check, and who pays when it cannot.** Validation comes in three levels, and only the first fits a chunk: - **per chunk, authenticity:** the chunk is the committed piece at its index, checked against the descriptor and the root before the node forwards it, claims it or serves it. It costs a Merkle proof, so every node checks it first, and a chunk that fails it is the fault of the peer that sent it; - **per group, after any K chunks, the code's consistency:** decode, re-encode and rebuild the tree against the root. Only the builder can fail it, and then it fails at every node. A node pushes or serves chunks it rebuilt, and hands the payload on, only after this check passes. It may claim them earlier, as soon as it has K chunks: a claim about a group that fails the check is about a group every node drops; - **per message, the application's checks** on the reassembled payload and its envelope: the builder's signature, the payload against the bid, then execution. A chunk carries nothing these could check. So nodes forward pieces of a payload that nobody has validated yet, and that is where the speed comes from. **What bounds the damage is the builder's cost.** A chunk authenticates only against the bid an installed beacon block carries, so at most one payload per winning bid crosses the network: one per block. Chunks committed to a losing bid never validate. Under Gloas, a bid's pending payment that reaches the same-slot attestation quorum is queued for withdrawal whether or not its payload ever arrives: if it is not settled earlier, at the end of the epoch after the bid's. A builder that commits to an invalid payload therefore pays for the slot and gets nothing for it. One case moves the cost: a proposer that signs a second block for the slot is slashed, and the slashing clears that slot's pending payment. The nodes that forwarded it could not have known, so a payload that fails after decoding must never count against them. A node that finds such a failure drops the group and retracts nothing: what it claimed were authentic pieces. The measured runs had no blocks and checked no proofs; the pseudocode's §9 says what that leaves out. **Parameters.** K is the uncompressed payload size divided by 16 KiB, rounded up: K = 64 at 1 MiB. With compress-first coding (card 6) each chunk carries 1/K of the compressed payload, about 12 KB at 1 MiB. 16 KiB is where the latency floor was reached in [*What segmented payload diffusion is made of*](https://ethresear.ch/t/eip-8411-what-segmented-payload-diffusion-is-made-of/26025). Smaller chunks added no speed and doubled the control traffic, and larger ones were slower. **Costs and risks.** More bytes, because many chunks racing through a full mesh deliver many duplicates. More control traffic, one announcement or IDONTWANT per chunk instead of per payload. More verifications, though each is a cheap Merkle proof. **When it matters.** In every setting measured, it is most of the latency gain of the whole series. A node starts forwarding after one chunk-time instead of one payload-time, and its uplink serves different chunks to different peers at once. The later cards mostly buy back the bytes it costs. **Lineage.** BitTorrent's hash-verified pieces (Cohen, 2003), Merkle trees in torrents (BEP 30, 2009) and BitTorrent v2's 16 KiB leaves (BEP 52); FullDAS's structured ids; [*Segment, code, push-pull*](https://ethresear.ch/t/wen-fast-payload-broadcast-segment-code-push-pull-and-everything-in-between/25913) (2026). ### 2. Batch publishing **Rule.** The source enqueues a first copy of every chunk before a second copy of any. **Problem.** Publishing chunks one after another sends every copy of chunk 1 before chunk 2 starts. The last chunk leaves the source only after nearly the whole payload has gone out once per mesh peer, so the pipeline that card 1 created is starved at its first hop. **How it works.** The source plans each chunk's push targets, then enqueues the first copy of every chunk, then the second copies. This sets only the order in which chunks enter each peer's queue; what leaves first on each link is decided when the queue sends (cards 9 and 14). **Where it acts.** Locally, at the source. It needs a publishing interface that takes several messages at once, which go-libp2p-pubsub has upstream. **Costs and risks.** Hardly any: the bytes change little. **When it matters.** In the all-home network, where the builder's uplink is the bottleneck of the first hop. With a datacenter builder it helped when it was added, but in tier 4, where the 1 Gbps builder also stripes (card 13), removing it changes nothing. **Lineage.** FullDAS's simulators; [batch publishing](https://ethresear.ch/t/improving-das-performance-with-gossipsub-batch-publishing/21713) (2025), merged [upstream](https://github.com/libp2p/go-libp2p-pubsub/pull/607) in go-libp2p-pubsub (2025). ## Tier 2: push and pull ### 3. Announce instead of push **Rule.** A node pushes each chunk to a few mesh peers and announces it to the rest at once, and they ask for it if they still need it. **Problem.** A full-mesh push of many chunks sends most copies to nodes that already hold the chunk or are about to. **How it works.** A node pushes the chunk to at most r mesh peers, chosen among those not known to hold it (cards 4, 11 and 16 set r and the choice), and sends an IHAVE for it to the other mesh peers not known to hold it. The announce goes out immediately, not at the next heartbeat. Known holders get neither. **Where it acts.** Locally, with one interaction on the receiving side: announcing per chunk sends many more IHAVEs than heartbeat gossip does, more than gossipsub's default limit on IHAVE messages per peer per heartbeat allows, and a stock receiver drops the rest. Clients must raise that limit, or batch their announcements per peer. **Costs and risks.** A pulled chunk takes a round trip, and the announcements multiply the asks a node must answer, which card 5 controls. Push and pull give separate recovery paths: a chunk lost on one can still arrive through other peers and later announcements. **When it matters.** It removes a large share of the bytes and shortens the tail at both builders, because the uplink stops queueing copies that would have been refused. With a datacenter builder the median gets slightly slower. **Lineage.** [PPPT](https://ethresear.ch/t/pppt-fighting-the-gossipsub-overhead-with-push-pull-phase-transition/22118) (2025), and the push-pull scheduling of peer-to-peer streaming (Abeni, Kiraly and Lo Cigno, 2009). Push and pull as the two halves of epidemic dissemination go back to the anti-entropy of epidemic algorithms (Demers et al., 1987), and eager push to a few peers with lazy announcements to the rest is Plumtree's split (Leitão, Pereira and Rodrigues, 2007). The same trade runs through the Vac work on [staggering and fragmentation](https://arxiv.org/abs/2504.10365) and [PREAMBLE and IMRECEIVING](https://arxiv.org/abs/2505.17337), and through [ethp2p](https://github.com/ethp2p/ethp2p). ### 4. The phase **Rule.** The push budget for a chunk shrinks with every mesh peer already known to hold it: push early in a chunk's life, announce late. **Problem.** A fixed push width is blind to how far a chunk has spread. Early, a push is almost always useful; late, when most of the mesh holds the chunk, it is almost always a duplicate. **How it works.** budget = max(0, r − holders), where holders counts the mesh peers that have said they hold the chunk. A node announces holding a chunk before it forwards it, in the urgent lane, ahead of data. So when a chunk comes from a mesh peer, that peer normally counts as a holder, and at r = 2 the chunk goes on to at most one further peer early in its life, and to none late. A chunk from outside the mesh, such as a striped push from the source (card 13), can go on to two. **Where it acts.** Locally. It reads the IDONTWANTs a node hears anyway, or the HAVE bitmaps of card 7. **Costs and risks.** On idle uplinks and small payloads it trades a little latency for fewer duplicates. **When it matters.** It is a byte card. Removing it from tier 4 brings back a large share of the duplicates in the all-home network and a smaller one with a datacenter builder, and costs some time at both. **Lineage.** [PPPT](https://ethresear.ch/t/pppt-fighting-the-gossipsub-overhead-with-push-pull-phase-transition/22118) (2025). Counting IDONTWANTs is Marco Munizaga's suggestion in [its discussion](https://ethresear.ch/t/pppt-fighting-the-gossipsub-overhead-with-push-pull-phase-transition/22118/3): push with a probability that falls with the IDONTWANTs received. This card reduces the budget linearly instead. Behind both is the classic result of randomized rumor spreading: push while few nodes hold the message, pull once most do (Karp, Schindelhauer, Shenker and Vöcking, 2000). ### 5. Disciplined pulls **Rule.** Ask one announcer for a chunk at a time, move on to another after a timeout, and stop asking a peer, for that payload only, if it breaks its promise. **Problem.** Some implementations, go-libp2p among them, ask every peer that announces a missing message. With announcements per chunk (card 3) that brings back through the pull path the duplicates the push path saved. Asking only one announcer instead needs a timeout, and waiting on one peer lets a peer that announces and never serves hold up the chunk. **How it works.** - **Offer table:** remember who announced each chunk. - **One ask at a time:** no second ask for the same chunk within a 200 ms window. After it, the next announcer may be asked, untried ones first, while the earlier answer can still arrive. - **Promises:** an asked peer that has not delivered within 400 ms of our first ask to it for that chunk has broken a promise. A late delivery is still taken. - **Park:** a peer that breaks a promise is parked for 30 s. Its announcements are recorded but not acted on for that payload's group. Its pushes and our answers to it continue. **Where it acts.** Locally. A promise closes when the chunk arrives from anyone, or when the payload decodes (card 10). **Parameters.** A 200 ms window, a 400 ms promise, one break to park, 30 s parking, scoped to the (peer, group). Offers are bounded: 16 announcers per chunk, 256 entries per announcer, 30 s. **Costs and risks.** Each chunk waits on one announcer at a time. A withholder that announces and never answers costs about one window per chunk it is asked for, and more if it is asked again; if every announcer is parked, the chunk waits for a fresh announcement or a push. The tail grows with the share of withholders. The code (card 6) buys most of that back. **When it matters.** It roughly halves the bytes. In the all-home network it also shortens the tail; with a datacenter builder the tail barely moves. The offer table, move-on and park change little on a clean network. They are insurance against peers that do not answer. The **group scope** of the park keeps one payload's broken promise from costing the next. With a datacenter builder an unscoped park is clearly slower: a busy peer, the builder included, can break a promise on one payload and then be ignored on the payloads that follow. **Lineage.** go-libp2p-pubsub [issue #606](https://github.com/libp2p/go-libp2p-pubsub/issues/606), *Sending only one IWANT at a time*, and [pull request #625](https://github.com/libp2p/go-libp2p-pubsub/pull/625), *Limit the number of outstanding IWANTs per messageid and per heartbeat* (open); the one-ask-per-id window of the das-simulator-nim; [*What segmented payload diffusion is made of*](https://ethresear.ch/t/eip-8411-what-segmented-payload-diffusion-is-made-of/26025) (2026). ## Tier 3: the code ### 6. The erasure code, and stop-pull **Rule.** Compress the payload, code it into K data chunks and K parity chunks so that any K distinct chunks rebuild it, and stop asking once the payload decodes. **Problem.** Among K chunks racing through the network, one arrives last, and every node waits for it. A withheld or lost chunk stalls everyone who needs it. **How it works.** - **Compress first.** Payload data compresses and parity does not. Compressing the whole payload first, then coding the compressed bytes, gives chunks of equal size on the wire. - **The code** is a systematic Reed–Solomon code over GF(2⁸): chunks 0 to K−1 are the compressed bytes themselves, and K to 2K−1 are parity. The commitment covers all 2K chunks. - **Decoding** takes any K distinct chunks, rebuilds the data, re-encodes the parity, rebuilds the tree, and checks the committed root. A mismatch can only be the builder's fault, and the group is dropped. Any node that holds K chunks can check the code, so chunks need no per-chunk consistency proof. - **Stop-pull:** a node that can decode asks for nothing more of that payload. Chunks already on their way still arrive; each new index among them counts toward the K. **Where it acts.** In consensus, the descriptor says the group is coded and compressed, and the commitment covers the parity. The rest is local. **Parameters.** Rate ½: N = 2K. The codec allows at most 256 chunks, so above 2 MiB of payload the group is published plain. A lower rate helped only where the source stripes wide, and there it bought a few percent of the tail for about a fifth more bytes, counted to the 3 s mark. It stays an option for a builder that would trade bytes for time. **Costs and risks.** The source sends twice the chunks, and receivers take more bytes than without the code. Decoding and re-encoding take CPU time on every node. **When it matters.** In the tail, and the median follows: completion becomes the K-th distinct chunk of 2K to arrive rather than the last of K, and on both networks both statistics shorten. It is also what makes the pull path robust: under withholding it takes the tail back down, and a source that omits chunks is covered as long as K distinct chunks still reach each receiver. **Lineage.** Reed and Solomon (1960); software erasure codes (Rizzo, 1997); the digital fountain (Byers et al., 1998); PULSE (2007) and source-coded epidemic streaming (Bonald et al., 2008); FullDAS. Network coding goes further and recodes inside the network: in content distribution (Gkantsidis and Rodriguez, 2005), and for Ethereum block propagation with random linear network coding ([Potuz, 2025](https://ethresear.ch/t/faster-block-blob-propagation-in-ethereum/21370)). Here only the source codes, and the other nodes forward chunks unchanged. ## Tier 4: what a node knows about its neighbours ### 7. HAVE bitmaps **Rule.** One bitmap per group replaces the per-chunk ids in IDONTWANT and IHAVE. **Problem.** With 128 chunks per payload, per-id IDONTWANTs and IHAVEs are many small messages that each say little. Worse for the cards that follow, a node has no compact picture of what each neighbour holds. **How it works.** A HAVE bitmap names a group and the set of its chunks. It travels as a single pseudo message id inside gossipsub's existing control messages, and the control message that carries it sets its meaning: - **in IDONTWANT, "I hold these":** always the sender's whole current bitmap for the group, so the receiver merges it in any order and a repeat does no harm. A node sends it urgently to its mesh peers on every new chunk once the chunk's proof checks, not on arrival as stock IDONTWANT does: a held index is stronger evidence than a held id, since it covers any chunk claiming that index. The source's HAVE grows with the chunks it sends, a chunk joining it when the source first sends it, and each peer it pushes to gets a HAVE naming its first chunk just ahead of it: a HAVE naming every chunk before any has left could only come from the source. The measured runs differ: there the source's HAVE named every chunk before its data, growing one chunk at a time as each joined the batch, and nodes announced on arrival, since they validated nothing (with the block installed, the check adds microseconds). - **in IHAVE, "I can send you these":** exactly the chunks the announcement names, minus those the sender pushed to that peer and those the peer said it holds. - **in IWANT, an ask by index:** the group and the index, for a chunk whose full id the asker does not know. A node keeps, per peer and group, the union of that peer's IDONTWANT bitmaps, live for three heartbeats after the peer's last one, and forgets them when the connection closes. An ask for a chunk the asker has claimed is dropped, and is a protocol violation: claims are made only for chunks whose proof checked, a node's holdings never shrink while its connection lives, and a node drops its queued asks for chunks it already holds, so an honest ask always arrives before the claim it would contradict. A restart is a new connection, with no claims. An IHAVE bitmap says who can serve, not who holds, and feeds only the offer table. **Where it acts.** On the wire, and both ends must agree. Nothing is added to gossipsub's protobuf: a peer that does not understand a bitmap sees an id that matches nothing. **Costs and risks.** - **Why not before validation:** announced on arrival, a forged chunk for index i would make a node claim i. Its peers would stop pushing and announcing i to it and count it as a holder, and bitmaps cannot take a claim back. Forged chunks for more than N − K indices would leave its mesh unable to bring it the payload. - **Chunks ahead of their block:** a chunk whose block is not yet installed cannot be checked, so it is announced only once the block installs. Until then its senders may keep pushing it, and their window slots stay held (card 14). Announcing such a chunk by its exact id on arrival, as stock IDONTWANT does, would close that gap safely, since an id covers only those bytes; that variant is not evaluated yet. - **Mixed deployment:** a peer running stock gossipsub that receives a bitmap in an IHAVE asks for it as if it were a message id, gets no answer, and may count a broken promise against the sender. Bitmaps should go only to peers known to understand them, behind a capability or protocol id. **When it matters.** Control traffic falls by more than half as measured, with a message id longer than card 1's; with the 56-byte id the saving is smaller. In the all-home network the tail gets a little shorter. Mostly it is the information cards 8, 9, 10, 12, 14 and 16 use. **Lineage.** The buffer maps of CoolStreaming/DONet (Zhang, Liu, Li and Yum, 2005), a per-partner bitmap of the chunks held, exchanged to drive scheduling; [FullDAS](https://ethresear.ch/t/fulldas-towards-massive-scalability-with-32mb-blocks-and-beyond/19529) (2024); the gossipsub partial-messages extension, which EIP-8136's cell-level deltas build on. ### 8. Cancel at dispatch **Rule.** When a queued chunk is about to be sent, drop it if the peer has meanwhile said it holds it. **Problem.** A push is chosen when the chunk enters a peer's queue and leaves some time later. In between, the peer may have received it elsewhere. **How it works.** Each peer has one writer, which takes the next item from the queue when the previous write has completed. Before writing a chunk it checks the peer's bitmap (card 7) and drops the chunk if the bit is set. This applies to answers too. An ask for a chunk the asker has already claimed is never answered (card 7), so an answer is cancelled only by a HAVE that arrives after the ask. (The measured runs answered such asks, clearing the claim for cancel only; the pseudocode's §9.) A cancelled push is not replaced by another target. **Where it acts.** Locally. **When it matters.** On its own, little: the queues of a clean network are short. It matters where the backlog is held above the transport, which the window (card 14) arranges. A chunk already handed to the transport cannot be cancelled. **Lineage.** BitTorrent's endgame cancel and gossipsub's IDONTWANT. Here the check sits immediately before a chunk leaves the queue. ### 9. Rarest at pop **Rule.** When a peer's queue holds several chunks, send first the one the fewest of our neighbours are known to hold. **How it works.** The node counts, for each chunk, the distinct peers whose live HAVE bitmaps cover it. At each send the writer picks the queued chunk with the lowest count, the earliest on a tie. It never moves a chunk past a queued entry that carries only control. (The measured implementation's counts only ever grew; the pseudocode's §9.) **Where it acts.** Locally. **When it matters.** On a clean network it hardly matters: batch publishing and the code already spread the chunks, and queues are short, so it rarely reorders anything. Under withholding, which distorts which chunks are rare, it buys a little of the tail. It costs little, so it stays. **Lineage.** BitTorrent's rarest-first (Cohen, 2003), and its measured effect on piece diversity (Legout, Urvoy-Keller and Michiardi, 2006); FullDAS. ### 10. Decode claim **Rule.** A node that can decode says at once that it holds every chunk of the group, and once it has checked the group, it pushes the chunks it rebuilt to the mesh peers still short of K. **Problem.** A node that has decoded keeps receiving chunks it does not need: pushes already queued toward it, and answers to asks it made before it finished. And when the builder releases only K chunks, every node needs every one of them, the slowest to reach it included, while the other K exist only in the nodes that have decoded. **How it works.** - **The claim.** At its K-th chunk the node can rebuild every chunk (card 6), and it says so at once, before decoding: it sends its mesh peers a HAVE with all N bits set. Their writers then cancel everything still queued toward it (card 8), and its own open asks close: nobody owes it chunks of that group any more. Without that, a client that scores peers would penalise honest peers for asks the decode made unnecessary. The node decodes and checks the group in the background (card 1). - **Repair.** Once the check has passed, the node pushes the chunks it rebuilt to each mesh peer whose claims show it short of K: up to that peer's shortfall, counting what the node already chose to push it, picked at random among the rebuilt chunks the peer lacks, so that decoded neighbours tend to push different chunks. A rebuilt chunk is the source's chunk byte for byte, with the same id and proof, so its receiver handles it like any other. The node does not announce rebuilt chunks. **Where it acts.** The claim on the wire, in card 7's encoding; the repair locally. The claim says the node holds every chunk, which is true once it has decoded and checked the group. It can say so at K, before decoding, because a group that fails the check fails it at every node (card 1). (The measured runs claimed at K and never decoded, so they did not repair, and they left the open asks to their deadline; the pseudocode's §9.) **Costs and risks.** - **Mesh only:** the claim reaches mesh peers only. A peer outside the mesh that is still pushing (the striping source of card 13) or answering learns of it only from the node's next acknowledgement (card 14). - **Repair's bytes:** several decoded neighbours may push to the same slow node at once, while it needs only its shortfall. The random choice makes it less likely that two of them push the same chunk, and does nothing to stop them pushing more chunks than the node needs; cancel at dispatch (card 8), projection (card 12) and the window (card 14) bound both. The extra bytes are fewest on a full release and most under a minimal release with withholders. - **Why push, and not hold or announce:** the claim is not an announcement, and asks go to announcers, so a node that only held its rebuilt chunks would never be asked for them: holding is the same as rebuilding nothing. Announcing adds an ask and an answer, three link delays against one, so it helps less, mainly where other asks fail. It can also be baited: an announcement is a promise nobody can check before asking, and a withholder or a liar draws asks it never answers until the park (card 5) stops them. - **Faulty nodes decode too:** a silent node, or a withholder that refuses to repair, keeps what it rebuilt. Under a minimal release, honest repair alone still carries most of the gain. - **Under-reporters:** a mesh peer that claims less than it holds draws repair pushes up to its claimed shortfall, at most K chunks from each decoded neighbour, once per group. Projection (card 12) stops it at half that, unless it acknowledges each chunk to its sender alone, like the under-reporter of card 16; repair skips that card's guard and draw. This attacker was not run. **When it matters.** The claim saves bytes, more with a datacenter builder, where many chunks are still in flight when a node finishes. Without it the builder in the all-home network also answers many more asks, from a small base. Repair matters when the builder releases only K chunks. Completion times then spread out, and a builder that releases late could use the spread to split the network at a deadline such as the payload's due time, which the payload timeliness committee checks. Pushing rebuilt chunks brings the spread most of the way back to that of a full release, also with three nodes in ten withholding, among them withholders that refuse to repair, and ones that also announce what they do not hold; with three in ten silent, about half of the way. On a full release it matters less: every chunk is released, and a rebuilt chunk is one more copy of a plentiful one. Figure 1 and the table at the end were measured without repair. The companion note [*What a forwarding node checks, and when it decodes*](https://notes.ethereum.org/@cskiraly/informed-diffusion-decoding) gives the reasoning and the measurements. **Lineage.** FullDAS's simulators, and its in-network repair for availability amplification; PeerDAS's cross-seeding of reconstructed columns; the partial-messages extension, where a node that holds a message says so. ### 11. A push budget of two **Rule.** With the code, the push budget r is 2 instead of 3. **Problem.** An uncoded receiver needs every chunk, so it benefits from several eager copies. A coded receiver needs any K of 2K, so extra copies are more often duplicates. **How it works.** Card 4 subtracts the mesh peers already known to hold the chunk, usually including the one it came from, so for a chunk received from the mesh r = 2 means at most one further push. **Where it acts.** Locally: a constant. **Parameters.** 2 at 1 MiB. Smaller payloads were run with a larger r: 4 at 256 KiB and below, 3 between, 2 from 1 MiB. The rule should be keyed on K rather than on the payload size, and is not fixed yet. **Costs and risks.** In the all-home network the third push was not only duplicates: with it the tail is slightly shorter, for a quarter more bytes. **When it matters.** On the ladder it is the largest byte saving among cards 7 to 12; in tier 4, projection (card 12) saves more with a datacenter builder. It costs a little time in the all-home network and none with a datacenter builder. **Lineage.** New in tier 4. ### 12. Projection **Rule.** Skip a push to a peer projected to reach K distinct chunks without it. **How it works.** At the moment of sending a push, count the chunks the peer has said it holds, plus twice the distinct chunks we have sent it, answers included, that it has not yet confirmed. If that reaches K, drop the push. The factor two assumes one other pusher as fast as us. Answers are never projected away: a peer that asked wants the chunk. **Where it acts.** Locally. **Parameters.** A fan-in of 2. **Costs and risks.** If the projection is wrong, the peer pulls its shortfall from the peers that announced the chunk to it. This node, which chose to push the chunk, did not announce it. **When it matters.** With a datacenter builder it saves about a tenth of the bytes at no cost in time; in the all-home network its effect is negligible. It matters more in tier 4 than when it joined the ladder. **Lineage.** New in tier 4. ## Tier 4: the source ### 13. Striped publishing **Rule.** A source whose uplink is well above its peers' spreads the first copies of its chunks over its connected peers on the topic, not only its mesh, each peer getting a different stripe of the chunks. A source at its peers' speed does not stripe. **Problem.** Batch publishing (card 2) sends to the source's eight mesh peers. A fast builder has some seventy connections, and its uplink can reach all of them in the time a home link reaches eight. **How it works.** The source pushes each chunk to two peers chosen among all its connected peers on the topic that are not known to hold it, those with the fewest chunks planned so far first. The chunks are dealt two at a time over all connections: the two copies of a chunk go to two different peers, and each connection gets a similar share. Mesh peers that were not pushed a chunk are announced it; other connections get no announcement from this step. **Where it acts.** Locally, at the source. Whether to stripe is its own choice, made from its configured uplink, the same configuration that sizes its window (card 14). **Depends on.** Card 3 for the split between pushed and announced mesh peers. The fewest-first ranking that spreads the stripes evenly is card 16's, applied at the source. **Parameters.** Stripe from a configured uplink of 1 Gbps: twenty times a home uplink, where the gain is measured. The first hop suggests the gain starts lower, once the source can send faster than its eight mesh peers can pass the chunks on: about eight times their uplink, 400 Mbps in the all-home network. A client may lower the threshold towards that, with the caveats under *Why a configured threshold*. **Costs and risks.** - **Privacy:** the source touches every connection at once, which makes it easier to find. A later post on privacy treats this. - **Block evidence:** [*Segment, code, push-pull*](https://ethresear.ch/t/wen-fast-payload-broadcast-segment-code-push-pull-and-everything-in-between/25913) asks that a node push only to peers known to hold the block. Striping picks non-mesh targets without that evidence; how to get it across the wider set is open. - **At its peers' speed:** in the all-home network striping costs time below 1 MiB, and the smaller the payload, the more it costs: about 5 % of the tail at 768 KiB, about 16 % at 128 KiB. At 1 and 2 MiB it ties. The bytes nodes receive do not change. **When it matters.** With a datacenter builder it is a large gain in the tail, about as large at 128 KiB as at 1 MiB. It is what let one topic per chunk keep up with a datacenter builder (variant C in [*What segmented payload diffusion is made of*](https://ethresear.ch/t/eip-8411-what-segmented-payload-diffusion-is-made-of/26025)): the source sat in every topic's mesh and reached most of its connections at once. It was the source's reach that paid, not the many meshes, and striping gets that reach on one topic. In the all-home network it gained at no payload size measured, from 128 KiB to 2 MiB. It pays when the source can send faster than its mesh peers can pass the chunks on: seeding seventy peers then puts more uplinks to work early. A source at its peers' speed is the bottleneck itself, and spreading the chunks thinner leaves each peer with too few to finish, which is why small payloads lose. The payload's size never changed which side won, so the rule follows the uplink alone. **Why a configured threshold.** The criterion cannot be computed at the source. A node's bandwidth is not guaranteed, neither in aggregate nor towards any one peer, so its configured uplink is a nominal figure, not what it can count on in that slot. Nor does it know its peers' uplinks. A threshold set where the gain is measured leaves a margin for both. Measuring the switch point more finely would not help: it would be the switch point of one simulated network, and it moves with the network's size, degree and bandwidths. **Not only latency.** The choice also decides how the source spends its link: how much of the distribution it does itself, and how soon the link is free for its other work, such as its other messages and attestations. Striping hands the first copies to many peers, but in our runs it raised the source's own upload at every size but 2 MiB. What hands the distribution over is the capped source of *Informed Diffusion*, which pushes its first copies and announces to nobody: with a fast builder it cut the source's upload to about a quarter at no measurable cost in time. We measured latency and bytes, not the source's other work. **Lineage.** SplitStream (Castro et al., 2003), which splits the content into stripes so that every node forwards a share; FullDAS; batch publishing; GossipSub's flood publishing (Vyzovitis et al., 2020); the source push of peer-to-peer streaming (Abeni, Kiraly and Lo Cigno, 2009). ### 14. The static window **Rule.** Each node limits its outstanding chunk deliveries, across all its peers, to a fixed window sized from its own uplink, and keeps further chunks in its own queues. **Problem.** With striping, seventy streams share one home uplink. Each chunk then leaves slowly, and the chunks that matter most wait behind the rest in transport queues the protocol cannot touch. Once a chunk is handed to the transport, cancel, rarest at pop and projection can no longer act on it. **How it works.** - **One window per node**, of W chunks. - **Taking a slot:** a chunk sent on the normal lane, push or answer. - **Returning it:** the peer's HAVE newly covering that chunk, from whatever source, or a 500 ms timeout. Every receiver sends its current HAVE back to the chunk's sender as an acknowledgement, duplicates included, in addition to its mesh peers. - **What it counts:** chunks a peer is not yet known to hold, not bytes on the wire. Another sender's copy can free a slot, and a second copy of a chunk still outstanding to the same peer takes none. - **Which chunk:** the slot is taken before the chunk is chosen, so cards 8, 9 and 12 still decide which chunk goes. - **What does not wait:** urgent control (HAVEs, acknowledgements). **Where it acts.** Locally, with one wire consequence: the acknowledgement. It is the ordinary HAVE, sent to one more peer. **Parameters.** W = ⌈uplink in bytes/s × (112 ms + 20 ms) / chunk size in bytes⌉: the network's mean round trip plus a small queue, in chunks. That is 69 chunks at 50 Mbps with 12 KB chunks. A node needs to know its uplink only roughly: a window sized for twice the real uplink costs about a tenth in the tail. **Costs and risks.** - **Unreliable acks:** a peer that never acknowledges holds slots until they time out. Withholders that also never acknowledge cost somewhat more than ordinary withholders; every node still completes within the slot budget. - **Control behind the window:** whether normal-lane control (IHAVE, IWANT) should wait behind queued chunks, as measured, or bypass the window, is open. **When it matters.** In the all-home network, where it binds mainly at the source, and the more the thinner the links. In the measured runs, with the source striping (which card 13 would not have a home builder do), tier 4 without the window (and without card 16's guard) has a tail about a tenth longer at 50 Mbps, over a quarter longer at 20 and 25 Mbps, and nearly half again as long at 10 Mbps. There, in a few payloads, most nodes missed 3 s. With the window every node completes within 3 s down to 10 Mbps. It is also the card that removed most of the source's answers to its own gossip. With a datacenter builder it hardly matters. **Why fixed.** The acknowledgement-driven controllers we tried could not converge within one payload, and estimating the link's capacity from the payload's own traffic failed; *Informed Diffusion, measured* (§§3 and 7) tells that story. A configured window is the form that deploys. **Lineage.** Hose rate control for P2P-TV (Birke, Kiraly, Leonardi, Mellia, Meo and Traverso, 2011). ### 15. Paced gossip **Rule.** Release the heartbeat's announcements one peer per short tick instead of all at once. **Problem.** At each heartbeat gossipsub announces new messages to a sample of peers outside the mesh, all at once. Those peers ask the source for what they lack while the source's uplink is still busy with its first copies. **How it works.** The heartbeat queues its announcements instead of sending them. Every heartbeat/16 one queued announcement is sent, filtered at that moment against what the peer has said it holds and what we pushed it. An announcement still queued a heartbeat later is dropped, since the next heartbeat replaces it. **Where it acts.** Locally. **Parameters.** 16 ticks per heartbeat: 43.75 ms at Prysm's 700 ms. **When it matters.** When it joined, it cut the source's answers in the all-home network by a third, at little cost in time; with a fast builder it changed them little. In tier 4 as it stands, with the window and furthest-behind-first in place, later cards do its job, and what remains is a small trade. Without it nodes in the all-home network receive about 3 % more bytes, in every case measured. The tail changes by a few percent at most: hardly at all on a clean network, a little longer on 10 Mbps links, a little shorter under withholding. The source's answers stay small in the all-home network either way, and stay large with a datacenter builder either way. **Why it stays.** For the bytes, a few percent in the all-home network at no consistent cost in time. Like every local card, a client can leave it out without affecting its peers. **Lineage.** New in tier 4. ## Tier 4: aiming the pushes ### 16. Furthest behind first **Rule.** Push to the mesh peers that hold the fewest chunks of the group, drawing among the lower half rather than taking the single furthest behind, and demote peers that take pushes but never report. **Problem.** Which of the candidates gets the push budget? Without this card the order is arbitrary, different for each chunk. The peers furthest behind are the ones for whom a push is least likely to be a duplicate, and the ones that would otherwise have to ask. **How it works.** - **The count:** for each candidate, the chunks of the group it is known to hold: the union of its HAVE bitmap and the chunks we have chosen to push it, including those still queued. Announcements and answered asks do not count. - **The lower-half draw:** nodes draw their push targets without replacement among the non-demoted candidates at or below the median count, ties included. If that pool is smaller than the budget, the rest follow in fewest-first order, demoted peers last. - **The proof guard:** a peer we have chosen to push at least r chunks of the group, the first more than 200 ms ago, that has sent no HAVE for the group, goes to the back of the order. It is not excluded, and the demotion lifts at its first HAVE. - **At the source** the plain ranking applies, with no draw (this is what spreads card 13's stripes evenly). **Where it acts.** Locally. **Depends on.** Card 3 for the budget it allocates, card 7 for the counts and for the guard's evidence: a mesh peer sends its HAVEs to its whole mesh, so a peer we push to reports to us whatever else it receives. (The measured implementation required the window, card 14, for the guard; the protocol does not.) **Parameters.** The lower half; a 200 ms grace, about one round trip. The grace starts when the first push is chosen, before queueing, so a loaded node can briefly demote an honest peer; the demotion lifts at the peer's first HAVE. **Costs and risks.** The rule trusts what each peer says about itself. In the plain form, picking the single peer furthest behind, an under-reporter always looks furthest behind. A withholder that tells each pusher it holds only what that pusher sent it draws most of its neighbours' pushes and passes none on, and against it the plain rule did worse than having no rule. So did a withholder that never reports at all, the case the proof guard is for. In the safer form an under-reporter no longer wins every contested push: it is drawn with bounded probability within the lower half. That is not a guarantee of a fair share of the traffic, but against the tailored under-reporter tier 4 loses about what an ordinary withholder costs, at every share we ran, from a tenth to half of the nodes. The draw costs a few percent against the plain form on a clean network, and somewhat more against ordinary withholders; it stays ahead of not aiming at all in every case measured. **When it matters.** At both builders it is among the larger gains in the tail. The plain form gains more and is less safe. **Lineage.** Related to two rules of peer-to-peer streaming: the Earliest-Latest peer rule (Abeni, Kiraly and Lo Cigno, 2009), which ranks peers by the age of their newest chunk rather than by how many they hold, and the most-deprived-peer rule of epidemic live streaming (Bonald et al., 2008). ### 17. Push degree by uplink **Rule.** Forwarding nodes with a fast uplink start from a push budget of six instead of two; the source keeps two. **Problem.** With datacenter nodes in the network, the fast nodes spent their spare uplink answering asks while the home nodes pushed. An answer is a push a round trip late. **How it works.** A forwarding node whose configured uplink is at least 500 Mbps uses r = 6, others r = 2; card 4 then subtracts the mesh peers already known to hold the chunk. The source keeps r = 2. A node knows its uplink from the same configuration that sizes its window (card 14). **Where it acts.** Locally. **Parameters.** r = 6 from 500 Mbps. Six is the knee: a larger budget added bytes, not time. **Costs and risks.** Somewhat more bytes received per node. **When it matters.** In networks with fast nodes, where it shortens both the median and the tail, and more under withholding: with a datacenter builder and 30 % withholders, the tail without it is about a fifth longer. The all-home network has no such nodes, and nothing changes there. The converse holds in time: lowering the budget of home nodes below two lengthened the tail, because chunks then arrive by the slower pull path. **Lineage.** New in tier 4. It is the push-pull trade once more: a duplicate is cheap on an abundant uplink, so push more there. ## Removing one card at a time Each row is tier 4 with one card removed, together with anything the measured implementation could not run without it: card 16's guard went with the window (card 14), and promises closing on decode with the decode claim (card 10). Each entry is the change in the receiver p99 or in the bytes each node receives, data and control, against full tier 4 on the same simulated network, as the median over the networks. The scenarios are the all-home network and the mixed-bandwidth network with a datacenter builder (see Terms), as in [*Informed Diffusion*](https://ethresear.ch/t/informed-diffusion-making-home-builders-publish-fast/26151) (2026). The reference tier 4 has the source striping in both; removing card 13 turns striping off. | card removed | all-home: p99 | all-home: bytes | datacenter builder: p99 | datacenter builder: bytes | |---|---|---|---|---| | 2 batch publishing | +8 % | −3 % | 0 | 0 | | 4 the phase | +8 % | +59 % | +6 % | +12 % | | 9 rarest at pop | +1 % | 0 | 0 | +1 % | | 10 decode claim (and promises closing on decode) | −1 % | +2 % | 0 | +5 % | | 11 budget of two (back to three) | −4 % | +26 % | +1 % | +7 % | | 12 projection | +1 % | 0 | 0 | +12 % | | 13 striped publishing | 0 | −1 % | +13 % | 0 | | 14 the static window (and card 16's guard) | +12 % | −2 % | +1 % | 0 | | 15 paced gossip | −1 % | +3 % | −1 % | −1 % | | 16 furthest behind first | +6 % | +1 % | +8 % | +3 % | | 17 push degree by uplink | – | – | +7 % | −8 % | | the park's group scope | +1 % | 0 | +12 % | −3 % | A positive entry means that removing the card lengthens the tail or adds bytes. Entries are rounded to the nearest percent, and 0 means the change rounds to zero. Card 17 has no entry for the all-home network, where no node is fast. The measured tier 4 did not repair, so card 10's row removes the claim alone. The table is for clean networks. Under stress some entries change, most of all the window's on thin links and card 17's under withholding; the cards' entries say how. Cards 0, 1, 3, 5, 6, 7 and 8 have no row. Removing segmentation, the announcements, the request discipline or the code turns tier 4 into a different protocol, not a smaller one. Removing the bitmaps or cancel takes away what several later cards read. Their effect is in Figure 1, where each card is added in turn. The two readings can disagree, because a card's effect depends on what is already in place. Paced gossip cut the source's answers when it joined; in tier 4 later cards do that job, and it keeps a small byte saving. Striping cost a little in the all-home network when it joined, and at 1 MiB is neutral there in tier 4, where the window holds the source's backlog. ## Open questions - **Getting the descriptor** (card 1): in every chunk, or in the bid instead of its hash. - **The striping threshold** (card 13): the default sits where a gain is measured; where the gain starts, and how the switch moves with the peers' bandwidths, is untested. - **Chunks ahead of their block** (card 7): announcing them by exact id on arrival, and by index once the proof checks. - **Repair under other releases** (card 10): a builder that releases the minimum to only part of the network, and a minimal release with a datacenter builder and on thin links; how many chunks to push to each peer, how long the check may take, and a random delay under a minimal release; what repair costs the nodes that decode first, and what a peer that claims less than it holds can make them send. - **The push budget against payload size** (card 11), to be keyed on K. - **Control and the window** (card 14): whether normal-lane control should bypass it. - **Batching announcements** (card 3), instead of raising gossipsub's IHAVE limit. - **Bitmaps in a mixed network** (card 7): a capability gate, so that stock peers never see them. - **Push only to peers known to hold the block** (card 1): the rule of *Segment, code, push-pull*. Striping (card 13) picks non-mesh targets without that evidence; how to get it is open. ## References - Reed, Solomon. *Polynomial codes over certain finite fields.* J. SIAM 8(2), 1960. - Rizzo. *Effective erasure codes for reliable computer communication protocols.* ACM CCR 27(2), 1997. - Byers, Luby, Mitzenmacher, Rege. *A digital fountain approach to reliable distribution of bulk data.* ACM SIGCOMM 1998. - Pianese, Perino, Keller, Biersack. *PULSE: an adaptive, incentive-based, unstructured P2P live streaming system.* IEEE Transactions on Multimedia, 2007. - Bonald, Massoulié, Mathieu, Perino, Twigg. *Epidemic live streaming: optimal performance trade-offs.* ACM SIGMETRICS 2008. - Demers, Greene, Hauser, Irish, Larson, Shenker, Sturgis, Swinehart, Terry. *Epidemic algorithms for replicated database maintenance.* ACM PODC 1987. - Karp, Schindelhauer, Shenker, Vöcking. *Randomized rumor spreading.* IEEE FOCS 2000. - Leitão, Pereira, Rodrigues. *Epidemic broadcast trees.* IEEE SRDS 2007. - Castro, Druschel, Kermarrec, Nandi, Rowstron, Singh. *SplitStream: high-bandwidth multicast in cooperative environments.* ACM SOSP 2003. - Zhang, Liu, Li, Yum. *CoolStreaming/DONet: a data-driven overlay network for peer-to-peer live media streaming.* IEEE INFOCOM 2005. - Gkantsidis, Rodriguez. *Network coding for large scale content distribution.* IEEE INFOCOM 2005. - Potuz. *Faster block/blob propagation in Ethereum.* ethresear.ch, 2025. - Cohen. *Incentives build robustness in BitTorrent.* P2P Econ 2003. - Legout, Urvoy-Keller, Michiardi. *Rarest first and choke algorithms are enough.* ACM IMC 2006. - Bakker. *Merkle hash torrent extension.* BitTorrent BEP 30, 2009. - Cohen. *The BitTorrent protocol specification v2.* BitTorrent BEP 52, 2017 revision. - Abeni, Kiraly, Lo Cigno. *On the optimal scheduling of streaming applications in unstructured meshes.* IFIP NETWORKING 2009, LNCS 5550, pp. 117–130. - Birke, Kiraly, Leonardi, Mellia, Meo, Traverso. *Hose rate control for P2P-TV streaming systems.* IEEE P2P 2011. - Vyzovitis et al. *GossipSub: attack-resilient message propagation in the Filecoin and ETH2.0 networks.* arXiv 2007.02754, 2020; the gossipsub v1.0–v1.2 specifications, libp2p/specs. - Kiraly et al. *FullDAS: towards massive scalability with 32 MB blocks and beyond.* ethresear.ch, 2024. - Kiraly et al. *Improving DAS performance with GossipSub batch publishing.* ethresear.ch, 2025. - Kiraly. *PPPT: fighting the GossipSub overhead with push-pull phase transition.* ethresear.ch, 2025. - Kiraly. *Wen fast payload broadcast? Segment, code, push, pull, and everything in between* (*Segment, code, push-pull*). ethresear.ch, 2026. - Kiraly. *EIP-8411: what segmented payload diffusion is made of* (*What segmented payload diffusion is made of*). ethresear.ch, 2026. - Kiraly. [*Informed Diffusion: making home builders publish fast*](https://ethresear.ch/t/informed-diffusion-making-home-builders-publish-fast/26151) (*Informed Diffusion*). ethresear.ch, 2026. - go-libp2p-pubsub issue #606, *Sending only one IWANT at a time* (2025), and pull request #625, *Limit the number of outstanding IWANTs per messageid and per heartbeat* (2025, open). - Munizaga. Reply 3 in the discussion of *PPPT*, ethresear.ch, 2025.