Deep Dive: Alpenglow - New Consensus Protocol for Solana
🐦
twitter
📅 2025-12-29
📝 2678 字
🌐 zh
🔗 查看原始來源
📋 摘要
Solana 提出新共識協議 Alpenglow，旨在解決當前 TowerBFT 協議的延遲問題。TowerBFT 需要 33 個區塊時間才能確定性提交，屬於非響應式協議，雖能通過持續流水線最大化吞吐量，但決策延遲較高且形式化證明複雜。 Alpenglow 採用雙路徑架構：樂觀快速路徑在網絡條件良好時執行，併發慢速路徑作為對抗條件下的安全回退機制。協議將決策延遲從 33 個區塊時間大幅降至 1 個投票輪次，實現 33 倍改善。容錯界限設定為 3f + 2p + 1，其中 p 為快速路徑可容忍的拜占庭進程數，f 為維持安全性的最大拜占庭進程數。 協議保持 Solana 核心特性：持續流水線、負載均衡的提案傳播，同時簡化共識控制平面。Alpenglow 通過投票集（Voset）和轉子（Rotor）機制管理驗證者參與和領導者輪換，在維持高價值網絡安全保證的前提下，有效解決區塊鏈共識中吞吐量與延遲的根本權衡問題。
📄 完整內容
Deep Dive: Alpenglow
By Toghrul Maharramov (@toghrulmaharram)
Introduction
Consensus protocols form the basis of state machine replication (SMR): they define how a distributed set of parties reach agreement on a single, consistently ordered log of entries. In permissionless ledgers, consensus must ensure correct execution in the presence of Byzantine behaviour, while also meeting stringent performance requirements.
Solana's current stack: TowerBFT for consensus, Proof of History (PoH) as a timekeeping primitive and Turbine for block dissemination, was engineered to maximize throughput via continuous pipelining while ensuring dispersal remains load-balanced. However, the design choices of the protocol incur non-negligible decision latency and yield a structure that is challenging to prove in a formal setting. TowerBFT is non-responsive, achieving deterministic commitment only after a depth rule, which corresponds to an effective decision latency of 33 blocktimes.
This article examines Alpenglow, a newly proposed consensus protocol for Solana that aims to preserve continuous pipelining and load-balanced proposal dissemination while substantially reducing decision latency and simplifying the consensus control plane.
Alpenglow Overview
Alpenglow is a Byzantine fault-tolerant protocol that combines an optimistic fast path with a concurrent slow path and targets a resilience bound of 3f + 2p + 1, where p denotes Byzantine processes tolerated on the fast path and f denotes the maximum number of Byzantine processes that can be tolerated while maintaining safety.
Key Features:
1. Reduces decision latency from 33 blocktimes to potentially 1 voting round
2. Simplifies consensus control plane
3. Maintains continuous pipelining
4. Load-balanced proposal dissemination
5. Byzantine fault-tolerant with dual-path approach
Technical Architecture:
- Fast Path: Optimistic execution when network conditions are favorable
- Slow Path: Fallback mechanism ensuring safety under adversarial conditions
- Voset (Voting Set): Defines which validators participate in each round
- Rotor: Mechanism for leader rotation and block production
Comparison with TowerBFT:
- TowerBFT: 33 blocktime decision latency, non-responsive
- Alpenglow: 1 voting round latency (optimistic), responsive protocol
The protocol aims to solve the fundamental trade-off between throughput and latency in blockchain consensus while maintaining the security guarantees required for a high-value network like Solana.
Key Statistics:
- Resilience bound: 3f + 2p + 1
- Decision latency improvement: 33x reduction (from 33 blocktimes to 1)
- Maintains Solana's continuous pipelining architecture
By Toghrul Maharramov (@toghrulmaharram)
Introduction
Consensus protocols form the basis of state machine replication (SMR): they define how a distributed set of parties reach agreement on a single, consistently ordered log of entries. In permissionless ledgers, consensus must ensure correct execution in the presence of Byzantine behaviour, while also meeting stringent performance requirements.
Solana's current stack: TowerBFT for consensus, Proof of History (PoH) as a timekeeping primitive and Turbine for block dissemination, was engineered to maximize throughput via continuous pipelining while ensuring dispersal remains load-balanced. However, the design choices of the protocol incur non-negligible decision latency and yield a structure that is challenging to prove in a formal setting. TowerBFT is non-responsive, achieving deterministic commitment only after a depth rule, which corresponds to an effective decision latency of 33 blocktimes.
This article examines Alpenglow, a newly proposed consensus protocol for Solana that aims to preserve continuous pipelining and load-balanced proposal dissemination while substantially reducing decision latency and simplifying the consensus control plane.
Alpenglow Overview
Alpenglow is a Byzantine fault-tolerant protocol that combines an optimistic fast path with a concurrent slow path and targets a resilience bound of 3f + 2p + 1, where p denotes Byzantine processes tolerated on the fast path and f denotes the maximum number of Byzantine processes that can be tolerated while maintaining safety.
Key Features:
1. Reduces decision latency from 33 blocktimes to potentially 1 voting round
2. Simplifies consensus control plane
3. Maintains continuous pipelining
4. Load-balanced proposal dissemination
5. Byzantine fault-tolerant with dual-path approach
Technical Architecture:
- Fast Path: Optimistic execution when network conditions are favorable
- Slow Path: Fallback mechanism ensuring safety under adversarial conditions
- Voset (Voting Set): Defines which validators participate in each round
- Rotor: Mechanism for leader rotation and block production
Comparison with TowerBFT:
- TowerBFT: 33 blocktime decision latency, non-responsive
- Alpenglow: 1 voting round latency (optimistic), responsive protocol
The protocol aims to solve the fundamental trade-off between throughput and latency in blockchain consensus while maintaining the security guarantees required for a high-value network like Solana.
Key Statistics:
- Resilience bound: 3f + 2p + 1
- Decision latency improvement: 33x reduction (from 33 blocktimes to 1)
- Maintains Solana's continuous pipelining architecture
文檔 ID：
783da711-5c58-4b57-bb9c-226fd884be9e
向量 ID：
doc_783da711-5c58-4b57-bb9c-226fd884be9e
建立時間：
2025-12-29 11:16:54.900712
更新時間：
2025-12-29 11:16:54.900712