MonadBFT 解析（下）：对开发者和用户意味着什么

在第一部分中，我们研究了经典 PBFT（实用拜占庭容错）共识的工作原理以及早期版本的 HotStuff 运行方式。我们还了解了 MonadBFT 如何解决 HotStuff 的尾部分叉问题，即在流水线系统中有效区块有时会被丢弃的问题。

这种尾叉问题造成两个主要问题：1） 它扰乱了诚实区块构建者的奖励，2） 可能会导致网络停滞。

MonadBFT 引入了重新提议规则和无背书投票投票机制来消除尾部分叉问题，确保任何来自诚实提议者的经适当批准的区块都能进入链中。

在第二部分中，我们将探讨 MonadBFT 的另外两个特性：1） 投机最终性和 2） 乐观响应性。我们还将探讨 MonadBFT 对开发者的影响。

单轮投机最终性​

除了抵抗尾部分叉外，MonadBFT 的另一个主要特性是单轮投机最终性。

在实际应用中，这意味着客户端和用户可以在区块获得绝大多数投票后立即收到交易确认，甚至在下一轮完成之前。

回想一下，在基线 HotStuff 协议中，一个区块通常要经过至少两个阶段（如 Fast-Hotstuff 和 Diem-BFT）才被视为最终确定（不可逆转）：一个阶段获得法定人数证书（QC）（以 ≥2f+1 票锁定区块），第二个阶段是下一位领导者基于该法定人数证书（QC）构建并提交区块。

这种两阶段提交是确保安全性所必需的：一旦有足够多的诚实节点锁定了一个区块，与之冲突的区块无法获得法定人数，而下一轮的提交将使其永久化。因此，客户端通常可能需要等待下一个区块或下一轮产生后，才能知道上一个交易是否最终确定。

MonadBFT 基本上允许交易只经过一轮投票就被认为最终足够（可以安全操作）。这就是所谓的投机最终性。

当领导者提出一个区块，验证者投票形成该区块的 QC 时，该区块就处于已投票状态（已被法定人数锁定）。在 MonadBFT 中，验证者一旦形成 QC，就会立即执行该区块的交易，甚至会向客户端发送初步确认，表明该区块被（投机性地）接受。这就像在说“我们有绝大多数人同意这个区块。除非发生非常意外的情况，否则可以认为这个区块已确认。”

这种即时确认是乐观的。区块尚未在账本中提交。这将在下一个提议出现并最确认它（QC-on QC），但在正常情况下，没有什么会撤销它。唯一能撤销投机性执行区块的情况是领导者发生等价攻击（即在同一高度提出两个不同的区块来分散投票）。

你可以把投机最终性看作是抵抗尾部分叉的一个很好的副产品。 抵抗尾部分叉保证即使下一个领导者崩溃，当前的提议也不会被丢弃（这归功于重新提议和 NEC 规则）。投机性执行区块被丢弃的唯一情况是原始提议者发生等价攻击（可证明恶意的双签错误），而这种情况：1） 可通过冲突 QC 检测到；2） 可惩罚；3） 极为罕见。

在之前的协议中，它们不保证下一个领导者会重新提出上一个区块，因此尾部分叉是可能的，从而打破了投机假设。

乐观响应性​

在大多数共识协议中，每轮之后都会有一个内置的等待，比如缓冲期或超时。这是为了确保所有消息在继续推进之前都已到达。这是一种保护机制，旨在处理最坏的情况，比如领导者崩溃或根本没发送任何信息。

这些超时通常过于保守。如果网络正常运行且所有验证者行为正确，那么固定的等待就会成为不必要的开销。区块本可以更快完成，但协议却为了以防万一而延迟了。

MonadBFT 引入了乐观响应性，这意味着协议可以基于网络信息立即前进，而不是总依赖固定的计时器。这里的设计原则可以概括为 “能快则快，必须耐心时才耐心"”。

MonadBFT 的设计使其在正常情况下，甚至在故障恢复时，如果没有必要，它不会暂停等待预定的超时。

• 在快乐路径上（意味着我们有一个诚实的领导者）： 在提议或投票中没有内置延迟。一旦轮到领导者，它就会提出一个区块。验证者一收到有效提议，就会立即投票。当领导者（或者更确切地说，下一个领导者，因为在流水线 HotStuff 中，投票会发送给下一个提议者）收集到 2f+1 票时，QC 形成，并可以传播。在乐观响应性设计中，这会立即触发下一阶段。

在实践中，这意味着如果节点之间的网络延迟是 100 毫秒，那么共识可能只需几百毫秒就能完成一轮（加上计算和聚合开销）。

如果不需要，它不会等待，例如，整整一秒的"时隙时间"。这与以太坊主网采用的 slot-and-epoch model 不同。在以太坊上，区块生产的时间间隔固定为 12 秒。即使每个人都提前准备好了，协议也会等待。

MonadBFT 的方法消除了不必要的延迟。它保留了流水线 HotStuff 结构，但移除了正常情况下 “必须等待 Δ 秒 ”的硬性规定。这意味着它可以在不牺牲安全性的前提下，在在响应性方面可以优于时间约束系统。

• 在不快乐路径上（领导者失败）： 在许多共识协议中，当领导者未能提出区块时，其他节点只有在超时 Δ 之后才会意识到这一点。例如，如果 Δ 为 1 秒，那么这段时间基本上就浪费了。MonadBFT 的处理方式与此不同。当验证者检测到提议丢失时，它们会立即广播超时消息（TC 或超时证书）。一旦出现 2f+1 次超时，下一个领导者就会接管。向新观点的过渡是由基于法定人数的证据触发的，而不是由时钟触发的。

与 hotstuff-family 共识的比较​

MonadBFT 建立在 HotStuff 系列共识协议的基础之上，但又通过实现一系列理想特性的组合而脱颖而出。 早期协议通常针对某些维度进行优化，如流水线吞吐量或线性通信，但不得不牺牲其他方面。MonadBFT 独一无二地将线性消息复杂性、流水线提交、强大的尾部分叉抵抗、无固定延迟的即时响应性和高效恢复机制结合在一起，同时还保留了快速最终确定和高可用性保证。下表总结了 MonadBFT 与其他轮换领导 BFT 协议在这些关键维度上比较：

这对开发者和用户意味着什么？​

对于开发者，MonadBFT 意味着几点：

• 更简单的最终确定性模型： 使用 MonadBFT，您可以将具有QC（绝大多数投票）的区块视为实际上已最终确定，因为协议将最终确定它或进行惩罚。开发者可以高度自信地安全操作 1 区块确认。
• 改善应用的用户体验： 如果您正在构建一个高吞吐量的应用程序（交易所、游戏等），MonadBFT 的低延迟和抵抗分叉特性将转化为更流畅的用户体验。用户几乎可以立即看到他们的操作得到确认，而且不会经常遇到令人困惑的重组或回滚。这样，您就可以设计出具有最终确定性和快速更新的应用。
• 确定性行为： MonadBFT 更严格的规则（如重新提议要求）减少了区块包含的不确定性。由于投票或超时是否先到达领导者等微妙的时间因素，区块被包含或跳过的 “边缘情况”更少。MonadBFT 用明确的规则和可验证的证据替代了这种对时间敏感的模糊性。这使得推理协议的正确性和测试变得更加容易。它还为识别故障节点提供了明确的依据（例如，如果有人未能重新提议或提议了冲突区块，您就知道他们违反了协议）。
• 可扩展性空间： 如果您是一个关注扩展性的开发者，MonadBFT 在遇到瓶颈之前为您提供更多空间。与二次协议相比，您可以更轻松地增加区块大小或验证者数量。而且像擦除编码区块传播等功能意味着您可以通过网络推送大量数据，而不会过度消耗单个节点。这使得瞄准更高吞吐量成为可能，为更雄心勃勃的链上应用打开设计空间。

针对最终用户： 普通用户不会了解我们在这里讨论的任何内容，但他们会感受到其影响。有了 MonadBFT 作为 Monad 链的基础，用户就可以在不牺牲去中心化和抵制审查的前提下，期待以下所有好的特性。

• 更快的确认： 交易（如发送代币、交换资产、铸造 NFT、执行交易）将快速得到确认。
• 减少意外： 链状态的一致性更高，因为像尾部分叉这类本质上属于重组的东西被消除了。
• 公平和透明： 共识的改善间接意味着链的运行更加公平。任何单个验证者都不能轻易审查交易或在区块间的排序上做手脚。

结论​

总结一下，MonadBFT 在流水线 HotStuff 风格共识的基础上引入了四项核心创新：

抵抗尾部分叉： MonadBFT 是首个消除尾部分叉攻击的流水线 BFT 协议。它通过下一任领导者在上一任领导者失败的情况下重新提出上次投票的区块，或出示无背书证书（NEC），证明该区块缺乏支持，从而实现这一目标。这就保证了任何获得绝大多数支持的区块都不会被丢弃，从而保护诚实领导者的奖励，并防止恶意重组和跨区块 MEV 提取。

单轮投机最终性： 验证者可以在单轮通信（一个领导者提议和投票）后确认区块，为客户端提供即时的包含保证。这种投机性确认只有在领导者等价攻击（可以被证明和惩罚的行为）时才会恢复，使其在实践中成为安全假设。

乐观响应性： 协议以网络速度运行，无固有延迟。领导者在收到必要投票后立即推进共识，视图变更在观察到法定人数的超时后立即发生，而不是等待固定的超时间隔。这种乐观响应性设计最小化等待时间并最大化吞吐量，同时在发生异步和故障时仍然能够稳健处理。

线性通信： 在快乐路径上（即领导者是诚实的），消息和验证的复杂性与验证者数量呈线性关系。MonadBFT 保留了 HotStuff 的高效通信模式，使用聚合签名和简单的领导者对验证者广播，使协议能够扩展到数百个验证者而不会出现性能瓶颈。