拜占庭容错和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.edu
https://www.jianshu.com/p/fb5edf031afd 部分论文翻译
区块链的共识机制
一、区块链共识机制的目标
区块链是什么？简单而言，区块链是一种去中心化的数据库，或可以叫作分布式账本(distributed ledger)。传统上所有的数据库都是中心化的，例如一间银行的账本就储存在银行的中心服务器里。中心化数据库的弊端是数据的安全及正确性全系于数据库运营方（即银行），因为任何能够访问中心化数据库的人（如银行职员或黑客）都可以破坏或修改其中的数据。
而区块链技术则容许数据库存放在全球成千上万的电脑上，每个人的账本通过点对点网络进行同步，网络中任何用户一旦增加一笔交易，交易信息将通过网络通知其他用户验证，记录到各自的账本中。区块链之所以得其名是因为它是由一个个包含交易信息的区块（blockquan）从后向前有序链接起来的数据结构。
很多人对区块链的疑问是，如果每一个用户都拥有一个独立的账本，那么是否意味着可以在自己的账本上添加任意的交易信息，而成千上万个账本又如何保证记账的一致性？ 解决记账一致性问题正是区块链共识机制的目标 。区块链共识机制旨在保证分布式系统里所有节点中的数据完全相同并且能够对某个提案（proposal）（例如是一项交易纪录）达成一致。然而分布式系统由于引入了多个节点，所以系统中会出现各种非常复杂的情况；随着节点数量的增加，节点失效或故障、节点之间的网络通信受到干扰甚至阻断等就变成了常见的问题，解决分布式系统中的各种边界条件和意外情况也增加了解决分布式一致性问题的难度。
区块链又可分为三种：
公有链：全世界任何人都可以随时进入系统中读取数据、发送可确认交易、竞争记账的区块链。公有链通常被认为是“完全去中心化“的，因为没有任何人或机构可以控制或篡改其中数据的读写。公有链一般会通过代币机制鼓励参与者竞争记账，来确保数据的安全性。
联盟链：联盟链是指有若干个机构共同参与管理的区块链。每个机构都运行着一个或多个节点，其中的数据只允许系统内不同的机构进行读写和发送交易，并且共同来记录交易数据。这类区块链被认为是“部分去中心化”。
私有链：指其写入权限是由某个组织和机构控制的区块链。参与节点的资格会被严格的限制，由于参与的节点是有限和可控的，因此私有链往往可以有极快的交易速度、更好的隐私保护、更低的交易成本、不容易被恶意攻击、并且能够做到身份认证等金融行业必须的要求。相比中心化数据库，私有链能够防止机构内单节点故意隐瞒或篡改数据。即使发生错误，也能够迅速发现来源，因此许多大型金融机构在目前更加倾向于使用私有链技术。
二、区块链共识机制的分类
解决分布式一致性问题的难度催生了数种共识机制，它们各有其优缺点，亦适用于不同的环境及问题。被众人常识的共识机制有：
l PoW（Proof of Work）工作量证明机制
l PoS（Proof of Stake）股权/权益证明机制
l DPoS（Delegated Proof of Stake）股份授权证明机制
l PBFT（Practical Byzantine Fault Tolerance）实用拜占庭容错算法
l DBFT（Delegated Byzantine Fault Tolerance）授权拜占庭容错算法
l SCP (Stellar Consensus Protocol ) 恒星共识协议
l RPCA（Ripple Protocol Consensus Algorithm）Ripple共识算法
l Pool验证池共识机制
（一）PoW（Proof of Work）工作量证明机制
1. 基本介绍
在该机制中，网络上的每一个节点都在使用SHA256哈希函数(hash function) 运算一个不断变化的区块头的哈希值 (hash sum)。 共识要求算出的值必须等于或小于某个给定的值。 在分布式网络中，所有的参与者都需要使用不同的随机数来持续计算该哈希值，直至达到目标为止。当一个节点的算出确切的值，其他所有的节点必须相互确认该值的正确性。之后新区块中的交易将被验证以防欺诈。
在比特币中，以上运算哈希值的节点被称作“矿工”，而PoW的过程被称为“挖矿”。挖矿是一个耗时的过程，所以也提出了相应的激励机制（例如向矿工授予一小部分比特币）。PoW的优点是完全的去中心化，其缺点是消耗大量算力造成了的资源浪费，达成共识的周期也比较长，共识效率低下，因此其不是很适合商业使用。
2. 加密货币的应用实例
比特币(Bitcoin) 及莱特币(Litecoin)。以太坊(Ethereum) 的前三个阶段（Frontier前沿、Homestead家园、Metropolis大都会）皆采用PoW机制，其第四个阶段 (Serenity宁静) 将采用权益证明机制。PoW适用于公有链。
PoW机制虽然已经成功证明了其长期稳定和相对公平，但在现有框架下，采用PoW的“挖矿”形式，将消耗大量的能源。其消耗的能源只是不停的去做SHA256的运算来保证工作量公平，并没有其他的存在意义。而目前BTC所能达到的交易效率为约5TPS（5笔/秒），以太坊目前受到单区块GAS总额的上限，所能达到的交易频率大约是25TPS，与平均千次每秒、峰值能达到万次每秒处理效率的VISA和MASTERCARD相差甚远。
3. 简图理解模式
（ps：其中A、B、C、D计算哈希值的过程即为“挖矿”，为了犒劳时间成本的付出，机制会以一定数量的比特币作为激励。）
（Ps：PoS模式下，你的“挖矿”收益正比于你的币龄(币的数量*天数)，而与电脑的计算性能无关。我们可以认为任何具有概率性事件的累计都是工作量证明，如淘金。假设矿石含金量为p% 质量, 当你得到一定量黄金时，我们可以认为你一定挖掘了1/p 质量的矿石。而且得到的黄金数量越多，这个证明越可靠。）
（二）PoS（Proof of Stake）股权/权益证明机制
1.基本介绍
PoS要求人们证明货币数量的所有权，其相信拥有货币数量多的人攻击网络的可能性低。基于账户余额的选择是非常不公平的，因为单一最富有的人势必在网络中占主导地位，所以提出了许多解决方案。
在股权证明机制中，每当创建一个区块时，矿工需要创建一个称为“币权”的交易，这个交易会按照一定比例预先将一些币发给矿工。然后股权证明机制根据每个节点持有代币的比例和时间（币龄）， 依据算法等比例地降低节点的挖矿难度，以加快节点寻找随机数的速度，缩短达成共识所需的时间。
与PoW相比，PoS可以节省更多的能源，更有效率。但是由于挖矿成本接近于0，因此可能会遭受攻击。且PoS在本质上仍然需要网络中的节点进行挖矿运算，所以它同样难以应用于商业领域。
2.数字货币的应用实例
PoS机制下较为成熟的数字货币是点点币（Peercoin）和未来币（NXT），相比于PoW，PoS机制节省了能源，引入了" 币天 "这个概念来参与随机运算。PoS机制能够让更多的持币人参与到记账这个工作中去，而不需要额外购买设备（矿机、显卡等）。每个单位代币的运算能力与其持有的时间长成正相关，即持有人持有的代币数量越多、时间越长，其所能签署、生产下一个区块的概率越大。一旦其签署了下一个区块，持币人持有的币天即清零，重新进入新的循环。
PoS适用于公有链。
3.区块签署人的产生方式
在PoS机制下，因为区块的签署人由随机产生，则一些持币人会长期、大额持有代币以获得更大概率地产生区块，尽可能多的去清零他的"币天"。因此整个网络中的流通代币会减少，从而不利于代币在链上的流通，价格也更容易受到波动。由于可能会存在少量大户持有整个网络中大多数代币的情况，整个网络有可能会随着运行时间的增长而越来越趋向于中心化。相对于PoW而言，PoS机制下作恶的成本很低，因此对于分叉或是双重支付的攻击，需要更多的机制来保证共识。稳定情况下，每秒大约能产生12笔交易，但因为网络延迟及共识问题，需要约60秒才能完整广播共识区块。长期来看，生成区块（即清零"币天"）的速度远低于网络传播和广播的速度，因此在PoS机制下需要对生成区块进行"限速"，来保证主网的稳定运行。
4.简图理解模式
（PS：拥有越多“股份”权益的人越容易获取账权。是指获得多少货币，取决于你挖矿贡献的工作量，电脑性能越好，分给你的矿就会越多。）
（在纯POS体系中，如NXT，没有挖矿过程，初始的股权分配已经固定，之后只是股权在交易者之中流转，非常类似于现实世界的股票。）
（三）DPoS（Delegated Proof of Stake）股份授权证明机制
1.基本介绍
由于PoS的种种弊端，由此比特股首创的权益代表证明机制 DPoS（Delegated Proof of Stake）应运而生。DPoS 机制中的核心的要素是选举，每个系统原生代币的持有者在区块链里面都可以参与选举，所持有的代币余额即为投票权重。通过投票，股东可以选举出理事会成员，也可以就关系平台发展方向的议题表明态度，这一切构成了社区自治的基础。股东除了自己投票参与选举外，还可以通过将自己的选举票数授权给自己信任的其它账户来代表自己投票。
具体来说， DPoS由比特股（Bitshares）项目组发明。股权拥有着选举他们的代表来进行区块的生成和验证。DPoS类似于现代企业董事会制度，比特股系统将代币持有者称为股东，由股东投票选出101名代表， 然后由这些代表负责生成和验证区块。 持币者若想称为一名代表，需先用自己的公钥去区块链注册，获得一个长度为32位的特有身份标识符，股东可以对这个标识符以交易的形式进行投票，得票数前101位被选为代表。
代表们轮流产生区块，收益（交易手续费）平分。DPoS的优点在于大幅减少了参与区块验证和记账的节点数量，从而缩短了共识验证所需要的时间，大幅提高了交易效率。从某种角度来说，DPoS可以理解为多中心系统，兼具去中心化和中心化优势。优点：大幅缩小参与验证和记账节点的数量，可以达到秒级的共识验证。缺点：投票积极性不高，绝大部分代币持有者未参与投票；另整个共识机制还是依赖于代币，很多商业应用是不需要代币存在的。
DPoS机制要求在产生下一个区块之前，必须验证上一个区块已经被受信任节点所签署。相比于PoS的" 全民挖矿 "，DPoS则是利用类似" 代表大会 "的制度来直接选取可信任节点，由这些可信任节点（即见证人）来代替其他持币人行使权力，见证人节点要求长期在线，从而解决了因为PoS签署区块人不是经常在线而可能导致的产块延误等一系列问题。 DPoS机制通常能达到万次每秒的交易速度，在网络延迟低的情况下可以达到十万秒级别，非常适合企业级的应用。 因为公信宝数据交易所对于数据交易频率要求高，更要求长期稳定性，因此DPoS是非常不错的选择。
2. 股份授权证明机制下的机构与系统
理事会是区块链网络的权力机构，理事会的人选由系统股东（即持币人）选举产生，理事会成员有权发起议案和对议案进行投票表决。
理事会的重要职责之一是根据需要调整系统的可变参数，这些参数包括：
l 费用相关：各种交易类型的费率。
l 授权相关：对接入网络的第三方平台收费及补贴相关参数。
l 区块生产相关：区块生产间隔时间，区块奖励。
l 身份审核相关：审核验证异常机构账户的信息情况。
l 同时，关系到理事会利益的事项将不通过理事会设定。
在Finchain系统中，见证人负责收集网络运行时广播出来的各种交易并打包到区块中，其工作类似于比特币网络中的矿工，在采用 PoW(工作量证明)的比特币网络中，由一种获奖概率取决于哈希算力的抽彩票方式来决定哪个矿工节点产生下一个区块。而在采用 DPoS 机制的金融链网络中，通过理事会投票决定见证人的数量，由持币人投票来决定见证人人选。入选的活跃见证人按顺序打包交易并生产区块，在每一轮区块生产之后，见证人会在随机洗牌决定新的顺序后进入下一轮的区块生产。
3. DPoS的应用实例
比特股(bitshares) 采用DPoS。DPoS主要适用于联盟链。
4.简图理解模式
（四）PBFT（Practical Byzantine Fault Tolerance）实用拜占庭容错算法
1. 基本介绍
PBFT是一种基于严格数学证明的算法，需要经过三个阶段的信息交互和局部共识来达成最终的一致输出。三个阶段分别为预备 (pre-prepare)、准备 (prepare)、落实 (commit)。PBFT算法证明系统中只要有2/3比例以上的正常节点，就能保证最终一定可以输出一致的共识结果。换言之，在使用PBFT算法的系统中，至多可以容忍不超过系统全部节点数量1/3的失效节点 (包括有意误导、故意破坏系统、超时、重复发送消息、伪造签名等的节点，又称为”拜占庭”节点)。
2. PBFT的应用实例
著名联盟链Hyperledger Fabric v0.6采用的是PBFT，v1.0又推出PBFT的改进版本SBFT。PBFT主要适用于私有链和联盟链。
3. 简图理解模式
上图显示了一个简化的PBFT的协议通信模式，其中C为客户端，0 – 3表示服务节点，其中0为主节点，3为故障节点。整个协议的基本过程如下：
(1) 客户端发送请求，激活主节点的服务操作；
(2) 当主节点接收请求后，启动三阶段的协议以向各从节点广播请求；
(a) 序号分配阶段，主节点给请求赋值一个序号n，广播序号分配消息和客户端的请求消息m，并将构造pre-prepare消息给各从节点；
(b) 交互阶段，从节点接收pre-prepare消息，向其他服务节点广播prepare消息；
(c) 序号确认阶段，各节点对视图内的请求和次序进行验证后，广播commit消息，执行收到的客户端的请求并给客户端响应。
(3) 客户端等待来自不同节点的响应，若有m+1个响应相同，则该响应即为运算的结果；
（五）DBFT（Delegated Byzantine Fault Tolerance）授权拜占庭容错算法
1. 基本介绍
DBFT建基于PBFT的基础上，在这个机制当中，存在两种参与者，一种是专业记账的“超级节点”，一种是系统当中不参与记账的普通用户。普通用户基于持有权益的比例来投票选出超级节点，当需要通过一项共识（记账）时，在这些超级节点中随机推选出一名发言人拟定方案，然后由其他超级节点根据拜占庭容错算法（见上文），即少数服从多数的原则进行表态。如果超过2/3的超级节点表示同意发言人方案，则共识达成。这个提案就成为最终发布的区块，并且该区块是不可逆的，所有里面的交易都是百分之百确认的。如果在一定时间内还未达成一致的提案，或者发现有非法交易的话，可以由其他超级节点重新发起提案，重复投票过程，直至达成共识。
2. DBFT的应用实例
国内加密货币及区块链平台NEO是 DBFT算法的研发者及采用者。
3. 简图理解模式
假设系统中只有四个由普通用户投票选出的超级节点，当需要通过一项共识时，系统就会从代表中随机选出一名发言人拟定方案。发言人会将拟好的方案交给每位代表，每位代表先判断发言人的计算结果与它们自身纪录的是否一致，再与其它代表商讨验证计算结果是否正确。如果2/3的代表一致表示发言人方案的计算结果是正确的，那么方案就此通过。
如果只有不到2/3的代表达成共识，将随机选出一名新的发言人，再重复上述流程。这个体系旨在保护系统不受无法行使职能的领袖影响。
上图假设全体节点都是诚实的，达成100%共识，将对方案A（区块）进行验证。
鉴于发言人是随机选出的一名代表，因此他可能会不诚实或出现故障。上图假设发言人给3名代表中的2名发送了恶意信息（方案B），同时给1名代表发送了正确信息（方案A）。
在这种情况下该恶意信息（方案B）无法通过。中间与右边的代表自身的计算结果与发言人发送的不一致，因此就不能验证发言人拟定的方案，导致2人拒绝通过方案。左边的代表因接收了正确信息，与自身的计算结果相符，因此能确认方案，继而成功完成1次验证。但本方案仍无法通过，因为不足2/3的代表达成共识。接着将随机选出一名新发言人，重新开始共识流程。
上图假设发言人是诚实的，但其中1名代表出现了异常；右边的代表向其他代表发送了不正确的信息（B）。
在这种情况下发言人拟定的正确信息（A）依然可以获得验证，因为左边与中间诚实的代表都可以验证由诚实的发言人拟定的方案，达成2/3的共识。代表也可以判断到底是发言人向右边的节点说谎还是右边的节点不诚实。
（六）SCP (Stellar Consensus Protocol ) 恒星共识协议
1. 基本介绍
SCP 是 Stellar (一种基于互联网的去中心化全球支付协议) 研发及使用的共识算法，其建基于联邦拜占庭协议 (Federated Byzantine Agreement) 。传统的非联邦拜占庭协议（如上文的PBFT和DBFT）虽然确保可以通过分布式的方法达成共识，并达到拜占庭容错 (至多可以容忍不超过系统全部节点数量1/3的失效节点)，它是一个中心化的系统 — 网络中节点的数量和身份必须提前知晓且验证过。而联邦拜占庭协议的不同之处在于它能够去中心化的同时，又可以做到拜占庭容错。
[…]
（七）RPCA（Ripple Protocol Consensus Algorithm）Ripple共识算法
1. 基本介绍
RPCA是Ripple（一种基于互联网的开源支付协议，可以实现去中心化的货币兑换、支付与清算功能）研发及使用的共识算法。在 Ripple 的网络中，交易由客户端（应用）发起，经过追踪节点（tracking node）或验证节点（validating node）把交易广播到整个网络中。追踪节点的主要功能是分发交易信息以及响应客户端的账本请求。验证节点除包含追踪节点的所有功能外，还能够通过共识协议，在账本中增加新的账本实例数据。
Ripple 的共识达成发生在验证节点之间，每个验证节点都预先配置了一份可信任节点名单，称为 UNL（Unique Node List）。在名单上的节点可对交易达成进行投票。共识过程如下：
(1) 每个验证节点会不断收到从网络发送过来的交易，通过与本地账本数据验证后，不合法的交易直接丢弃，合法的交易将汇总成交易候选集（candidate set）。交易候选集里面还包括之前共识过程无法确认而遗留下来的交易。
(2) 每个验证节点把自己的交易候选集作为提案发送给其他验证节点。
(3) 验证节点在收到其他节点发来的提案后，如果不是来自UNL上的节点，则忽略该提案；如果是来自UNL上的节点，就会对比提案中的交易和本地的交易候选集，如果有相同的交易，该交易就获得一票。在一定时间内，当交易获得超过50%的票数时，则该交易进入下一轮。没有超过50%的交易，将留待下一次共识过程去确认。
(4) 验证节点把超过50%票数的交易作为提案发给其他节点，同时提高所需票数的阈值到60%，重复步骤(3)、步骤(4)，直到阈值达到80%。
(5) 验证节点把经过80%UNL节点确认的交易正式写入本地的账本数据中，称为最后关闭账本（last closed ledger），即账本最后（最新）的状态。
在Ripple的共识算法中，参与投票节点的身份是事先知道的，因此，算法的效率比PoW等匿名共识算法要高效，交易的确认时间只需几秒钟。这点也决定了该共识算法只适合于联盟链或私有链。Ripple共识算法的拜占庭容错（BFT）能力为（n-1）/5，即可以容忍整个网络中20%的节点出现拜占庭错误而不影响正确的共识。
2. 简图理解模式
共识过程节点交互示意图：
共识算法流程：
（八）POOL验证池共识机制
Pool验证池共识机制是基于传统的分布式一致性算法（Paxos和Raft）的基础上开发的机制。Paxos算法是1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。过去, Paxos一直是分布式协议的标准，但是Paxos难于理解，更难以实现。Raft则是在2013年发布的一个比Paxos简单又能实现Paxos所解决问题的一致性算法。Paxos和Raft达成共识的过程皆如同选举一样，参选者需要说服大多数选民(服务器)投票给他，一旦选定后就跟随其操作。Paxos和Raft的区别在于选举的具体过程不同。而Pool验证池共识机制即是在这两种成熟的分布式一致性算法的基础上，辅之以数据验证的机制。
共识算法系列之一:私链的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
首先我们先来思考一个问题，为什么 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
区块链笔记——PBFT
PBFT是实用拜占庭容错的简称，是解决拜占庭将军问题的一种方案。比起最开始的BFT算法，PBFT额外要求网络封闭，即节点数目确定并提前互通，但将复杂度从指数级降低到多项式级，使得BFT系列算法真正具有可行性。
与POW、POS等大家耳熟能详的共识不同，BFT系列的共识不需要“Proof”，亦即不需要节点投入算力或其他资源来确权，因此不需要代币激励便可完成共识。缺点是原始的BFT效率太低，只能存在于理论而无法应用。而改进的PBFT虽然效率大大提高，却对节点数量和状态提出了要求，导致合格的记帐节点太少，并且也只能维持在少数，过多的节点会拖慢网络速度。因此PBFT更多是用在联盟链和私链上。公链也有应用，例如NEO，便是采用了PBFT算法。
拜占庭将军问题的实质是在恶劣的通讯环境中，如何使各参与方达成一致意见。POW和POS等共识要求参与方投入成本，争夺唯一的发言权。在某一段时间内只有唯一的发言人，自然只会有一个意见，从而达成共识。PBFT采取不同的思路，要求各参与方相互发送及验证彼此的信息，最终采用多数原则达成共识。
PBFT能够以一种低成本的方式实现节点间共识，其理念其实相当贴近我们的生活习惯。例如在老师布置作业后，同学们总要互相问问确认一下，才放心地把今天的作业记到本子上。当然实现上还有很多细节，保证各节点的平等关系。在节点数目不多的时候，节点之间实现相互通信的成本并不高，节点之间可以快速发送确认。但节点数目增长却会带来整体性能的下降。PBFT可以容忍的坏节点数量不多于总数的三分之一，如果节点损坏率比较固定，提高总节点数量虽然能使系统获得更好的冗余，却会大大增加通讯量，造成效率下降。加上PBFT没有激励机制，其适合联盟链和私链场景。作为公链不可避免地节点数量太少，分布过分集中，例如NEO只有七个节点。
PBFT要求坏节点数量f
拜占庭容错和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.edu
https://www.jianshu.com/p/fb5edf031afd 部分论文翻译
区块链方面哪家做的好?
房产区块链这方面还是兰房链平台做的好，为房地产全行业提供高效、可信任、优质的线 上运营管理服务，你要是有用过它们的区块链技术，就会知道，各方面表现相当突出
共识算法系列之一:私链的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
首先我们先来思考一个问题，为什么 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