150 毫秒的野心：Solana 想让「最终确定」更快。

撰文：KarenZ，Foresight News

Solana 已经是加密行业速度最快的公链之一，但它仍有一件事不够快：给交易盖上最终确认的印章。

在 Solana 上，一笔交易可能只需要几百毫秒就能获得初步确认，但要等到网络认定这笔交易已经最终确定、无法通过正常共识流程撤销，通常还需要十几秒。

对普通用户来说，这段等待时间未必明显。但对高频交易、链上支付、稳定币结算，以及越来越多由 AI Agent 自动发起的交易而言，交易被快速处理和交易获得最终确定性，是两回事。

如今，Solana 准备对这个问题进行一次重大升级。

10 月 13 日，Solana 核心开发团队 Anza 公布了 Alpenglow 升级（SIMD-0326）的主网激活安排，计划于 10 月 21 日将 Solana 主网的共识协议从 TowerBFT 切换至 Alpenglow。此次升级的核心目标，是将原本以秒计的区块最终确认时间缩短至约 150 毫秒。

这不是简单地提高 TPS，也不是一次普通的性能优化。Solana 将替换自创世以来一直使用的核心共识协议，重新设计验证者如何投票、如何就区块达成一致，以及在网络出现故障时如何继续运行。

更值得关注的是，这场酝酿了一年多的升级，预计只需要在一个区块槽位内完成关键切换。

Solana 已经够快了，为什么还需要 Alpenglow？

理解 Alpenglow，首先要弄清「最终性」。

通俗地说，最终性意味着：在协议安全假设成立的前提下，一个已经确定的区块，不会再被后续共识换掉。

Solana 此前采用基于 Proof of History（PoH，历史证明）和 TowerBFT 的共识机制。其中，PoH 提供可验证的事件顺序，TowerBFT 则利用验证者投票，让网络逐渐对区块的有效性和最终状态达成一致。

原有 TowerBFT 机制下，confirmed 与 finalized 对应不同的确认程度；Alpenglow 启用后，在共识语义上，confirmed 与 finalized 将趋于等价。

官方提出的约 150 毫秒，描述的是正常网络条件下的最终性目标。

v1.2 白皮书进一步说明了性能数字的来历：在按照质押权重随机选择出块者的模拟中，中位最终确定时间约为 130 毫秒。模拟采用特定的质押分布、节点间网络延迟和带宽假设，并未计入区块执行时间。由于首阶段主网升级暂不包含 Rotor，130 毫秒不能直接视为此次升级后的主网实测表现。

Votor：不再等待 32 个槽位，两条投票路径同时竞争

Alpenglow 的核心创新之一，是一套名为 Votor 的投票机制。

它的设计思路并不复杂：与其让新区块等待后续多个区块逐步累积最终确认，不如让验证者直接投票，在足够多的质押权重同意后立即完成最终确认。

可以把全网质押权重想象成 100 份表决权。Votor 同时运行两条最终确定路径：

• 一轮路径：收到代表至少 80 份权重、支持同一区块的首轮投票，就能形成快速最终确定证书。
• 两轮路径：当支持同一区块的首轮投票达到 60% 质押权重后，进入第二轮投票；如果第二轮也达到 60% 的质押权重门槛，该区块即可获得最终确认。

两条路径并行运行，先完成有效最终确认的一条生效。百分比指参与投票的质押权重，而非验证者数量。

这个设计的巧妙之处在于，轮数少，不一定总比轮数多更快。 如果代表 60% 权重的节点彼此通信很快，它们完成两轮投票，可能比等待分布更远的 80% 权重完成一轮还早。Votor 允许节点采用先完成的有效路径，从而适应不同的网络位置和通信条件。

除了缩短最终确认时间，Votor 还改变了验证者的投票方式。

在原有的 TowerBFT 机制下，Solana 验证者通过链上交易提交投票，需要占用链上数据和交易处理资源。Alpenglow 启用后，参与共识的验证者将直接交换带有 BLS 签名的投票消息；收集到满足相应质押权重门槛的投票后，节点可以通过签名聚合形成简洁、可验证的证书。这样，共识投票不再需要逐笔作为交易写入区块，从而减少链上投票带来的数据与处理开销。

与此同时，Votor 还引入了明确的跳过机制。如果区块生产者未能及时提供有效区块，验证者可以投票跳过相应槽位，避免网络持续等待。

与此相配套，Alpenglow 不再依赖历史证明（PoH）推进原有的共识流程，而是通过验证者的本地计时器、投票消息和相关证书协调共识。

Rotor：Solana 还想打破区块传播的带宽瓶颈

如果说 Votor 解决的是区块如何更快得到最终确认，那么 Alpenglow 的另一项设计 Rotor，试图解决的是区块如何更高效地传播到全球验证者。

Alpenglow 的完整设计涉及多个组件，但首阶段部署重点是 Votor。负责传播区块数据的 Turbine 暂时保留；白皮书里的新传播方案 Rotor 将另行部署。

Solana 当前采用 Turbine 协议传播区块数据。Turbine 将数据分成较小的片段，再通过多层节点转发，避免区块生产者必须独自将完整区块发送给所有验证者。

Rotor 延续了数据切片和纠删码的思路，但进一步调整了传播方式。

按照白皮书设计，区块生产者将数据编码为多个片段，发送给不同的中继节点，再由这些节点向网络中的其他节点转发。与 Turbine 的多层传播树相比，Rotor 旨在通过单层中继传播和按质押权重分配转发任务，更充分地利用整个验证者网络的上传带宽。

此外，Rotor 使用纠删码，即使某些数据片段未能成功到达，接收方也有机会凭借足够数量的其他片段重建完整数据。

从设计上看，这有助于提高区块传播的效率和容错能力，也可以缓解单个区块生产者上传带宽带来的限制。Rotor 的更大意义，是为 Solana 后续提高区块数据吞吐能力创造条件

「20+20」容错模型，Solana 正在重新定义容错边界

速度提升之外，Alpenglow 还对 Solana 的共识安全模型进行了重要调整。

在区块链网络中，验证者不一定始终诚实、在线。有些节点可能因为断电、服务器故障或网络中断而停止工作，也有一些节点可能故意发送错误信息，甚至联合起来攻击网络。

因此，一套共识协议不仅要考虑正常情况下如何快速确认交易，还必须回答一个问题：当部分验证者出现故障甚至恶意行为时，网络还能否安全运行？

传统拜占庭容错（BFT）共识通常以不足三分之一的节点权重存在任意恶意行为为安全边界。Alpenglow 则采用了不同的设计，提出所谓的「20+20」容错模型。

这里的两个 20%，分别对应不同类型的故障。

第一个 20% 的意思是，只要恶意验证者控制的质押权重低于 20%，Alpenglow 就能够在其设定的模型下维持共识安全性。即便恶意参与者试图扰乱通信，或者网络出现长时间延迟，也不会因此让诚实节点最终确认相互冲突的区块。

第二个 20%，则指额外的节点宕机或离线故障。在满足更强网络假设的情况下，除了不足 20% 的恶意质押权重之外，Alpenglow 还可以容忍额外最多约 20% 的质押权重离线。

背后的考虑是，在一个拥有大量验证者的权益证明网络中，故障未必来自有组织的攻击，也可能来自软件错误、硬件问题或基础设施中断。

但这也是一项需要正视的取舍：Alpenglow 并非在所有故障场景下都比传统 BFT 更安全，而是选择了不同的安全边界，以换取更快的最终确认。

10 月 21 日，Solana 将迎来一次真正的共识切换

Alpenglow 升级计划并非近期才提出。2025 年，Alpenglow 作为 SIMD-0326 被提交至 Solana 社区，并在同年的治理投票中获得通过。

此后，Anza 持续推进协议开发、测试和验证者准备工作。2026 年 9 月 24 日，Alpenglow 在 Solana Testnet 完成切换；次日又在 Devnet 完成相应迁移。如今，升级即将进入主网阶段。

对于 Solana 而言，Alpenglow 的意义并不只在于将最终确认时间从十几秒压缩至约 150 毫秒。

过去，Solana 已经依靠高吞吐量和较低交易成本，在 Meme 币、DeFi 以及链上交易等领域建立优势。但对于要求快速、可靠完成结算的金融场景，区块最终确认仍是必须面对的问题。

Alpenglow 正在尝试补上这一环。