共识算法学习总结

最新推荐文章于 2023-06-10 10:05:31 发布

小圣.

最新推荐文章于 2023-06-10 10:05:31 发布

阅读量3.8k

点赞数 4

分类专栏：共识算法文章标签：共识算法区块链

本文链接：https://blog.csdn.net/qq_31639829/article/details/122797881

版权

共识算法专栏收录该内容

4 篇文章 6 订阅

订阅专栏

1. 分布式系统简介

1.1 什么是分布式系统

分布式系统（distributed system）是建立在网络上的软件系统。在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统。系统拥有多种通用的物理和逻辑资源，可以动态的分配任务。分散的物理和逻辑资源通过计算机网络实现信息交换。通常，对用户来说，分布式系统只有一个模型或范型。在操作系统之上有一层软件中间件负责实现这个模型。一个著名的分布式系统的例子是万维网。

1.2 分布式系统应具备的能力

分布式系统作为一个逻辑整体，不应该返回错误的结果
只要系统里的大部分机器工作正常，整个分布式系统就能有效运行，这也是分布式系统应用的一个优点，抵抗单点故障
系统的性能是可以横向扩展的，对于分布式系统来说，木桶原理不起作用
分布式系统必须是异步的，每个节点按照自己的时许独立工作，没有全序的时间顺序

1.3 分布式系统面临的问题

节点处理事务的能力不同，网络节点数据的吞吐量有差异
节点间通讯的信道可能不安全
系统中可能会出现恶意节点
当异步处理能力达到高度一致时，系统的可扩展性就会变差（容不下新节点的加入）

1.4 FLP定理

FLP定理来源于Fischer、Lynch、Patterson三位作者于1985年发表的论文，之后该论文毫无悬念的获得了Dijkstra（狄克斯特拉）奖。FLP给出一个结论：在异步通信场景中，即使只有一个进程失败，也没有任何算法能保证非失败进程达到一致性。所以不要浪费时间去为异步分布式系统设计在任何场景下都能实现共识的算法。

1.5 CAP定理

在理论计算机科学中，CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer’s theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：

一致性(Consistency)：所有节点在同一时间能够看到同样的数据.
可用性(Availability)：确保每个请求都可以收到其是否成功的响应，并且是在有限的时间内。
分区容错性(Partition tolerance)：因为网络故障导致的系统分区不影响系统正常运行。

既然不能同时满足，只有弱化对某个特性的支持：

弱化一致性：对于实时的强一致性不要有太高的要求
弱化可用性：只要提高性能，保持可靠，尽量避免加载不必要的模块，也就是牺牲可用性
弱化分区容错性：对于分布式系统，分区容错是必然的。区块链系统，尤其是公有链，用各种共识算法，优先解决的就是保证整个系统的容错能力

1.6 分布式系统一致性的要求

可终止性(Termination)：一致性的将结果可在有限时间内完成
共识性(Consensus)：不同节点最终完成决策的结果应该相同
合法性(Validity)：决策的结果必须是其它进程提出的提案。

1.7 分布式系统与区块链

区块链系统本质就是一个分布式系统。区块链结构是一种分布式架构。其部署模式有公有链、联盟链、私有链，对应的是去中心化分布式系统、部分去中心化分布式系统和弱中心化分布式系统。

2. 共识算法

2.1 定义

所谓的共识算法（共识机制），主要是为了解决分布式系统中，所有节点对于数据的一致性和有效性而指定的一系列规则。在分布式系统中，要保障系统满足不同程度的一致性，往往需要通过共识算法来达成。

2.2 分类

2.2.1 基于博弈论的共识算法

工作量证明： POW、POC、DAG
权益证明：POS、DPOS、POA

2.2.2 基于分布式一致性原理的共识算法

崩溃容错(CFT)：PAXOS、RAFT、ZAB
拜占庭容错(BFT)：PBFT、RBFT、HotStuff

基于分布式一致性原理的共识算法是面向数据库的，而基于博弈论的共识算法是面向交易的，所以严格来说，基于分布式一致性原理的共识算法应该处于基于博弈论的共识算法的下面一层。

2.3 共识算法的选择

在区块链网络中，由于应用场景不同，所设计的目标各异，不同的区块链系统采用了不同的共识算法。一般来说，在私有链和联盟链情况下，对一致性、正确性有很强的要求，一般采用强一致性的共识算法。而在公有链情况下，对一致性和正确性通常没法做到百分之百，通常采用最终一致性的共识算法。

3. 常见的共识算法

3.1 POW

POW(Proof Of Work)，即工作量证明

原理

节点接收到交易数据时，不断得对交易数据进行哈希，求得一个指定的nonce值。当全网有一位节点计算出nonce值时，他就会把交易数据打包成区块并广播出去。其它节点收到区块后进行验证，验证通过后该区块就会被添加到区块链中。

在计算nonce的过程中会消耗大量时间和能源，以此来确保服务与资源是被真正的需求所使用。

优点

架构简明扼要、有效可靠。
由于要获得多数节点承认，那攻击者必须投入超过总体一半的运算量（51%攻击），才能保证篡改结果。这使得攻击成功的成本变得非常高昂，难以实现。

缺点

挖矿的激励机制会造成矿池算力的高度集中，背离了当初去中心化设计的初衷。
PoW机制的共识达成的周期较长，每秒最多只能做7笔交易。
非常浪费能源。投入在一种加密货币上的能源，可能会超过一个小型国家的总使用量。

3.2 POS

POS(Proof Of Stake)，即股权证明。类似于财产存储在银行，这种模式会根据你持有数字货币的量和时间，分配给你相应的利息。

原理

在POS算法中，节点必须抵押数字货币才有打包区块的资格。算法在选定打包节点时使用随机的方式。但是节点被选为打包区块的节点与节点质押的数字货币数量及拥有数字货币的时长有很大的关系。节点成功打包一个区块后，其质押的币龄就会被清空，每被清空365币龄就会得到一些利息。

优点

因为不需要通过计算来确保交易安全，效率高，节约能源。
攻击PoS的成本高，需要购买大量币才能攻击网络。
可以快速实现交易规模化。

缺点

不能激励工作，获得收益来自于拥有货币以及拥有货币的时间。
富有的节点的投票权重高，去中心化的区块链可能因为投票权重高又实现中心化。

3.3 DPOS

DPOS(Delegated Proof of Stake)，即代理股权证明。DPOS是基于POS衍生出的更专业的解决方案，它类似于议会制度或人民代表大会制度。

原理

在DPOS共识系统中，每个权益持有者可以进行投票，由此产生数位代表，我们可以把这些代表理解为超级节点或者矿池，而这些超级节点的权利是完全相同的。如果这些代表不能够履行他们的职责时，他们就会被除名，网络中的权益持有者会选出新的超级节点来代替他。DPOS的出现最主要还是因为矿机的产生，大量的算力在不了解也不关心比特币的人身上，类似演唱会的黄牛，大量囤票而丝毫不关心演唱会的内容。

代表节点的候选名单每个维护周期更新一次。代表节点然后随机排列，每个代表节点有2秒的权限时间生成区块，若见证人在给定的时间片不能生成区块，区块生成权限交给下一个时间片对应的见证人。DPoS的这种设计使得区块的生成更为快速，也更加节能。

优点

大幅度缩小参与验证和记账节点的数量，可以达到秒级的共识验证
减少记账节点规模，属于弱中心化，效率提高

缺点

选举固定数量的见证人作为记账候选人有可能不适合于完全去中心化的场景，牺牲了去中心化的概念，不适合公有链。
在网络节点数少的场景，选举的见证人的代表性也不强

3.4 PBFT

PBFT(Practical Byzantine Fault Tolerance)，即实用拜占庭容错系统。原始的拜占庭容错系统由于需要展示其理论上的可行性而缺乏实用性。另外，还需要额外的时钟同步机制支持，算法的复杂度也是随节点增加而指数级增加。实用拜占庭容错系统，降低了拜占庭协议的运行复杂度，从指数级别降低到多项式级别，使拜占庭协议在分布式系统中应用成为可能。

算法流程

PBFT算法的主要流程图如下（来源于网络）：

request：
客户端c向主节点p发送<REQUEST, o, t, c>请求。o: 请求的具体操作，t: 请求时客户端追加的时间戳，c：客户端标识。REQUEST: 包含消息内容m，以及消息摘要d(m)。客户端对请求进行签名。
pre-prepare:
主节点收到客户端的请求，需要进行以下交验：
- 客户端请求消息摘要是否正确
- 客户端请求消息签名是否正确。
非法请求丢弃。正确请求，分配一个编号n，编号n主要用于对客户端的请求进行排序。然后广播一条<<PRE-PREPARE, v, n, d>, m>消息给其他副本节点。v：视图编号，d客户端消息摘要，m消息内容。<PRE-PREPARE, v, n, d>进行主节点签名。n是要在某一个范围区间内的[h, H]。
prepare:
副本节点i收到主节点的PRE-PREPARE消息，需要进行以下交验：
- 主节点PRE-PREPARE消息签名是否正确。
- 当前副本节点是否已经收到了一条在同一v下并且编号也是n，但是签名不同的PRE-PREPARE信息。
- d与m的摘要是否一致。
- n是否在区间[h, H]内。
非法请求丢弃。正确请求，副本节点i向其他节点包括主节点发送一条<PREPARE, v, n, d, i>消息, v, n, d, m与上述PRE-PREPARE消息内容相同，i是当前副本节点编号。<PREPARE, v, n, d, i>进行副本节点i的签名。记录PRE-PREPARE和PREPARE消息到log中，用于View Change过程中恢复未完成的请求操作。
commit:
主节点和副本节点收到PREPARE消息，需要进行以下交验：
- 副本节点PREPARE消息签名是否正确。
- 当前副本节点是否已经收到了同一视图v下的n。
- n是否在区间[h, H]内。
- d是否和当前已收到PRE-PPREPARE中的d相同
非法请求丢弃。如果副本节点i收到了2f+1个验证通过的PREPARE消息，则向其他节点包括主节点发送一条<COMMIT, v, n, d, i>消息，v, n, d, i与上述PREPARE消息内容相同。<COMMIT, v, n, d, i>进行副本节点i的签名。记录COMMIT消息到日志中，用于View Change过程中恢复未完成的请求操作。记录其他副本节点发送的PREPARE消息到log中。
reply:
主节点和副本节点收到COMMIT消息，需要进行以下交验：
- 副本节点COMMIT消息签名是否正确。
- 当前副本节点是否已经收到了同一视图v下的n。
- d与m的摘要是否一致。
- n是否在区间[h, H]内。
非法请求丢弃。如果副本节点i收到了2f+1个验证通过的COMMIT消息，说明当前网络中的大部分节点已经达成共识，运行客户端的请求操作o，并返回<REPLY, v, t, c, i, r>给客户端，r：是请求操作结果，客户端如果收到f+1个相同的REPLY消息，说明客户端发起的请求已经达成全网共识，否则客户端需要判断是否重新发送请求给主节点。记录其他副本节点发送的COMMIT消息到log中。

视图切换

一致性协议要求来自客户端的请求在每个服务节点上都按照一个确定的顺序执行。这个协议把服务器节点分为两类：主节点和从节点，其中主节点仅一个。在协议中，主节点负责将客户端的请求排序；从节点按照主节点提供的顺序执行请求。每个服务器节点在同样的配置信息下工作，该配置信息被称为视图，主节点更换，视图也随之变化。

如果主节点掉线或者作恶不广播客户端的请求，客户端设置超时机制，超时的话，向所有副本节点广播请求消息。副本节点检测出主节点作恶或者下线，将会发起View Change请求。

优点

共识的事件延迟大约在2-5秒，基本达到商用实时处理的要求
共识效率高，可实现高频率交易量的需求
非常适合联盟链的应用场景，因此成为目前使用最多的联盟链共识算法

缺点

当系统只剩下33%的节点运行时，系统会停止运行
PBFT算法在公有链中不适合

3.5 Raft

在一些分布式系统的实用场景下，其假设条件不需要考虑拜占庭故障，而是处理一般的死机故障。在这种情况下，采用CFT共识算法会更加高效。Paxos是Lamport设计的保持分布式系统一致性的协议。但由于Paxos非常复杂，比较难以理解，因此后来出现了各种不同的实现和变种。Raft是由Stanford提出的一种更易理解的一致性算法，意在取代目前广为使用的Paxos算法。

Raft最初是一个用于管理复制日志的共识算法，它是一个为真实世界应用建立的协议，主要注重协议的落地性和可理解性。Raft是在非拜占庭故障下达成共识的强一致协议。

Raft动画演示网站： http://thesecretlivesofdata.com/raft/

角色

在raft算法中，每个服务器是leader、candidate和follower三种角色的其中一种。正常操作情况下，仅有一个leader，其它服务器均为follower。follower是被动的，不会对自身发出请求而是对leader和candidate的请求做出响应。leader处理所有的客户端请求，弱客户端将请求发送到follower，follower将请求转发给leader。candidate角色用来选举leader。

Leader选举

当follower在选举超时时间内未收到leader的心跳消息，则转换为candidate状态。为了避免选举冲突，这个超时时间是一个150～300ms之间的随机数。

选举中的规则：

任何一个服务器都可以成为一个候选者candidate，它向其他服务器follower发出要求选举自己的请求。
其他服务器同意了，发出OK。注意，如果在这个过程中，有一个follower宕机，没有收到请求选举的要求，此时候选者可以自己选自己，只要达到N/2 + 1的大多数票，候选人还是可以成为leader的。
这样这个候选者就成为了leader领导人，它可以向选民也就是follower发出指令，比如进行记账。
以后通过心跳进行记账的通知。
一旦这个leader崩溃了，那么follower中有一个成为候选者，并发出邀票选举。
follower同意后，其成为leader，继续承担记账等指导工作。