所谓一致性，就是指数据要完整、要同步。比如，我们在网上下了个订单，付了款，商城系统会记录下这些数据，之后无论我 们在哪里访问自己的订单，都能看到同样的结果，即便商城系统出了故障，那一般也会返回一个错误提示而不是给我们一个不一样的结果。再比如银行，我们存了一 笔钱进去，无论到哪里，我们查询银行账户的时候金额也不会变。也就是说，在这些系统中，数据的结果总是一致而同步的，即便这些系统的服务器不止一台，但都 属于同一个中心集群，在内部是可以高效一致同步的。

区块链系统本质就是一个分布式应用软件。分布式系统的首要问题就是如何解决一致性的问题，也就是如何在多个独立的 节点之间达成共识。要注意的是，这里说的是要达成一致，而没有说保证一定要结果正确，比如所有的节点都达成失败状态也是一种一致，说白了就是要成为一致行 动人。如果是中心化的场景，达成一致几乎没有任何问题，但分布式环境并不是那么理想的，比如节点之间的通信可能是不可靠的、会有延迟、会有故障，甚至节点 直接宕机。而在无数个节点之间，如果采用同步的方式来调用，那等于失去了分布式的优点，因为绝对理想的一致性，代价通常是很大的。这样一个模型，通常要求 不发生任何故障，所有节点之间的通信没有任何时差，这几乎就等于是一台计算机了，这样的强一致性往往意味着性能较弱。

历史经验表明，多路处理器和分布式系统中的一致性问题是非常难以解决的。难点在于以下几个方面。

1）分布式系统本身可能出故障。

2）分布式系统之间的通信可能有故障，或者有巨大的延迟。

3）分布式系统运行的速度可能大不相同，有的系统运行很快，而有些则很慢。

但是，一致性是设计分布式系统时必须考虑的问题。一致性问题历史悠久，而且臭名昭著。传统处理一致性问题的方法有两段式提交、令牌环、时间戳等，计算机专业的读者应该有所耳闻。本章将集中讨论与区块链相关的一致性问题和算法。

4.1.1　一致性问题

我们用状态机来解释一致性的问题。所谓状态机是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型，状态可以特指某个系统在某一时刻的数据变量，它具备以下几个特点：

·状态总数是有限的；

·任一时刻，只处在一种状态中；

·某种条件下，会从一种状态转变到另一种状态。

比如进销存系统中某一个时刻的库存状态，银行系统某一时刻的账户状态等，对于分布式系统来说，就是指每个节点拥有 的数据状态。假设我们有n台机器，位于不同位置的机器之间通过网络协同工作，所有机器的初始状态是一模一样的。给它们一组相同的指令，我们希望看到相同的 输出结果，而且希望看到状态的变化也是一样的。比如机器甲的状态是从状态A到B再到C，而如果机器乙的状态是由A直接到C，这种情况就是不一致的。

总而言之，一致性要求分布式系统中每个节点产生同样的结果或者具备同样的状态，看起来就好像是一台机器一样，前提 是没有一个中心服务器作为调度员，这对于分布在互联网上、不在同一个机房内、不属于同一个管理者的分布式系统来说，难度是很大的。出于系统的可用性考虑， 对于分布式系统来说，我们一般希望具备以下能力。

1）分布式系统作为一个逻辑整体，不应该返回错误的结果。

2）只要系统里的大部分机器工作正常，整个分布式系统就能有效运行，这也是分布式系统应用的一个优点，抵抗单点故障。

3）系统的性能是可以横向扩展的，对于分布式系统来说，木桶原理不起作用。

4）分布式系统必须是异步的，也就是说每个节点可以按照自己的时序独立工作，没有全序的时间顺序。

要达到这些要求，可是不容易呢！从生活中我们也可以发现，即便有统一的命令指挥，尚且不一定能完全做到整齐划一， 何况是没有这么一个指挥员呢！在互联网的场景中，任意一个节点的状态，我们都是没法去强力管控的，比如比特币节点，谁能控制网络中的那些节点呢！可能就是 关闭了、断网了，甚至是一个恶意伪装的节点。一切看起来似乎无解。然而实际上，很多时候我们对一致性的要求并没有那么迫切，在一定的约束下，可以实现所谓 的最终一致性，也就是说在某个时刻系统达到了一致的状态。这个节点现在断网了，没问题，等恢复后跟上，通过其他节点来同步自己的数据；那个节点宕机了，也 没问题，恢复后跟上。只要整个网络中绝大部分的节点都是正常工作的，整个系统总能在未来的某一个时刻达成数据状态的一致。

4.1.2　两个原理：FLP与CAP

1.FLP定理

叫FLP是因为提出该定理的论文是由Fischer、Lynch和Patterson三位作者在1985年发表 的，取了各自名字的首字母作为定理名称。看下定义：在网络可靠、存在节点失效（即使只有一个）的最小化异步模型系统中，不存在一个可以解决一致性问题的确 定性算法。在这个原理的前提下，也告诉人们：不要浪费时间去为异步分布式系统设计在任意场景下都能实现共识的算法，在允许节点失效的情况下，纯粹异步系统无法确保一致性在有限时间内完成。

这个其实也很好理解，比如三个人在不同房间回答问题，虽然三个人彼此之间是可以通过电话沟通的，但是经常会有人时 不时地开小差，比如Alice和Bob都回答了某个问题，Lily收到了两者的回答结果，然后玩游戏去了，忘了回复，则三个人永远无法在有限时间内获得最 终一致的答复。这个定理在理论上证明了此路不通，也就节省了后来者的研究时间。

2.CAP定理

CAP定理最早是由Eric Brewer在2000年ACM组织的一个研讨会上提出猜想，后来Lynch等人进行了证明。我们还是先来看下定义：分布式计算系统不可能同时确保一致性、可用性和分区容错性，这三者不可兼得。通过定义我们可以知道，这是一个典型的不可能三角。那么这三个术语具体是什么意思呢？含义如下。

·一致性（consistency）：所有节点在同一时刻能够看到同样的数据，即“强一致性”。

·可用性（availability）：确保每个请求都可以收到确定其是否成功的响应，并且是在有限的时间内。

·分区容错性（partition tolerance）：因为网络故障导致的系统分区不影响系统正常运行，比如1号模块和2号模块不能使用了，但是3号和4号依然能提供服务。

直觉上的论证很简单：如果网络分成了两半，我在一半的网络中给A发送了10个币，在另外一半的网络中给B发送了 10个币，那么要么系统不可用，因为其中一笔交易或者全部两笔都不会被处理，要么系统会变得没有一致性，因为一半的网络会完成第一笔交易，而另外一半网络 会完成第二笔交易。

既然不能同时满足，那么如果弱化对某个特性的支持呢？

（1）弱化一致性

比如软件升级新版本后，过一段时间其他人才更新成功；再如网站更新内容后，浏览器也是刷新后才显示更新内容。很多 时候对于实时的强一致性并没有很高的要求，生活中也有这样的例子：如果事情不那么紧急，就会发个短消息或者发个邮件，等对方看到了再处理；如果紧急的话， 就直接打电话，所以说电话是一种强连接方式，不过很多朋友肯定不喜欢时不时地就有电话打进来吧。

（2）弱化可用性

有些场合对一致性非常敏感，比如银行取款机，一旦系统故障就会拒绝服务，再如飞机上的控制系统，这个时候如果不能 实时处理，那可是要命的。对计算机使用比较熟悉的朋友都知道，很多服务器操作系统都是不带图形界面的，只能靠命令行来处理，因为服务器要提高性能，保持可 靠，会尽量避免加载不必要的模块，这也是一个牺牲可用性的例子。

（3）弱化分区容错性

对于分布式系统来说，分区容错是必然的，幸运的是这种情况出现的概率并不是很大。如果真的是大规模的服务不可用，那无论是什么样的系统都是不能正常工作的。

计算机系统的设计，有时候跟生活中的场景是很类似的，你不得不做出一些妥协以便保证自己最想要得到的结果。区块链系统中，尤其是公有链系统，使用各种共识算法，优先的目的就是要保证整个系统的容错能力，这也是设计为分布式或者去中心结构的目的之一。

4.1.3　拜占庭将军问题

拜占庭将军问题的经典描述是：拜占庭的军队是由小分队组成的，每个小分队由一个将军指挥，将军们通过传令兵来策划 一系列的行动。有些将军是叛徒，他们会有意地妨碍忠诚的将军达成一致的计划。这个问题的目标是使忠诚的将军达成一致的计划，即使背叛的将军一直在诱使他们 采用糟糕的计划。已经证明，如果背叛的将军超过了将军总数的1/3，达成上述目标是不可能的。特别要注意的是，要把拜占庭将军问题和两军问题区分开。两军 问题的模型要比拜占庭将军问题简单，并且设立的前提场景也有差别，我们来看一幅示意图：

如上图所示，在此问题模型中，假设有两支对抗的军队（一支为A军，一支为B军），这也就是所谓的两军。A军被B军隔开 为两个部分，分别是左A军和右A军。从战斗力来说，A军的两个部分必须同时合力进攻才能打败B军，这就要求A军的左右两支分队必须要协商好进攻时间和一些 进攻的其他约定，协商就意味着要通信，通过两边的互相通信来保持进攻指令的一致性。那么问题来了，左右两边的A军要互相通信，就必须经过B军的区域，这就 很难保证通信是畅通的，两边必须要不断发送回执来确认对方是否收到了消息，很显然，从理论上来讲，任何一次的回执都没法真正确认双方的消息接收是一致的。 比如左A军发送了消息给右A军，右A军接收到了并且发送了确认回执给左A军，可是确认回执被B军阻截了，此时左A军无法知道右A军到底收到消息没有，即便 右A军的回执成功到达了左A军，可是若没有左A军的回执（左A军的回执也可能被B军阻截），右A军同样无法确认左A军到底收到回执没有。按照这种确认模 式，只要有B军的阻截存在，左右两边A军就没法在理论上保证总是能达成一致的消息确认。

我们可以看到，两军问题的关键点在于：两点之间的信道传输不可靠。我们日常使用的大多数网络通信软件（支付、聊 天、发送邮件等）其实都会面临这样的问题，通信过程发生在互联网，谁也没法保证中间经过的“B军”是可靠的，一般也只能通过有限次数的双方回执来确认消息 的到达，这也是一个不得已的折中方案。值得注意的是，在这个问题模型中，并没有去假设中间是否存在故意破坏者，也就是在两军的通信过程中，不考虑某一方可 能叛变的情况。回到拜占庭将军问题，其考虑的主要问题在于通信的各方（不一定是两军，也可能是多军）存在故意破坏者或叛徒的情况下，大家如何来保持正确的 一致性的问题。

拜占庭将军问题的复杂性，可以用计算机容错学里的概念来表述。

1）拜占庭容错：这是最难处理的情况，指的是有一个节点压根就不按照程序逻辑执行，对它的调用会返回随意或者混乱的结果。要解决拜占庭式故障需要有同步网络，并且故障节点必须小于1/3，通常只有某些特定领域才会考虑这种情况，通过高冗余来消除故障。

2）崩溃容错：它比拜占庭容错多了一个限制，那就是节点总是按照程序逻辑执行，结果是正确的，但是不保证消息返回的时间。不能及时返回消息的原因可能是节点崩溃后重启了、网络中断了、异步网络中的高延迟等。

3）遗漏容错：它比崩溃容错多了一个限制，就是一定要“非健忘”。非健忘是指这个节点崩溃之前能把状态完整地保存 在持久存储上，启动之后可以再次按照以前的状态继续执行和通信。比如最基本版本的Paxos，它要求节点必须把投票的号码记录到持久存储中，一旦崩溃，修 复之后必须继续记住之前的投票号码。

4）崩溃停止容错：它比遗漏容错多了一个故障发生后要停止响应的要求。简单讲，一旦发生故障，这个节点就不会再和其他节点有任何交互，就像它的名字描述的那样，崩溃并且停止。

4.1.4　共识算法的目的

在有错误的进程存在并且有可能出现网络分区的情况下，FLP定理堵死了我们在传统计算机算法体系下提出解决方案的可能性。计算机科学家就想，如果我们把FLP定理的设定放松一点，问题是否有解呢？由社会学和博弈论中得到启发，科学家尝试引入了以下机制。

1）激励机制（incentive）。比如，在拜占庭将 军问题中给忠诚的将军以奖励。当背叛的将军发现背叛行为没有任何收益的时候，他们还有背叛的动机吗？这里引进了博弈论的概念：我们不再把节点或者说将军分 成公正/恶意（忠诚/背叛）两方，认为每一个节点的行为是由激励机制决定的。正如两千年前中国诸子百家热烈争论的话题：人之初，性本善焉，性本恶焉？我们 认为，人之初，性无善无恶。性的善恶由后天的激励机制决定。如果激励机制设置得当，考虑到每个节点都有最大化自己利益的倾向，大部分的节点都会遵守规则， 成为公正的节点。

2）随机性（randomness）。在拜占庭将军问题 中，决定下一步行动需要将军们协调一致，确定统一的下一步计划。在存在背叛将军的条件下，忠诚的将军的判断可能被误导。在传统的中心化系统中，由权威性大 的将军做决定。在去中心化的系统中，研究者提出一种设想：是否能在所有的将军中，随机地指定一名将军作决定呢？这个有点异想天开的设想为解决拜占庭将军问 题打开了一扇门。根据什么规则指定做决定的将军呢？对应到金融系统里，就是如何决定谁有记账权。

1）根据每个节点（将军）的计算力（computing power）来决定。谁的计算力强，解开某个谜题，就可以获得记账权（在拜占庭将军问题里是指挥权）。这是比特币里用的PoW共识协议。

2）根据每个节点（将军）具有的资源（stake）来决定。所用到的资源不能被垄断，谁投入的资源多，谁就可以获得记账权。这是PoS共识协议。

出于上面的考虑，科学家引入共识算法，试图解决拜占庭将军问题。分布式共识协议具有以下两点属性：

1）如果所有公正节点达成共识，共识过程终止；

2）最后达成的共识必须是公正的。

下面我们来谈谈共识算法的适用范围。区块链的组织方式一般有以下3种。

1）私有链：封闭生态的存储网络，所有节点都是可信任的，如某大型集团内部的多数公司。

2）联盟链：半封闭生态的交易网络，存在对等的不信任节点，如行业内部的公司A、B、C等。

3）公有链：开放生态的交易网络，即所有人都可以参与交易，没有任何限制和资格审核。

由于私有链是封闭生态的存储网络，因此使用传统分布式一致性模型应该是最优的；由于联盟行业链的半封闭、半开放特性，使用Delegated Proof of×××是最优的；对于公有链，PoW应该是最优的选择。

常见共识算法一览表：

来源：我是码农，转载请保留出处和链接！

本文链接：http://www.54manong.com/?id=98

• 区块链时代，互联网金融将走向何方2018-09-21 10:08
• 夯实通往区块链社会的基础2018-09-27 17:14
• 7.5　总结2018-09-15 10:35
• 第一章 区块链创世纪 [4] 2018-09-14 11:22