拜占庭容错算法

1. 共识算法都包括了什么算法

下面列出30种共识算法。
1. 工作量证明(PoW，Proof of Work)
2. 权益证明(PoS，Proof of Stake)
3. 延迟工作量证明(dPoW，Delayed Proof-of-Work)
4. 授权 PoS(DPoS，Delegated Proof-of-Stake)
5. 权威证明(PoA，Proof-of-Authority)
6. 权重证明(PoWeight，Proof-of-Weight)
7. 声誉证明(PoR，Proof of Reputation)
8. 所用时间证明(PoET，Proof of Elapsed Time)
9. 容量证明(PoC，Proof of Capacity)，也称为空间证明(PoSpace，Proof of Space)
10. 历史证明(PoHistory，Proof of History)
11. 权益流通证明(PoSV，Proof of Stake Velocity)
12. 重要性证明(PoImportance，Proof of Importance)
13. 烧毁证明(PoBurn，Proof of Burn)
14. 身份证明(PoI，Proof of Identity)
15. 活动证明(PoActivity，Proof Of Activity)
16. 时间证明(PoTime，Proof of Time)
17. 存在证明(PoExistence，Proof of Existence)
18. Ouroboros
19. 可收回证明(PoR，Proof of Retrievability)
20. 拜占庭容错(Byzantine Fault Tolerance)
21. 授权拜占庭容错算法(dBFT，Delegated Byzantine Fault Tolerance)
22. RAFT
23. 恒星共识(Stellar Consensus)
24. 置信度证明(PoB，Proof of Believability)
25. 有向无环图(DAG，Directed Acyclic Graphs)
26. Tangle(IOTA)
27. Hashgraph
28.Holochain
29. Block-Lattice(Nano)
30.SPECTRE

2. 共识算法4 (BFT)

拜占庭将军问题（Byzantine Generals Problem），由Leslie Lamport、Robert Shostak和Marshall Pease，在其同名论文中提出（1982年）。拜占庭将军问题现在主要指分布式对等网络节点间的通信容错问题。在分布式网络中，不同的计节点通过交换信息达成共识。但有时候，系统中的成员节点可能出错而发送错误的信息，用于传递信息的通讯网络也可能导致信息损坏，也可能存在恶意节点或被黑客攻破的节点故意发送错误的信息，从而导致系统无法达成共识或者达成错误的共识。（参考： BFT Wikipedia ）

拜占庭将军问题提出后，有很多的算法被提出用于解决这个问题。这类算法统称拜占庭容错算法（BFT: Byzantine Fault Tolerance）。BFT从上世纪80年代开始被研究，目前已经是一个被研究得比较透彻的理论，具体实现都已经有现成的算法。

BFT算法中最典型的是PBFT（Practical BFT）。PBFT是由Miguel Castro和Barbara Liskov于1999年提出。PBFT算法解决了之前拜占庭容错算法效率不高的问题，将算法复杂度由指数级降低到多项式级，使得拜占庭容错算法在实际系统应用中变得可行。PBFT在保证安全性和可用性的前提下，提供了 (n-1)/3 的容错性。（细节请参考： PBFT ）

PBFT之后，很多进一步提升性能或鲁棒性的BFT算法先后被提出，例如Zyzzyva、ABsTRACTs、Aardvark、RBFT等等。近几年，由于区块链的热度，无数针对区块链应用场景优化过的BFT算法也不断涌现出来。虽然目前PBFT已经不能说是最好的，或最适合区块链的BFT算法。但是PBFT已经足够好了，而且在实际应用中已经非常成熟。

在BFT共识机制中，网络中节点的数量和身份必须是提前确定好的。BFT共识机制无法做到PoW共识机制中实现的任何人都可以随时加入挖矿。另外，BFT算法无法应用到大量的节点，业内普遍认为100个节点是BFT算法的上限。所以BFT算法无法直接用于公有链，BFT算法适合的场景是私有链和联盟链。业内大名鼎鼎的联盟链Hyperledger fabric v0.6采用的是PBFT，v1.0又推出PBFT的改进版本SBFT。这里再顺便提一句，在可信环境下共识算法一般使用传统的分布式一致算法PAXOS或者RAFT。

公有链使用BFT的一个例外是NEO，NEO使用了DBFT（delegated BFT）共识机制。DBFT共识机制下投票选出7个共识节点。这些代理节点是通过静态选出的，并完全由项目方部署。这也是NEO被外界质疑过于中心化的原因。（参考： 早期公有链明星项目-NEO ）

BFT算法和公有链合适的结合点在于基于BFT的PoS共识算法（BFT based PoS）。基于BFT的PoS共识算法要点有：一，网络节点通过锁定虚拟资产申请成为区块链系统的验证者（或矿工）。系统验证者的数量是动态变化的。二，系统从当前验证者中随机选择一个人作为区块提案人。三，系统验证者对区块提案进行投票表决，投票可能要进行多轮才能达成共识。每个人的投票比重与锁定的虚拟资产成比例。

基于BFT的PoS的典型例子是tendermint（Cosmos采用了tendermint作为共识核心）。

3. 共识算法系列之一：私链的raft算法和联盟链的 pbft 算法

对数据顺序达成一致共识是很多共识算法要解决的本质问题
Fabic的pbft算法实现
现阶段的共识算法主要可以分成三大类：公链，联盟链和私链
私链，所有节点可信
联盟链，存在对等的不信任节点
私链：私链的共识算法即区块链这个概念还没普及时的传统分布式系统里的共识算法，比如 zookeeper 的 zab 协议，就是类 paxos 算法的一种。私链的适用环境一般是不考虑集群中存在作恶节点，只考虑因为系统或者网络原因导致的故障节点。

联盟链：联盟链中，经典的代表项目是 Hyperledger 组织下的 Fabric 项目， Fabric0.6 版本使用的就是 pbft 算法。联盟链的适用环境除了需要考虑集群中存在故障节点，还需要考虑集群中存在作恶节点。对于联盟链，每个新加入的节点都是需要验证和审核的。

公链：公链不仅需要考虑网络中存在故障节点，还需要考虑作恶节点，这一点和联盟链是类似的。和联盟链最大的区别就是，公链中的节点可以很自由的加入或者退出，不需要严格的验证和审核。

在公有链中用的最多的是pow算法和pos算法，这些算法都是参与者的利益直接相关，通过利益来制约节点诚实的工作，解决分布式系统中的拜占庭问题。拜占庭容错算法是一种状态机副本复制算法，通过节点间的多轮消息传递，网络内的所有诚实节点就可以达成一致的共识。

使用拜占庭容错算法不需要发行加密货币，但是只能用于私有链或者联盟链，需要对节点的加入进行权限控制；不能用于公有链，因为公有链中所有节点都可以随意加入退出，无法抵挡女巫攻击（sybil attack）

raft 算法包含三种角色，分别是：跟随者（ follower ），候选人（candidate ）和领导者（ leader ）。集群中的一个节点在某一时刻只能是这三种状态的其中一种，这三种角色是可以随着时间和条件的变化而互相转换的。

raft 算法主要有两个过程：一个过程是领导者选举，另一个过程是日志复制，其中日志复制过程会分记录日志和提交数据两个阶段。raft 算法支持最大的容错故障节点是（N-1）/2，其中 N 为 集群中总的节点数量。

国外有一个动画介绍raft算法介绍的很透彻，链接地址为： http://thesecretlivesofdata.com/raft/ 。这个动画主要包含三部分内容，第一部分介绍简单版的领导者选举和日志复制的过程，第二部分内容介绍详细版的领导者选举和日志复制的过程，第三部分内容介绍的是如果遇到网络分区（脑裂），raft 算法是如何恢复网络一致的。

pbft 算法的提出主要是为了解决拜占庭将军问题
要让这个问题有解，有一个 十分重要的前提 ，那就是 信道必须是可靠的 。如果信道不能保证可靠，那么拜占庭问题无解。关于信道可靠问题，会引出两军问题。两军问题的结论是，在一个不可靠的通信链路上试图通过通信以达成一致是基本不可能或者十分困难的。
拜占庭将军问题最早是由 Leslie Lamport 与另外两人在 1982 年发表的论文《The Byzantine Generals Problem 》提出的， 他证明了在将军总数大于 3f ，背叛者为f 或者更少时，忠诚的将军可以达成命令上的一致，即 3f+1<=n 。算法复杂度为 o（n^(f+1)) 。而 Miguel Castro (卡斯特罗)和 Barbara Liskov （利斯科夫）在1999年发表的论文《 Practical Byzantine Fault Tolerance 》中首次提出 pbft 算法，该算法容错数量也满足 3f+1<=n ，算法复杂度为 o（n^2）。

首先我们先来思考一个问题，为什么 pbft 算法的最大容错节点数量是（n-1）/3，而 raft 算法的最大容错节点数量是（n-1）/2 ？

对于raft算法，raft算法的的容错只支持容错故障节点，不支持容错作恶节点。什么是故障节点呢？就是节点因为系统繁忙、宕机或者网络问题等其它异常情况导致的无响应，出现这种情况的节点就是故障节点。那什么是作恶节点呢？作恶节点除了可以故意对集群的其它节点的请求无响应之外，还可以故意发送错误的数据，或者给不同的其它节点发送不同的数据，使整个集群的节点最终无法达成共识，这种节点就是作恶节点。

raft 算法只支持容错故障节点，假设集群总节点数为n，故障节点为 f ，根据小数服从多数的原则，集群里正常节点只需要比 f 个节点再多一个节点，即 f+1 个节点，正确节点的数量就会比故障节点数量多，那么集群就能达成共识。因此 raft 算法支持的最大容错节点数量是（n-1）/2。

对于 pbft 算法，因为 pbft 算法的除了需要支持容错故障节点之外，还需要支持容错作恶节点。假设集群节点数为 N，有问题的节点为 f。有问题的节点中，可以既是故障节点，也可以是作恶节点，或者只是故障节点或者只是作恶节点。那么会产生以下两种极端情况：

第一种情况，f 个有问题节点既是故障节点，又是作恶节点，那么根据小数服从多数的原则，集群里正常节点只需要比f个节点再多一个节点，即 f+1 个节点，确节点的数量就会比故障节点数量多，那么集群就能达成共识。也就是说这种情况支持的最大容错节点数量是 （n-1）/2。
第二种情况，故障节点和作恶节点都是不同的节点。那么就会有 f 个问题节点和 f 个故障节点，当发现节点是问题节点后，会被集群排除在外，剩下 f 个故障节点，那么根据小数服从多数的原则，集群里正常节点只需要比f个节点再多一个节点，即 f+1 个节点，确节点的数量就会比故障节点数量多，那么集群就能达成共识。所以，所有类型的节点数量加起来就是 f+1 个正确节点，f个故障节点和f个问题节点，即 3f+1=n。
结合上述两种情况，因此 pbft 算法支持的最大容错节点数量是（n-1）/3

pbft 算法的基本流程主要有以下四步：

客户端发送请求给主节点
主节点广播请求给其它节点，节点执行 pbft 算法的三阶段共识流程。
节点处理完三阶段流程后，返回消息给客户端。
客户端收到来自 f+1 个节点的相同消息后，代表共识已经正确完成。
为什么收到 f+1 个节点的相同消息后就代表共识已经正确完成？从上一小节的推导里可知，无论是最好的情况还是最坏的情况，如果客户端收到 f+1 个节点的相同消息，那么就代表有足够多的正确节点已全部达成共识并处理完毕了。

3.算法核心三阶段流程
算法的核心三个阶段分别是 pre-prepare 阶段（预准备阶段），prepare 阶段（准备阶段）， commit 阶段（提交阶段）

流程的对比上，对于 leader 选举这块， raft 算法本质是谁快谁当选，而 pbft 算法是按编号依次轮流做主节点。对于共识过程和重选 leader 机制这块，为了更形象的描述这两个算法，接下来会把 raft 和 pbft 的共识过程比喻成一个团队是如何执行命令的过程，从这个角度去理解 raft 算法和 pbft 的区别。

一个团队一定会有一个老大和普通成员。对于 raft 算法，共识过程就是：只要老大还没挂，老大说什么，我们（团队普通成员）就做什么，坚决执行。那什么时候重新老大呢？只有当老大挂了才重选老大，不然生是老大的人，死是老大的鬼。

对于 pbft 算法，共识过程就是：老大向我发送命令时，当我认为老大的命令是有问题时，我会拒绝执行。就算我认为老大的命令是对的，我还会问下团队的其它成员老大的命令是否是对的，只有大多数人 （2f+1） 都认为老大的命令是对的时候，我才会去执行命令。那什么时候重选老大呢？老大挂了当然要重选，如果大多数人都认为老大不称职或者有问题时，我们也会重新选择老大。
四、结语
raft 算法和 pbft 算法是私链和联盟链中经典的共识算法，本文主要介绍了 raft 和 pbft 算法的流程和区别。 raft 和 pbft 算法有两点根本区别：

raft 算法从节点不会拒绝主节点的请求，而 pbft 算法从节点在某些情况下会拒绝主节点的请求 ;
raft 算法只能容错故障节点，并且最大容错节点数为 （n-1）/2 ，而 pbft 算法能容错故障节点和作恶节点，最大容错节点数为 （n-1）/3 。

pbft算法是通过投票来达成共识，可以很好的解决包括分叉等问题的同时提升效率。但仅仅比较适合于联盟链私有链，因为两两节点之间通信量是O(n^2)（通过优化可以减少通信量），一般来说不能应用于超过100个节点。
pbft有解的前提是 信道必须是可靠的 ，存在的问题是 可扩展性（scalability）差

部分来自： https://blog.csdn.net/kojhliang/article/details/80270223
区块链在设计上就是为了BFT

4. 拜占庭协议

拜占庭将军问题是指“在存在消息丢失的不可靠信道上试图通过消息传递的方式达到一致性是不可能的”。因此在系统中存在除了消息延迟或不可送达的故障以外的错误，包括消息被篡改、节点不按照协议进行处理等，将会潜在地会对系统造成针对性的破坏。

改进型实用拜占庭容错 （Practical Byzantine Fault Tolerance/PBFT）

PBET共识机制是少数服从多数，根据信息在分布式网络中节点间互相交换后各节点列出所有得到的信息，一个节点代表一票，选择大多数的结果作为解决办法。PBET将容错量控制在全部节点数的1/3，即如只要有超过2/3的正常节点，整个系统便可正常运作。

授权拜占庭容错算法（Delegated Byzantine Fault Tolerance/dBFT）

dBFT，是基于持有权益比例来选出专门的记账人（记账节点），然后记账人之间通过拜占庭容错算法（即少数服从多数的投票机制）来达成共识，决定动态参与节点。dBFT可以容忍任何类型的错误，且专门的多个记账人使得每一个区块都有最终性、不会分叉。

拜占庭协议采用的方法是确保可以通过分布式的方法达成共识，即使出现了拜占庭式的失败也不会影响。“拜占庭失败”指的则是分布式系统中算法执行过程中的任意一个错误,也包括非理性的行为。

而联邦拜占庭协议的主要特点是权力下放和任意行为容忍：

FBA带来了开放的成员名单以及对拜占庭协议的去中心化控制；

任何人都可以加入其中；

通过分布式的方式，FBA使得法定人数或者节点足够的群体能够达成一致。每个节点决定信任对象，不同的节点也不需要依赖于信赖相同的参与者组合，即可完成共识。

非联邦拜占庭协议的主要特点包括了中心化和任意行为容忍。它要求所有参与者对系统成员资源达成一致共识——这意味着这是一个中心化的系统。网络中的每个节点必须提前知晓且验证过。

和非联盟的拜占庭协议相比，比特币设定理性行为者控制着大多数的计算能力，并通过分发硬币来激励潜在攻击者遵守协议。因此，拜占庭协议可以抵御拥有巨大计算能力的外部攻击者，但是成员名单是非公开的。

而SCP灵感正是来源于比特币。同时它从比特币中汲取经验，同时在低算力环境中扩展了对非理性行为的容忍能力。

5. 拜占庭问题与共识算法

“拜占庭将军问题”（Byzantine Generals Problem）是一个经典难题，这个难题是这样描述的：拜占庭是东罗马帝国的首都，它的军队分成多个师，每个师都由一个将军统领。这些将军通过信使进行交流，来达成一个共同作战方案，有些将军可能是叛徒，想故意破坏这个过程，这会造成那些忠诚的将军也无法达成一个统一的作战计划。这个难题在于如何让那些忠诚的将军在这样的情况下达成统一作战方案，而避免那些叛徒对作战方案的误导。

在点对点、分布式的区块链中，常常用拜占庭问题来比喻节点如何达成共识的问题。将军即对应着一个个节点，达成统一作战方案即达成共识，正确的打包与验证区块数据，防止恶意节点（叛徒将军）破坏区块链的运行。

顾名思义，就是能够解决拜占庭问题，使各个节点达成共识，解决共识问题的各种机制也被称为共识算法。在各种各样的共识算法中，又一直存在一个“不可能三角”的难题，这三角是指“安全性”、“去中心化”和“速度”，也就是说难以同时保证速度、安全性和去中心化程度，三者之间往往会顾此失彼。

现在各种共识算法算起来有好几十种，计算机界也一直处于研究阶段，并没有说哪种算法已经完美。
下面盘点一下讲解pBET和POW两种算法，以及它们的“安全性”、“去中心化”和“速度”如何。

实用拜占庭容错是一种较早的共识算法。pBFT的一个原则，就是少数服从多数。节点通过在相互传递有关决策的消息，谁的决策赞同的人数多，就采用谁的。所以在这个系统中，安全性随着诚实节点的数量而增加。诚实节点同意正确的决策，拒绝恶意节点的错误决策，只要恶意节点的数量少于总数的1/3，就能保证达成共识。

达成共识可以简化为四步：

pBFT 使用投票机制以循环方式选举领导节点。
领导者发起决策并将其广播给辅助节点。
所有节点，包括领导节点和辅助节点，都发送响应。
当 ⅔ + 1 个节点发送相同的响应时，该响应被认为是有效的。

如果领导者有恶意行为，它可以被大多数节点删除。

按少数服从多数的原则。那按理来说，只要恶意节点的数量少于1/2就够了啊，那么为什么PBFT算法的容错数量要满足恶意节点的数量少于总数的1/3呢？

因为 PBFT 算法的除了需要支持容错故障节点之外，还需要支持容错作恶节点。假设集群节点数为 N，有问题的节点为 f。有问题的节点中，可以既是故障节点，也可以是作恶节点，或者只是故障节点或者只是作恶节点。那么会产生以下两种极端情况：

（1）这f 个有问题节点既是故障节点，又是作恶节点，那么根据少数服从多数的原则，集群里正常节点只需要比f个节点再多一个节点，即 f+1 个节点，正确节点的数量就会比故障节点数量多，那么集群就能达成共识，即总节点数为f+(f+1)=n，也就是说这种情况支持的最大容错节点数量是 (n-1)/2。
（2）故障节点和作恶节点都是不同的节点。那么就会有 f 个作恶节点和 f 个故障节点，当发现节点是作恶节点后，会被集群排除在外，剩下 f 个故障节点，那么根据少数服从多数的原则，集群里正常节点只需要比f个节点再多一个节点，即 f+1 个节点，确节点的数量就会比故障节点数量多，那么集群就能达成共识。所以，所有类型的节点数量加起来就是 f+1 个正常节点，f个故障节点和f个作恶节点，即 3f+1=n。

结合上述两种情况，因此PBFT算法支持的最大容错节点数量是(n-1)/3，即少于1/3。

pBFT的优缺点
pBFT 系统不需要高计算资源或大量能源来运行。pBFT 在节点少的时候可以快速达成共识，因为所有节点都在不断地相互通信。一旦节点就决策达成一致，交易就完成了。

然而，pBFT的缺点也很明显：频繁的通信使它只能在节点数量有限的网络中正常工作。随着每个新节点加入网络，通信开销呈指数增长，响应所需的时间也随之增加。

pBFT 网络也容易受到女巫(Sybil)攻击，女巫就是恶意黑客制造的不同节点，黑客可以控制多个节点，使其超过1/3，那系统将无法达成正确的共识。

从不可能三角的角度来看，由此可见pBFT在节点少的时候速度快，但安全性差，去中心化低；节点多了又会导致速度很慢。

中本聪设计了POW共识机制来解决上面pBFT这个经典共识的可扩展性问题。

上面说到，pBFT通过不断广播然后计算节点的消息数，时间花费过长。POW是怎么做的：我不要计算节点数是否超过2/3，我直接选一个节点，按它的决策，其他节点全部同步它的决策。这样就省去在全节点通信然后计算节点数的费时操作。

那么，对于哪个节点来打包区块，那就很重要，万一是恶意节点呢？必须对打包的节点进行要求，哪个节点有权力进行打包呢？那就是解决复杂的数学问题，俗称挖kuang。节点必须花费大量算力和电费来争取某次打包区块的权力。这样的成本就限制了黑客的女巫攻击。

如果打包区块的权力真的被黑客抢到了，那可能会有什么问题？

（1）窃取冰糖橙
黑客能够窃取属于另一个用户，不受她控制的地址里的冰糖橙吗？答案是否定的。即使这一轮是由黑客打包区块链上的下一个区块，她也不可能窃取别人的比特币。这么做的话，黑客需要发起一笔有效的交易来转移比特币到自己的地址。这就要求黑客伪造比特币拥有者的签名，然而如果数字签名机制是安全的，她是无法办到的。只要背后的密码学基础是牢靠的，她就无法轻易窃取比特币。
（2）拒绝服务攻击
让我们来考虑另一种攻击。假设黑客不喜欢叫鲍勃的某个用户，黑客可以决定她不把鲍勃发起的任何交易放进她所提议的区块里。换言之，她拒绝提供服务给鲍勃。尽管这是黑客可以开展的有效的攻击，但幸好这不过是个小问题。如果鲍勃的交易没有被放进黑客所打包的下一个区块，鲍勃只要等到下一个诚实节点发起区块的时候，他的交易记录就会被放进这个区块里。所以这其实也不算是一个有效的攻击。

也就是说，黑客花费重大成本取得的打包，但并不能起到有效的攻击。由于对恶意节点进行惩罚、对诚实节点进行奖励这样的机制下，共识就达成了。

尽管有所改进，POW也引入了其他问题。工作量证明需要所有节点解决复杂的数学问题，这会消耗大量的能源，就是大家所熟知的挖kuang耗费电力。并且解决复杂的数学问题的时间也要求不短，10分钟左右。

从不可能三角的角度来看，POW去中心化高，安全性高，但速度还是慢，但至少已经不会像pBFT那样由于节点多导致花费时间呈指数增长。

共识算法各式各样，冰糖橙的POW并不是真正去解决分布式共识问题，它不能完美的套用到其他场景。但它在货币系统的这个特定场景下解决了冰糖橙的共识问题。POW在冰糖橙里运行得非常好。

6. 拜占庭容错和PBFT共识算法

实用的拜占庭容错算法
BFT 是区块链共识算法中，需要解决的一个核心问题。比特币的POW，eos的dpos，以及共识算法pos，这些公链算法，解决的是共识节点众多情况下的bft问题。

拜占庭将军问题。也称为拜占庭容错。
用来描述分布式系统一致性问题。

背景如下：
拜占庭帝国想要进攻一个强大的敌人，为此派出了10支军队去包围这个敌人。这个敌人虽不比拜占庭帝国，但也足以抵御5支常规拜占庭军队的同时袭击。这10支军队在分开的包围状态下同时攻击。他们任一支军队单独进攻都毫无胜算，除非有至少6支军队（一半以上）同时袭击才能攻下敌国。他们分散在敌国的四周，依靠通信兵骑马相互通信来协商进攻意向及进攻时间。困扰这些将军的问题是，他们不确定他们中是否有叛徒，叛徒可能擅自变更进攻意向或者进攻时间。在这种状态下，拜占庭将军们才能保证有多于6支军队在同一时间一起发起进攻，从而赢取战斗？

单从上面的说明可能无法理解这个问题的复杂性，我们来简单分析一下：

先看在没有叛徒情况下，假如一个将军A提一个进攻提议（如：明日下午1点进攻，你愿意加入吗？）由通信兵通信分别告诉其他的将军，如果幸运中的幸运，他收到了其他6位将军以上的同意，发起进攻。如果不幸，其他的将军也在此时发出不同的进攻提议（如：明日下午2点、3点进攻，你愿意加入吗？），由于时间上的差异，不同的将军收到（并认可）的进攻提议可能是不一样的，这是可能出现A提议有3个支持者，B提议有4个支持者，C提议有2个支持者等等。

再加一点复杂性，在有叛徒情况下，一个叛徒会向不同的将军发出不同的进攻提议（通知A明日下午1点进攻， 通知B明日下午2点进攻等等），一个叛徒也会可能同意多个进攻提议（即同意下午1点进攻又同意下午2点进攻）。

叛徒发送前后不一致的进攻提议，被称为“拜占庭错误”，而能够处理拜占庭错误的这种容错性称为“Byzantine fault tolerance”，简称为BFT。

使用密码学算法保证节点之间的消息传送是不可篡改的， 通过下面的算法我们可以保证A将军收到B将军发来的消息确实是B将军本人的真实请求 。

我们采用的是哈希函数（散列算法）SHA256 -- 从数据（byte）值中创建独一无二的hash值，并压缩成摘要，将数据格式固定下来。通过这个摘要与个人私钥生成Digital Signature 和个人公钥Public-key certificate，接收方验证签名和摘要，如果是通过验证，即证明摘要内容没有经过篡改。

pbft容忍无效或者恶意节点数量 e 。为了保证整个系统可以正常运作，需要有2f+1个正常节点，系统的总结点数为 ：3f+1。即pbft算法容忍小于1/3的恶意或者无效节点。 原因见节点作恶的极端情况

pbft是一种状态机副本复制算法，所有副本在一个view轮换过程中操作，哪些是主节点（进攻的提议者的大将军们，轮流当）通过view中其他节点（其他将军）赋予的编号和节点数集合来确定，即：主节点p=v mod |R| 。 v：view编号，|R|节点个数，p：主节点编号。 关于状态机复制算法、view change的意义（主要是防止主节点作恶），主节点详见论文。

基于拜占庭将军问题，PBFT算法一致性的确保主要分为这三个阶段：预准备（pre-prepare）、准备(prepare)和确认(commit)。流程如下图所示：

[图片上传失败...(image-e3329d-1562488133052)]

首先解释一下上面各个符号表达的意思：

下面结合上图，详细说一下PBFT的步骤：

根据上述流程，在 N ≥ 3F + 1 的情况下一致性是可能解决， N为总计算机数，F为有问题的计算机总数 。

下面所有的校验流程略去对消息内容、签名和身份的验证，即已经保证了节点之间消息传播是不可篡改的

上述算法中，比较重要的一个点是view change，为了能恢复之前的请求，每一个副本节点收到消息之后或者发送消息的时候都会记录消息到本地的log记录中。当执行请求后，副本节点需要把之前该请求的记录消息清除掉。最简单的做法是在reply消息后，在执行一次当前状态的共识同步，但是为了节省资源，一般在多条请求K后执行一次状态同步。这个状态同步就是checkpoint消息。

为了节省内存，系统需要一种将日志中的 无异议消息记录 删除的机制。为了保证系统的安全性，副本节点在删除自己的消息日志前，需要确保至少 f+1 个正常副本节点执行了消息对应的请求，并且可以在视图变更时向其他副本节点证明。另外，如果一些副本节点错过部分消息，但是这些消息已经被所有正常副本节点删除了，这就需要通过 传输部分或者全部服务状态实现该副本节点的同步 。因此，副本节点同样需要证明状态的正确性。

在每一个操作执行后都生成这样的证明是非常消耗资源的。因此，证明过程只有在请求序号可以被某个常数（比如100）整除的时候才会周期性地进行。我们将这些请求执行后得到的状态称作 检查点（checkpoint） ，并且将具有证明的检查点称作 稳定检查点（stable checkpoint） 。

上述情况是理想情况，实际上当副本节点i向其他节点发出checkpoint消息之后，其他节点还没有完成K条请求的相互共识，所以不会立即对i的请求作出响应。其他节点会按照自己的处理步骤和顺序，向前行进和共识。但是此时i发出的checkpoint没有形成stable，为了防止i太快，超过自己太多，于是被便会设置一个高水位H=h+L，其中L就是我们指定允许的高度差，等于checkpoint周期处理数K的整数倍，可以设置为L=2K。当副本节点i处理请求超过高水位H时，副本节点即使接受到请求也会视为非法请求。等待stable checkpoint发生变化，再继续向前推进处理。

如果主节点作恶，它可能会给不同的请求编上相同的序号，或者不去分配序号，或者让相邻请求的序号不连续。备份节点（备份主节点）应当有职责来主动检查这些序号的合法性。如果主节点掉线或者作恶不广播客户端的请求，客户端设置超时机制，超时的话，向所有副本节点广播请求消息。副本节点检测出主节点或者下线，发起view change流程。

我们在上面讲到，当网络中有F台有问题的计算机时，至少需要3F+1台计算机才能保证一致性问题的解决，我们在这里讨论一下原因。

我们可以考虑：由于有F个节点为故障或被攻击的节点，故我们只能从N-F个节点中进行判断。但是由于异步传输，故当收到N-F个消息后，并不能确定后面是否有新的消息。（有可能是目前收到的N-F个节点的消息中存在被攻击的节点发来的消息，而好的节点的消息由于异步传输还没有被收到。）

我们考虑最坏的情况，即剩下F个都是好的节点，收到的中有F个被攻击的节点，故我们需要使得收到的中好节点的数量 (N-F)-F 大于被攻击节点的数量 F ，于是有 N-2F>F ，即 N>3F ，所以N的最小整数为 N=3F+1 。

pbft是需要参与认证的节点进行的。所以一个完整的共识算法包括DPOS+PBFT。其速度是可以达到1500tps左右的。

参考文献：

https://mathpretty.com/9602.html

https://blog.csdn.net/jfkidear/article/details/81275974

Practical Byzantine Fault Tolerance

Miguel Castro and Barbara Liskov Laboratory for Computer Science, Massachusetts Institute of Technology, 545 Technology Square, Cambridge, MA 02139 castro,liskov @lcs .mit.e

https://www.jianshu.com/p/fb5edf031afd 部分论文翻译