PBFT实用拜占庭容错算法详解

分布式架构遭遇的问题

分布式架构会遭遇到以下问题：
1、异构环境的分布式架构首先可能遇到网络传输问题，比如数据丢失、延迟、重复、乱序。
2、欺骗攻击和重播攻击
3、操纵多个失效节点，延迟通讯，制造混乱。

具体到区块链世界，存在同样类似的问题：
区块链是一个分布式账本系统，参与者通过点对点网络连接，所有消息都通过广播的形式来 发送。系统中存在两种角色:普通节点和记账节点。普通节点使用系统来进行转账、交易等操作，并接受账本中的数据;记账节点负责向全网提供记账服务，并维护全局账本。 我们假设在此网络中，消息可能会丢失、损坏、延迟、重复发送，并且接受的顺序与发送的 顺序不一致。此外，节点的行为可以是任意的:可以随时加入、退出网络，可以丢弃消息、 伪造消息、停止工作等，还可能发生各种人为或非人为的故障。
其实这就是拜占庭将军问题。

实用拜占庭容错算法PBFT（Practical Byzantine Fault Tolerance）

为了解决节点故障可能造成对系统的危害，PBFT采用了一种比较简洁的办法。
首先借用一个类比（知乎[Devin Zeng]：
PBFT算法要求至少要4个参与者，一个被选举为军长，3个师长。军长接到总司令命令：你们向前行军500公里。军长就会给3个师长发命令向前行军500公里。3个师长收到消息后会执行命令，并汇报结果。A师长说我在首都以东500公里，B师长说我在首都以东500公里，C师长说我在首都以东250公里。军长总结3个师长的汇报，发现首都以东500公里占多数（2票>1票），所以就会忽略C师长的汇报结果，给总司令汇报说，好了，现在部队是在首都以东500公里了。这就是PBFT算法。

PBFT算法的核心理论是n>=3f+1
n是系统中的总节点数，f是允许出现故障的节点数。换句话说，如果这个系统允许出现f个故障，那么这个系统必须包括n个节点，才能解决故障。

5个概念

client：请求（request）自愿者，上例中指总司令。
replica：副本，所有参与提供服务的节点，上例指军长和师长
primary：承担起提供服务主要职责的节点，上例是军长
backup：其他副本，但相对于primary角色。上例指师长。
view：处于存在primary-bakup场景中的相对稳定的关系，叫视图。
如果primary出现故障，这种相对稳定的视图关系就会