[区块链] 拜占庭将军问题 [BFT]

背景：

　　拜占庭将军问题很多人可能听过，但不知道具体是什么意思。那么究竟什么是拜占庭将军问题呢? 本文从最通俗的故事讲起，并对该问题进行抽象，并告诉大家拜占庭将军问题为什么在区块链领域作为一个重点研究问题。

什么是拜占庭将军问题：

　　“拜占庭将军问题”也被称为“拜占庭容错”。

　　拜占庭将军问题是Leslie Lamport（2013年的图灵讲得住）用来为描述分布式系统一致性问题（Distributed Consensus）在论文中抽象出来一个著名的例子。

　　这个例子大意是这样的：

　　拜占庭帝国想要进攻一个强大的敌人，为此派出了10支军队去包围这个敌人。这个敌人虽不比拜占庭帝国，但也足以抵御5支常规拜占庭军队的同时袭击。这10支军队在分开的包围状态下同时攻击。他们任一支军队单独进攻都毫无胜算，除非有至少6支军队（一半以上）同时袭击才能攻下敌国。他们分散在敌国的四周，依靠通信兵骑马相互通信来协商进攻意向及进攻时间。困扰这些将军的问题是，他们不确定他们中是否有叛徒，叛徒可能擅自变更进攻意向或者进攻时间。在这种状态下，拜占庭将军们才能保证有多于6支军队在同一时间一起发起进攻，从而赢取战斗？　

注：“ 拜占庭将军问题中并不去考虑通信兵是否会被截获或无法传达信息等问题，即消息传递的信道绝无问题。Lamport已经证明了在消息可能丢失的不可靠信道上试图通过消息传递的方式达到一致性是不可能的。所以，在研究拜占庭将军问题的时候，已经假定了信道是没有问题的。 ”

通俗分析：

　　单从上面的说明可能无法理解这个问题的复杂性，我们来简单分析一下：

　　先看在没有叛徒情况下，假如一个将军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），使拜占庭协议在分布式系统中应用成为可能。

总结：共识算法的核心就是解决拜占庭将军问题（分布式网络一致性问题）。

REFERENCE

Lamport L，Shostak R，Pease M.The Byzantine generals problem.ACM Trans.on Programming Languages and Systems，1982，4（3）：382-401.
Fischer，M.J.，Lynch，N.A.，Paterson，M.：Impossibility of distributed consensus with one faulty process.J.ACM 32（2），374-382（1985）.
《区块链技术指南》邹均，张海宁，唐屹，李磊著

【时间仓促，如有错误，欢迎指正！ || 欢迎留下您的评语！大家一起探讨、学习区块链!】

【转载请注明出处！http://www.cnblogs.com/X-knight/】