Vetomint：Simperby 的 BFT 共识协议

Vetomint: Simperby 的 BFT 共识协议

概要

Vetomint 是一种共识算法，旨在满足 Simperby 的特殊需求。顾名思义，Vetomint 是 Tendermint 的修改版本。它旨在支持通过投票来取代指定的共识领导者，原因不限。此外，Vetomint 在设计时考虑了 Simperby 的自托管特性，因此可以在较长的超时时间内运行而不会降低性能，从而验证者可以偶尔运行他们的节点。下面总结了应用于 Tendermint 的修改以及 Vetomint 的最终属性：

行为

1. 验证者可以在超时到期之前投出 nil 预投票，以反对该轮（无论是否存在现有提案）。
2. 如果验证者收集到超过 5/6 的预投票（无论是 nil 投票还是非 nil 投票），它会立即停止并根据到目前为止收集的投票投出预提交。

属性

1. 假设所有非拜占庭验证者都投出预投票/预提交，并且消息在超时到期之前送达，则系统永远不会因可能的争议而被超时阻塞。
2. 如果拜占庭投票权小于 $1/3$，则保证系统安全。即，安全性的拜占庭阈值为 $1/3$。
3. 如果拜占庭投票权小于 $1/6$，并且所有非拜占庭验证者都对提案投出非 nil 预投票，则提案将被接受。

动机

Vetomint 的主要目标是让验证者可以选择通过类似投票的程序来取代指定的共识领导者。Vetomint 中的验证者可以对当前共识领导者的更换进行投票，甚至在区块提案之前。

这种需求的基本原因是 Simperby 采用的稳定领导者策略。 也就是说，除非明确更换，否则预计领导者保持不变（与典型 PoS 共识协议中基于循环的领导者选择相反）。 由于 Simperby 的所有验证者都旨在运行自己的节点，并且 Simperby 给提案者带来了沉重的负担（参见 协议概述），因此稳定的领导者策略显着提高了可用性。 与其所有其他偶尔打开节点进行投票的验证者不同，领导者应保持其节点开启状态，以用于按需区块生产和管理聊天服务。 并非所有验证者都愿意承担此负担，因此最好选择一些志愿者并让他们稳定地担任领导者。

稳定提案者策略的一个主要缺点是需要一个明确更改指定区块提案者的程序，以防提案者做错事。但是我们真的需要投票来做到这一点吗？ 答案是肯定的，因为错误的观念并不总是客观的。 例如，提案者可能会审查特定议程，使其无法包含在区块中，或者即使存在符合条件的议程，也拒绝提出区块。 这些无疑是恶意的——或者至少是不负责任的行为，但是没有明确的规则来确定它们——如果只有少数验证者认识到被审查的议程，我们应该称之为审查吗？

还应该注意的是，我们不能依赖超时到期来进行此决策。这是因为 Simperby 旨在按需生成区块，并且超时间隔被假定为很长。 因此，更换投票应在等待提案的阶段进行。

对 Tendermint 的修改

为实现该目标，我们对 Tendermint 进行了多项修改，总结如下：（1）在 Vetomint 中，验证者可以对语法有效的区块投出 nil 预投票，甚至在没有提议区块的情况下也可以；（2）如果验证者收到超过 5/6 的总预投票，则它会立即进入下一阶段，而无需等待超时到期。

超时到期之前的 Nil 预投票

首先，Vetomint 中的验证者可以在超时到期之前投出 nil 预投票。这些 nil 预投票用于更换当前的领导者，或者区块提案者。如果验证者认为当前的领导者不负责任或恶意审查议程，则无论领导者是否提出了区块，或者提出的区块是否在语法上有效，它都可以投出 nil 预投票。Nil 预投票的累积将导致拒绝提案（如果存在），并转移到具有更改的领导者的下一轮，这与 Tendermint 没有什么不同。

<!---
TODO: 详细说明这一点。
以下文字非常适合给出直觉，但包含细微的错误。
直观地说，在原始 Tendermint 中滥用 nil 预投票只不过是拥有错误的时钟。
-->

这种修改将保留安全条件。也就是说，同一高度上的两个验证者不会决定不同的区块提案。 直观地说，在原始 Tendermint 中滥用 nil 预投票只不过是拥有错误的时钟。在 Tendermint 的异步设置下，这不会影响安全性。稍后我们将在本文中讨论活跃性条件，即验证者最终将决定区块提案。

提前终止

Vetomint 对 Tendermint 的第二个修改是基于收到的总预投票进行提前终止的能力。在 Vetomint 中，如果验证者收集到超过 5/6 的预投票（无论是 nil 投票还是非 nil 投票），它会立即停止并根据到目前为止收集的投票投出预提交。在以下段落中，我们将解释此修改背后的基本原理。我们还将说明 5/6 阈值的选择自然意味着 1/6 的拜占庭阈值。

让我们回顾一下 Tendermint 的相关行为，以了解此决策。在 Tendermint 中，如果验证者在给定的轮次中收集到超过 2/3 的非 nil 预投票，则预投票阶段的验证者可以跳过超时事件，进入预提交阶段。假设所有非拜占庭验证者都及时参与，而没有网络延迟，则这可以显着优化共识。但是，即使已收集到超过 2/3 的预投票（包括 nil 预投票），Tendermint 也不允许基于预投票总数的提前终止。在原始 Tendermint 中，此行为没有问题，因为超时间隔通常很短，并且来自非拜占庭验证者的投票不会分裂，因为提案的接受由一组预定义的规则（而不是验证者的意愿）确定性地决定。

但是，由于我们假设 Vetomint 中的验证者可以自由地投出 nil 预投票，因此缺乏提前终止成为一个严重的问题。例如，可能存在一半的验证者投出了非 nil 预投票，而另一半投出了 nil 预投票的情况。在这种情况下，如果是原始 Tendermint，即使所有验证者都做出了决定，验证者也只能等待即将到来的超时到期，这可能是无法忍受的漫长。

为了防止此类问题，我们在 Tendermint 中添加了新的提前终止规则。如果验证者收集到超过 5/6 的总预投票（无论是 nil 投票还是非 nil 投票），它将根据到目前为止收到的预投票进入下一阶段。具体来说，在收到的预投票中，如果非 nil 预投票超过了预投票总数的 2/3，则验证者将广播非 nil 预提交，否则将广播 nil 预提交。

5/6 的阈值是经过仔细选择的。为了证明这一点，请考虑以下极端情况，其中阈值为 2/3（小于 2/3 或大于 1 的阈值毫无意义）。 假设提出了一个无可争议的可接受区块，除了一个试图延迟共识的恶意验证者之外，所有验证者都投出了非 nil 预投票。在理想的情况下，恶意行为应被有效地忽略。但是，我们可以很容易地看到，恶意验证者很有可能仅通过投出 nil 预投票来阻碍共识。在提前终止之前收到 nil 预投票的所有验证者都将（保守地）假定未满足法定人数：他们每个人都收到了略多于 2/3 的总预投票，并且其中一个预投票为 nil，这意味着收到的非 nil 预投票小于 2/3。简而言之，2/3 的阈值使系统对于外部攻击而言过于脆弱。

为了进一步解释选择 5/6 的重要性，我们将提出一个（非正式的）论点来表明它是最佳阈值。令 $x$ 为提前终止阈值。我们将证明 $x = 5/6$ 是最佳的。

首先，提前终止规则旨在防止共识因超时而陷入停滞，只要所有非拜占庭验证者都及时参与即可。为实现此目的，拜占庭阈值必须不大于 $1-x$。如果更大，则拜占庭验证者可能会通过简单地不广播预投票来阻碍共识。

其次，我们希望确保，如果超过 2/3 的验证者投出了非 nil 预投票，则无论恶意验证者的行为或消息的传输方式如何，提案都将被接受。 （2/3 阈值对于确保后续 Tendermint 阶段的安全性至关重要。） 让我们考虑一个场景，其中超过 $2/3$ 的验证者投出了非 nil 预投票，但是 $1-x$ 恶意验证者使用 nil 值伪造了他们的预投票，并且条件 $(1-x) + 2/3 > x$ 成立。 然后，收到 $1-x$ nil 预投票（来自恶意验证者）且恰好 $2/3$ 非 nil 预投票的验证者将提前终止，因为收到的总预投票 $(1-x) + 2/3$ 超过了提前终止阈值，即 $x$。 由于收集的非 nil 预投票的比例未超过 2/3，因此验证者将错误地得出未满足法定人数的结论，这是不可接受的。 为了防止这种结果，我们必须有 $(1-x) + 2/3 \le x$，或 $x \ge 5/6$。为了尽可能地最大化拜占庭阈值，最佳选择是 $x=5/6$，从而导致拜占庭阈值为 $1-x = 1/6$。

VetoMint 中不保证活跃性。但是，这并非 VetoMint 的设计错误，而是基于阈值进行决策所固有的问题：当然，如果验证者反复更换领导者，那么将根本不会创建区块。但是，我们仍然可以确保，如果所有非拜占庭验证者都决定不投 nil 预投票，则恶意验证者将无法阻碍共识。换句话说，假设所有非拜占庭验证者都投出非 nil 预投票并且消息已传递，则系统始终会取得进展并生成一个新区块。

• 原文链接： github.com/postech-dao/s...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～