隆重推出 Alpenglow：Solana 的新共识协议

Anza Labs（前身为 Solana Labs）提出了 Solana 区块链自上线以来最重要的更新：Alpenglow。

Alpenglow 用 Votor 替代了 TowerBFT 和 Proof-of-History 作为投票和区块最终确认机制，并用 Rotor 改进了 Turbine（作为数据传播层）。本文将讨论这些更改如何影响 Solana 生态系统，以及 Alpenglow 实施后你可以期待什么。

Votor

在 Votor 之前，Solana 依赖于 T**ower Byzantine Fault Tolerance (TBFT) 作为其共识算法，它是 Practical Byzantine Fault Tolerance (PBFT) 的自定义实现。你可以将 TBFT 可视化为两步握手。

在第一次握手中，即 预投票，每个验证者签署一条简短的“是的，我看到了这个区块”消息。只有在 至少三分之二 (2/3) 的所有 stake 发送了这第一张投票后，该区块才能继续进行。在第二次握手中，即 提交，一旦相同的超多数注意到第一轮成功，他们就会签署第二次“现在它已是最终的”投票。

只要 少于三分之一的总 stake 是主动恶意的，这种 2 跳模式（加上 leader 停滞时偶尔出现的视图更改）在数学上是安全的。然而，这引入了很多延迟，因为 Solana 上的区块最终确认平均约为 12.8 秒，这对于游戏等实时应用程序来说是不切实际的。

Votor 保留了熟悉的“每个人都使用 stake 加权签名进行投票”的想法，但允许链在 ≈ 80 % 的 stake 在截止日期 T₁ ≈ δ（T₁ = 第一个等待窗口，δ = 网络标准）之前设法发送其第一次投票时 提前停止。如果达到 80%，则立即最终确定该区块——无需第二次跳跃。

如果未及时达到 80%，则协议会放松到 60 %，经过两次跳跃，这仅比旧的 ⅔ 规则略微严格，但仍保持安全性。通过此机制，Votor 实现了 150 毫秒的中值延迟，与 Web2 基础设施相当。

从本质上讲，Votor 通过信任超过 20 % stake 的真实、协调的攻击很少发生，从而在 常见 情况下减少了数百毫秒。代价是稍微窄一些的安全缓冲，对验证者更严格的正常运行时间要求，以及一个更难以推理和在生产中监控的协议。

Rotor

最初，当前的 slot leader 负责将区块的每个字节发送给其余的验证者，这是一个巨大的瓶颈。为了减轻负担，该协议采用了 Turbine，它将区块分解成碎片，对其进行纠删码，并将它们推送到一个固定的扇出树上。

这有所帮助；但是，它留下了一些痛点。首先，每个碎片仍然起源于 leader 的网络，成千上万的交易通过一个管道。此外，中继工作是不均衡的。哪个节点中继给谁是由 slot 编号硬编码的，因此同一个倒霉的验证者可能会转发大量的流量，而其他验证者几乎不转发，但每个人都因“投票”而获得相同的奖励。

这种方法也对 stake 视而不见。拥有 0.1% stake 的验证者最终可能会中继与持有 5% 的验证者一样多的数据，即使后者既有资源又有经济动机来承担更多的负载。随着吞吐量的向上攀升，leader 瓶颈和不公平的带宽分配威胁着实时的用户体验。

Rotor 将区块分发重新构想为 stake 加权的点对点 CDN。leader 只需将足够的碎片 seed 到一组随机抽样的中继节点，每个节点的选择概率与其 stake 成正比。然后，这些中继向外喷射它们自己的与 stake 成比例的带宽；Γ 碎片中的任何 γ 都足以重建该区块，因此相当一部分中继可以离线而不会造成损害。

结果是，leader 的出站流量从“区块大小 × 扇出”下降到大约“区块大小 × (log N / Γ)”。

Rotor 保留了“leader 首先 seed 几个对等节点”的想法，但是它

消除了固定树、32 倍复制和无偿中继工作。代价是对诚实容量配置的更重依赖、验证者更陡峭的硬件要求以及一个必须保持诚实并在规模上可测量的明显更复杂的网络层。

结论

Alpenglow 通过消除 leader 管道作为瓶颈，让 stake 加权群体以接近网络速度移动区块和投票，从而重构了 Solana 的指导思想“世界计算机应该感觉像本地计算机”。如果即将到来的测试网络确认了预计的延迟和公平性收益，Alpenglow 可能会为高性能、开放参与的区块链设定新的基准。

• 原文链接： dev.to/davidekete/introd...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～