MonadBFT 是專為解決尾部分叉問題而設(shè)計(jì)的新一代共識(shí)協(xié)議。

區(qū)塊鏈的核心目標(biāo)在于實(shí)現(xiàn)嚴(yán)格的全球共識(shí)：無論節(jié)點(diǎn)分布在全球任何角落，所有參與者最終都必須就一組客觀結(jié)果達(dá)成一致。然而現(xiàn)實(shí)中的分布式網(wǎng)絡(luò)充滿挑戰(zhàn)——節(jié)點(diǎn)可能掉線、撒謊甚至故意破壞。共識(shí)協(xié)議應(yīng)運(yùn)而生，它本質(zhì)上是一套規(guī)則，指導(dǎo)彼此獨(dú)立且不完全可信的節(jié)點(diǎn)，就每筆交易的順序和內(nèi)容達(dá)成統(tǒng)一決定。一旦嚴(yán)格共識(shí)建立，區(qū)塊鏈便能解鎖數(shù)字產(chǎn)權(quán)保障、抗通脹貨幣模型等關(guān)鍵特性。但前提是共識(shí)協(xié)議必須同時(shí)滿足兩個(gè)基本要求：不能出現(xiàn)兩個(gè)互相沖突的區(qū)塊都被確認(rèn)；網(wǎng)絡(luò)必須持續(xù)推進(jìn)，不能卡住或停擺。MonadBFT 正是在這一方向上的最新技術(shù)突破。

### 共識(shí)協(xié)議的演進(jìn)回顧

共識(shí)機(jī)制的研究已持續(xù)數(shù)十年。早期的協(xié)議如 PBFT（實(shí)用拜占庭容錯(cuò)）已能處理現(xiàn)實(shí)場(chǎng)景：即使網(wǎng)絡(luò)中有部分節(jié)點(diǎn)掉鏈子、作惡或胡說八道，只要它們不超過總數(shù)的 1/3，系統(tǒng)仍能達(dá)成一致。這些早期協(xié)議采用傳統(tǒng)設(shè)計(jì)：每輪選出一個(gè)領(lǐng)導(dǎo)者發(fā)起提案，其他驗(yàn)證者多輪投票確認(rèn)交易順序。整個(gè)投票流程通常分為 pre-prepare、prepare、commit、reply 等階段，每個(gè)階段所有驗(yàn)證者需彼此通信。這種“全員互傳”的通信結(jié)構(gòu)復(fù)雜度高達(dá) n2——假設(shè)網(wǎng)絡(luò)有 100 個(gè)驗(yàn)證者，每輪共識(shí)可能需傳遞近 1 萬條消息。

在小型網(wǎng)絡(luò)中，這種通信負(fù)擔(dān)尚可接受，但驗(yàn)證者數(shù)量增加后，系統(tǒng)效率會(huì)迅速下降。這種“每個(gè)人跟每個(gè)人溝通”的二次通信結(jié)構(gòu)極低效。例如，在有 100 個(gè)驗(yàn)證者的網(wǎng)絡(luò)中，每輪共識(shí)可能需處理上萬條消息。在小圈子里尚能應(yīng)付，但在全球開放鏈上，通信負(fù)載會(huì)變得不可接受。因此，PBFT、Tendermint 等早期 BFT 協(xié)議通常只在許可制場(chǎng)景或驗(yàn)證者數(shù)量很少的系統(tǒng)中使用。

為了使 BFT 協(xié)議適應(yīng)無需許可的公鏈環(huán)境，新一代設(shè)計(jì)開始轉(zhuǎn)向更輕量的通信方式：每個(gè)驗(yàn)證者僅與領(lǐng)導(dǎo)者通信，而非全員互傳。消息復(fù)雜度從 n2 優(yōu)化為 n，大幅減輕系統(tǒng)負(fù)擔(dān)。HotStuff 協(xié)議于 2018 年提出，正是為了解決擴(kuò)展性問題。其設(shè)計(jì)理念是用更簡(jiǎn)潔的領(lǐng)導(dǎo)者驅(qū)動(dòng)通信結(jié)構(gòu)，替代 PBFT 的復(fù)雜投票流程。HotStuff 的關(guān)鍵特性是線性通信：每個(gè)驗(yàn)證者只需將投票發(fā)給當(dāng)前領(lǐng)導(dǎo)者，領(lǐng)導(dǎo)者再打包生成 Quorum Certificate（QC，法定多數(shù)證明）。QC 本質(zhì)上是集體簽名，證明“大多數(shù)節(jié)點(diǎn)同意了這個(gè)提案”。相比之下，PBFT 的“全員廣播”模式混亂低效，而 HotStuff 的“一人收集，一次打包”模式高效運(yùn)轉(zhuǎn)。

HotStuff 還可升級(jí)為流水線版本，進(jìn)一步提升效率。原始 HotStuff 中，同一位驗(yàn)證者會(huì)連續(xù)擔(dān)任多輪領(lǐng)導(dǎo)者，直到一個(gè)區(qū)塊被完整確認(rèn)為止，過程“一輪處理一個(gè)區(qū)塊”。流水線 HotStuff 則更靈活：每輪選出新的領(lǐng)導(dǎo)者，每位領(lǐng)導(dǎo)者同時(shí)完成兩項(xiàng)任務(wù)：
1. 將上一輪的投票打包成 QC 并廣播；
2. 提出新的區(qū)塊。

不再是“確認(rèn)完一個(gè)再處理下一個(gè)”，而是像生產(chǎn)線一樣，不同領(lǐng)導(dǎo)者輪流負(fù)責(zé)每個(gè)環(huán)節(jié)，鏈上共識(shí)像接力賽一樣傳下去。這就是“流水線”的由來：當(dāng)前區(qū)塊還在走確認(rèn)流程，下一個(gè)已在準(zhǔn)備中，多步并行，提高吞吐效率。

總結(jié)來說，HotStuff 相比傳統(tǒng) BFT 在兩個(gè)維度上重大提升：
1. 通信更輕量，每個(gè)驗(yàn)證者僅與領(lǐng)導(dǎo)者通信；
2. 處理效率更高，多個(gè)區(qū)塊確認(rèn)流程可并行。

這使得 HotStuff 成為許多現(xiàn)代 PoS 區(qū)塊鏈共識(shí)機(jī)制的設(shè)計(jì)模板。但凡事有利有弊——流水線結(jié)構(gòu)雖然性能強(qiáng)勁，卻也引入了結(jié)構(gòu)性風(fēng)險(xiǎn)：尾部分叉問題。

### 尾部分叉問題

HotStuff 尤其是流水線版本解決了擴(kuò)展性問題，但也帶來了新的挑戰(zhàn)，其中最關(guān)鍵的是“尾部分叉”（Tail Forking）。

什么是尾部分叉？簡(jiǎn)單來說，是區(qū)塊鏈在“鏈尾”發(fā)生意外的區(qū)塊重組。具體表現(xiàn)為：某個(gè)區(qū)塊有效、已傳播到大多數(shù)驗(yàn)證者、獲得足夠投票支持，按理說即將被確認(rèn)，但最終卻被跳過（orphaned），取而代之的是同一高度的新區(qū)塊。這不是 Bug 或攻擊，而是協(xié)議設(shè)計(jì)結(jié)構(gòu)中的固有風(fēng)險(xiǎn)。

流水線 HotStuff 中，每位領(lǐng)導(dǎo)者同時(shí)負(fù)責(zé)：
A. 提議新區(qū)塊（如 B???）；
B. 為前一位領(lǐng)導(dǎo)者的區(qū)塊收集投票，生成 QC（如為 B? 完成最終確認(rèn)）。

這兩個(gè)任務(wù)是并行的，輪番接力。問題就出在這里。例如，假設(shè) Alice 是領(lǐng)導(dǎo)者，在第 n 高度提出區(qū)塊 B?，獲得多數(shù)投票。接下來 Bob 擔(dān)任領(lǐng)導(dǎo)者，推進(jìn) B???，本應(yīng)將 B? 的 QC 打包進(jìn)提案完成確認(rèn)。但若 Bob 離線或故意不提交 B? 的 QC，B? 的投票記錄就無法傳播，最終被忽略。這就是尾部分叉的本質(zhì)：前一個(gè)領(lǐng)導(dǎo)者的區(qū)塊因下一個(gè)領(lǐng)導(dǎo)者的失職或惡意而被跳過。

尾部分叉為何嚴(yán)重？主要體現(xiàn)在：
1. **激勵(lì)機(jī)制被破壞**：被跳過的區(qū)塊提議者拿不到獎(jiǎng)勵(lì)（出塊獎(jiǎng)勵(lì)或手續(xù)費(fèi)），導(dǎo)致錯(cuò)誤激勵(lì)——惡意節(jié)點(diǎn)可通過跳過對(duì)手區(qū)塊“掐斷”其收益來源。長(zhǎng)期以往，系統(tǒng)參與度和公平性下降，甚至誘發(fā)串謀。
2. **MEV 攻擊空間擴(kuò)大**：假設(shè) Alice 的區(qū)塊有高價(jià)值套利交易，Bob 可與下一位領(lǐng)導(dǎo)者 Carol 串通，不傳播 Alice 區(qū)塊，改由 Carol 在相同高度重新構(gòu)造新區(qū)塊“抄走”套利交易。這種“鏈頭重排 + 串通挪用”表面合法，實(shí)則掠奪。更糟的是，誘導(dǎo)領(lǐng)導(dǎo)者建立共謀關(guān)系，使區(qū)塊確認(rèn)變成利益分配游戲。
3. **破壞終局性保障**：BFT 協(xié)議的優(yōu)勢(shì)是區(qū)塊一旦提交無法回滾，但尾部分叉破壞了這一保證。高吞吐 dapp 可能依賴區(qū)塊投票通過后的即時(shí)數(shù)據(jù)讀取，若區(qū)塊被丟棄，用戶狀態(tài)可能回滾（如賬戶余額異常、高杠桿交易消失、游戲狀態(tài)重置）。
4. **可能引發(fā)連鎖式故障**：若連續(xù)幾位領(lǐng)導(dǎo)者跳過上一區(qū)塊，系統(tǒng)可能停滯，直到出現(xiàn)“愿意承擔(dān)責(zé)任”的領(lǐng)導(dǎo)者才繼續(xù)。

### MonadBFT 的解決方案

MonadBFT 專為解決尾部分叉問題設(shè)計(jì)，在保留 HotStuff 性能優(yōu)勢(shì)的同時(shí)，彌補(bǔ)了結(jié)構(gòu)性隱患。它基于 HotStuff 核心框架，保留三個(gè)關(guān)鍵特性：
1. **領(lǐng)導(dǎo)者輪換**：每輪選出新的領(lǐng)導(dǎo)者推進(jìn)鏈；
2. **流水線提交**：多個(gè)區(qū)塊確認(rèn)過程可重疊進(jìn)行；
3. **線性通信**：每個(gè)驗(yàn)證者僅與領(lǐng)導(dǎo)者溝通。

但僅靠這三點(diǎn)不夠安全。MonadBFT 增加了兩個(gè)關(guān)鍵機(jī)制：
1. **強(qiáng)制重新提議機(jī)制（Re-Proposal）**；
2. **無背書證書（NEC, No-Endorsement Certificate）**。

#### 重新提議機(jī)制（Re-Proposal）

在 BFT 協(xié)議中，時(shí)間被劃分為輪次（view），每輪一位領(lǐng)導(dǎo)者負(fù)責(zé)提議新區(qū)塊。若領(lǐng)導(dǎo)者失敗，系統(tǒng)切換到下一輪并選出新的領(lǐng)導(dǎo)者。MonadBFT 增加機(jī)制，確保任何誠(chéng)實(shí)提出的區(qū)塊不會(huì)因領(lǐng)導(dǎo)者輪換而“掉鏈子”。

當(dāng)當(dāng)前輪領(lǐng)導(dǎo)者失效時(shí)，驗(yàn)證者會(huì)發(fā)出簽名的輪次切換消息（view change），包含最近一次投票的區(qū)塊信息，相當(dāng)于：“我沒收到合法提案，這是我看到的最新區(qū)塊?！?新一輪領(lǐng)導(dǎo)者從超級(jí)多數(shù)（2f+1）個(gè)驗(yàn)證者處收集這些消息，合并成超時(shí)證明（Timeout Certificate, TC）。TC 代表網(wǎng)絡(luò)對(duì)“鏈頭區(qū)塊”的統(tǒng)一認(rèn)知快照，新領(lǐng)導(dǎo)者需從中挑出最高高度（或最新視圖號(hào)）的區(qū)塊，即 high_tip，并重新提議它。

為什么？正如前文所述，不希望接近被確認(rèn)的區(qū)塊消失。例如，Alice 是 view 5 的領(lǐng)導(dǎo)者，提出有效區(qū)塊并獲得多數(shù)投票。若 view 6 的領(lǐng)導(dǎo)者 Bob 離線，Carol 擔(dān)任 view 7 領(lǐng)導(dǎo)者時(shí)，必須包含 TC 并重新提議 Alice 區(qū)塊。若 Carol 沒有該區(qū)塊，可向其他節(jié)點(diǎn)請(qǐng)求：提供區(qū)塊或返回簽名的“無背書消息”（NE），表示未收到。最多 f 個(gè)拜占庭節(jié)點(diǎn)可無視請(qǐng)求。一旦 Carol 重新提議 Alice 區(qū)塊，她將獲得額外提案機(jī)會(huì)，確保不會(huì)因上一輪領(lǐng)導(dǎo)者失敗而被“連坐”。

#### 無背書證書（NEC）

繼續(xù)剛才的例子：Bob 輪次超時(shí)后，Carol 請(qǐng)求 high_tip 區(qū)塊（Alice 區(qū)塊）。至少 2f+1 個(gè)驗(yàn)證者會(huì)響應(yīng)：
– 提供該區(qū)塊；
– 發(fā)送簽名的 NE 消息，表示未收到。

只要 Carol 收到 Alice 區(qū)塊，就必須重新提議。只有當(dāng)至少 f+1 個(gè)驗(yàn)證者簽署 NE 消息時(shí)，她才能跳過該區(qū)塊。為什么是 f+1？在 3f+1 個(gè)驗(yàn)證者的系統(tǒng)中，最多 f 個(gè)可能作惡。若 Alice 區(qū)塊確實(shí)獲得超級(jí)多數(shù)投票，至少 2f+1 個(gè)誠(chéng)實(shí)節(jié)點(diǎn)收到它。因此，若 Carol 聲稱“沒收到 Alice 區(qū)塊”，她必須提供 f+1 個(gè)驗(yàn)證者簽名證明這些人都未收到。NEC 是領(lǐng)導(dǎo)者“免責(zé)”的憑證，可驗(yàn)證地證明前一區(qū)塊尚未準(zhǔn)備好被確認(rèn)，自己不是惡意跳過，而是有理有據(jù)地“放棄”。

### MonadBFT 的核心機(jī)制

MonadBFT 通過重新提議機(jī)制和無背書證書（NEC），確立了一套嚴(yán)謹(jǐn)?shù)逆滎^處理規(guī)則：
– 要么完成“接近被確認(rèn)”的區(qū)塊最終提交；
– 要么提供足夠證據(jù)證明該區(qū)塊尚不具備被確認(rèn)條件，
否則，不允許跳過或替換前一區(qū)塊。

這條機(jī)制確保：任何已獲得法定多數(shù)投票的區(qū)塊，不會(huì)因領(lǐng)導(dǎo)者失誤或故意規(guī)避而被放棄。尾部分叉的結(jié)構(gòu)性風(fēng)險(xiǎn)被系統(tǒng)性化解，協(xié)議對(duì)不當(dāng)跳過行為形成明確約束。若領(lǐng)導(dǎo)者試圖無故跳過上一區(qū)塊但未能提供 NEC 佐證，協(xié)議將立即識(shí)別并拒絕。

從經(jīng)濟(jì)激勵(lì)層面看，這一設(shè)計(jì)對(duì)驗(yàn)證者提供明確保護(hù)：誠(chéng)實(shí)提出并獲得投票支持的區(qū)塊，其獎(jiǎng)勵(lì)不會(huì)因后續(xù)環(huán)節(jié)故障而被剝奪；即使極端情境下，例如節(jié)點(diǎn)故意跳過自己的提案輪次試圖協(xié)助他人搶占 MEV，協(xié)議也會(huì)強(qiáng)制后繼領(lǐng)導(dǎo)者優(yōu)先重新提議原區(qū)塊，使攻擊者無法通過跳過流程獲取經(jīng)濟(jì)收益。

更重要的是，MonadBFT 并未為提升安全性犧牲性能。此前一些解決方案（如 BeeGees 協(xié)議）雖具備防護(hù)能力，但往往依賴高通信復(fù)雜度（n2）或每輪重通信，增加系統(tǒng)負(fù)擔(dān)。MonadBFT 的設(shè)計(jì)更為精巧：只有在視圖失敗或異常時(shí)才啟動(dòng)額外通信（如超時(shí)消息、區(qū)塊重提議），常規(guī)路徑上仍維持輕量高效運(yùn)行。這種性能與安全性的動(dòng)態(tài)平衡，是 MonadBFT 相較前代協(xié)議的核心優(yōu)勢(shì)。

### 總結(jié)

本文回顧了傳統(tǒng) PBFT 的基本機(jī)制，梳理了 HotStuff 的發(fā)展路徑，并重點(diǎn)講解了 MonadBFT 如何從協(xié)議層結(jié)構(gòu)上解決流水線 HotStuff 內(nèi)生的尾部分叉問題。尾部分叉扭曲區(qū)塊提議者的經(jīng)濟(jì)激勵(lì)，威脅網(wǎng)絡(luò)活性。MonadBFT 通過重新提議機(jī)制和無背書證書（NEC），確保任何誠(chéng)實(shí)領(lǐng)導(dǎo)者提出、并獲得法定多數(shù)投票的區(qū)塊都不會(huì)被遺棄或跳過。

在下一篇中，我們將繼續(xù)探討 MonadBFT 的另外兩個(gè)核心特性：
1. **準(zhǔn)終局性（Speculative Finality）**；
2. **樂觀響應(yīng)性（Optimistic Responsiveness）**，并進(jìn)一步分析這些機(jī)制對(duì)驗(yàn)證者和開發(fā)者的實(shí)際意義。

未完待續(xù)。

歡迎加入深潮 TechFlow 官方社群 Telegram 訂閱群：http://iy168.cn/TechFlowDaily
Twitter 官方賬號(hào)：http://iy168.cn/TechFlowPost
Twitter 英文賬號(hào)：http://iy168.cn/BlockFlow_News