From TowerBFT to Alpenglow, Solana Enters the Subsecond Era

Original Article Title: Alpenglow: A New Consensus for Solana
Original Article Authors: Quentin Kniep, Kobi Sliwinski, and Roger Wattenhofer
Original Article Translation: zhouzhou, BlockBeats

Editor's Note: Alpenglow is a new consensus protocol introduced by Solana, replacing the original TowerBFT and Proof-of-History mechanisms, introducing Votor and Rotor to optimize voting and data propagation, significantly reducing latency to 100–150 milliseconds, achieving sub-second finality. This protocol enhances performance, resilience, and scalability, enabling Solana to achieve response times comparable to Web2.

The following is the original content (slightly reorganized for better readability):

We are proud to introduce Alpenglow, Solana's new consensus protocol. Alpenglow is a consensus protocol tailored for a high-performance global Proof-of-Stake blockchain. We believe that the release of Alpenglow will be a turning point for Solana. It is not only a new consensus mechanism but also the most significant protocol change since the founding of Solana.

During the transition to Alpenglow, we will bid farewell to a series of old core components, especially TowerBFT and Proof-of-History. We have introduced a brand-new module, Votor, to take over the voting and block finalization logic. Additionally, Alpenglow has abandoned the gossip-based communication method in favor of a faster direct communication primitive.

Despite being a major change, Alpenglow still builds upon Solana's greatest strengths. Turbine has played a crucial role in the success of the Solana network, addressing the important issue of data propagation. In traditional blockchains, the leader often becomes a bottleneck in the system.

However, the technology used by Turbine splits each block into many smaller fragments through erasure coding and rapidly disseminates them. Importantly, this process fully leverages the bandwidth of all nodes. The data propagation protocol Rotor in Alpenglow continues and optimizes the design principles of Turbine.

Through these innovations, we are pushing Solana's performance to unprecedented levels. When using TowerBFT, the time from block production to final confirmation takes approximately 12.8 seconds. To reduce the latency to sub-second levels, Solana has previously introduced the concept of "optimistic confirmation."

Now, Alpenglow will shatter these latency limits. We anticipate that Alpenglow will reduce the actual final confirmation time to around 150 milliseconds (median).

In certain cases, final confirmation could even be achieved within 100 milliseconds — a speed that is nearly unbelievable for a global L1 blockchain protocol. (These latency figures are based on simulated results of the current mainnet staking distribution and do not include computational overhead.)

A median delay of 150 milliseconds not only means Solana is faster — it means Solana's responsiveness can rival Web2 infrastructure, potentially making blockchain technology feasible in entirely new application areas that require real-time performance.

The above chart illustrates the latency distribution at various stages of the Alpenglow protocol when the leader is located in Zurich, Switzerland. We chose Zurich as an example because that's where we were developing Alpenglow.

Each bar graph shows the average latency of current Solana nodes in a global distribution, sorted by proximity to Zurich.

The chart plots the simulated latency of network nodes reaching different stages of the Alpenglow protocol, corresponding to the proportion of network nodes that have reached that stage.

The green bars represent Network Latency. Looking at the current distribution of Solana's nodes, approximately 65% of staked nodes have a network latency of 50 milliseconds or less to Zurich. However, there is a longer tail of latency, with some staked nodes experiencing network latency of over 200 milliseconds to Zurich.

Network latency forms a natural lower bound in our chart — for example, if a node is 100 milliseconds away from Zurich, any protocol wishing to achieve final block confirmation on that node would need at least 100 milliseconds.

The yellow bars represent Rotor (data propagation protocol) latency, which is the first stage of the Alpenglow protocol.

The red bar indicates the time spent by a node to receive at least 60% staked-weight endorsement votes.

The blue bar represents the finalization time.

So, where does Alpenglow's high performance come from?

Alpenglow's voting component, Votor, implements an extremely efficient single-round voting mechanism: if 80% of stake-weighted nodes participate, a block can be confirmed in one round of voting; if only 60% of staked nodes respond, confirmation can still be achieved within two rounds of voting. These two modes are integrated and executed in parallel, with the faster one determining the final path to block confirmation.

Alpenglow's data dissemination sub-protocol, Rotor, continues and optimizes the approach of Turbine. Similar to Turbine, Rotor proportionally utilizes its bandwidth based on node staking weight, mitigating the issue of the leader becoming a bottleneck and achieving high throughput. Ultimately, the total bandwidth can achieve near-optimal utilization. One of Rotor's design principles is that in reality, the delay in information dissemination is mainly limited by network latency rather than transmission or computation speed. Rotor uses single-layer relay nodes instead of Turbine's multi-layer tree structure, reducing network hop counts. Additionally, Rotor introduces a new relay node selection mechanism, enhancing robustness.

Alpenglow is the result of cutting-edge research, combining erasure coding data distribution with the latest consensus mechanisms. Its innovations include an integrated one-round/two-round voting mechanism, bringing unprecedented block finalization latency. It also introduces a distinctive "20+20 fault-tolerance mechanism": even under harsh network conditions, the protocol can still operate normally, tolerating up to 20% malicious staked nodes and an additional 20% non-responsive nodes. Other contributions include a low-variance sampling strategy.

We have prepared a comprehensive technical whitepaper that provides a detailed overview of Alpenglow. The whitepaper not only explains the intuitions and goals behind our design but also elaborates on the entire protocol with concise definitions and pseudocode. Additionally, it includes various simulated data and computations to help readers understand Alpenglow's actual performance and concludes with a complete correctness proof.

"Original Article Link"