EIP-8411: what segmented payload diffusion is made of

Дата публикации: 17-09-2026 03:41:53

This post continues Wen fast payload broadcast?, taking its recommended segmented diffusion policy apart, describing each protocol change and measuring its effect.
TL;DR
Payload propagation is fast enough today largely because of small blocks, and because datacenter builders and high-bandwidth nodes carry it.
EIP-8411 proposes faster execution payload propagation via message segmentation, letting pieces pipeline through the network instead of store-and-forward at every hop.
A Merkle tree commitment in the bid is the only consensus change needed; every segment is verified against it before it is forwarded.
With segmentation and batch publishing, median delivery falls below a second in our baseline home-builder simulation even without datacenter nodes, from 5 s for the whole payload.
A prototype is presented, providing three protocol implementation “tiers”, each a prefix of the next, with increasing complexity and performance:
tier 1: segmentation with batch publishing. The bare minimum: it cuts the 1 MiB median from 5 s to under a second and the tail from 6 s to just over 1 s, for a third more bytes than today.
tier 2: announce instead of pushing to everyone, with a push width that follows the payload size, and disciplined pulls. Local library policy only; less than half of tier 1’s bytes, and inside the 3 s budget through 2 MiB.
tier 3: tier 2 over a rate-½ erasure code of the compressed payload, with stop-pull. It is the fastest, has the lowest tail at every size, and shrugs off withholding; parity doubles what leaves the source, and the code’s commitment joins the bid.
0. Where the first post left off
Whole-payload gossip is fast enough on today’s mainnet mostly because datacenter builders and high-bandwidth nodes carry it. Our previous post showed that cutting the payload into smaller pieces removes that dependence. In this post we dive into the technical details of making segmentation even faster, while eliminating most of the duplicate traffic today’s gossipsub suffers from.
1. Segment first
Figure 1. Whole message as today (leftmost group) and the six segmented protocol variants in the first post’s three scenarios: home builder with no high-bandwidth nodes, home builder with 20% of nodes in datacenters, datacenter builder with 20% of nodes in datacenters. Bars: receiver p99 (±1 s.d. across seeds); ticks: receiver p50; dashed line: the 3 s budget.
Figure 1 compares the latency of whole-message gossipsub with six segmented protocol variants, under three networking scenarios. Variants represent three ways of mapping segments to gossipsub:
variant A uses a single topic as today, but with segmented messages;
B maps segments to the partial messages extension;
C follows the DAS design, mapping each segment to a separate topic.
Each of these can accommodate erasure coding, and the figure shows the performance of these combinations too. For B the code pays only when each part travels in its own frame; bundled per peer, as the extension sends by default, coded B is slower than B alone in every scenario (measured but not shown here).
Every segmented protocol variant beats whole-message gossip by a large margin. At the baseline, whole message reaches half the nodes in 5 s and the last of them in 6; A-tuned takes 0.75 s and 1 s, while each node receives 1.5 copies of the payload instead of 4.6. Our first post recommends variant A: it is simpler to introduce than B and C, yet it provides most if not all of the possible performance gains. However, the variant A-tuned we show here is not just segmentation alone. It also includes other networking techniques (some of which we already introduced in previous posts). In what follows we detail these techniques and their effects one by one.
How to read the numbers. Every number comes from a simulation harness that runs the real Prysm and go-libp2p-pubsub code over a simulated network on a virtual clock. The code implements the discussed changes, Merkle commitment, per-piece proofs, structured message IDs, and Reed-Solomon erasure coding included; the one thing the simulation stands in for is the bid: with no blocks in the simulated slot, a node admits the first segment group it sees as that slot’s commitment. The gossipsub wire format, mesh construction, degree and scoring are unchanged; the forwarding and request policies are options in a fork of the library.
The baseline scenario is 500 nodes (for faster simulations), a degree-70 neighbourhood as in Prysm, simulated geographic latency, 50 Mbps up and 100 Mbps down per node, and a 1 MiB payload from a home builder, with no high-bandwidth nodes assumed. A seed draws the network — who connects to whom, which links are slow — so configurations compared at the same seed see the same network; every measurement uses ten seeds.
A point on a figure is the median across seeds of one per-node statistic, with ±1 standard deviation bars. Receiver p50 is the time by which half the nodes hold the payload: the decisive node for the PTC’s head count on the happy path, without adversaries or byzantine faults. Receiver p99 is the tail, relevant to safety margins and to uses where most nodes must receive. Complete by 3 s is the share of receivers inside the slot’s 3 s PTC budget. Bytes are everything a node received for the payload, data and control together, expressed in copies of the payload as it would travel compressed as one message, 746 KB at 1 MiB, so that a segmentation’s compression loss and a code’s incompressible parity both count; the figures that plot the two separately say so.
2. What variant A is made of
Figure 2. Successive changes stacked on stock gossipsub, at various payload sizes. Top left: p50 latency; bottom left: p99. Top right: all bytes received per node, data and control, as a multiple of the payload’s compressed size; bottom right: the control bytes alone.
2.1 The ladder
Variant A is not one change but a short ladder of incremental changes, and Figure 2 climbs it at various payload sizes. Each rung does one thing. The bulk of the delay advantage comes from segmentation alone, and that is the main message of this post: the commitment and the segmentation, by themselves, put us far ahead of where we are today. The other rungs mostly remove duplicates — useful, but second to the timing gain — and add smaller latency improvements of their own.
Whole message: the reference
Stock gossipsub v1.2 carries the payload as one large message. A receiver first tells its mesh peers that it has it (IDONTWANT), then validates it, then forwards it to every mesh peer that has not said IDONTWANT in the meantime. At the next heartbeat it announces the id to a sample of its other peers, and a node that lacks an announced id asks every peer that announced it.
Two things follow from sending the whole payload as a single message. Nothing can be forwarded before the whole payload has arrived and been checked, so each hop adds a large delay (the so-called store-and-forward delay). And a mesh of eight sends eight copies in parallel, sharing the uplink bottleneck and slowing down each send to an eighth of the link’s speed. Even worse, if a heartbeat happens in the meantime, announcements can bring several more IWANT requests and thus parallel copies in through the pull path. This is the performance baseline we measure everything else against.
Segmentation
Segmentation aims to eliminate the store-and-forward delay. The builder cuts the payload into fixed-size pieces, commits to them with a Merkle root in its bid, and publishes each piece with its proof as an ordinary gossip message. It needs structured message ids similar to FullDAS: an id that carries the group’s Merkle root and the piece’s index, followed by the usual content hash, 56 bytes against gossipsub’s 20 (Part 1’s layout without the slot and block root, which the commitment makes redundant). The root and the index are there for two reasons:
a receiver can check the segment against the commitment it got with the block, and relay it,
an IHAVE announcement carries enough structure in the id to be matched to the bid before a request is granted.
A piece that arrives before its bid waits in a bounded cache and is not relayed until the bid installs.
This is pipelining, and it is most of the latency gain in the whole post. A node starts relaying after one piece-time instead of one payload-time, and its uplink serves different pieces to different peers at the same time. The price is bytes and control traffic: a full-mesh push of 32 pieces delivers more duplicate copies than one push of the whole, and 32 ids mean 32 times the announcements. Some later rungs buy that price back (and some more).
Batch publishing
Once the payload is segmented, the first bottleneck is the source’s own uplink. Publishing the pieces one after another, as the API does today, sends every copy of piece 1 — one to each of the eight mesh peers — before the first copy of piece 2, so the last piece leaves the source only after nearly the whole payload has gone out eight times. The pipeline that segmentation created is starved at its first hop.
Batch publishing interleaves: the publisher sends the first copy of every piece, each to a different mesh peer, before the second copy of any. We proposed it for segmented diffusion in DAS; it equally applies here, and it is already upstream in go-libp2p-pubsub.
The whole payload leaves the source once within one payload-time, and every piece begins its diffusion from a different neighbour. Bytes are unchanged and nothing is given up; it needs no protocol change, only an API that publishes several messages at once.
Announce instead of push
Segmentation’s price is duplicates. Full-mesh push sends every piece to every mesh peer that has not yet said it has it, and with 32 pieces racing through the mesh, most of those copies reach nodes that already hold the piece or are about to: Figure 2’s byte panel shows six copies of the payload arriving at every node. Gossipsub already has the machinery to offer a message instead of sending it — IHAVE and IWANT — but only uses it at the heartbeat, for peers outside the mesh.
According to the push-pull idea of PPPT, a node that receives a message (a segment here) pushes it whole to at most r of its mesh peers — chosen among those it does not already know to hold it — and immediately announces the id to the rest, who ask for it if they still need it. The same trade (fewer eager copies, the rest pulled or suppressed) runs through the Vac/nim-libp2p work on staggering and fragmentation and PREAMBLE and IMRECEIVING, and through Raul’s ethp2p. We use r = 2 in this rung.
The result is fewer duplicates: a third of the bytes off the full-mesh push, and no slower — the uplink stops queueing copies that would have been refused, which pays for the round trip that a pulled piece now costs. Both ways of losing a piece stay covered: a lost request by the push, a lost push by the announce-and-ask path. The cost is on the pull side: every pulled piece takes a round trip, and there are now many more announcements to answer, which is what we will discuss in Section 2.2.
The phase shift
A fixed push width is blind to how far a piece has spread. Early in a piece’s life a push is almost certainly useful; late, when most of the mesh already holds it, a push is almost certainly a duplicate. A node has a free local signal of which case it is in: the IDONTWANTs it has heard for that piece.
Each IDONTWANT indicates that the piece is in an already diffused state, and a push would result in a duplicate with higher probability. So every IDONTWANT lowers the node’s remaining push budget for that piece, and a node that receives the piece late only announces it — the IDONTWANT-count rule from the PPPT discussion.
The result is another ~20% of the bytes off: the copies late forwarders would have pushed into a mesh that mostly holds the piece already. When the uplinks are idle — below about 640 KiB in our scenario — this trades some latency for fewer duplicates; above that it has only upside, the same time for fewer bytes.
2.2 Disciplined pulls
The rungs above change what a node pushes. Disciplined pulls change what it asks for.
Stock gossipsub’s pull is based on IHAVEs emitted to non-mesh peers at heartbeats, and IWANTs requesting missing messages (segments in our case). Some implementations, including the go-libp2p one, simply send IWANTs to every announcer, whether or not they were already asking someone else for the same segment, generating duplicates. In stock gossipsub, where IHAVEs are limited to heartbeat gossip, the effect is limited. But once we start using announce instead of push to reduce duplicates, the number of IHAVEs grows, and the duplicates we eliminated by not pushing return through the back door. Hence we need to control pulls better.
The solution looks simple on the surface: ask only the first announcer. This, however, has two fundamental issues. First, in networking nothing works without a timeout. Something must happen when the first IWANT is not answered. We should move on to another announcer sending a new IWANT (the first could still deliver after the timeout; that is fine). Second, an IWANT with a timeout means we are waiting on one node, which is an ideal surface for a capture attack. It is easy to see why the naive “ask everyone” policy is free from these issues, but if we want to remove duplicates, we need a better mechanism, and we call this disciplined pulls:
keep track of peers offering an id in our offer table
send at most k (1 by default) requests per id at first;
after a timeout (200 ms), move on, sending a new request instead of the expired one;
our timed-out request might still be answered late, and we handle this with a second, larger timeout (400 ms): if the node still delivers, we take it; if not, we treat it as a broken promise and park that peer for 30 s.
The two timeouts allow fast recovery from a potential loss, while bounding a given peer’s capability to capture. We use fixed timeouts in this post, but these can also easily be tuned per peer.
Figure 3. Disciplined pulls against payload size, 500 nodes: the phase shift rung of Figure 2, then A-tuned. Panels as in Figure 2.
Figure 3 shows that disciplined pull roughly halves byte utilization at every size, reaching 1.5 payload copies per node at 1 MiB, control traffic included. It slightly slows down diffusion of smaller payloads, where the request round trip dominates and an unasked second copy would have arrived. It roughly ties from 512 to 896 KiB and leads above, where bandwidth becomes a bottleneck, reducing both latency statistics by a quarter at 2 MiB.
At the clean 1 MiB base the 200 ms discipline alone takes received bytes from 3.3 payload copies to 1.5 at an unchanged p99, and the offer table, move-on and park then change neither statistic. They are insurance: they cost nothing when nothing goes wrong.
We call the resulting policy, combining all the techniques above, A-tuned. By limiting pulls, we are still allowing peers to hold up a receiver: each id now waits on one selected announcer and remembers the alternatives. Section 3 measures what that dependence costs on thin links and what it exposes under withholding.
3. Where the changes might bite
So far the networks have been clean and undisturbed, with only payload size and datacenter placement varied. Now we add stress: thin links, where duplicates cost time, and withholding, where requests become capture. Figure 4 has both, with A-tuned as the top rung.
Figure 4. The ladder under stress, 500 nodes, 1 MiB (±1 s.d. across seeds): whole message, then the rungs of Figure 2 up to A-tuned. Left: receiver p50 against residual uplink, 10–200 Mbps, downlink 2×; dashed line: the 3 s budget. Right: receiver p99 against the share of nodes withholding, 0–70%. A number beside a point counts the honest receivers still incomplete when the run ends (“strands”). Withholders forward and announce like every other node but never answer a request.
3.1 Thin links
When the uplink is narrow, bytes are time, and duplicate reduction pays off. Every rung that saves bytes is faster on a thin link. At 15 Mbps whole message would take 28 s on the median, segmentation alone 12, batch publishing 4.3, announcing 3.4, the phase shift 3.2 and A-tuned 2.6.
Above 100 Mbps IWANT discipline (and its baseline announce instead of push) has some latency cost. It is the request round trip that every pulled piece costs, which no amount of bandwidth removes. One might argue it is still a worthwhile compromise, leaving more space on the wire for other traffic.
3.2 Adversaries
The withholder of Figure 4 forwards and announces like every other node and never answers a request. This is the cheap attack on a pull path. Refusing costs the attacker nothing, and because its pushes into the mesh stay honest, gossipsub’s peer scoring never sees it; the one stock defence, the penalty for an unanswered request, fires 3 s later, after the slot budget is gone. An overloaded honest peer whose outbound queue drops responses looks the same. Doses above 30% are there for the shape, not as a threat model.
The discipline trades withholding exposure for bytes.
The push-heavy rungs are flat across every dose because they never use the attacked channel: segmentation alone and batch publishing barely request.
The announcing rungs ask every announcer and pay only little: the phase shift’s p99 goes from 1.05 s clean to 2.1 s at 70%.
A-tuned asks one announcer and waits, so it starts best at 0.99 s but climbs steadily with withholder count. However, latency is still under control, well below our baseline, and it can further be reduced with parameter tuning (two requests allowed in parallel, or a lower move-on timeout).
Surprisingly, withholding even shortens whole message’s tail, from 5.9 to 4.2 s across the sweep. The refused requests were for duplicate whole-payload copies, and those copies were clogging uplinks. The gain comes from less traffic, not from fewer peers.
We also tried two harsher withholding models:
relays that also forward nothing they receive,
withholders that also claim, through IDONTWANT, to already hold every id they hear, pushing more of the traffic onto the pull path.
At 30% withholding A-tuned survives these too.
4. Treating the tail of the distribution: erasure coding
Among N peers that need to receive, there will always be a slowest. Among K segments that are diffused, there will always be one arriving last. In this section we discuss techniques to cut the tail of the delivery latency distribution.
Since segments diffuse independently — although racing each other — in the network, the slowest will matter. With a largely heterogeneous network, one segment can get unlucky (or attacked), hindering the completion time for every node. There are a few known techniques to fight this:
balancing the diffusion of segments, one example being BitTorrent’s famous rarest-first strategy;
triggering extra recovery efforts towards the end of the diffusion (the tail hedge);
using coding (e.g. Reed-Solomon erasure coding, random linear network coding) to change the game.
In what follows we focus on erasure coding, noting that variants of balancing and tail hedging can be used together with it and are implemented in our prototype too. Measured but not shown here, asking three announcers at once for the last four pieces trims A-tuned’s median by ~10% and leaves fewer receivers stranded under withholding, but it cannot replace a piece the source never sent.
What makes erasure coding stand out is its robustness. While the other techniques have to focus on ensuring no late or withheld segment, erasure coding can focus on the first K, and let N-K slip, effectively cutting the tail of the distribution. Even better, since any sufficient subset rebuilds the payload, each single node can focus on its own fastest K. Precedents include FullDAS, RLNC block propagation, and ethp2p.
4.1 Erasure coding and the vector commitment
Importantly, the builder has to commit to all N erasure-coded segments and the bid should contain this; otherwise, spamming would be possible. Whether code consistency needs a per-segment proof also needs clarification. In sampled diffusion (DAS), we need samplers to be able to verify that a single sample is consistent with the code (a parity segment is really an extension of the data); otherwise, the sampling guarantee breaks. Even there, any node that can get at least K segments can verify the encoding and attribute blame to the builder, but most nodes don’t have such high custody. Here all nodes need K segments, so any node can verify the honesty of the builder, and refuse anything inconsistent, leading to economic loss for the builder itself, so segment-level code consistency proofs are not needed.
4.2 Erasure coding and the ladder
Our Erasure coding variant builds on A-tuned, and to simplify our discussion here we only illustrate the K->2K case using a rate-½ Reed–Solomon code.
It also implements Stop-pull as a local request policy: once a node holds K segments, decline further announcements for that payload, though pushes already in flight still land. Near completion it requests every segment it lacks, so its last segment is whichever arrives K-th. These alternative requests are not duplicates: every segment that arrives counts. They also tolerate segments the source never sent.
Compress first. Gossipsub compresses every message it carries. Payload data is compressible, while erasure coding parity is high entropy, so it is not. Thus, if we segment first and gossipsub compresses segment-by-segment after, segment sizes can become largely imbalanced. Compress the payload first and code the compressed bytes, and every segment has the same wire size, none of them compressible further. The commitment then covers the erasure coding extension of the compressed bytes, and decompression is deterministic. A canonical encoding might still be beneficial to tighten the rules, but we leave this discussion for later.
Figure 5 shows both orders; the coded A of the other figures cuts first.
Figure 5. The code against payload size, 500 nodes: the phase shift rung, A-tuned, and coded A with stop-pull, which ends requests once K segments arrive. The code has K data and K parity segments: 32+32 at 1 MiB with 32 KiB pieces; counts follow payload size. Dashed: the code over the payload compressed first. Panels as in Figure 2.
What the code buys, and what it costs. The code sits at or under A-tuned on both statistics at every size. The gain reaches p50, not only p99, because completion is every node’s last segment, and the code makes that the K-th of 2K rather than the last of K: every node’s wait shortens, and the nodes that waited longest for a particular segment gain most. The code does not replace the disciplined pulls; it builds on them: without them the extra segments become extra copies at every node and the code is slower than A-tuned (measured but not shown here). The price is bytes. Receivers take about 50% more than A-tuned, and the publisher sends more than twice as much, since parity doubles what leaves the source. As the payload grows the receivers’ share of that overhead shrinks while the publisher’s grows. Compressing first cuts both, and is the fastest line in Figure 5.
Figure 6. Figure 4 with the code added: the ladder under stress, 500 nodes, 1 MiB (±1 s.d. across seeds), whole message, the rungs up to A-tuned, and coded A cut first and, dashed, compress first. Left: receiver p50 against residual uplink, 10–200 Mbps, downlink 2×. Right: receiver p99 against the share of nodes withholding, 0–70%. Grey dashed line: the 3 s budget; worst-seed strand counts and hollow markers as in Figure 4. Withholders forward and announce like every other node but never answer a request.
The code buys back what the discipline gave up. Section 3 showed the trade: disciplined pulls cut A-tuned’s bytes to well under half of the announcing rungs’, and in exchange its tail climbs with the withholder count and its median stops improving above 100 Mbps, because one request per id waits for one peer. The undisciplined rungs never had either problem; they pay for that with three to four copies of the payload at every node. Figure 6 puts the code beside them. Under withholding it takes A-tuned’s tail back to where the announcing rungs sit, at every dose and stranding nobody, and with four of the 32 original segments never sent it still completes everyone at the clean p99. On fat links it recovers their speed too, finishing with whichever K segments arrive first instead of waiting for particular ones. It does this at 2.1 copies per node, between A-tuned’s 1.4 and the announcing rungs’ 3 to 4. On thin links the bytes win: at 30 Mbps and below the cut-first code is slower than A-tuned, while compressing first, which puts fewer bytes on the wire, stays ahead of it down to 10 Mbps. The code is insurance for the tail, paid for in bandwidth, and it pays off where bandwidth is not the constraint.
5. The segment size
Figure 7. Segment size at the headline base: 500 nodes, 1 MiB. Panels show receiver p50 and p99 (±1 s.d. across seeds), encoded data received per node in compressed-payload copies, and control bytes received per node. Lines: A-tuned and coded A at 8, 16, 32 and 64 KiB; dashed: compression before coding. Coding’s segment count follows the segment size.
Our choice of 32 KiB for the reference 1 MiB payload scenario was arbitrary. The A family reaches its floor at 16 KiB. Moving from 32 to 16 KiB cuts both latency statistics by about a tenth, for A-tuned and coded A alike, with slightly fewer data bytes and double the control bytes. Going to 8 KiB adds no speed and doubles control bytes again; 64 KiB segments cost 15–40% over 32 KiB. The ordering holds beyond the base: for A-tuned, 16 KiB beats 32 KiB on both statistics at every payload size, on thin links down to 10 Mbps and under every withholding dose (measured but not shown here). So a 16 KiB segment for A is better than 32 KiB, with some caveats:
it means more signaling load, and more segment verifications (although cheap with Merkle proofs);
it also means more context switching and thus processing load.
Fixed segment size behaves better than fixed segment count. Figure 2 climbs the ladder keeping segment size fixed at 32 KiB, so the count follows the payload: four segments at 128 KiB, sixty-four at 2 MiB. Fixing the segment count at 32 instead makes the segment follow the payload, from 4 KiB at 128 KiB to 64 KiB at 2 MiB. Results from our simulations (not shown here) show that fixing the segment size is a better choice.
6. The skeptic’s questions
“Easy win for 500 nodes, but mainnet has more than 10000. How about that?” We were exploring the design space with 500 nodes simply to make the state space exploration with 10 seeds feasible. If p2p networks do one thing very well, that’s scale. Figure 8 shows four rungs of the ladder from 250 to 4000 nodes. The ordering is the same at every size, and scaling is as the hop count predicts: each doubling of the network adds about the same delay. A doubling adds about 0.4 s to whole message’s median, 0.04 s to the phase shift’s and A-tuned’s, and 0.02 s to coded A’s. Segmentation keeps the logarithmic scaling rule, while shrinking the per-hop delay that sets the increment: a hop forwards a segment instead of the whole payload, and the code finishes on whichever segments arrive first, so the slower paths never set its time.
Figure 8. Network size at 1 MiB, 250 to 4000 nodes: whole message, the phase shift, A-tuned and coded A, receiver p50 and p99 (±1 s.d. across seeds). Hollow markers: the median seed misses the 3 s budget; the numbers give whole message’s share complete by 3 s.
“Why libp2p and gossipsub, when ethp2p, waggle and other protocols are being designed?” There is a confusion between the algorithmic side of a protocol, the composition of the stack, and the API. This post is about the algorithmic side, and it is mapped onto libp2p and gossipsub to show that even there it is possible. Whether the API changes and whether the stack is composed differently are almost orthogonal questions. Almost, because an API change can open possibilities and move responsibilities, and lead to a conceptually cleaner design; and almost, because a stack that embraces QUIC to its full potential opens possibilities this post does not rely on.
“You count bytes but not messages. Doesn’t that flatter the small pieces?” The harness normally charges no CPU, so 16 KiB pieces and 64 coded segments look free apart from their control bytes. Charging 300 µs per received data message, paired against the uncharged twin at ten seeds, moves A-tuned’s median by 7 ms at 1 MiB and its p99 by 12 to 26 ms; A at 16 KiB moves by about 1 ms on the median, and coded A not measurably. The ordering of A’s rungs is unchanged. Control-message processing remains uncharged.
7. Closing and Recommendations
Segmentation removes the whole-payload store-and-forward latency at every hop and gets a 1 MiB payload comfortably inside the 3 s budget without relying on datacenter uplinks. Whichever variant is chosen, segmentation
helps decentralization;
enables shorter slot times; and/or
provides more headroom for post-quantum signatures and objects.
The technologies discussed here also provide an ideal baseline for other large message use cases (larger consensus blocks, ZK proofs, etc.).
Figure 9 highlights three of the many variants we discussed: potential stopping points that we recommend based on this study and implementation considerations.
Figure 9. Where the ladder ends, 500 nodes, ten seeds per point. Solid: today’s whole message and the three tiers, all on 16 KiB segments: segmentation with batch publishing, size-adaptive A, and size-adaptive A over the compress-first RS erasure code. Dashed: the two references each tier is priced against, A-tuned at 16 KiB and the compress-first RS code alone at 32 KiB. Panels as in Figure 2.
Tier 1, the bare minimum: the commitment in the bid, segmentation, and batch publishing. The first two are the spec change of section 2: the piece format, the Merkle root in the bid, structured ids and the relay rule. Batch publishing comes along in our recommendation simply because it is a local publisher policy with no protocol change, and it is already upstream in most libp2p implementations and used for DAS.
With 16 KiB segments this tier cuts the 1 MiB median from 5 s to under a second and the tail from 6 s to just over 1 s, and its tail stays flat under withholding because it barely requests. It buys that time with bytes: a node receives a third more than today, and control traffic grows from a few kilobytes per payload to over a hundred at 1 MiB, since it scales with the number of ids. On thin links it is the slowest of the segmented arms and still several times faster than today. It stays inside the budget up to 2 MiB, but with little room, a tail at 2.2 s, and control traffic past half a megabyte per node. Figure 6 measured this rung under stress with 32 KiB segments; Figure 9 draws it at 16 KiB.
Tier 2, the next stopping point: A-tuned at 16 KiB, with a push width that follows the payload size. It adds the request policy of section 2: announcing instead of pushing to everyone, the phase shift, and disciplined pulls. All of it is local to the gossipsub library; nothing changes on the wire or in the spec beyond tier 1. The one knob that follows the payload size is how many mesh peers a node pushes each segment to: more for small payloads, where uplinks are idle and a pull’s round trip is what costs time; two above 1 MiB, where duplicates fill the links.
This tier is about bytes. For small payloads tier 1 is slightly faster, but this tier receives less than half the bytes. For large payloads it is also the faster one: tier 1’s duplicates and announcements grow with the payload and push its latency toward the budget, while this tier stays near A-tuned’s byte floor and well inside the budget through 2 MiB. Disciplined pulls are what a withholder can lean on; under 30% withholding it still completes everyone and keeps its lead over A-tuned (measured but not shown here).
Tier 3, the full stack: tier 2 over the compress-first erasure code. The payload is compressed, coded at rate ½ and cut into 16 KiB segments. The push and pull rules are tier 2’s, plus stop-pull: a node stops asking once it holds enough segments to rebuild. This is a spec change again, the code and its commitment in the bid; stop-pull is local policy.
This tier is about the tail. A node finishes on whichever segments arrive first, so no single slow or withheld segment holds anyone up. It is the fastest of the three at every size, it has the lowest tail, and it is the one that shrugs off withholding: everyone completes and the tail moves least of anything we measured (measured but not shown here). The price is bandwidth: parity doubles what leaves the source, receivers take more than in tier 2, and with twice as many segment ids its control traffic runs level with tier 2’s, and both sit above tier 1’s up to 1 MiB.
Nothing here touches gossipsub’s wire format, mesh construction, degree or scoring. Every number comes from one harness on one branch. Published with this post is a prototype implementation. Note that the goal of this early prototype is design space exploration and reproducibility, not code quality of robustness. The code this post recommends is the variant-a series: 26 commits on Prysm’s develop, one change per commit behind --enable-segmented-payload-gossip, cutting at 16 KiB, over a go-libp2p-pubsub branch that adds phase forwarding, the request discipline, the park, the offer table and the request gate to v0.17.0. Every figure comes from a different branch: the research tree at tag followup-part1, with the fork it measured pinned, and the harness, the runner, the cell lists behind each figure and the extractor and figure scripts under testing/segstudy/; the raw logs of every cell are attached to the tag. That branch is a harness, not a proposal. The series’ own SEGMENTED_PAYLOAD_GOSSIP.md says which part of the design is in the tree, which is proposed, which exists only in the harness, and what is known to be open.
While this was a long post, a few things still ask for a follow-up post, comparing variant A with B (partial messages) and C (per-segment topics), and discussing some orthogonal protocol design questions:
control traffic clearly increased, as shown in Figure 9. There’s a reason bitmap-based signaling was proposed in FullDAS, later embodied in the partial messages extension. It addresses the control traffic aspect, while higher-frequency message processing remains, so it is still to be seen whether it allows further performance improvements.
our batch publishing starts to distribute segments on independent paths, but this path independence is not guaranteed later on. The degree of a single topic also limits what high-bandwidth nodes can achieve. Using more topics as in DAS (variant C) is one way of overcoming these limitations.
all of the above is based on libp2p and gossipsub. Not because we have to, but because we can. Would a new stack, e.g. a UDP-based QUIC-native stack, allow further performance gains? Most probably yes.
queue management, priorities, per-peer timer tuning, etc. are all implementation-local improvements that are worth investigating and eventually recommending for clients.
These are all interesting questions to tackle in a follow-up post, but none of these are required to reach the goals of EIP-8411.

Схожие новости

#	Наименование новости	Тональность	Информативность	Дата публикации
1	Wen fast payload broadcast? Segment, code, push, pull, and everything in between	0	15.31	17-09-2026
2	EIP-8146: Block Access List Sidecars	0	6	10-07-2026
3	Public-mempool gas sponsorship needs escrow, a bond, or trust	0	6.46	14-09-2026
4	Mempool Account Transaction Capacity from Historical Activity (MATCHA)	0	9.38	22-09-2026
5	Scaling Ethereum with recursive STARKs and the Trustless Log Index	0	6.14	15-09-2026
6	Etheorem update: the complete executable consensus specs written in Lean 4	0	4.8	21-09-2026
7	All Core Devs - Consensus (ACDC) #183, July 23 2026	0	15.18	13-07-2026
8	Strict role alternation: reciprocal broadcast without relayers for EVM shielded pools (spec + population simulation, no code yet)	0	12.48	19-09-2026
9	Post-Glamsterdam One-dimensional Fee Market and Comparison with EIP-7999	0	13.47	22-09-2026
10	When Data Binds Execution: Dynamic Simulation of EIP-7999’s Multidimensional Fee Market	0	10.98	16-09-2026

Классификация: . Схожих патентов: 0. Схожих новостей: 10. Тональность: 0. Информативность: 8.61. Источник: ethresear.ch.