認識 3SF — 以太坊未來共識的管線化魔法
2026-03-2611:00
Taipei Ethereum Meetup
2026-03-26 11:00
本篇文章內容由AI與作者共同編寫,最終的產出由作者審閱及潤飾
Generated By 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)著手,打造真正的「快速最終性」。

從 PBFT 到 SSF:理想與現實的拉扯

要理解 SSF 與 3SF 之前,我們先來認識 PBFT,這是 SSF 的基礎

什麼是 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Δ。然而,現實是殘酷的。在擁有百萬驗證者的以太坊中,如果所有節點直接互相廣播選票,傳統 BFT O(N²) 的通訊複雜度會瞬間癱瘓整個 P2P 網路。

為了解決這點,以太坊規定選票必須先發送給特定的「聚合器(Aggregators)」,由他們透過密碼學將成千上萬的 BLS 簽章「壓縮」成單一一個證明,然後再向全網廣播。

正是這個「一收一發」的聚合過程,成為了壓垮 single slot 的稻草。聚合器必須先等待收集大家的選票(耗時 Δ),計算完成後再將壓縮後的聚合簽章廣播給全網(再耗時 Δ)。這直接將每一次投票階段的網路傳播延遲翻倍,從原本的 Δ 膨脹成了 2Δ。

因此,原本理論上輕盈的 4Δ 設計,在實務上為了容納百萬驗證者,塞入了聚合步驟,最終變成了沈重的 6Δ:

  • 區塊廣播(耗時 Δ)
  • 第一次投票與聚合:Head-Vote(耗時 2Δ)
  • 第二次投票與聚合:FFG-Vote(耗時 2Δ)
  • 第三次確認廣播與視圖凍結(耗時 Δ)
SSF 的設計: 4 個步驟,每個步驟為 Δ 延遲,所以理論上為 4Δ 的延遲。source: https://ethresear.ch/uploads/default/original/2X/b/b2e3bad804fd7b520b49902e89ab31bcfe56a06a.png

這意味著一個完整的 SSF Slot 實際上需要 6Δ 的網路傳播時間。如果全球網路延遲稍微波動,這整套流程就會超時。這導致 SSF 實務上面臨兩難:要麼網路頻繁地失去活躍性(Liveness),要麼必須將 Slot 時間大幅延長(例如拉長至 24 或 32 秒),這完全違背了以太坊追求高效能結算層的初衷。這也是為什麼 SSF 雖然是理論上的最優解,但在工程實作上極度困難。

Δ

3SF 的誕生:管線化(Pipelining)與合併投票

既然無法在單一 Slot 內硬塞入 6Δ 的通訊與兩次聚合,研究員們轉而借鏡了現代 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 投出一張票時,他實際上在同時做三件事:

  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):確保管線流暢的「視角同步」機制

在 3SF 的管線化設計中,最脆弱的一環就是 Slot 1 的快速確認。如果驗證者們因為網路延遲或攻擊者的惡意干擾,導致大家看到的「鏈頭」不一致,那麼 Slot 1 就無法在有限的時間內凝聚 2/3 的共識,整條管線接力就會卡死。

為了確保這場「接力賽」不掉棒,研究員引入了視圖合併。它不是另一輪投票,而是在驗證者投出那張關鍵的「合併選票」前,強制執行的視角校準:

  1. 視圖凍結(View Freeze)
    驗證者在 Slot 開始前的一個短暫時間點(Δ)會暫時「閉上眼睛」,不再接受新的分叉選擇訊息。這創造了一個穩定的運算基準面。
  2. 提議者導航(Proposer’s Insights)
    當前的提議者(Proposer)會根據他看到的最新狀態打包區塊,並在區塊中附帶一份「我做決定時參考的投票清單」。
  3. 視圖合併
    驗證者收到區塊後,會將提議者列出的這些投票與自己凍結的視角進行強制合併。

這解決了什麼問題?
在舊有的 LMD-GHOST 機制中,攻擊者常利用「平衡攻擊 (Balancing Attacks)」在微秒級的時間差內釋放訊息,讓誠實節點在兩個分叉間猶豫不決。而視圖合併透過強制同步提議者的視角,確保了只要網路延遲在容許範圍內,全網誠實節點都能「看見同一個世界」,進而投出一致的選票。

從補丁到協議完整性
相較於過去為了對抗重組而強加的 Proposer Boost(這更像是一種憑空給予的「權宜之計」),視圖合併是從協議層的角度確保了視圖的一致性。它讓提議者不再是憑空獲得權重,而是成為一名「導航員」,引導驗證者在正確的基礎上進行合併投票。

這套機制讓 3SF 的管線化不僅僅是理論上的優雅,更具備了在真實、具備敵意網路環境下穩定運行的穩定性。

SSF vs. 3SF:一場通訊成本與體感時間的魔術

網路活躍性與容錯極限

SSF 是一種高度耦合的設計。它將 BFT 的所有階段強硬地綁定在一個 12 秒的 Slot 內。這意味著系統對網路的同步性有著極高的要求(必須嚴格滿足 6Δ 的極限)。一旦 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Δ): 提議 (1Δ) + 鏈頭投票 (2Δ) + FFG 投票 (2Δ) + 確認與凍結 (1Δ) = 6Δ

3SF 則將單個 Slot 的複雜度降為 5Δ。雖然這看起來只節省了 1Δ,但在全球規模的網路中,這代表時槽長度能縮減約 16%。

3SF (5Δ): 提議 (1Δ) + 合併投票 (2Δ) + 快速確認 (1Δ) + 視圖合併 (1Δ) = 5Δ

從嚴格的密碼學角度來看,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 推向以太坊主網的過程中,仍面臨以下挑戰:

簽章聚合的絕對極限與驗證者瘦身計畫

儘管 3SF 將每個 Slot 的網路通訊次數從 2 次降了 1 次,但「這 1 次」依然無比沈重。以太坊目前擁有超過百萬名驗證者,要在幾秒鐘的 Δ 延遲內,透過 P2P 網路 Gossip 傳遞百萬個 BLS 簽章並完成聚合,依然會壅塞整個 P2P 網路,導致節點頻寬癱瘓。

為了突破這個工程限制,以太坊研究社群目前有兩條路徑,試圖為驗證者集合「瘦身」:

  • 共識層的數學抽籤(Orbit SSF): 系統不再要求百萬大軍每個 Slot 都投票,而是透過密碼學隨機抽籤,選出一個具備高度經濟安全性、規模約 10 萬人的「子委員會」來執行 3SF 投票。這直接將網路負載降低了一個數量級。
  • 經濟層的角色解綁(Rainbow Staking): 承認硬體能力的差異,將質押者分為「重型(Heavy)」與「輕型(Light)」。重型節點負責處理 3SF 繁重的高頻寬最終性投票;而硬體受限的百萬名 Solo Stakers 則轉為輕型節點,不參與高頻投票,轉而負責提供「抗審查性(如 Inclusion Lists)」。

務實的過渡時程:先 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:


認識 3SF — 以太坊未來共識的管線化魔法 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

【免责声明】市场有风险,投资需谨慎。本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资,责任自负。

专栏文章
查看更多
数据请求中

推荐专栏

数据请求中

一起「遇见」未来

DOWNLOAD FORESIGHT NEWS APP

Download QR Code