Original title: Alpenglow: A New Consensus for Solana
Original author: Quentin Kniep, Kobi Sliwinski and Roger Wattenhofer
Original translation: zhouzhou, BlockBeats
Editors Note: Alpenglow is a new consensus protocol launched by Solana, which replaces the original TowerBFT and historical proof mechanism, introduces Votor and Rotor, optimizes voting and data dissemination, significantly reduces latency to 100-150 milliseconds, and achieves finality in seconds. The protocol enhances performance, elasticity and scalability, making Solana comparable to Web2 in response speed.
The following is the original content (for easier reading and understanding, the original content has been reorganized):
We are proud to introduce Alpenglow, Solana’s new consensus protocol. Alpenglow is a consensus protocol tailor-made for the world’s high-performance Proof-of-Stake blockchains. We believe the launch of Alpenglow will be a turning point for Solana. It is not only a new consensus mechanism, but also the biggest change to the core protocol since Solana’s founding.
In the process of migrating to Alpenglow, we will say goodbye to a series of old core components, especially TowerBFT and Proof-of-History. We have introduced a new module Votor to take over the voting and block final confirmation logic. In addition, Alpenglow abandons the gossip-based communication method and adopts a faster direct communication primitive.
While this is a significant change, Alpenglow builds on Solana’s greatest strengths. Turbine plays a key role in the success of the Solana network by solving an important problem: data propagation. In traditional blockchains, leaders are often the bottleneck of the system.
The technology used by Turbine splits each block into many smaller fragments through erasure coding and spreads them out 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 concept of Turbine.
Through these changes, we have pushed Solanas performance to unprecedented heights. When using TowerBFT, it takes about 12.8 seconds from block generation to final confirmation. In order to reduce latency to sub-second levels, Solana 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 incredible speed for a global L1 blockchain protocol. (These latency figures are based on simulation results based on the current mainnet staking distribution and do not include computational overhead.)
A median latency of 150ms doesn’t just mean Solana is faster — it means Solana’s responsiveness is on par with Web2 infrastructure, which has the potential to make blockchain technology viable for entirely new application areas that require real-time performance.
The figure above shows the latency distribution of each phase of the Alpenglow protocol when the leader is located in Zurich, Switzerland. We chose Zurich as an example because we were based in this city when we developed Alpenglow.
Each bar shows the average latency of the current Solana nodes distributed around the world, sorted by distance from Zurich.
The figure plots the simulated delays of each node in the network arriving at different stages of the Alpenglow protocol, corresponding to the proportion of network nodes that have reached that stage.
The green column represents network latency. Based on the current node distribution of Solana, about 65% of the staking nodes have a network latency of less than 50 milliseconds from Zurich. However, the latency tail is longer, with some staking nodes having a network latency of more than 200 milliseconds from Zurich.
Network latency forms a natural lower bound in our graph - for example, if a node is 100ms from Zurich, then any protocol that wants to finalize a block at that node will also need at least 100ms.
The yellow bars represent the latency of Rotor (data propagation protocol), which is the first phase of the Alpenglow protocol.
The red bars represent the time it takes for the node to receive notarization votes from at least 60% of the staked weight.
The blue column is the final confirmation time.
So, where does Alpenglow’s high performance come from?
Alpenglows voting component Votor implements an extremely efficient single-round voting mechanism: if 80% of the staking nodes participate, the block can be confirmed in one round of voting; if only 60% of the staking nodes respond, it can also be completed within two rounds of voting. These two modes are integrated and executed in parallel. Whichever is faster will be used to finally confirm the block.
Alpenglows data dissemination sub-protocol Rotor continues and optimizes Turbines approach. Similar to Turbine, Rotor utilizes its bandwidth in proportion to the nodes stake weight, thereby alleviating the problem of the leader becoming a bottleneck and achieving high throughput. In the end, the total bandwidth can achieve near-optimal utilization. One of Rotors design concepts is that in reality, the delay in information dissemination is mainly limited by network latency, rather than transmission or computing speed. Rotor uses a single-layer relay node instead of Turbines multi-layer tree structure, which reduces the number of network hops. In addition, Rotor has introduced a new relay node selection mechanism to improve robustness.
Alpenglow is a 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, which brings unprecedented block final confirmation delays. At the same time, it also introduces a unique 20+20 fault tolerance mechanism: even if network conditions are severe, the protocol can still operate normally, tolerating up to 20% of malicious staked nodes and an additional 20% of unresponsive nodes. Other contributions include a low-variance sampling strategy.
We have written a complete technical white paper that describes Alpenglow in detail. The white paper not only explains the intuition and goals behind our design, but also explains the entire protocol with concise definitions and pseudocode. It also includes a variety of simulation data and calculations to help readers understand the actual performance of Alpenglow, and finally provides a complete correctness proof.
