Original Title: Alpenglow: A New Consensus for Solana Original authors: Quentin Kniep, Kobi Sliwinski, and Roger Wattenhofer Original compilation: zhouzhou,

Editor's Note: Alpenglow is a new consensus protocol launched by Solana, replacing the original TowerBFT and historical proof mechanisms, introducing Votor and Rotor, optimizing voting and data propagation, significantly reducing latency to 100–150 milliseconds, achieving sub-second finality. This protocol enhances performance, resilience, and scalability, allowing Solana to achieve a response speed comparable to Web2.

The following is the original content (for ease of reading and understanding, the original content has been restructured):

We are proud to introduce Alpenglow, Solana's brand new consensus protocol. Alpenglow is a consensus protocol designed for global high-performance Proof-of-Stake blockchains. 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 biggest change to the core protocol since Solana's inception.

During the migration to Alpenglow, we will say goodbye to a series of old core components, especially TowerBFT and Proof-of-History. We have introduced a brand new module called Votor to take over the voting and block finality logic. Additionally, Alpenglow has discarded the gossip-based communication method in favor of a faster direct communication primitive.

Despite being a significant transformation, Alpenglow is still built on the foundation of Solana's greatest advantages. Turbine has played a key role in the success of the Solana network, addressing the important issue of 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 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 concept of Turbine.

Through these transformations, we have pushed Solana's performance to unprecedented heights. When using TowerBFT, it takes about 12.8 seconds from block generation to final confirmation. 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 global L1 blockchain protocols. (These latency data 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 that Solana is faster—it means that Solana's responsiveness can rival that of Web2 infrastructure, which has the potential to make blockchain technology viable in new application areas that require real-time performance.

The diagram above shows the delay 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 chart shows the average latency of the current Solana nodes in global distribution, sorted by distance from Zurich.

The figure illustrates the simulated latency of each node 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, approximately 65% of the staked nodes have a network latency of less than 50 milliseconds from Zurich. However, the latency tail is quite long, with some staked nodes having a network latency exceeding 200 milliseconds from Zurich.

Network latency constitutes a natural lower bound in our charts—for example, if a node is 100 milliseconds away from Zurich, then any protocol attempting to achieve block finality at that node will require at least 100 milliseconds.

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

The red bar represents the time spent for the node to receive at least 60% of the staked weight of the notarized votes.

The blue bars represent the final confirmation 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 the staked nodes participate, the block can be confirmed in one round of voting; if only 60% of the 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 one being chosen to ultimately confirm the block.

Alpenglow's data propagation subprotocol, Rotor, continues and optimizes Turbine's approach. Similar to Turbine, Rotor utilizes its bandwidth proportionally based on node staking weight, alleviating the bottleneck of leaders and achieving high throughput. As a result, the total bandwidth is utilized to a near-optimal level. One of Rotor's design ideas is that, in reality, the latency of information propagation is primarily limited by network latency, rather than transmission or computing speed. Rotor uses a single layer of relay nodes instead of Turbine's 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 based on cutting-edge research, combining erasure coding for data distribution with the latest consensus mechanisms. Its innovations include an integrated one-round/two-round voting mechanism, which brings unprecedented block finality delay. Additionally, it introduces a distinctive "20+20 fault tolerance mechanism": even under severe network conditions, the protocol can still operate normally, tolerating up to 20% of maliciously staked nodes and an additional 20% of unresponsive nodes. Other contributions include a low-variance sampling strategy.

We've written a full technical white paper detailing Alpenglow. The white paper not only explains the intuition and goals behind our design, but also explains the entire protocol with clear and concise definitions and pseudocode. It also includes a variety of simulation data and calculations to help the reader understand Alpenglow's actual performance, and finally provide a complete proof of correctness.

"Original link"

：