Most recent progress in blockchain consensus has fixated on a single number: how fast a proposal, once made, can be confirmed. That work matters, and the best protocols today sit at or near the theoretical floor for confirmation latency. But confirmation is only half of the delay a transaction actually feels. The other half is how long a transaction waits for any proposal to pick it up in the first place. A paper posted to arXiv on June 16, Gatling: Rapid-Fire Consensus from Parallel Composition by Giulia Scaffino, Max Resnick, and Joachim Neu, attacks that second number, and the headline claim is unusually crisp.

The authors frame consensus the way a systems engineer would: a replicated state machine in which every correct node must agree on the same totally ordered log of input transactions. Good-case transaction latency, they note, decomposes into two factors — how frequently proposals are made, and how quickly each proposal is confirmed once issued. Prior work has effectively closed the book on the second factor with tight lower bounds that modern protocols already meet. The open question Gatling targets is whether the inter-proposal time can drop below the state of the art of one network delay.

"We introduce Gatling, an atomic broadcast protocol that achieves arbitrarily small inter-proposal times under rotating leader schedules; in particular, smaller than the network delay."— arXiv:2606.18220, source

The mechanism is the interesting part, and it is conceptually simple. Rather than redesign a consensus protocol from scratch, Gatling treats an existing atomic-broadcast protocol as a black box and runs several instances of it in parallel. The instances' proposal schedules are staggered, so that across the whole ensemble proposals are emitted in faster succession than any single instance could manage. A deterministic interleaving rule then merges the per-instance outputs into one global log. Because the merge is deterministic, every correct node reconstructs the same final ordering without an extra agreement step — the agreement already happened inside each component instance.

Read carefully, what Gatling claims to improve and what it leaves alone are both worth stating plainly. It does not claim to confirm any single proposal faster than the underlying protocol; the confirmation latency of a given proposal is whatever the black-box component delivers. What it claims is that proposals can be started more often, so the expected wait before a transaction is captured by some proposal shrinks. For workloads where transactions arrive continuously and the bottleneck is proposal cadence rather than per-proposal confirmation, that is the number that dominates user-perceived latency.

The cost the paper actually accounts for

Running multiple instances is not free, and the authors do not pretend otherwise. The most obvious hazard is head-of-line blocking: under rotating leader schedules, a crashed leader stalls its instance, and if the merge rule waits on a stalled instance the whole pipeline can choke. The paper analyzes this effect explicitly and derives an optimal number of parallel instances — too few and you leave inter-proposal time on the table, too many and the coordination overhead and crash exposure eat the gains. That derivation is the load-bearing technical contribution: a knob with a principled setting rather than a vague 'add more instances' gesture.

A second concern is a property the authors call predictable validity — roughly, the guarantee that a transaction known to all honest nodes will actually be included rather than perpetually deferred. Parallel composition can threaten such guarantees if the interleaving lets some instances starve. Gatling addresses this directly, presenting two variants that retain predictable validity. The existence of two variants rather than one is a tell that the property does not come for free and that there is a design trade-off between aggressiveness and inclusion guarantees.

Why a black-box construction matters

The most practically significant design choice is that Gatling sits on top of off-the-shelf components rather than replacing them. Their experiments confirm that Gatling can be combined with existing component protocols to achieve low latency without fine-tuning the component for minimum latency. For protocol designers, that is the difference between a research curiosity and something deployable: a chain that already runs a vetted atomic-broadcast protocol could, in principle, wrap it in Gatling's scheduling and merge layer rather than swapping the consensus core and re-auditing the whole stack.

The skeptic's question is how much of the theoretical gain survives contact with a real network. Inter-proposal time below one network delay is a statement about scheduling, not about physics; the merged log still propagates over the same links, and bandwidth, not proposal cadence, is the binding constraint on many production chains. The paper's contribution is to show the cadence floor is not fundamental and to quantify the instance count where the trade-off turns negative. Whether that translates into end-to-end throughput wins depends on whether proposal frequency, rather than bandwidth or confirmation, is your system's actual bottleneck.

For the consensus-design lane, the cleaner takeaway is methodological. Gatling reframes a latency improvement as a composition problem — take a primitive whose single-instance behavior is well understood, run several copies, and merge deterministically — rather than a new-protocol problem. That framing is reusable. The same staggered-and-merged pattern could in principle apply to other replicated primitives where the per-instance latency is fixed but the aggregate cadence is the thing you want to push. The paper's value, beyond the specific protocol, is the demonstration that the inter-proposal interval was a degree of freedom hiding in plain sight, and that it can be exploited without giving up the safety and validity properties that make a consensus protocol worth running at all.