Pipelined intra-slot slicing (K=8) for Rotor: decoupling shred construction from broadcast

[DSdBVS]

Context

Alpenglow's writeup (anza.xyz/blog/alpenglow-a-new-consensus-for-solana) treats network latency as the real floor: ~65% of stake sits within 50ms of a reference leader, long tail past 200ms. That's a hard limit on the consensus layer itself.

This is one layer below consensus: how fast a validator can start using a slice's data, not how fast validators agree on it. Uses Rotor's existing FEC-group/shred construction path.

The idea

Rotor splits a block into slices, and each slice into shreds via Reed-Solomon erasure coding (commonly 32+32 shreds per FEC group, 1:1 data:coding, tolerates up to 50% loss). Does the current pipeline wait for all data-shreds to be built before broadcasting the FEC group? If a leader instead splits one slice's data-shreds into K independent segments, each sent as soon as it's built, each with its own FEC group and quorum, can downstream consumers act on partial data sooner without hurting full-payload delivery?

What we found (toy Monte Carlo simulation, not real telemetry)

Modeled: base network delay + exponential jitter + i.i.d. per-shred loss, plus a construction-time-per-shred cost (a naive "build everything, then broadcast" model ignores this). Swept K = 1, 2, 4, 8, 16, 32, 100,000 trials per point, 1% loss, 0.6ms per data-shred build cost:

K	segment size	full-payload success	full-payload mean (ms)	first-segment mean (ms)
1	32	100.0000%	103.37	103.37
2	16	100.0000%	103.33	93.73
4	8	100.0000%	103.25	88.84
8	4	100.0000%	103.44	86.28
16	2	99.9920%	104.44	84.76
32	1	99.7040%	106.61	83.68

K=8 gets most of the first-chunk latency win (86ms, close to the ~80ms floor in this model) with no measurable cost to full-payload success or mean latency, only a small tail-latency cost. Past K=8 it gets worse: full-payload reliability drops because all K segments need to individually clear quorum.

Separately checked: splitting one FEC group into smaller independent groups for network-arrival speed alone doesn't help, and hurts tail reliability at high loss rates (200k-trial sweep, can share details).

Open questions

1. Does Rotor's current slicing/shredding already decouple construction from broadcast this way, or does it wait for the full data-shred batch before erasure-coding/broadcasting? If it already works this way, this idea is moot, want to know that directly.
2. Is there a downstream consumer (banking stage, replay, anything) that could use a partial/first-segment slice today, or does this need new plumbing?
3. Is K=8 the right number, or should it be fixed differently or dynamic based on measured loss/jitter, under real bursty network conditions and real validator geo-distribution?

This is a toy model: i.i.d. loss, constant per-shred construction cost, no real telemetry. Meant to make the idea concrete enough to discuss, not a finished proposal or SIMD. Can share the simulation code if useful.