【虾说区块链】分布式系统共识的FLP不可能原理与CAP猜测

欢迎收听「虾说区块链」。如今区块链这个概念在互联网上至关火热，这里简单作一个普及，不涉及项目推广投资，单纯地对区块链相关基础知识概念做一个说明讲解。本人区块链技术爱好者，结合相关区块链资料总结整理了「虾说区块链」，也是本身一个学习笔记，涉及相关内容如理解有误，也请及时指正。

1

共识机制基础概念

首先，共识机制在分布式系统中是无解的，为何说是无解，众多的节点之间通讯，必然存在网络自身不可靠的缘由、主机故障缘由、恶意操控等缘由，故是没法保证明现彻底的共识，这里不是笔者随便下的结论，Fischer, Lynch 和 Patterson三位在1985年就提出了一个FLP不可能原理：在网络可靠的前提下，任意节点失效，一个或者多个的最小化异步模型系统中，不可能存在一个解决一致性问题的肯定性算法。这三位的论文后来得到了Dijkstra奖。这一理论已被可靠的论证过，因此不用再花大力气在异步分布式系统中去设计一个彻底一致的共识算法。（这里不深究FLP原理，有兴趣能够百度Lynch的<Distributed Algorithms>）

FLP说明在异步分布式系统中彻底一致性是不可能的，但这是一个科学理论，应用到现实工程中，咱们能够牺牲一些代价把不可能变成可能，这就是科学和工程的最大区别，就像你炒股吧，官方确定会告诉你股市有风险，入市需谨慎，但你确定认为在你高超的操做下仍是能赚钱的。那在计算机工程领域中2000年 Eric Brewer在ACM 研讨会提出猜测，CAP猜测，CAP拆解后就是一致性（Consistency）全部节点上的数据时刻保持同步、可用性（Availablity）每一个请求都能接受到一个响应不论响应成功或失败、分区容忍性（Partition）系统内部有消息失效的状况下仍能提供持续服务。

实际运用在工程环境下，适当取舍这三者，一致性、可用性和分区容错性三者没法在分布式系统中被同时知足，而且最多只能知足其中两个。这样就出现了如下三种状况：

1）CA without P：若是不要求P（不容许分区），则C（强一致性）和A（可用性）是能够保证的。但其实分区不是你想不想的问题，而是始终会存在，所以CA的系统更多的是容许分区后各子系统依然保持CA。Zookeeper为此类设计。

2）CP without A：若是不要求A（可用），至关于每一个请求都须要在Server之间强一致，而P（分区）会致使同步时间无限延长，如此CP也是能够保证的。不少传统的数据库分布式事务都属于这种模式。MongoDB、Redis为此类设计。

3）AP wihtout C：要高可用并容许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每一个节点只能用本地数据提供服务，而这样会致使全局数据的不一致性。CouchDB、cassandra为此类设计。

CAP猜测出现至今都一直存在不少质疑，有人提出概念的混乱、不适应数据库事务架构等各类质疑，2002年对CAP猜测被证明为一个定理，证实了CAP三者不可能同时知足，但没有证实任意二者均可知足，对C\A\P做了更明确的声明：

(论文原文：http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf)，

最初这个辩证是在webserver集群环境下的。

1）C：一致性被称为原子对象，任何的读写都应该看起来是“原子“的，或串行的。写后面的读必定能读到前面写的内容。全部的读写请求都好像被全局排序。

2）A：对任何非失败节点都应该在有限时间内给出请求的回应。（请求的可终止性）

3）P：容许节点之间丢失任意多的消息，当网络分区发生时，节点之间的消息可能会彻底丢失。

质疑一直存在。2012年lynch重写论文，再次对CAP作了进一步的解释：

把CAP理论的证实局限在原子读写的场景，并申明不支持数据库事务之类的场景。

一致性场景不会引入用户agent，只是发生在后台集群以内。

把分区容错归结为一个对网络环境的陈述，而非以前一个独立条件。这实际上就是更加明确了概念。

引入了活性(liveness)和安全属性(safety)，在一个更抽象的概念下研究分布式系统，并认为CAP是活性与安全熟悉之间权衡的一个特例。其中的一致性属于liveness，可用性属于safety。

把CAP的研究推到一个更广阔的空间：网络存在同步、部分同步；一致性性的结果也从仅存在一个到存在N个（部分一致），引入了通讯周期round，并引用了其余论文，给出了为了保证N个一致性结果，至少须要通讯的round数。

（论文原文：http://groups.csail.mit.edu/tds/papers/Gilbert/Brewer2.pdf）

谈论了以上CAP原理，目的就是为了说明共识机制是相对的，目前没有一种决对完美的共识机制，全部各类共识机制都是理论结合工程实践产生的。

2

拜占庭问题

拜占庭将军问题就会时常看到，拜占庭将军问题是一个协议问题，拜占庭帝国军队的将军们必须全体一致的决定是否攻击某一支敌军。问题是这些将军在地理上是分隔开来的，而且将军中存在叛徒。叛徒能够任意行动以达到如下目标：欺骗某些将军采起进攻行动；促成一个不是全部将军都赞成的决定，如当将军们不但愿进攻时促成进攻行动；或者迷惑某些将军，使他们没法作出决定。若是叛徒达到了这些目的之一，则任何攻击行动的结果都是注定要失败的，只有彻底达成一致的努力才能得到胜利（来自百度百科）。

这里不讨论军事问题，把拜占庭将军问题引入到计算机领域，在分布式系统中，网络中各节点因为硬件设备故障、网络延时或故障、恶意攻击致使整个系统中出现不可预知的错误。把拜占庭将军问题嵌入到分布式系统中说明：

前提：

1.网络中各节点信道可靠。

2.网络中节点数可知为n。

分布式网络中的众多节点，同时更新或者删除数据，必须达到共识的状态，可是有些节点会出现不肯定故障或者恶意篡改，致使分布式节点数据不一致，这个问题现实中是不可避免的。那么要求系统能正常运行，这里引入一个容错的概念，能够在不彻底一致的状态下，系统仍然能够正常运行。

所谓的正常运行有两种概念：

1. 数据的正常更新后提供服务。

2. 因为故障节点过多数据不更新提供服务，再发起一次共识。

如何来定义这个正常运行，这个须要有一个取舍，由于结合实际应用不少因素须要考虑，理论的严谨和工程的取舍这个通常都会有权衡。下面说明经过容错达成的正常运行。

设置一个变量x，节点数为n,假设其中一个节点为i。经过各类条件设置应用场景：

节点i发布请求x，诚实节点收到的是（x一、x2...xi...xn）集合，这些集合内x值一致，那么从i的诚实性考虑，有可能i是诚实节点、也有可能i自己就仍是恶意节点。

i节点是诚实节点，那么其余诚实节点也一样发送x值。

结合1.2，咱们无论i节点的诚实性，全部诚实节点都收到同样的x值集合。

这样网络中节点收到的请求更新一致，若是i是诚实节点，那么保证了正常运行。这种状况将1.2结合系统达到了一致性和正常运行的两个要求。

可是这是理想化的状态在现实网络节点中刚才的假设都是理想化的。经过执行流程来看下：

再假设三个前提：1.x发送均可正确传达到其他节点中。2.接收节点知道发送节点。3.节点知道x消息完整。

那么网络中n个节点，恶意节点为m个，那么n>3m+1。

i发送x给每个节点，每一个节点收到x则更新、未收到默认就为不操做。

每一个节点收到i发送x更新后，恶意节点m发送y其他节点，发送是一个递归过程。

每一个节点收集i发送x信息，恶意节点m接收x值，不发送至其他剩余节点。

下面经过图形说明：

这里n=3，m=1，那么节点i和节点B是诚实节点，可是B节点不知道应该是x仍是y是更新。再引入一个节点：

这种状况下i、b、c节点是诚实节点，x值在b、c集合中出现2次，y出现一次，故达到了共识。这个前提是i是诚实节点，若是i自己就不是诚实节点，i发送不一样三个值，那整个系统没法共识。

n >3m+1 m=2 n=7

这个过程就会比较复杂了，假设a和d是恶意节点，那么每一个诚实节点经过递归方式去接受其他节点的信息，而后收集的到信息集合中经过多数原则来肯定。

b 、c、e、f为诚实节点加上i，系统达成共识。固然i若是是恶意节点，发送不一样消息给下面节点，那么共识将没法成立，可是若是i发送是有一半是x值一半是不一样值，能够推理下。以上推理过程在拜占庭将军问题中称为口头协议。追溯咱们以前写的三个假设中，若是接收者知道发送者，那么就有书面协议。下面对书面协议再做说明：

所谓书面协议，就是网络节点在传输过程当中添加一个签名，任何节点能够验证签名可靠性。

仍是用节点收到的数据集合v，i节点发送x值给各个节点，节点收到v（x），而后发送v（x）：i给其他节点，若是收到的一串值中没有v（x），那么就把这个值添加到本身的v集合中。每一个节点收到值后，经过choice函数判断。在口头协议中三个节点当i节点发送不一样值的时候没法一致，那么这里加上签名后能够看下，以图说明：

这种状况下最后a、b节点接收信息后都是x、y那么在系统中两个节点信息一致。这就解决了3节点口头协议不能完成一致的问题。若是n=4，m=2有兴趣能够再推理一次，结果也是一致的。

综上所述，在拜占庭问题中n>3m+1能获得保证，拜占庭将军问题比较考验整个推理，笔者也是根据本身理解写了点介绍，有不对的请及时指正。

（音频内容来源：“投河自尽的鱼”）

如下是咱们的社区介绍，欢迎各类合做、交流、学习：）

点击“阅读原文”进入直播室听专栏音频

阅读原文