在第1部分，我们研究了经典PBFT共识的工作原理以及早期版本的HotStuff是如何运作的。我们还研究了MonadBFT是如何解决HotStuff的尾部分叉问题的，这是一个在流水线系统中，有效区块有时会被落下的问题。
这个尾随分叉问题造成了两个大问题：1）它搞乱了诚实块构建者的奖励，2）可能会导致网络停滞。
MonadBFT引入了Reproposal规则和No-Endorsement投票机制，以消除尾分叉问题，确保来自诚实提议者的任何正确批准的区块都将始终进入链中。
在第2部分中，我们将探讨MonadBFT的另外两个特征，即1）投机性终局和2）乐观的响应能力。我们还将探讨MonadBFT对开发人员的影响。
一轮投机性最终性
除了尾叉抗拒外，MonadBFT的另一个重要特性是在单一轮内的猜测性最终性。
在实际操作中，这意味着客户和用户可以在区块获得超过半数的投票后立即收到交易确认，甚至在下一轮完成之前。
回想一下，在协议基线HotStuff中，一个块通常不被认为是最终的(不可逆)直到它经历了至少两个阶段(例如Fast-Hotstuff和Diem-BFT)：第一阶段获得法定证书(用≥2f+1票锁定块)，第二阶段下一位领导者在此基础上构建并承诺该块。
为了确保安全性，需要进行两阶段提交：一旦足够多的诚实节点锁定了一个区块，就不会有冲突的区块能够获得法定人数，下一轮的提交会使其变为永久。因此，通常情况下，客户端可能需要等待下一个区块或下一轮产生之前，才能确定上一笔交易是否最终完成。
MonadBFT基本上允许交易在经过一轮投票后被认为足够最终（安全执行）。这称为推测性最终性。
当领导者提出一个区块并且验证者投票形成一个QC来确认该区块时，该区块现在处于已投票状态（被法定人数锁定）。在MonadBFT中，验证者将在形成QC后立即执行该区块的交易，甚至向客户端发送初步确认，表明该区块已（推测性地）被接受。这就像在说：“我们有绝对多数人同意这个区块。除非发生非常意外的事情，否则请将此区块视为已确认。”
这种即时确认是乐观的。区块尚未在账本中提交。当下一个提案到来并最终确定（QC-on QC）时，区块将被提交，但在正常情况下，没有任何事情会撤销它。唯一可以撤销具有推测性执行的区块的情况是如果领导者出现了矛盾（即在同一高度提出了两个不同的区块以分割投票）。
您可以将投机性最终性视为尾部分叉抵抗的一个很好的副产品。尾部分叉抵抗可保证即使下一个领导者崩溃，当前提案也不会被放弃（这要归功于再提案和NEC规则）。因此，只有在原始提案者出现二义性（经过证明是恶意的双签名故障）时，投机执行的区块才会被丢弃：1）可以通过冲突的QCs检测，2）可被惩罚，3）极其罕见。
在以前的协议中，他们并没有保证下一个领导者会重新提出上一个区块，因此尾部分叉是可能的，打破了推测的假设。
乐观的响应
在大多数共识协议中，每轮后都会有一个内置的等待时间，就像一个缓冲期或超时。这是为了确保所有消息都已到达，然后再继续前进。这是一种保护机制，旨在处理最坏的情况，比如当领导者崩溃或根本不发送任何消息时。
这些超时通常过于保守。如果网络正常运行且所有验证者行为正确，则固定等待就变得不必要。区块本可以更快被最终确认，但协议为防万一而减缓了速度。
MonadBFT引入了乐观的响应性，这意味着协议可以立即基于网络消息进行推进，而不总是依赖固定的定时器。这里的设计原则可以概括为“能快时快，必须耐心时耐心”。
MonadBFT被设计成这样，即使在正常情况下，甚至在从故障中恢复时，如果没有必要，它也不会暂停预定的超时。
- 在幸福路径（意味着我们有一个诚实的领导者）：在提议或投票中没有内置的延迟。一旦领导者轮到，它就提出一个区块。一旦验证者收到一个有效的提议，他们就投票。在领导者（或者更确切地说，下一个领导者，因为投票会发送到流水线式HotStuff中的下一个提议者）收集到2f+1票时，QC形成并可以传播。在乐观响应设计中，这将立即触发下一个阶段。
实际上，这意味着如果节点之间的网络延迟为100毫秒，共识可能仅需几百毫秒就能完成一轮（加上计算和聚合开销）。
如果没有必要，它不会等待完整的一秒钟“时隙时间”。这与以太坊主网形成对比，后者遵循时隙和纪元模型在以太坊上，区块生产固定在12秒间隔。即使所有人都准备好了，协议也会等待。
MonadBFT的方法消除了不必要的延迟。它保留了流水线式的HotStuff结构，但在正常情况下取消了刚性的“你必须等待Δ秒”的规则。这意味着它可以在响应性方面胜过时间限制系统，而不会牺牲安全性。
- 在不幸的路径（领导者失败）中：在许多共识协议中，当领导者未能提出一个区块时，其他节点只有在经过超时Δ之后才意识到这一点。例如，如果Δ为1秒，那么这段时间基本上就浪费了。MonadBFT处理方式不同。当验证者检测到缺失的提案时，他们立即广播超时消息（TC或超时证书）。一旦看到2f+1个这样的超时，下一个领导者接管。进入新视图是由基于法定人数的证据触发的，而不是由时钟触发。
与hotstuff-family共识的比较
MonadBFT 建立在 HotStuff 系列共识协议的血统之上，但通过实现理想的属性组合而脱颖而出，而以前的设计无法在不进行权衡的情况下完全集成这些属性。早期的协议通常针对某些维度（如流水线吞吐量或线性通信）进行了优化，但不得不牺牲其他维度。MonadBFT 独特地将线性消息传递复杂性、流水线提交、强大的尾部分叉阻力、无固定延迟的即时响应和高效的恢复机制相结合，同时保持快速确定性和高活跃性保证。下表总结了 MonadBFT 在这些关键维度上与其他轮换领导者 BFT 协议的比较：
开发人员和用户会怎么样？
对于开发人员来说，MonadBFT 意味着两件事：
- 更简单的最终性模型：使用MonadBFT，您可以将具有QC（超过半数投票）的区块视为在大多数情况下已经最终确定，因为协议将最终确定它，或者如果不是，则会削减。开发人员可以安全地依靠1个区块确认并具有较高的信心。
- 改进的应用程序用户体验：如果您正在构建高吞吐量的应用程序（交易所、游戏等），MonadBFT的低延迟和抗分叉特性将带来更流畅的用户体验。用户几乎可以立即看到他们的操作得到确认，不常见混乱的重组或回滚。这让您可以设计假定最终性和快速更新的应用程序。
- 确定性行为：MonadBFT的更严格规则（如重新提议要求）减少了区块包含中的非确定性。减少了“边缘情况”场景，例如一个区块可能会根据微妙的时机而被包含或跳过，例如投票或超时先到达领导者。MonadBFT用明确的规则和可验证的证据取代了这种对时机敏感的模糊性。这使得更容易推断协议的正确性并对其进行测试。它还为识别故障节点提供了明确依据（例如，如果有人未能重新提议或提出冲突的区块，则知道他们违反了协议）。
- 可扩展的余地：如果您是一个关心扩展性的开发者，MonadBFT可以让您在遇到瓶颈之前有更多的余地。您可以更轻松地增加区块大小或验证者数量，而不像二次协议那样不舒服。而像消除编码块传播这样的功能意味着您可以通过网络传输大量数据，而不会使个别节点超负荷。这使得可以追求更高的吞吐量，从而为更雄心勃勃的链上应用开辟了设计空间。
对于最终用户：一个普通用户可能不了解我们在这里讨论的任何内容，但他们会感受到它的影响。在Monad链的支撑下，用户可以期待以下所有良好的特性，而不会牺牲去中心化和抗审查性能。
- 更快的确认：交易（如发送代币、交换资产、铸造NFT、执行交易）将会非常快速确认。
- 更少的惊喜：链状态的一致性更高，因为诸如尾部分叉（本质上是重新组织）之类的东西被消除了
- 公平和透明性：共识方面的改进间接意味着链的运行更加公平。没有单个验证者可以轻易审查交易或在区块之间进行排序游戏。
结论
简而言之，MonadBFT在流水线式HotStuff共识的基础上引入了四项核心创新：
尾部分叉抵抗力：MonadBFT是第一个流水线式BFT协议，可消除尾部分叉攻击。它通过要求下一位领导者在前任领导者失败时重新提议最后投票的区块，或者以无背书证书（NEC）作为证明，表明该区块缺乏支持来实现这一点。这确保不会放弃超多数背书的区块，保护诚实领导者的奖励，并防止恶意重组和跨区块MEV提取。
一轮推测性最终性：验证者可以在一轮通信后确认一个区块（一个领导者提案和投票），为客户提供即时的包含确认。这种推测性确认只有在领导者发生否认的情况下才会撤销（这种行为可以被证明并受到惩罚），在实践中这是一个安全的假设。
乐观响应：该协议以网络速度运行，没有固有延迟。领导者一旦收到必要的投票就会推进共识，并且在观察到超时的法定人数后，视图更改会立即发生，而不是等待固定的超时间隔。这种乐观响应设计最大限度地减少等待时间，最大化吞吐量，同时在异步性和故障发生时稳健地处理。
线性通信：在快乐路径上（意味着领导者诚实），消息和认证复杂度与验证者数量呈线性关系。MonadBFT保留了HotStuff的高效通信模式，使用聚合签名和简单的领导者到验证者的广播，这使得协议能够在不影响性能的情况下扩展到数百个验证者。
免责声明：
- 此文章转载自[michael_lwy]。所有版权属于原作者[michael_lwy]. 如果对此转载有异议，请联系Gate 学习团队会立即处理。
- 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
- Gate Learn团队负责将文章翻译成其他语言。 未经说明，复制、分发或剽窃翻译后的文章均被禁止。
