Original Title: Alpenglow: A New Consensus for Solana
Original Authors: Quentin Kniep, Kobi Sliwinski, and Roger Wattenhofer
Original Compiler: zhouzhou, BlockBeats
Editor's Note: Alpenglow is a new consensus protocol launched by Solana, replacing the original TowerBFT and Proof-of-History mechanisms, introducing Votor and Rotor, optimizing voting and data propagation, and significantly reducing latency to 100–150 milliseconds, achieving sub-second finality. This protocol enhances performance, resilience, and scalability, allowing Solana to achieve response speeds comparable to Web2.
The following is the original content (reorganized for readability):
We are proud to introduce Alpenglow, Solana's new consensus protocol. Alpenglow is a consensus protocol tailored for high-performance Proof-of-Stake blockchains worldwide. We believe that the release of Alpenglow will mark a turning point for Solana. It is not just a new consensus mechanism but the most significant transformation of the core protocol since Solana's inception.
In the transition to Alpenglow, we will bid farewell to a series of old core components, particularly TowerBFT and Proof-of-History. We have introduced a 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 this major transformation, Alpenglow is still built on the foundation of Solana's greatest strengths. Turbine has played a key role in the success of the Solana network, addressing the critical issue of data propagation. In traditional blockchains, the leader often becomes a bottleneck for the system.
The technology used by Turbine splits each block into many smaller fragments through erasure coding and propagates them quickly. The key is that this process fully utilizes the bandwidth of all nodes. The data propagation protocol Rotor in Alpenglow continues and optimizes the design philosophy of Turbine.
Through these changes, we are pushing Solana's performance to unprecedented heights. When using TowerBFT, it took about 12.8 seconds from block generation to final confirmation. To reduce latency to sub-second levels, Solana previously introduced the concept of "optimistic confirmation."
Alpenglow will break these latency limits. We expect Alpenglow to reduce the actual final confirmation time to about 150 milliseconds (median).
In some cases, final confirmation can even be achieved within 100 milliseconds—an almost unbelievable speed for global L1 blockchain protocols. (These latency figures are based on simulated results of the current mainnet staking distribution and do not include computational overhead.)
A median latency of 150 milliseconds not only means Solana is faster—it means Solana's responsiveness can rival Web2 infrastructure, potentially making blockchain technology viable in new application areas that require real-time performance.
The chart above shows the latency distribution of various stages of the Alpenglow protocol when the leader is located in Zurich, Switzerland. We chose Zurich as an example because we were developing Alpenglow in this city.
Each bar in the chart represents the average latency of current Solana nodes distributed globally, sorted by their distance from Zurich.
The chart depicts the simulated latency for nodes in the network 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. Based on the current distribution of Solana nodes, about 65% of staked nodes have a network latency of under 50 milliseconds from Zurich. However, the latency tail is long, with some staked nodes having a network latency exceeding 200 milliseconds from Zurich.
Network latency constitutes a natural lower bound in our chart—for example, if a node is 100 milliseconds away from Zurich, then any protocol aiming to achieve block finalization at that node will require at least 100 milliseconds.
The yellow bars indicate the latency of Rotor (the data propagation protocol), which is the first stage of the Alpenglow protocol.
The red bars represent the time taken for nodes to receive notarized votes with at least 60% staking weight.
The blue bars indicate the final confirmation time.
So, where does Alpenglow's high performance come from?
The voting component of Alpenglow, Votor, implements an extremely efficient single-round voting mechanism: if 80% of staked nodes participate, the block can be confirmed in one round of voting; if only 60% of staked nodes respond, it can still be completed within two rounds of voting. These two modes are integrated and executed in parallel, with the faster path being used for final block confirmation.
The data propagation sub-protocol Rotor continues and optimizes the approach of Turbine. Similar to Turbine, Rotor proportionally utilizes its bandwidth based on node staking weight, alleviating the bottleneck issue of the leader and achieving high throughput. Ultimately, the total bandwidth can reach nearly optimal utilization. One of Rotor's design philosophies is that, in reality, the delay in information propagation is primarily limited by network latency rather than transmission or computation speed. Rotor employs a single-layer relay node instead of Turbine's multi-layer tree structure, thereby reducing the number of network hops. Additionally, Rotor introduces a new relay node selection mechanism to enhance robustness.
Alpenglow is the result of cutting-edge research, combining erasure-coded data distribution with the latest consensus mechanisms. Its innovations include an integrated one-round/two-round voting mechanism, resulting in unprecedented block finalization delays. It also introduces a distinctive "20+20 fault tolerance mechanism": even under severe network conditions, the protocol can operate normally, tolerating up to 20% of malicious staked nodes and an additional 20% of non-responsive nodes. Other contributions include a low-variance sampling strategy.
We have written a complete technical white paper detailing Alpenglow. The white paper not only explains the intuition and goals behind our design but also provides clear definitions and pseudocode to explain the entire protocol. It also includes various simulation data and calculations to help readers understand Alpenglow's actual performance, and finally, it provides a complete correctness proof.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
