Alpenglow：Solana 共识机制的重大重构

可付诸实践的洞察 

• Alpenglow 为 Solana 带来的核心优势是将交易达到最终确定性的时间缩短 100 倍。根据验证者所在的地理位置，这一时间将从 12.8 秒降至 100–150ms，使 Solana 能够与更加中心化的 Web2 基础设施竞争，并支持实时应用。
• Alpenglow 移除了 Solana 的多个旧有组件，包括历史证明、Tower BFT 和基于 gossip 的投票传播，从而简化了共识机制。Alpenglow 不再使用历史证明，而是引入固定的 400ms 区块时间来协调全网时序；这与采用全局同步时钟并不相同。
• 该协议围绕两个基础组件构建：Rotor，一种对 Solana 现有 Turbine 架构进行扩展和改进的区块传播协议；以及 Votor，一种取代 Tower BFT、历史证明和通过 gossip 传播投票的新投票机制。
• 所有共识活动都将转移到链下——投票证书仍会锚定在链上，用轻量级 BLS 证书系统取代每个 slot 的投票交易。这项变更将消除目前形式的投票费用。投票费用一直是验证者的主要运营成本，因此该变更将显著改善小型运营商的验证者经济性。具体经济模型仍在最终确定中。
• Alpenglow 提供“20+20”韧性模型：即使多达 20% 的质押由对手控制，也能维持安全性；如果另外独立的 20% 质押离线或无响应，仍能维持活性。这使协议能够同时容忍恶意和不稳定的网络状况。
• Votor 使用双层并行投票系统来达成共识。在 Fast-Finalization 路径中，如果一个区块在第一轮获得 ≥80% 的质押批准，就会通过 Fast-Finalization Certificate 立即最终确定。在 Slow-Finalization 路径中，一旦区块获得 ≥60% 的质押批准，就会启动第二轮。如果这一轮达到 ≥60% 的批准率，区块就会通过 Finalized Certificate 最终确定。
• Turbine 依赖扇出为 200 的多层树状结构，而 Rotor 采用由中继节点处理 shred 分发的单跳模型。每个 shred 都作为单个纠删码数据包传输，并且 Rotor 的设计原生兼容 DoubleZero 等组播系统。请注意，与 Votor 相比，Rotor 很可能会作为一个独立的 SIMD 推进。
• Alpenglow 目前预计将于明年年初前部署到 Solana 主网。你可以在 Github 上找到该协议的参考实现。

引言

Alpenglow 共识算法是迄今为止对 Solana 核心协议最重大的重构。它借鉴区块链研究的最新进展，从根本上重新设计了全网达成共识的方式。

Alpenglow 由 Anza 新成立的研究部门开发。该部门由苏黎世联邦理工学院 Roger Wattenhofer 教授领导，该校是全球排名领先的计算机科学机构之一。Wattenhofer 教授是分布式系统领域的权威专家，此前曾共同撰写 2024 年论文 Halting the Solana Blockchain with Epsilon Stake，揭示了 Solana 当前共识协议中潜在的活性漏洞。他以前的博士生 Kobi Sliwinski 和 Quentin Kniep 也一同加入了 Anza。

该团队的任务是在保留 Turbine 架构的同时，重新设计 Solana 的共识算法，使其性能更高并具备可证明的正确性。Alpenglow 融合了分布式系统研究中的多项最新成果，尤其侧重于应对恶意网络行为。

Alpenglow 这个名称源自德语 Alpenglühen，意为“阿尔卑斯山辉”。它指日出或日落时山峰上出现的绚丽光芒，也是在致敬该协议的瑞士渊源。

Alpenglow 有哪些优势？

下面概括了 Alpenglow 有望带来的主要优势。本文其余部分将逐一深入探讨。

更快的最终确定性

Alpenglow 为 Solana 带来的核心优势是将交易达到最终确定性的时间缩短 100 倍，也就是大幅缩短用户交易在区块链网络上生根所需的时间。根据验证者所在的地理位置，这一时间将从 12.8 秒降至 100–150ms，使 Solana 能够与更加中心化的 Web2 基础设施竞争，并支持实时应用。

• **当前 Solana 最终确定时间：**12.8 秒 
• **当前 Solana 乐观确认时间：**500–600 毫秒
• **Alpenglow 最终确定时间：**150 毫秒（中位数）*
• **最快竞品的最终确定时间：**400 毫秒（自行报告）

*会随地理位置和集群分布而波动。

不再需要投票交易

使用 Alpenglow 后，所有共识活动都在链下进行。这将减轻交易处理单元（TPU）和重放环节的负载，因为它们不再需要处理投票交易。

Alpenglow 还将显著改善小型验证者的经济性。投票交易费用是验证者最大的运营支出。通过链下投票消除这些费用后，参与成本将大幅下降，小型验证者运营起来更为可行，也降低了参与维护网络安全的门槛。

其他优势包括简化承诺逻辑，以及减缓账本增长，因为投票交易不再占用区块空间或增大账本体积。

这一转变还有一个额外好处：消除了 Solana 每秒交易数（TPS）指标的歧义。目前，TPS 通常有两种报告方式：包含投票交易的总 TPS，以及仅统计非投票交易的真实 TPS。

更精简的协议

Alpenglow 移除了 Solana 的多个旧有组件，包括历史证明、Tower BFT 以及通过 gossip 传播投票，从而精简了达成共识的流程。它既融合了现代区块链研究的前沿成果，又没有引入不必要的复杂性。

Alpenglow 的 Votor 和 Rotor 为未来升级奠定了基础，例如异步执行和多并行领导者（MCL），让 Solana 能够继续提升性能并推动协议演进。

Solana 当前的共识机制是什么？

历史证明

历史证明（PoH）并非共识算法。它是一种辅助达成共识的工具。之所以容易产生混淆，可能是因为其命名方式——“X 证明”会让熟悉工作量证明和权益证明的人以为它也是一种共识算法。更恰当的理解是将其视为一种“预共识”算法，通过高效处理交易来简化共识。

从宏观上看，PoH 是一种去中心化时钟，用于在存在对手的网络中证明时间。更正式地说，PoH 是一种加密时间戳函数，让节点无需相互通信即可就事件顺序达成一致。它使用顺序执行、抗原像攻击的哈希函数创建哈希链。领导者使用这些哈希为区块添加时间戳，以证明已经过一段时间。由于所有哈希相互链接，PoH 能够提供历史记录，证明数据在特定时间点已经存在。 

这种方法不同于其他链：其他链通常在共识过程中确定区块顺序，之后再添加时间戳。Solana 则先构建一个可通过密码学验证的时钟，再按照该时钟传入交易，最后由共识验证已预先排序的交易日志。哈希链让时间顺序无可争议。 

Tower BFT

Tower BFT 在 shred（即部分区块）传播到其他验证者且网络完成重放后运行，以确定该区块是否成为账本的一部分。从概念上讲，它是一种类似 pBFT 的共识算法，旨在利用历史证明提供的全网时钟。验证者不必针对每个 slot 开展一轮同步共识，而是可以根据已经观察到的历史证明序列，预先承诺未来的 slot，从而实现持续出块。

验证者每个 slot 都会提交一笔由其投票账户签名的投票交易。对某一分叉的投票会触发该分叉的锁定期（即超时）。锁定期是指验证者无法对另一分叉投票的一段指定 slot 周期。这一机制旨在迫使验证者承诺选择一个分叉；如果想切换分叉，锁定期就会呈指数增长。每次投票都带有锁定计数器，验证者每当对后代 slot 投票时，计数器都会翻倍，从而形成由承诺组成的“投票塔”。因此，如果验证者为区块 X 投票，那么它将无法对任何冲突分叉投票，而且这一限制覆盖的未来 slot 数量会呈指数增长（例如 1、2、4、8……）。违反锁定规则的行为可以被证明并受到惩罚，不过罚没机制尚未部署到主网。

在 Tower BFT 下，Solana 实现了两个层级的最终确定性：乐观确认和确定性最终确认。 

当新区块生成且 ≥66% 的质押为其投票时，该区块会被视为领先分叉（即规范分叉）的一部分。这称为乐观确认，因为一旦获得绝大多数投票，区块就会被标记为“confirmed”承诺级别。乐观确认是在 Solana Labs（现为 Agave）客户端 v1.3 中引入的，通过在区块正式最终确定前将其视为已最终确定来改善 UX。

**自 Solana 创世区块以来，从未有任何经过乐观确认的区块被回滚。**若要回滚，至少三分之一的总质押必须在 66% 的质押已经诚实投票后公布冲突分叉。换言之，一旦区块的乐观确认数达到质押的 ~87%，对手就需要让其中 ≥20% 的质押进行双重签名，而这是可被证明并执行罚没的行为。尽管从严格的共识理论角度看，这并非绝对最终性，但乐观确认在实践中提供了强有力的保证。对于几乎所有用例，这些区块都可以视为已最终确定——因此从实际角度看，Solana 的最终确定时间通常被认为是 500–600 毫秒。

真正的确定性最终确认要求区块在投票塔中达到最大锁定，也就是由 32 个层叠投票确认。换句话说，一个区块必须在其上再构建 32 个区块，才能被视为已“finalized”或已在网络中生根。考虑到需要经过 32 个 slot，且每个 slot 时长为 ~0.4 秒，区块达到确定性最终确认需要 ~12.8 秒。当锁定投票深度使回滚变得不可能时，即实现确定性最终确认。

Solana 当前的共识机制有哪些局限？

历史证明和 Tower BFT 帮助 Solana 实现了高吞吐量和快速的乐观确认。但这种设计在成本、延迟、活性和验证者运营方面存在多项局限。

高昂的投票开销和成本

每个验证者都必须持续对每个 slot 投票，以参与共识。投票是与投票程序交互的交易，会消耗网络资源并支付费用。 

Solana 上约四分之三的交易都是投票交易，占用了大量网络资源，同时让验证者在每个 slot 都承担实际成本。这种对持续投票的不必要依赖会产生高昂开销和成本，并随处理的 slot 数量及集群中的验证者数量增长。 

最终确定延迟

乐观确认虽然很快，但确定性最终确认并不快。与 Sui 的 Mysticeti 等较新的共识协议相比，~12.8 秒相当缓慢，后者宣称最终确定时间约为 ~500ms。这会给交易所等需要绝对确定性的应用带来问题。实践中，用户会信任已确认区块，但在最终确定前可能发生小规模重组，因此网络仍需保留较长的分叉历史。 

乐观确认与确定性延迟之间的差距是一种权衡：Tower BFT 以更慢的最终确定速度为代价，通过保留一个较短的分叉应变窗口来优先保障活性。即使没有任何攻击或共识漏洞，~12.8 秒的最终确定时间与快速最终确定的区块链和现有 Web2 基础设施相比也相形见绌。

活性与网络分区容错能力

Tower BFT 要求绝大多数验证者在线并及时响应，才能确认和最终确定新区块。如果超过三分之一的质押离线，或者网络发生严重分区，共识就可能停滞。Solana 可能仍会优先保障活性并继续出块，但网络可能无法达到乐观确认这些区块所需的投票阈值。在最坏情况下，正如 Solana 近期宕机事件所示，验证者可能因等待投票或无法处理乐观分叉而触发网络停机，进而需要协调重启。

这是 BFT 共识的经典局限。Solana 没有内置机制来应对大量验证者暂时无响应。因此，在极端条件下，一旦无法达到共识所需的绝大多数阈值，协议就无法妥善应对，Solana 的活性也会受到影响。当在线质押不足 60% 时，Tower BFT 仍然必须继续出块。这意味着这些区块永远无法获得乐观确认，并且可能被回滚。

验证者运营复杂性

Tower BFT 对验证者要求很高：持续发送投票交易、维护可靠的网络、升级客户端、避免失职，以及持久化“投票塔状态”。如果验证者重启或丢失最新的投票塔状态，就可能投出违反此前锁定承诺的票，从而损失投票积分。

该协议依赖历史证明的持续哈希计算和通过 gossip 传播投票，这意味着验证者必须承担繁重工作，才能跟上 Solana ~400ms 的 slot 时间。尽管 Solana 的硬件要求正随时间推移而降低，但仍然不可小觑。此外，无论质押量多少，所有验证者都必须对每个 slot 投票以最大化奖励，这意味着在大多数情况下，小型验证者需要支付与大型验证者相同的费用并承担相同的工作负载。由于领导者 slot 按质押比例分配，质押更多的验证者会生成更多区块，因此也会获得其他验证者支付的更多投票费用。这形成了价值的循环流动，投票费用实际上会将资本重新分配给质押量更高的验证者。

此外，Solana 当前的共识机制让重复区块重放变得极其复杂，因为客户端需要管理同一 slot 的多个候选区块。Votor 的证书系统保证每个 slot 要么提交一个唯一哈希，要么明确跳过，因此重复区块重放变得非常简单。

显而易见，Tower BFT 的设计虽然具有创新性，却给验证者运营带来了相当高的复杂性。

Alpenglow 如何工作？

Alpenglow 围绕两个核心组件构建：

• Rotor：升级版区块传播协议，在现有 Turbine 架构基础上构建并加以增强。
• Votor：一种新的投票协议，在参与共识时取代 Tower BFT、基于 gossip 的投票传播和历史证明。

接下来，我们将详细介绍这些组件。

Rotor：新的数据分发层

Rotor 是一种增强型区块传播协议，以 Solana 现有的 Turbine 设计为基础，并在效率和简单性方面进行了重要改进。Turbine 使用扇出为 200 的多层树状结构，而 Rotor 使用单跳模型（2δ）。 

区块会被拆分为多个切片，每个切片随后使用 Reed-Solomon 纠删码编码为多个 shred。为确保 shred 的真实性，领导者会根据 shred 的哈希创建 Merkle 树并对树根签名。每个 shred 都包含其在该树中的路径和领导者的签名。

每个 shred 都会直接发送到中继节点。随后，中继节点将其 shred 广播给网络中的所有节点，并优先发送给下一任领导者。这种单层方式既降低了延迟，也简化了传播路径。其速度也出乎意料地快：

领导者和 shred 中继节点均通过质押加权抽样选出，这意味着每个节点按其质押比例负责传输数据。得益于纠删码，节点只需接收一部分 shred 即可重建原始区块切片。

Rotor 与 Turbine 的一个显著区别是，Rotor 只传输每个 shred 的单个纠删码版本，不再像 Turbine 那样分别发送数据 shred 和恢复 shred。虽然冗余度（即数据扩展比率）保持不变，但这种设计消除了围绕转发数据 shred 可能出现的各种异常博弈，确保协议设计保持简单。

Rotor 的架构还兼容 DoubleZero 等组播系统，为区块交付方式提供了灵活性。由于区块传播会消耗大量带宽（目前大型验证者每秒发送的数据包接近 150,000 个），Rotor 引入了一种奖励中继节点分发数据的模型，使激励机制与支持网络性能的目标保持一致。

Alpenglow 白皮书并未定义计算或分配奖励的具体机制。不过，其中指出 Rotor 奖励应考虑消耗的带宽，中继更多数据的节点预计会获得更高比例的奖励。

什么是 Blokstor？

Blokstor 是节点存储和管理从 Rotor 收到的区块数据的地方。更正式地说，Blokstor 是一种管理切片存储的数据结构。收到 shred 后，如果满足特定条件，其内容就会添加到 Blokstor，包括：

• Blokstor 尚未包含对应索引的 shred
• 有效的领导者签名
• 有效的 Merkle 树路径

当 Blokstor 收到 slot(b) 的第一个完整区块 b 时，会发出事件 "Block(slot(b), hash(b) hash(parent(b)))"。Blokstor 还可以执行修复流程，为同一 slot 收集并存储其他备选区块。当一个区块最终确定后，Blokstor 在对应 slot 中必须只存储该区块。

Votor：新的投票与最终确定引擎

Votor 是 Aplenglow 新的投票与最终确定引擎，取代 Tower BFT 来公证和最终确定区块。它从 Simplex 系列研究中汲取灵感，以提高效率和简单性，并将其应用于权益证明场景。 

Simplex 表明，在网络延迟上限足够严格的前提下，可以在领导者轮换的权益证明环境中使用极小的消息高效达成拜占庭协议。Votor 基于这些见解，在一轮或两轮内达成共识。

从宏观上看，Votor 会确保每个 slot 要么有一份表明该 slot 已被跳过的跳过证书，要么有一个基于规范公证区块链构建的已公证区块。区块必须拥有有效证书才能获得公证。验证者不会通过 gossip 大量发送投票，而是将轻量级投票消息广播给经过质押加权的对等节点集合，形成一种“直接发送”网状网络，而非传统的 Solana gossip。达到法定数量后，任何节点都可以使用 Boneh–Lynn–Shacham（BLS）签名方案，将这些签名聚合为证书。由于锚定到链上的是聚合证书头，因此不再需要每个 slot 的投票交易。

Votor 的投票机制如何工作？

Votor 使用分层并行投票机制，分为两条投票路径：

• Fast-Finalization：如果拟议区块在第一轮投票中获得 ≥80% 的质押批准，该区块会立即最终确定，并生成 Fast-Finalization Certificate。由于 80% 的质押远高于绝大多数阈值，因此可以通过一轮投票完成最终确定，无需开展第二轮投票。
• Slow-Finalization：如果第一轮投票获得的质押批准率为 <80% 但 ≥60%，Votor 会立即启动第二轮投票。一旦第二轮投票达到 ≥60% 的质押批准率，就会生成 Finalized Certificate。

两条路径并行运行，最先达到阈值的路径会最终确定区块。领导者完成父区块的摄取后，即可开始传输下一个区块，即使此时投票仍在累积。因此，与 Solana 旧共识机制相同，每 ~400ms 就会生成一个区块。这种设计确保第一轮未能获得 ≥80% 的质押批准时，Votor 会回退到第二轮投票。由于质押存在重叠，它也能确保两个冲突区块无法同时达到最终确定状态。

什么是 Votor 的 Pool 数据结构？

Pool 是每个节点维护的一种数据结构，相当于投票活动和证书生成的本地账本。它会记忆每个 slot 和每个节点收到的投票。收到足够多的投票后，就会生成相应证书。当新收到或自行构建的证书添加到 Pool 后，它会被广播给所有其他节点。 

虽然多个验证者可能几乎同时生成证书，但只要证书达到法定数量阈值，无论签名集合中包含哪些具体验证者，它们在共识功能上都是等价的。唯一例外是 Finalized Certificate，因为可能需要传播多达三种不同的认证。对于给定 slot，所有类型的唯一证书总数绝不会超过四份，而且每份唯一证书只广播一次。这种方法可以防止投票垃圾消息，同时仍允许任何诚实节点在 Pool 显示达到法定数量时立即构建并共享证书。

核心要点

投票以单个 UDP 数据包的形式传输给所有验证者，验证者会记忆每个 slot 和每个节点收到的投票。在 Votor 下，给定区块是否获得公证和最终确定由以下三个条件决定：

• 第一轮投票获得 ≥80% 的质押批准。
• 第一轮和第二轮投票均获得 ≥60% 的质押批准。
• 验证者从另一验证者处收到说明该区块已最终确定的有效证书。

不再需要历史证明

由于 Rotor 只需一跳即可传播区块数据，并且 Votor 的目标延迟上限为 ~150ms（下一节将深入介绍），Solana 不再需要去中心化时钟。简单的本地时钟就已足够。Alpenglow 使用本地超时计时器取代历史证明。

Votor 的超时机制如何工作？

在实践中，超时系统按以下方式运行：

• 领导者窗口：领导者将负责一个包含四个 slot 的窗口，每个 slot 的 Δblock ≈ 400ms。
• 数据到达或超时：领导者的父区块一经公证，每个验证者就会启动超时机制，并预设四个截止时间，每个 slot 一个，计算方式为 t = now + Δtimeout + slotIndex * Δblock，其中 Δblock ≈ 400ms。请注意，这些计时器永远不会重置，而是作为时间上限。如果区块的 shred 及时到达，验证者就会使用 NotarVote 消息为该 slot 投票，待处理的超时则不执行任何操作。但如果在任何 shred 到达前计时结束，验证者就会认为领导者不诚实或失职，并发出 SkipVote。
• 认证：如上所述，已公证区块会生成 Fast-Finalization Certificate 或 Finalized Certificate。被跳过的 slot 也可以生成 Skip Certificate。

Alpenglow 引入了一套让每个验证者在本地独立测量超时的系统。因此，Solana 不再需要像历史证明那样由哈希驱动的统一时钟。由于消息只有一个 UDP 数据包，Rotor 也只需一跳，因此即使不进行哈希计算，400ms 的上限也切实可行。验证者不再需要持续计算哈希，可以在不受锁定限制的情况下反对区块，而且 Firedancer 等替代客户端也不必被迫复刻 Agave 客户端的历史证明实现。

跳过 Slot

验证者还可以发送 SkipVote 消息来跳过 slot。如果 ≥60% 的质押发出 SkipVote 消息，就会生成 Skip Certificate，并正式跳过该 slot。跳过投票和公证投票具有相同的奖励权重，因此当领导者行为不当时，验证者没有保持沉默的动机。请注意，Alpenglow 的经济模型最终确定后，这一点可能会改变。

当验证者确定无法最终确定某个 slot 的区块时，就会为该 slot 发送 SkipVote。原因可能是达到超时期限、缺失区块，或者区块无效或格式错误。如果领导者四 slot 窗口中的第一个 slot 触发了其中任一条件，验证者就会将整个窗口标记为不良，接着遍历窗口中的剩余 slot，并为每个尚未投票的 slot 发出 SkipVote。因此，整个四 slot 窗口可以压缩成一轮跳过流程。每张票仍只对应一个 slot，但由于大多数验证者会同时批量执行相同操作，三个待处理 slot 会在大致相同的时间达到 60% 阈值。这样可以避免离线领导者超时时，集群还要空等另外三个空 slot。

显然，这会导致区块生产出现空缺。不过，得益于这些快速跳过证书，slot 的节奏不会中断。这简化了分叉选择并提高了一致性，因为跳过证书相当于该 slot 的规范“空区块”，所有诚实节点都会接受跳过这一结果。因此不会产生竞争分叉，跳过 slot 也不会造成持久分叉，常规出块节奏得以维持。

验证者奖励

Votor 下的验证者奖励取决于其对投票和证书生成的参与情况。通过投票参与共识的节点，无论是支持区块（NotarVote）还是反对区块（SkipVote），都会获得同等奖励。这会鼓励诚实参与，确保节点根据自身状态投票，而不是试图预测或迎合多数派。

目前尚未明确具体的奖励实现方式。

Alpenglow 性能基准与模拟结果

Anza 的模拟显示，Alpenglow 大约需要 100-150ms 即可完成区块终局确认，具体取决于区块是通过快速终局路径还是回退路径（即慢速终局路径）完成公证。快速终局路径的延迟目标为 ~100ms，而慢速终局路径的延迟目标为 ~150ms。

延迟直方图

网络延迟为任何分布式系统中的通信设定了根本下限。例如，如果领导者位于纽约，而多数质押权重位于欧洲，那么节点向其他网络节点发送信息的单向延迟中位数可能达到约 200 毫秒。地理位置相近的节点（例如位于同一数据中心或区域内的节点）延迟较低，而位于全球南方或其他遥远地区的节点延迟则明显更高。

• **网络：**通过互联网向其他节点发送 1 比特数据的网络延迟
• **Rotor：**Rotor 相比这一下限慢多少
• **公证：**接收来自 60% 质押权重的公证投票所需的时间（也可以再进行一轮投票；收到投票后即可开始终局确认）
• **终局性：**完成终局确认所需的时间

Alpenglow 的整体终局确认时间是该下限的 2 倍。也就是说，共识开销会使原始网络延迟下限乘以 2。因此，如果领导者与拥有绝对多数质押权重的节点之间最长单向传输耗时为 ~70ms（即 RTT 为 ~140ms），快速路径的终局确认时间应落在 120-150ms 范围内。

Anza 模拟得出的延迟直方图显示，65% 的质押权重可在原始网络延迟之后的 50ms 内完成终局确认。这意味着大多数验证者几乎会在数据到达后立即投票。

借助 Alpenglow，确定性承诺的延迟远低于任何竞争性 L1，让 Solana 的链上体验更接近传统 Web2 服务。

Alpenglow 安全性与容错分析

Alpenglow 的共识机制改进了传统 BFT 共识；后者能够抵御控制最多 33% 网络质押权重的对手。这表示为“3f + 1”。基于 Martin 和 Alvisi 在 快速拜占庭共识 中提出的 5f + 1 界限，Alpenglow 将这一上限降至网络质押权重的 20%。它采用“20+20”韧性模型，将保障分为两部分：

• 拜占庭故障 ≤ 20%：如果对手控制的质押权重不足总质押权重的 20%，安全性便可得到保证。这涉及数十亿美元的巨额资金，而且很容易被识别并惩罚。因此，攻击者可能失去全部质押资产，这让此类攻击在经济上不可行。
• 非恶意故障 ≤ 20%：如果与对手质押权重相互独立的离线、崩溃或因其他原因未参与共识的质押权重最多占总质押权重的 20%，活性便可得到保证。这包括网络中断、配置错误和软件缺陷。因此，即使相当一部分验证者没有响应，网络仍可继续完成区块终局确认。

安全性

只要对手控制的总质押权重 ≤20%，且无法阻止至少 60% 的诚实质押权重参与同一分叉，安全性便可得到保证。这些条件确保协议视为终局的任何投票阈值（即单轮快速路径和双轮慢速路径）都足够高，使另一个分叉无法获得与之冲突的阈值。如果对手验证者试图进行双重投票（即为两个不同分叉投票，或在同一时隙中生成两个不同区块），诚实节点最终会收到其相互冲突的签名。这种行为很容易识别，理想情况下，未来会成为可通过罚没等方式惩处的违规行为。 

此外，如果领导者试图生成无效区块，诚实验证者只需拒绝为其投票。Alpenglow 采用直接通信的投票模型，使恶意参与者很难隔离或遮蔽拥有质押权重的诚实节点，因为诚实多数的投票最终会暴露其行为。恶意领导者最多只能迫使共识进入较慢的路径，或造成一个时隙的延迟，但无法永久阻塞网络或导致链发生分歧。

活性

只要不超出故障阈值，活性在部分同步条件下便可得到保证。这意味着，经过一定的网络延迟后，诚实验证者将能够通信，并为某个区块汇集 ≥60% 的质押权重。如果恰好有 20% 的总质押权重离线，只要其余所有诚实节点都投票，快速路径仍可能成功。如果略多于 20% 的总质押权重离线，网络将持续使用慢速终局路径进行第二轮投票。终局性仍可得到保证，但速度会有所降低。因此，良性故障主要影响性能，而非安全性。

高崩溃韧性

Alpenglow 在设计时明确考虑了高崩溃韧性，以应对恶劣的网络条件。也就是说，在 20% 的质押权重具有恶意、另有 20% 的质押权重无响应的情况下，Alpenglow 仍将保持安全并继续运行。 

不过，这并不是解决所有可能故障的万能方案。Alpenglow 是 Solana 的一项重大改进，但如果其假设遭到破坏，它并不能完全消除网络暂停或中断的风险。生成新区块需要 ≥60% 的质押权重，而 ≥20% 的质押权重采取恶意行为可能会阻止共识或导致故障。尽管如此，在既定限制内，Alpenglow 可保证在一轮或两轮投票内实现安全性和活性。

移除历史证明会削弱安全吗？

尽管历史证明是 Solana 当前运行机制的基础，移除历史证明不会以任何实质性方式削弱安全性。如前所述，统一的 400ms 界限将取代历史证明哈希时钟。即使网络出现严重延迟，Votor 中质押权重的重叠（即单轮 ≥80%，双轮 ≥60% + ≥60%）也能防止诚实验证者批准两个不同的分叉。

不过，这确实会改变活性保证，因为活性依赖同步消息——只要诚实消息在这一延迟范围内到达，活性就能得到保证。Rotor 的单跳数据传播和单数据包投票意味着，即使在压力之下，延迟也能远低于 400ms 的范围。

总体而言，移除历史证明将消除对持续哈希计算的依赖，从而移除任何通过阻塞哈希计算发动攻击的途径。如上所述，这也会改变活性保证。但移除历史证明不会以任何实质性方式削弱安全性。

关键要点

Alpenglow 以略微降低拜占庭容错能力为代价，换取亚秒级确定性终局性、对大规模良性中断的平稳处理，以及更容易识别恶意验证者。这些要点可概括如下：

• 除非 ≥20% 的质押权重进行双重签名，否则两个相互冲突的区块无法同时完成终局确认；这种行为极易证明并可予以惩罚。
• 只要 ≥60% 的质押权重能够通信，即使其余质押权重全部离线，Solana 仍会继续完成区块终局确认。
• 最坏情况下，终局确认会回退到第二轮投票，目标延迟为 ~150ms，因此攻击会先降低链的速度，而不会威胁其安全性。
• 突破 20% 拜占庭上限的成本高得令人望而却步；在主网上线罚没机制后，规模较小的不当行为则可以被发现，并通过社会和经济手段予以惩罚。

Alpenglow 对验证者有何影响？

投票成本是运行 Solana 验证者的最大准入障碍。运行验证者并没有严格的 SOL 最低要求。不过，要参与共识，必须在每个时隙发送投票交易，这每天可能耗费多达 ~1 SOL。

Alpenglow 计划用紧凑型证书系统取代每时隙投票交易，从根本上取消目前的投票费用。每个验证者会向其他所有节点广播轻量级投票消息。达到法定人数后，任何节点都可通过 BLS 签名方案将这些签名聚合成证书。由于这些投票已通过 BLS 聚合，链上只需锚定证书头。实际而言，这将消除每个验证者每天约 ~1 SOL 的成本。 

如前所述，在 Alpenglow 中，每个区块提案都会通过两条并行的投票路径进行评估：

• 快速终局（单轮）
  • 当第一轮投票中某个区块的公证投票总数达到 ≥80% 的质押权重时触发
  • 生成快速终局证书 
  • 延迟目标为 ~100ms
• 慢速终局（双轮）
  • 当第一轮投票中某个区块的公证投票总数达到 ≥60% 的质押权重时触发
  • 当第二轮的公证投票总数达到 ≥60% 的质押权重后，生成终局证书
  • 延迟目标为 ~150ms

Votor 会并行运行两条路径，这意味着两边的票数都由同一个第一轮投票流更新，首个达到阈值的证书将使区块完成终局确认。重叠的质押权重集合（即 ≥60%）确保两个相互冲突的区块绝不可能同时达到终局状态。

这一新设计对验证者的运营有以下积极影响：

降低运营成本 

取消投票费用大幅降低了潜在验证者的准入门槛。另一方面，投票费用曾使小型验证者在熊市期间更加依赖通胀奖励。考虑到 SIMD-228 的投票颇具争议，取消这项费用可能促使社区在未来讨论 Solana 的通胀问题。按照目前讨论中的 Alpenglow 实现方案，根据 Cogent Crypto 的验证者利润计算器计算，这一成本削减将使实现盈利所需的最低 SOL 数量从 ~4850 SOL（~80 万美元）降至 ~450 SOL（~7.5 万美元）。

简化密钥管理 

Solana 验证者不再需要为每个时隙的投票签名。这意味着验证者身份密钥可以存放在硬件安全模块（HSM）中，而不会带来任何性能风险，从而有效降低热钱包风险。

降低领导者时隙的网络负载

每个区块聚合一个证书，可取代每个 epoch 中数千笔独立的投票交易，从而降低领导者时隙的网络负载。 

无需锁定期计算

Solana 的 Tower 式指数锁定表将被移除。现在，验证者只需在内存中追踪最新的证书链，从而缩短重启时间。

Alpenglow 对 RPC 提供商有何影响？

这一新设计对 RPC 提供商运营的影响大多是积极的，但其中少数可能引发可扩展性问题：

简化承诺级别 

这种新的终局性级别将消除 confirmed（即乐观确认）与 finalized（即已生根）承诺级别之间长期存在的差异。例如，任何等待两个确认级别的 UX 逻辑（如在 finalized 前一直显示加载图标）都可以简化为单次证书检查。

减少账本大小

按照 Solana 当前的需求，由于不再有投票交易，账本增长量将减少约四分之三。这也意味着快照和归档的大小会减小。不过，鉴于区块 CU 上限的预计提升目标，实际效果仍有待观察。

WebSocket 扇出瓶颈

在 Alpenglow 中，轮询交易不再有意义，因为终局确认会在 ~100-150ms 内到达，并编码在单个证书中。通过一个在应用、浏览器或机器人的整个生命周期内保持开放的推送通道获取终局性信息会更加合理，该通道会向每个订阅客户端广播每个新证书。痛点将从数百万次微型 HTTP 轮询转变为数十万个实时套接字。

实时缓存新鲜度

由于证书会在 100-150ms 内使区块完成结算，任何将账户数据保留超过四分之一秒的缓存都有可能返回过时数据。边缘缓存、CDN 和第 7 层代理将需要极短的 TTL，或能够识别证书的缓存清除钩子。

Alpenglow 的开发时间表是什么？

Alpenglow 于 5 月下旬在纽约 Accelerate 大会上正式发布。下一阶段将发布正式的 Solana 改进文档（SIMD），并通过 GitHub、Solana 治理论坛和 Solana Tech Discord 向社区开放反馈渠道。

社区评审期结束后，该提案将进入由验证者社区参与的链上治理投票。与此同时，新设计将接受广泛测试，以确保其性能和安全性。

如果所有阶段均按计划推进，预计将于明年初部署到 Solana 主网。

Alpenglow 的风险与待解问题

一种新的共识算法

迁移到新的共识协议是一项重大工程，但已有重要先例。Ethereum 2022 年的合并证明，大型在线网络可以在不中断运行的情况下，成功将其核心共识机制从工作量证明迁移到权益证明。换言之，尽管仍存在许多风险，但这并非完全未知的领域。

这种迁移还需要配套的迁移指南，避免 Alpenglow 将 confirmed 和 finalized 承诺级别合并为单次证书检查后，应用、SDK、钱包和机器人在没有提示的情况下失效。任何明确轮询两个承诺级别或默认使用 confirmed 承诺级别的代码都将停止工作。在 Alpenglow 上线前，整个生态系统需要围绕文档、lint 警告、RPC 方法和整体代码架构展开协调。 

治理

治理风险是另一个需要考虑的因素。最近的 SIMD-228 投票表明，Solana 是一个真正去中心化的网络：即使提案得到核心开发者和知名社区成员的支持，也无法保证一定通过。不过，Alpenglow 带来的变化，尤其是投票成本的降低，普遍有利于验证者，特别是小型运营商。因此，我们认为其遭遇治理阻力的可能性相对较低。

奖励

迄今发布的 Alpenglow 白皮书及相关材料并未明确说明奖励验证者投票活动或补偿 Rotor 中继带宽用量的具体机制。白皮书也明确指出，双重投票行为将受到惩罚，但并未说明实际由谁提交处罚、处罚金额有多大，以及相关惩罚是自动执行还是由治理决定。这些缺失让验证者经济模型的关键方面仍未确定，并可能成为生态系统中争议激烈的讨论焦点。

MEV

Alpenglow 也将从根本上重塑 Solana 当前的 MEV 格局。延迟仍是影响 MEV 的关键因素，因为某些盈利策略依赖于镜像 TPU 流量，或在交易获得乐观确认前，按特定顺序通过垃圾消息取消并替换交易。目前，这一切都发生在 ~500-600ms 的窗口内，而 Alpenglow 计划将其缩短至 ~150ms。乍看之下，领导者，尤其是已经托管定制区块构建基础设施的验证者，将有机会获取更大份额的 MEV；而独立延迟套利者可能会失去优势，除非他们继续开发速度更快、粒度更细的交易系统。

多个并发领导者

相比 Solana 当前的共识架构，Alpenglow 的设计能够更灵活地采用多领导者框架，即多个并发领导者（MCL）。正如 Anatoly Yakovenko 所指出的，初版 MCL 原型可以启动两个共享同一 Rotor 集合的 Alpenglow 实例，并同时发布所有分片。Rotor 会扇出这些并行数据流，Votor 则会为每条通道进行公证。不过，这也会引出若干执行层问题。具体而言：

• 应该如何划分写入集，才能确保两个领导者的区块永远不会锁定同一账户；或者，如果发生锁定冲突，如何让冲突解决过程既具确定性又成本低廉？
• 如何将各通道的证书合并为一个规范状态根，同时避免让重放成本翻倍？
• 当不同通道争夺资产时，应采用何种费用市场逻辑？
• 这会催生哪些跨通道 MEV 策略？
• 如果没有通道上限，单个高质押权重验证者是否可能主导并发时隙？ 

Alpenglow 的设计通过移除共识层障碍，使 MCL 成为切实可行的路线图项目。不过，在这些待解问题得到回答之前，它仍然只是一项前景可期的未来计划。

结论

本报告探讨了 Alpenglow 的核心组件，并研究了它们如何重塑 Solana 的共识模型。我们还分析了技术改进、验证者经济模型变化、网络层影响，以及它在性能、简洁性和可扩展性方面带来的优势。

Alpenglow 白皮书标志着 Solana 的转折点，不仅体现在协议设计上，也体现在开发理念上。Solana 首次为其共识算法发布正式的正确性证明，表明它正从传统的实证型、工程驱动方法，转向更加严谨、由研究支撑的基础。这一演变反映出生态系统正在走向成熟：它继续将性能放在首位，同时引入形式化验证所带来的严谨性。

弃用历史证明（PoH）同样代表着网络身份的象征性转变。尽管 PoH 的实际重要性经常被夸大，但长期以来，它一直是 Solana 的标志性创新，在技术入门资料中占据显著位置，并已成为该品牌的代名词。移除 PoH 标志着一个时代的结束和新时代的开始。Solana 正在走向成熟。

其他资源

• Accelerate Alpenglow 演示幻灯片 - Roger Wattenhofer
• Alpenglow：Solana 的新共识 - Anza 博客
• Alpenglow 参考实现 - GitHub
• Alpenglow 白皮书 - Quentin Kniep、Jakub Sliwinski、Roger Wattenhofer
• Solana 共识机制 - Helius 博客
• 在 Accelerate 2025 上扩展或消亡：介绍 Alpenglow——Solana 的新共识 - YouTube 视频