本文详细介绍了以太坊为实现快速最终性提出的3SF(3槽最终性)机制。文章首先回顾了SSF(单槽最终性)面临的挑战及其物理瓶颈,随后深入阐述了3SF如何通过管线化和合并投票克服这些困难,并探讨了其在现实中的工程挑战和未来发展方向。
本篇文章內容由AI与作者共同編写,最終的产出由作者审阅及润色

本篇文章主要介紹 3SF (3 Slots Finality) 是如何运作的,如何在 3 个 slots 达到最终性(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)著手,打造真正的「快速最终性」。
要理解 SSF 与 3SF 之前,我們先來認識 PBFT,這是 SSF 的基礎
PBFT(Practical Byzantine Fault Tolerance)是分散式系統中非常經典的共識機制。相較於傳統 PoW 的機率性确认,PBFT 追求的是「絕對的確定性」:只要網路达成共識,區塊就永遠不能被翻盤。
为了解決網路延遲与惡意節點作亂(拜占庭將軍問題),PBFT 設計了嚴格的「多階段确认」機制。假設我們需要全網超過 2/3 的節點同意:
为什么需要兩次投票(Pre-vote 和 Commit)?因为在分散的網路中,每个人收到訊息的時間不同。第一輪投票是确认「 大家投的是同一个區塊」,第二輪投票是确认「全網大多數人都已經达成共識」。經歷這完整的通訊往返,區塊才能獲得絕對的最终性。
對 PBFT 想深入了解的,可以參考 若想搞懂區塊鏈就不能忽視的經典:PBFT* ](https://miro.medium.com/v2/resize:fit:700/1VBxky5XzZLJSZfr56uhX-g.png)
Generated by AI
SSF 的設計,則是試圖把 PBFT 那套複雜的多輪投票流程,全部壓縮在「單一一个 Slot」(目前是 12 秒)內完成。根據以太坊研究論壇上的 Simple SSF 提案,一个 Slot 內必須經歷:
提案 → 第一次投票 → 簽章聚合 → 第二次投票 → 第二次簽章聚合。
为什么需要兩次投票?兩次分別投什么?
在分散式網路中,單次投票無法保證安全性(Safety)。如果網路发生延遲或分區,或者惡意提议者(Byzantine Proposer)故意只向一半的網路廣播區塊,單次投票會導致部分節點以为达成了共識,進而引发嚴重的分叉。因此,SSF 必須遵循 PBFT 的兩階段确认:
驗證者收到提议的區塊后,首先驗證區塊的合法性、執行結果与資料可用性(Data Availability)。投下這張票代表:「我确认這个區塊是合法的,且根據 LMD-GHOST 分叉選擇規則,我認为它是目前的鏈頭。」
驗證者必須先「看見」全網有超過 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$:

SSF 的設計: 4 个步驟,每个步驟为 $\Delta$ 延遲,所以理論上为 $4\Delta$ 的延遲。source: https://ethresear.ch/uploads/default/original/2X/b/b2e3bad804fd7b520b49902e89ab31bcfe56a06a.png
這意味著一个完整的 SSF Slot 實際上需要 $6\Delta$ 的網路傳播時間。如果全球網路延遲稍微波動,這整套流程就會超時。這導致 SSF 實務上面臨兩難:要么網路頻繁地失去活躍性(Liveness),要么必須將 Slot 時間大幅延長(例如拉長至 24 或 32 秒),這完全違背了以太坊追求高效能結算层的初衷。這也是为什么 SSF 雖然是理論上的最優解,但在工程實作上極度困難。
$\Delta$
既然無法在單一 Slot 內硬塞入 $6\Delta$ 的通訊与兩次聚合,研究員們轉而借鏡了現代 CPU 与高效能 BFT 共識(如 HotStuff)最核心的技術 — — 管線化(Pipelining)。
3SF 放棄了在 1 个 Slot 內完成「提案 → 投票 → 聚合 → 二次投票」的執念,而是將這兩次關鍵的 BFT 投票,優雅地拆解並「分攤」到連續的 3 个 Slots 中。更重要的是,为了不增加額外的訊息負載,3SF 引入了一項共識协议的魔法:合併投票(Unified Vote)。
什么是合併投票?
在目前的以太坊中,決定哪條鏈是最長鏈的「分叉選擇規則(LMD-GHOST)」与決定區塊不可逆的「最终性工具(Casper FFG)」是分离的。而在 3SF 中,驗證者的這「1 次投票」是一張帶有多重意義的合併選票。
目前的 Beacon Chain,驗證者所投的票確實同時包含了 Head Vote 和 FFG Vote 這兩項意義,但這兩票指向的 目標(Target) 通常是不同的( Head Vote 是指向最新的區塊,FFG Vote 是指向 Epoch 的邊界區塊)。
當一个驗證者在 Slot $N$ 投出一張票時,他實際上在同時做三件事:
這就像是在同一份簽章中,同時打包了 PBFT 的 Pre-vote 与 Commit。透過管線化的方式,上一个區塊的「聚合簽章」會直接被打包進下一个區塊中。這让原本在 SSF 內會卡死的等待時間,變成了流暢的接力賽:
提议者廣播區塊 1。驗證者收到后,投出第一次合併選票並发給聚合器。這个 Slot 只需要承受一次通訊往返。一旦下一个提议者收集到超過 2/3 的票數,區塊 1 就獲得了「快速确认」。在經濟安全上,這已經足以防範絕大多數的重組攻擊。
提议者廣播區塊 2。當驗證者對區塊 2 投下合併選票時,這張票隱含的語意是:「我看見了大家對區塊 1 的認可」。這張票完美對應了 PBFT 的 Commit(第二次投票),此時區塊 1 的狀態正式推進为被證明( Justified)。
提议者廣播區塊 3。當驗證者對區塊 3 投票時,等同於執行了 PBFT 的 Commit 階段。协议規則被觸发,區塊 1 徹底达成最终性(Finalized),写入不可逆的歷史。

Generated by AI
視圖合併(View Merge):確保管線流暢的「視角同步」機制
Remember me for faster sign in
在 3SF 的管線化設計中,最脆弱的一環就是 Slot 1 的快速确认。如果驗證者們因为網路延遲或攻擊者的惡意干擾,導致大家看到的「鏈頭」不一致,那么 Slot 1 就無法在有限的時間內凝聚 2/3 的共識,整條管線接力就會卡死。
为了確保這場「接力賽」不掉棒,研究員引入了視圖合併。它不是另一輪投票,而是在驗證者投出那張關鍵的「合併選票」前,強制執行的視角校準:
驗證者在 Slot 开始前的一个短暫時間點($\Delta$)會暫時「閉上眼睛」,不再接受新的分叉選擇訊息。這創造了一个穩定的运算基準面。
當前的提议者(Proposer)會根據他看到的最新狀態打包區塊,並在區塊中附帶一份「我做決定時參考的投票清單」。
驗證者收到區塊后,會將提议者列出的這些投票与自己凍結的視角進行強制合併。
這解決了什么問題?
在舊有的 LMD-GHOST 機制中,攻擊者常利用「平衡攻擊 (Balancing Attacks)」在微秒級的時間差內釋放訊息,让誠實節點在兩个分叉間猶豫不決。而視圖合併透過強制同步提议者的視角,確保了只要網路延遲在容許範圍內,全網誠實節點都能「看見同一个世界」,進而投出一致的選票。
从補丁到协议完整性
相較於過去为了對抗重組而強加的 Proposer Boost(這更像是一種憑空給予的「權宜之計」),視圖合併是从协议层的角度確保了視圖的一致性。它让提议者不再是憑空獲得權重,而是成为一名「導航員」,引導驗證者在正確的基礎上進行合併投票。
這套機制让 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 內完成所有确认,必須塞入兩个投票聚合階段。其結构如下:
3SF 則將單个 Slot 的複雜度降为 $5\Delta$。雖然這看起來只節省了 $1\Delta$,但在全球規模的網路中,這代表時槽長度能縮減約 16%。
从嚴格的密碼學角度來看,3SF 达成「絕對最终性」的時間確實比 SSF 慢(12 秒 vs. 36 秒)。這是否意味著 3SF 的使用者體驗倒退了?答案是否定的,因为這裡存在一个工程上的巧思:分层的确认機制(Layered Confirmation)。
對於絕大多數的 DApp 使用者、L2 排序器(Sequencer)或是中心化交易所而言,當 Slot 1 結束,區塊收集到超過 2/3 驗證者的第一張合併選票時,該區塊就已經达成了 「快速确认(Fast Confirmation)」。
要推翻一个具備 快速确认 的區塊,攻擊者必須让超過 1/3 的驗證者同時進行「雙重投票」。在以太坊目前的經濟模型下,這意味著攻擊者將面臨數百億美元級別的 Slash(罰沒)懲罰。因此,就「經濟安全性」而言,Slot 1 結束時的確定性已經足以視为交易成功。這使得 L2 能夠在短短 12 秒內就獲得極高強度的底层結算保證,體感時間与 SSF 完全一致。
聽起來 3SF 藉由管線化完美解決了問題,但這並非毫無代價。在將 3SF 推向以太坊主網的過程中,仍面臨以下挑战:
簽章聚合的絕對極限与驗證者瘦身計畫
儘管 3SF 將每个 Slot 的網路通訊次數从 2 次降了 1 次,但「這 1 次」依然無比沈重。以太坊目前擁有超過百萬名驗證者,要在幾秒钟的 $\Delta$ 延遲內,透過 P2P 網路 Gossip 傳遞百萬个 BLS 簽章並完成聚合,依然會壅塞整个 P2P 網路,導致節點頻寬癱瘓。
为了突破這个工程限制,以太坊研究社群目前有兩條路徑,試圖为驗證者集合「瘦身」:
務實的過渡時程:先 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
- 本文转载自: medium.com/taipei-ethere... , 如有侵权请联系管理员删除。
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!