Introducing Alpenglow: Solana’s new consensus protocol

Anza Labs (formerly known as Solana Labs) has proposed the most significant update to the Solana blockchain since it went live: Alpenglow.

Alpenglow replaces TowerBFT and Proof-of-History as the voting and block finalization mechanism with Votor and refines Turbine as the data propagation layer with Rotor. This piece will discuss how these changes affect the Solana ecosystem and what you can expect after Alpenglow’s implementation.

Votor

Until Votor, Solana relied on T**ower Byzantine Fault Tolerance (TBFT) as its consensus algorithm, which is a custom implementation of Practical Byzantine Fault Tolerance (PBFT). You can visualize TBFT as a two-step handshake.

On the first handshake, known as the pre-vote, every validator signs a short “yes, I saw this block” message. The block can move on only after at least two-thirds (2/3) of all stake have sent this first vote. On the second handshake, known as the commit, once the same super-majority notices that the first round succeeded, they sign a second, “now it’s final” vote.

This 2-hop pattern (plus occasional view changes when the leader stalls) is mathematically safe as long as less than one-third of the total stake is actively malicious. However, this introduces a lot of latency, as block finality on Solana averages about 12.8 seconds, which is impractical for real-time applications like games.

Votor keeps the familiar “everyone votes with stake-weighted signatures” idea, but lets the chain stop early if ≈ 80 % of the stake manages to send its first vote before a deadline T₁ ≈ δ (T₁ = first waiting window, δ = network yardstick). If 80% is reached, the block is finalized immediately—no second hop.

If 80 % isn’t reached in time, the protocol relaxes to 60 % in two hops, which is only slightly stricter than the old ⅔-rule but still maintains safety. With this mechanism, Votor achieves a median latency of 150 ms, comparable to Web2 infrastructure.

In essence, Votor shaves hundreds of milliseconds off the common case by trusting that true, coordinated attacks above 20 % stake are rare. The bargain is a slightly narrower safety cushion, tighter uptime requirements for validators, and a protocol that is trickier to reason about and to monitor in production.

Rotor

Originally, the current slot leader was responsible for sending every byte of the block to the rest of the validators, which was a huge bottleneck. To ease the burden, the protocol adopted Turbine, which broke the blocks into shreds, erasure-coded them, and pushed them down a fixed fan-out tree.

This helped; however, it left a few pain points. One, every shred still originates on the leader’s network, tens of thousands of transactions passing through a single pipe. Also, the relay work was uneven. Which node relays to whom is hard-coded by slot number, so the same unlucky validator may forward huge chunks of traffic while others forward almost none, and yet everyone earns identical rewards for “voting”.

This approach was also blind to stake. A validator with a 0.1% stake could end up relaying as much data as one holding 5%, even though the latter has both the resources and the economic incentive to shoulder more load. As throughput crept upward, the leader bottleneck and unfair bandwidth distribution threatened real-time user experience.

Rotor re-imagines block distribution as a stake-weighted peer-to-peer CDN. The leader seeds just enough shreds to a randomly sampled set of relay nodes, each chosen with probability proportional to its stake. Those relays then spray their own stake-proportional bandwidth outward; any γ out of Γ shreds suffice to reconstruct the block, so a fair chunk of relays can drop offline without harm.

The result is that the leader’s outbound traffic falls from “block size × fan-out” to roughly “block size × (log N / Γ)”.

Rotor keeps the idea of “leader seeds a few peers first”, but it

eliminates the fixed tree, the 32-fold duplication, and the unpaid relay work. The price is a heavier dependency on honest capacity provisioning, steeper hardware requirements for validators, and a significantly more intricate networking layer that must stay honest and measurable at scale.

Conclusion

Alpenglow reframes Solana’s guiding idea, “the world computer should feel like the local computer,” by eliminating the leader pipe as a bottleneck and letting a stake-weighted swarm move blocks and votes at near-network speed. If the upcoming test networks confirm the projected latency and fairness gains, Alpenglow could set a new benchmark for high-performance, open-participation blockchains.