分布式系统工作原理分析

区块链是一个分布式系统。 如果不了解分布式系统的工作原理，就很难真正理解区块链。

不了解区块链的麻烦在于，你会陷入“去中心化”、“免许可”等概念的讨论，以及“TPS”、“安全”等失去上下文的问题。 这不仅无助于我们准确分析判断一个区块链项目，也使我们无法认知区块链可能的技术发展路线。

说得直白一点，我们需要掌握一些分布式系统的基础知识。 正因为如此，我们才能看到区块链本身的局限性，我们知道任何真正有价值的区块链项目都应该：为了解决特定的问题，在特定的环境下，做出特定的解决方案。

简单的指标比较是不客观的，更好的判断标准是：这个方案是否适合解决这个问题。

了解分布式系统的工作原理对区块链世界非常重要。 那么现在，就让我们开始分布式系统的探索吧。

计算机的作用就是处理信息，我们把条件A输入它，它输出结果B给我们。 如果处理信息的工作由一台计算机完成，这就是集中式结构； 如果处理信息的工作是由多台独立的计算机协同完成的，我们就可以称之为“分布式系统”。

分布式系统有许多不同的架构，它们实现了不同的信息处理方式。 假设系统中有十台计算机，一种架构是：我们将一个计算任务分成十个部分，让每台计算机独立处理一个任务，最后将它们的计算结果汇总为输出。

还有一种架构，就是让这十台电脑来处理这个计算任务。 如果所有的计算机都正常工作，它们的计算结果应该是相同的，然后将这个一致的计算结果作为输出。 区块链就是这样一种分布式系统。

很容易发现，这是一个“请苦力”的系统，相当于把同样的工作做了十次，不同计算机之间还需要额外的通信工作。

那么为什么需要这样的系统呢？ 因为它可以让我们避免对中心化计算机和该计算机背后的中心化公司或组织的依赖。 这样可以避免单点故障或作恶，减少权力的集中和滥用。

1.分布式系统的理想目标

区块链所属的分布式系统也被称为“复制状态机”。 它的目标很简单：系统中的所有计算机就某个输出值达成一致，这意味着：系统中所有的计算机节点/计算机都具有相同的初始状态，执行完一笔交易后，所有节点的最终状态都相同。

如果计算机都运行良好并且它们之间的通信完全同步，那么这并不难实现。 但现实并非如此。 主要有两类问题：

1. 某/某台电脑宕机，可能无法计算结果，也可能无法连接系统。

2.如果不同的计算机接收到事件的顺序不同，那么它们处理事件的顺序也会不同，从而导致输出结果不同。 例如，(a+b)×c和a+(b×c)是两个不同的计算序列，会带来不同的计算结果。

这些问题是普遍存在且不可避免的，而且一旦出现问题，不可能所有计算机都对某个输出结果达成一致。 著名的分布式系统“FLP不可能原理”是这样描述的：在一个网络可靠但允许节点故障的最小异步模型的系统中，不存在可以解决一致性问题的确定性共识算法。 通俗地说：只要系统中有一台计算机出现故障，系统就无法就输出值达成共识。

FLP 不可能原则告诉我们：不要浪费时间为面向所有场景的分布式系统设计共识算法，那是不可能的。

2. 分布式系统的共识算法

虽然 FLP 的不可能原则很残酷，但是分布式系统能够带来的好处是值得去面对困难的。 由于没有适用于所有场景的共识算法，或许可以找到一些在特定场景下有效的共识算法。 共识算法是指分布式系统达成共识的一种方法。

且看科学家们是如何一步步限定场景，实现该场景下的共识算法的。

首先，如果系统中的每一台计算机都能得出自己的结果，情况无疑会很复杂，因为我们甚至不知道要对哪个结果达成共识。 因此，解决共识问题的第一步是确定共识是什么。 最简单的方法是某台计算机说了算，它提出一个结果，其他计算机都同意这个结果。

拥有最终决定权的计算机称为提议者或领导者。 虽然通过领导者达成共识并不是解决问题的唯一途径，但大多数协议都是在此基础上实现的，包括区块链系统中使用的共识算法。

所以你看，没有绝对的权力下放。 达成共识的第一步是确定一个中心。

题外话：当我们知道这一点时，我们可以就权力下放建立更有效的讨论。 比如，这里不能泛泛地谈去中心化，而是：选这个leader的方法要不要去中心化。

回到主题。 需要领导者的共识算法的工作步骤大致如下：

1、选出一个leader；

2、领导提出成果；

3、关注者决定是否同意该结果；

4. 如果大家对结果达成共识，则系统输出最终结果； 如果大家没有达成共识，回到第一步重新开始。

这种思路提供了一种达成共识的方式，但离真正达成共识还很远。 因为如果一台电脑连不上系统，就无法投票是否同意leader的结果； 如果出现问题的计算机恰好是领导者，情况会更糟，整个系统会陷入瘫痪。

3. 同步假设共识算法

如何解决上述宕机问题？ 方法说起来简单：如果一台电脑连不上系统，就忽略它，不参与本轮共识。

那么一个新的问题出现了，我们怎么知道它是否连接不上系统，或者它是否正在参与共识但速度比其他机器慢？

因此，科学家们提出了解决共识问题最重要的假设之一：同步性假设。 同步性假设引入了“timeout”的概念，即预先设定一个时间范围，如果leader未能在该时间范围内发出提案，则该leader将被淘汰，并选举出新的leader。 这样，领导节点的故障是可以容忍的。 （注：同步性假设不等于同步性假设）

Paxos算法和Raft算法都是基于同步性假设提出的。 但是这两个算法还需要对系统做另外一个假设，即系统中的所有计算机都是“好人”，它们要么正确响应领导者的提议比特币分布式的实现原理，要么因失败而无法响应。

然后制定一个规则：只要系统中有超过半数的计算机接受了领导者的提议，该提议就作为系统的最终结果。 这样，您可以容忍跟随者节点的问题，而无需等待所有计算机响应。

所以，我们终于有了一个可以达成共识的分布式系统，虽然它有严格的条件。

Paxos共识算法是Leslie Lamport于1990年提出的一种基于消息的、高容错的共识算法，在分布式系统应用领域具有重要地位，包括Google在内的多家公司的大型分布式系统中都采用了该算法，包括 。 而我们第一阶段的探索也可以到这里结束，接下来是第二阶段。

4.摆脱系统中的“坏人”

Paxos虽然可以达成共识，但它的算法是建立在所有计算机都是“好人”的前提下的。 共识就足够了。 而如果电脑中存在“坏人”，系统中就会出现坏人的声音和好人的声音，Paxos算法无法处理这种情况。

我们需要一种算法，即使在有坏人在场的情况下也能达成共识，这可能吗？ Leslie Lambert 开发了一个模型来讨论这种可能性，称为拜占庭将军问题，其中拜占庭节点是传输破坏性消息的坏人节点，阻止整个系统达成共识。

在《拜占庭将军问题》一文中，Lambert 提出了几种解决方案，其中一种可以在拜占庭节点少于 1/3 时实现系统的共识。 也就是说，如果系统中坏人的数量少于1/3，就可以通过算法达成共识。

之后出现的DLS算法和PBFT算法（Practical Byzantine Fault Tolerant Algorithm）都是在此基础上发展起来的。

PBFT是一种具有代表性的拜占庭容错算法，其实现过程大致如下。 不了解流程也没关系，只要知道通过这种沟通方式就能达成共识即可。

1. Pre-prepare阶段：leader将结果发送给所有follower。 领导者是该图中的节点 0，它将结果发送给追随者 1、2 和 3。

2.准备阶段：如果follower认为结果是正确的，他会告诉所有其他节点批准这个结果。 例如，节点 1 将其批准消息发送到节点 0、2 和 3。

3. Commit阶段：如果follower发现超过2/3的节点同意leader的结果，就会告诉所有其他节点接受这个结果作为最终结果。

4、回复阶段：如果leader和follower发现有超过2/3的节点接受了最终结果，则可以认为大部分节点已经达成共识，并将共识反馈给客户端; 如果客户端收到超过1/3的3个节点有相同的共识，可以认为全网达成共识。

至此，我们已经解决了拜占庭节点分布式系统的共识问题。 但是，如果系统中坏人的数量等于或超过1/3，仍然无法达成共识。 我们能做的就是通过系统的准入条件或者激励机制，让坏人减少到1/3以下。

分布式系统第二阶段的探索到此结束，接下来进入第三阶段。

5. 中本聪共识算法

Paxos 和 PBFT 都使用了同步性假设。 事实上，直到中本聪共识的出现，几乎所有关于共识算法的研究都是朝着这个方向发展的。 中本聪共识使用非确定性机制。

这是什么意思？ 我们可以把一个由 12 台计算机组成的分布式系统想象成一个由 12 名陪审员组成的陪审团。 我们把这12个人锁在会议室里，交了纸条说明案情，然后就坐在会议室门口等着他们给出审理结果。

这12个人对于如何判断会有不同的意见，并且可能会随着讨论的进行改变立场，也可能会有人睡着了，无法发表自己的意见（参考《十二怒汉》）。 那么坐在门口等待的人有两个选择。 第一个方案是你商量，你想等多久我都可以，但最后你必须给我唯一确定的审理结果； 第二个选项是我等不及了，你先给出大多数人都同意的结果。 我呢，如果有一个结果让更多人认同，我就改成那个结果。

显然，我们只能二选一。 如果需要确认结果，则不保证一定会获得结果； 如果需要结果，则不能保证结果一定是最终结果。

分布式系统就是这种情况。 只有两个选择。 第一个选项称为Finality，意思是“结果的确定性”或安全性； 第二个选项称为 Liveness，这意味着网络的活动或可用性。

这两种选择决定了分布式共识的两种不同设计思路：

1.追求Finality是优先结果，所以需要对网络提出要求。 PBFT 和 Tendermint 都是这种类型的算法。 它们遵循网络同步的假设，使用此类算法的系统不会分叉。

2、追求Liveness是网络的首要任务，所以我们必须对结果做出让步。 中本聪共识就是这类算法，它走的是结果的非确定性路线，使用这类算法的分布式网络永远可用，任何节点都可以随时加入/离开系统。

顺便说一句，Finality 和 Liveness 取其一也是分布式系统 CAP 定理（不可能三角）的体现。 定理说：对于分布式系统来说，不可能同时满足一致性、可用性和分区容错性。 因为分区容错意味着系统必须能够容忍网络分区，而真实的网络肯定会分区，所以必须满足这个条件。 其实CAP定理说的是分布式系统不能同时满足一致性和可用性，其中CAP一致性体现Finality，CAP可用性体现Liveness。

无论是FLP不可能原理，还是CAP不可能定理，都不是在告诉我们：这条路很难走，如果突破了，就是一个伟大的创新； 他们告诉我们的是：这条路走不通，你要做的就是根据需要做出取舍和选择。

上面已经详细介绍了使用同步性假设的共识算法，它们通过引入超时的概念和忽略有问题的计算机来达成共识。

使用非确定性机制的中本聪共识也很容易描述：如果你看到一个提议的区块具有最多的工作量证明，则接受该区块，也称为最长链规则。 其具体实现过程大家都很熟悉，本文不再赘述。

现在，让我们看看使用同步性假设（Finality，在 PoS 中使用较多）的系统与使用非确定性机制（Liveness，在 PoW 中使用较多）的系统有何不同。 但需要提醒的是，并不是所有的PoS都是Finality路线，比如Casper FFG； 而 PoW 并不局限于 Liveness 路线，虽然没有人在 PoW 上设计 Finality 共识。

PoW 和 PoS 的区别在于，一个是 Work，一个是 Stake。 之所以需要强调这一点，是因为在讨论 PoW 和 PoS 时比特币分布式的实现原理，我们往往不是在讨论 Work 机制和 Stake 机制的区别，而是在比较 Finality 系统和 Liveness 系统的区别。 例如，“免许可”基本上是Finality系统和Liveness系统之间的话题，而不是Work和Stake之间的争论。

让我们回到有 12 个审稿人的房间。 为了追求Finality，每个reviewer都需要知道其他人的想法，也需要把自己的想法告诉其他人，所以沟通的复杂度会随着reviewer人数的增加而迅速增加，整个系统也会因此不可用，所以必须控制陪审员的人数。

那么对于分布式系统来说，只有少数几个节点被选中进入会议室，由他们决定共识，而其他节点只接受共识。 因此，在这个系统中存在三种角色，领导者、追随者和学习者。 leader 和 follower 就是会议室里的审稿人。 他们需要很好地工作，否则系统可能无法达成共识。

中本聪共识追求的是Liveness。 节点/评论者不需要与其他节点通信，他们只需要与周围的节点通信，因此通信复杂度不会因为节点数量的增加而增加。 如果你想当评委，可以不经许可走进会议室当评委，也不会让陪审团难以达成共识。 同时，您不能随时工作或离开。 系统中只有两个角色，leader和follower，大家在那个会议室参与共识。

看起来中本聪共识似乎更符合大家对分布式系统开放性的期待，但是不要忘了它可以这样设计，因为它牺牲了Finality，它的输出是一个概率性的最终结果。

试想一下，你在星巴克得到了100%的一杯咖啡，而星巴克却没有得到100%的钱，这不符合大多数人理解的世界规则。 所以非确定性机制有其自身的缺点和不适合的场景。

另一方面，在最终性系统保证了结果的确定性之后，系统设计又要追求Liveness； 而Liveness系统保证了网络的开放性后，系统设计必须逆向追求Finality。 为了提高结果的确定性或安全性，中本聪共识需要做出其他让步，比如 TPS。

以比特币为例。 比特币可以将出块时间从 10 分钟提高到 1 分钟，TPS 会大大提高，但 1 分钟不足以让消息传遍全网，而且系统会出现很多分叉，导致确定性较低结果；比特币也可以将区块大小从1MB增加到100MB，TPS也会增加，但是大区块对网络和节点的要求很高，会增加节点的进入门槛，带来中心化，导致容易篡改输出结果。

所以你看，设计一个分布式系统就像和撒旦做交易，你得到一些，你也必须付出一些。 没有最好的系统，只有适合解决某类问题的系统； 没有简单的指标比较，只是在什么设置下实现这个指标。

如果你明白这一点，那么本文的目的就达到了，我们对分布式系统的探索也就到此为止了。

六、走得更远

这篇文章的灵感来自分布式共识如何工作？ 》受文章启发而写，如果想深入了解分布式系统，推荐这篇文章，从专业的角度介绍分布式共识；同时推荐《WHAT WE TALK ABOUT WHEN WE TALK ABOUT DISTRIBUTED SYSTEMS》 ，系统地罗列了分布式系统的经典论文。