什么是拜占庭将军问题？

区块链共识机制中，常见的一个名词是——拜占庭将军问题。小白每次试图去理解它的时候，百度百科出来的每一个字都认识，但合在一起就觉得晦涩难懂，难以静心看下去。

正是这个心路历程让我有了这篇写作灵感，像小白一样对它复杂的解释缴械投降的人不在少数，想要全面了解区块链，拜占庭将军问题是一个绕不过的门槛，如果小白能通俗易懂的解释拜占庭将军问题，那岂不是为众多小白谋福利（此处也可能是小白想多了，各位看官都能看懂，惟有小白我有点笨，如果误解了各位看官，请海涵）。

哈哈。好，为了这个灵感，我看了二十几篇关于拜占庭将军问题的文章，终于有了一些能让我自圆其说的认识。

首先，明确一点，拜占庭将军问题不是一个真实的故事，而是学者通过虚拟故事描述的分布式节点传输信息时如何保持数据的一致，即共识这个问题。

拜占庭是真实存在的，拜占庭帝国又称东罗马帝国，是欧洲最悠久的君主制国家，军事力量很强大。莱斯利兰伯特，微软研究院的首席研究员，用一个历史上真实的国家虚拟一个故事，本意是想吸引眼球，让更多的人对共识机制产生兴趣，但谁知这个故事讲的也挺复杂，也被演绎了好几个版本，版本中共同的一点是：拜占庭式一个帝国，富有而辽阔的帝国，有10个部队和10个将军，要发动一场战争。接下来有两个主要的版本。

版本一：拜占庭帝国周围有10个小国，每个小国都有部队和将军，这些小国的将军们必须达成共识一半以上同时进攻才能打败拜占庭。

版本二：拜占庭有10支军队、10个将军，一起去攻击强大的敌人。这些军队分散在敌国的周边，需要达成协议至少有6支军队同时进攻才能胜利。

如果单纯从故事的名字来判断，应该是版本二更可靠一些，第二个版本的将军才是拜占庭的将军啊，版本一中的将军不是拜占庭的将军。所以，我们以版本二位蓝本，继续研究下去。

拜占庭将军问题的核心是如何让地位平等的10个将军达成共识同时进攻，确保胜利。每个将军各派9个通信兵发出进攻命令，每个将军将受到来自9个将军的信息“进攻”、“何时进攻”、“不进攻”。9个信息都同意进攻，且进攻时间一致的概率太低，迅速达成共识的可能性基本为零。

本身达成共识的概率就太低，实际应用中还有很多其他难点，（1）距离很远，将军不能聚在一起开会；（2）可能有叛徒；（3）通信兵可能被杀；（4）信息被敌国截获；（5）无法确认消息来源的真实性；（6）将军在商量的过程中浪费时间，贻误战机。重重阻挠，很难让各将军达成共识发动进攻。

拿出现叛徒的事来进行示例。为了更好的解释，先将10个将军简化成3个将军。将军A、将军B、将军C，其中将军B是叛徒。将军A对将军B、C发出进攻的消息，将军B发出不进攻的消息，并同时告诉将军C他收到将军A不进攻的消息。此时的将军C混乱了，他没办法判断将军A到底是要进攻还是不进攻？正是由于上述原因，只要三个将军中出现一个叛徒，即叛徒等于1/3，拜占庭将军问题就不可解决。

拿商量过程太长，贻误战机的因素继续举例。还是三个将军，将军A、将军B、将军C，三个将军中没有叛徒。将军A对将军B、C发出明天下午一点进攻的消息，将军B对将军A、C发出明天上午十点进攻的消息，此时将军C也无所适从，到底选择哪个时间进攻？ 继续将军A发个消息给将军B，我认为下午一点进攻何最合适，原因是……；将军B也发消息给将军A，我认为上午十点进攻最合适，原因是……。等将军A和将军B统一意见，同时再告诉将军C进攻时间时，已经是两天后了。这已经是最简化的模型，没有考虑叛徒和将军C的意见，都如此复杂。

以上只是将问题简化为3个分布式节点，考虑单一因素的影响都很难达成一致，如果节点增多，各种因素交叉影响，那情况将更为复杂。解决这个问题一直没有好的办法。

小结

如果将场景放回现实世界中，那就是一个去中心化的分布式系统，将军们是里面的节点，而节点间通信过程中可能会出现的信息丢失、重复，甚至是内容损坏和篡改问题。如果要让系统运行顺利起来，就需要一个可信的“客观机器”。