第6章　集成共识机制的排序服务

本章会介绍共识的一些基本概念和Hyperledger Fabric 1.0中的共识机制，及其可插拔的架构设计。

6.1　概述

在区块链系统中，共识（Consensus）是多个参与方对一个交易是否提交到账本以及提交的顺序达成一致的过 程。由于是多个节点参与的分布式系统，所以网络传输可能存在延时。共识一致并不代表在所有时刻都有完全相同的结果，是经过一段收敛时间后，网络中的多数节 点对同一个交易执行相同的记账操作。在共识的过程中可能存在一些节点无响应或者响应延迟的情况，也可能存在一些参与方恶意提交请求或者篡改请求内容的情 况。根据错误类型的不同，共识算法可以满足两种范围的容错。加 入 会 员 微 信 dedao555

1）崩溃故障容错（Crash Fault-Tolerance，CFT）：在区块链网络中存在网络延时或者故障的情况下，共识机制能够确保有效的交易达成一致。

2）拜占庭容错（Byzantine Fault-Tolerance，BFT）：在区块链网络中存在部分恶意节点提交或者篡改请求的情况下，共识机制能够确保有效的交易达成一致。

在共识过程中网络节点要确保交易有序且交易区块有效，需要提供以下核心功能。

1）交易有效：能够根据背书及共识策略确保区块中所有交易有效。

2）交易有序：能够确保所有节点提交和执行交易顺序的一致性，这才能保证执行结果的一致性和最终全局状态的一致性。

3）交易验证：能够利用智能合约的接口，验证交易的有效性和提交顺序。

根据第3章的交易流程，我们看到在Hyperledger Fabric 1.0中，一个交易从提交到最终记账会经历多个阶段，每个阶段都需要多节点的参与，共识是在分阶段共识基础上的全过程共识，对于任何一个阶段的共识失败，最终结果都是共识失败。

6.1.1　共识算法的类型

共识算法必须具备两个特性以保证节点之间数据的一致性。

1）安全性（Safety）：它指每个节点保证相同的输入序列，并在每个节点上产生相同的输出结果。当节点接收到相同顺序的交易时，每个节点将发生同样的状态改变。算法的执行结果必须与单节点系统依次执行每个交易的结果一致。

2）存活性（Liveness）：指在没有通信故障的情况下，每个非故障节点最终都能接收到提交的所有交易。

节点一致性在账本上的体现是：

1）区块的确定性：在不同节点上相同区块号的区块内容完全一致；

2）区块的完整性：在不同节点上有相同的区块数，且按照顺序形成相同的区块链。

共识算法大体可以分为两种类型，基于彩票中奖的算法（Lottery-based Algorithm）和基于投票计数的算法（Voting-based Algorithm）。

基于彩票中奖的算法是一个形象化的说法，加入到区块链网络中的节点都可以生成区块，广播给网络中的其他节点以进行 确认，通过竞争获得最终的记账权。实际上，区块是否获取其他节点的确认是有一定概率的，这与买彩票中彩一样。这种算法是一种先记账再共识的算法，优势是其 可以很容易地扩展到大量的节点上，缺点是区块记账是一种大概率的确认算法，区块确认的时间较长。常见的一些算法，如消逝时间量证明算法（Proof of Elapsed Time，PoET）和工作量证明算法（Proof of Work，PoW）都属于这一类算法。

基于投票计数的算法是节点参与区块的投票，网络中的节点确认区块以后再记账的过程。这种算法中区块的记账是确定性 的，已经记账的区块都是有效的。这是一种绝对一致的机制，确定的结果才能在某些对结果要求比较高的场合使用，比如金融场景，已经完成的转账是不能随意地撤 回的。这种算法的缺点是需要更长的时间达成共识，不能满足某些需要高吞吐量、低延迟的场景要求。这就需要不同的应用场景在可扩展性、确定性和速度等方面进 行一个权衡。冗余拜占庭容错算法（Redundant Byzantine Fault Tolerance，RBFT）和Paxos都属于这一类型的算法。

表6-1所示为这两种算法的比较。

表6-1　共识算法类型的比较

超级账本应用场景的目标是企业级的区块链平台，网络节点一般是需要授权加入的，所以超级账本是不支持标准的PoW算法的。

6.1.2　Hyperledger Fabric 1.0的共识机制

超级账本中是把共识分为3个阶段

（1）交易背书

应用程序根据背书策略的要求选择背书节点，给这些节点发送需要执行的交易提案（Proposal）。背书节点调用 链码（Chaincode）执行这些交易提案，交易过程是执行是模拟执行的，并不真正提交数据到账本中。执行完成以后调用交易背书系统链码ESCC对模拟 执行结果进行签名背书。

（2）交易排序

排序阶段接受已经签名背书的交易，确定交易的顺序和数量，将排好序的交易打包到区块中，广播给Peer节点进行验证。通常，从效率方面考虑，排序服务不会输出单个交易作为一个区块，而是把多个交易打包成一个区块。

（3）交易验证

Peer节点验证接收到区块里包含的交易的有效性，包括背书策略验证及双花检测（double- spending）。可以将验证错误分为两大类：语法错误和逻辑错误。语法错误包括无效输入、未验证的签名以及重复的交易（双花攻击），重复的交易应该丢 弃。第二类错误比较复杂，比如会导致双花或者MVCC失败的交易，这需要定义策略来决定程序是继续执行还是终止。策略还可以定义是否需要记录日志以便对这 类交易进行审计。交易验证依赖链码的业务逻辑，目前默认的交易验证系统链码VSCC只支持背书策略的验证，详细的过程后面的章节会有介绍。

在超级账本中这3个阶段的设计均是可插拔的，应用程序可根据自身需求实现和选择不同的交易背书、交易排序及交易验证模块。

我们先来看下交易背书和交易验证的可插拔设计。交易背书和交易验证由内置的系统链码（System Chaincode）来实现，这两个系统链码都是可替代的。可以把交易背书和交易验证的功能逻辑实现成链码（Chaincode）并提交到链上，在提交交 易提案的时候指定新的交易背书和交易验证链码。前面的章节已经详细介绍过peer chaincode命令，里面的“-E”和“-V”参数就是指定新的交易背书和交易验证系统链码的。

排序服务的实现也是可插拔的，它采用的是异步事件的方式，提供了两个基本的接口：

1）broadcast（blob）：客户端调用broadcast接口在通道上广播blob消息。

2）deliver（seqno，prevhash，blob）：排序服务调用deliver给客户端发送blob消息，包含序号seqno（无符号整数）和上一个消息的哈希（prevhash），它是排序服务的事件输出接口。

目前，正式发布的版本只支持Apache Kafka的排序服务。排序服务接口会加入基于BFT协议的算法，目前正在开发中的算法有BFT Smart、简化拜占庭容错算法（SBFT）、蜜罐拜占庭容错算法（Honey Badger of BFT）等。在本章的后面部分我们会详细介绍排序服务的接口，大家可以实现一个自定义的排序服务。

来源：我是码农，转载请保留出处和链接！

本文链接：http://www.54manong.com/?id=1064

• 共识算法2018-09-25 10:03
• 区块链+2018-09-25 17:17
• 中国打击比特币努力效果有限 2018-09-05 13:01
• 2.5 总结2018-09-12 14:56