pbft算法（pbft算法原理）

本篇文章给大家谈谈pbft算法，以及pbft算法原理对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、拜占庭容错和PBFT共识算法
• 2、共识算法系列之一：私链的raft算法和联盟链的 pbft 算法
• 3、RAFT与PBFT
• 4、区块链笔记——PBFT
• 5、PBFT共识算法
• 6、共识算法4 (BFT)

拜占庭容错和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-2FF ，即 N3F ，所以N的最小整数为 N=3F+1 。

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

参考文献：

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.edu

部分论文翻译

[img]

共识算法系列之一：私链的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算法介绍的很透彻，链接地址为： 。这个动画主要包含三部分内容，第一部分介绍简单版的领导者选举和日志复制的过程，第二部分内容介绍详细版的领导者选举和日志复制的过程，第三部分内容介绍的是如果遇到网络分裤雹区（脑裂），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）差

部分来自：

区块链在设计上就是为了BFT

RAFT与PBFT

【一．raft算法】

因为网上已经有大量文章对raft算法进行过详细的介绍，因此这部分只会简单的阐述算法的基本原理和流程。raft算法包含三种角色，分别是：跟随者（follower），候选人（candidate）和领导者（leader）。集群中的一个节点在某一时刻只能是这三种状态的其中一种，这三种缓厅隐角色是可以随着时间和条件的变化而互相转换的。

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

国外有一个动画介绍raft算法介绍的很透彻，链接地址在这里[1]。这个动画主要包含三部分内容，第一部分介绍简单版的领导者选举和日志复制的过程，第二部分扰厅内容介绍详细版的领导者选举和日志复制的过程，第三部分内容介绍的是如果遇到网络分区（脑裂），raft算法是如何恢复网络一致的。有兴趣的朋友可以结合这个动画来更好的理解raft算法。

【二．pbft算法】

pbft算法的提出主要是为了解决拜占庭将军问题。什么是拜占庭将军问题呢？拜占庭位于如今的土耳其的伊斯坦布尔，是古代东罗马帝国的首都。拜占庭罗马帝国国土辽阔，为了达到防御目的，每块封地都驻扎一支由将军统领的军队，每个军队都分隔很远，将军与将军之间只能靠信差传递消息。 在战争的时候，拜占庭军队内所有将军必需达成一致的共识，决定是否有赢的机会才去攻打敌人的阵营。但是，在军队内有可能存有叛徒伏禅和敌军的间谍，左右将军们的决定影响将军们达成一致共识。在已知有将军是叛徒的情况下，其余忠诚的将军如何达成一致协议的问题，这就是拜占庭将军问题。

下图列出了raft算法和pbft算法在适用环境，通信复杂度，最大容错节点数和流程上的对比。

关于两个算法的适用环境和最大容错节点数，前文已经做过阐述，这里不再细说。而对于算法通信复杂度，为什么raft是o（n），而pbft是o（n^2）呢？这里主要考虑算法的共识过程。

对于raft算法，核心共识过程是日志复制这个过程，这个过程分两个阶段，一个是日志记录，一个是提交数据。两个过程都只需要领导者发送消息给跟随者节点，跟随者节点返回消息给领导者节点即可完成，跟随者节点之间是无需沟通的。所以如果集群总节点数为 n，对于日志记录阶段，通信次数为n-1，对于提交数据阶段，通信次数也为n-1，总通信次数为2n-2，因此raft算法复杂度为O（n）。

对于pbft算法，核心过程有三个阶段，分别是pre-prepare（预准备）阶段，prepare（准备）阶段和commit（提交）阶段。对于pre-prepare阶段，主节点广播pre-prepare消息给其它节点即可，因此通信次数为n-1；对于prepare阶段，每个节点如果同意请求后，都需要向其它节点再 广播parepare消息，所以总的通信次数为n （n-1），即n^2-n；对于commit阶段，每个节点如果达到prepared状态后，都需要向其它节点广播commit消息，所以总的通信次数也为n （n-1），即n 2-n。所以总通信次数为（n-1）+（n 2-n）+（n 2-n），即2n 2-n-1，因此pbft算法复杂度为O（n^2）。

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

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

对于pbft算法，共识过程就是：老大向我发送命令时，当我认为老大的命令是有问题时，我会拒绝执行。就算我认为老大的命令是对的，我还会问下团队的其它成员老大的命令是否是对的，只有大多数人（2f+1）都认为老大的命令是对的时候，我才会去执行命令。那什么时候重选老大呢？老大挂了当然要重选，如果大多数人都认为老大不称职或者有问题时，我们也会重新选择老大。

区块链笔记——PBFT

PBFT是实用拜占庭容错的简称，是解决拜占庭将军问题的一种方案。比起最开始的BFT算法，PBFT额宏羡液外要求网络封闭，即节点数目确定并提前互通，但将复杂度从指数级降低到多项式级，使得BFT系列算法真正具有可行性。

与POW、POS等大家耳熟能详的共识不同，BFT系列的共识不需要“Proof”，亦即不需要节点投入算力或其他资源来确权，因此不需要代币激励便可完成共识。缺点是原始的BFT效率太低，只能存在于理论而无法应用。而改进的PBFT虽然效率大大提高，却对节点数量和状态提出了要求，导致合格的记帐节点太少，并且也只能维持在少数，过多的节点会拖慢网络速度。因此PBFT更多是用在联盟链和私链上。公链也有应用，例如NEO，便是采用了PBFT算法。

拜占庭将军问题的实质是在恶劣的通讯环境中，如何使各参与方达成一致意见。POW和POS等共识要求参与方投入成本，争夺唯一的发言权。在某一段时间内只有唯一的发言人，自然只会有一个意见，从而达成共识。PBFT采取不同的思路，要求各参与方相互发送及验证彼此的信息，最终采用多数原则达成共识。

PBFT能够以一种低成本的方式实现节点间共识，其理念其实相当贴近我们的生活习惯。例如在老师布置作业后，同学们总要互相问问确认一下，才放心地把今天的作业记到本子上。当然实现上还有很多细节，保证各节点的平等关系。在节点数目不多的时候，节点之间实现相互通信的成本并不高，节点之间可以快速发送确认。但节点数目增长却会带来整体性能的下降。PBFT可蔽物以容忍的坏节点数量不多于总数的三分之一，如果节点损坏率比较固定，提高总节点数量虽然能使系统获得更好的冗余，却会大大增加通讯量，造成效率下降。加上PBFT没有激励机制，其适合联盟链和私链场景。作为公链不可避免地节点数量太少，分布过分集中，例如NEO只有七个节派伍点。

PBFT要求坏节点数量f=(n-1)/3，这里n是总节点数。只要f满足这个条件，共识总是可以达成。为什么f要满足这个条件？简单来说，假设网络中存在恶意节点联盟，其控制了数量为f的节点，这些节点可以故意发布错误的信息。此时网络中正常节点数量为n-f个。将这n-f个节点分为两部分，各自包含一部分节点。对于任一部分正常节点来说，只要恶意节点数f大于自身节点数，同时大于剩余的正常节点数，这部分正常节点便会与恶意节点联盟达成共识。此时只要恶意节点联盟先后向两部分正常节点发送不同的共识信息，便可造成网络分叉。因此要保证网络运行，对于每一部分正常节点来说，网络中恶意节点数量不能同时大于自身节点数和网络剩余正常节点数。代入计算便得到f=(n-1)/3。

PBFT共识算法

Practical Byzantine Fault Tolerance： PBFT，是联盟币的共识算法的基础。实现了在有限个节点的情况下的拜占庭问题，有3f+1的容错性，并同时保证一定的性能。

Primary节点和普通节点，PBFT系统的Primary是轮流当选的，这和zab、raft不一样

Primary节点的作用：

Primary节点孝和拍地位和follower节点一样，并没有什么特权

客户端发起请求--转发请求到primary--primary生成proposal--primary广播proposal--所有节点复制棚告proposal并广播--复制过半节点完成--广播commit节点--commit过半节点完成--应用状态机--反馈客户端--客户端统计f+1个反馈消息--交易完成

解释：

客户端请求消息:客户端直接向Primary节点发巧羡起一个请求 ： 消息的格式REQUEST, o, t, c

服务端在执行request时会进行签名验证，因为PBFT应用的是联盟链，而不是私链，所以要对操作者的身份进行校验，比如A发起一笔转账，则服务端需要check是不是A发起的转账，防止盗刷

服务端回复消息：REPLY, v, t, c, i, r

当普通节点感知到primary异常的时候，触发viewchange，重新选举必须要有2f+1个节点都confirm（VIEW-CHANGE）了，发起重选才生效，一旦超过2f节点都发起VIEW-CHANGE消息，则选举结束，p =v+1 mod |R|节点当选为new Primary。并且new primary会根据自己统计的VIEW-CHANGE的内容,生成并广播NEW-VIEW消息，其它节点验证之后，开始新的view

VIEW-CHANGE, v+1, n, C, P, i消息

NEW-VIEW, v+1, V, O

未完成的PRE-PREPARE消息集合的生成逻辑：

副本节点收到主节点的NEW-VIEW消息，验证有效性（各个replica都统计view-change的个数），有效的话，进入v+1状态，并且开始O中的PRE-PREPARE消息处理流程。

特殊情况：

那么如果一半的节点和primary网络分区了，那也无法发起重选。

同时primary也执行不了新的操作，因为新的消息有一半节点收不到，整个集群陷入瘫痪状态。所以primary也应该和zab一样，具备自我检测超时，超过一定个数的ack缺失时，触发重新选举。

美图架构师 讲PBFT 和Raft区别

原始论文的地址

论文翻译中文版

共识算法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作为共识核心）。

关于pbft算法和pbft算法原理的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。