pbft共识算法[pbft共识算法应用于联盟链]

Bitget下载

注册下载Bitget下载，邀请好友，即有机会赢取 3,000 USDT

APP下载   官网注册

pbft共识算法可能是相关行业人士都值得关注的知识，在此对pbft共识算法应用于联盟链进行详细的介绍，并拓展一些相关的知识分享给大家，希望能够为您带来帮助！

根本目的是为了效率；

对比pbft和bft的完成一次共识的消息量就知道了，主节点的存在可以极大降低消息量从而提升效率

实用的拜占庭容错算法

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

部分论文翻译

对数据顺序达成一致共识是很多共识算法要解决的本质问题

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

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

相关内容

标签： 共识过程 拜占庭问题 拜占庭将军