【发布时间】：2021-02-27 21:33:48
【问题描述】：
如果使用相同的 ProposalId 发布了两个提案，会发生什么情况？如果它们具有相同的值，它不应该产生任何问题。但是不同的价值观呢？我可以设计出一个场景，它会在失败时冒着生命危险，但这会对协议的安全性造成任何问题吗？
【问题讨论】：
【发布时间】：2021-02-27 21:33:48
【问题描述】：
这是一个好主意，因为它可以缓解实际系统的恼人设计要求：设计一个方案以确保提议者拥有不同但不断增加的轮数。
不幸的是，它不起作用。
让我们将 PaxosPrime 定义为 Paxos 的变体，其中允许不同的提议者拥有相同的轮数。我们通过矛盾证明 PaxosPrime 不是共识算法。
证明草图：假设 PaxosPrime 是一种共识算法。让我们考虑每个接受器在哪里具有不同的值，但在同一轮中（w.l.o.g 我们将选择
3）。每个人也将在 3 时承诺。然后我们有一对提议者在系统中进行交互。
A1 | A2 | A3
v p | v p | v p
------+-------+------
x@3 3 | y@3 3 | z@3 3
- P1 准备第 4 轮（即阶段 1.A）并接收所有三个值
x@3、y@3和z@3。 Paxos 中没有规定可以打破平局，所以我们让它选择x。- P2 也为第 4 轮做准备，并分别从 A2 和 A3 收到
y@3和z@3。我们让它选择y。- P1 为
x@4（即阶段 2.A）发送接受，并且接受者都处理它。此时所有的acceptor都有v@4的值并且承诺为4。系统对x的值达成共识。- P2 发送接受轮
y@4并且接受器 A2 和 A3 成功处理它。大多数接受者现在具有价值y@4； 系统对y的值达成共识。这是从接受者的角度来看的痕迹：
A1 | A2 | A3
v p | v p | v p
------+-------+------
x@3 3 | y@3 3 | z@3 3 # Start
x@3 4 | y@3 4 | z@3 4 # Process P1's propose command
x@3 4 | x@3 4 | x@3 4 # Process P1's accept command
x@3 4 | y@3 4 | y@3 4 # Process P2's accept command
系统首先对值
x达成共识，然后对值y达成共识。这是对共识的定义的矛盾；因此 PaxosPrime 不是共识算法。■
【讨论】：
-
所以它违反了安全性，感谢您的出色回答。这是基于您的示例的另一个想法：Acceptor 具有三个不同的值，这仅仅是因为至少有一个 Acceptor 在第 3 轮中向多个提议者承诺（阶段 1B）（否则多个提议者无法到达第二阶段）。 Paxos 允许这样做。如果我们不允许呢？我们可以通过在 Acceptor 中的每一轮 Promised 中保留唯一的 ProposerID（例如其 IP）来轻松执行它......（请继续下一条评论）
-
... 这样，Acceptor 在每一轮中仅将其 Promise 提供给 一个特定的提议者（并拒绝其他提议者），因此不允许多个提议者到达该轮的第二阶段。因此，这消除了 Acceptor 在同一轮中具有不同值的可能性。
-
好的，但是如果我们只承诺准备数量严格大于目前看到的最高准备数量怎么办？然后，不可能从不同的提议者那里获得相同的准备值的多个多数承诺。那你怎么证明呢？
Synod 算法在技术上并不要求提案编号在所有进程中都是唯一的。而单调递增的需求只是一种优化。从技术上讲，我们可以选择一个随机的提案编号，并且仍然有一个正确的算法。
算法从提议者向所有接受者发送准备（提议编号）开始。然后，如果大多数接受者还没有看到提案编号高于或高于该提案编号，并且成功发回每个提案编号只能发生一次的承诺，则它只能在提案中使用该提案编号。在这个阶段之后，如果提议者能够继续，那么该提议号实际上是唯一的。因此，该算法已经强制执行提案中实际使用的提案编号的唯一性。
【讨论】：