为什么PBFT需要View Changes

若图片不显示，请访问原文：https://lessisbetter.site/2020/03/22/why-pbft-needs-viewchange/

前言

在当前的PBFT资料中，尤其是中文资料，多数都在介绍PBFT的3阶段消息过程，很少提及View Changes（视图切换），View Changes对PBFT的重要性，如同Leader Election对Raft的重要性，它是一个一致性算法中，不可或缺的部分。

作者为大家介绍下，为什么View Changes如此重要，即为什么PBFT需要View Changes，以及View Changes的原理。

为什么PBFT需要View Changes

一致性算法都要提供：

• safety ：原意指不会出现错误情况，一致性中指操作是正确的，得到相同的结果。
• liveness ：操作过程能在有限时间内完成。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-g1zlt75J-1586608969105)(http://img.lessisbetter.site/2020-03-consistency-property.png)]

safety通常称为一致性，liveness通常称为可用性，没有liveness的一致性算法无法长期提供一致性服务，没有safety的一致性算法称不上一致性算法，所以，所有的一致性算法都在做二者之间的折中。

所以对一致性和可用性不同的要求，就出现了你常听见的ACID原理、CAP理论、BASE理论。

PBFT作为一个一致性算法，它也需要提供一致性和可用性。在为什么PBFT需要3个阶段消息中，介绍了PBFT算法的如何达成一致性，并且请求可以在有限时间内达成一致，客户端得到响应，也满足可用性。

但没有介绍，当遇到以下情况时，是否还能保住一致性和可用性呢？

1. 主节点是拜占庭节点（宕机、拒绝响应…）
2. 主节点不是拜占庭节点，但非拜占庭副本节点参与度不足，不足以完成3阶段消息
3. 网络不畅，丢包严重，造成不足以完成3阶段消息
4. …

在以上场景中，新的请求无法在有限时间内达成一致，老的数据可以保持一致性，所以一致性是可以满足的，但可用性无法满足。必须寻找一个方案，恢复集群的可用性。

PBFT算法使用View Changes，让集群重新具有可用性。通过View Changes，可以选举出新的、让请求在有限时间内达成一致的主节点，向客户端响应，从而满足可用性的要求。

让集群重新恢复可用，需要做到什么呢？让至少f+1个非拜占庭节点迁移到，新的一致的状态。然后这些节点，运行3阶段消息协议，处理新的客户端请求，并达成一致。

不同版本的View Changes协议有什么不同？

PBFT算法有1999年和2001年2个版本：

• 99年：Practical Byzantine Fault Tolerance，PBFT初次发表。
• 01年：