从分布式一致性到共识机制(三)拜占庭问题

分布式一致性问题,区块链里体现就是共识问题。
共识机制就是在一个群体中的个体经过某种方式达成一致性的一种机制,好比在一个团队、或者一个公司里的个体意见不一致时,就须要有一个领导,由领导来作决定,保证团队达成共识。web

目前的共识算法,主要有基于算力的POW,基于股权的POS和基于投票的DPOS算法,以及著名的拜占庭容错算法。算法

1、共识机制

团队里的共识机制延伸到普通的分布式系统里面,就是系统须要有一个master,系统的全部决定都由master来达成共识,在分布式系统里面master的选举其实就是基于某种共识机制达成共识。网络

到了区块链中,因为区块链是一种去中心化的分布式系统,因此区块链中是没有相似于团队里的领导,以及分布式系统中的master的角色,这样就须要有某种共识机制,以便保证系统一致性。分布式

实际上当节点之间的通讯网络不可靠的状况下,系统是没法达成共识的,具体缘由请参考“两军问题"。
即便在网络通讯可靠的状况下,一个可扩展的分布式系统的共识问题也是无解的。这个结论被称为”FLP不可能性原理“。通常的把故障(不响应)即信道不可靠的状况称为”非拜占庭错误“,恶意响应(即系统被攻击)称为”拜占庭错误“。函数

2、拜占庭将军问题

拜占庭将军问题是一个共识问题: 首先由Leslie Lamport与另外两人在1982年提出,被称为The Byzantine Generals Problem或者Byzantine Failure。核心描述是军中可能有叛徒,却要保证进攻一致,由此引伸到计算领域,发展成了一种容错理论。区块链

论文地址:
The Byzantine Generals Problemspa

一群将军想要实现某一个目标(一致进攻或者一致撤退),可是单独行动行不通,必须合做,达成共识;因为叛徒的存在,将军们不知道应该如何达到一致。日志

1.两军问题和TCP协议

拜占庭将军问题中并不去考虑通讯兵是否会被截获或没法传达信息等问题,即消息传递的信道绝无问。Lamport已经证实了在消息可能丢失的不可靠信道上试图经过消息传递的方式达到一致性是不可能的。因此,在研究拜占庭将军问题的时候,咱们已经假定了信道是没有问题的,并在这个前提下,去作一致性和容错性相关研究。blog

若是须要考虑信道是有问题的,这涉及到了另外一个两军问题,两军问题在经典情境下是不可解的,现代通讯系统中应用三次握手与TCP协议来处理此类问题,不过这也只是一种相对可靠的方式。递归

2.口头协议算法

Lamport论文:

对于这个算法须要说明的是:

(1) 在第一轮将军会把消息发送给全部的副官,第i个副官收到的记为 Vi。如 1(这里表明的是Attack)

(2) 在第二轮里面,Li(即第i个副官)会怀疑将军发来的消息Vi是对仍是错,因而他会问其他的副官。这样他就会获得剩下的(n-2)个副官的值。 i从1到n-1,因此每一个副官都会获得剩余的n-2个副官手里的Vi。在这一步骤里,忠诚的副官j会直接将本身的 Vj发送给其它人。叛徒则会发假消息。

在n=7,m=2的时候 若是将军是忠臣的话,那么在第二轮忠诚的副官确实已经能够判断出要作的决定,由于他们会收到(1 1 1 0 0 )再加上将军发来的1就是 1 1 1 1 0 0 可是这个算法是递归的全部必需要到第三轮。而且若是将军是个叛徒的话,那么第二轮有情形是作不出决定的。

这里对进入第三轮的解释是,如L1收到其它L2~L6发来的Vj, 可是他要怀疑准确性,好比L1会想L2发给本身是不是正确的呢?那么就进入第三轮进行投票。

(3)在第三轮里面,接着(2)中后面的问题。L1会依次询问L3,4,5,6 ,问他们上一轮L2给他们发了什么,而后L1会获得在(2)中 L2->L3, L2->L4,L2->L5, L2->L6的值 这样再结合本身的L2->L1的值,从这5个里面用majority函数投出决定获得L2发给本身的消息值。依次再进行L3,L4,L5,L6在第二轮中发给本身的消息的确认。

这样L1就完成了第二轮的确认。以后L1再从第一步中将军发给本身的vi和第二轮中肯定的5个值中投出本身的决定。

其他的L2,L3后续也进行一样的步骤。

3.书面协议算法

书面协议和口头协议最大区别是,副官能够叛变而且说谎,也就是中国人讲的口说无凭。
如今咱们给消息加上将军的签名,必须经过签名来验证,就是为了防止说谎。

在签名算法中加了两个条件:

  • 忠诚将军的签名是不能伪造的,内容修改可检测
  • 任何人均可以识别将军的签名,叛徒能够伪造叛徒司令的签名

这里Lamport规定,每条消息只能够复制,而后加上本身的姓名再发出去。

Lamport论文:

3、PBFT 实用拜占庭算法

这里借用一个类比(知乎[Devin Zeng]:

PBFT算法要求至少要4个参与者,一个被选举为总司令,3个师长。总统对总司令下达命令,大家向前行军500千米,总司令就会给3个师长发命令向前行军500千米。3个军长收到消息后会执行命令,并汇报结果。A师长说我在首都以东500千米,B师长说我在首都以东500千米,C师长说我在首都以东250千米。总司令总结3个师长的汇报,发现首都以东500千米占多数(2票>1票),因此就会忽略C军长的汇报结果,给总统说,好了,如今部队是在首都以东500千米了。

1.五个概念

client:请求(request)资源者
replica:副本,全部参与提供服务的节点
primary:承担起提供服务主要职责的节点
backup:其余副本,但相对于primary角色
view:处于存在primary-bakup场景中的相对稳定的关系,叫视图。
若是primary出现故障,这种相对稳定的视图关系就会转变(transit),某个backup转变为primary。

2.四个阶段

client请求阶段,客户端请求资源。

预准备(pre-prepare):主节点向全部backup节点发送预准备消息,其中包括当前视图编号,client请求以及请求摘要,签名是否一致等。

准备(prepare):包括主节点在内的全部副本节点在收到准备消息以后,对消息的签名是否正确,视图编号是否一致,以及消息序号是否知足水线限制这三个条件进行验证,若是验证经过则把这个准备消息写入消息日志中。

确认(commit):每一个副本接受确认消息的条件是:1)签名正确;2)消息的视图编号与节点的当前视图编号一致;3)消息的序号n知足水线条件,在h和H之间。一旦确认消息的接受条件知足了,则该副本节点将确认消息写入消息日志中。

回复(reply):结果反馈。

共识真的不能达成吗

关于拜占庭等问题的讨论只是学术上极端状况下的理论值,现实中的物理系统远比这个要复杂,咱们付出必定的代价老是能作到必定程度的共识。

参考
拜占庭将军问题深刻探讨

相关文章
相关标签/搜索