We proudly present Alpenglow, Solana’s new consensus protocol. Alpenglow is a consensus protocol tailored for a global high-performance proof-of-stake blockchain. We believe that the release of Alpenglow will be a turning point for Solana. Alpenglow is not only a new consensus protocol, but the biggest change to Solana’s core protocol since, well, ever.

When moving to Alpenglow, we say goodbye to a number of legacy components of the core protocol, in particular, TowerBFT and Proof-of-History. We instead introduce Votor, which takes over the voting and block finalization logic. Moreover, rather than relying on gossip, Alpenglow adopts a faster direct communication primitive.

Despite being a big change, Alpenglow builds on Solana’s biggest strengths. Turbine has played a crucial role in the Solana network’s success as it addresses the important aspect of data dissemination. In blockchains of the past, the leader was often the bottleneck of the system. In contrast, Turbine features a technique where each block is erasure-coded into many smaller pieces which can be disseminated rapidly. Crucially, the bandwidth of all nodes is utilized in this process. Rotor, which is Alpenglow’s data dissemination protocol, embraces Turbine’s approach and refines it.

With these changes we will bring Solana to an unprecedented performance level. With TowerBFT, Solana had about 12.8 sec from block creation until block finality. To bring latency down into the sub-second domain, Solana introduced the “optimistic confirmation” concept. Alpenglow will shatter both these latency bounds. We expect that Alpenglow can achieve actual finality in about 150 ms (median). Sometimes finality can be achieved as fast as 100 ms, which is an unbelievably low number for a world-wide L1 blockchain protocol. (These latency numbers are based on simulations with the current mainnet stake distribution, not counting computation overhead.)

A median latency of 150 ms does not just mean that Solana is fast — it means Solana can compete with Web2 infrastructure in terms of responsiveness, potentially making blockchain technology viable for entirely new categories of applications that demand real-time performance.

The above plot shows the latency breakdown of different parts of Alpenglow with the leader in Zurich, Switzerland. We have chosen Zurich as an example because it was our location while developing Alpenglow. Each bar shows the average delays of the current world-wide distribution of Solana nodes, sorted by distance from Zurich. Simulated latencies to reach different stages of the Alpenglow protocol are plotted against the fraction of the network that arrived at that stage.

The green bars show the network latency. With the current node distribution of Solana, about 65% of Solana’s stake is within 50ms network latency of Zurich. The long tail of stake has more than 200ms network latency from Zurich. The network latency serves as a natural lower bound for our plot, e.g., if a node is 100ms from Zurich, then any protocol needs at least 100ms to finalize a block at that node.
The yellow bars show the delay incurred by Rotor, the first stage of our protocol.
The red bars mark the time when a node has received notarization votes from at least 60% of the stake.
Finally, the blue bars show the finalization time.

So where is this high performance coming from?

Alpenglow’s voting component Votor finalizes blocks in a record single round of voting if 80% of the stake is participating, and in two rounds if only 60% of the stake is responsive. These two voting modes are integrated and performed concurrently, such that finalization happens as soon as the faster of the two paths terminates.

Rotor, which is Alpenglow’s data dissemination sub-protocol, embraces Turbine’s approach and refines it. Like Turbine, Rotor utilizes the bandwidth of participating nodes proportionally to their stake, alleviating the leader bottleneck for high throughput. As a result, total available bandwidth is used asymptotically optimally. One of the insights informing Rotor’s design is that speed of light is still too slow, and the delay in information dispersal is dominated by network latency, as opposed to transmission or computation delay. Rotor features a single layer of relay nodes, as opposed to the multi-layer tree of Turbine. In this way, Rotor minimizes the number of network hops. Moreover, Rotor introduces new techniques to determine the relay nodes, resulting in improved resilience.

Alpenglow is built on state-of-the-art research, combining erasure-coded data distribution with the latest advancements in consensus. It introduces innovations, such as its integrated one/two-round voting modes, resulting in unprecedented finalization latency. The distinctive “20+20” resilience allows the protocol to operate effectively even under harsh network conditions, tolerating up to 20% adversarial stake and an additional 20% non-responsive stake. Other contributions include a low-variance sampling strategy.

We have written a comprehensive white paper that describes Alpenglow in detail. The white paper presents the intuition behind Alpenglow, and what we want to achieve. It also discusses the protocol with concise definitions and pseudo-code. The white paper includes various simulation measurements and calculations to get an understanding of how Alpenglow is going to perform. And finally, the white paper contains correctness proofs.

Disclaimer：

1. This article is reprinted from [anza]. All copyrights belong to the original author [Quentin Kniep, Kobi Sliwinski, and Roger Wattenhofer]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.