Content pfp
Content
@
https://solana.com
0 reply
1 recast
2 reactions
@
0 reply
0 recast
0 reaction
mous (say moose) pfp
mous (say moose)
@adlonymous
2/ The old model: Proof of History (PoH) + Tower BFT PoH is a cryptographic clock that lets validators agree on when things happened, Tower BFT allows validators to commit to a block through just a single round of voting. Votes are submitted through a 'vote transaction' onchain. Finality under this model takes ~12.8s, the time it takes for 32 slots to accumulate, and lockouts are used to keep validators on one fork. In practice, many apps use optimistic confirmation (if block is confirmed by a supermajority, clients treat it as final within 600ms)
1 reply
0 recast
0 reaction
mous (say moose) pfp
mous (say moose)
@adlonymous
3/ A protocol called Turbine is used to broadcast blocks Leaders chop blocks into ~1KB 'shreds' and relay them through a layered tree. It is bandwidth-efficient, but it could suffer if any relay node lagged or dropped data.
1 reply
0 recast
0 reaction
mous (say moose) pfp
mous (say moose)
@adlonymous
4/ Despite all the optimizations, the current mechanism has limits Tower BFT requires >66% of stake to be online and voting or else the network would halt. PoH made synchronization easier but introduced it's own complexity. Turbine relies on timing sensitive relay trees. Alpenglow replaces all of it. No PoH, no TBFT, new evolution of Turbine. Consensus is handled by two new mechanisms: Rotor (for block propagation) and Votor (for voting and finalization). The goal? Finality in 100 - 150ms, faster than most web apps load!
1 reply
0 recast
0 reaction
mous (say moose) pfp
mous (say moose)
@adlonymous
5/ Votor introduces a dual-mode voting system. If 80% of stake votes quickly, then the block is finalized in a single round. If not, the network falls back to a second round, where only 60% is needed. Both modes run in parallel, and whichever succeeds first wins (some caveats) This “fast-then-fallback” approach gives Solana a new resilience model. It tolerates up to 20% malicious stake and up to 20% offline stake. That’s a big leap from the old 33% BFT model, which assumes all non-responders might be malicious.
1 reply
0 recast
0 reaction
mous (say moose) pfp
mous (say moose)
@adlonymous
6/ Rotor handles block propagation with a flatter design. Instead of a multi-hop tree like Turbine, blocks are now relayed in a single layer to stake-weighted validators. Fewer hops = lower latency. Erasure coding still provides fault tolerance, just like before. A block is divided into “slices,” which are independently erasure-coded and streamed out. Validators reconstruct the block piece by piece and store it using a module called Blokstor. Missing pieces? Fetch them later. Consensus doesn’t wait.
1 reply
0 recast
0 reaction
mous (say moose) pfp
mous (say moose)
@adlonymous
7/ Once a validator reconstructs a block, it votes. Votor collects those votes and checks whether the block hit 80% in round one. If not, it moves seamlessly into round two. Validators don’t need to decide which mode to use—both just run. When enough votes come in, a quorum certificate is formed. The block is final. Validators track all this in a local structure called Pool, which replaces the old Tower “vote stack.” No more lockouts, just immediate vote aggregation.
1 reply
0 recast
0 reaction
mous (say moose) pfp
mous (say moose)
@adlonymous
8/ This new design isn’t just faster—it’s more robust. Under Alpenglow, the network keeps moving even if 40% of stake is down or slow. Tower would halt in that situation. And because there’s no PoH, there’s no dependency on a single tick producer.
1 reply
0 recast
0 reaction
mous (say moose) pfp
mous (say moose)
@adlonymous
9/ But why 80% for fast finality? That’s a safety buffer. An attacker with <20% stake can’t trick 80% of honest validators into voting on something malicious. The fallback 60% path has tighter rules, but it still maintains safety guarantees. Finality is no longer “wait 32 blocks and hope.” A transaction can be finalized in under 150ms—sometimes as fast as 100ms. Alpenglow is a key piece to the puzzle of scaling Solana, alongside the upcoming Firedancer client and optimizations of the Agave client.
1 reply
0 recast
0 reaction
mous (say moose) pfp
mous (say moose)
@adlonymous
End/ Consider supporting my work and ensuring the future publication of longform pieces by donating to my Farcaster wallet or Adlonymous.sol For the full breakdown of Alpenglow, check out Helius' article at: https://www.helius.dev/blog/alpenglow Or the full whitepaper at: https://www.anza.xyz/blog/alpenglow-a-new-consensus-for-solana
0 reply
0 recast
0 reaction