【共识专栏】Quorum机制与PBFT

实用性拜占庭容错算法（Practical Byzantine Fault Tolerance，PBFT），是一种在信道可靠的情况下解决拜占庭将军问题的实用方法。拜占庭将军问题最早由Leslie Lamport等人在1982年发表的论文[1]提出，论文中证明了在将军总数n大于3f，背叛者为f或者更少时，忠诚的将军可以达成命令上的一致，即3f+1<=n，算法复杂度为O(n^(f+1))。随后Miguel Castro和Barbara Liskov在1999年发表的论文[2]中首次提出PBFT算法，该算法容错数量也满足3f+1<=n，算法复杂度降低到了O(n^2)。

如果对于PBFT共识算法有所了解，对节点总数n与容错上限f的关系可能会比较熟悉：在系统内最多存在f个错误节点的前提下，系统内总节点数量n应该满足n>3f，在推进共识过程中则需要收集一定数目的投票，才能完成认证过程。在本节当中，我们将首先讨论这些数值间关系该如何得出。

–Quorum机制–

在有冗余数据的分布式存储系统当中，冗余数据对象会在不同的机器之间存放多份拷贝。但是在同一时刻，一个数据对象的多份拷贝只能用于读或者写。为了保持数据冗余与一致性，需要对应的投票机制进行维持，这就是Quorum机制。区块链作为一种分布式系统，同样也需要该机制进行集群维护。

为了更好地理解Quorum机制，我们先来了解一种与之类似，但是更加极端的投票机制——WARO机制（Write All Read One）。使用WARO机制维护节点总数为n的集群时，节点执行写操作的“票数”应当为n，而读操作时的“票数”可以设置为1。也就是说，在执行写入时，需要保证全部节点完成写入操作才可视该操作为完成，否则会写入失败；相应地，在执行读操作时，只需要读取一个节点的状态，就可以对该系统状态进行确认。可以看到，在使用WARO机制的集群中，写操作的执行非常脆弱：只要有一个节点执行写入失败，那么这次操作就无法完成。不过，虽然牺牲了写操作健壮性，但是，在WARO机制下，对于该集群执行读操作会非常容易。

Quorum机制[3]就是对读写操作的折衷考虑，对于同一份数据对象的每一份拷贝，不会被超过两个访问对象读写，并且权衡读写时的集合大小要求。在一个分布式集群当中，每一份数据拷贝对象都被赋予了一票。假设：

系统中有V票，这就意味着一个数据对象有V份冗余拷贝；

对于每一个读操作，获得的票数必须不小于最小读票数R（read quorum）才可以成功读取；

对于每个写操作，获得的票数必须不小于最小写票数W（write quorum）才可以成功写入。

此时，为了维持集群一致性，V、R、W应满足不等关系，R+W>V且W>V/2。其中，R+W>V保证了一个数据不会被同时读或写。当一个写操作请求传入，它必须要获得W票，而剩下的数量是V-W不足R，因此不会再处理读请求。同理，当读请求已经获得了R票，写请求就无法被处理。W>V/2，保证了数据的串行修改，也就是说，一份数据的冗余拷贝不可能同时被两个写请求修改。

对于集群中的共识节点，在推进共识算法时，参与共识的节点会同时对集群进行读写操作。为了平衡读写操作对于集合大小的要求，每个节点的R与W取同样大小，记为Q。当集群中总共存在n个节点，并且其中最多出现f个错误节点的情况下，我们该如何计算n、f、Q之间的关系呢？接下来，我们将从最简单的CFT场景出发，逐步探索如何在BFT场景中得到这些数值取值之间的关系。

▲CFT

CFT（Crash Fault Tolerance），表示系统中的节点只会出现宕机（Crash）这种错误行为，任何节点不会主动发出错误消息。当我们在讨论共识算法可靠性时，通常会关注算法两种基本性质：活性（liveness）与安全性（safety）。在计算Q的大小时，同样也可以从这两个角度出发进行考虑。

对于活性与安全性，有一种比较直观的描述方式：

something eventually happens[4]，某个事件最终会发生

something good eventually happens[4]，这个最终会发生的事件合理

从活性角度出发，我们的集群需要能够持续运行下去，不会由于某些节