Skip to main content

​
概要

MonadBFT 代表了拜占庭容错 (BFT) 共识的重大飞跃。它负责确保 Monad 网络高效且安全地就有效提议的区块达成一致,同时支持 10,000+ tx/s 的吞吐量和亚秒级最终确认时间,并且支持庞大的共识节点集。 MonadBFT 结合了所有这些特性,同时还抵御 尾端分叉——这是流水线化基于领导者的 BFT 协议的关键弱点,即领导者可以将其前任的区块分叉掉。 有关 MonadBFT 的完整描述和深入的技术剖析,请参阅完整研究论文、来自 Category Labs 的最新博客文章以及介绍 MonadBFT 的原始博客文章。 MonadBFT 实现了:
  • 在单轮共识中推测性最终确认,以及 在两轮内完全最终确认。
  • 在乐观路径(即正常运行、无故障时)上具有 线性消息和验证器复杂度。这使共识验证者集能够扩展到大量节点。
  • 乐观响应性:无论是在常见情况下还是在从失败的轮次恢复时,轮次推进都无需等待最坏情况的网络延迟。
  • 领导者故障隔离:单个失败的领导者只会导致一次超时延迟。所有其他轮次都能以网络允许的速度进行。这与现有的流水线化 BFT 协议形成对比,后者在领导者失败时会有两次超时。
  • 抗尾端分叉性:内置对尾端分叉的保护,尾端分叉是一类最大可提取价值 (MEV) 攻击,恶意领导者本可将其前任的区块分叉掉。这解决了先前基于领导者的流水线化 BFT 共识机制中的一个关键问题。
没有任何其他流水线化基于领导者的 BFT 协议能同时结合所有这些特性。
Category Labs 最近对 MonadBFT 进行了多项改进。本页面和研究论文现已使用完整细节进行了更新。请查看快速恢复章节或阅读这篇博客文章了解新变化。

​
Monad 中的配置

抗女巫机制权益证明 (PoS)
最小区块时间300 ms
最终确认2 个时隙 (600 ms)
推测性最终确认 (仅在罕见情况下可以回滚,该情况需要原始领导者进行等价签名)1 个时隙 (300 ms)
允许委托是

​
演示

请参阅 Category Labs 的这篇博客文章,查看 MonadBFT 的实时演示! 该演示运行的是驱动 Monad 区块链的 monad-bft 的精确实现,编译为 Wasm 并在您的浏览器中针对一个模拟框架 (mock-swarm) 运行。

​
常见概念

为了解释 MonadBFT,首先需要定义一些概念。我们将从许多 BFT 机制的共同概念开始:

​
拜占庭阈值

按照惯例,设有 n = 3f+1 个节点,其中 f 是拜占庭(故障)节点的最大数量。也就是说,2f+1(2/3)的节点是非拜占庭的。在下面的讨论中,我们将所有节点视为具有相等的质押权重;实际上,所有阈值都可以用质押权重表示,而不是节点数量。

​
超级多数

>2/3 的质押权重。

​
轮次 (Round)

协议按轮次(也称为视图)进行。无论是否成功提出块提案,轮次编号在协议的每一步都会增加 1。

​
领导者 (Leader)

每一轮都有一个领导者,有权提出块提案。领导者按照先前根据质押权重确定的时间表在每一轮轮换。

​
区块

一个区块由轮次编号、一个负载(有序的交易列表)和一个 QC 组成。区块建立在 父 区块之上,并包含一个证明该父区块的 QC。区块通过父子关系连接在一起,这就是为什么我们称之为区块链。

​
法定人数证书 (Quorum Certificate, QC)

验证者评估每个区块提案的有效性,并将他们的投票发送给下一个领导者。如果下一个领导者收到超级多数的 YES 投票,他们将这些投票汇总为对该区块提案的法定人数证书 (QC)。QC 是网络中 2/3 收到并对该区块提案投 YES 票的证明。 尽管这更多是实现细节,但值得注意的是,在 Monad 的 MonadBFT 实现中,验证者使用 BLS 签名进行签名,因为这些签名可以高效地聚合,使 QC 上的签名验证相对便宜。

​
线性通信

每一轮遵循扇出-扇入模式。领导者将其块提案发送给每个验证者(使用 RaptorCast 进行高效广播)。验证者评估块提案并将签名投票直接发送给下一个领导者。这种线性通信机制与依赖于全对全(二次方)通信的其他协议形成对比;它使共识集能够扩展。

​
MonadBFT 相对独特的概念

以下是 MonadBFT 相对独特的概念。我们将它们分开介绍以便于理解。 为简化起见,我们专注于 MonadBFT 的标准恢复。快速恢复优化在快速恢复章节中说明。

​
提案 (Proposal)

一个块提案(通常简称为 提案)由当前轮次编号、一个区块、一个可选的 TC 或 NEC,以及一个(由发出提案的领导者)对上述元素的签名组成。在简单情况下,可选字段为空,轮次编号与区块的轮次编号相同,这样提案基本上就是一个签名的区块。有时,未能获得支持的区块会被重新提议;在这种情况下,该区块仍然保留最初被提出时的轮次编号,但提案将带有重新提议时的轮次编号。

​
新鲜提案 (Fresh Proposal)

新鲜提案是包含一个新区块的提案,即一个未受先前失败提案影响的提案。 新鲜提案将满足以下条件之一:
  1. 轮次编号等于其 QC 的轮次编号加 1。这是常见情况,当领导者诚实且在线,并且网络没有任何异常延迟时。
  2. 带有一个标识 high QC 的 TC。当领导者从失败的轮次中恢复时会发生这种情况(快速恢复)。
  3. 带有一个 NEC。这种情况极其罕见,当领导者从更复杂的故障中恢复时会发生(标准恢复)。

​
重新提案 (Reproposal)

重新提案是包含来自先前新鲜提案的区块的提案,当前领导者试图恢复或最终确认该区块。重新提案的轮次编号将大于其 QC 的轮次编号加 1。 从故障中恢复的领导者是否必须重新提议一个先前的区块,由 TC 决定。如果 TC 包含 high tip(而不是 high QC),那么与 high tip 对应的区块必须被重新提议。重新提案是标准恢复的一部分。实际上,通过快速恢复,重新提案通常可以被跳过。

​
Tip

Tip 是一个减去了区块负载的提案。您可以将其视为提案的区块头加上一些额外的元数据,包括接收该提案时的轮次编号。 在 MonadBFT 中,每个验证者都会跟踪其最新的 tip,该 tip 在验证者对某个提案投票时会被更新。如果验证者对某个重新提案投票,则 tip 会被设置为原始提案,而不是其重新提案。

​
High Tip

给定一组 tip,high tip 就是轮次编号最高的 tip。如果有多个这样的 tip,则选择基于其中嵌入的最高 QC 构建的 tip。

​
超时消息 (Timeout Message)

超时消息是验证者在预期时间内没有收到来自被安排领导者的有效区块时产生的签名证明。超时消息证明了有效区块的缺失。 每个验证者将超时消息发送给所有其他验证者,采用全对全通信。 其他 BFT 协议中也使用超时消息。在 MonadBFT 中,超时消息包括发送方的 tip —— 关于其世界观的附加信息,这些信息将在 MonadBFT 中被用于从超时中优雅地恢复。 对于快速恢复,超时消息中包含验证者的最高 QC,如果该 QC 的视图与本地 tip 的视图相等或更高。

​
超时证书 (Timeout Certificate, TC)

当发生超时时,验证者开始发送和接收超时消息。每个验证者累积它收到的超时消息;如果它得到超级多数的此类消息,它就构建一个超时证书 (TC)。 TC 包括所有贡献超时消息的验证者的所有 tip 的信息。也计算 high tip(用于标准恢复)。在大多数情况下,快速恢复是可行的,TC 中包含 high QC 而不是 high tip。

​
无背书消息与无背书证书

在某些条件下,领导者会向其他验证者请求与某个 tip 对应的完整提案(区块)。如果验证者没有该提案,他们将回复一条签名的无背书消息证明这一点。 如果领导者在尝试恢复某个 tip 的提案时得到超级多数的无背书消息,他们可以产生一个无背书证书 —— 网络中超级多数没有该提案的证明。

​
由于 MonadBFT 产生的区块状态

由于 MonadBFT,区块可以处于三种状态之一:
  1. Proposed
  2. Voted
  3. Finalized
正如在区块状态中提到的,这是 Monad 中区块总共可以处于的四种状态中的三种。(第四种状态 Verified 是在 MonadBFT 之外作为异步执行的一部分实现的。) 下面,我们描述区块如何在这些状态之间推进。

​
乐观路径 (Happy Path)

乐观路径描述了一个区块从被提议到被最终确认的普通过程,没有任何超时或失败的轮次。

​
场景

为了描述乐观路径的流程,我们将遵循下图所示的场景。 当前是轮次K,被安排的领导者是 Alice。Bob 和 Charlie 是时间表中接下来的两位领导者。Alice 最后见过的区块是 N-1,所以她将提议区块 N。
MonadBFT 的进行如下。

​
轮次 K:Alice 的提案

  1. 提案: Alice,轮次 K 的指定领导者,选择一个负载,即从她的 mempool 中选择的一个交易列表。她构建区块 N,由该负载和来自先前提案的 QC 组成(不必担心这部分)。Alice 将由该区块组成的提案直接发送给所有其他验证者。
  2. 投票: 每个验证者检查 Alice 提案的有效性。如果提案有效,验证者直接将签名投票发送给 Bob,即轮次 K+1 的指定领导者,并将区块 N 标记为 Proposed。
  3. QC 形成:在获得关于 Alice 提案的超级多数投票后,Bob 将投票汇总为关于 Alice 提案的 QC。

​
轮次 K+1:Bob 的提案

  1. 提案: Bob 选择一个负载。Bob 将该负载与 Alice 提案的 QC 结合,产生一个新区块,他将其发送给所有其他验证者。
  2. 投票: 每个验证者检查 Bob 提案的有效性。如果提案有效,验证者直接将投票发送给 Charlie,即轮次 K+2 的指定领导者,并将区块 N 标记为 Voted(并将区块 N+1 标记为 Proposed)。 这也意味着该区块可以被 推测性最终确认。这种推测性最终确认只在非常特定的罕见条件下才会回滚,并且这些条件也会带来问责。稍后详述。
  3. QC 形成:在获得关于 Bob 提案的超级多数投票后,Charlie 将投票汇总为关于 Bob 提案的 QC。这个 QC 也可以看作是对 Alice 提案的 QC-squared,因为它是一个证明超级多数收到了关于 Alice 提案的 QC 的 QC。

​
轮次 K+2:Charlie 的提案

  1. Charlie 的提案: 与之前一样,Charlie 构建一个由新负载和 Bob 提案上的 QC 组成的区块。Charlie 将提案发送给每个人。
  2. 投票: 每个验证者检查 Charlie 提案的有效性。如果提案有效,验证者直接将投票发送给 David,即轮次 K+3 的指定领导者,并将区块 N 标记为 Finalized(并将区块 N+1 标记为 Voted,区块 N+2 标记为 Proposed)。
尽管我们将在此停止描述该序列,但共识机制会重复地继续。一旦每个验证者收到 David 的提案(其中包含关于 Charlie 提案的 QC,即关于 Bob 提案的 QC-squared),他们就可以将 Bob 的提案标记为 Finalized(并将 Charlie 的标记为 Voted)。以此类推。 这强调了 MonadBFT 的流水线化方面。每一轮,一个新的负载和一个关于先前提案的新 QC 被共享,允许父提案被推测性最终确认,祖父提案被完全最终确认。您可以在这里看到:

说明 MonadBFT 的流水线化(交错)性质。与前一张图相同,但缩小到包含多一轮。

​
悲观路径(故障处理)

悲观路径描述了异常情况:领导者未能发送有效提案,或 QC 构建者(下一个领导者)未能构建 QC。 理解悲观路径对于理解乐观路径的工作方式也至关重要!最终允许验证者在收到子提案后推测性最终确认提案,或在收到孙提案后最终确认提案的,是知道回退机制仍将保留原始提案。 在这里,我们将专注于标准恢复,这实际上是回退机制的回退。在大多数实际情况下,我们可以使用快速恢复,这大大加快了协议在故障发生后回到乐观路径的时间。 然而,为了让协议整体上实现抗尾端分叉性,即使在拜占庭故障的最坏情况下,我们也依赖于标准恢复,现在我们介绍它。

​
场景

与之前一样,为了描述悲观路径的流程,我们将遵循图中所示的场景。 同样地,假设当前是轮次 K,Alice 是被安排的领导者。Bob 和 Charlie 是时间表中接下来的两位领导者。Alice 最后见过区块 N-1,所以她将提议区块 N。 在我们的示例中,Alice 在轮次 K 发送了区块 N,但 Bob 在轮次 K+1 未能发送区块。这可能是因为他离线了,也可能是因为 Alice 发送了一个无效区块,或者没有足够多的人为它投票。

​
轮次 K:Alice 的提案

  1. 提案: Alice,轮次 K 的指定领导者,选择一个负载并构建由该负载和来自先前提案的 QC 组成的区块 N(同样,不必担心这部分)。 Alice 将提案直接发送给所有其他验证者。
  2. 投票: 每个验证者检查提案的有效性,如果有效,则直接将签名投票发送给 Bob,轮次 K+1 的指定领导者。每个验证者本地将 Alice 的提案标记为 Proposed。

​
期望的轮次 K+1:Bob 错过的时隙

  1. Bob 未能提议区块 N+1,因此所有投票都被吞掉,Alice 区块的 QC 没有产生。
  2. 每个人发送超时消息: 在超时窗口之后,每个验证者”意识到”轮次 K 失败了,因为 Alice 区块的 QC 未形成。因此,每个人向其他所有验证者发送关于区块 K 的超时消息。(注意这种通信是全对全的。)
  3. TC 组装:在获得超级多数超时消息后,包括 Bob 在内的每个验证者组装一个 TC,证明轮次 K(Alice 提议者,Bob QC 构建者)失败。在为 K 构建 TC 后,验证者将其轮次推进到 K+1。

​
由 TC 推进的轮次 K+1

TC 包含一个称为 high_tip 的计算值,该值(粗略地讲)是任何贡献超时消息的验证者见过的最新有效区块的区块头。您可以将 high_tip 视为签署 TC 所需的 2/3 质押权重范围内观察到的最大区块。 在这个具体示例中,high_tip 将是 Alice 区块的区块头。 根据 MonadBFT 的规则,下一个领导者有义务要么重新提议 TC 的 high_tip 中引用的区块(即 Alice 的区块),要么证明该区块不受支持。(我们将在下面更详细地讨论这一点。) 由于我们现在在轮次 K+1,下一个领导者是 Bob。(您可能会觉得这具有讽刺意味,但这是协议无法区分 Bob 离线的可能性和 Alice 发送了无效区块或没有足够多的人对 Alice 的区块投票的可能性这一事实的必然结果。在后两种情况的任何一种下,跳过 Bob 都是不公平的。)
  1. (可选)从其他验证者请求 Alice 的区块:Bob 需要重新提议 Alice 的区块。然而,high_tip 只是一个区块头 —— 不是完整的区块主体 —— 所以如果 Bob 没有 Alice 的区块,他可以从其他验证者请求完整版本(通过 blocksync)。

​
重新提案情况(Bob 重新提议 Alice 的区块)

  1. 重新提案:如果 Bob 有 Alice 的区块(要么是因为在她最初提议时就收到了,要么是通过 blocksync),那么他将其连同证明重新提案合理的 TC 一起提议。
  2. 投票: 每个验证者对 Bob 重新提案的有效性进行投票。如果重新提案有效,验证者将其投票发送给下一个领导者 Charlie。
  3. QC 形成: Charlie 从投票中组装一个 QC。
  4. Charlie 的提案: Charlie 在轮次 K+2 构建一个由新负载和来自轮次 K+1 的重新提案 QC 组成的区块,并将该区块发送给每个人。此时 Alice 的区块对任何收到 Charlie 区块的人来说都变为 Voted。每个人将其轮次推进到 K+2,协议返回到乐观路径。

​
新鲜提案情况(Bob 证明 Alice 的区块不受支持)

  1. 对 Bob 区块的无背书:回想一下,在第 6 步中,Bob 被允许向其他验证者轮询 Alice 的区块。当验证者被轮询时,如果他们也没有,他们可以向 Bob 发送一条签名的无背书消息,证明 没有 见过 Alice 的区块。如果超级多数验证者签署了无背书消息,那么 Bob 可以组装一个无背书证书 (NEC)。
  2. Bob 的新鲜提案:根据 MonadBFT 的规则,Bob 可以跳过重新提议 Alice 的区块,而是在同一区块高度 N 上发起新区块的新鲜提案,前提是他还可以提供 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 中,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。在其他区块链中,无意中允许区块被重新挖矿已经造成了巨大影响。 MonadBFT 的无尾端分叉性质的关键在于对错过时隙情况的处理。直观地说,在 MonadBFT 中,TC 携带足够的信息,即使 Bob 吞掉了所有关于它的投票,也能向前传播关于 Alice 区块存在的知识。 当轮到 Bob 提议时,他有义务重新提议 Alice 的区块(基于 TC,其中包括 high_tip,即 Alice 区块的有效区块头),除非他能获得超级多数(2f+1)证明 没有 见过 Alice 的区块。超级多数签署 NEC 的事实是关键:即使 f 个节点是拜占庭的,仍然有 f+1 个非拜占庭节点证明 没有 见过 Alice 的区块,这保证了 Alice 的区块 不应该 达到法定人数,因为法定人数需要 2f+1 个投票,而至少有 f+1 个非拜占庭的 NO 投票。 MonadBFT 论文提供了对协议更严格的定义,以及尾端分叉不会发生的形式化证明。

​
推测性最终确认

MonadBFT 的另一个极佳特性是单时隙推测性最终确认。 为了解释这一点,首先要提醒的是,区块的状态始终是从特定观察者的角度而言的。例如,如果您收到了某个区块的 QC,那么您可以将该区块移到 Voted 状态,但如果您的朋友尚未收到该 QC,那么她仍会认为该区块处于 Proposed 状态。 构建分布式共识机制的挑战在于定义规则,让节点能够在收到消息时单独更新其状态机,即使假设最坏情况,即假设它们可能是唯一收到该消息的节点。

​
收到 Alice 的提案后

假设您是 Valerie,网络中的一个验证者。您收到了 Alice 的提案;您对其进行有效性检查,它们通过了,所以您将 Alice 的提案标记为 Proposed。 请注意,您不知道是否有其他人收到了这个提案,Alice 可能在耍花招,只将提案发送给您(或只发送给非常少数的节点),试图让您与其他所有人分歧。

​
收到 Bob 的提案后

现在假设您收到了 Bob 的提案,其中携带了 Alice 提案的 QC。您对 Bob 的提案进行有效性检查,它们通过了,所以您将 Alice 的提案标记为 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 论文提供了这个论点的更严格版本。但总而言之,本地观察到 QC(将提案移到 Voted)是提案将最终确认的一个非常强的指标,因为它不会最终确认的唯一方式是 Alice 等价签名,Bob 错过了他的时隙,近 1/3 的网络是拜占庭的,并且我们对最终填充 TC 的节点相当不走运。

​
快速恢复

自 2025 年初发布原始 MonadBFT 论文以来,Category Labs 分析了协议的行为,并设计、评估和实现了多项改进。 协议的更改使得在最常见的故障场景中能够快速恢复。 这篇博客文章很好地介绍了快速恢复的工作原理。总而言之:
  • 验证者现在不仅将投票发送给下一个视图的领导者,还发送给当前视图的领导者。这给了每个领导者一个机会收集自己提案的投票以形成 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机制以应对更复杂的拜占庭故障。然而,通过这些改进,我们相信大多数故障现在都可以通过新的快速恢复路径顺利处理。

​
参考文献