英文原文链接：https://medium.com/s/story/lets-take-a-crack-at-understanding-distributed-consensus-dad23d0dc95

How Does Distributed Consensus Work?

How Does Distributed Consensus Work?

区块链技术关键突破概述——以及为什么中本聪共识如此重要。

分布式系统可能难以理解，主要是因为围绕它们的知识是分布式的。但别担心，我很清楚其中的讽刺意味。在自学分布式计算时，我多次摔倒在地。现在，经过多次尝试和磨难，我终于准备好向您解释分布式系统的基础知识了。

区块链迫使工程师和科学家重新审视和质疑分布式计算中根深蒂固的范式。

我还想讨论区块链技术在该领域产生的深远影响。区块链迫使工程师和科学家重新审视和质疑分布式计算中根深蒂固的范式。也许没有其他技术比区块链更快地促进了这一研究领域的进展。

分布式系统绝不是新事物。科学家和工程师花了几十年的时间研究这个主题。但区块链与他们有什么关系？好吧，如果分布式系统没有首先存在，区块链所做的所有贡献都是不可能的。

本质上，区块链是一种新型的分布式系统。它始于比特币的出现，此后在分布式计算领域产生了持久的影响。所以，如果你想真正了解区块链是如何工作的，那么掌握分布式系统的原理是必不可少的。

不幸的是，许多关于分布式计算的文献要么难以理解，要么分散在太多的学术论文中。更复杂的是，有数百种架构，所有这些都服务于不同的需求。将其归结为一个易于理解的框架是相当困难的。

因为领域广阔，我必须仔细选择我可以涵盖的内容。我还必须进行概括以掩盖一些复杂性。请注意，我的目标不是让您成为该领域的专家。相反，我想为您提供足够的知识，帮助您开启分布式系统和共识之旅。

阅读完这篇文章后，您将更深入地了解：

什么是分布式系统，
分布式系统的属性，
在分布式系统中达成共识意味着什么，
对基础共识算法（例如 DLS 和 PBFT）的理解，
以及为什么中本聪共识很重要。

我希望你已经准备好学习了，因为现在上课了。

什么是分布式系统？

分布式系统涉及一组不同的进程（例如计算机），它们相互传递消息并协调以实现共同目标（即解决计算问题）。

分布式系统是一组计算机一起工作以实现一个统一的目标。

简而言之，分布式系统是一组计算机一起工作以实现一个统一的目标。尽管这些过程是分开的，但系统对于最终用户来说就像一台计算机。

正如我所提到的，分布式系统有数百种架构。例如，一台计算机也可以被视为一个分布式系统：中央控制单元、内存单元和输入输出通道是相互协作以完成目标的独立进程。

以飞机为例，这些离散单元协同工作，将您从 A 点带到 B 点：

在这篇文章中，我们将关注分布式系统，其中进程是空间分离的计算机。

注意：我可以将术语“节点”、“对等体”、“计算机”或“组件”与“进程”互换使用。就本文而言，它们的含义相同。同样，我可以将术语“网络”与“系统”互换使用。

分布式系统的属性

每个分布式系统都有一组特定的特征。这些包括：

A）并发

系统中的进程同时运行，这意味着多个事件同时发生。换句话说，网络中的每台计算机与网络中的其他计算机同时独立地执行事件。

这需要协调

B) 缺少全局时钟

为了使分布式系统正常工作，我们需要一种确定事件顺序的方法。然而，在一组同时运行的计算机中，有时不可能说两个事件中的一个首先发生，因为计算机在空间上是分开的。换句话说，没有单一的全局时钟来确定网络中所有计算机发生的事件顺序。

在论文“Time, Clocks and Ordering of Events in a Distributed System”中，Leslie Lamport 展示了我们如何通过记住以下因素来推断一个事件是否先于另一事件发生：

消息在被收到之前发送。
每台计算机都有一系列事件。

通过确定哪个事件先于另一个事件发生，我们可以获得系统中事件的部分排序。 Lamport 的论文描述了一种算法，该算法要求每台计算机都能听到系统中其他计算机的声音。这样，事件就可以基于这种部分排序进行完全排序。

但是，如果我们完全根据每台计算机听到的事件来确定顺序，我们可能会遇到这种顺序与系统外部用户所感知的不同的情况。因此，该论文表明该算法仍然可以允许异常行为。

最后，Lamport 讨论了如何通过使用适当同步的物理时钟来防止此类异常。

但是等等——有一个很大的警告：协调原本独立的时钟是一个非常复杂的计算机科学问题。即使您最初准确地设置了一堆时钟，经过一段时间后时钟也会开始不同。这是由于“时钟漂移”，一种时钟以略微不同的速率计算时间的现象。

从本质上讲，Lamport 的论文表明，时间和事件顺序是空间分离的分布式计算机系统中的基本障碍。

C) 组件的独立故障

理解分布式系统的一个关键方面是承认分布式系统中的组件是错误的。这就是为什么它被称为“容错分布式计算”的原因。

一个没有故障的系统是不可能的。真实系统存在许多可能的缺陷或缺陷，无论是进程崩溃；消息丢失、扭曲或重复；延迟或丢弃消息的网络分区；甚至是一个完全失控的过程并根据一些恶意计划发送消息。

一个没有故障的系统是不可能的。

这些故障大致可分为三类：

Crash-fail：组件在没有警告的情况下停止工作（例如，计算机崩溃）。
Omission：组件发送消息但其他节点未收到（例如，消息被丢弃）。
Byzantine：该组件的行为是任意的。这种类型的故障与可能没有恶意行为的受控环境（例如，谷歌或亚马逊数据中心）无关。相反，这些错误发生在所谓的“对抗性环境”中。基本上，当一组分散的独立参与者充当网络中的节点时，这些参与者可能会选择以“拜占庭”方式行事。这意味着他们恶意选择更改、阻止或根本不发送消息。

考虑到这一点，我们的目标是设计允许具有故障组件的系统仍然实现共同目标并提供有用服务的协议。

鉴于每个系统都有故障，我们在构建分布式系统时必须考虑的一个核心问题是它是否能够在其部分偏离正常行为的情况下仍然存在，无论这是由于非恶意行为（即崩溃失败或遗漏故障）造成的或恶意行为（即拜占庭错误）。

从广义上讲，在制作分布式系统时需要考虑两种类型的模型：

1）简单的容错

在一个简单的容错系统中，我们假设系统的所有部分都做两件事之一：它们要么完全遵循协议，要么失败。这种类型的系统绝对应该能够处理节点离线或故障。但它不必担心节点表现出任意或恶意行为。

2A）拜占庭容错

一个简单的容错系统在不受控制的环境中不是很有用。在一个由独立参与者控制的节点在开放、无许可的互联网上进行通信的去中心化系统中，我们还需要为选择恶意或“拜占庭”的节点进行设计。因此，在拜占庭容错系统中，我们假设节点可能发生故障或恶意。

2B) BAR 容错

尽管大多数真实系统的设计都是为了抵御拜占庭式故障，但一些专家认为，这些设计过于笼统，没有考虑到“理性”故障，如果节点出于自身利益这样做，可能会偏离。换句话说，节点既可以诚实也可以不诚实，这取决于激励措施。如果激励足够高，那么即使是大多数节点也可能会做出不诚实的行为。

更正式地说，这被定义为 BAR 模型——一个指定了拜占庭和理性失败的模型。 BAR 模型假设了三种类型的参与者：

Byzantine：拜占庭式节点是恶意的，并试图搞砸你。
Altruistic：诚实的节点始终遵循协议。
Rational：理性节点仅在适合它们的情况下遵循协议。

D) 消息传递

正如我之前提到的，分布式系统中的计算机通过一台或多台其他计算机之间的“消息传递”进行通信和协调。可以使用任何消息传递协议传递消息，无论是 HTTP、RPC 还是为特定实现构建的自定义协议。有两种类型的消息传递环境：

1）同步

在同步系统中，假定消息将在某个固定的已知时间量内传递。

同步消息传递在概念上不那么复杂，因为用户有一个保证：当他们发送消息时，接收组件将在一定的时间范围内得到它。这允许用户使用消息到达其目的地所需时间的固定上限来建模他们的协议。

但是，这种类型的环境在现实世界的分布式系统中不太实用，在这种系统中，计算机可能会崩溃或脱机，并且消息可能会被丢弃、复制、延迟或乱序接收。

2）异步

在异步消息传递系统中，假设网络可以无限延迟消息、复制消息或乱序传递消息。换句话说，接收消息需要多长时间没有固定的上限。

在分布式系统中达成共识意味着什么

到目前为止，我们已经了解了分布式系统的以下属性：

Concurrency of processes
Lack of a global clock
Faulty processes
Message passing

接下来，我们将重点了解在分布式系统中实现“共识”意味着什么。但首先，重申我们之前提到的内容很重要：有数百种硬件和软件架构用于分布式计算。

最常见的形式称为复制状态机。

Replicated State Machine

复制状态机是一种确定性状态机，可在多台计算机上复制，但用作单个状态机。这些计算机中的任何一台都可能出现故障，但状态机仍然可以运行。

在复制状态机中，如果事务有效，一组输入将导致系统状态转换到下一个状态。事务是对数据库的原子操作。这意味着操作要么完全完成，要么根本不完成。在复制状态机中维护的一组事务称为“事务日志”。

从一个有效状态转换到下一个有效状态的逻辑称为“状态转换逻辑”。

换句话说，复制状态机是一组分布式计算机，它们都以相同的初始值开始。对于每个状态转换，每个进程都会决定下一个值。达成“共识”意味着所有计算机必须集体同意这个值的输出。

反过来，这会在系统中的每台计算机上维护一致的事务日志（即，它们“实现共同目标”）。复制的状态机必须不断地接受新事务到这个日志中（即“提供有用的服务”）。尽管有以下事实，但它必须这样做：

有些电脑有问题。
网络不可靠，消息可能无法传递、延迟或乱序。
没有全局时钟来帮助确定事件的顺序。

我的朋友们，这是任何共识算法的基本目标。

共识问题，定义

一个算法如果满足以下条件，就可以达成共识：

Agreement：所有非故障节点决定相同的输出值。

Termination：所有非故障节点最终决定某个输出值。

注意：不同的算法对上述条件有不同的变化。例如，有些人将协议属性分为一致性和总体性。有些人有有效性或完整性或效率的概念。但是，这些细微差别超出了本文的范围。

从广义上讲，共识算法通常假设系统中有三种类型的参与者：

Proposers（提议者），通常称为领导者或协调者。
Acceptors（接收者），侦听来自提议者的请求并以值响应的进程。
Learners（学习者），系统中的其他进程学习最终决定的值。

一般来说，我们可以通过三个步骤来定义一个共识算法：

Step 1: Elect

进程们选择一个进程（即领导者）来做出决策。
领导者提出下一个有效的输出值。

Step 2: Vote

非故障进程监听领导者提出的值，对其进行验证，并将其作为下一个有效值提出。

Step 3: Decide

非故障进程必须就单个正确的输出值达成共识。如果它收到满足某些标准的相同投票的阈值数量，则进程将决定该值。
否则，这些步骤将重新开始。

需要注意的是，每种共识算法都有不同的：

术语（例如，轮次、阶段）、
如何处理投票的程序
以及如何决定最终值的标准（例如，有效性条件）。

尽管如此，如果我们可以使用这个通用过程来构建一个保证上面定义的一般条件的算法，那么我们就有一个能够达成共识的分布式系统。

很简单，对吧？

FLP impossibility

… 并不真地。但你可能已经看到了！

回想一下我们如何描述同步系统和异步系统之间的区别：

在同步环境中，消息在固定的时间范围内传递
在异步环境中，不能保证消息被传递。

这种区别很重要。

在同步环境中达成共识是可能的，因为我们可以假设消息传递所需的最长时间。因此，在这种类型的系统中，我们可以允许系统中的不同节点轮流提出新交易，轮询多数票，如果在最大时限内没有提出提案，则跳过任何节点。

但是，如前所述，假设我们在同步环境中操作在消息延迟可预测的受控环境（例如具有同步原子钟的数据中心）之外是不切实际的。

实际上，大多数环境不允许我们做出同步假设。所以我们必须针对异步环境进行设计。

如果我们不能假设异步环境中的最大消息传递时间，那么实现终止就困难得多，如果不是不可能的话。请记住，达成共识必须满足的条件之一是“终止”，这意味着每个非故障节点都必须决定某个输出值。

这被正式称为“FLP 不可能结果”。这个名字是怎么来的？好吧，我很高兴你问！

即使是单个故障进程也无法在确定性异步进程之间达成共识。

研究人员 Fischer、Lynch 和 Paterson（又名 FLP）在他们 1985 年的论文“Impossibility of Distributed Consensus with One Faulty Process,”中展示了即使是一个错误的进程也无法在确定性异步过程之间达成共识。基本上，由于进程可能在不可预测的时间失败，它们也有可能在阻止共识发生的确切时机失败。

这个结果对于分布式计算空间来说是一个巨大的打击。尽管如此，科学家们仍在继续努力寻找规避 FLP 不可能性的方法。

在高层次上，有两种方法可以规避 FLP 不可能性：

使用同步假设
使用非确定性。

现在让我们深入研究每一个。

方法 1：使用同步假设

我知道你在想什么：这到底是什么意思？

让我们重新审视我们的不可能结果。这是另一种思考方式：FLP 不可能结果本质上表明，如果我们不能在系统中取得进展，那么我们就无法达成共识。换句话说，如果消息是异步传递的，则无法保证终止。回想一下，终止是一个必需条件，这意味着每个非故障节点最终都必须决定某个输出值。

但是，如果我们不知道由于异步网络何时传递消息，我们如何保证每个非故障进程都会决定一个值呢？

需要明确的是，该发现并未表明无法达成共识。相反，由于异步性，无法在固定时间内达成共识。说共识“不可能”仅仅意味着共识“并不总是可能的”。这是一个微妙但至关重要的细节。

避免这种情况的一种方法是使用超时。如果在决定下一个值时没有取得任何进展，我们会等到超时，然后重新开始这些步骤。正如我们即将看到的，这就是像 Paxos 和 Raft 这样的共识算法本质上所做的。

Paxos

Paxos 于 1990 年代推出，是第一个现实世界的、实用的、容错的共识算法。它是最早被 Leslie Lamport 证明是正确的广泛采用的共识算法之一，并已被谷歌和亚马逊等全球互联网公司用于构建分布式服务。

Paxos 的工作原理是这样的：

Phase 1: Prepare request

提议者选择一个新的提议版本号（n）并向接受者发送“准备请求”。
如果接受者收到一个准备请求（"prepare"，n），其 n 大于他们已经响应的任何准备请求，接受者发送（"ack，"n，n'，v'）或（"ack，"n, ^ , ^)。
接受者回应承诺不再接受任何编号小于 n 的提案。
接受者建议他们接受的最高数量提案的值（v），如果有的话。否则，他们会回复 ^。

Phase 2: Accept request

如果提议者收到大多数接受者的响应，那么它可以发出一个接受请求（“accept”，n，v），编号为 n，值为 v。
n 是出现在准备请求中的数字。
v 是响应中编号最高的提案的值。
如果接受者收到一个接受请求（“accept,”n，v），它会接受该提议，除非它已经响应了一个编号大于 n 的准备请求。

Phase 3: Learning phase

每当接受者接受提议时，它都会响应所有学习者（“accpet”，n，v）。
学习者从大多数接受者那里接收 (“accept,” n, v)，决定 v，并将 (“decide,” v) 发送给所有其他学习者。
学习者收到（“decide” v）和决定的 v。

呸！迷茫了吗？我知道有很多信息需要消化。

但是等等……还有更多！

正如我们现在所知，每个分布式系统都有故障。在该算法中，如果提议者失败（例如，因为存在 omission 错误），则可能会延迟决策。 Paxos 通过在第 1 阶段开始使用新版本号来解决这个问题，即使之前的尝试从未结束。

我不会详细介绍，但在这种情况下恢复正常操作的过程非常复杂，因为预计流程会介入并推动解决过程向前发展。

Paxos 如此难以理解的主要原因是它的许多实现细节留给读者解释：我们如何知道提议者何时失败？我们是否使用同步时钟来设置超时时间来决定提议者何时失败并且我们需要进入下一个等级？ ?‍

为了提供实施的灵活性，关键领域的一些规范是开放式的。诸如领导人选举、故障检测和日志管理之类的事情是模糊或完全未定义的。

这种设计选择最终成为 Paxos 的最大缺点之一。它不仅难以理解，而且难以实施。反过来，这使得分布式系统领域非常难以驾驭。

到目前为止，您可能想知道同步假设的来源。

在 Paxos 中，虽然算法中没有明确超时，但在实际实现中，需要在超时一段时间后选举一个新的提议者来实现终止。否则，我们无法保证接收者会输出下一个值，系统可能会停止。

Raft

2013 年，Ongaro 和 Ousterhout 为名为 Raft 的复制状态机发布了一种新的共识算法，其核心目标是可理解性（与 Paxos 不同）。

我们从 Raft 中学到的一个重要的新东西是使用共享超时来处理终止的概念。在 Raft 中，如果您崩溃并重新启动，您至少要等待一个超时时间，然后再尝试让自己被宣布为领导者，并且保证您会取得进展。

但是等等……“拜占庭”环境呢？

虽然传统的共识算法（例如 Paxos 和 Raft）能够使用某种程度的同步假设（即超时）在异步环境中蓬勃发展，但它们不是拜占庭容错的。它们只是崩溃容错的。

崩溃故障更容易处理，因为我们可以将进程建模为工作或崩溃——0 或 1。进程不能恶意行为和撒谎。因此，在崩溃容错系统中，可以构建一个简单多数足以达成共识的分布式系统。

在开放和去中心化的系统（例如公共区块链）中，用户无法控制网络中的节点。相反，每个节点都针对其个人目标做出决策，这可能与其他节点的目标相冲突。

在拜占庭系统中，节点具有不同的激励机制并且可以撒谎、协调或任意行动，你不能假设简单的多数足以达成共识。一半或更多的所谓诚实节点可以相互协调以撒谎。

例如，如果当选的领导人是拜占庭节点，并且与其他节点保持着强大的网络连接，则可能会危及系统。回想一下我们说过，我们必须对系统进行建模，以容忍简单故障或拜占庭故障。Raft和Paxos是简单的容错，但不是拜占庭式的容错。它们不是为了容忍恶意行为而设计的。

“拜占庭将军的问题”

试图建立一个可靠的计算机系统来处理提供冲突信息的进程，这被正式称为“拜占庭将军的问题”。拜占庭容错协议应该能够实现其共同目标，即使是针对来自节点的恶意行为。

Leslie Lamport、Robert Shostak 和 Marshall Pease 的论文“Byzantine General’s Problem”提供了解决拜占庭将军问题的第一个证明：它表明具有 $x$ 个拜占庭节点的系统必须至少有 $3x + 1$ 个节点才能达到共识。

原因如下：

如果 $x$ 个节点出现故障，则系统需要在与 $n$ 减去 $x$ 个节点协调后才能正常运行（因为 $x$ 节点可能出现故障/拜占庭式且没有响应）。但是，我们必须为没有响应的 $x$ 可能不是故障的可能性做好准备；可能是 $x$ 确实响应。如果我们希望非故障节点的数量超过故障节点的数量，我们至少需要 $n-x-x>x$。因此，$n>3x+1$ 是最优的。

但是，本文中演示的算法仅设计用于在同步环境中工作。无赖！看来我们只能选择其中一个（拜占庭式或异步式）正确。拜占庭和异步的环境似乎更难设计。

为什么？

简而言之，构建一个既能承受异步环境又能承受拜占庭环境的共识算法……嗯，这有点像创造奇迹。

像 Paxos 和 Raft 这样的算法是众所周知的并且被广泛使用。但也有很多学术工作更侧重于解决拜占庭+异步设置中的共识问题。

所以系好安全带……

我们要去实地考察……

到领地……

理论学术论文！

好的，好的 - 我很抱歉建立了这个。但你应该感到兴奋！还记得我们之前讨论过的整个“创造奇迹”吗？我们将看看两种算法（DLS 和 PBFT），它们使我们比以往任何时候都更接近于打破拜占庭 + 异步障碍。

The DLS Algorithm

Dwork、Lynch 和 Stockmeyer 的论文“Consensus in the Presence of Partial Synchrony”（因此称为“DLS”算法）介绍了拜占庭容错共识的重大进步：它定义了如何在“部分同步”中实现共识的模型同步系统。”

您可能还记得，在同步系统中，消息从一个处理器发送到另一个处理器所需的时间有一个已知的固定上限。在异步系统中，不存在固定的上限。部分同步位于这两个极端之间。

该论文解释了部分同步假设的两个版本：

假设消息传递所需的时间存在固定界限。但它们不是先验的。目标是达成共识，无论实际界限如何。
假设消息传递的上限是已知的，但只能保证从某个未知时间（也称为“全球标准化时间”，GST）开始保持。目标是设计一个无论何时发生都能达成共识的系统。

下面是 DLS 算法的工作原理：

每一轮都有一个提议者，并从每个流程开始，传达他们认为正确的值。
如果至少 $N - x$ 个进程已经传达了该值，则提议者“提议”一个值。
当一个进程从提议者那里收到提议的值时，它必须锁定该值，然后广播该信息。
如果提议者从 $x + 1$ 个进程接收到他们锁定在某个值上的消息，它会将其作为最终值提交。

DLS 是一项重大突破，因为它创造了一种新的网络假设类别——即部分同步——并证明了这种假设是可能的。 DLS 论文的另一个必要要点是将在拜占庭和异步环境中达成共识的问题分为两个部分：安全性和活跃性。

Safety

这是我们之前讨论过的“协议”属性的另一个术语，其中所有非故障进程都同意相同的输出。如果我们能保证安全，我们就能保证整个系统保持同步。我们希望所有节点都同意交易日志的总顺序，尽管失败和恶意行为者。违反安全意味着我们最终会得到两个或更多有效的事务日志。

Liveness

这是我们之前讨论的“终止”属性的另一个术语，其中每个非故障节点最终都会决定某个输出值。在区块链环境中，“liveness”意味着区块链通过添加有效的新区块而不断增长。活跃性很重要，因为它是网络可以继续发挥作用的唯一方式——否则，它就会停滞不前。

正如我们从 FLP 的不可能性中知道的那样，在完全异步的系统中无法达成共识。 DLS 论文认为，为实现 liveness 条件做出部分同步假设足以克服 FLP 的不可能性。

因此，论文证明了算法不需要使用任何同步假设来实现安全条件。

很简单，对吧？如果不是，请不要担心。让我们深入一点。

请记住，如果节点没有决定某个输出值，系统就会停止。因此，如果我们做出一些同步假设（即超时）来保证终止并且其中一个失败，那么这也会使系统停止是有道理的。

但是，如果我们设计一个假设超时（以保证正确性）的算法，那么如果同步假设失败，则存在导致两个有效事务日志的风险。

设计分布式系统总是需要权衡取舍。

这将比前一种选择危险得多。如果服务已损坏（即没有safety），那么拥有有用的服务（即 liveness）就毫无意义。基本上，拥有两个不同的区块链比让整个区块链停止更糟糕。

分布式系统总是需要权衡取舍。如果你想克服一个限制（例如，FLP 不可能性），你必须在其他地方做出牺牲。在这种情况下，将关注点分为安全性和活性是非常好的。它使我们能够构建一个在异步设置中安全但仍需要某种形式的超时来继续产生新值的系统。

尽管 DLS 论文提供了一切，但 DLS 从未在现实世界的拜占庭环境中广泛实施或使用。这可能是因为 DLS 算法的核心假设之一是使用同步处理器时钟，以便有一个共同的时间概念。实际上，同步时钟容易受到许多攻击，并且在拜占庭容错设置中表现不佳。

The PBFT Algorithm

由 Miguel Castro 和 Barbara Liskov 于 1999 年发表的另一种拜占庭容错算法被称为“实用拜占庭容错”（PBFT）。对于表现出拜占庭行为的系统，它被认为是一种更“实用”的算法。

从这个意义上说，“实用”意味着它可以在互联网等异步环境中工作，并进行了一些优化，使其比以前的共识算法更快。该论文认为，以前的算法虽然被证明是“理论上可行的”，但要么太慢而无法使用，要么假设为安全同步。

正如我们所解释的，这在异步环境中可能非常危险。

简而言之，PBFT 算法表明，假设 $(n-1)/3$ 个节点出现故障，它可以提供安全性和活性。正如我们之前所讨论的，这是我们需要容忍拜占庭故障的最小节点数。因此，算法的弹性是最佳的。

无论有多少节点出现故障，该算法都提供了安全性。换句话说，它没有为了安全而假设同步。然而，该算法确实依赖于同步来实现活力。最多 $(n-1)/3$ 个节点可能出现故障，并且消息延迟的增长速度不会超过某个时间限制。因此，PBFT 通过使用同步假设来保证活性来规避 FLP 的不可能性。

该算法通过一系列“视图”移动，其中每个视图都有一个“主”节点（即领导者），其余的是“备份”。这是它如何工作的分步演练：

一个新事务发生在客户端上并被广播到主节点。
主节点将其多播到所有备份节点。
备份执行事务并向客户端发送回复。
客户端希望从备份中得到 $x + 1$ 个具有相同结果的回复。这是最终的结果，状态转换发生了。

如果领导者没有故障，则协议工作得很好。然而，检测坏主节点并重新选择新主节点（称为“视图更改”）的过程非常低效。例如，为了达成共识，PBFT 需要二次消息交换，这意味着每台计算机都必须与网络中的所有其他计算机进行通信。

注意：完整解释 PBFT 算法是一篇博客文章！我们将把它留到另一天；）。

虽然 PBFT 是对以前算法的改进，但它不足以扩展到有大量参与者的实际用例（例如公共区块链）。但是，嘿，至少在故障检测和领导选举（与 Paxos 不同）之类的事情上，它更加具体。

承认 PBFT 的贡献很重要。它包含了重要的革命性思想，新的共识协议（尤其是在后区块链世界中）将从中学习和使用。

例如，Tendermint 是一种深受 PBFT 影响的新共识算法。在“验证”阶段，Tendermint 使用两个投票步骤（如 PBFT）来决定最终值。 Tendermint 算法的主要区别在于它的设计更加实用。

例如，Tendermint 每一轮都会轮换一个新的领导者。如果当前轮的领导者在设定的时间内没有响应，则跳过领导者，算法简单地移动到具有新领导者的下一轮。这实际上比每次需要改变视图并选出新的领导者时都使用点对点连接更有意义。

方法2：使用非确定性

正如我们所知，大多数拜占庭容错共识协议最终都使用某种形式的同步假设来克服 FLP 的不可能性。然而，还有另一种方法可以克服 FLP 的不可能性：非确定性。

Enter: Nakamoto Consensus

正如我们刚刚了解到的，在传统共识中，$f(x)$ 是这样定义的，即提议者和一群接受者必须协调和沟通才能决定下一个值。

传统的共识不能很好地扩展。

这太复杂了，因为它需要知道网络中的每个节点以及与每个其他节点通信的每个节点（即二次通信开销）。简而言之，它不能很好地扩展，并且在任何人都可以随时加入和离开网络的开放、无需许可的系统中不起作用。

中本聪共识的精彩之处在于使上述概率化。 $f(x)$ 不是每个节点都同意一个值，而是让所有节点都同意该值正确的概率。

等等，这到底是什么意思？

Byzantine-fault tolerant

与其选举领导者然后与所有节点协调，不如根据哪个节点可以最快地解决计算难题来决定共识。比特币区块链中的每个新区块都是由最快解决这个难题的节点添加的。网络继续在这条带时间戳的链上构建，而规范链是花费最多的累积计算工作量（即累积难度）的链。

最长的链不仅可以作为区块序列的证明，而且可以证明它来自最大的 CPU 能力池。因此，只要大部分 CPU 能力由诚实节点控制，它们就会继续生成最长的链并超过攻击者。

Block rewards

Nakamoto Consensus 的工作原理是假设节点将花费计算努力来决定下一个区块的机会。该算法的出色之处在于在经济上激励节点重复执行此类计算成本高昂的难题，以获得随机赢得大奖励（即块奖励）的机会。

Sybil resistance

解决这个难题所需的工作证明使该协议具有固有的 Sybil 抗性。不需要 PKI 或任何其他花哨的身份验证方案。

Peer-to-peer gossip

中本聪共识的一个主要贡献是使用了 gossip 协议。它更适合无法假设非故障节点之间通信的点对点设置。相反，我们假设一个节点只连接到其他节点的一个子集。然后我们使用点对点协议，在节点之间传递消息。

Not “technically” safe in asynchronous environments

在 Nakamoto 共识中，安全保证是概率性的——我们正在增长最长的链，每个新区块都会降低恶意节点尝试构建另一条有效链的概率。

因此，中本聪共识在技术上并不能保证异步设置中的安全性。让我们花一点时间来理解为什么。

对于在异步设置中实现安全条件的系统，我们应该能够在异步网络条件下保持一致的事务日志。另一种思考方式是，节点可以随时下线，然后再重新上线，并使用区块链的初始状态来确定最新的正确状态，而不管网络状况如何。任何诚实节点都可以查询过去的任意状态，恶意节点无法提供诚实节点认为是真实的欺诈信息。

中本聪共识在技术上不保证异步设置中的安全性。

在本文讨论的先前算法中，这是可能的，因为我们在每一步都确定性地最终确定一个值。只要我们终止每个值，我们就可以知道过去的状态。然而，比特币在“技术上”不是异步安全的原因是，有可能存在一个网络分区，允许在分区一侧具有足够大哈希能力的攻击者创建比诚实链更快的替代链在分区的另一边——在这条替代链上，他可以尝试更改他自己的一项交易以收回他花费的钱。

诚然，这将需要攻击者获得大量哈希能力并花费大量金钱。

从本质上讲，比特币区块链的不变性源于大多数矿工实际上并不想采用替代链这一事实。为什么？因为很难协调足够的哈希算力来让网络采用替代链。换句话说，成功创建替代链的概率非常低，几乎可以忽略不计。

Nakamoto vs. Traditional Consensus

出于实际目的，中本聪共识是拜占庭容错的。但它显然没有像研究人员传统上假设的那样达成共识。因此，它最初被视为完全脱离了拜占庭容错的世界。

根据设计，中本聪共识使得任意数量的节点都可以公开参与，无需任何人了解全部参与者。这一突破的重要性怎么强调都不为过。谢谢你，中本聪。

它比以前的共识算法更简单，它消除了点对点连接、领导者选举、二次通信开销等的复杂性。你只需在任何计算机上启动比特币协议软件并开始挖矿。

这使得它可以很容易地部署在现实世界的环境中。它确实是 PBFT 更“实用”的表亲。

Conclusion

就是分布式系统和共识的简要基础知识。分布式计算走到这一步，经历了漫长而曲折的研究、障碍和独创性之旅。我希望这篇文章可以帮助您至少更好地了解该领域。

中本聪共识确实是一项创新，它让全新的研究人员、科学家、开发人员和工程师浪潮继续在共识协议研究中开辟新天地。

并且正在开发超越中本聪共识的全新协议系列。proof of steak，有人吗？ ? 但我会把它留到下一篇文章中——敬请期待！

注意：为了不把它变成一本书，我跳过了许多重要的论文和算法。例如，Ben Orr 的 Common Coin 也使用了概率方法，但没有最佳弹性。 Hash Cash 等其他算法也使用 PoW，但用于限制电子邮件垃圾邮件和拒绝服务攻击。还有很多我遗漏的传统共识协议！我觉得以上内容足以帮助您在传统环境与中本聪的情况下很好地掌握共识。下一篇文章见！

参考链接：https://medium.com/s/story/lets-take-a-crack-at-understanding-distributed-consensus-dad23d0dc95