Monad 共识客户端现已开源（链接如下）。 这是 @category_xyz 团队数千小时努力的结果。 请享用

MonadBFT的突破总结 昨天，Category Labs发布了MonadBFT论文，描述了将在主网上为Monad提供动力的共识机制。 MonadBFT是共识研究中的一个重要发展，因为这是第一次Pipelined HotStuff对尾分叉具有抵抗力。 尾分叉发生在一个错过的插槽导致之前的提案被丢弃并重新挖掘时。这是之前Pipelined HotStuff公式中的一个严重问题，因为它开启了不稳定共识的多区块MEV攻击。 缓解这个问题是一个巨大的进步，因为它让我们可以享受Pipelined HotStuff的所有好处——频繁的区块、低延迟、大型验证者集——同时避免最大的缺点。 MonadBFT还为最终性提供了巨大的升级。它具有单插槽（500毫秒）投机性最终性和双插槽（1秒）硬最终性。 “投机性最终性”意味着“只有在大多数验证者双签的情况下才会撤销的最终性”。在大多数区块链系统中，双签是一个重大违规行为，通常会被削减处罚；双签的惩罚越大，您可以将“投机性最终性”视为最终性的程度越接近。 单插槽投机性最终性对于高性能应用程序来说是一个巨大的解锁，因为它可以在接收到下一个区块后立即自信地显示世界的更新状态。 这些特性使MonadBFT在共识方面取得了巨大的进步，并且是Monad中其他复合改进的有力补充，包括异步执行、乐观并行执行和MonadDb。 本文的其余部分概述了HotStuff的连续改进如何相互构建，以解释MonadBFT解决的问题。 总结： 1. HotStuff为我们提供了线性通信复杂性，使我们可以拥有大型验证者集，但效率不高 2. Pipelined HotStuff通过在每个插槽提议区块为我们提供效率和低延迟，但存在尾分叉问题 3. MonadBFT为我们提供了尾分叉抵抗力和单插槽投机性最终性 --- HotStuff：线性通信复杂性支持大节点数量 HotStuff算法在多轮通信过程中完成，通常采取“发散，汇聚”的通信形式，直接从领导者到验证者再回到领导者。 每轮开始时，领导者直接向其他验证者发送消息，验证者每人发送回一条签名消息，证明已收到消息。 只要三分之二的验证者发送回证明，每轮结束时，领导者将签名证明聚合成一个Quorum Certificate（QC），作为超级多数证明。 HotStuff算法有多轮这样的通信。 - 领导者的第一条消息是区块提案 - 第二条消息是该区块提案的QC - 第三条消息是关于之前QC的QC（即QC-on-QC） - 依此类推 如果在最终性之前的任何时间中断程序，区块将无法最终化并被丢弃；该区块的交易将必须在下一个区块中重新包含。 原始HotStuff协议没有流水线，在最终性之前有3轮通信；每轮由同一验证者担任领导者角色。 --- Pipelined HotStuff：每个插槽的新区块提高效率 流水线是我们在完成两批洗衣时直观地进行的操作。与其等待第1批完成整个周期后再开始第2批，在流水线中，我们将第1批放入烘干机的同时将第2批放入洗衣机。 您可以将原始HotStuff视为那种天真的洗衣方法（在第1批完全完成之前不要开始第2批），而Pipelined HotStuff则是以分阶段方式推进多个洗衣批次的直观行为。 在Pipelined HotStuff中，我们错开提案，使得每轮都有一个新区块提议，新区块搭载在携带前一个区块QC的消息之上。 区块提案在多轮过程中朝着最终性前进。 流水线的好处是显著的。流水线提高了区块提案的密度，因为每个插槽都有区块提案，这提高了吞吐量并降低了最终性时间。 然而，流水线有一个主要缺点，最好用一个例子来说明。假设区块N、N+1和N+2的领导者分别是Alice、Bob和Charlie。 如果Bob错过了他的插槽，那么Alice的提案也将无效，因为Bob的消息同时携带了他的提案和Alice提案的QC。 当这种情况发生时，Charlie最终被要求生成一个区块，就好像Alice的提案从未存在过一样。 我们将这种行为称为“尾分叉”，可以被视为深度为1的小型重组。 尾分叉的可能性具有重大影响，因为错过的插槽不一定是偶然的。 如果有机会通过重新挖掘Alice的区块来重新排序或省略某些交易来提取价值，那么Bob和Charlie可以串通让Bob故意错过他的插槽，从而为Charlie创造重新挖掘Alice区块的机会。 这一直是Pipelined HotStuff协议（其中一些已在主网上）的一个显著缺点。 --- MonadBFT改变了这一点 MonadBFT是第一个在启用流水线的同时使算法具有尾分叉抵抗力的协议。 这种尾分叉抵抗力来自Bob错过插槽时的回退程序，使验证者能够拼凑出他们对Alice提案及其在验证者集内共识水平的集体知识。 特别是，在MonadBFT下，如果Bob错过了他的插槽，那么回退程序让验证者通过签名证明相互沟通，说明他们是否看到了Alice的区块。 如果超级多数证明了Alice的区块，那么Charlie被迫重新提议Alice的区块。如果Charlie希望提议一个不同的区块，那么他必须提供大多数验证者的签名证明，证明他们没有及时看到Alice的区块。 在典型情况下，Charlie重新提议Alice的区块，然后他可以在下一轮提议他的区块。 结果是两个重要特性：尾分叉抵抗力和投机性单插槽最终性。我们已经讨论过尾分叉抵抗力，但让我们了解对最终性的影响。 如前所述，假设区块N、N+1和N+2的领导者分别是Alice、Bob和Charlie。 在Pipelined 2-Phase HotStuff下——即在MonadBFT之前——作为验证者（或完整节点），您无法在看到Charlie的区块提案之前最终化Alice的区块提案。为什么？因为如果您在看到Bob的提案时立即最终化，Bob可能会通过仅将他的提案转发给您来捉弄您，并且他实际上计划未能将他的提案发送给其他人，从而错过他的插槽。 但在MonadBFT中，一旦您看到Bob的提案，您可以“投机性”地最终化Alice的提案，因为Bob的提案包括Alice提案的QC，这是2/3网络证明Alice提案的证明。 即使Bob通过仅将他的提案转发给您来捉弄您，并最终错过他的插槽，您知道网络的超级多数看到了Alice的提案，并且当他们参与回退程序时，将再次签署Alice的提案。 Alice的区块不会被最终化的唯一方法是验证者出现双签并签署声明他们没有看到Alice的消息。这种故障很容易证明——我们有他们签署的冲突消息。如果双签的惩罚是巨大的——而且应该是——这种“投机性”最终性实际上并不那么投机。 --- 要点 MonadBFT是共识的一个非常令人兴奋的发展，是Monad中其他复合改进的有力补充，包括异步执行、乐观并行执行和MonadDb。 祝贺@MohammadMJalal1和@KushalBabel取得这一重大突破。 MonadBFT将很快在Monad Testnet上实施，目前实现了Pipelined 2-Phase HotStuff。 欲了解更多信息，请参阅下一条推文中的链接博客文章和论文。

请阅读@category_xyz发布的这篇超棒的博客文章，内容关于RaptorCast——在保持容错能力的同时，实现高效广播大区块，并且还能最大限度地减少带宽需求。 你会学到很多！