# What is Turbine? How Solana propagates blocks in under a second

> Turbine is Solana's block propagation protocol. Learn how shreds, erasure coding, and stake-weighted trees deliver blocks in milliseconds, and what Rotor changes.

Canonical HTML: https://app.marinade.finance/learn/turbine-block-propagation-solana/

Every blockchain has the same delivery problem. A leader produces a block and every validator needs a copy before they can vote on it. Bitcoin and Ethereum solve it with gossip: each node forwards the full block to its peers, who forward it again. That works when blocks arrive every 12 seconds. It cannot work when they arrive every 400 milliseconds.

Turbine is Solana's answer. Instead of flooding whole blocks through the network, the leader slices each block into small packets called shreds, adds mathematical redundancy so lost packets can be reconstructed, and pushes them through a stake-weighted tree where every validator does a small share of the forwarding work. The result is that most of Solana's roughly 1,000 validators receive block data within two to three network hops, in a few hundred milliseconds.

This article explains how Turbine works, why stake determines how fast a validator sees new blocks, what changed in recent network upgrades, and how Rotor, part of the Alpenglow upgrade, will eventually replace it.

![Turbine: leader node streaming shreds into a branching teal network](https://public.marinade.finance/learn/01-hero-turbine.webp)

## The problem Turbine solves

The bottleneck in block propagation is bandwidth, not computation. Anatoly Yakovenko's original Turbine writeup illustrates it with a thought experiment: a leader with a 128 MB block and 20,000 validators to serve. If the leader sends the full block to each validator directly, it has to transmit 128 MB twenty thousand times. No single machine's network connection can do that in any useful timeframe.

Gossip protocols spread the load, but at the cost of redundancy and latency. Each node receives and retransmits the full block, often multiple times, and the block reaches the network's edge only after many sequential hops. That trade is acceptable for chains that finalize in minutes. Solana targets slot times of 400 milliseconds, so it needed a propagation protocol where the leader's outbound bandwidth stays constant regardless of network size and where the number of hops stays small.

Turbine borrows its core idea from BitTorrent: break the data into pieces and spread the sending work across the whole network, so no single node ever transmits more than a small, fixed amount.

## Shreds: how a block travels

Before a block leaves the leader, it gets shredded. Transactions are batched into entries, serialized, and cut into packets of roughly 1,280 bytes, sized to fit a standard network packet (MTU) without fragmentation. These packets are called shreds, and they come in two types.

Data shreds carry the actual transaction data. Coding shreds carry Reed-Solomon erasure coding, a form of forward error correction. Together they form an FEC set, typically 32 data shreds plus 32 coding shreds. The mathematics of Reed-Solomon coding mean that any 32 of those 64 shreds are enough to reconstruct the full set. The network can lose up to half the packets in a set and still rebuild the block without asking for a single retransmission.

![From block to shreds: each block is cut into 32 data shreds and 32 coding shreds — any 32 of the 64 rebuild the full set](https://public.marinade.finance/learn/02-shreds-erasure-coding.webp)

This matters because retransmission is poison for latency. Packet loss compounds with every hop. The [Anza documentation](https://docs.anza.xyz/consensus/turbine-block-propagation) walks through the math: under illustrative assumptions of 15% packet loss, a 32:32 FEC ratio delivers a per-block success rate around 99%, while weaker ratios collapse to practically zero. Leaders can also raise the coding ratio dynamically when network conditions degrade.

Every shred is signed by the leader. Under the current Merkle shred scheme, the leader builds a Merkle tree over each FEC set and signs the root, so each shred carries a compact proof of integrity. This replaced the older per-shred signatures, and since [SIMD-0313](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0313-drop-unchained-merkle-shreds.md), chained Merkle shreds are the mandatory format on mainnet. Validators verify the signature on every shred they receive, so a malicious relay cannot inject corrupted data.

## The Turbine tree: stake decides your position

Shreds do not travel to all validators at once. They travel down a tree.

For every single shred, the network deterministically constructs a propagation tree. All validators are sorted by stake weight, shuffled using a seed derived from the leader's identity, the slot, the shred index, and the shred type, then sliced into layers. The fanout constant is 200: the leader sends each shred to one root node, the root forwards it to up to 200 validators in layer one, and each layer-one node forwards it to its own unique subset of layer two.

![The Turbine tree: stake-weighted, rebuilt for every shred, fanout of 200 — higher-stake validators sit closer to the root and receive shreds first](https://public.marinade.finance/learn/03-turbine-tree.webp)

Two properties of this design carry most of the weight.

First, egress is bounded. Each validator transmits at most 200 copies of any shred, no matter how large the network grows. Propagation scales logarithmically: with a fanout of 200, two hops reach 40,000 nodes. On today's mainnet of roughly 1,000 active validators, nearly the entire network sits within two hops of the leader.

Second, the tree is stake-weighted and unpredictable. Because validators are sorted by stake before the shuffle, higher-staked validators land closer to the root and receive shreds earlier. And because the tree is re-derived for every shred, no attacker can predict which position any node will occupy for the next packet. An adversary trying to eclipse a validator or censor a region of the tree would need to control a share of positions proportional to enormous stake. Combined with erasure coding, which absorbs the damage any single faulty relay can do, this makes the propagation layer resilient to both random packet loss and deliberate interference. If a validator still cannot reconstruct a block, it falls back to Solana's repair protocol and requests the missing shreds from peers.

## Turbine by the numbers

![Turbine by the numbers: ~400 ms slot time, 1,280 B shred size, 32+32 data and coding shreds per FEC set, 50% packet loss tolerated, 200 tree fanout, 2–3 hops to reach the network, ~1,000 active validators, 0.8 ms retransmit latency with Agave 4.0](https://public.marinade.finance/learn/04-turbine-numbers.webp)

| Parameter | Value on mainnet |
|---|---|
| Slot time | ~400 ms |
| Shred size | ~1,280 bytes |
| FEC set (typical) | 32 data + 32 coding shreds |
| Loss tolerance per set | up to 50% |
| Tree fanout | 200 |
| Hops to reach the network | 2 to 3 |
| Active validators | ~1,000 |
| Retransmit latency (Agave 4.0, XDP) | ~0.8 ms, down from ~600 ms |

## What changed recently: Turbine keeps getting faster

Turbine is not a static design. Three upgrades since 2024 changed its performance profile.

The Merkle shred migration completed. All shreds on mainnet now use chained Merkle authentication, which cut verification costs and hardened block integrity across FEC sets.

Agave 4.0 moved shred retransmission close to the network card. Using XDP, a kernel-level fast path, Anza reports [Turbine retransmit latency dropping from roughly 600 ms to under 1 ms](https://www.anza.xyz/blog/agave-4.0-patch-notes) on large validators. That removes one of the biggest internal delays between a validator receiving a shred and forwarding it down the tree, and creates headroom for larger blocks.

Independent validator clients now run their own Turbine implementations. Firedancer, the C client built by Jump Crypto, reimplements shredding, erasure coding, and forwarding with kernel-bypass networking, which both speeds up propagation and removes the single-implementation risk that caused a network halt in December 2020.

Alongside protocol upgrades, dedicated network infrastructure entered the picture. DoubleZero, a private fiber network for validators, launched on mainnet in late 2025 with over a fifth of staked SOL connected. Measured results from validator operators such as [Chorus One](https://chorus.one/reports-research/the-doublezero-effects) show it acts as a latency equalizer: it shortens paths for geographically distant validators while changing little for validators already close to stake-dense regions. It complements Turbine rather than replacing it.

## Rotor: what comes after Turbine

Turbine will eventually be replaced, and it is worth understanding by what and when.

Alpenglow is the largest consensus rewrite in Solana's history, developed by Anza's research team led by Professor Roger Wattenhofer of ETH Zurich. It has two components. Votor replaces Tower BFT voting and targets finality of roughly 100 to 150 milliseconds, compared to about 12.8 seconds today. It passed governance as [SIMD-0326](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0326-alpenglow.md) in August 2025 with 98% of participating stake voting yes.

Rotor is the block propagation half. It flattens Turbine's multi-hop tree into a single layer of stake-weighted relay nodes: the leader sends each erasure-coded shred to one relay, and that relay broadcasts it to every node directly. One hop instead of two or three. Rotor also transmits a single erasure-coded version of each shred rather than separate data and coding shreds, and it is designed to work natively with multicast networks like DoubleZero. The [Alpenglow whitepaper](https://www.anza.xyz/alpenglow-1-1) estimates that reaching 80% of stake takes only a couple of milliseconds of transmission time on gigabit links.

![Turbine today vs Rotor next: Turbine's multi-hop tree (2–3 hops, fanout 200) versus Rotor's single-hop relay broadcast — both designs select positions by stake weight](https://public.marinade.finance/learn/05-turbine-vs-rotor.webp)

The important nuance: Rotor is not live. It will ship as its own separate SIMD after Votor, and Wattenhofer has confirmed publicly that Turbine remains the production propagation layer for now, since, in his words, Turbine is already good. Any article claiming Solana already runs Rotor is ahead of reality. Turbine is simultaneously being made faster and being prepared for succession.

## What Turbine means for stakers

Here is the part most explainers skip: Turbine makes stake distribution a network health question, not just a governance one.

Position in the Turbine tree is a function of stake. Validators with more stake sit closer to the root, receive shreds earlier, replay blocks sooner, and get their votes back to the leader faster. Rotor keeps this principle, selecting relays proportionally to stake. In both designs, the geography and concentration of stake directly shape how fast and how reliably blocks move through the network.

That cuts two ways. Stake weighting is what makes the tree efficient and attack-resistant. But if stake concentrates in a handful of operators or a single region, block propagation concentrates with it. Measurement studies already show this: because so much Solana stake sits in Europe, propagation depth and latency look very different for a validator in Singapore than for one in Amsterdam. A network where a small superminority of validators controls enough stake to halt consensus is also a network where a small group sits at the top of every propagation tree.

This is where staking choices become infrastructure choices. When stakers delegate to already-oversized validators, they deepen the concentration Turbine has to route around. When stake spreads across many performant, geographically diverse validators, the tree gets healthier: lower tail latency, fewer single points of failure, more resilient consensus.

Marinade was built around exactly this principle. Its delegation strategy distributes stake across 100+ validators, scoring them on performance, commission-adjusted yield, and decentralization, and it deducts points from validators already in the superminority. Staking through [Marinade](https://app.marinade.finance) earns yield while pushing stake toward the distribution that protocols like Turbine and Rotor depend on. Decentralized stake is not a slogan here. It is measurably better block propagation.

## Frequently asked questions

**What is Turbine in Solana?**
Turbine is Solana's block propagation protocol. It splits each block into small packets called shreds, adds Reed-Solomon erasure coding for loss recovery, and distributes them through a stake-weighted tree of validators so the whole network receives blocks in a few hundred milliseconds.

**What are shreds?**
Shreds are the ~1,280-byte packets a Solana block is cut into for transmission. Data shreds carry transactions and coding shreds carry redundancy. In a typical 32:32 FEC set, any 32 of the 64 shreds are enough to reconstruct the data.

**How fast is Solana block propagation?**
Most validators receive a block within 2 to 3 network hops, fast enough to support 400 ms slot times. With the XDP fast path in Agave 4.0, the internal retransmit step on a validator takes under a millisecond.

**Does more stake mean a validator sees blocks sooner?**
Yes. The Turbine tree sorts validators by stake before shuffling, so higher-staked validators sit closer to the root and receive shreds earlier on average. This is one reason stake distribution matters for network health.

**Is Turbine being replaced?**
Eventually. Rotor, part of the Alpenglow upgrade, will replace Turbine's multi-hop tree with a single hop through stake-weighted relays. The Votor consensus component of Alpenglow passed governance in 2025, but Rotor will arrive later under its own proposal. Turbine remains Solana's production propagation layer today.

**What is the difference between Turbine and gossip?**
Gossip protocols like Bitcoin's flood full blocks redundantly through the network. Turbine sends each shred along exactly one deterministic path per hop, bounds every node's bandwidth with a fixed fanout, and uses erasure coding instead of retransmission to handle loss. Turbine trades gossip's redundancy for speed and recovers reliability through coding.

---

*Sources: [Anza Turbine documentation](https://docs.anza.xyz/consensus/turbine-block-propagation), [Anatoly Yakovenko's original Turbine post](https://solana.com/news/turbine---solana-s-block-propagation-protocol-solves-the-scalability-trilemma), [Helius: Turbine block propagation](https://www.helius.dev/blog/turbine-block-propagation-on-solana), [Anza: Alpenglow](https://www.anza.xyz/blog/alpenglow-a-new-consensus-for-solana), [Agave 4.0 patch notes](https://www.anza.xyz/blog/agave-4.0-patch-notes), [SIMD-0326](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0326-alpenglow.md), [Chorus One: The DoubleZero Effects](https://chorus.one/reports-research/the-doublezero-effects).*