区块链的核心之一是共识算法。因为各类区块链采用的共识算法不同，所以在运行性能、容灾容错性等方面的表现也不尽相同，进而决定了不同链适用场景上的差异。本期我们将挑选一些目前比较流行的共识算法进行探讨。目前较为常见的共识算法有POW、POS、DPOS、PBFT、RBFT，除此之外还有Hyperledger Fabric主推的Kafka、Raft，以下是各共识算法及对应的代表链。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算法的主要工作流程分为三阶段：2）当主节点接收到请求后，启动三阶段的协议以向各从节点广播请求。主节点给收到的请求分配编号，然后发出预准备消息<<PRE-PREPARE,view,n,digest>,message>给其他从节点。view：当前视图的编号。当因为主节点故障而发生视图轮换时，v值相应增加n：当前请求的编号。主节点收到客户端的每个请求都以一个编号来标记。注意，仅当满足以下条件，各从节点才会接受预准备消息：1、请求和预准备消息的签名正确，并且digest与message的摘要一致。3、该从节点从未在视图v中接受过序号为n的消息，或者接受过但是摘要d和消息m需要和上次消息的一样。从节点接收PRE-PREPARE消息，检查消息的合法性，检查通过后，向其他节点广播prepare消息<PREPARE,view,n,digest,id>，带上本节点的id，同时接受来自其他节点的PREPARE消息，收到PREPARE消息后同样进行合法性检查。一旦收到2f个不同节点的prepare消息，就代表prepare阶段已经完成。广播commit消息<COMMIT,view,n,digest,id>，告诉其他节点某个提案n在视图v里已经处于准备状态，如果它收到了2f+1条commit消息（包括自身的一条，这些来自不同节点的commit消息携带相同的编号n和view v），则说明提案通过。该请求就会被节点执行。在完成请求的操作之后，节点向客户端发送回复。客户端等待来自不同节点的响应，若有f+1个响应相同，则该响应即为运算的结果。通常在采用PBFT的共识机制下，主节点（Replica）负责将来自客户端的交易请求进行排序，然后按顺序发送给备份节点（Backups）。主节点拥有比其它备份节点更大的权利，一旦主节点出现问题，会导致系统中比较大的延迟甚至无法达成共识。国内自主研发的井通Jingtum联盟公链后续采用的RBFT共识机制针对这一缺陷进行了改进。RBFT参考借鉴了RAFT中的选举机制，采用投票表决方式进行节点选举，无需抢夺记账权，保证各个共识节点权益的公平性。与PBFT的不同之处主要在于，在节点的选择上使用了随机数。PBFT本是有限节点记账的共识机制，系统中只有被认可的节点才能作为记账节点。加入随机数之后，可以将静态的节点选择变为动态，使节点增多。RBFT算法类似于DPOS，但支持的节点数目远远超过EOS（21个），这可以使系统在不牺牲性能的前提下提高安全性。 以上POW、POS、DPOS、PBFT、RBFT是较常见的主流共识算法，接下来我们看看Hyperledger Fabric主推的Kafka和Raft。Kafka是一款基于zookeeper协调的领导者、跟随者模型的分布式消息系统，Hyperledger fabric 1.4以前版本主要通过kafka进行共识。Hyperledger Fabric是由IBM公司主导开发的一个面向企业级客户的区块链项目,后贡献给开源非营利组织 Hyperledger 基金会，Fabric是需要许可型平台，即适用联盟链及私有链，并且它会删除“并不适合企业场景”的特性, 需要注意的是fabric 2.0后将会去掉Kafka。
图1
图1中，一个订购服务，由5个订购服务节点(OSN-n)和一个Kafka集群组成。订购服务客户端可以连接到多个OSNs。注意，OSNs之间不直接通信。
这些有序服务节点(OSNs) (1)执行客户端身份验证，(2)允许客户端使用简单的接口写入或读取链，(3)它们还为重新配置现有链或创建新链的配置事务执行事务过滤和验证。
Kafka中的消息(记录)被写入主题分区。一个Kafka集群可以有多个主题，每个主题可以有多个分区（图2）。每个分区都是一个有序的、不可变的记录序列，它被不断地追加来者客户端的交易记录。
图2
现在看看Fabric中Kafka的完整工作流程：
排序服务客户端将收集到的记录发往各OSN，OSN将批量交易打包成block,并生成用于验证的签名，同时为block分配kafka上的partition分区及partition中的offset偏移量。OSN将block发送至kafka集群中指定的partition中对应偏移量的位置上。
各OSN按相同顺序从partition中读取block发往对应channel中的各peers验证节点进行验证。
部署方面，由于Kafka集群大都需要部署到大型公司、集团总部或者云厂商，保证高计算能力和高可用，当Kafka所在的联盟链间各个企业不存在一强多弱，真正是几家平等的企业在合作时，在技术设计中就会存在一个比较大的疑惑，Kafka排序服务应该部署在哪里呢？也许部署到公有云上是一个选择，但当云厂商本身是利益的相关方呢？
Raft
Raft与Kafka一样也是领导者、跟随者模型，以下是大致执行过程
节点初始都是跟随者follower,每个follower都有自己的timeout，时间范围在150ms - 300ms之间，timeout后若未检测到来自Leader的心跳消息，则follower自动升级为Candidate（候选者），并向网络中其它节点发送选举自己为Leader的投票消息。
当收到大部分的票数后，候转节点变为Leader,同步消息至网络中其它节点以确认新的Leader，之后开始处理Leader收到的来自客户端的消息。
Leader将收到的来自客户端的消息记录至本地日志中，并同步至各follower节点，各节点确认没问题后返回确认消息给Leader，Leader返回处理结果给客户端，同时更新日志中的消息至持久化存储区域，并且同步给各follower。
Raft具体执行过程可参考链接 http://thesecretlivesofdata.com/raft
但是Raft用于区块链共识的前提是“假设将军中没有叛军”，简单通俗的说法就是在分布式系统中机器节点可能会挂，网络可能延迟、重复或者丢失，但是机器节点不会作恶，传递的消息也不会被篡改，区块链的重要特性之一为不可篡改，而在无拜占庭容错的情况下，这一特性显然无法完全得到保障，一但出现节点作恶，对链与应用带来的影响无法想象。
在上文对各共识算法分别进行了原理探讨后，我们简单归纳整理如下：
共识算法 | 代表链 |
POW | 适用无信任授权区块链，如BTC（比特币)、ETH（以太坊),优点是完全去中心化、公平公正，安全，缺点是需要消耗大量算力，浪费能源，出块慢，效率低。 |
POS | 较适用联盟链、私链，优点是比POW出块更快，缺点是去中心化不强，通过持币量越高，越有话语权，很容易形成对记账权的垄断，不利于区块链生态发展。 |
DPOS | POS的PLUS版，适用联盟链、私链，优点是共识节点数相对稳定，比POS出块更快。 |
PBFT | 适用于联盟链、私链，优点是支持拜占庭容错，能提供较稳定服务，缺点是主节点权利太大，一旦主节点出现问题，会导致系统中比较大的延迟甚至无法达成共识,并且支持节点数较少。 |
RBFT | 适用于联盟链、私链，加入了随机数概念，削弱了主节点的权利，能启用更多的静态节点，性能更高，出块时间稳定控制在秒级，程序接入简单，耦合低。 |
Kafka | 适用于私链，优点是方便对交易排序，性能高。缺点是中心化程序较高，且不支持拜占庭容错。 |
Raft | 与Kafka相似，适用于私链，优点是支持拜占庭，但不支持拜占庭容错，即在分布式系统中机器节点可能会挂，网络可能延迟、重复或者丢失，但是机器节点不会作恶，传递的消息也不会被篡改。 |
结语：
企业对链的选择，其实就是对共识算法的选择，每种共识算法自有其适用的场景，企业可以根据自身情况进行择优选择。我们的认知还有很多疏漏之处，欢迎各位朋友斧正。
版权申明：本内容来自于互联网，属第三方汇集推荐平台。本文的版权归原作者所有，文章言论不代表链门户的观点，链门户不承担任何法律责任。如有侵权请联系QQ：3341927519进行反馈。
