MonadBFT：重新定義區塊鏈共識安全，告別尾部分叉風險

作者：michaellwy

區塊鏈的核心在於實現一種嚴格的全球共識（strict global consensus）：也就是說，不管網路節點分布在哪個國家、哪個時區，所有參與者最後都必須對一組客觀結果達成一致。

但現實中的分布式網路並不理想：有節點掉線，有節點撒謊，甚至還有人故意搞破壞。在這種情況下，系統又是如何“衆口一詞”，保持一致的？

這就是共識協議要解決的問題。它本質上是一套規則，用來指導一羣彼此獨立、甚至不完全可信的節點，如何就每筆交易的順序和內容達成統一的決定。

而一旦這種“嚴格共識”建立起來，區塊鏈就能解鎖許多關鍵特性，比如數字產權保障、抗通脹的貨幣模型，以及可擴展的社會協作結構。但前提是，共識協議本身必須同時保證兩個基本面：

不能出現兩個互相衝突的區塊都被確認；

網路必須持續推進，不能卡住或停擺。

MonadBFT 就是在這個方向上做出的最新技術突破。

共識協議的簡要演進回顧

共識機制這個領域，其實已經研究了幾十年。最早的一批協議，比如 PBFT（實用拜佔庭容錯），就已經能處理一種很現實的情況：即使網路裏有部分節點掉鏈子、作惡、胡說八道，只要它們不超過總數的 1/3，系統就還能達成一致。

這些早期協議的設計方式比較“傳統”：每一輪選出一個領導者，由他發起提案，其它驗證者對這個提案進行多輪投票，一步步確認交易順序。

整個投票流程通常要經過幾個階段，比如 pre-prepare、prepare、commit、reply。在每個階段，所有驗證者都要彼此通信。換句話說，每個人都得跟每個人說一遍，消息量呈“網狀”爆發式增長。

這種通信結構的復雜度是 n²——也就是說，假如網路裏有 100 個驗證者，那每一輪共識就可能要傳遞將近 1 萬條消息。

這在小型網路裏問題不大，但一旦驗證者數量上來，系統的通信負擔會迅速變得難以承受，效率直接拉垮。

資料來源：

這種“每個人跟要跟每個人溝通”的二次通信結構，其實非常低效。比如說，在一個有 100 個驗證者的網路裏，每輪共識就可能要處理上萬條消息。

這在一個小圈子裏還能應付，但要是放在全球範圍、開放式的鏈上網路裏，通信負載馬上就變得不可接受了。於是像 PBFT、Tendermint 這樣的早期 BFT 協議，通常只在許可制場景（permissioned network）或者驗證者數量很少的系統中使用，才能勉強跑得動。

爲了讓 BFT 協議也能適應無需許可、公鏈環境，一些新一代的設計開始走向更輕量的通信方式：讓每個驗證者只和領導者通信，而不是全員互傳。

這就把消息復雜度從原本的 n²，優化成了 n —— 大大減輕了系統負擔。

HotStuff 協議就是在 2018 年提出的，正是爲了解決這個擴展性問題。它的設計理念非常明確：用更簡潔、領導者驅動的通信結構，替代 PBFT 的復雜投票流程。

HotStuff 的關鍵特性是所謂的線性通信（linear communication）。在它的機制裏，每個驗證者只需把自己的投票發給當前領導者，領導者再把這些投票打包，生成一個Quorum Certificate（QC，法定多數證明）。

這個 QC 本質上就是一個集體籤名，向整個網路證明：“大多數節點同意了這個提案。”

相比之下，PBFT 的通信模式是“全員廣播”，每個人都在羣裏說話，場面一度十分混亂。HotStuff 的模式更像是 “一人收集，一次打包”，不管網路有多少人，依然能保持高效運轉。

上圖對比了 HotStuff 的扇出式通信結構與 PBFT 的全網互聯模式

資料來源：

除了線性通信外，HotStuff 還可以進一步升級爲流水線版本（pipelined HotStuff），用來提升效率。

在原始的 HotStuff 裏，同一位驗證者會連續擔任多輪領導者，直到一個區塊被完整確認爲止。這個過程是 “一輪處理一個區塊”，所有精力都集中在推進當前那一個。

而在流水線 HotStuff中，機制就更靈活了：每一輪都會選出新的領導者，而每個領導者的任務有兩個：

一邊把上一輪的投票打包成 Quorum Certificate（QC），廣播給全網；

一邊提出一個新的區塊，準備開啓下一輪。

也就是說，不再是“確認完一個再處理下一個”，而是像生產線一樣，不同領導者輪流負責每個環節。 前一位提出區塊，下一位確認它並繼續提出新塊，鏈上共識就像接力賽一樣傳下去。

這就是“流水線”這個比喻的由來：當前的區塊還在走確認流程，下一個已經在準備中了，多步並行，提高吞吐效率。

總結一下，HotStuff 這類協議相比傳統 BFT 在兩個維度上都做出了重大提升：

一是通信更輕量，每個驗證者只需跟領導者通信；

二是處理效率更高，多個區塊確認流程可以並行。

這使得 HotStuff 成爲了很多現代 PoS 區塊鏈共識機制的設計模板。但凡事有利也有弊——流水線結構雖然性能強勁，卻也悄悄引入了一個不容易被發現的結構性風險。

接下來我們就要深入聊聊這個核心問題：尾部分叉（Tail Forking）。

尾部分叉問題（Tail-Forking）

雖然 HotStuff —— 尤其是它的流水線版本 —— 解決了共識協議的擴展性問題，但它也引入了一些新的挑戰。其中最關鍵、也最容易被忽視的，就是所謂的“尾部分叉”（Tail Forking）問題。

什麼是尾部分叉？可以簡單理解爲：區塊鏈在“鏈尾”發生了一次意外的區塊重組(reorg)。

具體來說，有一個區塊，它是有效的，也已經成功傳播到大多數驗證者手中，還拿到了足夠多的投票支持，按理說，它馬上就要被確認、寫進主鏈。但最後，它卻被“跳過了”，被丟棄了（orphaned），取而代之的是另一個在同一高度的新區塊。

這不是 Bug，也不是攻擊，而是因爲協議本身的設計結構裏，存在這種“掉鏈尾”的可能性。這聽起來是不是有點不公平？那麼，這到底是怎麼發生的？

我們前面說過，流水線 HotStuff 的每一位領導者都有兩個任務：

A. 提議一個新區塊（比如 Bₙ₊₁）

B. 爲前一位領導者的區塊收集投票，生成 QC（比如爲 Bₙ 完成最終確認）

這兩個任務是並行的，輪番接力。但問題就出在這裏。

舉個例子：假設 Alice 是領導者，她在第 n 高度提出了區塊 Bₙ，這個區塊獲得了超級多數的投票，已經“差一點就確認了”。

接下來該由 Bob 擔任領導者，繼續推進鏈的下一個區塊 Bₙ₊₁，同時也應該把 Bₙ 的 QC（法定多數證明）打包進他的提案中，完成 Bₙ 的最終確認。

但如果 Bob 這時離線了，或者故意不提交 Bₙ 的 QC，那就出問題了。

因爲沒有人替 Alice 的區塊完成 QC 打包，Bₙ 的投票記錄就沒能傳播出去，這個本應被確認的區塊，就這樣被“冷處理”了，最終被整個網路忽略掉。

這就是尾部分叉的本質：前一個領導者的區塊因爲下一個領導者的失職或惡意，而被跳過。

尾部分叉爲何嚴重？

尾部分叉的問題主要集中在兩方面：1）激勵機制被破壞，2）系統的活躍性受到威脅。

第一，獎勵被吞：

一個區塊如果被拋棄，提出它的領導者就會拿不到任何獎勵。無論是出塊獎勵還是交易手續費。比如 Alice 提出了一個合法區塊，還拿到了超級多數投票支持，結果因爲 Bob 的失誤或者惡意操作，這個區塊沒能被確認，Alice 最終一分錢也拿不到。這將會導致了錯誤的激勵結構：像 Bob 這樣的惡意節點，可以通過跳過對手的區塊，來“掐斷”他們的獎勵來源。這種行爲不需要技術攻擊，只需要故意“不配合”，就能削弱競爭者的收益。如果這種事情反復發生，久而久之，會讓整個系統的參與度和公平性都下降，甚至誘發節點之間的串謀。

第二，MEV 攻擊空間擴大：

尾部分叉還會帶來一個更隱蔽但嚴重的問題：MEV（最大可提取價值）被惡意操縱的空間變大了。舉個例子：假設 Alice 的區塊裏有極具價值的套利交易。Bob 如果有心搞事，可以和下一位領導者 Carol 串通，故意不傳播 Alice 的區塊。然後由 Carol 在相同高度重新構造一個新塊，把 Alice 原本那筆套利交易“抄走”——把 MEV 收益變成自己的了。這種“鏈頭重排 + 串通挪用”的做法，表面上還是照章出塊，實則是一場精心設計的掠奪。更糟的是，它會誘導領導者們之間建立“共謀關係”，讓區塊確認變成一個利益分配遊戲，而不是公共服務。

第三，破壞終局性保障，影響用戶體驗：

相比 Nakamoto 類協議，BFT 的一大優勢是確定性終局：一旦區塊被提交，就無法被回滾。但尾部分叉破壞了這種保證，尤其是在那些“已獲得投票但尚未正式確認”的區塊上。某些高吞吐 dapp 通常希望能在區塊投票通過後立刻讀取數據以降低延遲，而如果該區塊被突然丟棄，可能導致用戶狀態回滾——例如帳戶餘額異常、剛剛完成的高槓杆交易無故消失、遊戲狀態突然重置等。

第四，可能引發連鎖式故障：

一般來說，尾部分叉可能只會讓某個區塊晚確認一輪，影響不算大。但在一些邊緣場景下，如果連續幾位領導者都選擇跳過上一區塊，系統可能陷入停滯狀態，沒有人願意“接”前一個區塊。整個鏈的推進就此卡住，直到終於出現一個“願意把責任扛下來”的領導者，網路才會繼續前進。

雖然此前也有一些解決方案，比如 BeeGees 協議提出的尾部分叉規避機制，但往往需要犧牲性能，比如重新引入二次通信復雜度，得不償失。

什麼是 MonadBFT？

MonadBFT 是專門爲了解決尾部分叉問題而設計的新一代共識協議。它的厲害之處在於：在解決結構性隱患的同時，沒有犧牲掉流水線 HotStuff 帶來的性能優勢。換句話說，MonadBFT 並不是推倒重來，而是基於 HotStuff 的核心框架，繼續優化。它保留了三個關鍵特性：

1）領導者輪換（rotating leader）：每一輪選出新的領導者來推進鏈；

2）流水線提交（pipelined commits）：多個區塊確認過程可以重疊進行；

3）線性通信（linear messaging）：每個驗證者只需要跟領導者溝通，省下大量網路開銷。

但僅靠這三點，還不夠安全。爲了堵上尾部分叉這個結構性漏洞，MonadBFT 加上了兩套關鍵機制：

1）強制重新提議機制（Re-Proposal）

2）無背書證書（NEC, No-Endorsement Certificate）

重新提議機制（Re-Proposal）

在 BFT 協議中，時間被劃分爲一個個輪次（稱爲 view），每個輪次有一位領導者負責提出新區塊。如果領導者失敗（例如沒有按時提出區塊，或者提案無效），系統將切換到下一輪，並選出新的領導者。

MonadBFT 增加了一項機制，確保在view切換過程中，任何誠實提出的區塊都不會因爲領導者輪換而“掉鏈子”。

當當前輪的領導者失效時，驗證者會發出一個籤名的輪次切換消息（view change），表明當前輪次已超時。

特別的是，這條消息不僅僅表示“超時了”，還必須包含該驗證者最近一次投票的區塊信息，相當於說：“我沒收到合法提案，這是我當前看到的最新區塊。”

新一輪的領導者將從超級多數（2f+1）個驗證者那裏收集這些超時消息，並將其合並成一個超時證明（Timeout Certificate, TC）。這個 TC 代表的是：當上一個輪次失敗時，整個網路對“鏈頭區塊”的統一認知快照。新領導者會從中挑出最高高度（或最新視圖號）的區塊，即所謂的 high_tip。

MonadBFT 要求：新領導者的提案必須包含一個合法 TC，並且必須重新提議 TC 中最高的掛起區塊，讓這個區塊再次獲得被確認的機會。

爲什麼？正如我們前面提到的：我們不希望一個接近被確認的區塊就此消失。

舉個例子：假設 Alice 是 view 5 的領導者，提出了一個有效區塊，並獲得多數投票。接下來，view 6 的領導者 Bob 離線，未能推進鏈進程。等到 Carol 擔任 view 7 的領導者時，根據 MonadBFT 的規則，她必須包含 TC，並重新提議 Alice 的區塊。這樣一來，Alice 的誠實勞動不會白費。

如果 Carol 沒有 Alice 的區塊，她可以從其他節點請求。節點可以：

提供該區塊，或者

返回一條籤名的“無背書消息”（No-Endorsement, NE），表示自己沒有這個區塊（後文介紹其機制）。（最多 f 個拜佔庭節點可能選擇無視請求，不作回應。）

一旦 Carol 重新提議了 Alice 的區塊，她將獲得一個額外的提案機會，確保不會因爲上一輪領導者的失敗而被“連坐”。

這個重新提議機制的作用是明確的：確保鏈的推進是公平的，任何有效工作都不會因運氣不好或有人搗亂而被悄悄丟棄。

無背書證書（NEC）

繼續剛才的例子：Bob 的輪次超時後，Carol 請求其他驗證者提供 high_tip 區塊（即 Alice 的區塊）。此時，至少 2f+1 個驗證者將作出響應：

要麼提供 Alice 的區塊

要麼發送籤名的 NE 消息，表示自己沒有收到 Alice 的區塊

只要 Carol 收到了 Alice 的區塊，她就必須按規則重新提議它。只有在至少 f+1 個驗證者都籤署了 NE 消息的情況下，Carol 才可以跳過該區塊並提出一個新的。

爲什麼是 f+1？在一個由 3f+1 個驗證者組成的 BFT 系統中，最多只有 f 個可能作惡。如果 Alice 的區塊確實獲得了超級多數投票，那至少有 2f+1 個誠實節點收到了它。

因此，如果 Carol 聲稱“我沒法拿到 Alice 的區塊”，那她必須拿出 f+1 個驗證者籤名，證明這些人都沒收到。這就構成了一個無背書證書（No-Endorsement Certificate, NEC）。

NEC 是領導者“免責”的憑證：它是一個可驗證的證據，表示前一區塊尚未準備好被確認，自己不是惡意跳過，而是有理有據地“放棄”。

重新提議 + 無背書證書 = 解決尾部分叉

MonadBFT 通過引入 重新提議機制（Re-Proposal） 和 無背書證書（NEC, No-Endorsement Certificate），確立了一套嚴謹且明確的鏈頭處理規則：

要麼對“接近被確認”的區塊完成最終提交；

要麼提供足夠證據，證明該區塊尚不具備被確認的條件，

否則，不允許跳過或替換前一區塊。

這條機制確保了：任何已獲得法定多數投票的區塊，不會因領導者失誤或故意規避而被放棄。

尾部分叉的結構性風險被系統性化解，協議能夠對不當跳過行爲形成明確約束。

如果某位領導者試圖無故跳過上一區塊，但未能提供 NEC 佐證，協議將立即識別並拒絕該行爲。沒有加密證據的跳躍行爲將被視爲非法，不會獲得網路共識支持。

從經濟激勵層面來看，這一設計對驗證者提供了明確保護：

只要是誠實提出並獲得投票支持的區塊，其獎勵就不會因後續環節故障而被剝奪；

即使在極端情境下，例如某個節點故意跳過自己的提案輪次，試圖協助他人搶佔前一區塊的 MEV，協議也會強制後繼領導者優先重新提議原區塊，使攻擊者無法通過跳過流程獲取經濟收益。

更重要的是，MonadBFT 並未爲了提升安全性而犧牲協議的性能表現。

此前一些應對尾部分叉的設計（如 BeeGees 協議）雖然具備一定防護能力，但往往依賴於高通信復雜度（n²）或在每一輪都啓用重通信流程，這在實踐中會顯著增加系統負擔。

MonadBFT 的設計策略則更爲精巧：

只有在視圖失敗或存在異常時，才啓動額外的通信（如超時消息、區塊重提議）。在大多數誠實領導者連續出塊的常規路徑上，協議仍維持輕量、高效的運行狀態。

這種在性能與安全性之間的動態平衡，正是 MonadBFT 相較前代協議的核心優勢之一。

總結

本文回顧了傳統 PBFT 共識的基本機制，梳理了 HotStuff 協議的發展路徑，並重點講解了 MonadBFT 如何從協議層結構上，解決流水線 HotStuff 內生的尾部分叉問題。

尾部分叉會扭曲區塊提議者的經濟激勵，也對網路的活性構成潛在威脅。MonadBFT 通過引入重新提議機制和無背書證書（NEC），確保任何由誠實領導者提出、並獲得法定多數投票的區塊都不會被遺棄或跳過。

在下一篇中，我們將繼續探討 MonadBFT 的另外兩個核心特性：

1）準終局性（Speculative Finality）

2）樂觀響應性（Optimistic Responsiveness）

並進一步分析這些機制對驗證者和開發者的實際意義。

未完待續。