精华内容
参与话题
问答
  • 拜占庭将军问题

    千次阅读 2017-02-27 17:18:57
    了解过比特币和区块链的人,多少都听说过拜占庭将军问题,或听说过比特币(或区块链)的一个重要成就正是解决了拜占庭将军问题。但真正明白这个问题的人并不多,甚至知道这个问题实质的人都很罕见。本文是一篇技术...

    了解过比特币和区块链的人,多少都听说过拜占庭将军问题,或听说过比特币(或区块链)的一个重要成就正是解决了拜占庭将军问题。但真正明白这个问题的人并不多,甚至知道这个问题实质的人都很罕见。本文是一篇技术科普,将重点提供了拜占庭将军问题本身对本质及经典算法的解析,并探讨与之相关的一些问题。笔者参考了不少文献,夹杂了大量私货,但并没有提出解决该问题的新算法,这也不是本文的目的。

     

    Part1:拜占庭将军问题是什么

     

    拜占庭将军问题是一个共识问题: 首先由Leslie Lamport与另外两人在1982年提出,被称为The Byzantine Generals Problem或者Byzantine Failure。核心描述是军中可能有叛徒,却要保证进攻一致,由此引申到计算领域,发展成了一种容错理论。随着比特币的出现和兴起,这个著名问题又重入大众视野。

     

    1.1. 拜占庭将军问题场景

     

    关于拜占庭将军问题,一个简易的非正式描述如下:

    拜占庭帝国想要进攻一个强大的敌人,为此派出了10支军队去包围这个敌人。这个敌人虽不比拜占庭帝国,但也足以抵御5支常规拜占庭军队的同时袭击。基于一些原因,这10支军队不能集合在一起单点突破,必须在分开的包围状态下同时攻击。他们任一支军队单独进攻都毫无胜算,除非有至少6支军队同时袭击才能攻下敌国。他们分散在敌国的四周,依靠通信兵相互通信来协商进攻意向及进攻时间。困扰这些将军的问题是,他们不确定他们中是否有叛徒,叛徒可能擅自变更进攻意向或者进攻时间。在这种状态下,拜占庭将军们能否找到一种分布式的协议来让他们能够远程协商,从而赢取战斗?这就是著名的拜占庭将军问题。

    应该明确的是,拜占庭将军问题中并不去考虑通信兵是否会被截获或无法传达信息等问题,即消息传递的信道绝无问。Lamport已经证明了在消息可能丢失的不可靠信道上试图通过消息传递的方式达到一致性是不可能的。所以,在研究拜占庭将军问题的时候,我们已经假定了信道是没有问题的,并在这个前提下,去做一致性和容错性相关研究。如果需要考虑信道是有问题的,这涉及到了另一个相关问题:两军问题。

     

    1.2.与拜占庭将军相关问题:两军问题

     

    正如前文所说,拜占庭将军问题和两军问题实质是不一样的。国内大量解释拜占庭将军问题的文章将两者混为一谈,其实是混淆了两个问题的实质,由此造成了许多误解。这两个问题看起来的确有点相似,但是问题的前提和研究方向都截然不同。

    图1:两军问题图示

    如图1所示,白军驻扎在沟渠里,蓝军则分散在沟渠两边。白军比任何一支蓝军都更为强大,但是蓝军若能同时合力进攻则能够打败白军。他们不能够远程的沟通,只能派遣通信兵穿过沟渠去通知对方蓝军协商进攻时间。是否存在一个能使蓝军必胜的通信协议,这就是两军问题。

    看到这里您可能发现两军问题和拜占庭将军问题有一定的相似性,但我们必须注意的是,通信兵得经过敌人的沟渠,在这过程中他可能被捕,也就是说,两军问题中信道是不可靠的,并且其中没有叛徒之说,这就是两军问题和拜占庭将军问题的根本性不同。由此可见,大量混淆了拜占庭将军问题和两军问题的文章并没有充分理解两者。

    两军问题的根本问题在于信道的不可靠,反过来说,如果传递消息的信道是可靠的,两军问题可解。然而,并不存在这样一种信道,所以两军问题在经典情境下是不可解的,为什么呢?

    倘若1号蓝军(简称1)向2号蓝军(简称2)派出了通信兵,若1要知道2是否收到了自己的信息,1必须要求2给自己传输一个回执,说“你的信息我已经收到了,我同意你提议的明天早上10点9分准时进攻”。

    然而,就算2已经送出了这条信息,2也不能确定1就一定会在这个时间进攻,因为2发出的回执1并不一定能够收到。所以,1必须再给2发出一个回执说“我收到了”,但是1也不会知道2是否收到了这样一个回执,所以1还会期待一个2的回执。

    虽然看似很可笑,但在这个系统中永远需要存在一个回执,这对于两方来说都并不一定能够达成十足的确信。更要命的是,我们还没有考虑,通信兵的信息还有可能被篡改。由此可见,经典情形下两军问题是不可解的,并不存在一个能使蓝军一定胜利的通信协议。

    不幸的是,两军问题作为现代通信系统中必须解决的问题,我们尚不能将之完全解决,这意味着你我传输信息时仍然可能出现丢失、监听或篡改的情况。但我们能不能通过一种相对可靠的方式来解决大部分情形呢?这需要谈到TCP协议。事实上,搜索“两军问题与三次握手”,您一定可以找到大量与TCP协议相关的内容。若您是通信方面的专家,权当笔者是班门弄斧,这里仅用最浅显易懂的方式科普TCP协议的原理和局限,可能存在一些毛刺,请多包涵。

                                                                                                                                                                                                      (图2:TCP协议的基本原理)

    TCP协议中,A先向B发出一个随机数x,B收到x了以后,发给A另一个随机数y以及x+1作为答复,这样A就知道B已经收到了,因为要破解随机数x可能性并不大;然后A再发回y+1给B,这样B就知道A已经收到了。这样,A和B之间就建立一个可靠的连接,彼此相信对方已经收到并确认了信息。

    而事实上,A并不会知道B是否收到了y+1;并且,由于信道的不可靠性,x或者y都是可能被截获的,这些问题说明了即使是三次握手,也并不能够彻底解决两军问题,只是在现实成本可控的条件下,我们把TCP协议当作了两军问题的现实可解方法。

                                                                                                                                                                                          (图3:量子隐形传态的原理图)

    那么,是否能够找到一个理论方法来真正的破解两军问题呢?答案是有的,量子通讯协议,笔者并没有能力弄清这个颇为高深的问题。据我的理解,处于量子纠缠态的两个粒子,无论相隔多远都能够彼此同步,光是直观的来看,这个效应可以用来实现保密通讯。

    但是由于测不准原理,一测量粒子状态就会改变其状态,所以通讯时还必须通过不可靠信道发送另一条信息。尽管这个“另一条信息”是不可靠的,但是由于已经存在了一条绝对可靠的信道(量子纠缠),保证了另一条信道即使不可靠也能保证消息是可靠的,否则至少被窃取了一定能够被发现。

    因此我们可以相信,至少理论上两军问题是可解的,即存在一种方法,即使利用了不可靠的信道,也能保证信息传递的可靠性。所以,在确保了信道可靠的基础上,我们可以回到拜占庭将军问题上继续讨论。

     

    Part2:问题实质及形式化

     

    我们已经了解了拜占庭将军问题的场景,并且明确了这个问题的解决是建立在通信兵可以正确的传达信息的基础上的,即信道绝对可信。同时,通过前文对于两军问题的探讨,我们明白了理论上可信的信道也是可以实现的。接下来,我们将探讨拜占庭将军问题的实质。

     

    2.1. 拜占庭将军问题实质

     

    回顾问题,一群将军想要实现某一个目标(一致进攻或者一致撤退),但是单独行动行不通,必须合作, 达成共识;由于叛徒的存在,将军们不知道应该如何达到一致。注意,这里“一致性”才是拜占庭将军问题探讨的内容,如果本来叛徒数量就已经多到了问题不可解的地步,这个就是“反叛”的问题了;同时,我们的目标是忠诚的将军能够达成一致,对于这些忠诚的将军来说,进攻或者撤退都是可以的,只要他们能够达成一致就行。

    但是,光靠“一致”就可以解决问题吗?考虑一下,如果万事俱备,客观上每个忠诚的将军只要进攻了就一定能够胜利,但是却因为叛徒的存在他们都“一致的”没有进攻;反之,条件不利,将军们不应该进攻,但是却因为叛徒的存在所有人都“一致的”进攻了。

    可以发现,只有“一致性”是不足以解决拜占庭将军问题的,我们还需要提出一个“正确性”要求。这个要求是值得斟酌的,因为如果客观来看或许会有“绝对正确的”判断,但是针对每一个将军,大家的判断或许都不相同,我们如何定义“正确”呢?我们或许可以简单地说,正确就是每个忠诚的将军都正确的表达了自己的意思,不会因为叛徒让别的将军认为忠诚的将军是叛徒而不采用他传达的消息。

    至此,我们将拜占庭将军问题简化成了,所有忠诚的将军都能够让别的将军接收到自己的真实意图,并最终一致行动;而形式化的要求就是,“一致性”与“正确性”。

    如果将问题推广开来,可以发现针对一致性和正确性的算法并不要求命令必须是“进攻/撤退”或是“1/0”,而可以是“发送消息1/发送消息2/待机”或“x/y/z/w”,这意味着拜占庭将军问题算法可以为多种分布式系统提供启发,比如电力系统或网络系统。

    由此可见,这个问题说到底是一个关于一致性和正确性的算法问题,这个算法是针对的是忠诚的将军,因为叛徒可以做出任何超出约定的判断。我们就是要在有叛徒的干扰下,找到一个抗干扰的算法。要解决这个算法问题,我们需要将形式化要求具体化。

     

    2.2.形式化条件的推演

     

    定义一个变量vi(为不失一般性,并不要求vi是布尔值),作为其他将军收到的第i个将军的命令值;i将军会将把自己的判断作为vi。可以想象,由于叛徒的存在,各个将军收到的vi值不一定是相同的。之后,定义一个函数来处理向量(v1,v2,…,vn),代表了多数人的意见,各将军用这个函数的结果作为自己最终采用的命令。至此,我们可以利用这些定义来形式化这个问题,用以匹配一致性和正确性。

    1)一致性

    条件1:每一个忠诚的将军必须得到相同的(v1,v2,…,vn)指令向量或者指令集合。

    这意味着,忠诚的将军并不一定使用i将军送来的信息作为vi,i将军也可能是叛徒。但是仅靠这个条件,忠诚的将军的信息送来的信息也可能被修改,这将影响到正确性。

    2)正确性

    条件2:若i将军是忠诚的,其他忠诚的将军必须以他送出的值作为vi。

    如此,我们得到了一致性和正确性的形式化条件(条件1和条件2),这个条件是充分条件。考虑到正确性条件是针对单个将军,而一致性条件是针对所有将军的,为方便我们重写一致性条件为

    条件1′:无论i将军是忠诚或是叛徒,任何两个忠诚的将军都使用相同的vi。

    条件1和条件1′是完全等价的。这是很巧妙的一步转换,如此一致性条件(条件1′)和正确性条件(条件2)都只涉及一个将军i如何帮别的将军接受自己送出的值vi,所以可以将问题改为司令-副官模式来简化问题,即一个司令把自己的命令传递给n-1个副官,使得:

    IC1:所有忠诚的副官遵守一个命令,即一致性。

    IC2:若司令是忠诚的,每一个忠诚的副官遵守他发出的命令,即正确性。

    IC1和IC2分别由条件1′和条件2演化得来。司令-副官模式只要将司令遍历各个将军,就可以变成完整问题,而他们采用的算法可以是完全一致的。IC1和IC2构成了解决拜占庭将军问题的充分条件,在这种模式下,司令副官的形式下达成的一致意味着司令的命令得到了有效传达,若出现了异议,有异议的将军会作为司令发起新的司令副官模式寻求自己的观点表达,以协商达成一致。

    接下来,我们可以讨论拜占庭将军问题的算法了,这个算法只要能够满足IC1和IC2,就代表这个算法可以切实有效的解决拜占庭将军问题。

    在经典的情形下,我们可以找到两种办法,口头协议书面协议。笔者将会逐一探讨两种算法的推演和证明,其中证明部分并不会采用纯推理,而以介绍证明思路为主。

    事实上,若完整进行了算法推演,对算法已经能够有一个大致的了解。口头协议和书面协议会有很多不同的启发,口头协议的实现起来简单,但是算法复杂,同时需要克服的困难更多;书面协议的算法本身很简单,却能够克服很多问题,但是实现算法并不容易。这些不同让两者有了不同的使用场景和具体实现。

     

    Part3:口头协议

     

    首先,我们明确什么是口头协议。我们将满足以下三个条件的方式称为口头协议:

    A1:每个被发送的消息都能够被正确的投递

    A2:信息接收者知道是谁发送的消息

    A3:能够知道缺少的消息

    简而言之,信道绝对可信,且消息来源可知。但要注意的是,口头协议并不会告知消息的上一个来源是谁。

    先告知结论:采用口头协议,若叛徒数少于1/3,则拜占庭将军问题可解。也就是说,若叛徒数为m,当将军总数n至少为3m+1时,问题可解(即满足了IC1和IC2)。

    这个结论说明了,一个三模冗余的系统只能容故障冻结类型的错误,即一个元件故障以后就卡住不动了(也即已知错误后会出现的结果),那么三模冗余是足够的。

    但是对于拜占庭将军问题,由于叛徒可以做出各种各样的判断,就必须四模冗余系统才足够容错。口头协议算法就是把自己的命令告诉其他人,并利用对其他人的命令取多数的方法来得到自己的结论。但要注意的是,别的将军传来的命令是通过算法递归的方法来确定的。利用这个方法,可以保证在叛徒数量少于1/3的情况下,忠诚的将军可以实现一致性和正确性要求,即问题可解。

    那么,口头协议算法又是怎么实现叛徒数少于1/3即可容错的呢?下面,笔者将介绍Lamport在其论文中提出的口头协议OM(m)算法。笔者将会逐一介绍口头协议算法的详细内容、实例推演及证明,这一部分将会需要您花一些时间来思考。

     

    3.1.口头协议算法OM(m)

     

    OM(0)算法

    (1)司令将他的命令发送给每个副官。

    (2)每个副官采用从司令发来的命令;如果没有收到命令,则默认为撤退命令。

    OM(m)算法

    (1)司令将他的命令发送给每个副官。

    (2)对于每个i,vi是每个副官i从司令收到的命令,如果没有收到命令,则默认为撤退命令。副官i在OM(m-1) 中作为发令者将之发送给另外n-2 个副官。

    (3)对于每个i,和每个j ≠ i,vj 是副官i 从第2步中的副官j (使用OM(m-1)算法)发送过来的命令,如果没有收到第2步中副官j 的命令,则默认为撤退命令。最后副官i 使用majority(v1,…,vn-1)得到命令。

    其中,majority(v1,…,vn-1)代表了大多数人的命令,若不存在则默认为撤退命令。

    要一遍读懂这个算法并不容易,笔者也是花了不少时间研究这一小段文字才弄明白的。不过您不用担心,笔者将会解释几个值得注意的点,并利用一个不难的实例来帮助您理解这个算法。

    (1)算法始终保证了一个更加安全的默认值,这意味着若信息没有传到是可知的,并且传输时间不在考虑范围内。

    (2)这个算法是一个递归算法,在OM(m)中需要采用OM(m-1)得到相关结果。m代表的是叛徒数量,从m到0,意味着对于每个将军,需要m+1轮的算法才能完成。

    (3)该算法是关于m的,意味着使用该算法必须知道有多少个叛徒。或者说,利用该算法,可以保证叛徒数量在某一个最大值(即总将军数量的1/3)之下时,拜占庭将军问题可解。

    (4)对于任意k<m,在第m-k+1步中OM(k)的vi,都是利用OM(k-1)得来的,即每个将军将会在OM(k-1)中询问其他人,i将军传给他们的是什么,而其他人传递回来的信息则是利用OM(k-2)得到。

    这个就是递归的意义,若您觉得笔者表达得不甚清楚,不用担心,您只用记住每一步都会牵涉到下面很多步骤就可以了,之后将在实例推演中明白算法的核心思路。

     

    3.2.口头协议实例推演

     

    首先,笔者将先举一个m=1,n=3的例子来说明三模冗余的问题所在,并介绍m=1,n=4的时候系统是怎么容错的,这样您就可以明白算法是运行的。但由于m=1的时候并没有体现递归的过程(因为m-1就变成了0),笔者将再举一个m=2,n=7的例子来说明算法递推的过程。 (1)m=1,n=3的情形 n=3,意味着一个司令发送命令给两个副官,m=1意味着他们中有一个叛徒。 首先考虑司令忠诚而副官2是叛徒的情况。

    (图4:m=1,n=3中司令忠诚而副官2是叛徒的情形)

    司令把进攻命令传给了两个副官1和副官2,但是由于副官2为了不让他们达成一致,将司令的命令改成了撤退。那对于副官1来说,他应该如何判断?他无法知道是司令是叛徒还是副官2是叛徒,从而无法判断。

                                                                                                                                                                                 (图5:m=1,n=3中司令是是叛徒的情形)

    而如果司令是叛徒,两个副官忠诚,司令会发送两个不同的命令。当两个副官对照命令时,他们又凌乱了,无法判断司令是叛徒或者对方是叛徒,从而又无法判断。这个情形非常简易的说明了三模冗余是无法动态容错的。(2)m=1,n=4的情形 n=4,意味着一个司令发送命令给三个副官,m=1意味着他们中有一个叛徒。 首先考虑司令忠诚而副官3是叛徒的情况。

    (图6:m=1,n=4中司令忠诚而副官3是叛徒的情形)

    倘若司令在OM(1)中给各副官发送的消息都是进攻(A),之后OM(0)时,叛徒副官3给副官1和副官2说他收到的消息是撤退(R)。那么对于副官1(或副官2)来说,他综合司令、副官3和副官2(或副官1)后得到的消息向量都将会是(A,A,R),利用majority函数之后,将会采用A,满足了IC1和IC2(回顾IC1:所有忠诚的副官遵守一个命令,IC2:若司令是忠诚的,每一个忠诚的副官遵守他发出的命令)。

      (图7:m=1,n=4中司令是是叛徒的情形)

    倘若司令是叛徒,那么我们已经不需要满足IC2。为方便,我们假设叛徒司令在OM(1)会给三个副官发送的信息是(x,y,z),其中x,y,z都可以是A或R的任意一种。之后,三位忠诚的副官将会按照OM(0)要求的那样,交换他们收到的信息。

    对于副官1,他综合司令、副官2和副官3后得到的消息向量将会是(x,y,z),可以发现对于其他两个忠实的副官,他们得到的消息向量也将是(x,y,z)。不管x,y,z如何变化,majority(x,y,z)对于三人来说都是一样的,所以三个副官将会采用一致的行动。

    (3)m=2,n=7的情形 接下来,我们将讨论m=2,n=7的情形,虽然只是多了一个叛徒,但是这里会出现递归过程,所以会复杂很多。

    首先,我们先讨论司令忠诚的情形,假设叛徒为副官5和副官6。

      (图8:m=2,n=7中司令忠诚而副官5和副官6是叛徒的情形)

    在OM(2)中,司令将攻击命令(A)传给各个副官。在OM(1)中,忠诚的副官们将会发送他们收到的消息(A),但由于副官5和副官6是叛徒,他们将会发送别的信息(比如R)。这时,忠诚的副官们将会采用使用OM(1)中的方法来确定各个v1~v6。例如,对于副官1,他收到了司令传来的命令,他会直接采用majority函数综合司令和其他将军传来的信息吗?他不会,因为这还在OM(1)中,他并不知道司令是不是叛徒,他会利用询问别人的方式来确认将军的命令,但是按照算法他会把司令的命令作为v1(即v1=A)并传给其他人。

    接下来他会努力取得其他的v2~v6的值,这时已经在OM(1)中了,副官1绝不会轻易相信别人传来的消息,比如副官2给他传来了命令A,但是他会怀疑副官2传来的消息,所以他用OM(1)大法,问其他人副官2传给了他们什么,副官3和副官4诚实的告诉副官1,副官2给他们传的是A,而这时副官5和副官6又要撒谎了,他们又乱说,我们姑且假定他们传来的是x’和y’吧。这样,终于进入到了OM(0),这时副官1将会综合其他副官对于v2的反馈,得到向量(A,A,A,x’,y’),再利用majority函数,得到了v2=A。如下图,这是副官1在OM(1)中得到的信息(x,y等表示了不确定的命令)。

                                                                                                                                                                                         (图9:司令忠诚时副官1在OM(1)中得到的信息)

    我们就可以得到副官1的v1~v6向量为(A,A,A,A,x,y),利用majority函数,副官1最终采用的行动会是A。 类似的,我们可以发现,其他几个忠诚的副官得到的命令向量都会是(A,A,A,A,x,y),利用majority函数后采用的行动都会是A。所以,我们可以发现忠诚的副官采用的命令都是A(满足IC1),并且和忠诚的将军的命令一致(满足IC2)。至此,您应该已经明白了这个算法是怎么递归的,不管m等于多少,都只是一个算法步骤多寡的问题。 至于司令是叛徒的情形,其实是相似的,这里简单的再提一下便于理解。若您已经明白了算法过程,完全可以跳过。

                                                                                                                                                                    (图10:m=2,n=7中司令和副官6是叛徒的情形)

    为方便,我们假定了副官6是叛徒。司令在OM(2)中就很鸡贼的给副官1~副官6发送了不同的命令(A,R,A,R,A,x)。在OM(1)中,各副官把自己收到的命令传出去,而(为方便,假定)副官6则给其他副官分别发送了(A,R,A,R,A)。类似于前文推演的那样,考虑副官1,他将司令传来的命令A作为v1后,还会询问其他人传来的命令,由此去确认v2~v6,类似的,我们将之表达为下图:

                                                                                                                                                                       (图11:司令反叛时副官1在OM(1)中得到的信息)

    如图,我们就可以得到副官1的v1~v6向量为(A,R,A,R,A,A),利用majority函数,副官1最终采用的行动会是A。类似的,我们可以发现忠诚的副官1~副官5得到的消息向量都是(A,R,A,R,A,A),最终他们采用的行动都会是A(满足了IC1),而司令是叛徒不需要满足IC2。值得提醒的是,若副官6传递的是(R,A,R,A,R),那么他们所有人得到的消息向量都是(A,R,A,R,A,R),此时A和R数量一样多,这并不代表majority不起作用了,他将采用默认值R(回顾前文:majority(v1,…,vn-1)代表了大多数人的命令,若不存在则默认为撤退命令),所有人的行动都会采用R,这同样是满足的。

    到此为止,我们已经将口头算法的实例推演进行的很彻底了,若您还有兴趣,可以试一试当n=7,m=3的时候为什么就不能达成一致了,操作是类似的。 3.3.口头协议算法证明 算法的证明思路其实并不复杂,简单的来说,对于一个递归算法,我们使用数学归纳法来证明是最直观而又有效的方法了。我们回顾一下命题:将军总数为n,叛徒数量为m,OM(m)可以实现,在n>3m的情况下,使得:

    IC1:所有忠诚的副官遵守一个命令。

    IC2:若司令是忠诚的,每一个忠诚的副官遵守他发出的命令。

    为了证明整个命题,我们先引入一个针对IC2的引理:

    引理:对于任意m和k,如果有超过2k+m 个将军和最多k 个背叛者,那么算法OM(m)满足IC2。

    证明:

    (1)m=0,而将军是忠诚的,直接满足IC2;

    (2)m>0,此时假定OM(m-1)是有效的,那么只需要考虑OM(m)这一轮即可。

    n>2k+m,意味着n-1>2k,n-1是除了司令以外的所有副官,而所有副官的数量比叛徒的两倍还多,那他们直接利用majority函数的时候,就可以直接正确得到司令的命令。
    可以发现,这个引理说明了如果只需要考虑IC2,将军总数是不需要3倍背叛者之多的,接下来我们回归命题。

    证明:

    首先考虑司令是忠诚的,令引理中的k=m,直接得到OM(m)可以满足IC2。

    这时,我们只用考虑司令是叛徒的状况。同样利用数学归纳法。

    (1)m=1,之前我们已经推演过OM(1)可以满足1个叛徒司令,3个忠诚副官的情况;

    (2)m>1,那么假设n’>3m’的情况下,OM(m-1)能够满足IC1和IC2。

    由于司令是叛徒,在OM(m)中司令会把命令发给各个副官,而这些副官中会有m-1个叛徒。在下一轮中,副官的数量至少有3m个,叛徒数为m-1,很显然3m>3(m-1),也就是说n’>3m’,根据假设,OM(m-1)可以满足IC1和IC2,尽管司令是叛徒,由于OM(m-1)是有效的,OM(m)这一轮中忠诚的副官可以得到相同的(v1,…,vn-1)向量,所以忠诚的副官将会利用majority函数采用相同的命令,得证。

    总结一下,口头协议中,我们始终要求的是相同的(v1,…,vn-1)向量,只要这个向量是相同的我们怎么处理都可以。又由于算法是递归的,所以我们一定需要把这个处理方法变得通用而逻辑有效才行,所以我们才选用了majority函数这个算法。这一点至关重要却又没有这么直观,因为我们的第一反应是要得到相同的majority函数值。但是反过来一想,既然算法是递归的,majority函数值相同不就意味着(v1,…,vn-1)向量相同吗?正确理解递归的思想是使用该算法和利用数学归纳法证明该算法的关键点。

    至此,我们已经大致明确了口头协议是怎么回事,可以做到什么不能做到什么,以及这个算法的推演和证明。很多系统都会出现口头协议的情况,即各个系统节点可以把自己的消息准确的发送出去,同时可以知道消息的来源于何处。但是,这个方法的消息并不能追本溯源,这使得在口头协议中至少得四模冗余,我们可以试图找到一个方法,让消息能够追本溯源,可以想象这能够拓宽使用条件,这个方法可以是书面协议。

     

    Part4:书面协议

     

    口头协议中我们讨论了很多,揭示了口头协议的缺点是消息不能追本溯源,这使得口头协议必须在四模冗余的情况下才能保证正确。但是,若能引入一种方法让消息能够追本溯源,情况会不会有所改变呢?这就是书面协议引入的灵感。

    除了A1,A2和A3以外,我们在口头协议之上添加一个条件A4,使之成为书面协议

    A4:(a)签名不可伪造,一旦被篡改即可发现,而叛徒的签名可被其他叛徒伪造;(b)任何人都可以验证签名的可靠性。

    那么,我们先说结论:对于任意m,最多只有m个背叛者情况下,算法SM(m)能解决拜占庭将军问题。也就是说,在使用签名的情况下,书面协议可以打破三模冗余的僵局,使用了签名的情况下,只要知道了叛徒数量,我们就可以利用SM(m)算法解决拜占庭将军问题。

     

    4.1.书面协议算法SM(m)

     

    口头协议算法我们已经讨论过很多了,所以笔者对书面协议尽量简短的介绍。回顾

    IC1:所有忠诚的副官遵守一个命令,即一致性。

    IC2:若司令是忠诚的,每一个忠诚的副官遵守他发出的命令,即正确性。

    我们要找到一个算法SM(m),不管将军总数n和叛徒数量m,只要采用该算法,忠诚的将军总能达到一致(满足IC1和IC2)。我们用集合Vi来表示i副官收到的命令集,这是一个集合,也就是满足互异性(没有重复的元素)等集合的条件。类似的,我们定义choice(V)函数来决定各个副官的选择,这个函数可以有非常多种形式,他只要满足了以下两个条件:

    (1)如果集合V只包含了一个元素v,那么choice(V)=v

    (2)choice(o)=RETREAT,其中o是空集

    任何满足了这两个条件的函数都可以作为choice(),例如取平均值就可以。我们只需要根据具体情形定义choice()即可,这个非重点,笔者并不加以讨论,您可以自行思考。之后我们会发现SM(m)算法并不是一个递归算法,我们只要让各个副官收到的V集相同,choice(V)也一定能够得到相同的值。

    简单解释该算法如下:

    初始化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)。

    值得注意的是,如果司令忠诚,由于其签名不可伪造,所有忠诚的副官都将得到一个单点集{v},他们采用的命令集Vi相同,得到的choive(Vi)也为v,满足了IC1和IC2。

    如果司令并非忠诚,只需要满足IC1,但是算法SM(m)使得所有忠诚的副官得到相同的Vi,使用choice()函数后采用的命令也就一定相同。

     

    4.2.书面协议实例推演

     

    司令是叛徒的状况稍难想象,举个例子,n=3,m=1,其中司令是叛徒,这是口头协议不能解决的状况。

                                                                                                                                                                                 (图12:m=1,n=3中司令是叛徒的情形)

    很显然,副官1得到的V1={A,R},副官2得到相同的V2={A,R}。他们采用choice函数后得到的命令一定相同。

    相似的,n=4,m=2,其中司令是叛徒,这同样是口头协议不能解决的状况。

     

    (图13:m=2,n=4中司令和副官3是叛徒的情形)

    副官1和副官2得到的V1=V2={A,R},他们采用choice函数后得到的命令也相同。即使命令不是布尔值,经过上面的分析框架,也可以得到相似的结论。至于这个算法的证明,有兴趣的读者可以参考Lamport的原文,笔者就不做过多解释了,如有问题仍可与笔者联系。

                                                                                                                                                                                (图14:Lamport在论文中对书面协议算法的证明)

    书面协议的本质就是引入了签名系统,这使得所有消息都可追本溯源。这一优势,大大节省了成本,他化解了口头协议中1/3要求,只要采用了书面协议,忠诚的将军就可以达到一致(实现IC1和IC2)。这个效果是惊人的,相较之下口头协议则明显有一些缺陷。

    书面协议的结论非常令人兴奋,这不是解决了拜占庭将军问题了吗?但请注意我们在A1~A4中实际上是添加了一些条件的,这使得拜占庭将军问题在这些假设下能够解决,但是在实际状况中却会有一些问题。观察A1~A4,我们做了一些在现实中比较难以完成的假设,比如没考虑传输信息的延迟时间,书面协议的签名体系难以实现,而且签名消息记录的保存难以摆脱一个中心化机构而独立存在。事实上,存在能够完美解决书面协议实际局限的方法,这个方法就是区块链。如果您感兴趣,也可以参考笔者同系列的文章《大材小用——用区块链解决拜占庭将军问题》。

    作者:毒毒程
    审校:初夏虎 村长
    责编:printemps

    稿源:巴比特资讯



    每次我向那些不熟悉比特币的人解释比特币的独特之处的时候,我都会用会计学上的总账和拜占庭将军问题来帮助讲解。此文就是帮助讲解的内容,有了此文我就可以把链接发给小伙伴们,而不需要每次都重新打一大堆字了。

    比特币与拜占庭将军问题

    首先,不要把比特币当成一种货币,而是一个总账。它是个电子总账,网络上的每一个参与者的电脑都会有一份总账的备份,并且所有的备份都是在实时的持续的更新、对账、以及同步着。每一个参与者都能在这本总帐里记上一笔,这一笔记录着一定数量的币从一个参与者那里被发送到另一个参与者那里,并且每一条这样的记录都接着就实时的广播到网络了,所以在每一台电脑上的每一分份拷贝都是几乎同时更新的,并且所有的总账拷贝都保持着同步。这本公开的分布式的总账的官方叫法是“区块链(blockchain)”,并且它使用了BT技术以保证所有的拷贝都是同步的。

    你还可以把比特币当作一个对于在分布式系统领域的一个复杂的算法难题的通用解决方法,这个难题俗称“拜占庭容错”、“拜占庭将军问题”、或者“两军问题”。

    这一问题的趣味非正式表述如下:想象一下,在拜占庭时代有一个墙高壁厚的城邦,拜占庭,高墙之内是它的邻居想象不到之多的财富。它被其他10个城邦所环绕,这10个城邦也很富饶,但和拜占庭相比就微不足道了。它的十个邻居都觊觎拜占庭的财富,并希望侵略并占领它。

    但是,拜占庭的防御是如此的强大,没有一个相邻的城邦能够成功入侵。任何单个城邦的入侵行动都会失败,而入侵者的军队也会被歼灭,使得其自身容易遭到其他九个城邦的入侵和劫掠。这十个城邦之间也互相觊觎对方的财富并持续互相对抗着。而且,拜占庭的防御如此之强,十个邻居的一半以上同时进攻才能攻破它。

    也就是说,如果六个或者更多的相邻敌军一起进攻,他们就会成功并获得拜占庭的财富。然而,如果其中有一个或者更多背叛了其他人,答应一起入侵但在其他人进攻的时候又不干了,也就导致只有五支或者更少的军队在同时进攻,那么所有的进攻军队都会被歼灭,并随后被其他的(包括背叛他们的那(几)个)邻居所劫掠。这是一个由不互相信任的各方构成的网络,但他们又必须一起努力以完成共同的使命。

    而且,是个邻居之间通讯和协调统计时间的唯一途径是通过骑马在他们之间传递信息。他们不能聚在一个地方开个会(所有的王都不互相信任他们的安全在自己的城堡或者军队范围之外能够得到保障)。然而,他们可以在任意时间以任意频率派出任意数量的信使到任意的对方。每条信息都包含类似如下的内容:“我将在第四天的6点钟进攻,你愿意加入吗?”。

    如果收信人同意了,他们就会在原信上附上一份签名了的/认证了的/盖了图章的/验证了的回应,然后把新合并了的信息的拷贝再次发送给九个邻居,要求他们也如此这样做。最后的目标是,通过在原始信息链上盖上他们所有十个人的图章,让他们在时间上达成共识。最后的结果是,会有一个盖有十个同意同一时间的图章信息链,可能还会有一些被抛弃了的包含部分但不是全部图章的信息链。

    但是,问题在于如果每个城邦向其他九个城邦派出一名信使,那么就是十个城邦每个派出了九名信使,也就是在任何一个时间又总计90次的传输,并且每个城市分别收到九个信息,可能每一封都写着不同的进攻时间。除此以外,部分城邦会答应超过一个的攻击时间,故意背叛发起人,所以他们将重新广播超过一条的信息链。这个系统迅速变质成不可信的信息和攻击时间相互矛盾的纠结体。

    比特币通过对这个系统做出一个简单的(事后看是简单的)修改解决了这个问题,它为发送信息加入了成本,这降低了信息传递的速率,并加入了一个随机元素以保证在一个时间只有一个城邦可以进行广播。它加入的成本是“工作量证明”,并且它是基于计算一个随机哈希算法的。哈希是一种算法,它唯一做的事情就是获得一些输入然后进行计算,并得到遗传64位的随机数字和字母的字符串,就像这个:

    d70298566aa2f1a66d892dc31fedce6147b5bf509e28d29627078d9a01a8f86b

    在比特币的世界中,输入数据包括了到当前时间点的整个总账(区块链)。并且尽管单个哈希值用现在的计算机可以几乎即时的计算出来,但只有一个前13个字符是0的哈希值结果可以被比特币系统接受成为“工作量证明”。这样一个13个0的哈希值是极其不可能与罕见的,并且在当前需要花费整个比特币网络大约10分钟的时间来找到一个。在一台网络中的机器随机的找到一个有效哈希值之前,上十亿个的无效值会被计算出来,这就是减慢信息传递速率并使得整个系统可用的“工作量证明”。下面是一个例子:

    f51d0199c4a6d9f6da230b579d850698dff6f695b47d868cc1165c0ce74df5e1
    d70298566aa2f1a66d892dc31fedce6147b5bf509e28d29627078d9a01a8f86b
    119c506ceaa18a973a5dbcfbf23253bc970114edd1063bd1288fbba468dcb7f8

    在找到一个有效值之前,成百万上亿个更多的类似上面这样的字符串被计算出来。。。

    000000000000084b6550604bf21ad8a955b945a0f78c3408c5002af3cdcc14f5

    那台发现下一个有效哈希值的机器(或者说在我们类比中的城邦),把所有的之前的信息放到一起,附上它自己的,以及它的签名/印章/诸如此类,并向网络中的其他机器广播出去。只要其他网络中的机器接收到并验证通过了这个13个0的哈希值和附着在上面的信息,他们就会停止他们当下的计算,使用新的信息更新他们的总账拷贝,然后把新更新的总账/区块链作为哈希算法的输入,再次开始计算哈希值。哈希计算竞赛从一个新的开始点重新开始。如此这般,网络持续同步着,所有网络上的电脑都使用着同一版本的总账。

    与此同时,每一次成功找到有效哈希值以及区块链更新的间隔大概是10分钟(这是故意的,算法难度每两周调整一次以保证网络一直需要花费10分钟来找到一个有效的哈希值)。在那10分钟以内,网络上的参与者发送信息并完成交易,并且因为网络上的每一条机器都是使用同一个总账,所有的这些交易和信息都会进入遍布全网的每一份总账拷贝。当区块链更新并在全网同步之后,所有的在之前的10分钟内进入区块链的交易也被更新并同步了。因此分散的交易记录是在所有的参与者之间进行对账和同步的。

    最后,在个人向网络输入一笔交易的时候,他们使用内嵌在比特币客户端的标准公钥加密工具来同时他们的私钥以及接收者的公钥来为这笔交易签名。这对应于拜占庭将军问题中他们用来签名和验证消息时使用的“印章”。因此,哈希计算速率的限制,加上公钥加密,使得一个不可信网络变成了一个可信的网络,使得所有参与者可以在某些事情上达成一致(比如说攻击时间、或者一系列的交易、域名记录、政治投票系统、或者任何其他的需要分布式协议的地方)。

    这里是比特币为何如此特别的关键:它代表了一个对于一个困难的算法上的难题的解决方案,这一解决方案在一系列的历史事件发生之前是不可能的,这些事件有:

    1. 互联网的创造
    2. 公钥加密算法的发明
    3. 点对点Bitorrent(BT)协议的发明。BT协议最开始是开发来用于在网络上的相对小的用户子集之间共享许多文件的,但比特币用它来在所有用户之间共享单个文件。
    4. 人们意识到,在系统中添加一个简单的时间延迟,同时使用公钥加密算法以验证每笔交易,可以解决这个问题。

    如果说一些最棒的想法在事后看来是很简单的,那么上述的第四点就完全符合条件,尽管整个项目是站在了巨人的肩膀上的。

    最后,这一对于拜占庭将军问题的解决方案,可以推广到任何核心问题是在分布式网络上缺乏信任的领域。如我们已经提到乐的,人们正在为互联网建设一个分布式的域名系统,以及为政治选举建设分布式的投票系统(还没有网站)。如果人们认为单纯的文件分享搅乱了这个世界,那么比特币解决方案和协议才刚刚打开洪水的闸门。

    原文 http://expectedpayoff.com/blog/2013/03/22/bitcoin-and-the-byzantine-generals-problem/

    作者 Byron Gibson

    翻译 He1l_Q

    本文如有帮助,请考虑捐助:15X9AMhccjqqPRkhpgraoj7fgdqymW3iSC

    欢迎转载,转载时请注明作者翻译者和出处,谢谢支持!


    展开全文
  • 漫画:什么是拜占庭将军问题?

    万次阅读 多人点赞 2018-05-07 00:00:00
    点击上方“程序员小灰”,选择“置顶公众号”有趣有内涵的文章第一时间送达!————— 第二天 —————————————————什么是拜占庭将军问题?在很久很久以前,拜...
        

    点击上方“程序员小灰”,选择“置顶公众号”

    有趣有内涵的文章第一时间送达!



    640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1



    640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1



    —————  第二天  —————



    640?wx_fmt=jpeg



    640?wx_fmt=jpeg



    640?wx_fmt=jpeg



    640?wx_fmt=jpeg



    640?wx_fmt=jpeg



    ————————————



    640?wx_fmt=jpeg

    640?wx_fmt=jpeg



    640?wx_fmt=jpeg



    640?wx_fmt=jpeg



    什么是拜占庭将军问题?


    在很久很久以前,拜占庭是东罗马帝国的首都。那个时候罗马帝国国土辽阔,为了防御目的,因此每个军队都分隔很远,将军与将军之间只能靠信使传递消息。


    640?wx_fmt=png



    在打仗的时候,拜占庭军队内所有将军必需达成一致的共识,才能更好地赢得胜利。但是,在军队内有可能存有叛徒,扰乱将军们的决定。


    640?wx_fmt=jpeg


    这时候,在已知有成员不可靠的情况下,其余忠诚的将军需要在不受叛徒或间谍的影响下达成一致的协议。


    莱斯利·兰伯特( Leslie Lamport )通过这个比喻,表达了计算机网络中所存在的一致性问题。这个问题被称为拜占庭将军问题



    640?wx_fmt=jpeg



    640?wx_fmt=jpeg



    什么是 Raft 算法?


    Raft 算法是一种简单易懂的共识算法。它依靠 状态机 主从同步 的方式,在各个节点之间实现数据的一致性。


    在学习Raft算法的时候,大家需要了解Raft的两个核心要点:


    1.选取主节点


    2.同步数据



    不难理解,使用主从同步的方式,可以让集群各个节点的数据更新以主节点为准,从而保证了一致性。那么,如何选取主节点呢?


    640?wx_fmt=jpeg



    640?wx_fmt=jpeg



    640?wx_fmt=jpeg



    我们的出生,离不开无数小蝌蚪之间的激烈竞争。在竞争的过程中,某个速度最快运气最好的小蝌蚪最终胜出,让我们诞生到了这个世界。


    同样道理,Raft算法在选择主节点的过程中,也是通过多个节点之间的投票竞争


    说到这里,不得不说一下Raft算法的状态机。Raft算法为节点定义了三种角色:


    1.Leader(主节点)

    2.Follower(从节点)

    3.Candidate(参与投票竞争的节点


    让我们来看一看选主的具体流程:


    第一步,在最初,还没有一个主节点的时候,所有节点的身份都是Follower。每一个节点都有自己的计时器,当计时达到了超时时间(Election Timeout),该节点会转变为Candidate。



    640?wx_fmt=png



    第二步,成为Candidate的节点,会首先给自己投票,然后向集群中其他所有的节点发起请求,要求大家都给自己投票。



    640?wx_fmt=png



    第三步,其他收到投票请求且还未投票的Follower节点会向发起者投票,发起者收到反馈通知后,票数增加。


    640?wx_fmt=png



    第四步,当得票数超过了集群节点数量的一半,该节点晋升为Leader节点。Leader节点会立刻向其他节点发出通知,告诉大家自己才是老大。收到通知的节点全部变为Follower,并且各自的计时器清零。



    640?wx_fmt=png



    这里需要说明一点,每个节点的超时时间都是不一样的。比如A节点的超时时间是3秒,B节点的超时时间是5秒,C节点的超时时间是4秒。这样一来,A节点将会最先发起投票请求,而不是所有节点同时发起。


    为什么这样设计呢?设想如果所有节点同时发起投票,必然会导致大家的票数差不多,形成僵局,谁也当不成老大。


    那么,成为Leader的节点是否就坐稳了老大的位置呢?并不是。Leader节点需要每隔一段时间向集群其他节点发送心跳通知,表明你们的老大还活着。



    640?wx_fmt=png



    一旦Leader节点挂掉,发不出通知,那么计时达到了超时时间的Follower节点会转变为Candidate节点,发起选主投票,周而复始......



    640?wx_fmt=png



    640?wx_fmt=jpeg



    640?wx_fmt=jpeg



    让我们来看一看数据同步的流程:


    第一步,由客户端提交数据到Leader节点。



    640?wx_fmt=png



    第二步,由Leader节点把数据复制到集群内所有的Follower节点。如果一次复制失败,会不断进行重试。



    640?wx_fmt=png



    第三步,Follower节点们接收到复制的数据,会反馈给Leader节点。



    640?wx_fmt=png



    第四步,如果Leader节点接收到超过半数的Follower反馈,表明复制成功。于是提交自己的数据,并通知客户端数据提交成功。



    640?wx_fmt=png



    第五步由Leader节点通知集群内所有的Follower节点提交数据,从而完成数据同步流程。



    640?wx_fmt=png




    共识算法的应用场景?



    640?wx_fmt=jpeg



    640?wx_fmt=jpeg



    640?wx_fmt=png



    640?wx_fmt=jpeg



    640?wx_fmt=jpeg



    Paxos 算法:

    早期的共识算法,由拜占庭将军问题的提出者 Leslie Lamport 所发明。谷歌的分布式锁服务 Chubby 就是以 Paxos 算法为基础。


    ZAB 算法:

    Zookeeper 所使用的一致性算法,在流程上和 Raft 算法比较接近。


    PBFT 算法:

    区块链技术所使用的共识算法之一,适用于私有链的共识。



    640?wx_fmt=jpeg




    —————END—————


    640?wx_fmt=png



    喜欢本文的朋友们,欢迎长按下图关注订阅号程序员小灰,收看更多精彩内容

    640?wx_fmt=jpeg

    展开全文
  • 拜占庭将军问题

    万次阅读 2019-05-15 18:42:54
    拜占庭将军问题”是由著名计算机科学家莱斯利•兰伯特(LeslieLamport)提出的点对点通信中的基本问题,也可称为“两军问题”或者“拜占庭容错”。 在5〜15世纪,拜占庭就是当时的东罗马帝国,也就是现在土耳其的...

    拜占庭将军问题”是由著名计算机科学家莱斯利•兰伯特(LeslieLamport)提出的点对点通信中的基本问题,也可称为“两军问题”或者“拜占庭容错”。

    在5〜15世纪,拜占庭就是当时的东罗马帝国,也就是现在土耳其的伊斯坦布尔。可以想象,拜占庭军队有许多分支,驻守在敌人城外随时准备进攻,每一个分支都有各自的将军。当时的环境决定了骑马传递信息是将军之间通信和协调统计进攻时间的唯一途径。

    由于敌人的防御比较强大,任何一个军队分支的单独入侵行动都会失败,而且入侵的分支还会被歼灭。因此,只有一半以上的分支同时进攻才能成功占领敌人的城池。

    在观察了敌情以后,将军们需要制订出一个统一的进攻计划,即确定出在哪一天的哪一时刻进攻。然而将军中存在一个叛徒,他的任务就是破坏忠诚将军们的进攻计划,使他们的进攻不能达成一致。这样只要进攻时的军队分支少于一半,敌人就会胜利,叛徒的目的就达到了。这是一个由互不信任的各方构成的网络,但是他们需要完成一个共同使命(除叛徒以外)。

    由于各个将军之间互相不信任,认为只有在自己的城堡以及军队范围内才能保障自己的生命安全,所以将军们不会聚集到一起开会。在这种情况下,他们在任意时间以任意P率派出任意数量的信使到任意对方,内容如下:“我将在第X天的第X点进攻,你同意吗?”

    如果收到信息的将军同意该做法,他就会在原信上附上一份盖章验证的回信,然后把合并之后的信息拷贝再次发送给其余的将军们,要求他们也这样做。他们的目标就是通过原始信息的积累使最后的信息链盖上他们所有将军的图章,在时间上达成共识。

    问题出现在这里,假设有10个将军,每个将军向其他9个将军派出一名信使,那么就是10个将军每人派出了9名信使,而在任意时间内有总计90次的传输,并且每个将军分别收到9个信息,可能每一封信的进攻时间都不同。另外,叛变的将军还会同意超过一个以上将军的攻击时间,然后重新广播超过一条的信息链。于是,这个系统迅速演变成一个信息虚假和攻击时间相互矛盾的纠结体。

    展开全文
  • PBFT(拜占庭容错)

    2018-06-08 14:45:46
    PBFT(拜占庭容错)基于拜占庭将军问题,一致性的确保主要分为这三个阶段:预准备(pre-prepare)、准备(prepare)和确认(commit)。流程如下图所示:其中C为发送请求端,0123为服务端,3为宕机的服务端,具体步骤如下...

    PBFT(拜占庭容错)

    基于拜占庭将军问题,一致性的确保主要分为这三个阶段:预准备(pre-prepare)、准备(prepare)和确认(commit)。流程如下图所示:
    其中C为发送请求端,0123为服务端,3为宕机的服务端,具体步骤如下:
    1. Request:请求端C发送请求到任意一节点,这里是0
    2. Pre-Prepare:服务端0收到C的请求后进行广播,扩散至123
    3. Prepare:123,收到后记录并再次广播,1->023,2->013,3因为宕机无法广播
    4. Commit:0123节点在Prepare阶段,若收到超过一定数量的相同请求,则进入Commit阶段,广播Commit请求
    5.Reply:0123节点在Commit阶段,若收到超过一定数量的相同请求,则对C进行反馈
    根据上述流程,在 N ≥ 3F + 1 的情況下一致性是可能解決,N为总计算机数,F为有问题的计算机总数
    N=4 F=0 时:

     


    得到数据最终数据
    A1 1 1 11
    B1 1 1 11
    C1 1 1 11
    D1 1 1 11

     

    N=4 F=1 时:

     


    得到数据最终数据
    A1 1 1 01
    B1 1 0 11
    C1 0 1 11
    D0 1 1 11

     


    N=4 F=2 时:

     


    得到数据最终数据
    A1 1 0 0NA
    B1 0 0 1NA
    C0 0 1 1NA
    D0 1 1 0NA

     

    由此可以看出,拜占庭容错能够容纳将近1/3的错误节点误差,IBM创建的Hyperledger就是使用了该算法作为共识算法。
    展开全文
  • 拜占庭容错(BFT)介绍

    千次阅读 2019-06-03 10:26:52
    链客,专为开发者而生,有问必答! 此文章来自链客区块链技术问答社区,未经允许拒绝转载。 自2008年比特币作为一种作为点对点的电子现金系统出现开端,许多加密钱银都被发明出来,每个加密钱银都有其特定的机制。...
  • 拜占庭问题

    2019-01-05 15:10:22
    1.拜占庭问题  拜占庭问题是分布式系统中的模型基础,也是区块链的核心。其根本是假设在消息传输过程中,在信道可靠的情况下,如何在有信息欺骗的情况下,做到有效容错,从而做出正确的决策。 二、相关解决方案 ...
  • 拜占庭问题与算法

    千次阅读 2018-12-04 17:05:43
    拜占庭问题(Byzantine Problem)又叫拜占庭将军(Byzantine Generals Problem)问题,讨论的是允许存在少数节点作恶(消息可能被伪造)场景下的如何达成共识问题。拜占庭容错(Byzantine Fault Tolerant,BFT)讨论...
  • 拜占庭故障

    千次阅读 2017-12-26 12:37:53
    1、拜占庭故障具体是什么分类呢? 2、拜占庭故障出现在哪里?出现在硬件中,还是软件中,出现在操作系统中吗? 比如,拜占庭故障会不会出现在云计算中。博客一:拜占庭故障(zz) 这个问题是在1982年由Lamport, ...
  • 拜占庭问题深入探讨

    2017-11-01 17:08:16
    拜占庭问题、两军问题、口头协议、书面协议深入介绍。
  • 区块链 :拜占庭将军问题 [BFT]

    万次阅读 2019-04-18 09:38:59
    什么是拜占庭将军问题: 通俗分析: 问题抽象: 中本聪的解决方案: 经济学分析 REFERENCE 正文 回到顶部 背景:  拜占庭将军问题很多人可能听过,但不知道具体是什么意思。那么究竟什么是拜占庭将军...
  • 拜占庭将军

    千次阅读 2018-03-06 11:52:00
    拜占庭将军问题很多人可能听过,但不知道是什么意思,本文从非专业的角度来讲讲,拜占庭将军问题到底是说什么的。 拜占庭将军问题(Byzantine Generals Problem),首先由Leslie Lamport与另外两人在1982年提出,很...
  • 拜占庭

    2018-06-18 09:07:00
    区块链书籍(来源) 两军问题 拜占庭问题 口头协议 书面协议 BFT PBFT 转载于:https://www.cnblogs.com/ycx95/p/9194450.html
  • 拜占庭问题论文翻译

    2020-04-16 20:37:10
    这种情况可以用拜占庭军队的将军和他们的部队围困在敌方城市附近来概括地表达。 将军们只能通过使者交流,他们必须商定共同的战斗计划。 但是,其中一个或多个可能是叛徒,他们会试图混淆其他人。 问题是找到一种...
  • 拜占庭

    2014-03-16 23:39:26
    拜占庭问题-----》 主要是忠诚的将军如何在意见上达到一致,其他的叛徒将军不考虑,其他条件不考虑。   条件有两个: IC1:所有忠诚的副官遵守相同的命令。(协议的制定) IC2:如果发送命令的将军是忠诚的,...
  • 拜占庭将军问题深入探讨

    千次阅读 2018-01-29 15:16:28
    了解过比特币和区块链的人,多少都听说过拜占庭将军问题,或听说过比特币(或区块链)的一个重要成就正是解决了拜占庭将军问题。但真正明白这个问题的人并不多,甚至知道这个问题实质的人都很罕见。本文是一篇技术...
  • 了解过比特币和区块链的人,多少都听说过拜占庭将军问题,或听说过比特币(或区块链)的一个重要成就正是解决了拜占庭将军问题。但真正明白这个问题的人并不多,甚至知道这个问题实质的人都很罕见。本文是一篇技术...
  • 通俗易懂解释拜占庭容错

    千次阅读 2018-03-18 03:39:02
    作者:苏江同学  ...拜占庭将军问题很多人可能听过,但不知道是什么意思,本文从非专业的角度来讲讲,拜占庭将军问题到底是说什么的。 拜占庭将军问题(Byzantine Generals Problem),首先由Leslie Lamp...
  • 什么是拜占庭将军问题

    千次阅读 2018-02-07 12:24:23
    接触区块链的同学,多少都听说过拜占庭将军问题,经常看到或听到某某区块链使用某某算法解决了拜占庭将军问题,那么究竟什么是拜占庭将军问题呢? 什么是拜占庭将军问题 也被称为“拜占庭容错”、“拜占庭将军...
  • 【本文转自拜占庭将军问题深入探讨】了解过比特币和区块链的人,多少都听说过拜占庭将军问题,或听说过比特币(或区块链)的一个重要成就正是解决了拜占庭将军问题。但真正明白这个问题的人并不多,甚至知道这个问题...
  • 区块链的最早应用是比特币,而比特币的概念最初由中本聪在2009年提出,根据中本聪的思路设计发布的开源软件以及建构其上的P2P网络构成比特币系统...了解过比币和区块链的人,多少都听说过拜占庭将军问题,区块链正是...

空空如也

1 2 3 4 5 ... 20
收藏数 11,836
精华内容 4,734
关键字:

拜占庭