相互共识算法
A. 拜占庭问题与共识算法
“拜占庭将军问题”(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在冰糖橙里运行得非常好。
B. 共识算法系列之一:私链的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