介绍 3SF (三槽最终性) — 以太坊未來共识

本篇文章内容由 AI 与作者共同编写，最终的产出由作者审阅及润色。

本篇文章主要介绍 3SF (3 Slots Finality) 是如何运作的，以及如何在 3 个 slot 内达到最终性（Finality）。此外，还会介绍最初提出的 SSF（Single Slot Finality）及其面临的挑战，并解释为何目前开发倾向于 3SF。文章最后将比较 3SF 与 SSF 之间的差异。

目前 Beacon chain 所使用的 Gasper FFG 协议，需要等待 2 个 epoch（约 12.8 分钟）才能让一个区块达到最终性。这对于未来的全球结算层或是 L2 来说，等待时间实在太漫长了。为了解决这个痛点，近年由于 MEV 促成了“提议者与建构者分离（PBS）”架构的普及，使得由基础设施层提供“预确认（Pre-confirmation）”的可行性大幅提高，能为用户带来更快速的交易体验。然而，预确认终究只是建立在押金与惩罚机制上的“软性保证”；只要底层 L1 还需要 15 分钟才能最终化，提供保证的 L2 排序器或跨链桥就必须承担这 15 分钟内可能发生区块重组的巨大风险。我们终究不能只靠外挂的基础设施，而是必须从协议层（Protocol level）着手，打造真正的“快速最终性”。

从 PBFT 到 SSF：理想与现实的拉扯

在理解 SSF 与 3SF 之前，我们先来认识作为 SSF 基础的 PBFT。

什么是 PBFT？深入共识的两阶段确认

PBFT（Practical Byzantine Fault Tolerance）是分布式系统中非常经典的共识机制。相较于传统 PoW 的概率性确认，PBFT 追求的是“绝对的确定性”：只要网络达成共识，区块就永远不能被推翻。

为了解决网络延迟与恶意节点作乱（拜占庭将军问题），PBFT 设计了严格的“多阶段确认”机制。假设我们需要全网超过 2/3 的节点同意：

1. Propose（提议）：负责提案的节点广播一个新区块。
2. Pre-vote（预投票）：节点收到区块且验证无误后，向全网广播“我准备好接受这个区块了”。
3. Commit（提交）：当一个节点收集到超过 2/3 的预投票后，它会再次向全网广播“我确认大家都同意了，我们正式将这个区块写入历史”。

为什么需要两次投票（Pre-vote 和 Commit）？因为在分布式网络中，每个人收到信息的时间不同。第一轮投票是确认“大家投的是同一个区块”，第二轮投票是确认“全网大多数人都已经达成共识”。经历完整的通讯往返后，区块才能获得绝对的最终性。

对 PBFT 想深入了解的，可以参考 若想搞懂区块链就不能忽视的经典：PBFT

Generated by AI

SSF 的野心与物理瓶颈：被压垮的签名聚合

SSF 的设计试图将 PBFT 那套复杂的多轮投票流程，全部压缩在“单个 Slot”（目前是 12 秒）内完成。根据以太坊研究论坛上的 Simple SSF 提案，一个 Slot 内必须经历：

提案 → 第一次投票 → 签名聚合 → 第二次投票 → 第二次签名聚合。

为什么需要两次投票？两次分别投什么？

在分布式网络中，单次投票无法保证安全性（Safety）。如果网络发生延迟或分区，或者恶意提议者（Byzantine Proposer）故意只向一半的网络广播区块，单次投票会导致部分节点误以为达成了共识，进而引发严重的分叉。因此，SSF 必须遵循 PBFT 的两阶段确认：

1. 第一次投票（Pre-vote / 链头与有效性投票）： 验证者收到提议的区块后，首先验证区块的合法性、执行结果与数据可用性（Data Availability）。投下这张票代表：“我确认这个区块是合法的，且根据 LMD-GHOST 分叉选择规则，我认为它是目前的链头。”
2. 第二次投票（Pre-commit / 最终性锁定投票）： 验证者必须先“看见”全网有超过 2/3 的节点都投了第一次票（通过聚合签名证明），才能投下第二次票。这张票代表：“我确认全网绝大多数人都看见了同一个合法区块，我们现在正式把这个区块锁定（Finalized），不允许任何重组（Reorg）。”

致命的物理瓶颈：签名聚合（Signature Aggregation）

在纯粹的理论模型中，SSF 只需要经历 4 个单向的网络通讯步骤（提议 → 第一次投票 → 第二次投票 → 确认冻结），其通讯预算理应是非常优雅的 $4\Delta$。然而现实是残酷的。在拥有百万验证者的以太坊中，如果所有节点直接互相广播选票，传统 BFT $O(N^2)$ 的通讯复杂度会瞬间瘫痪整个 P2P 网络。

为了解决这点，以太坊规定选票必须先发送给特定的“聚合器（Aggregators）”，由它们通过密码学将成千上万的 BLS 签名“压缩”成单一证明，然后再向全网广播。

正是这个“一收一发”的聚合过程，成为了压垮 single slot 的稻草。聚合器必须先等待收集大家的选票（耗时 $\Delta$），计算完成后再将压缩后的聚合签名广播给全网（再耗时 $\Delta$）。这直接将每一次投票阶段的网络传播延迟翻倍，从原本的 $\Delta$ 膨胀成了 $2\Delta$。

因此，原本理论上轻盈的 $4\Delta$ 设计，在实务中为了容纳百万验证者，塞入了聚合步骤，最终变成了沉重的 $6\Delta$：

• 区块广播（耗时 $\Delta$）
• 第一次投票与聚合：Head-Vote（耗时 $2\Delta$）
• 第二次投票与聚合：FFG-Vote（耗时 $2\Delta$）
• 第三次确认广播与视图冻结（耗时 $\Delta$）

SSF 的设计：4 个步骤，每个步骤为 $\Delta$ 延迟，所以理论上为 $4\Delta$ 的延迟。来源: https://ethresear.ch/uploads/default/original/2X/b/b2e3bad804fd7b520b49902e89ab31bcfe56a06a.png

这意味着一个完整的 SSF Slot 实际上需要 $6\Delta$ 的网络传播时间。如果全球网络延迟稍微波动，整套流程就会超时。这导致 SSF 在实务上面临两难：要么网络频繁失去活跃性（Liveness），要么必须将 Slot 时间大幅延长（例如拉长至 24 或 32 秒），这完全违背了以太坊追求高效能结算层的初衷。这也是为什么 SSF 虽然是理论上的最优解，但在工程实现上极度困难。

$\Delta$

3SF 的诞生：流水线化（Pipelining）与合并投票

既然无法在单个 Slot 内硬塞入 $6\Delta$ 的通讯与两次聚合，研究员们转而借鉴了现代 CPU 与高效能 BFT 共识（如 HotStuff）最核心的技术——流水线化（Pipelining）。

3SF 放弃了在 1 个 Slot 内完成“提案 → 投票 → 聚合 → 二次投票”的执念，而是将这两次关键的 BFT 投票，优雅地拆解并“分摊”到连续的 3 个 Slot 中。更重要的是，为了不增加额外的消息负载，3SF 引入了一项共识协议的魔法：合并投票（Unified Vote）。

什么是合并投票？

在目前的以太坊中，决定哪条链是最长链的“分叉选择规则（LMD-GHOST）”与决定区块不可逆的“最终性工具（Casper FFG）”是分离的。而在 3SF 中，验证者的这“1 次投票”是一张带有多重意义的合并选票。

目前的 Beacon Chain，验证者所投的票确实同时包含了 Head Vote 和 FFG Vote 这两项意义，但这两票指向的 目标（Target） 通常是不同的（Head Vote 指向最新的区块，FFG Vote 指向 Epoch 的边界区块）。

当一个验证者在 Slot $N$ 投出一张票时，他实际上在同时做三件事：

1. LMD-GHOST 链头投票：认可 Slot $N$ 的区块是合法的最新链头。
2. Casper FFG 目标投票 (Target)：将 Slot $N$ 的区块设为下一个检查点目标。
3. Casper FFG 来源投票 (Source)：引用 Slot $N-1$ 的区块作为基础。这等于向全网宣告：“我确认 $N-1$ 已经被证明（Justified），且连带确认 $N-2$ 已经最终化（Finalized）”。

这就像是在同一份签名中，同时打包了 PBFT 的 Pre-vote 与 Commit。通过流水线化的方式，上一个区块的“聚合签名”会直接被打包进下一个区块中。这让原本在 SSF 内会卡死的等待时间，变成了流畅的接力赛：

• Slot 1（快速确认 Fast Confirmation）： 提议者广播区块 1。验证者收到后，投出第一次合并选票并发给聚合器。这个 Slot 只需要承受一次通讯往返。一旦下一个提议者收集到超过 2/3 的票数，区块 1 就获得了“快速确认”。在经济安全上，这已经足以防范绝大多数的重组攻击。
• Slot 2（证明 Justification）： 提议者广播区块 2。当验证者对区块 2 投下合并选票时，这张票隐含的语意是：“我看见了大家对区块 1 的认可”。这张票完美对应了 PBFT 的 Commit（第二次投票），此时区块 1 的状态正式推进为被证明（Justified）。
• Slot 3（最终化 Finalization）： 提议者广播区块 3。当验证者对区块 3 投票时，等同于执行了 PBFT 的 Commit 阶段。协议规则被触发，区块 1 彻底达成最终性（Finalized），写入不可逆的历史。

Generated by AI

视图合并（View Merge）：确保流水线流畅的“视角同步”机制

Remember me for faster sign in

在 3SF 的流水线设计中，最脆弱的一环就是 Slot 1 的快速确认。如果验证者们因为网络延迟或攻击者的恶意干扰，导致大家看到的“链头”不一致，那么 Slot 1 就无法在有限的时间内凝聚 2/3 的共识，整条流水线接力就会卡死。

为了确保这场“接力赛”不掉棒，研究员引入了视图合并。它不是另一轮投票，而是在验证者投出那张关键的“合并选票”前，强制执行的视角校准：

1. 视图冻结（View Freeze）： 验证者在 Slot 开始前的一个短暂时间点（$\Delta$）会暂时“闭上眼睛”，不再接受新的分叉选择信息。这创造了一个稳定的运算基准面。
2. 提议者导航（Proposer’s Insights）： 当前的提议者（Proposer）会根据他看到的最新状态打包区块，并在区块中附带一份“我做决定时参考的投票清单”。
3. 视图合并： 验证者收到区块后，会将提议者列出的这些投票与自己冻结的视角进行强制合并。

这解决了什么问题？

在旧有的 LMD-GHOST 机制中，攻击者常利用“平衡攻击 (Balancing Attacks)”在微秒级的时间差内释放信息，让诚实节点在两个分叉间犹豫不决。而视图合并通过强制同步提议者的视角，确保了只要网络延迟在容许范围内，全网诚实节点都能“看见同一个世界”，进而投出一致的选票。

从补丁到协议完整性

相较于过去为了对抗重组而强加的 Proposer Boost（这更像是一种凭空给予的“权宜之计”），视图合并是从协议层的角度确保了视图的一致性。它让提议者不再是凭空获得权重，而是成为一名“导航员”，引导验证者在正确的基础上进行合并投票。

这套机制让 3SF 的流水线不仅在理论上优雅，更具备了在真实、存在敌意的网络环境下稳定运行的鲁棒性。

SSF vs. 3SF：一场通讯成本与体感时间的魔术

网络活跃性与容错极限

SSF 是一种高度耦合的设计。它将 BFT 的所有阶段强硬地绑定在一个 12 秒的 Slot 内。这意味着系统对网络的同步性有着极高的要求（必须严格满足 $6\Delta$ 的极限）。一旦 P2P 网络发生短暂的拥塞，或是聚合器（Aggregators）由于地理延迟无法及时产出聚合签名，验证者就无法投下第二张票。这会导致该 Slot 直接失效（Empty Slot），甚至引发频繁的短暂分叉，严重损害区块链的活跃性。

相对地，3SF 通过流水线化解开了这层硬性束缚。在 3SF 中，如果 Slot 1 的聚合签名由于网络延迟来不及被打包进 Slot 2，网络并不会因此停摆。依赖 LMD-GHOST 分叉选择规则，链依然能继续出块并保持活跃性；只是这批区块的“最终性”会被推延到 Slot 4 或 Slot 5 达成。3SF 继承了 Gasper 协议“宁可延迟最终化，也绝不停机”的优良传统。

6Δ vs 5Δ 的时空交换

SSF 为了在单个 Slot 内完成所有确认，必须塞入两个投票聚合阶段。其结构如下：

• SSF ($6\Delta$)： 提议 ($1\Delta$) + 链头投票 ($2\Delta$) + FFG 投票 ($2\Delta$) + 确认与冻结 ($1\Delta$) = $6\Delta$

3SF 则将单个 Slot 的复杂度降为 $5\Delta$。虽然这看起来只节省了 $1\Delta$，但在全球规模的网络中，这代表时段长度能缩减约 16%。

• 3SF ($5\Delta$)： 提议 ($1\Delta$) + 合并投票 ($2\Delta$) + 快速确认 ($1\Delta$) + 视图合并 ($1\Delta$) = $5\Delta$

从严格的密码学角度来看，3SF 达成“绝对最终性”的时间确实比 SSF 慢（36 秒 vs. 12 秒）。但这是否意味着 3SF 的用户体验倒退了？答案是否定的，因为这里存在一个工程上的巧思：分层的确认机制（Layered Confirmation）。

对于绝大多数的 DApp 用户、L2 排序器（Sequencer）或是中心化交易所而言，当 Slot 1 结束，区块收集到超过 2/3 验证者的第一张合并选票时，该区块就已经达成了 “快速确认（Fast Confirmation）”。

要推翻一个具备 快速确认 的区块，攻击者必须让超过 1/3 的验证者同时进行“双重投票”。在以太坊目前的经济模型下，这意味着攻击者将面临数百亿美元级别的 Slash（罚没）惩罚。因此，就“经济安全性”而言，Slot 1 结束时的确定性已经足以视为交易成功。这使得 L2 能够在短短 12 秒内就获得极高强度的底层结算保证，体感时间与 SSF 完全一致。

3SF 的现实挑战与工程限制

听起来 3SF 借由流水线化完美解决了问题，但这并非毫无代价。在将 3SF 推向以太坊主网的过程中，仍面临以下挑战：

签名聚合的绝对极限与验证者瘦身计划

尽管 3SF 将每个 Slot 的网络通讯次数从 2 次降为 1 次，但这“1 次”依然无比沉重。以太坊目前拥有超过百万名验证者，要在几秒钟的 $\Delta$ 延迟内，通过 P2P 网络 Gossip 传递百万个 BLS 签名并完成聚合，依然会拥塞整个 P2P 网络，导致节点带宽瘫痪。

为了突破这个工程限制，以太坊研究社区目前有两条路径，试图为验证者集合“瘦身”：

• 共识层的数学抽签（Orbit SSF）： 系统不再要求百万大军每个 Slot 都投票，而是通过密码学随机抽签，选出一个具备高度经济安全性、规模约 10 万人的“子委员会”来执行 3SF 投票。这直接将网络负载降低了一个数量级。
• 经济层的角色解绑（Rainbow Staking）： 承认硬件能力的差异，将质押者分为“重型（Heavy）”与“轻型（Light）”。重型节点负责处理 3SF 繁重的高带宽最终性投票；而硬件受限的百万名 Solo Stakers 则转为轻型节点，不参与高频投票，转而负责提供“抗审查性（如 Inclusion Lists）”。

务实 transition：先 Rainbow，后 Orbit

在近期的研究《Paths to SSF revisited》中，目前工程实现上更倾向于 优先推动 Rainbow Staking 上线。原因在于，Orbit SSF 作为全新的动态抽签机制，与 3SF 的底层共识设计深度绑定，开发周期长。相对而言，Rainbow Staking 从“经济学角色分工”切入，可以在不彻底修改共识引擎的前提下，先将百万名 Solo Stakers 从繁重的 P2P 签名广播中解放出来。这种“先解绑经济角色，再升级共识引擎”的策略，能有效避免 3SF 的开发进程被过度拖延。

小结

3SF 彻底移除了现行 Gasper 协议中 Epoch 的概念，让最终性以流水线的方式，随着每一个 Slot 逐次推进。这不仅大幅降低了用户的“体感确认时间”，让 L2 跨链与全球结算能做到近乎即时，更为未来将 Slot 时间缩短至 8 秒或 4 秒铺平了道路。

在以太坊走向 Lean Consensus 与高效能验证的蓝图中，3SF 是在“快速的经济最终性”与“严酷的网络物理限制”之间取得的最优解。在克服上述挑战后，还需要与现行的 ePBS, FOCIL, PeerDAS 等其他提案进行整合。依照官方蓝图，目前的 Faster Finality 还处于探索阶段，毕竟 Lean Consensus 最快也要 3 年以后才会上线，这过程中或许还会发现更好的解法。

Special thanks to TSK and Juno for reviewing and improving this post

Reference:

• https://ethresear.ch/t/3-slot-finality-ssf-is-not-about-single-slot/20927
• https://ethresear.ch/t/a-simple-single-slot-finality-protocol/14920
• https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739
• https://leanroadmap.org/
• https://ethresear.ch/t/paths-to-ssf-revisited/22052
• https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683/6
• https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928
• Gemini Deep Research

• 本文转载自： medium.com/taipei-ethere... , 如有侵权请联系管理员删除。