PBFT：为什么2/3准备好之后复制品无法执行请求？为什么我们需要提交阶段？

Question

我知道在这个网站上有一些问题会提出同样的问题。但答案永远不清楚：

在PBFT中，为什么在2/3准备好之后副本不能执行请求？为什么需要提交阶段？如果2/3 + 1副本同意准备，那么我认为他们可以执行请求而不再播放？

Answer 1

（已编辑）除了之前（不完整）的回答，来自Practical Byzantine Fault Tolerance and Proactive Recovery的引用可能有所帮助。请注意，作者声称Prepare阶段足以在同一视图中对请求进行排序，但是对于跨视图更改排序请求是不够的，因此这就是需要Commit阶段的原因。

这可确保副本在同一视图中就​​请求的总订单达成一致，但不足以确保跨视图更改的请求的总订单。副本可以使用相同的序列号和不同的请求在不同的视图中收集准备好的证书。提交阶段解决了以下问题。

---

客户的请求应该是完全有序的，并且应该以完全相同的顺序执行。通过按您提到的法定大小收集准备消息，副本在准备阶段就请求顺序达成共识，但在该阶段不会立即执行，因为它们必须以相同的顺序执行相同的请求。 （在状态复制机系统中，所有状态机必须以相同的顺序确定性地执行相同的请求以满足安全条件;执行顺序影响状态机的状态）

因此，在提交阶段，他们必须就执行时间达成共识，以便他们在安全条件的同一时间单元中执行相同的请求。

在您的评论“一旦复制品收到2/3准备，他们可以提交”，每个状态机（PBFT的节点）的内部状态将发散，违反安全条件。这就是需要提交阶段的原因。

---

回答你的评论;

当副本按法定大小获得准备消息时，副本执行请求时，可能出现上述情况。我认为PBFT假定部分同步的重要事实;由于网络速度或对手不稳定，消息可以被任意延迟，但最终会收到。因此，每个副本可以在不同的时间点执行请求消息，并且示出了一个示例情况。

---

回答你的第二条评论

我想我需要通过说明恶意复制品（包括主要复制品）的协同攻击来详细说明答案。假设n个复制品，其中n = 3f + 1 = 100，在拜占庭容错系统中f = 33。在该系统中，系统可以容忍f个拜占庭故障复制品。现在我举一个反例来回答你的问题。考虑以下设置;我将n个副本分成三组;

1. G1 = {b1，b2，...，b33}为拜占庭故障复制品，包括拜占庭初级（b1），| G1 | = 33
2. 对于正确的副本组，G2 = {r1，r2，...，r33}，| G2 | = 33
3. 对于正确的副本组，G3 = {r34，r35，...，r67}，| G3 | = 34

因为n = | G1 | + | G2 | + | G3 | = 33 + 33 + 34 = 100，上面的分区是有道理的。并且G1完全由超级天才黑客以协调的方式控制，他们对破坏协议特别感兴趣。

现在，我将演示如果提交阶段从协议中消失，上述设置如何违反安全条件; （安全条件是指G2和G3的状态应相同）。为简单描述，将共识值简化为二进制值，而不是具有序列号的请求。

1. [预备阶段]：主要（b1）向G2发送0值，向G3发送1值。这种情况不是问题因为我们假设拜占庭主要。
2. [准备阶段]：现在G2和G3中的副本交换来自主要消息的消息，以检查它们是否具有相同的消息。但是，在此阶段，G1的副本向G2发送0值并向G3发送1值。消息交换后，情况如下 一个。 G2中的复制品收到以下结果; 66票对0票，34票对1票。 湾G3中的复制品收到以下结果; 33票对0值，33 + 34 = 67票对1值。

由于法定人数大小为2f + 1 = 67，因此G3中的副本接受来自Byzantine primary的建议值，该值与Byzantine副本进行协调，而G2中的副本则不接受。

因此，在系统中，即使系统可以容忍多达33个拜占庭故障副本（包括主要副本），它也会立即失败。