实用拜占庭算法原理（PBFT）

一.什么是拜占庭将军问题

拜占庭将军问题(The Byzantine Generals Problem)提供了对分布式共识问题的一种情景化描述,拜占庭将军问题是假设有一个城堡，里边有三个将军，这三个将军遵守少数服从多数原则，统一进行进攻或者撤退。假设三个将军里有一个叛军，其中将军一发出进攻的信号，其他两个将军收到信号后需要回应，并告诉其他人进攻这个信息。反叛的将军二则会传递撤退的信号给其他两人，如此，将军三会收到一个进攻指令，一个撤退指令，导致行动失败。

二.如何解决拜占庭将军问题

解决拜占庭将军问题的方法有很多，今天只介绍PBFT（Practical Byzantine Fault Tolerance），也就是实用拜占庭协议。实用拜占庭协议将三个将军转换成一个将军两个副手，将军就是接受客户端指令的节点，它的作用就是接收客户端指令并构造请求给副手（Pre-prepare消息），副手收到信息后会继续将这个消息传加工后（Prepare消息）给其他人（包括将军），然后在一定时间范围内，如果主节点收到超过 2f 个不同节点的 prepare 消息（具体数量原因在后文），就代表 prepare 阶段已经完成。进入下一阶段，再向其他节点发送消息（Commit消息），当收到 2f+1 个 commit 消息后（包括自己），代表大多数节点已经进入 commit 阶段，这一阶段已经达成共识，于是节点就会执行请求，写入数据。

PBFT的将共识问题分解为小的决策，这些决策由节点按照三个阶段来完成：

• Pre-prepare（预备阶段）： 领导者（primary）将客户端的请求广播给其他节点，其他节点在收到请求后，将请求封装成一个预准备消息，表示该节点认同这个请求。

• Prepare（准备阶段）： 节点在收到超过2f个不同节点的相同预准备消息后，就广播一个准备消息。这个消息表示节点已经看到了足够数量的其他节点也认同了这个请求。

• Commit（提交阶段）： 当一个节点收到超过2f+1个相同的准备消息，它就广播一个提交消息，表示节点确认这个请求可以被执行。一旦节点收到超过2f+1个提交消息，它就会执行请求并将结果返回给客户端。

三.为什么只支持小于三分之一n个节点出现问题？

n是指节点总数，f是指恶意节点，实用拜占庭协议只支持小于n/3的节点出现问题，也就是n>=3f+1。为什么n要大于3f呢？

首先，要满足共识机制要保证，好节点个数应该多于坏节点，有f个坏节点就应该有f+1个数量的节点传递正确消息，所以现在节点规则是n>=2f+1。然而因为假设有f个恶意节点，我们就需要用剩下的n-f个节点来达到共识。主节点收到n-f个信息时就会开始发布下一步的指令，而不是收到全部节点的消息再发布下一阶段指令。好节点可能由于延迟等原因还没把消息传到主节点，但是坏节点已经把消息传到主节点了。也就导致了这n-f个节点里边有可能还有f个坏节点，所以总节点n>=3f+1。 

四.为什么实用拜占庭需要用三步？

为什么实用拜占庭需要用三步？用两步或者一步可不可以？

一步：客户端发送请求到主节点，主节点发送信息给副节点，副节点自己执行请求，如果少于f个副本执行了请求，系统就出现了不一致。

两步：客户端发送请求到主节点，主节点发送pre-pre消息到副节点，副节点收到信息后发送pre信息给其他节点，当节点收到2t+1个pre信息时开始执行客户端需要的命令，此时a节点完成执行，但是其他节点超时，发起view change（更换主节点）命令，a认为已经完成共识，并没有发生view change，新的主节点再次发送同一个请求，那么a节点再执行一次该命令，就会出现问题。