TowerBFT vs Alpenglow: how long Solana takes to finalize
One transaction, one healthy cluster of 25 validators, one seed, run twice. Under TowerBFT, the protocol Solana runs today, that transaction takes about 12.8 seconds to become final. Under Alpenglow, the protocol it is moving to, the same transaction is final in about 150 milliseconds.
Two orders of magnitude, from a consensus rule change rather than from faster hardware or a faster network. The table below is what the simulator actually measures, across every scenario it ships, at 25 validators on seed 1.
| Scenario | Alpenglow → final | TowerBFT → confirmed | TowerBFT → rooted |
|---|---|---|---|
| happy-path | 451 ms (fast path, 80%) | 513 ms | 12.7 s |
| ideal (tx rides the block's last slice) | 150 ms (fast path, 80%) | 187 ms | 12.4 s |
| offline-25pct | 563 ms (slow path, 60%+60%) | 493 ms | 17.8 s |
| leader-down (tx sent into a dead window) | 452 ms after the next live leader | 350 ms | 12.5 s |
| partition-heal (tx sent mid-partition) | 1.3 s after the heal (standstill re-broadcast, then 512 ms of consensus) | 495 ms | 12.7 s |
| twenty-twenty (21% offline, then a partition) | 462 ms (slow path) | 489 ms | not within 14 s |
What the columns mean
- Alpenglow → final is the first time a finality certificate covers the block the transaction landed in. In Alpenglow that is the only stage worth calling final.
- TowerBFT → confirmed is optimistic: two thirds or more of stake has its latest vote on the block or a descendant. It is not safe yet and can still be reverted.
- TowerBFT → rooted is final. A block is rooted once 32 votes stack on top of it, which at 400 ms slots is roughly 12.8 seconds after it was made.
The gap is not all consensus
happy-path and ideal run on the same healthy cluster with no
faults at all, and Alpenglow finalizes in 451 ms in one and 150 ms in the other. The
difference is not the voting. It is when the transaction lands in the block.
A block cannot be voted on until the leader has produced every one of its slices across
the whole 400 ms block, so a transaction that rides the first slice waits for the rest of
the block to be built, and one that rides the last slice pays almost none of that. Both
then pay the same 150 ms of voting and certification.
That is the most useful thing this simulator shows: the median 150 ms in the Alpenglow white paper (Fig. 14) is measured after a block has been distributed, so it is the last-slice case. Much of the apparent end-to-end latency gap between the two protocols is block assembly, which the protocol change does not touch.