分布式与一致性协议之PBFT算法(一)

PBFT算法

概述

前面提到了拜占庭将军问题之后，有人可能会感到困惑:口信消息型拜占庭问题直接在实际项目中是如何落地的呢？事实上，它很难在实际项目中落地，因为口信消息型拜占庭问题之解是一个非常理论化的算法，没有与实际场景结合，也没有考虑如何在实际场景中落地和实现。

比如，它实现的是在拜占庭错误场景下，忠将们如何在判断干扰时就一致行动达成共识。但是它并不关心结果是什么，这会出现一种情况:现在适合进攻，但将军们达成的最终共识却是撤退。

很显然，这不是我们想要的结果。因为在实际场景中，我们需要就提议的一系列值(而不是单值)，即使在拜占庭错误发生的时候，也能达成共识。那我们应该怎么做呢？答案就是采用PBFT算法。

PBFT算法非常实用，它是一种能在实际场景中落地的拜占庭容错算法，在区块链中应用广泛(比如Hyperledger Sawtooth、Zilliqa)。为了更好地理解PBFT算法，下面会先介绍口信消息型拜占庭问题之解的局限，再介绍PBFT算法的原理。

老规矩，我们先看一道思考题。
假设苏秦再一次带队抗秦，如苏秦和4个国家的4位将军赵、魏、楚、韩商量军机要事，如图所示在这里插入图片描述
，结果刚商量完没多久苏秦就接到了情报:联军中可能存在一个叛徒。这时，苏秦要如何下发作战指令来保证忠将们正确、一致地执行下发的作战指令，而不被叛徒干扰呢？

口信消息型拜占庭问题之解的局限

口信消息型拜占庭问题之解有个非常致命的缺陷。如果将军数为n、叛将数为f,那么算法需要递归协商f+1轮，消息复杂度为O(n^(f+1))，消息数量指数级暴增。你可以想象以下，如果叛将数为64，那么消息数会远远超过int64所能表示的数量，这是无法想象的，不可行的。

另外，尽管对于签名消息，不管叛将数(比如f)是多少，经过f+1轮的协商，忠将们都能达成一致的作战指令，但是这个算法同样存在"理论化"和"消息数指数级暴增"的痛点，说到这儿，你肯定明白为什么这个算法很难再实际场景中落地了。不过技术是不断发展的，算法也是在解决实际场景问题中不断改进的。那么PBFT算法的原理是什么呢？为什么它能在实际场景中落地呢？

PBFT算法是如何达成共识的

我们先来看看如何通过PBFT算法解决苏秦面临的共识问题。先假设苏秦制定的作战指令是进攻，而楚是叛徒(为了演示方便)，如图所示在这里插入图片描述

需要注意的是，所有的消息都是签名消息，也就是说，消息发送者的身份和消息内容都是无法伪造和篡改的(比如，楚无法伪造一个假装来自赵的消息)。
首先，苏秦联系找，向赵发送包含作战指令"进攻"的请求，如图所示. 在这里插入图片描述

当赵接收到苏秦的请求之后，会执行三阶段协议(Three-phase protocol)。
赵将进入预准备(Pre-prepare)阶段，构造包含作战指令的预准备消息，并广播给其他将军(魏、韩、楚)，如图所示。在这里插入图片描述

在这里想问一个问题:魏、韩、楚收到消息后能之解执行指令吗？
答案是不能，因为他们不能确认自己接收到的指令与其他人接收到的指令是相同的。比如,赵可能是叛徒，赵收到了两个指令，分别是"进攻"和"准备30提案的粮草"，然后他给魏发送的是"进攻"，给韩、楚发送的是"准备30天粮草"，这样就会出现无法一致行动的情况。那么具体怎么办呢？
接收到预准备消息之后，魏、韩、楚将进入准备(Prepare)阶段，并分别广播包含作战指令的准备消息给其他将军。比如，魏广播准备消息给赵、韩、楚，如图所示在这里插入图片描述
。为了方便演示，我们假设叛徒楚想通过不发送消息来干扰共识协商(如图所示，楚没有发送消息)。

然后，某个将军在收到2f个(包括自己，其中f为叛徒数,在该演示中是1)一致的包含作战指令的准备消息后，会进入提交阶段(Commit)阶段。在这里，提一个问题:此时该将军(比如魏)可以之解执行指令吗?
答案是不能，因为魏不能确认赵、韩、楚是否收到了2f个一致的包含作战指令的准备消息。也就是说，魏这时无法确认赵、韩、楚是否已经准备好执行作战指令，那么怎么办呢？

进入提交阶段后，各将军(不包括叛徒楚)分别广播提交信息给其他将军，也就是告诉其他将军，我已经准备好执行指令了，如图所示在这里插入图片描述

最后，当某个将军收到2f+1(包括自己，其中f为叛徒数，在该演示中为1)个验证通过的提交消息后，也就是大部分的将军已经达成共识，可以执行作战指令了，那么该将军将执行苏秦的作战指令，并在执行完毕后发送执行成功的消息给苏秦，如图所示。在这里插入图片描述

最后，当苏秦收到了f+1个(其中f为叛徒数，在该演示中为1)相同的响应(Reply)消息时，说明各位将军们已经就作战指令达成了共识，并执行了作战指令。
你看，将军们经过3轮协商，是不是就指定的作战指令达成了共识并执行了作战指令呢？
在这里，苏秦采用的就是简化版的PBFT算法，在这个算法中:

1.可以将赵、魏、韩、楚理解为分布式系统的四个节点，其中赵是主节点(Primary),魏、韩、楚是备份节点(Backup);
2.可以将苏秦理解魏业务，也就是客户端
3.可以将消息理解为网络消息
4.可以将作战指令"进攻"理解为客户端提议的值，也就是希望被个节点达成共识并提交给状态的值。
PBFT算法通过签名(或消息认证码MAC)来约束恶意节点的行为的，也就是说，每个节点都可以通过验证消息签名来确认消息的发送来源，一个节点无法伪造另外一个节点的消息。同时，该算法是基于大多数原则(2f+1)实现共识的。而最终的共识是否达成，是由客户端进行判断的，如果客户端在指定事件内未收到请求对应f+1个相同响应，则认为集群故障，未达成共识，且客户端会重新发送请求。

需要注意的是，PBFT算法通过视图变更(View Change)的方式来处理主节点作恶行为，当发现主节点在作恶时，该算法会以"轮流上岗"的方式推荐新的主节点。另外，尽管PBFT算法相比口信消息型拜占庭之解已经有了很大的优化，如将消息复杂度从O(n^{(f+1))降低为O(n}2)，能在实际场景中落地，以及能解决实际的共识问题等，但PBFT还是有一定的局限，如需要发送比较多的消息，以13节点的集群(f为4)为例，PBFT算法需要涉及如下消息.

1.请求消息:1
2.预准备消息:3f=12
3.准备消息:3f*(3f-f)=96
4.提交消息:(3f-f+1)*(3f+1)=117
5.恢复消息:3f-1=11
也就是说，一次共识协商需要237个消息，消息数还是蛮多的，所以推荐在中小型分布式系统中使用PBFT算法。