PBFT：为什么副本在 2/3 准备好后无法执行请求？为什么我们需要提交阶段？

Question

我知道该网站上有一些问题提出了相同的问题。然而答案始终不明确：

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

Answer 1

（已编辑）除了之前（不完整）的答案之外，引用《实用拜占庭容错和主动恢复》可能会有所帮助。请注意，作者声称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. [预准备阶段]：Primary(b1) 向 G2 发送 0 值，向 G3 发送 1 值。这种情况不是问题，因为我们假设拜占庭主。

2. [准备阶段]：现在G2和G3中的副本交换来自主节点的消息，以检查它们是否具有相同的消息。但是，在此阶段，G1 的副本向 G2 发送 0 值，向 G3 发送 1 值。消息交互后，情况如下

   A。G2 中的副本收到以下结果；66 票支持 0 值，34 票支持 1 值。

   b. G3 中的副本收到以下结果；33 票为 0 值，33+34=67 票为 1 值。

由于仲裁大小为 2f+1 = 67，G3 中的副本接受来自与拜占庭副本协调的拜占庭主节点的建议值，而 G2 中的副本则不接受。

因此，在系统中，即使系统可以容忍最多 33 个拜占庭故障副本（包括主副本），但它会立即在您的假设中失败。