浅议区块链的共识算法(区块链技术共识算法)

下面由小编针对浅议区块链的共识算法为您答疑解惑，希望能给您带来有一些有效参考。

区块链的核心之一是共识算法。

因为各类区块链采用的共识算法不同，所以在运行性能、容灾容错性等方面的表现也不尽相同，进而决定了不同链适用场景上的差异。

本期我们将挑选一些目前比较流行的共识算法进行探讨。

目前较为常见的共识算法有POW、POS、DPOS、PBFT、RBFT，除此之外还有Hyperledger Fabric主推的Kafka、Raft，以下是各共识算法及对应的代表链。

共识算法代表链POWBTC(比特币)、ETH(以太坊)POSATOM(阿童木)DPOSEOS(柚子)PBFT&RBFTSWTC(井通)KafkaHyperledgerFabricRaftHyperledgerFabric接下来我们对这些共识算法逐一介绍。

POW(Proof Of Work)- 工作量证明所有竞争记账方需要通过大量运算对一道算法题求解，最先得到问题正确答案的一方将获得本轮的记账权，计算机算力越高，越有机会获得记账权，算力是计算机硬件（CPU、GPU等）提供的，要耗费 电力，造成能源的大量浪费，主要使用在无信任关系的公链上，出块慢。

POS(Proof Of Stake)- 权益证明POS记账权由币龄决定，币龄怎么获得呢，比如你有1W个Token，经过一段时间之后，比如10天，那么你的币龄为1W x 10= 10W。

假如此时你的币龄是网络节点中最大的，那么你就获得了记账权，自然能拿到记账的Token奖励，所以这种模式下拥有Token数量越多的人越有机会获得记账权。

这种共识的优点是持有Token数量越多的人会越自觉维护链的秩序，因为作恶成本高。

共识过程相比POW更快，因为POS通过币龄来确定获得记账权的难度远低于POW通过全网大量运算得到正确答案的难度。

缺点是去中心化程度不高，因为币龄的机制决定了记账权容易被大资本掌控, 贫富差距容易变大。

在POS机制下，Token持有量少的人很难获得记账权，也就无法获得记账奖励，而Token大户很容易形成记账权垄断，对链的生态发展是不利的。

DPOS(Delegated Proof Of Stake)- 委托权益证明相当于POS的升级版，在节点中增加了委托人概念，各网络节点均可以参加投票，选出节点代表，由这些得票高的节点代表轮流记账，相对POS去中心化程度有所好转，出块时间更短，效率更高。

PBFT(Practical Byzantine Fault Tolerance)- 实用拜占庭容错PBFT是区块链共识机制的主流算法之一，经过优化，将拜占庭容错算法从指数级别降低到多项式级别，支持在网络弱同步性情况下，在叛变节点不超过总节点的1/3情况下（最坏需要F+1轮交互，F为叛变节点），确保整个系统达成共识。

C为客户端，0 ~3 表示从节点，特别的，0为主节点，3 为故障节点。

如上图所示，pbft算法的主要工作流程分为三阶段：1）客户端发送请求，激活主节点的服务操作。

2）当主节点接收到请求后，启动三阶段的协议以向各从节点广播请求。

阶段一 Pre-Prepare主节点给收到的请求分配编号，然后发出预准备消息<<PRE-PREPARE,view,n,digest>,message>给其他从节点。

view：当前视图的编号。

当因为主节点故障而发生视图轮换时，v值相应增加n：当前请求的编号。

主节点收到客户端的每个请求都以一个编号来标记。

digest：消息摘要message：消息注意，仅当满足以下条件，各从节点才会接受预准备消息：1、请求和预准备消息的签名正确，并且digest与message的摘要一致。

2、当前视图编号是v。

3、该从节点从未在视图v中接受过序号为n的消息，或者接受过但是摘要d和消息m需要和上次消息的一样。

4、编号n必须在高低水位h和H之间。

阶段二 Prepare从节点接收PRE-PREPARE消息，检查消息的合法性，检查通过后，向其他节点广播prepare消息<PREPARE,view,n,digest,id>，带上本节点的id，同时接受来自其他节点的PREPARE消息，收到PREPARE消息后同样进行合法性检查。

一旦收到2f个不同节点的prepare消息，就代表prepare阶段已经完成。

只有满足以下条件，各个点才会接受一个准备消息：1、消息的签名正确。

2、视图编号一致。

3、编号n满足高低水位。

阶段三 Commit广播commit消息<COMMIT,view,n,digest,id>，告诉其他节点某个提案n在视图v里已经处于准备状态，如果它收到了2f+1条commit消息（包括自身的一条，这些来自不同节点的commit消息携带相同的编号n和view v），则说明提案通过。

该请求就会被节点执行。

在完成请求的操作之后，节点向客户端发送回复。

只有满足以下条件，各个点才会接受一个确认消息：1、消息的签名正确。

2、视图编号一致。

3、编号n满足高低水位。

客户端等待来自不同节点的响应，若有f+1个响应相同，则该响应即为运算的结果。

RBFT(Randomized BFT)通常在采用PBFT的共识机制下，主节点（Replica）负责将来自客户端的交易请求进行排序，然后按顺序发送给备份节点（Backups）。

主节点拥有比其它备份节点更大的权利，一旦主节点出现问题，会导致系统中比较大的延迟甚至无法达成共识。

国内自主研发的井通Jingtum联盟公链后续采用的RBFT共识机制针对这一缺陷进行了改进。

RBFT参考借鉴了RAFT中的选举机制，采用投票表决方式进行节点选举，无需抢夺记账权，保证各个共识节点权益的公平性。

与PBFT的不同之处主要在于，在节点的选择上使用了随机数。

PBFT本是有限节点记账的共识机制，系统中只有被认可的节点才能作为记账节点。

加入随机数之后，可以将静态的节点选择变为动态，使节点增多。