作者：michaellwy
区块链的核心在于实现一种严格的全球共识（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）。
虽然 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 是专门为了解决尾部分叉问题而设计的新一代共识协议。它的厉害之处在于：在解决结构性隐患的同时，没有牺牲掉流水线 HotStuff 带来的性能优势。换句话说，MonadBFT 并不是推倒重来，而是基于 HotStuff 的核心框架，继续优化。它保留了三个关键特性：
1）领导者轮换（rotating leader）：每一轮选出新的领导者来推进链；
2）流水线提交（pipelined commits）：多个区块确认过程可以重叠进行；
3）线性通信（linear messaging）：每个验证者只需要跟领导者沟通，省下大量网络开销。
但仅靠这三点，还不够安全。为了堵上尾部分叉这个结构性漏洞，MonadBFT 加上了两套关键机制：
1）强制重新提议机制（Re-Proposal）
2）无背书证书（NEC, No-Endorsement Certificate）
在 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 的区块，她将获得一个额外的提案机会，确保不会因为上一轮领导者的失败而被“连坐”。
这个重新提议机制的作用是明确的：确保链的推进是公平的，**有效工作都不会因运气不好或有人捣乱而被悄悄丢弃。
继续刚才的例子：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）
并进一步分析这些机制对验证者和开发者的实际意义。
未完待续。
