为什么我们需要在共识协议的视图变化中进行总排序？

Question

在他们著名的article 中，Miguel Castro 和 Barbara Liskov 证明了 PBFT 共识协议的提交阶段是这样的：

这确保副本在请求的总顺序上达成一致 相同的观点，但不足以确保总订单 跨视图更改的请求。复制品可以收集准备好的 具有相同序列号的不同视图中的证书和 不同的要求。提交阶段按如下方式解决了这个问题。 每个副本 i 多播 _{α_i} 说它有 准备好证书并将此消息添加到其日志中。那么每个 副本收集消息，直到它具有 2 f + 的仲裁证书 1 COMMIT 消息对于相同的序列号 n 和视图 v 来自 不同的副本（包括它自己）。我们称此证书为 提交的证书并说请求是由 当它同时具有准备好的和提交的证书时的副本。

但是为什么我们需要保证视图更改的总顺序？ 如果领导者/主副本失败并触发视图更改，那么丢弃前一个视图中的所有内容就足够了吗？什么情况下提交阶段阻止了这个解决方案没有？

抱歉，如果这太明显了。我是分布式系统的新手，我还没有找到任何直接回答这个问题的来源。

Answer 1

这有一个概念上的原因。该系统在客户看来是一个黑盒子。这个盒子的整个想法是提供对某些服务的可靠访问，因此，它应该掩盖特定副本的故障。否则，如果您在每次视图更改时丢弃所有内容，客户端将不断丢失其数据。所以基本上，您的解决方案与规范相矛盾。确切地需要提交阶段来防止这种情况。如果只有在有 2f + 1 个 COMMIT 消息时才“接受”请求，那么即使所有 f 个副本都发生故障，其余节点也可以恢复所有已提交的请求，这提供了对系统的持久访问。

还有一个技术原因。从理论上讲，系统是异步的，这意味着您甚至不能保证视图更改只会因故障而发生。一些副本可能只是怀疑leader有故障而改变视图。使用您的解决方案，即使没有副本出现故障，系统也可能会丢弃它接受的所有内容。

如果您是分布式系统的新手，我建议您看看容忍非拜占庭故障的经典协议（例如 Paxos），它们更简单，但以类似的方式解决问题。

编辑

当我说“客户不断丢失他们的数据”时，这比听起来要多。我说的是特定客户端请求对系统的影响。让我们看一个键值存储。客户A 通过我们的“黑匣子”将一些value 与一些key 关联起来。 “黑匣子”现在根据任何其他并发（或简单的并行）请求对该请求进行排序。然后它在所有副本中复制它，最后通知A。没有提交阶段就没有排序，在两个不同的视图中，我们的“黑匣子”可以选择两种不同的客户端请求执行顺序。话虽如此，以下是可能的：

1. 每次t、A 将value 关联到key 并且“框”批准了这一点，
2. 当时t+1、B 将value_2 关联到key 并且“框”批准了这一点，
3. 当时t+2，C从key读取value_2，
4. 视图更改（客户端不可见），
5. 当时t+3，D 从key 读取value。

请注意，（5）是可能的，不是因为“盒子”不知道value_2（正如你提到的值本身可以重新提交），而是因为它不知道以前它先写了value，然后用value_2 覆盖它。在新视图中，系统需要以某种方式对这两个请求进行排序，但没有运气，该决定与过去不一致。

最终同步是保证协议活跃性的一种方式，但是它不能防止上述情况。最终同步状态最终您的系统将表现得与同步系统非常相似，但您不知道什么时候，在那之前任何奇怪的事情都可能发生。如果在异步期间违反了安全属性，那么显然整个系统是不安全的。

Answer 2

PBFT 的输出不应该是每个视图一个日志，而是一个不断增长的全局日志，每个视图都试图为其贡献新的“块”。

区块链中的等效概念是每个区块提议者或区块矿工必须附加到当前区块链，而不是从头开始新的区块链。 IE。新区块必须尊重之前的交易，就像新的观点必须尊重之前的观点一样。

如果总排序在各个视图之间不一致，那么我们就失去了上面的属性。

事实上，如果我们在 PBFT 中的每个序列号之后强制更改视图，它看起来很像区块链，但具有更复杂的恢复/安全机制（部分原因是 PBFT 块不会提交到前一个块，所以我们需要单独就每一个达成一致）