Minimmit：简单快速的共识

Minimmit 1 是 Commonware 最近提出的区块链共识算法。它属于一种新的共识协议，该协议要求超过 80% 的参与者是诚实的（而不是像传统异步 BFT 协议中的 2/3）。作为回报，你将获得一个更低延迟的协议，该协议仅需一轮投票即可达成共识（这被称为 2 轮，因为领导者的区块提议算作第一轮）。

我喜欢它的一点是，它感觉像是一种专为区块链协议设计的共识算法：带有链式提议的领导者轮换被集成到协议中，而不是事后才附加的。这实现了一种优美的简洁性，比许多传统的 BFT 算法更简洁。在初次接触 BFT 文献时，最难理解的事情之一就是对 justification 和 finalization 的划分。在领导者失败的情况下，完整的领导者轮换通常非常复杂，并且在论文中描述不完整，在实现中也存在 bug。在 Minimmit 中，它感觉更自然（假设你来自区块链的背景）。

关于本文的快速说明

我在此的目标主要是对 Minimmit 的工作原理以及为什么需要 80% 的多数做出直观的解释。无论我写 2/3 多数还是 80% 多数，都应理解为需要额外的一票，因此 3 票中的 2 票不足以满足 2/3 多数，但 4 票中的 3 票和 10 票中的 7 票则足够。

为什么需要 80% 多数的直觉解释

如果你想通过单轮投票来 finalization，则需要 80% 的节点是诚实的：正式地，Minimmit 使用 $n \geq 5f+1$，其中 $n$ 是节点总数，$f$ 是容忍的拜占庭故障数，即可以完全恶意行为的节点数。这意味着严格超过 80% 的节点需要是诚实的。快速拜占庭共识的一般紧下界实际上是 $n \geq 5f-1$ 2，当提议者是接受者的子集时，该下界适用。但是，FaB Paxos 3 确定了 $n \geq 5f+1$ 对于提议者和接受者是不同集合的特定类型的协议是必要的。有关区块链上下文中最近的处理，请参见 Minimmit 1。

理解为什么这是必要的，一个好方法是理解领导者（即区块提议者）可能是拜占庭式的，并且他们可以做的一件事是同时提出几个区块，因此诚实的节点在要投票的内容上存在分歧。我们想要避免的是领导者能够将协议置于任何不良状态；最坏的情况是 finalization 两个不兼容的区块（不在同一链中的区块），但是我们也不能允许他们将协议置于无法恢复的状态（即协议无法在没有人工干预的情况下自动恢复的状态）。

这是为什么 2/3 多数无法进行一轮 finalization 的直觉解释。假设如果一个区块获得了 2/3 的选票，我们就 finalization 该区块。让我们从简单的部分开始：一个诚实的提议者只提出一个区块。所有诚实的节点都会为此投票。在部分同步网络中，所有选票最终都会到达所有诚实的参与者处，因此他们都会看到 2/3 的人投票赞成该区块。到目前为止，一切都很好。

但是现在我们必须考虑一个恶意提议者。他们可以做的一件事是不提出区块。协议需要能够检测到这一点，因此各方必须能够为空槽投票（在 Minimmit 中，这称为 nullify，因此我从现在开始将其称为 nullifying）。如果 2/3 的节点投票 nullify 区块，我们可以继续。

但不幸的是，领导者可以做的比仅仅不提出区块更糟糕：他们也可以同时提出两个不同的区块。现在，我们将面临这样一种情况：大约一半的诚实节点投票赞成每个提案。此外，我们必须记住，恶意节点可以投票两次，或者根本不投票，甚至可以等到以后再看到诚实节点在做什么之后再决定他们的行动。在这里，他们可以暂时将一些选票借给选票较少的提案，以使其看起来拥有多数选票，例如： 如果协议使用票数更多的选项来继续链，则意味着下一轮是在不健全的基础模块上开始的，因为恶意节点将有权 finalization 另一个选项。设计的协议面临着一个不可能的选择：

• 在提案达到 2/3 的选票之前，永远不要继续。在这种情况下，恶意提议者可以阻止该链
• 继续选择获得最多选票的提案。在这种情况下，恶意节点可能能够通过其剩余的选票或通过模棱两可的方式 finalization 不同的提案

这就是传统 BFT 算法通过 justification 解决的难题。第一轮投票是对一个区块进行 justification（这巩固了它是由一个非模棱两可的提议者正确提出的）。当一个区块已被 justification（即，当 f+1 个正确的节点及时看到了第一轮投票的 quorum）时，诚实的节点不能在后续视图中投票支持像 PBFT 4 这样的不兼容区块。但这增加了一个额外的轮次，这正是我们想要避免的。

这就是为什么我们不能在一轮中以 2/3 多数 finalization 的直观解释。

为什么它适用于 80% 多数：

让我们更改一下，要求大于 80% (4/5) 的多数才能 finalization。和以前一样，我们不必担心存在诚实提议者的情况。

相反，让我们看一下提议者拆分诚实节点的情况。假设我们有诚实节点在两个不同的提案之间大致平均分配：

请注意现在一个重要的区别：恶意节点不再拥有 finalization 任何一个节点的权力。添加他们的选票只能使他们达到 60%，而不能达到 80%。这很好：这意味着我们可以继续执行其中一个选项，而不会冒着另一个选项将被 finalization 的风险，这将是不好的。这让我们更清楚地表达了我们想要的东西：

• 我们需要下一个提议者能够推断出一个安全的区块来构建——或者一个空的（nullified）区块。我们想要的是，如果他们是诚实的，他们的区块将被 finalization（并且这不能与前一轮 finalization 的冲突区块相矛盾）

Minimmit 使用 M-notarization（M 代表 mini）来实现这一点，这是一组超过 40% 的选票（或 nullify 选票）。重要的是，M-notarization 不是 finalization（在 Minimmit 中称为 L-notarization，尽管我将其简称为 finalization）。那是因为在同一个 slot 中可以有多个 M-notarization。最好的想法是，它是协议发给下一个提议者的一个信号：“构建在这个区块上是安全的”：

• 这意味着在 M-notarization 的 slot 中，没有其他提案可以被 finalization
• 如果一个诚实的提议者建立在一个 M-notarized 提案（或 nullification）上，那么他们的区块将被 finalization；换句话说，如果下一个提议者 (a) 按时提出建议，并且 (b) 不模棱两可，那么他们的提案将被 finalization

现在棘手的部分是要确保每个 slot 始终存在一个 M-notarization；当只有两个选项时，就像在我构造的示例中一样，这没问题；但是如果提议者发送了许多不同的区块，因此现在有了更多选项，并且没有一个选项获得超过 40% 的选票怎么办？这可以通过指示诚实节点在已经投票的情况下也发送一个 nullify 消息来解决，但仅当他们看到超过 40% 的选票是 nullify 选票或投票给他们没有投票的区块时才这样做。这是安全的，因为该条件意味着他们投票的区块不能再被 finalization；因此他们可以安全地投票 nullify 此 slot。

这个想法非常酷，因为它使协议超级简单：除了已经构建到区块链中的算法之外，没有特殊的视图更改算法。而且它也非常快：它可以在只有 40% 的选票的情况下取得进展，并且在只有一轮投票（80%）的情况下即可 finalization。

现在，让我们回到为什么我们需要特别超过 80% 的诚实节点，而不是像 75% 这样的小比例（我们已经看到 2/3 是不够的）。我们使用的关键属性是，如果存在 M-notarized 提案，则在给定的轮次中，没有其他提案可以被 finalization。现在，其中 20% 可能是恶意节点，因此我们真正知道的只有超过 20% 的诚实节点投票支持此提案。这意味着另外不到 60% 的诚实节点可能投票支持其他提案。这是关键：如果恶意节点为第二个提案投两次票，它仍然只能达到不到 80%，不足以将其推过边缘并 finalization。

由于非常接近 80% 的 finalization 阈值，因此我们无法降低诚实度要求。如果我们允许 21% 的恶意节点，则数学运算将不起作用：我们现在需要 79% 的选票才能 finalization（需要能够在没有恶意节点帮助的情况下 finalization），并且我们必须要求$100\% - 79\% + 21\% = 42\%$才能 M-notarization。我们还需要在已经投票后提高发送 nullify 投票的阈值（这是在提出多个提案的恶意提议者的情况下继续前进的关键）至 42%。现在假设恶意提议者发送了两个区块，并且恶意投票者不投票；那么他们每个人都有可能获得 39% 的诚实投票。现在协议卡住了：拆分投票的任何一方都无法 nullify 他们的投票，因为他们看不到 42% 的投票支持其他东西（只有 39% 在另一边）。这直观地表明，使用此协议，我们只能容忍少于 20% 的节点恶意。

协议描述

我们准备给出对协议的描述。我们假设以另一种方式预先确定领导者的时间表（这通常在区块链协议中给出，例如，他们可以使用 VRF（可验证随机函数）来确定随机领导者或仅轮流通过所有节点）。

定义：

• 提案是由当前轮次的提议者签名的区块。一个区块也指它的祖先，从而创建一个区块链。
• 投票是由一个节点签名的消息，其中包括正在投票支持的提案的哈希值。它由投票节点签名
• nullify 消息是一种替代投票，它表示没有有效的提案，或者在本轮中有多个有效的提案。它仅包括轮次编号和节点签名
• M-notarization 是收集超过 40% 的对有效提案的投票；对当前轮次的超过 40% 的有效 nullify 消息称为 nullification
• finalization 是收集超过 80% 的对有效提案的投票
• 如果一个提案是最后一个 finalization 的区块的后代，则该提案是有效的，自最后一个 finalization 的区块以来，所有祖先都经过 M-notarized 或有效的 nullification，并且它带有轮次领导者的签名（区块链协议可以添加其他有效性条件）

在每个轮次中：

1. 领导者会一直等待，直到他们看到上一轮的有效提案的 M-notarization（或 nullification）
2. 他们基于此提出一个区块
3. 所有节点都投票支持他们首先看到的有效提案，或者如果在协议指定的时间内没有看到提案，则投票 nullify
4. 如果一个节点看到 40% 的选票不是投给自己投票的提案，它也会投票 nullify 该轮次。
5. 节点在看到当前轮次的 M-notarization 后，立即进入下一轮。

关键是每个轮次：

• 始终存在 M-notarization 或 nullification（因此协议始终可以进行）
• 如果有几个选项（几个 M-notarized 的提案或一个 M-notarized 的提案和一个 nullification），那么这些选项都不能被 finalization（这意味着构建在 nullification 的 M-notarization 之上始终是安全的）

M-notarization 与动态可用性相似吗？

在以太坊中，“动态可用性”的思想是，即使少于共识多数（在以太坊的情况下为 2/3）的节点在线，我们也可以继续构建链——这种动态可用的链对于像 finalization 的链那样的重组是不安全的，尽管它确实提供了一些针对少数攻击者的保证。

假设所有在线节点都是诚实的，并且在合理的同步假设下，Minimmit 可以仅在 40% 的节点在线的情况下构建链，类似于动态可用共识。虽然它需要 40% 的节点在线（与能够在以太坊中以个位数百分比继续进行比较），但这仍然比大多数 BFT 协议要好得多，后者一旦少于 2/3 的所有节点在线就会失败。它看起来类似于 ebb and flow 构造或以太坊的 FFG+GHOST 构造。

让我们考虑一下当两个不同的 M-notarization 链可用时会发生什么，这可能在网络分区后发生。假设我们有一个分区，其中两组节点（每组都有足够的节点来形成 M-notarization）独立运行，每个分区内都保持同步，但它们之间没有通信。由于 Minimmit 不使用固定的 slot 时间，而是在看到 M-notarization 时推进轮次，因此两个链可能会以不同的速率推进，从而产生不同的轮次编号。

当分区解决并且同步恢复时，下一个诚实的领导者（假设领导者是随机选择的，并且事先不为对手所知）将看到两个链。他们可以选择在哪个链上构建，并且所有诚实的节点都会投票支持他们的提案。但是，如果一个链已达到更高的轮次编号（即，具有更多 M-notarized 轮次，不包括 nullification），那么遵循较短链的节点将已经推进以匹配较长链的轮次编号，因为他们看到了丢失的 M-notarization。在这种情况下，领导者别无选择，只能在具有更高轮次编号的链上构建，因此该分区会支持推进更快的链。

这与以太坊没有什么不同，以太坊必须添加提议者提升 5，以确保在攻击者试图平衡链的情况下，链拆分始终可以解决（添加他们的投票以始终保持投票拆分）。在 Minimmit 中，当链具有相似的轮次编号时，提议者充当仲裁者；但是当一个链明显更长（在具有 M-notarization 轮次编号方面）时，该协议自然会支持它。

参考文献

1. Chou, B. K., Lewis-Pye, A., & O’Grady, P. (2025). Minimmit：具有更快区块的快速 Finality。被 FC'26 接受（金融密码学 2026）。↩ ↩2

2. Kuznetsov, P.，Tonkikh, A., & Zhang, Y. X. (2021)。重新审视快速拜占庭共识的最佳弹性。作者表明，当提议者是接受者的子集时，$5f-1$ 是快速拜占庭共识的紧下界，纠正了早期的误解。↩

3. Martin, J. P., & Alvisi, L. (2006)。快速拜占庭共识。IEEE Transactions on Dependable and Secure Computing, 3(3), 202-215。FaB Paxos 确定，对于提议者和接受者是不同集合的两步共识协议，至少需要 $5f+1$ 个副本。↩

4. Castro, M., & Liskov, B. (1999)。实用拜占庭容错。在 OSDI (Vol. 99, pp. 173-186) 中。在 PBFT 中，一旦在准备阶段准备好（justified）一个请求，诚实的副本将不会在同一视图中准备冲突的请求。↩

5. 引入了提议者提升以防止以太坊分叉选择中的平衡攻击。该机制在以太坊共识规范中指定，并在 LMD GHOST 分叉选择的上下文中进行了讨论。有关平衡攻击以及需要提议者提升的原始讨论，请参见ethresear.ch 讨论。↩

• 原文链接： dankradfeist.de/tempo/20...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～