| 抗女巫机制 | 权益证明 (PoS) |
| 最小区块时间 | 300 ms |
| 最终确认 | 2 个时隙 (600 ms) |
| 推测性最终确认 *(仅在[罕见情况](#speculative-finality)下可以回滚,该情况需要原始领导者进行等价签名*) | 1 个时隙 (300 ms) |
| 允许委托 | 是 |
说明 MonadBFT 的流水线化(交错)性质。与前一张图相同,但缩小到包含多一轮。
## 悲观路径(故障处理) 悲观路径描述了异常情况:领导者未能发送有效提案,或 QC 构建者(下一个领导者)未能构建 QC。 理解悲观路径对于理解乐观路径的工作方式也至关重要!最终允许验证者在收到子提案后推测性最终确认提案,或在收到孙提案后最终确认提案的,是知道回退机制仍将保留原始提案。 在这里,我们将专注于标准恢复,这实际上是回退机制的回退。在大多数实际情况下,我们可以使用[快速恢复](#fast-recovery),这大大加快了协议在故障发生后回到乐观路径的时间。 然而,为了让协议整体上实现抗尾端分叉性,即使在拜占庭故障的最坏情况下,我们也依赖于标准恢复,现在我们介绍它。 ### 场景 与之前一样,为了描述悲观路径的流程,我们将遵循图中所示的场景。 同样地,假设当前是轮次 `K`,Alice 是被安排的领导者。Bob 和 Charlie 是时间表中接下来的两位领导者。Alice 最后见过区块 `N-1`,所以她将提议区块 `N`。 在我们的示例中,Alice 在轮次 `K` 发送了区块 `N`,但 Bob 在轮次 `K+1` 未能发送区块。这可能是因为他离线了,也可能是因为 Alice 发送了一个无效区块,或者没有足够多的人为它投票。
### 轮次 `K`:Alice 的提案
1. **提案:** Alice,轮次 `K` 的指定领导者,选择一个负载并构建由该负载和来自先前提案的 [QC](#quorum-certificate-qc) 组成的区块 `N`(同样,不必担心这部分)。
Alice 将提案直接发送给所有其他验证者。
2. **投票:** 每个验证者检查提案的有效性,如果有效,则直接将签名投票发送给 Bob,轮次 `K+1` 的指定领导者。每个验证者本地将 Alice 的提案标记为 [`Proposed`](/zh/monad-arch/consensus/block-states#proposed)。
### 期望的轮次 `K+1`:Bob 错过的时隙
3. **Bob 未能提议区块 `N+1`**,因此所有投票都被吞掉,Alice 区块的 QC 没有产生。
4. **每个人发送超时消息:** 在超时窗口之后,每个验证者"意识到"轮次 `K` 失败了,因为 Alice 区块的 QC 未形成。因此,每个人向其他所有验证者发送关于区块 `K` 的[超时消息](#timeout-message)。(注意这种通信是全对全的。)
5. **TC 组装**:在获得超级多数超时消息后,包括 Bob 在内的每个验证者组装一个 [TC](#timeout-certificate-tc),证明轮次 `K`(Alice 提议者,Bob QC 构建者)失败。在为 `K` 构建 TC 后,验证者将其轮次推进到 `K+1`。
### 由 TC 推进的轮次 `K+1`
TC 包含一个称为 [`high_tip`](#high-tip) 的计算值,该值(粗略地讲)是任何贡献超时消息的验证者见过的最新有效区块的区块头。您可以将 `high_tip` 视为签署 TC 所需的 2/3 质押权重范围内观察到的最大区块。
在这个具体示例中,`high_tip` 将是 Alice 区块的区块头。
根据 MonadBFT 的规则,下一个领导者有义务要么重新提议 TC 的 `high_tip` 中引用的区块(即 Alice 的区块),要么证明该区块不受支持。(我们将在下面更详细地讨论这一点。)
由于我们现在在轮次 `K+1`,下一个领导者是 **Bob**。(您可能会觉得这具有讽刺意味,但这是协议无法区分 Bob 离线的可能性和 Alice 发送了无效区块或没有足够多的人对 Alice 的区块投票的可能性这一事实的必然结果。在后两种情况的任何一种下,跳过 Bob 都是不公平的。)
6. **(可选)从其他验证者请求 Alice 的区块**:Bob 需要重新提议 Alice 的区块。然而,`high_tip` 只是一个区块头 —— 不是完整的区块主体 —— 所以如果 Bob 没有 Alice 的区块,他可以从其他验证者请求完整版本(通过 [blocksync](/zh/monad-arch/consensus/blocksync))。
#### 重新提案情况(Bob 重新提议 Alice 的区块)
7. **重新提案**:如果 Bob 有 Alice 的区块(要么是因为在她最初提议时就收到了,要么是通过 blocksync),那么他将其连同证明重新提案合理的 TC 一起提议。
8. **投票:** 每个验证者对 Bob 重新提案的有效性进行投票。如果重新提案有效,验证者将其投票发送给下一个领导者 Charlie。
9. **QC 形成:** Charlie 从投票中组装一个 QC。
10. **Charlie 的提案:** Charlie 在轮次 `K+2` 构建一个由新负载和来自轮次 `K+1` 的重新提案 QC 组成的区块,并将该区块发送给每个人。此时 Alice 的区块对任何收到 Charlie 区块的人来说都变为 [`Voted`](/zh/monad-arch/consensus/block-states#voted)。每个人将其轮次推进到 `K+2`,协议返回到乐观路径。
#### 新鲜提案情况(Bob 证明 Alice 的区块不受支持)
7. **对 Bob 区块的无背书**:回想一下,在第 6 步中,Bob 被允许向其他验证者轮询 Alice 的区块。当验证者被轮询时,如果他们也没有,他们可以向 Bob 发送一条签名的[无背书消息](#no-endorsement-message-and-no-endorsement-certificate),证明 *没有* 见过 Alice 的区块。如果超级多数验证者签署了无背书消息,那么 Bob 可以组装一个[无背书证书 (NEC)](#no-endorsement-message-and-no-endorsement-certificate)。
8. **Bob 的新鲜提案**:根据 MonadBFT 的规则,Bob 可以跳过重新提议 Alice 的区块,而是在同一区块高度 `N` 上发起新区块的[新鲜提案](#fresh-proposal),前提是他还可以提供 NEC。
需要强调的是,Bob 只有在超级多数验证者签署 NEC 时才被允许跳过重新提议 Alice 的区块。否则,他有义务重新提议。这一规则有助于确保即使 Bob 未能为 Alice 的区块构建 QC,Alice 的区块也能最终确认。
从此,共识正常进行,返回到乐观路径。
#### 无提案情况
还有第三种可能性,即 Bob 在轮次 `K+1` 中完全没有提议任何东西。(这相当可能,因为他在第一次期望轮次 `K+1` 时就没有发送区块。) 在这种情况下,再次发生超时,这次是轮次 `K+1` 的超时,允许共识推进到轮次 `K+2`,即 Charlie 的回合。然后 Charlie 继承了 Bob 在轮次 `K+1` 的处境,即他必须要么重新提议 Alice 的区块,要么证明 Alice 的区块不受支持。
更一般地,如果 Charlie(以及可能后续的一些领导者)也未能提议任何东西,情况将持续下去,直到有人重新提议 Alice 的提案或证明它不受支持。这就是关于 `high_tip` 的 MonadBFT 规则,它确保 Alice 的区块最终会被最终确认,除非它本来就不应该被支持。
## 讨论
### 无尾端分叉
在先前的流水线化 HotStuff 家族共识协议的实现中,Bob 错过时隙的情况会导致 Alice 的提案也被回滚(尾端分叉)。这背后的直觉是:Bob 是唯一负责接收所有人对 Alice 提案投票的人,所以当他离线时,所有那些投票都会被吞掉,使得难以区分大多数验证者对 Alice 提案投 YES 的情况和大多数验证者拒绝她提案的情况。
例如,在 [Fast-HotStuff](https://arxiv.org/abs/2010.11454) 中,TC 携带足够的信息证明 Bob 错过了他的时隙,允许 Bob 合理地提议一个跳过 Alice 区块的区块,使 Alice 的区块成为牺牲品。Bob 只需在与 Alice 相同的区块高度重新提议,替换最终区块链中 Alice 的区块。这就是为什么 MonadBFT 之前的流水线化 HotStuff 共识机制经常出现成对的错过时隙。
**尾端分叉是一个严重的弱点。** 当 Alice 的区块被提议时,如果 Bob 在其中看到有价值的 MEV 机会,Bob —— 作为 QC 构建者(下一个领导者)—— 可能会拒绝为 Alice 的区块构建 QC,并提议携带 Alice QC 的自己的区块。在这种情况下,验证者无法检测到是 Alice 未能传播她的提案,还是 Bob 拒绝构建 QC;因此 Bob 在轮次 K+1 中获得了提议区块的机会。然后 Bob 可以通过只选择偏好的交易,以及随意重新排序或替换它们来提取高价值 MEV。在其他区块链中,无意中允许区块被重新挖矿已经造成了[巨大影响](https://ethresear.ch/t/equivocation-attacks-in-mev-boost-and-epbs/15338)。
MonadBFT 的无尾端分叉性质的关键在于对错过时隙情况的处理。直观地说,在 MonadBFT 中,[TC](#timeout-certificate-tc) 携带足够的信息,即使 Bob 吞掉了所有关于它的投票,也能向前传播关于 Alice 区块存在的知识。
当轮到 Bob 提议时,他有义务重新提议 Alice 的区块(基于 TC,其中包括 high\_tip,即 Alice 区块的有效区块头),除非他能获得超级多数(`2f+1`)证明 *没有* 见过 Alice 的区块。超级多数签署 [NEC](#no-endorsement-message-and-no-endorsement-certificate) 的事实是关键:即使 `f` 个节点是拜占庭的,仍然有 `f+1` 个非拜占庭节点证明 *没有* 见过 Alice 的区块,这保证了 Alice 的区块 *不应该* 达到法定人数,因为法定人数需要 `2f+1` 个投票,而至少有 `f+1` 个非拜占庭的 NO 投票。
[MonadBFT 论文](https://arxiv.org/abs/2502.20692)提供了对协议更严格的定义,以及尾端分叉不会发生的形式化证明。
### 推测性最终确认
MonadBFT 的另一个极佳特性是单时隙推测性最终确认。
为了解释这一点,首先要提醒的是,区块的状态始终是从特定观察者的角度而言的。例如,如果您收到了某个区块的 QC,那么您可以将该区块移到 [`Voted`](/zh/monad-arch/consensus/block-states#voted) 状态,但如果您的朋友尚未收到该 QC,那么她仍会认为该区块处于 [`Proposed`](/zh/monad-arch/consensus/block-states#proposed) 状态。
构建分布式共识机制的挑战在于定义规则,让节点能够在收到消息时单独更新其状态机,即使假设最坏情况,即假设它们可能是唯一收到该消息的节点。
#### 收到 Alice 的提案后
假设您是 Valerie,网络中的一个验证者。您收到了 Alice 的提案;您对其进行有效性检查,它们通过了,所以您将 Alice 的提案标记为 [`Proposed`](/zh/monad-arch/consensus/block-states#proposed)。
请注意,您不知道是否有其他人收到了这个提案,Alice 可能在耍花招,只将提案发送给您(或只发送给非常少数的节点),试图让您与其他所有人分歧。
#### 收到 Bob 的提案后
现在假设您收到了 Bob 的提案,其中携带了 Alice 提案的 QC。您对 Bob 的提案进行有效性检查,它们通过了,所以您将 Alice 的提案标记为 [`Voted`](/zh/monad-arch/consensus/block-states#voted)。
同样,虽然您现在拥有超级多数为 Alice 提案投票的证据,您仍应担心 Bob 可能只将其发送给您,试图欺骗您。您应该担心 Bob 的提案无法达到法定人数。
MonadBFT 的超能力在于,由于前面描述的处理超时的复杂规则集,当您处于 Valerie 收到 Bob 提案的位置时,您可以在很大程度上克服这种担心,至少就 Alice 提案的状态而言是这样。您可以在将 Alice 的提案移动到 `Voted` 阶段时对其进行 **推测性最终确认**。也就是说,您可以确信 Alice 的提案几乎肯定会被最终确认,除非出现非常特定的罕见情况。
直观地讲,根据我们上面所说的,这是合理的。您 Valerie 拥有 Alice 区块的 QC,由 Bob 组装。这实际上意味着,从您的角度来看,Bob 并未离线。
而且 **即使** Bob 对大多数人来说是 *有效离线* 的(例如,他只将下一个提案和 Alice 区块的 QC 发送给您),您知道流程将是组装一个 TC;那个 TC 中的 `high_tip` 可能指向 Alice 的区块。为什么?因为:
1. 您手中的 QC 证明超级多数(`2f+1`)已经见过 Alice 的区块,
2. TC 也需要超级多数(`2f+1`)
3. 因此至少 `f+1` 个投票者对 QC 和 TC 都是共同的,并且最多 `f` 个是拜占庭的,所以至少 1 个会引用 Alice 的区块。
如果 Alice 的区块进入 `high_tip`,那么 Charlie 将被迫重新提议它(除非他能得到关于它的 NEC,而他不能,因为那需要超级多数的无背书消息,而超级多数已经签署了 Alice 区块的 QC)。
所以乍一看,我们 Valerie 似乎可以在收到 Alice 区块的 QC 后立即最终确认它。
#### 唯一的漏洞
事实证明,有一个漏洞阻止我们如此自信。该漏洞出现的情况是,*Alice* **等价签名** —— 在第一个区块 `b`(我们有它的 QC)相同的高度上签署了第二个区块 `b'`,并将 `b'` 发送给了少数几个节点。
在这种情况下,如果 Bob 在离线前只将其提案发送给我们,那么最终 TC 中的 `high_tip` 可能会解析为 `b'` 而不是 `b`。如果发生这种情况,那么 Charlie 可能最终会重新提议 `b'`,或者收集关于 `b'` 的 NEC,并使用它来证明在 Alice 的区块高度提议一个新区块的合理性。
实际上,由于以下几个原因,这个漏洞极为罕见:
1. 等价签名是一个易于证明的过错 —— 您所需的所有证据就是同一高度上由 Alice 签署的两个区块。等价签名在区块链中是件大事,可以受到严厉惩罚。
2. 当 Alice 等价签名时,她只可能扰乱自己(同时也让自己面临等价签名的惩罚)。
[MonadBFT 论文](https://arxiv.org/abs/2502.20692)提供了这个论点的更严格版本。但总而言之,本地观察到 QC(将提案移到 `Voted`)是提案将最终确认的一个非常强的指标,因为它不会最终确认的唯一方式是 Alice 等价签名,Bob 错过了他的时隙,近 1/3 的网络是拜占庭的,并且我们对最终填充 TC 的节点相当不走运。
## 快速恢复
自 2025 年初发布原始 [MonadBFT 论文](https://arxiv.org/abs/2502.20692)以来,Category Labs 分析了协议的行为,并设计、评估和实现了多项改进。
协议的更改使得在最常见的故障场景中能够快速恢复。
这篇[博客文章](https://www.category.xyz/blogs/monadbft-update-fast-recovery-leader-fault-isolation)很好地介绍了快速恢复的工作原理。总而言之:
* 验证者现在不仅将投票发送给下一个视图的领导者,还发送给当前视图的领导者。这给了每个领导者一个机会收集自己提案的投票以形成 QC,而不是仅仅依赖下一个领导者(可能是拜占庭的)。领导者广播这个 QC。
* 验证者可以在他们的超时消息中包含他们观察到的最高 QC,而不是 tip。如果 QC 比本地最高 tip 更新(更新近),或者是在与 tip 相同的轮次中产生的,他们就这样做。
* 如果验证者在超时消息中发送 tip(而不是 high QC),验证者还包括一个 tip 投票,即以当前视图编号对该 tip 的投票。同一视图中对同一提案的 `2f+1` 个投票,通过常规投票或超时消息获得,可以组合形成一个新的 QC,可以由下一个领导者直接扩展。
* 超时证书包括收到的超时消息中最高的 QC,如果它至少与最高 tip 一样高。它还包含选择了正确的 high tip 或 high QC 的证明。如果 TC 包含 high QC,那么领导者可以直接提议一个扩展该 high QC 的新鲜区块。
这些机制在最常见的故障场景中实现了更快的恢复。例如,考虑视图 `v` 中的领导者离线的情况。在原始 MonadBFT 协议中,这将导致视图 `v-1` 和 `v` 超时(因为 `v-1` 中投出的投票丢失,视图 `v` 中没有区块被提议)。此外,视图 `v-1` 中提议的区块将必须在视图 `v+1` 中被重新提议,导致连续两个视图没有新鲜区块提案。
通过更新后的协议,几种机制实现了更快的恢复。例如,在视图 `v` 的超时消息中,每个验证者为视图 `v-1` 中提议的区块包含一个 tip 投票。这允许视图 `v+1` 的领导者在视图 `v` 中构造一个 QC。由于同一视图中不能形成两个冲突的 QC,`v+1` 的领导者可以直接提议一个扩展这个 QC 的新鲜区块。因此,单个崩溃的领导者只会导致该领导者的视图超时;所有其他视图都成功,并且在每个视图中都提议了新鲜区块。
其他机制同样提供了快速恢复选项。我们仍保留原始 MonadBFT 论文中的重新提案和[NEC](#no-endorsement-message-and-no-endorsement-certificate)机制以应对更复杂的拜占庭故障。然而,通过这些改进,我们相信大多数故障现在都可以通过新的快速恢复路径顺利处理。
***
## 参考文献
* Mohammad Mussadiq Jalalzai, Kushal Babel.
[MonadBFT: Fast, Responsive, Fork-Resistant Streamlined Consensus](https://arxiv.org/pdf/2502.20692), 2025.
* Maofan Yin, Dahlia Malkhi, Michael K. Reiter, Guy Golan Gueta, and Ittai Abraham.
[HotStuff: BFT Consensus in the Lens of Blockchain](https://arxiv.org/abs/1803.05069), 2018.
* Mohammad M. Jalalzai, Jianyu Niu, Chen Feng, Fangyu Gai.
[Fast-HotStuff: A Fast and Resilient HotStuff Protocol](https://arxiv.org/abs/2010.11454), 2020.
* Rati Gelashvili, Lefteris Kokoris-Kogias, Alberto Sonnino, Alexander Spiegelman, and Zhuolun Xiang.
[Jolteon and ditto: Network-adaptive efficient consensus with asynchronous fallback](https://arxiv.org/pdf/2106.10362.pdf).
arXiv preprint arXiv:2106.10362, 2021.
* The Diem Team.
[DiemBFT v4: State Machine Replication in the Diem Blockchain](https://developers.diem.com/papers/diem-consensus-state-machine-replication-in-the-diem-blockchain/2021-08-17.pdf), 2021.