MonadBFT 解析（上）：如何解決尾部分叉問題
區塊鏈的核心在於實現一種嚴格的全球共識（strict global consensus）：也就是說，不管網路節點分布在哪個國家、哪個時區，所有參與者最後都必須對一組客觀結果達成一致。
但現實中的分布式網路並不理想：有節點掉線，有節點撒謊，甚至還有人故意搞破壞。在這種情況下，系統又是如何“衆口一詞”，保持一致的？
這就是共識協議要解決的問題。它本質上是一套規則，用來指導一羣彼此獨立、甚至不完全可信的節點，如何就每筆交易的順序和內容達成統一的決定。
而一旦這種“嚴格共識”建立起來，區塊鏈就能解鎖許多關鍵特性，比如數字產權保障、抗通脹的貨幣模型，以及可擴展的社會協作結構。但前提是，共識協議本身必須同時保證兩個基本面：
- 不能出現兩個互相衝突的區塊都被確認；
- 網路必須持續推進，不能卡住或停擺。
MonadBFT 就是在這個方向上做出的最新技術突破。
共識協議的簡要演進回顧
共識機制這個領域，其實已經研究了幾十年。最早的一批協議，比如 PBFT（實用拜佔庭容錯），就已經能處理一種很現實的情況：即使網路裏有部分節點掉鏈子、作惡、胡說八道，只要它們不超過總數的 1/3，系統就還能達成一致。
這些早期協議的設計方式比較“傳統”：每一輪選出一個領導者，由他發起提案，其它驗證者對這個提案進行多輪投票，一步步確認交易順序。
整個投票流程通常要經過幾個階段，比如 pre-prepare、prepare、commit、reply。在每個階段，所有驗證者都要彼此通信。換句話說，每個人都得跟每個人說一遍，消息量呈“網狀”爆發式增長。
這種通信結構的復雜度是 n²——也就是說，假如網路裏有 100 個驗證者，那每一輪共識就可能要傳遞將近 1 萬條消息。
這在小型網路裏問題不大，但一旦驗證者數量上來，系統的通信負擔會迅速變得難以承受，效率直接拉垮。
資料來源：https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae
這種“每個人跟要跟每個人溝通”的二次通信結構，其實非常低效。比如說，在一個有 100 個驗證者的網路裏，每輪共識就可能要處理上萬條消息。
這在一個小圈子裏還能應付，但要是放在全球範圍、開放式的鏈上網路裏，通信負載馬上就變得不可接受了。於是像 PBFT、Tendermint 這樣的早期 BFT 協議，通常只在許可制場景（permissioned network）或者驗證者數量很少的系統中使用，才能勉強跑得動。
爲了讓 BFT 協議也能適應無需許可、公鏈環境，一些新一代的設計開始走向更輕量的通信方式：讓每個驗證者只和領導者通信，而不是全員互傳。
這就把消息復雜度從原本的 n²，優化成了 n —— 大大減輕了系統負擔。
HotStuff 協議就是在 2018 年提出的，正是爲了解決這個擴展性問題。它的設計理念非常明確：用更簡潔、領導者驅動的通信結構，替代 PBFT 的復雜投票流程。
HotStuff 的關鍵特性是所謂的線性通信（linear communication）。在它的機制裏，每個驗證者只需把自己的投票發給當前領導者，領導者再把這些投票打包，生成一個Quorum Certificate（QC，法定多數證明）。
這個 QC 本質上就是一個集體籤名，向整個網路證明：“大多數節點同意了這個提案。”
相比之下，PBFT 的通信模式是“全員廣播”，每個人都在羣裏說話，場面一度十分混亂。HotStuff 的模式更像是 “一人收集，一次打包”，不管網路有多少人，依然能保持高效運轉。
上圖對比了 HotStuff 的扇出式通信結構與 PBFT 的全網互聯模式 資料來源：
https://www.mdpi.com/1424-8220/24/16/5417
除了線性通信外，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）
並進一步分析這些機制對驗證者和開發者的實際意義。
聲明：
- 本文轉載自 [michael_lwy]，著作權歸屬原作者 [michael_lwy]，如對轉載有異議，請聯系 Gate Learn 團隊 )，團隊會根據相關流程盡速處理。
- 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
- 文章其他語言版本 由Gate Learn 團隊翻譯， 在未提及 Gate.io) 的情況下不得復制、傳播或抄襲經翻譯文章。
Related articles
什麼是穩定幣 USDT？
MonadBFT 解析（上）：如何解決尾部分叉問題
區塊鏈的核心在於實現一種嚴格的全球共識（strict global consensus）：也就是說，不管網路節點分布在哪個國家、哪個時區，所有參與者最後都必須對一組客觀結果達成一致。
但現實中的分布式網路並不理想：有節點掉線，有節點撒謊，甚至還有人故意搞破壞。在這種情況下，系統又是如何“衆口一詞”，保持一致的？
這就是共識協議要解決的問題。它本質上是一套規則，用來指導一羣彼此獨立、甚至不完全可信的節點，如何就每筆交易的順序和內容達成統一的決定。
而一旦這種“嚴格共識”建立起來，區塊鏈就能解鎖許多關鍵特性，比如數字產權保障、抗通脹的貨幣模型，以及可擴展的社會協作結構。但前提是，共識協議本身必須同時保證兩個基本面：
- 不能出現兩個互相衝突的區塊都被確認；
- 網路必須持續推進，不能卡住或停擺。
MonadBFT 就是在這個方向上做出的最新技術突破。
共識協議的簡要演進回顧
共識機制這個領域，其實已經研究了幾十年。最早的一批協議，比如 PBFT（實用拜佔庭容錯），就已經能處理一種很現實的情況：即使網路裏有部分節點掉鏈子、作惡、胡說八道，只要它們不超過總數的 1/3，系統就還能達成一致。
這些早期協議的設計方式比較“傳統”：每一輪選出一個領導者，由他發起提案，其它驗證者對這個提案進行多輪投票，一步步確認交易順序。
整個投票流程通常要經過幾個階段，比如 pre-prepare、prepare、commit、reply。在每個階段，所有驗證者都要彼此通信。換句話說，每個人都得跟每個人說一遍，消息量呈“網狀”爆發式增長。
這種通信結構的復雜度是 n²——也就是說，假如網路裏有 100 個驗證者，那每一輪共識就可能要傳遞將近 1 萬條消息。
這在小型網路裏問題不大，但一旦驗證者數量上來，系統的通信負擔會迅速變得難以承受，效率直接拉垮。
資料來源：https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae
這種“每個人跟要跟每個人溝通”的二次通信結構，其實非常低效。比如說，在一個有 100 個驗證者的網路裏，每輪共識就可能要處理上萬條消息。
這在一個小圈子裏還能應付，但要是放在全球範圍、開放式的鏈上網路裏，通信負載馬上就變得不可接受了。於是像 PBFT、Tendermint 這樣的早期 BFT 協議，通常只在許可制場景（permissioned network）或者驗證者數量很少的系統中使用，才能勉強跑得動。
爲了讓 BFT 協議也能適應無需許可、公鏈環境，一些新一代的設計開始走向更輕量的通信方式：讓每個驗證者只和領導者通信，而不是全員互傳。
這就把消息復雜度從原本的 n²，優化成了 n —— 大大減輕了系統負擔。
HotStuff 協議就是在 2018 年提出的，正是爲了解決這個擴展性問題。它的設計理念非常明確：用更簡潔、領導者驅動的通信結構，替代 PBFT 的復雜投票流程。
HotStuff 的關鍵特性是所謂的線性通信（linear communication）。在它的機制裏，每個驗證者只需把自己的投票發給當前領導者，領導者再把這些投票打包，生成一個Quorum Certificate（QC，法定多數證明）。
這個 QC 本質上就是一個集體籤名，向整個網路證明：“大多數節點同意了這個提案。”
相比之下，PBFT 的通信模式是“全員廣播”，每個人都在羣裏說話，場面一度十分混亂。HotStuff 的模式更像是 “一人收集，一次打包”，不管網路有多少人，依然能保持高效運轉。
上圖對比了 HotStuff 的扇出式通信結構與 PBFT 的全網互聯模式 資料來源：
https://www.mdpi.com/1424-8220/24/16/5417
除了線性通信外，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）
並進一步分析這些機制對驗證者和開發者的實際意義。
聲明：
- 本文轉載自 [michael_lwy]，著作權歸屬原作者 [michael_lwy]，如對轉載有異議，請聯系 Gate Learn 團隊 )，團隊會根據相關流程盡速處理。
- 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
- 文章其他語言版本 由Gate Learn 團隊翻譯， 在未提及 Gate.io) 的情況下不得復制、傳播或抄襲經翻譯文章。
Related articles