拜占庭将军问题不少人可能听过,但不知道具体是什么意思。那么究竟什么是拜占庭将军问题呢? 本文从最通俗的故事讲起,并对该问题进行抽象,并告诉你们拜占庭将军问题为何在区块链领域做为一个重点研究问题。html
“拜占庭将军问题”也被称为“拜占庭容错”。算法
拜占庭将军问题是Leslie Lamport(2013年的图灵讲得住)用来为描述分布式系统一致性问题(Distributed Consensus)在论文中抽象出来一个著名的例子。服务器
这个例子大意是这样的:网络
拜占庭帝国想要进攻一个强大的敌人,为此派出了10支军队去包围这个敌人。这个敌人虽不比拜占庭帝国,但也足以抵御5支常规拜占庭军队的同时袭击。这10支军队在分开的包围状态下同时攻击。他们任一支军队单独进攻都毫无胜算,除非有至少6支军队(一半以上)同时袭击才能攻下敌国。他们分散在敌国的四周,依靠通讯兵骑马相互通讯来协商进攻意向及进攻时间。困扰这些将军的问题是,他们不肯定他们中是否有叛徒,叛徒可能擅自变动进攻意向或者进攻时间。在这种状态下,拜占庭将军们才能保证有多于6支军队在同一时间一块儿发起进攻,从而赢取战斗? 异步
注:“ 拜占庭将军问题中并不去考虑通讯兵是否会被截获或没法传达信息等问题,即消息传递的信道绝无问题。Lamport已经证实了在消息可能丢失的不可靠信道上试图经过消息传递的方式达到一致性是不可能的。因此,在研究拜占庭将军问题的时候,已经假定了信道是没有问题的。 ”分布式
单从上面的说明可能没法理解这个问题的复杂性,咱们来简单分析一下:post
先看在没有叛徒状况下,假如一个将军A提一个进攻提议(如:明日下午1点进攻,你愿意加入吗?)由通讯兵通讯分别告诉其余的将军,若是幸运中的幸运,他收到了其余6位将军以上的赞成,发起进攻。若是不幸,其余的将军也在此时发出不一样的进攻提议(如:明日下午2点、3点进攻,你愿意加入吗?),因为时间上的差别,不一样的将军收到(并承认)的进攻提议多是不同的,这是可能出现A提议有3个支持者,B提议有4个支持者,C提议有2个支持者等等。性能
再加一点复杂性,在有叛徒状况下,一个叛徒会向不一样的将军发出不一样的进攻提议(通知A明日下午1点进攻, 通知B明日下午2点进攻等等),一个叛徒也会可能赞成多个进攻提议(即赞成下午1点进攻又赞成下午2点进攻)。学习
叛徒发送先后不一致的进攻提议,被称为“拜占庭错误”,而可以处理拜占庭错误的这种容错性称为「Byzantine fault tolerance」,简称为BFT。区块链
求解拜占庭将军问题,隐含要知足如下两个条件:
1)每一个忠诚的将军必须收到相同的命令值vi(vi是第i个将军的命令)。
2)若是第i个将军是忠诚的,那么他发送的命令和每一个忠诚将军收到的vi相同。
因而,拜占庭将军问题的能够描述为:一个发送命令的将军要发送一个命令给其他n-1个将军,使得:
IC1.全部忠诚的接收命令的将军遵照相同的命令;
IC2.若是发送命令的将军是忠诚的,那么全部忠诚的接收命令的将军遵照所接收的命令。
Lamport对拜占庭将军问题的研究代表,当n>3m时,即叛徒的个数m小于将军总数n的1/3时,经过口头同步通讯(假设通讯是可靠的),能够构造同时知足IC1和IC2的解决方案,即将军们能够达成一致的命令。但若是通讯是可认证、防篡改伪造的(如采用PKI认证,消息签名等),则在任意多的叛徒(至少得有两个忠诚将军)的状况下均可以找到解决方案。
而在异步通讯状况下,状况就没有这么乐观。Fischer-Lynch-Paterson定理证实了,只要有一个叛徒存在,拜占庭将军问题就无解。翻译成分布式计算语言,在一个多进程异步系统中,只要有一个进程不可靠,那么就不存在一个协议,此协议能保证有限时间内使全部进程达成一致。
因而可知,拜占庭将军问题在一个分布式系统中,是一个很是有挑战性的问题。由于分布式系统不能依靠同步通讯,不然性能和效率将很是低。所以寻找一种实用的解决拜占庭将军问题的算法一直是分布式计算领域中的一个重要问题。
在这里,咱们先给出分布式计算中有关拜占庭缺陷和故障的两个定义:
定义1:拜占庭缺陷(Byzantine Fault):任何观察者从不一样角度看,表现出不一样症状的缺陷。
定义2:拜占庭故障(Byzantine Failure):在须要共识的系统中因为拜占庭缺陷致使丧失系统服务。
在分布式系统中,不是全部的缺陷或故障都能称做拜占庭缺陷或故障。像死机、丢消息等缺陷或故障不能算为拜占庭缺陷或故障。拜占庭缺陷或故障是最严重缺陷或故障,拜占庭缺陷有不可预测、任意性的缺陷,例如遭黑客破坏,中木马的服务器就是一个拜占庭服务器。
在一个有拜占庭缺陷存在的分布式系统中,全部的进程都有一个初始值。在这种状况下,共识问题(Consensus Problem),就是要寻找一个算法和协议,使得该协议知足如下三个属性。
1)一致性(Agreement):全部的非缺陷进程都必须赞成同一个值。
2)正确性(Validity):若是全部的非缺陷的进程有相同的初始值,那么全部非缺陷的进程所赞成的值必须是同一个初始值。
3)可结束性(Termination):每一个非缺陷的进程必须最终肯定一个值。
根据Fischer-Lynch-Paterson的理论,在异步通讯的分布式系统中,只要有一个拜占庭缺陷的进程,就不可能找到一个共识算法,可同时知足上述要求的一致性、正确性和可结束性要求。在实际状况下,根据不一样的假设条件,有不少不一样的共识算法被设计出来。这些算法各有优点和局限。算法的假设条件有如下几种状况:
1)故障模型:非拜占庭故障/拜占庭故障。
2)通讯类型:同步/异步。
3)通讯网络链接:节点间直连数。
4)信息发送者身份:实名/匿名。
5)通讯通道稳定性:通道可靠/不可靠。
6)消息认证性:认证消息/非认证消息。
在出现比特币以前,解决分布式系统一致性问题主要是Lamport提出的Paxos算法或其衍生算法。Paxos类算法仅适用于中心化的分布式系统,这样的系统的没有不诚实的节点(不会发送虚假错误消息,但容许出现网络不通或宕机出现的消息延迟)。
中本聪在比特币中创造性的引入了“工做量证实(POW : Proof of Work)”来解决这个问题,有兴趣可进一步阅读工做量证实(猛击!)。
经过工做量证实就增长了发送信息的成本,下降节点发送消息速率,这样就以保证在一个时间只有一个节点(或是不多)在进行广播,同时在广播时会附上本身的签名。
这个过程就像一位将军A在向其余的将军(B、C、D…)发起一个进攻提议同样,将军B、C、D…看到将军A签过名的进攻提议书,若是是诚实的将军就会马上赞成进攻提议,而不会发起本身新的进攻提议。
以上就是比特币网络中是单个区块(帐本)达成共识的方法(取得一致性)。
理解了单个区块取得一致性的方法,那么整个区块链(总帐本)若是达成一致也好理解。
咱们稍微把将军问题改一下:
假设攻下一个城堡须要屡次的进攻,每次进攻的提议必须基于以前最屡次数的胜利进攻下提出的(只有这样敌方已有损失最大,我方进攻胜利的可能性就更大),这样约定以后,将军A在收到进攻提议时,就会检查一下这个提议是否是基于最多的胜利提出的,若是不是(基于最多的胜利)将军A就不会赞成这样的提议,若是是的,将军A就会把此次提议记下来。这就是比特币网络最长链选择 (猛击!)。
工做量证实其实至关于提升了作叛徒(发布虚假区块)的成本,在工做量证实下,只有第一个完成证实的节点才能广播区块,竞争难度很是大,须要很高的算力,若是不成功其算力就白白的耗费了(算力是须要成本的),若是有这样的算力做为诚实的节点,一样也能够得到很大的收益(这就是矿工所做的工做),这也实际就不会有作叛徒的动机,整个系统也所以而更稳定。
矿工挖矿得到比特币奖励以及记帐所得的交易费用使得矿工更但愿维护网络的正常运行,而任何破坏网络的非诚信行为都会损害矿工自身的利益。所以,即便有些比特币矿池具有强大的算力,它们都没有做恶的动机,反而有动力维护比特币的正常运行,由于这和它们的切实利益相关。
注:原始的拜占庭容错系统因为须要展现其理论上的可行性而缺少实用性。另外,还须要额外的时钟同步机制支持,算法的复杂度也是随节点增长而指数级增长。实用拜占庭容错系统(PBFT)(猛击!)下降了拜占庭协议的运行复杂度,从指数级别下降到多项式级别(Polynomial),使拜占庭协议在分布式系统中应用成为可能。
总结:共识算法的核心就是解决拜占庭将军问题(分布式网络一致性问题)。
Lamport L,Shostak R,Pease M.The Byzantine generals problem.ACM Trans.on Programming Languages and Systems,1982,4(3):382-401.
【时间仓促,若有错误,欢迎指正! || 欢迎留下您的评语! 你们一块儿探讨、学习区块链!】
【转载请注明出处!http://www.cnblogs.com/X-knight/】