共识算法 Consensus protocols

一、 拜占庭将军问题（Byzantine Generals Problem）

拜占庭的n个将军围攻一个敌人，n个将军包围着这个敌人，所以他们是在不同的地方。忠诚的将军希望通过某种协议达成某个命令的一致（比如约定某个时间一起进攻）。但其中一些背叛的将军会通过发送错误的消息阻挠忠诚的将军达成命令上的一致。如果同时发起进攻的将军数量少于m个，那么不足以歼灭敌人反而容易被敌人全部歼灭。怎样做才能保证有多于m个将军在同一时间一起发起进攻？

模型中的两个假设

1. 所有忠诚的将军收到相同的命令后，执行这条命令得到的结果一定是相同的

所有节点对命令的解析和执行是一样的，这个命令必须是一个确定性的命令，不能存在随机性，也不能依赖节点自身的状态。（这个命令不能是心情好就攻击敌人，心情不好就原地休息。）

2. 如果命令是正确的，那么所有忠诚的将军必须执行这条命令。

忠诚的将军需要判断接收到的命令是不是正确的。这个判断命令的方法是整个拜占庭容错技术的核心。

类比于区块链上的共识机制

拜占庭消息误传系指区块链上分散式网络中节点所出现的任何错误（如，伪造签名、恶意破坏系统的一致性、超时、重复发送消息等）。共识机制通常具有容错的设计，即使某些节点失败或是缓慢的，分散式网络中节点的独立处理器仍能达成某种精确的相互一致性。但是共识机制具多样种类且其各自特性，并由小表显示的共识机制基本参数来决定。

来源：https://www.jinse.com/news/blockchain/40493.html

二、 PBFT（Practical Byzantine Fault Tolerance - PBFT）

著名的PBFT算法的核心思想是

对于每一个收到命令的将军，都要去询问其他人，他们收到的命令是什么。不需要判断谁是背叛者——他们只需要执行收到多的那个命令就可以了。采用PBFT方法，本质上就是利用通信次数换取信用。每个命令的执行都需要节点间两两交互去核验消息，通信代价是非常高的。通常采用PBFT算法，节点间的通信复杂度是节点数的平方级的。

共识运作过程

实用拜占庭容错算法（Practical Byzantine Fault Tolerance - PBFT）：讯息在分散式网络中节点间互相交换后，由各节点列出所有得到的信息，以大多数的结果作为解决办法。而在PBFT算法中，主要依据法定多数（quorum）的决定，一个节点代表一票，以少数服从多数的方式实现了拜占庭的容错演算。至多容错量以不超过全部节点数的1/3，意即如果有超过2/3的正常节点，整个系统就便可正常运作(R ≥ 3F + 1; R：节点总数，F：有问题节点总数)。

PBFT算法的运作步骤

1. 取一个副本作为主节点，其他的副本作为备份、

2. 用户端向主节点发送使用服务操作的请求

3. 主节点通过广播将请求发送给其他副本

4. 所有副本执行请求并将结果发回用户端

5. 用户端需要等待F+1个不同副本节点发回相同的结果，作为整个操作的最终结果

来源：https://www.jinse.com/news/blockchain/40493.html

上面所讨论的所有情况里，还有一个假设：所有传递的消息都是口头消息。意思就是，A告诉B下午1点进攻，B可能告诉C说“A命令我下午2点进攻”。如果采用了书写的消息，那么情况是不一样的。A派传令兵给B一张纸，A将军用自己独特的笔迹写的“下午1点进攻”，然后要求B把这张纸传给C，B在纸上用自己独特的笔迹签名表示同意，然后B传给C，C也签名表示同意，然后D也同意，最后签过所有名的纸再给每个人看一眼，就可以让所有节点一致了。这种采用书面签名消息的情况，对算法要求简单得多。但是，采用书面消息的前提是：每个将军都知道其他将军的笔迹是什么样的，并且无法模仿其他将军的笔迹。 

在PBFT的基础上，又出现了很多变种算法，这些算法往往都带有一些额外的假设。例如：认为发起请求的客户端一定是忠诚的，由客户端去验证节点是否忠诚；认为绝大部分时候将军都是忠诚的，所以降低两两交互核验消息的次数；通过对节点进行分工，来提高整个系统的处理速度；等。这些变种算法由于增加了额外的假设，导致了整个系统的去中心化程度的降低（关于区块链系统去中心化程度的理解，可以参见本系列的第6篇文章）。

但是，对于不同类型的应用场景，有些假设是合理的，有些假设则是不合理的。例如，在类似比特币的代币转账系统中，不能认为客户端是忠诚的，因为客户端很可能会发起双花交易。因此，当企业希望使用区块链技术改进自己的业务或者开展新业务的时候，一定要选择适合自己业务的区块链技术和系统。

更多资料：http://baijiahao.baidu.com/s?id=1596184609683656426&wfr=spider&for=pc