# Informed Diffusion, measured *This note accompanies [Informed Diffusion: making home builders publish fast](https://ethresear.ch/t/informed-diffusion-making-home-builders-publish-fast/26151) (2026), which gives the design: the tiers, the cards and their logic. The [card reference](https://notes.ethereum.org/@cskiraly/segmented-stack-cards) describes each card on its own. This note holds the measurements: what each group of cards changed on the ladder, what the source's cards buy and under what conditions, how tier 4 compares with the earlier tiers and with today's whole message, and how it holds under stress. It continues the measurements of [EIP-8411: what segmented payload diffusion is made of](https://ethresear.ch/t/eip-8411-what-segmented-payload-diffusion-is-made-of/26025) (2026) and of its cross-check, [EIP-8411 payload segmentation under the Shadow simulator](https://ethresear.ch/t/eip-8411-payload-segmentation-under-the-shadow-simulator/26070) (2026).* ## 0. How to read the numbers The harness is the one of the previous posts: the real Prysm and go-libp2p-pubsub code over a simulated network on a virtual clock, 500 nodes with about 70 connections each and a mesh of 8 per topic, geographic latency, a 1 MiB payload. Two networks, three scenarios. In the **all-home network** every node, the builder included, is 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 is faster. This is the operating point the design is meant to guarantee: it must work there without relying on faster nodes, whereas today's mainnet is fast enough largely because datacenter builders and high-bandwidth nodes carry the payload. The **mixed-bandwidth network**, closer to today, is the same network with a fifth of the nodes in datacenters at 1 Gbps. We run it **with a datacenter builder**, at 1 Gbps, and **with a home builder**, at 50 Mbps: the case of a solo builder in a network that is otherwise today's. One change from the previous posts: each run publishes **six payloads, a slot apart, on the same network**, and we report the last five. The first payload pays for opening connections, which a running node does not; the warm payloads are what a deployment sees. Every point is the median over the simulated networks of each network's median over the warm payloads. A node counts as done when it holds enough chunks to rebuild the payload; decoding, the checks that follow and any wait for the block are outside the times. Bytes are everything a node has received for the payload, data and control, by the time the last node completes, in copies of the payload compressed whole. We say *chunk* for the unit on the wire, as EIP-8411 does; the earlier posts said *segment*, which stopped fitting once compression, segmentation and coding could be combined in several orders. ## 1. The ladder  *Figure 1. The ladder from the whole message (0) to tier 4, one card per step, in the all-home network (blue), and on the mixed-bandwidth network with a home builder (green) and with a datacenter builder (red). Horizontal: receiver p99; vertical: bytes received per node by the network's completion, data and control, in copies of the payload compressed whole; bars: one standard deviation over the simulated networks. Lower left is better. The key names every rung; the large points are the tiers. Card 17 changes nothing in the all-home network, where no node is fast, so the blue line ends at 16.* Each point of Figure 1 adds one mechanism, a card, numbered as in the post and the card reference. The first six steps are the previous post's ladder; its tiers are the large points at 2, 5 and 6. This note reads the rest of the ladder by groups of cards: what the state cards changed (§2), what the source's cards buy and when (§3), what aiming the pushes buys and what it exposes (§4). §5 sets tier 4 against the earlier tiers and against today's whole message with local rules, §6 runs it through the stresses, and §7 lists what did not work. ## 2. What the state cards changed (cards 7 to 12) Cards 7 to 12 change what a node knows about its neighbours and how it uses that knowledge: one HAVE bitmap per payload per peer (7), and five rules that read it: cancel at dispatch (8), rarest at pop (9), the decode claim (10), a push budget of two (11) and projection (12). The bitmaps alone replace gossipsub's one message id per chunk, many small messages that each say little, with a peer's whole holding in a few bytes. Control traffic falls by more than half, and the tail in the all-home network gets a little shorter. The decode claim's other half, the repair of a rebuilt chunk, is described in the card reference; the measured stack rebuilt no chunks. Together, these cards remove a third of the bytes and more than half of the control traffic that tier 3 carried. They do not make a clean, uniform network faster: the bytes they save were not on anyone's critical path, and the smaller push budget even costs a little time in the all-home network. Where they do help latency is where networks are uneven. With uplinks spread widely around the same mean, the slow nodes' tail shortens noticeably, because their scarce uplinks stop carrying copies nobody needed. This is what the previous post's variant B, which carries chunks through the partial-messages extension, had over variant A, which sends them as ordinary messages on one topic: explicit per-link state of who holds what. B paid for it with a knowledge exchange before every targeted pull. Tier 4 takes the state but not the substrate: it pushes first, as A does, and uses the state to prune, order and aim the pushes, so the exchange never sits on the critical path. ## 3. The source ### Striped publishing (13): when it pays Striped publishing spreads the source's first copies over every connection, each peer getting a different stripe of the chunks, so the payload starts from seventy points instead of eight. This is what made per-segment topics, the previous post's variant C, fast with a datacenter builder there. With one topic per segment, the source sits in every mesh and reaches most of its connections at once. Striping recovers on one topic the reach that C's many meshes gave the source, without 64 standing meshes, and the single topic with it beats C in the networks we ran; we read the gain as the source's reach rather than the meshes. Striping pays when the source can send faster than its eight mesh peers can pass the chunks on: seeding seventy peers then puts more uplinks to work early. A builder at its peers' speed is the bottleneck itself. In the all-home network striping never gained, and below 1 MiB it costs time, the more the smaller the payload, which we read as each peer getting too few chunks to finish; with a 1 Gbps builder it gains at both sizes we ran there, 128 KiB and 1 MiB, by about the same margin. So the source decides from its own uplink, against a configured threshold set where the gain is measured. The stack as plotted stripes at both builders; the threshold is the protocol's reading of these comparisons. The margin is deliberate: a node knows neither its peers' uplinks nor how much of its own it can count on, towards the network or towards any one peer. And latency is not the only stake: the source also chooses how much of the distribution it does itself, and how soon its link is free for its other work. ### The static window (14): why fixed, and what it must know The window keeps each node's backlog above the transport: a fixed number of chunks in flight, sized from the node's own uplink and a typical round trip, the rest held in its own queues, where cancel, rarest-first and projection still apply. Why a fixed window rather than an adaptive one? We tried adaptive ones. The controllers we tried, which adjust the window from acknowledgements, could not converge within a single message: a whole payload is shorter than one bandwidth-delay product on a fast link. A configured window is the form that deploys, and a node usually knows its uplink. It need not know it exactly: a window sized for twice the real uplink costs about a tenth in the tail. The window matters more the thinner the links. Without it (and without card 16's guard, which our implementation ties to it), tier 4's tail lengthens faster as the uplinks shrink, the source's uplink filling with answers, and on 10 Mbps uplinks most nodes missed 3 s in a few payloads. With it, every node is inside 3 s down to 10 Mbps (Figure 3, left). The source stripes in these runs, as in every tier-4 cell we plot, which card 13 would not have a home builder do. ### Paced gossip (15), and what the whole message gains from local rules Gossipsub announces new ids at each heartbeat to a sample of peers outside the mesh, all at once. Those peers ask the source for what they lack, and the source's uplink, busy with its first copies, now also carries answers. This is one of the two reasons whole-message gossip is so slow with a home builder; the other is the parallel start, eight copies sharing one uplink. At every heartbeat the source announces the payload, stock gossipsub asks every announcer, and each answer is the whole 746 KB. **The source answers its own gossip**: in whole-message diffusion it uploads about thirty copies of the payload as answers, alongside its mesh pushes, on a 50 Mbps link. This also says what the whole message could gain without segmentation, with local rules. We measured two of them on today's protocol: paced gossip itself, and a cap on the copies a node has in flight (card 14's window counting whole messages, with the receiver's "don't want", gossipsub's IDONTWANT, as the acknowledgement, which stock peers do not send to the sender). Pacing the gossip takes the all-home network's whole-message tail from 6.3 to 4.6 s and a home builder's on the mixed-bandwidth network from 4.2 to 2.7 s; the cap, at three copies in flight, takes the all-home network's to 2.7 s, where the builder's uplink was the whole problem, and the home builder's on the mixed-bandwidth network to 2.3 s: less there, since fast nodes already carry the load, but it removes the slow cases, where paced gossip alone ran to twice that. With a datacenter builder neither rule changes anything: a 1 Gbps builder's uplink was never the problem. A cap of one copy in flight is a disaster, and two copies are too few once some peers never acknowledge, which is why three. With one, the uplink idles through every acknowledgement. So the fair reference for the ladder is not quite the 6.3 s of stock gossip: with paced gossip, which is local, and the cap, whose acknowledgement is gossipsub's own "don't want" returned to the sender as well, a behaviour its peers must share, a client can get to about twice tier 1's time without a new message type (Table 1's second row). What these rules did not get lies below: the start still shares the uplink between whole copies, and every hop still stores before it forwards. Segmentation is what removes both. Figure 2 follows that load up the ladder. Segmentation makes each answer small, and the request discipline stops duplicate asks. The state cards then push less, so more nodes ask, and early on the source holds most of what they ask for: its answers grow again. The window turns that around: with the source's backlog held in its own queue, where cancel still acts, its answers fall to a sixth. **Paced gossip** spreads the heartbeat's announcements over short ticks, one peer at a time, so fewer peers ask the source before a push reaches them. And pushing first to the peers furthest behind (§4) serves the ones that would otherwise ask. By tier 4 the source's answers are, in the all-home network, a couple of hundred times smaller than in the whole message.  *Figure 2. What the source uploads as answers to requests, per rung of Figure 1's ladder, in copies of the payload compressed whole (log scale), in the all-home network (blue) and on the mixed-bandwidth network with a datacenter builder (red). Bars: the median over the simulated networks; whiskers: the middle half of them. Card 17 has no all-home bar, as in Figure 1.* In the all-home network, paced gossip cut the source's answers by a third when it joined, at little cost in time. In tier 4 as it stands, the window and furthest behind first do most of that job, and it stays for a small saving in bytes in the all-home network. ### Who carries the load With a 1 Gbps builder the picture changes. The source has uplink to spare and answers many requests from it, uploading many copies of the payload, most of them as answers (Figure 2, red). It does not have to. **A capped mode**, in which the source pushes its first copies and announces to nobody, cuts its upload sharply at the same latency; the other nodes then serve the requests instead. We treat this as a mode the source chooses, not a property of the protocol. ## 4. Aiming the pushes ### Furthest behind first (16): what it buys, and what it exposes With bitmaps, a node knows how many chunks of the payload each mesh peer holds, counting the pushes it has already queued to it, and can push to the peers furthest behind. Among tier 4's cards it is the one that shortens the tail at both builders: without it the tail is noticeably longer in the all-home network and with a datacenter builder. It also opens an attack. The rule trusts what each peer says about itself, and a peer that under-reports 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. Against it the plain rule does worse than having no rule. So tier 4 uses **a safer form**: pick at random among the lower half of the ranking rather than the single peer furthest behind, and demote a peer that has taken pushes but reported nothing after a grace period. An under-reporter then no longer wins every contested push; it is drawn with bounded probability within the lower half. That is not a guaranteed fair share, but the tailored under-reporter costs about what an ordinary withholder does. The price is a few percent on a clean network, somewhat more against ordinary withholders; the rule still beats not aiming at all. ### Pushing by uplink (17) With datacenter nodes in the network, the fast ones answered many requests from their spare uplink while the home nodes pushed. Giving **forwarding nodes with a fast uplink a push budget of six** instead of two turns those answers into pushes, a round trip earlier. It shortens both the median and the tail, for somewhat more bytes, and helps more under withholding. Beyond six, the small further gain in the median came with a worse tail and more bytes. The all-home network has no such nodes, and nothing changes there. ## 5. Tier 4 against the earlier tiers | | | all-home network | | home builder, mixed bandwidth | | datacenter builder, mixed bandwidth | | |---|---|---|---|---|---|---|---| | | | p99 | copies | p99 | copies | p99 | copies | | whole message | stock gossipsub | 6.3 s | 4.4 | 4.2 s | 3.4 | 1.8 s | 3.4 | | whole message | paced gossip, three copies in flight (§3) | 2.7 s | 3.6 | 2.3 s | 3.2 | 1.8 s | 3.4 | | tier 1 | chunks, batch publishing | 1.26 s | 6.5 | 1.03 s | 6.2 | 0.87 s | 5.7 | | tier 2 | announce, the phase, disciplined pulls | 0.87 s | 2.0 | 0.83 s | 2.0 | 0.73 s | 2.0 | | tier 3 | the erasure code | 0.71 s | 2.5 | 0.66 s | 2.6 | 0.55 s | 2.8 | | **tier 4** | **state, the source, aimed pushes** | **0.63 s** | **1.7** | **0.58 s** | **2.1** | **0.41 s** | **2.1** | *Table 1. Warm receiver p99 and bytes received per node by the network's completion, 500 nodes, 1 MiB. The tier rows are Figure 1's large points; the second row is §3's whole message with paced gossip and an acknowledged cap on copies in flight.* Against the previous post's tiers, tier 4 is faster at both builders and lighter than tier 3; in the all-home network it is the lightest of all; with datacenter nodes it receives a little more than tier 2. Against variant C with the code, the fastest mapping at a datacenter builder last time, it is faster at both too, and receives fewer bytes: the regime the previous post gave to C belongs to the single topic now. With a home builder and a fifth of the nodes in datacenters, tiers 2 to 4 stay close to their all-home times, since the builder's 50 Mbps uplink still bounds the first hop: at tier 4, a 1 Gbps builder without the datacenter nodes recovers most of the gain a datacenter builder sees on the mixed-bandwidth network. The whole message and tier 1 get about half way, because the fast nodes carry much of their load. We also checked whether every card still earns its place, by removing one at a time from tier 4 (the table is in the [card reference](https://notes.ethereum.org/@cskiraly/segmented-stack-cards#Removing-one-card-at-a-time)). Most carry weight somewhere: in time at one of the two builders, or in bytes. A few do little on a clean network. Rarest at pop stays for the withholding case, where it buys a little of the tail. Paced gossip did its job when it joined; later cards now do most of it, and it stays for a few percent of bytes in the all-home network. ## 6. Under stress A fast protocol on a clean network is the easy part. We ran tier 4 through the stresses the previous posts used, and a few more.  *Figure 3. Tier 4 under stress in the all-home network, warm receiver p99. Left: every node's uplink from 10 to 50 Mbps (downlinks 100 Mbps, 20 at 10), with and without the window (the runs without it also run without card 16's guard, and with the source striping, as the plotted stack does at every builder); the ring marks the worst payload without the window at 10 Mbps, where most nodes missed the 3 s budget. Right: the share of withholding nodes, from none to half the network, for withholders that announce and never answer, and for withholders that also forward nothing (silent), send no HAVE or acknowledgement (mute), leave chunks out of their HAVE to draw pushes (tailored under-reporters), or send no acknowledgements. Points: the median over the simulated networks; bars: their range.* **Every node receives every warm payload within 3 s in every stress we ran.** The tail moves, and how much depends on what is attacked: - **Loss** of 5 % of the data deliveries, or separately of 5 % of the requests, costs almost nothing. Every chunk has several ways to arrive. - **Withholders**, nodes that announce but never answer, lengthen the tail steadily with their share, as in the previous post; with half the network withholding the tail is about 1 s, well inside the budget. Withholders that also never acknowledge, and so hold window slots until they time out, cost little more, about a tenth at half the network. - **Silent nodes**, which also forward nothing, cost more than withholders at the same share, and the more so the larger their share, since they remove pushes as well as answers: at half the network, about a quarter more. - **Mute withholders**, which also send no HAVE and no acknowledgement, sit between the two: their peers cannot cancel what they push to them, nor count them as holders. - **Tailored under-reporters**, which leave out of their HAVE chunks they hold so as to draw pushes, cost no more than plain withholders at any share we ran. Against the plain form of card 16 the same attacker did worse than no rule at all (§4); these curves are its safer form. - **A source that omits chunks**, as many as the code can spare, is covered by the code, at a longer tail. - **Thin links** are where the window pays: on 10 Mbps uplinks tier 4 is about three times slower than at 50 and still inside the 3 s budget (Figure 3, left). - **Uneven uplinks**, the same mean spread widely, cost more in the tail than the median: the slowest nodes finish last whatever the protocol does. Tier 4 shortens their wait by about a tenth against tier 3 with the state cards. - **Payload size** from 128 KiB to 2 MiB stays inside the budget, the smaller sizes with the larger push budget the card reference gives card 11. ## 7. What did not work Some ideas looked promising and did not survive measurement. Each result holds under the conditions we ran; we say what would reopen it. - **An adaptive window.** Covered in §3: at these message sizes the controllers we tried had no time to converge. A payload long enough to span many round trips would reopen it. - **Estimating the link's capacity.** Five forms failed to recover a known 50 Mbps: transport bytes overstate delivery, acknowledgements under-read nodes that never saturate, an ack carries the reverse path's queue, bursts this short never reach a plateau, and a forward-delay stamp reads the transport's own buffers as queue. A delivery counter at the uplink, or a probe outside gossip, might work. - **A lower-rate code.** More parity helps only where the source stripes wide, and there it bought a few percent of the tail for about a fifth more bytes, counting every byte to the 3 s mark, the parity chunks that arrive after a node completes included. It stays an option for a builder that would trade bytes for time. - **Keeping chunk paths apart.** Variant C's other half, independent paths per chunk, did not show as something tier 4 lacks: C with the code, which keeps them, stayed behind tier 4 in every network we ran. We read it as the code and rarest-first attacking the same problem, the last chunk a node needs, while phase forwarding already gives each chunk its own push tree inside the mesh. Uneven uplinks, where separate paths might have helped, did not change that: with speeds spread widely, one topic per chunk with the code fell further behind tier 4, not closer. The spread was random per node; real networks can also have shared regional bottlenecks, whereas this sweep varies uplinks independently.