从分布式一致性算法到区块链共识机制

引言

分布式一致性是一个很“古典”的话题，即在分布式系统中，如何保证系统内的各个节点之间数据的一致性或能够就某个提案达成一致。这个问题想必对于很多技术同学而言并不陌生，几乎在所有的分布式系统中都会遇到，比如hdfs、mq、zookeeper、kafka、redis、elasticsearch等。然而这个问题却历久弥新，随着分布式网络的蓬勃发展与复杂化，对于该问题解法的探索也一直在进行中。

而近年来，随着区块链技术的兴起，特别是开放网络中的公有链与有权限网络中的联盟链的蓬勃发展，一致性问题再次得到关注，并从新的视角来审视该问题。

本文将从传统的分布式一致性问题说起，再次重温我们需要面对的问题挑战、已有的理论研究、以及相应的一致性算法，并简要分析这些一致性算法的适用性与局限性，以及这些传统一致性算法与崭新的区块链技术的结合。另外，将从区块链中一致性问题的全新视角“人的可信”出发，重点阐述公有链领域中的共识算法与机制。因此，本文围绕“一致性”技术问题，重点从技术视角阐述传统计算机科学中的分布式一致性算法与区块链中的共识机制的关联，以及公有链对于一致性问题的重新思考。

分布式一致性问题的挑战

要清楚理解分布式一致性，首先需要对分布式网络的特性有清晰的认识。那么分布式网络具有哪些特点呢？或者通俗理解，在分布式网络中，可能遇到哪些问题呢？

Crash Fault

故障错误（Crash Fault）很好理解，就是说分布式网络中：

• 节点或副本可能随时宕机、可能暂停运行但随后又恢复；
• 网络可能随时中断；
• 发送的消息可能在传递的过程中丢失，对方一直收不到；
• 发送的消息可能出现延迟，过了很久对方才能收到；
• 消息在传递的过程中可能出现乱序；
• 网络可能出现分化，如中美集群因通信不畅，而导致整体网络分化为中美两个子网络；

这些问题，其实就是我们在分布式环境中最常实际遇到的问题，这些问题实质上都是由于分布式系统中的物理硬件的不可靠、不稳定所带来的必然风险，比如：网络（信道）不可能是永远稳定可靠的、物理机磁盘或CPU等不可能是永远良好的。故障错误可以说是分布式系统中必须考虑并解决的最基本、最常见的一类错误。

Byzantine Fault

上文的故障错误，仍然基于一个很简单的假设：节点要么不正常工作或响应，要么能正常工作或响应，但不能口是心非、阳奉阴违、表里不一，即可以不干事、但不能干坏事。一旦网络中存在作恶节点，可能会随意篡改或伪造数据，那么一致性问题的难度就大幅增加。我们常把这类存在“捣乱者”，可能会篡改或伪造数据或响应信息的错误，称之为拜占庭错误（Byzantine Fault），而前面所说的故障类错误也称之为非拜占庭错误。

拜占庭这一称呼，源于Lamport最初的论文，可以说是分布式领域最复杂、最严格的容错模型。简而言之，n个将军准备一起进攻某个城堡，每个将军都可以选择进攻或是撤退，但所有将军必须行动一致才能成功。各个将军之间相隔很远，不能直接通讯，必须通过信使来传递消息。但是信使并不可靠，信使可能过了很久才送到消息、可能一直也没有把消息送到、甚至可能会故意篡改消息；而将军也并不可靠，里面可能存在叛徒，并不按照提案来行动。显然，这个故事中的信使用来代表分布式网络中的不可靠信道，而将军就是各个不可靠的节点。

 

应对风险—Fault Tolerance

如何在充满风险与不确定的分布式网络中，寻找到某种确定性与一致性，使得整个分布式网络输出稳定可靠的一致性结果，就是分布式一致性算法要解决的核心问题。显而易见，解决故障类错误更容易一些，通常把这类一致性算法叫做故障容错算法（Crash Fault Tolerance）或者非拜占庭容错算法。而拜占庭类错误，因为有恶意篡改的可能性存在，复杂性更高、解决难度更大，通常把解决这类问题的算法称作拜占庭容错算法（Byzantine Fault Tolerance）。

那么我们忍不住要问，两类容错算法的界限在哪里？或者说两类错误都在什么样的场景下出现？恶意篡改这种情况真的需要考虑吗？问题的答案可能取决于我们所处的网络环境与业务场景。

CFT

通常而言，如果系统处于可信的内部网络环境中，只需要考虑故障容错（CFT）可能就足够了。比如我们经常见到的公司内的分布式存储、消息队列、分布式服务等各种分布式组件，其实只需要考虑故障容错就足够了。因为公司内整个网络是封闭的，又有多重防火墙的保护，外界很难接入或攻击；各个节点是由公司统一部署的，机器或运行的软件遭到篡改的可能性极小；此时的分布式网络环境相对“单纯”，我们唯一的敌人只是：通信网络与机器硬件。我们需要考虑的是网络的延迟、不稳定，以及机器随时可能出现的宕机、故障。

BFT

而拜占庭类错误(BFT)，是把整个分布式网络放到了更大的环境中去看，除了物理硬件之外，还考虑了一些“人”的因素。毕竟，机器是不会作恶的，作恶的只有人。假如我们所处的分布式网络是较为开放的网络，比如行业内几十上百家公司组成的联盟网络；或者是完全开放的网络，比如任何人都可以随意接入到网络中；而节点机器和上面部署的软件也是由各个公司或个人自己提供和部署的，那么如果利益足够大，很可能会有人对网络中的某个节点发起DDoS攻击、故意篡改软件代码改变其执行逻辑、甚至可能故意篡改磁盘上持久化的数据。显然，我们此时面临的挑战更大了，我们除了要考虑通信网络和机器硬件的不可靠之外，还必须要考虑和应对系统中的“捣乱者”。

不可能三角

这些实践中遇到的问题，也引发了诸多计算科学家进行了非常多的理论研究。这些理论研究对于工程技术人员而言或许过于抽象繁琐，有些甚至是无趣的数学问题，但这些理论对于指导我们解决这些问题意义重大。这些理论相当于是告诉了我们这类问题解法的理论极限，以及哪些方向可以探索、哪些方向是死路一条。站在前人的肩膀上，才不至于花毕生精力去研制“永动机”。这些理论大家应该都有所了解，这里只简单回顾。

FLP impossibility

早在1985年，Fisher、Lynch、Paterson三位科学家就发表了关于分布式一致性问题的不可能定理：在完全异步的分布式网络中，故障容错问题无法被解决。（ We have shown that a natural and important problem of fault-tolerant cooperative computing cannot be solved in a totally asynchronous model of computation. ）说得更直白点：在异步网络中，不可能存在能够容忍节点故障的一致性算法，哪怕只有一个节点故障。并且这里并没有考虑拜占庭错误，而是假设网络非常稳定、所有的消息都能被正确传递、并且仅被传递一次，即便如此都不可能找到能容忍哪怕只有一个节点失效的一致性协议，可见该结论有多强。（ In this paper, we show the surprising result that no completely asynchronous consensus protocol can tolerate even a single unannounced process death. We do not consider Byzantine failures, and we assume that the message system is reliableit delivers all messages correctly and exactly once. ）

当然了，这只是理论上的。它的意义在于告诉我们此类问题的理论极限，并不意味着此类问题在实践中也不可能被“解决”。如果我们愿意放宽限制、做出牺牲，在工程上是可以找到切实可行的解法的。

FLP不可能定理的最大适用前提是异步网络模型。何为同步、异步模型呢？

• 所谓异步模型，是说从一个节点到另一个节点的消息延迟是有限的，但可能是无界的（finite but can be unbounded）。这就意味着如果一个节点没有收到消息，它无法判断消息到底是丢失了，还是只是延迟了。也就是说，我们无法通过超时时间来判断某个节点是否故障。
• 所谓同步模型，是说消息传递的延迟是有限的，且是有界的。这就意味着我们可以通过经验或采样精确估算消息的最大可能延迟，从而可以通过超时时间来确定消息是否丢失、节点是否故障。

所幸的是，我们所处于的真实的网络世界更接近同步模型，在很多场景上，我们都可以通过经验或采样确定最大超时时间。举个通俗点的例子：你给朋友快递了一本书，朋友过了3天还没收到，此时朋友很难判断到底是快递延迟了，还是快递出问题送丢了。但是如果过了一个月，朋友仍没收到书，基本就可以断定快递送丢了。而背后的推论就是基于经验或统计：通常快递都能在1-2周内送达。显然，异步模型其实是反映了节点间通讯的最差情况、极端情况，异步模型包含了同步模型，即能在异步模型上有效的一致性协议，在同步模型上也同样有效。而同步模型是对异步模型做了修正和约束，从而使得更接近真实世界，也使得在实践中一致性问题有可能得到有效解。

另外，即便是在异步网络模型下，FLP也并不意味着一致性永远无法达成，只是说无法保证在有界的时间（in bounded time）内达成。在实践上，如果放宽对bounded time的限制，仍然是有可能找到实践中的解法的。

而根据DLS的研究，一致性算法按照网络模型可以分为三大类：

• 部分同步网络模型（partially synchronous model）中的一致性协议可以容忍最多1/3的任意错误。这里的部分同步模型是指网络延迟是有界的，但是我们无法提前得知。这里的容错也包含了拜占庭类错误。
• 异步网络模型（asynchronous model）中的确定性协议无法容忍错误。这里的异步模型即是前文所说的网络延迟是无界的。该结论其实就是FLP不可能定理的含义，在完全异步网络中的确定性协议不能容忍哪怕只有一个节点的错误。
• 同步网络模型（synchronous model）可以达到惊人的100%容错，虽然对错误节点超过1/2时的节点行为有限制。这里的同步模型是指网络延迟一定是有界的，即小于某个已知的常数。

从另一个角度来理解，FLP实际上考虑了分布式系统的3个属性：安全(safety)、活性（liveness)、容错：

• 安全是说系统内各个节点达成的值是一致的、有效的。safety其实是保证系统一致性运行的最低要求，其核心是cannot do something bad，即不能干坏事、不能做错事。
• 活性是说系统内各个节点最终（在有限时间内）必须能够达成一致，即系统必须能够向前推进，不能永远处于达不成一致的状态。liveness其实是更高要求，意味着不能只是不干坏事，也不能一直不干事，you must do something good，即必须使得整个系统能良好运转下去。
• 容错是说该协议在有节点故障的情况下也必须能有效。

FLP不可能定理其实意味着在异步网络中，不可能存在同时满足这三者的分布式一致性协议。因为分布式环境中，节点故障几乎是必然的，因此容错是必须要考虑的因素，所以FLP不可能定理就意味着一致性协议在能做到容错的情况下，没办法同时做到安全性与系统活性。通常在实践中，我们可以做出部分牺牲，比如牺牲一部分安全性，意味着系统总能很快达成结论，但结论的可靠性不足；或者牺牲一部分系统活性，意味着系统达成的结论非常可靠，但可能长时间、甚至永远都在争论中，无法达成结论。所幸的是，很多时候现实世界的鲁棒性很强，使一致性协议失效的倒霉事件发生的概率也很可能极低。

​​

另外，FLP并未排除Las Vegas类随机算法，许多一致性算法采用了这种随机性来规避FLP不可能定理对于确定性异步网络的限制。此类非确定性一致性算法涉及Las Vegas规则：网络最终一定能达成一致，但是达成一致所需要的时间可能是无界的。此类算法每轮共识决策都有一定的概率，并且系统在T秒内能够达成一致的概率P随着时间T的增加而指数增长并趋近于1。事实上，该方法被许多成功的一致性算法所采用，是在FLP不可能定理笼罩下的安全地带（escape hatch），后面将会讲到比特币的共识机制就是采用了这样的方法。

CAP theorem

众所周知、大名鼎鼎的CAP原理，从另一个维度，简单明了、直截了当地告诉我们：可用性、一致性与网络分区容错性这三者不可能同时实现，而只能实现任意其中的两个。( "Of three properties of shared-data systems (data consistency, system availability and tolerance to network partitions) one can only achieve two at any given time".) CAP与FLP看起来有相似之处，其实二者并不尽相同，二者是从不同的维度思考问题，另外即使是很相似的概念，内涵也并不完全一样。比如：

• FLP面对的是分布式一致性问题，而CAP面对的是分布式网络中的数据同步与复制。
• FLP是说在异步网络模型中，三者不可能同时实现；而CAP是说在所有场景下，三者都不可能同时实现。
• FLP中的liveness强调的是一致性算法的内在属性；而CAP中的availability强调的是一致性算法对外呈现的外在属性。

理论上，只能从CAP三者中选择两者，然而，这种选择的边界并非是非此即彼的（not binary），很多时候混合考虑不同程度的各个因素，结果可能是更好的。（ The whole spectrum in between is useful; mixing different levels of Availability and Consistency usually yields a better result.）