Solana · New Consensus
The biggest upgrade in Solana's history — a complete rewrite of its core. Get an intuitive grip on the hard parts by touching them.
Until now Solana has run on two systems: Proof of History and TowerBFT. Alpenglow retires them and swaps in two new parts: Votor (decides finality by voting) and Rotor (spreads data to everyone).
Let's run both in the demos below.
On a blockchain, validators around the world vote that a block is valid, which finalizes the transactions. Finality means it can no longer be reversed — truly done.
Finality happens two ways. ① 80% in round 1 finalizes instantly (Fast-Finalization). ② 60–80% in round 1 notarizes, then 60% in round 2 finalizes. Votes aren't written on-chain one by one; signatures are aggregated off-chain, which frees about three-quarters of block space (previously taken by votes) for real transactions.
A new block's data must reach every validator worldwide. The question is how to spread it fast. Alpenglow rebuilds the delivery method itself.
In today's actual Solana, Turbine's fanout is large (~200) and relaying is only about two layers — this figure is a simplified illustration. As the network grows, Turbine gains layers, whereas Rotor keeps relaying to a single layer; that's the essential difference. Rotor also sends each shred as one erasure-coded packet (no separate data and recovery shreds), so redundancy stays the same while the design gets simpler.
The data Rotor delivers is a block cut into small pieces (shreds), plus extra “spare” pieces added by error correction (FEC — Reed–Solomon coding). A receiver doesn't need them all — enough pieces is enough to rebuild the original.
The 8-of-16 shown above is a simplified, scaled-down example. Alpenglow itself only requires that enough shreds arrive to rebuild a slice — the exact split of data and parity shreds is an implementation setting (Solana's current default is 32 data + 32 parity = 64, where any 32 reconstruct the slice). The difference from Turbine: Rotor sends each shred as one erasure-coded packet (no separate data and recovery shreds), so redundancy stays the same while the design gets simpler.
The famous figure from the Alpenglow white paper (leader in Zurich). The time to finality is broken into four parts. Drag across the chart to see the breakdown at any point.
What dragging reveals: reaching a small share of stake is fast. Reaching nearly everyone (close to 100%) means waiting for the most distant validators, so Network latency (green) shoots up — a node 100ms from Zurich physically can't be reached in less than 100ms. That's exactly why “finalize as soon as 80% is reached” pays off.
* An interactive re-creation of the white-paper figure. Values are approximate, for intuition.
This site is a simplified demo to build intuition for beginners; figures and behavior are simplified to convey the idea. Alpenglow is not yet live on mainnet, and details and timing may change with further testing. For primary sources, see the Anza blog and SIMD-0326.