πŸš€ Premium Banner Placement β€” Reach 100K+ daily crypto readersAdvertise with us β†’
LIVE
BTCβ€”ETHβ€”SOLβ€”BNBβ€”XRPβ€”ADAβ€”AVAXβ€”DOGEβ€”LINKβ€”DOTβ€”MATICβ€”ATOMβ€”LTCβ€”TRXβ€”TONβ€”BTCβ€”ETHβ€”SOLβ€”BNBβ€”XRPβ€”ADAβ€”AVAXβ€”DOGEβ€”LINKβ€”DOTβ€”MATICβ€”ATOMβ€”LTCβ€”TRXβ€”TONβ€”
Blockchain

Anza and a16z Researchers Propose Gatling, Targeting 10ms Solana Slots

16 Jun 2026by CryptoJazz Admin1 min read6 views
Anza and a16z Researchers Propose Gatling, Targeting 10ms Solana Slots

Researchers from Anza and a16z Crypto published a paper on 16 June proposing a way to cut the gap between block proposals on Solana to as little as 10 milliseconds. The paper, "Gatling: Rapid-Fire Consensus from Parallel Composition," is credited to Giulia Scaffino, Max Resnick and Joachim Neu. Its central argument is that a network does not have to make a single consensus process faster in order to produce blocks faster; it can run several consensus processes at once and stagger them. A prototype running nine instances in parallel produced a new proposal roughly every 56 milliseconds. None of this is a shipped feature, and the work carries no production timeline.

The Idea: Nine Consensus Instances Instead of One Faster One

Consensus is the procedure by which validators agree on the next block and its contents, and its speed is bounded by how long messages take to travel between them. Most attempts to shorten block times attack that bound directly, by cutting rounds of voting or shrinking the messages that carry votes. Gatling takes a different route. It runs K independent instances of an existing consensus protocol side by side, starts them on a staggered schedule so their proposals land at evenly spaced intervals, and merges their outputs into one chain through a deterministic interleaving rule, so that every validator derives the same order from the same set of instances. The wrapper treats the underlying consensus as a black box, composing existing instances without modifying their internals, which is what would let it sit on top of a protocol already in use rather than replace it.

The Numbers: 56 Milliseconds Between Proposals

The reported prototype results are for K=9, nine parallel instances. Inter-proposal time, the gap between one block proposal and the next, came in at about 56 milliseconds, roughly nine times the baseline rate and in line with the number of instances. End-to-end latency, measured from proposal to confirmed output, was 226.6 milliseconds under normal conditions and 244 milliseconds with 1% packet loss. The 10-millisecond slot time is described as a theoretical target, not an achieved figure. The distance between 56 milliseconds and 226.6 milliseconds is the design's defining trade: parallel composition makes proposals arrive more often without making any individual instance confirm faster, so a chain gets more frequent blocks while each block still takes as long as it always did to settle.

Alongside Alpenglow: Orthogonal Rather Than Competing

Solana already has a consensus overhaul in progress. Alpenglow replaces the TowerBFT and proof-of-history voting machinery with a component called Votor, targets roughly 150 milliseconds to finality, and introduces a Validator Admission Ticket priced at 1.6 SOL per epoch. It entered validator testing on a community cluster on 11 May 2026 and has not reached mainnet. Gatling is presented as orthogonal and complementary to that effort rather than an alternative to it: Alpenglow makes a single consensus instance finalize faster, while Gatling would run several instances of whatever consensus a network already has. Because the wrapper does not touch the internals of the protocol it composes, the two are meant to stack.

From Prototype to Live Network: The Distance Left

A latency figure from a prototype and a latency figure from a live network are not the same measurement. Solana mainnet runs across an open network with uneven hardware, adversarial traffic and real economic incentive to misbehave, and a controlled run at K=9 speaks to none of that. Client engineering is on its own track: Firedancer v1.0.0, the ground-up C rewrite of the validator client, reached testnet in June on a date carried by only one report, and is explicitly not recommended for Mainnet Beta, which distinguishes it from the Frankendancer hybrid already running more than 20% of mainnet stake. Agave v4.0.3 and v4.1.0-rc.1, released the same day as the Gatling paper, carried five backported correctness fixes covering entry validation, blockstore integrity, voting overhead and nonce handling. Gatling has a paper, a prototype and a shape that fits the work already under way. What it does not have is a date.

← All news