如何用数学方法解决拜占庭将军问题

1. 拜占庭问题

拜占庭帝国即中世纪的土耳其，拥有巨大的财富，周围10个邻邦垂诞已久，但拜占庭高墙耸立，固若金汤，没有一个单独的邻邦能够成功入侵。任何单个邻邦入侵的都会失败，同时也有可能自身被其他9个邻邦入侵。拜占庭帝国防御能力如此之强，至少要有十个邻邦中的一半以上同时进攻，才有可能攻破。

然而，如果其中的一个或者几个邻邦本身答应好一起进攻，但实际过程出现背叛，那么入侵者可能都会被歼灭。

于是每一方都小心行事，不敢轻易相信邻国。这就是拜占庭将军问题。

在拜占庭问题中，最重要的point就是： 所有将军如何达成一致攻打拜占庭的共识 ，这当中，可能出现的情况举例如下：

用一个模型解释一下：

假设只有3个人，A、B、C，三人中如果其中一个是叛徒。当A发出进攻命令时，B如果是叛徒，他可能告诉C，他收到的是“撤退”的命令。这时C收到一个“进攻”，一个“撤退“，于是C被信息迷惑，而无所适从。

如果A是叛徒。他告诉B“进攻”，告诉C“撤退”。当C告诉B，他收到“撤退”命令时，B由于收到了司令“进攻”的命令，而无法与C保持一致。

正由于上述原因，在只有三个角色的系统中，只要有一个是叛徒，即叛徒数等于1/3，拜占庭问题便不可解。

可以看得出， 只要叛徒的数量大于或等于1/3，拜占庭问题不可解

从技术上理解， 拜占庭将军问题是分布式系统容错性问题 。加密货币建立在P2P网络之上，是典型的分布式系统，类比一下， 将军就是P2P网络中的节点，信使就是节点之间的通信，进攻还是撤退的决定就是需要达成的共识 。 如果某台独立的节点计算机拓机、掉线或攻击网络搞破坏，整个系统就要停止运行，那这样的系统将非常脆弱，所以容许部分节点出错或搞破坏而不影响整个系统运行是必要的 ， 这就需要算法理论上的支撑，保证分布式系统在一定量的错误节点存在的情况下，仍然保持一致性和可用性 。

而且，拜占庭将军与两军问题不同，前者假定信差没有问题，只是将军出现了叛变等问题；后者研究信差的通信问题。

终极解决方案到了——

如果 10个将军中的几个同时发起消息，势必会造成系统的混乱，造成各说各的攻击时间方案，行动难以一致 。

谁都可以发起进攻的信息，但由谁来发出呢？中本聪巧妙地在个系统加入了 发送信息的成本 ，即：

它加入的 成本就是”工作量“ —— 节点必须完成一个计算工作才能向各城邦传播消息 ，当然，谁第一个完成工作，谁才能传播消息。（这也是 工作量证明机制的意义：以检验结果的方式证明你过去所做过了多少工作 ）

这种加密技术——非对称加密，完全可以解决古代难以解决的签名问题：

中本聪在设计比特币时，它采用了一种工作量证明机制叫哈希现金，在一个交易块这要找到一个随机数，计算机只能用穷举法来找到这个随机数，可以说，能不能找到全靠运气，所以对于各个节点来说，这个世界上，只有随机才是真正的公平，实现随机的最好办法是使用数学，所有的将军在寻找共识的过程，借助了大家都认可的数学逻辑。

当然了， 凭什么要义务进行计算工作，那么肯定要有一个激励机制 ：比特币的奖励机制是每打包一个块，目前是奖励25个比特币，而拜占庭将军问题的奖励机制可以是瓜分拜占庭获得的利益。

在这个分布式网络里：

每个将军都有一份实时与其他将军同步的消息账本 。
账本里有每个将军的签名都是可以验证身份的。 如果有哪些消息不一致，可以知道消息不一致的是哪些将军 。
尽管有消息不一致的，只要超过半数同意进攻，少数服从多数，共识达成（只要大多数是好人，那么就可以实现共识）。

区块链上的共识机制主要解决 由谁来构造区块 ，以及 如何维护区块链统一 的问题。

拜占庭容错问题需要解决的也同样是 谁来发起信息 ，如何 实现信息的统一同步 的问题。

注：区块链学习新人，若有不正确的地方，望指出

2. 理论上区块链怎么解决拜占庭将军问题

拜占庭将军问题（以下简称“共识问题”）的正式表述是：如何在一个不基于信任的分布式网络中就信息达成共识？这个表述听起来有些晦涩，但其本质并不复杂，下面的例子与共识问题虽然并不完全一致，但却有助于我们的理解[9]。

想象一下在遥远的拜占庭时代，有一个富饶的城邦，金银珠宝绫罗绸缎应有尽有，它的领主哆啦A梦独享着这一切奢华与荣耀。而在城邦的外围，四位拜占庭将军大雄、胖虎、小夫和静香都觊觎着哆啦A梦的财富，于是他们决定联手攻占哆啦A梦的城邦。根据双方的实力对比，必须有超过半数的将军同时发起进攻方能克敌制胜，因此获胜条件就是四人中至少三个人可以就进攻时间达成一致。那么四位将军的胜算有多少呢？

这个问题的答案就要取决于四个人的合作方式了，如果是集中式系统，有一个盟主，比如胖虎（相当于中央服务器），那么他们的胜利是毫无悬念的，因为就进攻时间达成一致非常简单，只要胖虎召集大雄、小夫和静香开个会讨论一下就可以了，即使大家意见有分歧胖虎也可以在最后予以定夺。下面让我们回到拜占庭将军问题的假设里，在不基于信任的分布式网络中，四位将军的胜算又如何呢？

?

首先由于四位将军之间缺乏信任，因此聚到小黑屋里开个密谋会的可能性被排除了（一旦在小黑屋里被胖虎绑架了怎么办？）；其次由于没有盟主，四个人的意见都会被同等的看重。在这种情况下，四位将军只能通过信使在各自营地之间传递消息，来商定进攻时间了。比如大雄觉得早上6点是发动进攻的好时机，他就会派信使将自己的意见告诉胖虎、小夫和静香，与此同时，胖虎可能认为晚上9点发动突袭更好，小夫更喜欢下午3点出击，而静香希望是上午10点，他们三人也会在同一时间派出自己的信使。这样一来，在第一轮通信结束后，四位将军每个人都有了四个可供选择的进攻时间，他们各自要在下一轮通信中把自己选定的时间告知另外三人。由于四个人的决策都是独立做出的，因此最终的选择结果就有256种可能，而只有当三人以上都恰好选择了同一时间的时候，共识才被达成，而这样的结果才64种，也就是说达成共识的概率仅为1/4。这还只是四位将军的情况，如果将军的人数是10人，100人，1000人呢？我们稍加计算就可以发现随着人数的增加，达成共识的希望会变得越来越渺茫。

把上面例子中的将军换成计算机网络中的节点，把信使换成节点之间的通信，把进攻时间换成需要达成共识的信息，你就可以理解共识问题所描述的困境了。达成共识的能力对于一个支付系统来说重要性不言而喻，如果你给家里汇了一笔钱买车，第二天去银行核实的时候柜台告诉你“关于你汇了多少钱的问题，我们的系统里有三个版本的记录”，这样的银行你显然是不敢把钱存进去的。在比特币出现之前共识问题是很难被完美解决的，要保证达成共识就需要采用集中式系统（除非节点满足特定条件），要想去中心化共识就无法保证。那么区块链技术又是如何解决这一难题的呢？（关注公众号weoption，回复“区块链”，可查看全文。）

3. 如何理解拜占庭将军问题

拜占庭将军问题（Byzantine failures），是由莱斯利·兰伯特提出的点对点通信中的基本问题。含义是在存在消息丢失的不可靠信道上试图通过消息传递的方式达到一致性是不可能的。因此对一致性的研究一般假设信道是可靠的，或不存在本问题。
拜占庭位于如今的土耳其的伊斯坦布尔，是东罗马帝国的首都。由于当时拜占庭罗马帝国国土辽阔，为了防御目的，因此每个军队都分隔很远，将军与将军之间只能靠信差传消息。 在战争的时候，拜占庭军队内所有将军和副官必需达成一致的共识，决定是否有赢的机会才去攻打敌人的阵营。但是，在军队内有可能存有叛徒和敌军的间谍，左右将军们的决定又扰乱整体军队的秩序。在进行共识时，结果并不代表大多数人的意见。这时候，在已知有成员谋反的情况下，其余忠诚的将军在不受叛徒的影响下如何达成一致的协议，拜占庭问题就此形成。
拜占庭将军问题是一个协议问题，拜占庭帝国军队的将军们必须全体一致的决定是否攻击某一支敌军。问题是这些将军在地理上是分隔开来的，并且将军中存在叛徒。叛徒可以任意行动以达到以下目标：欺骗某些将军采取进攻行动；促成一个不是所有将军都同意的决定，如当将军们不希望进攻时促成进攻行动；或者迷惑某些将军，使他们无法做出决定。如果叛徒达到了这些目的之一，则任何攻击行动的结果都是注定要失败的，只有完全达成一致的努力才能获得胜利。
拜占庭假设是对现实世界的模型化，由于硬件错误、网络拥塞或断开以及遭到恶意攻击，计算机和网络可能出现不可预料的行为。拜占庭容错协议必须处理这些失效，并且这些协议还要满足所要解决的问题要求的规范。这些算法通常以其弹性t作为特征，t表示算法可以应付的错误进程数。
很多经典算法问题只有在n ≥ 3t+1时才有解，如拜占庭将军问题，其中n是系统中进程的总数。

4. 如何理解拜占庭将军问题

-----------------[简单理解]-----------------
因为Lamport是分布式系统祖师爷级的人物，所以我就从分布式系统的角度来说。如果要保证分布式系统一致性和可用性，就必须处理错误节点，防止系统出现用户可以观察到的错误。拜占庭将军问题在我看来是提出了一个错误模型。即错误节点可以做任意事情（不受protocol限制），比如不响应、发送错误信息、对不同节点发送不同决定、不同错误节点联合起来干坏事等等。总之就是说，没有节点会出现比这更严重的错误。很显然，拜占庭错误是overly pessimistic的模型，因为这种错误实际环境中比较少见。那么为什么要研究这个模型呢？其中最简单的一个原因是，如果某个一致性算法能够保证在系统出现f个拜占庭错误时保持系统一致，那么这个算法也就能够保证在出现f个任意其他错误的时候也保持系统一致。错误模型有上限，肯定也就有一个下限（overly optimistic，没有比它还要弱的模型）。这个下限就是‘fail-stop’模型。这个模型的假设是：当一个节点出错，这个节点会停止运行，并且其他所有节点都知道这个节点发生了错误。用同样的逻辑，如果某个一致性算法不能保证在系统出现f个错误的时候保持一致，那么这个算法也就没法处理其他f个任意其他问题。应用这些错误模型，可以对不同算法进行比较，也可以对具体算法的cost进行讨论。

-----------------[关于算法]-----------------
第一个提出解决拜占庭将军问题算法的，是Lamport于1980年发表的 Reaching agreement in the presence of faults [http://research.microsoft.com/en-us/um/people/lamport/pubs/reaching.pdf]。这篇文章描述了当出现拜占庭错误的节点数（f）为1时的算法。上面匿名用户贴的链接是Lamport与1982年发表的文章，其中描述了第一个能够处理f≥1的算法。对这个问题的下一个进展是在1999年，是由Barbara Liskov（三位女性图灵奖获得者之一）提出。但是，具体列出这个进展之前，需要提一下拜占庭将军问题和FLP定理之间的关系。除了错误模型，系统一致性的另一个重要方面是讨论在不同系统假设（通信异步/同步，任务完成时间有没有规定上限）下达成一致性的可能性和相应算法/协议。由于FLP（Impossibility of Distributed Consensus with One Faulty Process）决定了在异步+无响应上限的情况下不存在能够mask一个节点崩溃（强于fail-stop，节点崩溃，其他节点不知情）的有效算法。所以解决拜占庭问题的算法都会有同步假设（或者同步保证safety，或者同步保证liveness）。

5. 拜占庭问题与共识算法

“拜占庭将军问题”（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在冰糖橙里运行得非常好。

6. 拜占庭将军问题的解决算法

拜占庭问题的最初描述是：n 个将军被分隔在不同的地方，忠诚的将军希望通过某种协议达成某个命令的一致（比如一起进攻或者一起后退）。但其中一些背叛的将军会通过发送错误的消息阻挠忠诚的将军达成命令上的一致。Lamport 证明了在将军总数大于3m ，背叛者为m 或者更少时，忠诚的将军可以达成命令上的一致。
为了保证上面的需求，必须满足下面两个条件：
1. 每两个忠诚的将军必须收到相同的值 v(i)（v(i)是第i 个将军的命令）
2. 如果第i 个将军是忠诚的，那么他发送的命令和每个忠诚将军收到的v(i)相同
为了简化以上模型，我们使用一个将军发送命令给多个副官的形式来证明，发送命令的将军称为发令者，接收命令的将军为副官，那么上面的两个条件可以表述为：
IC1. 所有忠诚的副官遵守相同的命令
IC2. 如果发出命令的将军是忠诚的，那么所有忠诚的副官遵守司令（发出命令的将军）的命令
特别提示：发送命令的每次只有一个将军，将其命令发送给n-1 个副官。m 代表叛国者的个数，因为将军总数为n，所以副官总数为n-1 个。IC2 中副官遵守实际上是指忠诚的将军能够正确收到忠诚将军的命令消息。 通过口头消息传递达到一致，如果有m 个叛国将军，则将军们的总数必须为3m+1 个以上。下面是口头消息传递过程中默认的一些条件：
A1. 每个被发送的消息都能够被正确的投递
A2. 信息接收者知道是谁发送的消息
A3. 能够知道缺少的消息
A1 和A2 假设了两个将军之间通信没有干扰，既不会有背叛者阻碍消息的发送（截断）也不会有背叛者伪造消息的情况（伪造）。即是每个将军都可以无误地将自己的消息发送给其他每个将军。（下一节中可以不需要这个必要条件）
我们定义口头消息算法OM(m) 。对于所有的非负整数m ，每个发令者通过OM(M) 算法发送命令给n-1 个副官。下面将说明OM(m) 算法在最多有m 个背叛者且总将军数为3m+1 或者更多的情况下可以解决拜占庭将军问题。（考虑到网络应用实际环境，原文使用了收到值代替收到命令，本文不做修改）
算法定义一个函数：majority(com1,com2,…,comn)等于多数派命令。
OM(0)算法
（1）发令者将他的命令发送给每个副官。
（2）每个副官采用他从发令者得到的命令，或者默认使用撤退命令，如果没有收到任何命令。
OM(m)算法
（1）发令者将他的命令发送给每个副官。
（2）对于每个i ，vi 是每个副官i 从发令者收到的命令，如果没有收到命令则为撤退命令。副官i 在OM(m-1) 中作为发令者将vi 发送给另外n-2 个副官。
（3）对于每个i，并且j eq i，vj 是副官i 从第（2）步中的副官j 发送过来的命令（使用OM(m-1)算法），如果没有收到第（2）步中的副官j 的命令则默认为撤退命令。最后副官i 使用majority(v1,…,vn-1)得到命令。
接下来实际的考虑一个n=4，m=1 的情况：
1. 当副官D是背叛者
第一步发令者A执行算法OM(1)将自己的命令发送给三个副官B，C，D，三个副官都正确地收到了命令。
第二步每个收到命令的副官都作为发令者执行算法OM(0)，将自己收到的命令转发给其余副官，因为副官D是背叛者，所以他给副官B和C传递的消息可能会是假消息。副官B和C分别根据majority 函数来决定命令。
这样背叛的副官D 同理也干扰不了发令者的决定。下面看看如果发令者是背叛者。
2. 发令者是背叛者，其余副官为忠诚的
第一步：发令者A向副官B，C，D发送了不同的命令，实际情况中是一个攻击者向不同方发送了不一致的值（例如，0或1）企图扰乱副官做出一致决定。
第二步：副官收到命令后，摇身一变为发令者执行OM(0) 向所有的副官发送命令，每个副官通过多数表决算法仍可以达成一致的命令。
文章接着就证明了OM(m)算法对任意m 都是可以满足，首先引入一个引理（归纳法证明）：
引理1：对于任意m 和k ，如果有超过2k+m 个将军和最多k 个背叛者，那么算法OM(m) 满足IC2 （回顾下IC2 指的是，如果将军是忠诚的，所有的副官遵守将军命令）。
证明：当m=0 的时候，OM(0) 在将军是忠诚的时候满足IC2。当m>0 时，首先将军将命令传递给 n-1 个副官，然后每个副官对n-1 个将军执行OM(m-1) 算法。因为假设了n>2k+m（引理中有将军数大于2k+m），所以 n-1 > 2k+(m-1) >= 2k（即每一轮中副官总数不小于背叛者的两倍），这样每轮OM(m-k) 算法中忠诚的副官收到的命令都是majority(v1,v2,...,v(n-1))，其中忠诚副官发送的命令大于或者等于一半。
接着解决拜占庭将军问题。
定理1：对于任意m，如果有超过3m 个将军和最多m 个背叛者，算法OM(m) 满足条件IC1 和条件IC2。
证明：通过m 的归纳法证明，我们通过假设OM(m-1) 成立来证明OM(m) m>0。首先考虑发送命令的将军是忠诚的。那么将引理中k 设为m 则OM(m) 满足IC2 ，IC1 在发令将军是忠诚的情况下也满足。
接着考虑m 个背叛者中有一个是发令者，那最多就只有m-1 个副官是背叛者了，又因为有3m 个将军，所以副官的总数超过3m-1，且有3m-1>3(m-1) 。因此通过归纳法假设 OM(m-1) 满足IC1 和IC2（最多3(m-1) 个将军和最多m-1 个背叛者）。那么任意两个忠诚的副官j 在OM(m-1) 获得相同命令vj，那么在OM(m) 算法中每个忠诚的副官都会收到(v1,v2,...,v(n-1))，可知满足条件IC1 和IC2。
看完这段证明其实我也挺糊涂的~~~~，画了张图来看看lamport 是怎么证明的：
签名消息在除了满足口头消息A1-A3 三点要求外还应该满足下面A4：
A4 （a）签名不可被伪造，一旦被篡改即可发现
（b）任何人都可以验证将军签名的可靠性
下面定义一个类似于上面majority() 函数的choice() 来决定副官的选择：1.当集合V 只包含了一个元素v ，那么choice(V)=v ；2. choice(o)=RETREAT。
有了上面A4 和choice() 基础我们给出SM(m) 方法：
SM(m) 算法
初始化Vi=空集合
（1）将军签署命令并发给每个副官
（2）对于每个副官i ：
（A）如果副官i 从发令者收到v:0 的消息，且还没有收到其他命令序列，那么：
（i）使Vi 为{v}
（ii）发送v:0:i 给其他所有副官
（B）如果副官i 收到消息v:0:j1:...:jk 且v 不在集合Vi 中则
（i）添加v 到Vi
（ii）如果k<m ，那么发送v:0:j1:...:jk:i 给每个不在j1,..,jk 中的副官
（3）对于每个副官i ，当不再收到消息，则遵守命令choive(Vi)
算法的几点说明：
算法第三步并没有说明副官如何判断没有新的消息，可以通过两个解决方法：一是要求每个副官收到消息后要么签名转发该消息，要么发送一个通知他将不发送这个消息；二是设置一个超时时间，如果在该时间段还没有收到消息，则认为不再收到消息。
算法SM(m) 中，让副官签名是确认其收到了该消息（有点像来了份文件给每个领导批阅）。在SM(1) 中副官收到消息就不用签字了，因为不用转发给其他副官。
定理2：对于任意m，最多只有m 个背叛者情况下，算法SM(m) 解决拜占庭将军问题
Proof：首先证明IC2，如果发令者是忠诚的，那么所有的副官一定收到相同的命令，因为签名无法篡改，且IC1 也就满足了。证明IC1 只用考虑发令者是背叛者的情况（重新回顾下IC1 是指所有忠诚的副官执行相同的命令），IC1 要求两个忠诚的副官（i，j）必须收到相同的命令集合Vi、Vj，也就是Vi 中每个v 都在Vj 中。会存在两种情况，其一当副官i 收到v 命令的序列后，加入到Vi，并将其发送给副官j ，j 将命令v 保存；其二副官i 收到命令v:0:j1:...:jk:i，其中有jr=j，所以 由A4 可知副官j 也收到了该命令。如果没有，则有：
k<m。这种情况下，i 发送信息v:0:j1:...:jk:i 给副官j ，那么j 一定收到v 。（这点感觉和上面有重复）
k=m。发令者是背叛者，最多只有m-1 个副官是背叛者。因此，最少有一个序列j1,...,jm是忠诚的。那么j 一定收到这个忠诚的副官序列发来的值v ，所以副官j 收到v 。
证明完毕。

7. 实用拜占庭容错算法（PBFT）

       拜占庭帝国即东罗马帝国，拥有巨大的财富，并对邻邦垂诞已久，为此派出了10支军队去包围这个敌人。这个敌人虽不比拜占庭帝国，但也足以抵御5支常规拜占庭军队的同时袭击。基于一些原因，这10支军队不能集合在一起单点突破，必须在分开的包围状态下同时攻击。他们任一支军队单独进攻都毫无胜算，除非有至少6支军队同时袭击才能攻下敌国。他们分散在敌国的四周，依靠通信兵相互通信来协商进攻意向及进攻时间。困扰这些将军的问题是，他们不确定他们中是否有叛徒，叛徒可能擅自变更进攻意向或者进攻时间。在这种状态下，拜占庭将军们能否找到一种分布式的协议来让他们能够远程协商，从而赢取战斗？这就是着名的拜占庭将军问题【在分布式系统中指的是消息不仅可以被丢失、延迟、重放，还可以被伪造】。

        PBFT(Practical Byzantine Fault Tolerance)算法由Miguel Castro 和Barbara Liskov在1999年提出来的，解决了原始拜占庭容错算法效率不高的问题，将算法复杂度由指数级降低到多项式级，使得拜占庭容错算法在实际系统应用中变得可行。

        PBFT是一种状态机副本复制算法，一般包括三种协议:一致性协议(agreement)、检查点协议(checkpoint)和视图更换协议(view change)。该算法要满足以下两个性质：   

        安全性(safety)：safety means nothing bad happens.                                                        活性(liveness)：liveness means that something good eventually happens.

        在一个拜占庭系统里面，要容忍f个拜占庭节点错误，则replica数量至少为3f+1，这是满足安全性的前提。因为网络延迟或宕机，系统存在f个节点不回复响应（f个节点包括拜占庭节点和非拜占庭节点，最坏情况f个节点全是非拜占庭节点），剩下2f+1个响应中可能有f个拜占庭节点，从而得到n-2f>f，即响应中非拜占庭节点数目大于拜占庭节点数目（f+1>f）。

        算法不依赖同步提供安全性，则必须依赖同步提供活性，否则违背FLP定理(在异步通信场景，即使只有一个进程失败了，没有任何算法能保证非失败进程能够达到一致性)。在拜占庭节点不超过f，并且delay(t)有界的情况下就能保证系统活性，delay(t)表示从消息发送到接受的时间间隔。

        在一个view里面，会从replicas中选择一个primary，其余的replicas则叫backups。如果主节点行为发生异常，则进行view change换主。                                  

       游戏从client向primary发送请求 开始。 状态机操作， 时戳。                                                                                                                                       游戏从client至少收到f+1个replicas的响应 结束。 视图编号， 时戳， 客户端身份， replica编号， 请求结果。【why f+1？因为在2f+1个committed中有f个拜占庭节点表面上同意请求，实际上根本不会回复请求】

3.1 重彩大戏------三阶段协议

Pre-prepare:

        Primary为客户端请求分配一个序列号n，向所有backups发现预准备消息 。 视图编号， 消息 的摘要。

Prepare:

        若满足以下条件，backups接受预准备消息：                                                                    1.客户端请求和预准备消息具有正确签名。                                                                        2.当前视图编号是v。                                                                                                          3.backups从未在当前视图v接收过序列号为n但摘要不同的预准备请求。                          4.h<n<H。【防止一个拜占庭节点选择一个大的序号来消耗序号空间】

        如果上述条件满足，backups接收预准备消息，进入prepare阶段，向其他节点广播准备消息 ，并将预准备和准备消息写入日志。

commit:

       如果backups收到2f【包括自己】个与预准备消息一致的准备消息，请求消息和预准备消息具有相同的视图v和序列号n，并且已将相关消息写入日志，则进入commit阶段，向其他节点广播一条确认消息 。如果各节点收到2f+1条相同的commits消息，则向客户端发送一条reply消息。

3.2 垃圾回收

      PBFT是一种状态机副本复制算法，replicas会将执行过消息记录在本地日志中，为了节省内存，需要一种机制来清理日志。何时来清理？在每次操作完后执行是不明智的，因为比较耗资源。可以定期清理，比如每100次清理一次。我们将请求后执行的状态称为检查点checkpoint；带证明的检查点称为stable certificate，当节点收到2f+1个checkpoint消息时，可证明稳定检查点是正确的。稳定检查点之前的日志消息均可删除。                       

      当清理检查点时replica i向其他replicas广播一条检查点协议 ， 是最近一次正确执行请求序号， 是其当前状态摘要。如果每一个replica收到2f+1个具有相同序号 和摘要 的检查点消息，这时每一个replica可以清理序列号 小于等于n的日志信息。

       检查点协议也用来更新水平线。低水平线 等于最近稳定检查点的序号，高水平线 ， 为日志大小。

3.3 视图更改

        当主节点挂掉，或者在commit阶段有些节点收到2f+1个commit，有些没有收到2f+1个commit，导致状态不一致，这些状况都需要更改视图来提供系统活性和安全性。

        当请求超时，备份节点进入视图v+1，广播视图更改消息 。 稳定检查点序列号， 是稳定检查点证明， 是一个集合，包含对请求 （请求的序列号大于 ）相关消息集合 。 包含2f+1个相同的准备消息。

         当视图v+1的主节点收到2f个相同个视图更改消息，向其他副本广播新视图消息 ， 是2f+1个视图更改消息， 的计算规则如下：        1.确定序列号 和 。其中 等于 中稳定检查点序列号, 等于 中最大prepare消息序列号。                                                                                                  2.主节点为 和 之间的每一个序列号n分配pre-prepare消息。如果 中包含n对应的 组合，则对应的预准备消息为 （也就是说序列号n对应的请求有2f+1个prepare消息，在新视图中依然提交这个请求）。如果 中不包含n对应的 组合，则提交null消息为 ，即不做任何处理。

        副本收到新视图消息后，广播一次prepare消息，进入v+1，视图更换完成。

8. 易理解的拜占庭将军问题——深入剖析

拜占庭将军问题和两军问题实质是不一样的，不能混为一谈。其中两军问题如下图所示：

两军问题描述：

和拜占庭将军问题有一定的相似性也有不同之处，所以我们必须注意的是：

两军问题的根本问题在于信道的不可靠，也就是信号做不到真正的同步，那么想要做到真正的同步唯一的办法就是量子通信——毕竟遇事不决量子搞定:

到底是一个关于一致性和正确性的算法问题。针对的是忠诚的将军，因为叛徒可以做出任何超出约定的判断。我们就是要在有叛徒的干扰下，找到一个抗干扰的算法。

类似TCP/IP的三次握手，我们也同样的是采用容错机制，通过限制一部分条件最后使得在有叛徒的情况下依然能够得到信息的真实性。

失效说明：

满足以下三个条件的方式称为口头协议：

对于正整数 和 ，当图 是 -正则的是，定义算法 OM(m, p) ：

在算法中，司令官发送一个签名的命令给他的每个副官。然后，每个副官添加他的签名到命令上，并发送给其他副官，收到命令的副官再添加他的签名发送给其他副官......

算法还假定了一个 choice 函数，作用在一个命令的集合上来获得一个单独的命令。 choice 函数需要满足：

例如， choince 函数可以是取有序集合 的中位数。

令 指由将军 签名的命令值 ， 指命令指 由将军 签名后再由将军 签名。令将军 为司令官，每个副官 维护一个命令集 ，包含他收到的被正确签名的命令值。(如果司令官是忠诚的，这个值集的元素不会超过一个)。

书面协议的结论非常令人兴奋，这不是解决了拜占庭将军问题了吗？但请注意我们在A1~A4中实际上是添加了一些条件的，这使得拜占庭将军问题在这些假设下能够解决，但是在实际状况中却会有一些问题。观察A1-A4，我们做了一些在现实中比较难以完成的假设，比如：

9. 共识算法：Raft

上篇讲到了“拜占庭将军问题”：多个拜占庭将军要如何在可能有叛徒、信使可能被策反或者暗杀的情况下达成是否要进攻的一致性决定？还不了解的先看看上一篇 《拜占庭将军问题》 。这篇主要是介绍简化版拜占庭将军问题的解决方案：Raft 共识算法。

所以将拜占庭将军问题根据常见的工作上的问题进行简化： 假设将军中没有叛军，信使的信息可靠但有可能被暗杀的情况下，将军们如何达成一致性决定？

对于这个简化后的问题，有许多解决方案，第一个被证明的共识算法是 Paxos，由拜占庭将军问题的作者 Leslie Lamport 在1990年提出，最初以论文难懂而出名，后来这哥们在2001重新发了一篇简单版的论文 Paxos Made Simple ，然而还是挺难懂的。

因为 Paxos 难懂，难实现，所以斯坦福大学的教授在2014年发表了新的分布式协议 Raft。与 Paxos 相比，Raft 有着基本相同运行效率，但是更容易理解，也更容易被用在系统开发上。

我们还是用拜占庭将军的例子来帮助理解 Raft。

Raft 的解决方案大概可以理解成 先在所有将军中选出一个大将军，所有的决定由大将军来做。 选举环节 ：比如说现在一共有3个将军 A, B, C，每个将军都有一个 随机时间 的倒计时器，倒计时一结束，这个将军就会把自己当成大将军候选人，然后派信使去问其他几个将军，能不能选我为总将军？假设现在将军A倒计时结束了，他派信使传递选举投票的信息给将军B和C，如果将军B和C还没把自己当成候选人（倒计时还没有结束），并且没有把选举票投给其他，他们把票投给将军A，信使在回到将军A时，将军A知道自己收到了足够的票数，成为了大将军。在这之后，是否要进攻就由大将军决定，然后派信使去通知另外两个将军，如果在一段时间后还没有收到回复（可能信使被暗杀），那就再重派一个信使，直到收到回复。

故事先讲到这里，希望不做技术方面的朋友可以大概能理解 Raft 的原理，下面从比较技术的角度讲讲 Raft 的原理。

从拜占庭将军的故事映射到分布式系统上，每个将军相当于一个分布式网络节点，每个节点有 三种状态：Follower，Candidate，Leader ，状态之间是互相转换的，可以参考下图，具体的后面说。

每个节点上都有一个倒计时器 (Election Timeout)，时间随机在 150ms 到 300ms 之间。有几种情况会重设 Timeout：

在 Raft 运行过程中，最主要进行两个活动：

假设现在有如图5个节点，5个节点一开始的状态都是 Follower。

在一个节点倒计时结束 (Timeout) 后，这个节点的状态变成 Candidate 开始选举，它给其他几个节点发送选举请求 (RequestVote)

其他四个节点都返回成功，这个节点的状态由 Candidate 变成了 Leader，并在每个一小段时间后，就给所有的 Follower 发送一个 Heartbeat 以保持所有节点的状态，Follower 收到 Leader 的 Heartbeat 后重设 Timeout。

这是最简单的选主情况， 只要有超过一半的节点投支持票了，Candidate 才会被选举为 Leader ，5个节点的情况下，3个节点 (包括 Candidate 本身) 投了支持就行。

一开始已经有一个 Leader，所有节点正常运行。

Leader 出故障挂掉了，其他四个 Follower 将进行重新选主。

4个节点的选主过程和5个节点的类似，在选出一个新的 Leader 后，原来的 Leader 恢复了又重新加入了，这个时候怎么处理？在 Raft 里，第几轮选举是有记录的，重新加入的 Leader 是第一轮选举 (Term 1) 选出来的，而现在的 Leader 则是 Term 2，所有原来的 Leader 会自觉降级为 Follower

假设一开始有4个节点，都还是 Follower。

有两个 Follower 同时 Timeout，都变成了 Candidate 开始选举，分别给一个 Follower 发送了投票请求。

两个 Follower 分别返回了ok，这时两个 Candidate 都只有2票，要3票才能被选成 Leader。

两个 Candidate 会分别给另外一个还没有给自己投票的 Follower 发送投票请求。

但是因为 Follower 在这一轮选举中，都已经投完票了，所以都拒绝了他们的请求。所以在 Term 2 没有 Leader 被选出来。

这时，两个节点的状态是 Candidate，两个是 Follower，但是他们的倒计时器仍然在运行，最先 Timeout 的那个节点会进行发起新一轮 Term 3 的投票。

两个 Follower 在 Term 3 还没投过票，所以返回 OK，这时 Candidate 一共有三票，被选为了 Leader。

如果 Leader Heartbeat 的时间晚于另外一个 Candidate timeout 的时间，另外一个 Candidate 仍然会发送选举请求。

两个 Follower 已经投完票了，拒绝了这个 Candidate 的投票请求。

Leader 进行 Heartbeat， Candidate 收到后状态自动转为 Follower，完成选主。

以上是 Raft 最重要活动之一选主的介绍，以及在不同情况下如何进行选主。

Raft 在实际应用场景中的一致性更多的是体现在不同节点之间的数据一致性，客户端发送请求到任何一个节点都能收到一致的返回，当一个节点出故障后，其他节点仍然能以已有的数据正常进行。在选主之后的复制日志就是为了达到这个目的。

一开始，Leader 和 两个 Follower 都没有任何数据。

客户端发送请求给 Leader，储存数据 “sally”，Leader 先将数据写在本地日志，这时候数据还是 Uncommitted (还没最终确认，红色表示)

Leader 给两个 Follower 发送 AppendEntries 请求，数据在 Follower 上没有冲突，则将数据暂时写在本地日志，Follower 的数据也还是 Uncommitted。

Follower 将数据写到本地后，返回 OK。Leader 收到后成功返回， 只要收到的成功的返回数量超过半数 (包含Leader) ，Leader 将数据 “sally” 的状态改成 Committed。( 这个时候 Leader 就可以返回给客户端了)

Leader 再次给 Follower 发送 AppendEntries 请求，收到请求后，Follower 将本地日志里 Uncommitted 数据改成 Committed。这样就完成了一整个复制日志的过程，三个节点的数据是一致的，

在 Network Partition 的情况下，部分节点之间没办法互相通信，Raft 也能保证在这种情况下数据的一致性。

一开始有 5 个节点处于同一网络状态下。

Network Partition 将节点分成两边，一边有两个节点，一边三个节点。

两个节点这边已经有 Leader 了，来自客户端的数据 “bob” 通过 Leader 同步到 Follower。

因为只有两个节点，少于3个节点，所以 “bob” 的状态仍是 Uncommitted。所以在这里， 服务器会返回错误给客户端

另外一个 Partition 有三个节点，进行重新选主。客户端数据 “tom” 发到新的 Leader，通过和上节网络状态下相似的过程，同步到另外两个 Follower。

因为这个 Partition 有3个节点，超过半数，所以数据 “tom” 都 Commit 了。

网络状态恢复，5个节点再次处于同一个网络状态下。但是这里出现了数据冲突 “bob" 和 “tom"

三个节点的 Leader 广播 AppendEntries

两个节点 Partition 的 Leader 自动降级为 Follower，因为这个 Partition 的数据 “bob” 没有 Commit，返回给客户端的是错误，客户端知道请求没有成功，所以 Follower 在收到 AppendEntries 请求时，可以把 “bob“ 删除，然后同步 ”tom”，通过这么一个过程，就完成了在 Network Partition 情况下的复制日志，保证了数据的一致性。

Raft 是能够实现分布式系统强一致性的算法，每个系统节点有三种状态 Follower，Candidate，Leader。实现 Raft 算法两个最重要的事是：选主和复制日志

参考链接：
Raft 官网： https://raft.github.io/

Raft 原理动画 (推荐看看)： http://thesecretlivesofdata.com/raft/

（本来不想一个个图片粘，但是在国内时候访问不了这个链接，干脆就复述了一遍整个过程。）