隋 源，汪 卫，邓 雪

1(复旦大学 软件学院 数据库与海量信息处理实验室，上海 200433)2(复旦大学 计算机科学技术学院 数据库与海量信息处理实验室，上海 200433)3(珠海复旦创新研究院，广东 珠海 518057)

E-mail：18212010027@fudan.edu.cn

1 引 言

从2009年最初的比特币开始，区块链技术也不单单局限于加密数字货币的应用，更多的研究逐渐的将重点放在如何将数据管理能够与区块链更好的结合.区块链本质上是一个去中心化的不可篡改的分布式账本，区块链技术是集成数据库、共识机制、密码学、分布式数据存储等多个方向的应用研究.区块链网络中每个节点都是互相独立的个体，彼此不信任对方，通过密码学的手段网络中的所有节点选举出背书节点，并定期更换背书节点，维护一个哈希加密的链式数据结构.从数据库的角度看待区块链，区块链是一个存储了大量时间戳数据的数据库.区块链自身需要大量的共识和密码计算来保证自身的效率，这就导致了传统结构的区块链的系统吞吐量都比较低，不能满足用户的需要.

区块链本身具有防篡改的特性，随着区块链在其他领域的应用和发展，例如金融、供应链、物流等领域，用户对可验证查询的需求也越来越高，比如用户想要查询“昨天晚上六点”这样的历史数据，可验证查询是指提供查询服务的节点在把查询结果返回给请求查询的用户的同时，也会返回一个可以证明查询结果正确可靠的数据结构.区块链数据管理研究方向是从数据库的角度，运用成熟的传统的数据库技术来解决区块链系统存在的问题.由此很多数据库化的区块链系统和新的方法被提出.区块链数据管理是一个全新的方向，主要涉及的领域有数据溯源、查询验证、版本控制等等.许多的数据库研究机构IBM，Oracle和SAP以及诸如FlureedDB[1]，BigchainDB[2]，和SwarmDB[3]，也都在致力于研究成熟的数据库技术如何在区块链中加以利用.

为此，本文提出了一种通过增加链下数据库层的方式，增加系统的每秒事务吞吐量，如图1所示是一种增加链下数据库层的方法示意图.链下数据库负责存储全部的数据，链下数据库的类型可以是一个性能成熟强大的关系型或者是NoSQL类型的数据库，本文中链下数据库采用了HBase(1)https：//hbase.apache.org/，首先HBase适合海量数据，这对于区块链源源不断产生时间序列数据的情况是一个很好的优势.它的易拓展、高并发的特点，对于本身是分布式的区块链网络有着很大的帮助.链下数据库按批次的将全部数据存储，并计算每个批次的消息摘要值，存放在区块链上.这样的结构，链下数据库可以提供性能的保证，区块链可以提供安全的保证.

本文工作如下：

提出一种区块链结合链下数据库的模式，以应对系统每秒吞吐量比较高的应用场景；

基于这种模式，提出了一种可以根据信任程度不同的多模式可验证查询方法和一种异步可验证查询方法；

对于链下数据库结合区块链的方式，进行了与没有链下数据库的区块链的对比试验，并验证了可验证查询的效率.

2 区块链数据管理面临问题及挑战

2.1 相关工作

目前区块链的研究已经不止局限于代币，国外目前已经有了一些区块链在工业领域应用的研究，大致可以分为几个方面：

提升事务处理速度(TPS)：由于区块链的防篡改特性，必须使用大量的密码学和共识机制来保证系统的安全稳定，这就导致了大部分的区块链系统的事物处理能力遇到了瓶颈，为了提升系统的事务处理能力，Ankur Sharma等人[4]通过重新组织事务顺序，识别事务语义来减少失效事务的数量，并尽早的识别确定失效的事务，来提升事务处理的能力.通过改变区块链系统的结构也可以达到提升系统的事务处理能力，Hung Dang[5]通过分片的方式，并行产生区块，这种并行出块的结构在以太坊等区块链系统中也得到了利用.

还有的研究[6-11]通过增加外源数据库来实现提升事务处理能力的效果，因为一些成熟的数据库的事务处理能力很强，可以通过把数据放在线下，加密证据放在线上的方式来达到提升事务处理速度的效果.

可验证查询：区块链与传统数据库相比，不可篡改的特性是一个很大的优势，但是目前大部分的区块链系统并不支持可验证查询，Cheng Xu 等人[6]通过更改区块结构，来支持可验证的查询，并且保证查询结果的完整性，并且在效率上也有一定的保证.

版本控制：分叉问题是区块链系统的一个缺陷，比特币和以太坊自从诞生以来都经过了很多次硬分叉.但是Sheng Wang 等人[7]通过一种Merkle有向图(Merkle DAG)的数据结构，将这种缺陷利用到了版本控制技术领域中，有效的解决了版本之间的空间效率问题.

数据溯源：在现有区块链中查询数据历史只能通过重放所有交易来完成，这种方法适用于大规模，离线分析，但不适合在线事务处理.在工业应用领域溯源查询往往是比较常见的.PingchengRuan等人[8]通过在Hyperledger和一个名为ForkBase的区块链优化存储系统之上实现了LineageChain，支持高效的溯源查询并且可以有效的利用空间资源.

2.2 相关技术——Hyperledger Fabric

Hyperledger Fabric(2)https：//www.hyperledger.org/use/fabric是IBM提出的一种联盟链区块链系统，在这个网络中，每个节点都是已知的，每个节点都运行着一个账本的实例，除此之外每个节点存储着一份当前状态的数据.该系统有着高效的事务处理流，分为模拟、排序、验证、提交4个阶段.在模拟阶段，client向对peer的指定子集(背书节点)提交事务建议.背书节点根据其当前状态的本地副本模拟交易.在排序阶段，排序服务在所有接收到的事务之间建立全局顺序，并以块的粒度将排序好的事务分配给网络的所有peer.在验证阶段，所有对peer根据背书分别验证所接收块内的事务.在提交阶段，将块追加到本地账本，并将有效交易记录所做的更改应用于当前状态.

Hyperledger Fabric是一种联盟链的架构，所有的节点在整个网络中每时每刻都是已知的.每个节点都被分配到一个组织中，这意味着每个节点被所在的组织管理和监督.在一个组织中，所有节点都互相信任，每个节点都运行一个Fabric的本地实例，实例包括全网账本的副本，具体是全网的交易事务的有序序列(即包括有效事务，又包括无效事务).除了全网账本的副本以外，每个节点还以状态数据库的形式包含当前状态，除了在模拟阶段和验证阶段都扮演重要角色的节点之外，还有一个名为排序服务的单独节点，它是排序阶段的核心组件，被认为是值得信任的.

2.3 面临问题及挑战

目前的在食品药品等制造生产中，数据防伪、数据溯源等是很重要的技术，用户或者监管部门需要知道每个环节中的数据，每个环节的数据也要保证安全可靠防篡改.考虑这样一个场景，在某种食品药品生产运输销售的过程中，涉及到，生产商，运输商，销售商，消费者和一些监管部门.

当消费者拿到自己购买的商品后，若想知道该商品是否是符合生产标准的，就需要溯源可验证查询的支持.例如在运输的过程中，运输环境需要低于一定的温度，那么运输商就需要按照时间序列将温度、湿度等信息进行保存.传统的溯源的方法的数据库仅仅考虑了数据的存储，并没有考虑存储数据的安全性.

区块链本身有防篡改的特性，在防伪溯源领域有先天的优势，但是由于大量的共识算法导致区块链的每秒事务吞吐量(TPS)遇到了瓶颈.普通的关系型数据库或者NoSQL并不能提供防篡改的安全性保障.

由于在这里想解决的问题是提升区块链的每秒事务吞吐量(TPS)，一些以代币为基础的区块链应用在事务吞吐量角度的缺陷较为严重，Bitcoin(3)https：//bitcoin.org/en/、Ethereum(4)https：//ethereum.org/这些系统在事务吞吐量方面的表现并没有任何优势.而一些以物联网为基础的区块链应用平台在事务吞吐量方面优势就很明显，如Hyperledger Fabric、IOTA(5)https：//www.iota.org/.

Hyperledger Fabric是一个开源的联盟链框架，继承独立的开放协议和标准，通过框架方法和专用模块，包括各区块链的共识机制和存储方式，以及身份服务、访问控制和智能合约.但是Hyperledger Fabric在真正部署应用的过程中还存在很多不足：

1) 事务处理速度不够，通过实验获得到当使用CouchDB作为状态数据库时TPS在300个/秒左右，这样的事务处理能力是远远不够的；

2) 查询功能不够完备，底层数据库是levelDB，只支持简单的等值查询.

为了解决以上的两个问题，本文的思路是在Hyperledger Fabric架构的基础上引入一个外源数据库，由外源数据库提供存储及查询效率的保证，区块链提供数据安全的保证.

3 链下数据库改进的Hyperledger Fabric架构

3.1 高吞吐量Hyperledger Fabric+外源数据库架构

虽然Hyperledger Fabric的每秒事务吞吐量较传统结构的区块链相比已经有了很大的提升，但是并没有达到关系型或者NoSQL类型数据库那样高的标准，为了更进一步的提升每秒事务吞吐量，在Hyperledger的基础上加入一层外源数据库，外源数据库为区块链提供事务吞吐量.

图1 链下数据库架构Fig.1 Off-chain database schema

以HBase作为一个例子，HBase作为一个链下数据库，存放所有的数据，并将数据按照批次进行打包计算消息摘要值，仅将消息摘要值存放到区块链上，这样的做法会大大提升每秒事务吞吐量.这样的一个HBase作为区块链的链下数据库架构如图1所示.

图1中有4种类型的节点分别是client、peer、order和data center.节点作用见表1，Data center节点负责存储所有数据，并定期检查数据安全性；client节点负责与用户进行交互，与peer节点进行通信；peer节点是核心节点，负责背书、记账，将智能合约变成状态更新发送给order节点，peer节点还存储了区块链中所有的交易数据，即每个批次的数据的消息摘要值，并不是所有的数据，全数据在data center节点中存储；order节点提供排序服务，将peer发送给order的交易数据排序并产生区块，广播给全网的peer节点.

表1 节点类型及作用Table 1 Node types and functions

在某食品生产销售的过程中，有生产商、运输商、销售商和消费者群体这几个相互独立的组织，他们之间互相不信任.那么生产商、运输商和销售商就可以构成3个组织，每个组织都实时的产生自己的数据并存放到链下数据库中，并通过3个组织的区块链网络对数据进行加密，区块链使得线下数据库中的数据不可篡改.

3.2 数据更新维护方法

溯源系统中，数据是实时产生，例如在运输的过程中传感器产生时间序列数据，这些时间序列数据需要实时的存入，通过client节点发送给data center节点，data center节点首先缓存这些数据，当数据达到一定数量时(如100条)，数据中心节点将这一定数量的数据打包成一个批次，并计算消息摘要值.之后data center将消息摘要值通过peer节点添加到区块链上.

为了方便说明，给出一个例子：假设只有一个组织(例如生产商)，生产商需要将生产过程中的数据存入到链下数据库中并且存证以便消费者或者监管部门查询.组织内部有client节点、peer节点、order节点和数据中心节点，client节点源源不断的接收到时间序列数据(例如传感器数据)，假设client收到的数据，并向data center节点(HBase)发送.

组织1的data center节点设置每10条数据为一个批次，时刻到时刻，组织1的data center节点插入了10条数据如表2所示.

t1时刻到t2时刻，组织1的data center节点生成了10条数据如表3所示.

Data center节点将传感器时刻到时刻的数据作为第1批次的数据打包在一起，并计算消息摘要值，为方便说明，消息摘要值采用SHA256计算方法.

根据表2中传感器时刻到数据构建一个二维数据，所计算出来的消息摘要值为911c6da8a8da020fe625d98553f23383，data center节点将它保存，并且通过client节点将存到区块链中.

表2 第1批次的数据Table 2 First batch data

表3 第2批次的数据Table 3 Second batch data

同理，表3中的数据计算出消息摘要值为f725063aa16bed9c971df65473c0b312，data center节点同样将它保存，并且通过cli节点将存到区块链中.

算法1.数据插入算法(Insert Data)

输入：一段时间序列数据Vector

输出：true or false

数据中心节点Data Center：

1.functionBoolean

插入数据(Vector，data，invoke)

2. 数据缓冲区.append(data)

3.while(缓冲区达到数据块大小){

4. Hx=计算消息摘要(数据缓冲区)

5. putDB(Hx)//将Hx放入数据中心中

6. putBLC(Hx) //将Hx放入区块链中

7.returntrue

8. }

9. return true

算法1的1-2行表示当数据量没有达到预先设定的数据块大小时，将数据暂时放入缓冲区；3-7行表示，如果缓冲区中的数据达到预先设定的数据块大小，则计算数据块消息摘要，并放入数据库和区块链中.

如图2所示，data1数据代表传感器第一个批次的数据，data center节点将它计算消息摘要值并将它同时存放在data center和区块链中，算法1说明了数据插入的过程.

3.3 数据存放方式

在生产销售溯源场景中，在生产商生产的过程中，需要将全数据记录在data center节点，比如需要记录的传感器温度，传感器将温度数据实时的传送给data center节点，区块链负责对data center节点进行加密.

图2 插入数据示意图Fig.2 Insert data schema

Data center节点在整个结构中起着很重要的作用，它负责存储全数据，定期检查数据的安全可靠性，为全网提供可靠的查询服务，所以data center节点的安全性是很重要的一个环节.单纯的集中式的data center节点会存在容易被攻击、宕机后只有一个节点无法再继续提供服务的问题.为了解决这些问题，data center节点不应该仅仅有中心化模式，在这里考虑3种模式的data center，第1种是中心化的data center节点；第2种是data center节点不只有一个，而是有很多个备份；第3种是采用分布式数据库，通过Hadoop搭建分布式HBase.

3.3.1 中心化HBase

中心化的HBase所有的组织公用一个data center节点，在实际的溯源场景中，如图3(a)所示，这个HBase节点存储全网的数据，包括生产商、运输商、和销售商的数据，定期打包批次数据，并为全网提供查询和验证支持.

3.3.2 备份HBase

单节点的HBase缺陷是很明显的，比如当唯一好的HBase节点收到攻击时，没有其他备份节点，在唯一的HBase节点宕机之后，无法保证整个网络的正确有效的运行.

第2种网络结构是HBase节点有多个备份，在图3(b)中，每个组织都有一个HBase节点，每个HBase节点都保存着全网的所有数据，当其中某一个HBase节点出现问题宕机时，其余的HBase节点可以继续保证全网的运行.

3.3.3 分布式HBase

多备份的HBase节点虽然可以保证一定的安全可靠性，但是缺少有效的数据同步的方法，不同之间的HBase节点之间保证数据的一致较为困难.为此data center节点可以采用分布式数据库，例如HBase可以通过Hadoop支持实现分布式.

如图3(c)，分布式HBase通过DFS的支持，作为全网的data center节点，这里data center节点已经不是一个中心化的结构了，区块链为分布式的外源数据库(HBase)提供了安全性的保障.

图3 数据不同存放方式Fig.3 Different storage methods of data

4 高吞吐量多模式可验证查询方法

4.1 多模式可验证应用场景

在溯源的过程中，可验证查询是非常重要的技术，例如生产商、运输商、销售商、用户之间互相不信任.外源数据库不止为整个网络提供吞吐量的支持，还为全网提供多模式可验证查询的支持.区块链本身具有防篡改的特性，利用这个防篡改的特性，可以为用户提供可验证查询，即用户请求查询时，提供查询服务的节点(HBase节点)，在返回查询结果的同时，返回给用户一个可以证明查询结果完整正确的数据结构.

当用户向HBase节点请求查询时，HBase首先通过查询接口将符合条件的数据，根据查询结果的数据的批次，找到同批次的所有数据，将它们按照时间戳重新排列起来，重新计算消息散列值，并从区块链中查询到该批数据未被篡改过的最初的消息摘要值，将新计算的消息散列值与从区块链上拿到的消息散列值进行比对，验证查询结果是否是正确的.

图4 多模式验证查询流程图Fig.4 Multi-schema validation query

根据请求查询的节点对data center节点信任程度不同，可以采用不同模式的验证查询方式，当请求查询的节点对data center信任程度较低时，需要采用代价比较高的全数据验证方式；当请求查询的节点对data center信任程度中等时，可以采用代价相对没有那么高的data center节点代替验证的查询方式；当请求查询的节点对data center的信任程度比较高时，可以采用代价较小的简单验证查询方式.多模式验证查询的流程图见图4.

图5 多模式数据验证Fig.5 Multi-mode verifiable query method

4.2 简单验证查询

当请求查询的节点对HBase节点信任程度较高的时候，验证查询的方式可以采用简单验证查询.

Client节点首先向HBase节点发送查询请求，HBase节点查询到结果和结果的批次信息，通过批次信息在区块链中查询到最初的未被篡改的消息摘要值，将这个消息散列值与在HBase中的消息散列值进行比较，若比较结果是相同的则，说明查询结果没有问题，若比较结果是不同的则说明查询结果有可能是伪造的.简单验证查询示意图见图5.

简单验证查询过程的系统开销主要来自于从区块链中取得到消息摘要值，除此之外简单验证查询的查询效率与传统数据库基本相同，事实上查询效率大部分取决于链下数据库的种类，采用NoSQL或者关系型数据库都可以保证系统的高吞吐量.

4.3 Data Center节点代替验证查询

当请求查询的节点对HBase节点的信任程度中等时，可以采用data center代替验证的查询方式，算法2说明了Data center节点代替验证查询的步骤.

算法2.DC代替验证查询 (DC Validation Query)

输入：查询条件

输出：查询结果和查询结果是否有效(true or false)

客户端Client：

1.function(查询结果，查询结果是否有效) DCVQ(查询条件)：

2. 查询结果，查询结果是否有效=DCVQ_DC(查询条件)

3.if(查询结果有效)

4.return(查询结果，查询结果有效)

5.else

6.return(null，查询结果无效)

数据中心Data center

7.function(查询结果，查询结果是否有效) DCVQ_DC(查询条件)

8. 查询结果=getDB(查询条件)

9. 数据中心中的消息摘要值=计算消息摘要(查询结果)

10. 区块链中的消息摘要值=getBLC(查询条件)

11.if(数据中心中的消息摘要值==区块链中的消息摘要值)

12.return(查询结果，查询结果有效)

13.else

14. return (null，查询结果无效)

算法2的1-6行是请求查询的客户端节点进行的操作，在第2行客户端节点向数据中心节点请求查询结果和结果的真实性.与简单验证查询不同的是从数据中心节点拿到数据块需要重新计算消息摘要值，再与区块链中消息摘要值进行对比返回结果.

当请求查询的节点向HBase节点请求查询时，HBase首先在自身查询出符合条件的数据和批次信息，之后根据批次信息查询出同批次的所有数据，并按照时间戳排序(将同批次数据按照存入HBase时的数据排列即可)，重新计算该批数据的消息摘要值.根据查询结果的区块信息在区块链中查询到该批次数据的最初消息散列值，将重新计算的消息散列值与区块链中的消息散列值进行对比，若比较结果是相同的则说明查询结果没有问题，若比较结果是不同的则说明查询结果有可能是伪造的.Data center节点代替验证查询示意图见图5.

Data Center节点代替验证查询方法开销与简单验证查询相比多了将数据块重新计算消息摘要的过程.由于数据块在磁盘中是按照顺序存放的，读取磁盘开销代价并不是很大，计算消息摘要代价也在级别，所以可以保证系统的高吞吐量.

4.4 全数据验证查询

当请求查询的节点对HBase节点的信任程度较差时，就需要采用全数据验证查询的方法，全数据验证方法的方式是将与查询结果同批次的数据都返回给请求查询的节点，请求查询的节点自己验证数据的真实性，所以全数据查询验证代价开销比较高.算法3说明了全数据查询过程步骤.

HBase节点收到请求查询节点的查询请求后，首先查询到符合条件的结果，根据查询结果的批次信息找到同批次的所有数据，并将这些同批次所有的数据返回给请求查询的client节点.请求查询的client节点还要在区块链中查询到最初存入的未被篡改过的消息摘要值.Client节点通过重新计算批次数据的消息摘要值并与区块链中查询到的消息散列值进行对比，来确定查询结果是否真实可靠.全数据验证查询示意图见图5.

算法3.全数据验证查询 (Full Data Validation Query)

输入：查询条件

输出：查询结果和查询结果是否有效(true or false)

客户端Client：

1.function(查询结果，查询结果是否有效) FDVQ(查询条件)：

2. 查询结果=FDVQ_DC(查询条件)

3. 数据中心中的消息摘要值=计算消息摘要(查询结果)

4. 区块链中的消息摘要值=getBLC(查询条件)

6.return(查询结果，查询结果有效)

7.else

8.return(null，查询结果无效)

数据中心Data Center：

9.function(查询结果)FDVQ_DC(查询条件)：

10. 查询结果=getDB(查询条件)

11.return查询结果

算法3的1-8行是请求查询的客户端节点进行的操作，在第2行客户端节点向数据中心节点请求完整数据块，第3行客户端节点计算消息摘要值，第4行客户端节点向区块链请求消息摘要值，第5-8行进行消息摘要值对比并返回结果.

例如在表2中的数据，在存储过程中被修改，见表4.

表4 第1批次被篡改数据Table 4 First batch of tampered data

某个查询节点想查询数据编号为3的数据：

Query：Select * from Table1 where 数据编号=3;

表5 查询结果Table 5 Query results

无论采用简单验证查询、data center节点代替查询验证查询还是全数据验证查询方式，查询到的结果见表5.

数据中心节点根据被篡改过后的数据计算出消息摘要值为7981c3f689896fb560bc5590b8e8192e，而在区块链中拿到的哈希摘要值为911c6da8a8da020fe625d98553f23383，两者值不同.若采用了data center节点代替验证查询和全数据验证查询的方式，请求查询的用户节点会发现查询结果可能存在问题，而若采用了简单验证查询的方式，则说明请求查询的用户节点对data center节点的信任程度较高且data center较为安全不易被篡改和攻击.

与DataCenter节点代替验证查询不同的是，数据中心节点和区块链需要把数据块和消息摘要值返回给用户节点用户自己进行验证，而验证所带来的开销与DataCenter节点代替验证查询基本是相同的，系统高吞吐量的性能即可得到保证.

5 实验评估

5.1 实验配置

5.1.1 实验环境

实验集群的硬件环境为双核心四线程CPU Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz，内存为16G(2×8192 MB (16G) 1600MHz)，硬盘转速为5400rmp.操作系统版本为Ubuntu18.04，Golang版本为go1.12.6 Linux/amd64，Hyperledger Fabric版本为hyperledger/fabric release-1.3.0.

5.1.2 网络参数

1)单机单节点配置参数

单机单节点是将所有的组件(包括order、peer、client、HBase节点)部署在一台服务器上，节点名称及数量见表6.

表6 单机单节点配置参数Table 6 Configuration parameters of single machine and single node

2) 多机多节点配置参数

多机多节点将每个组件放在不同的计算机上，形成一个集群，所采用的节点配置及数量见表7.

表7 多机多节点配置参数Table 7 Configuration parameters of multi-machine and multi-node

5.2 吞吐量测试

5.2.1 无HBase测试

为了对比试验的方便，对不加HBase只有Fabric的网络进行吞吐量测试.

1)不同存储方式对性能的影响

在Hyperledger Fabric中，数据以key-value形式的文档数据存储，在实验中数据存储采用了两种方式，分别是一对象一个文档和一个历史版本一个文档.一对象一文档指的是每个对象中用数组或者其他数据结构存储历史版本信息.这种结构的数据会将每个对象的历史版本信息存在一个文档内，数据特点：文档数量少，每个文档尺寸大.一个历史版本一文档指的是每个对象的id+时间信息代表一个历史版本的信息.这种结构的数据会将一个对象的每个版本信息都存储为一个文档，数据特点：文档数量多，单个文档尺寸小.

图6 存储方式和索引对性能的影响Fig.6 Influence of index and storge types on query performance

为了测试不同存储方式对性能的影响，本文测试了不同存储方式下的插入效率、修改效率、查询效率.首先测试了插入50000条数据所需要的总时间，如图6(a)所示，实验结果表明一对象一文档插入每条数据所需要的平均时间为0.08s，而一历史版本一文档插入每条数据所需要的平均时间为0.10s；本文还测试了不同存储方式下的修改性能，实验方法是随机对数据库中的数据进行修改50000次，实验结果表明一对象一文档每次修改的平均时间为0.08s，一历史版本一文档的每次修改的平均时间为0.11s；在测试查询效率的过程中，分为简单查询测试和范围查询测试，简单查询测试是指按照HBase中的列名进行查询，范围查询测试是指查询的属性是一个数值范围，在实验中，一对象一文档在简单查询测试中每次需要0.07s的时间，一历史版本一文档在范围查询测试中每次需要0.09s.

2)索引对查询性能的影响

CouchDB支持对数据进行构建索引，在一对象一文档的情况下，本文测试了索引对范围查询效率的影响，如图6(b)所示，实验结果表明有索引的查询效率要比无索引的查询效率高.

5.2.2 多机多节点外源数据库测试

实验所采用的数据是索非亚空气质量数据集(6)https：//www.kaggle.com/hmavrodiev/sofia-air-quality-dataset，是传感器类型的时间序列数据.

将HBase节点加入整个集群中，其中数据再HBase中的存储结构见表8.

1)单节点与多节点性能测试

在实际应用的场景中，往往都是分布式、并行的结构，本文将单节点和多节点的性能进行了实验对比.首先测试了插入17709数据，分别统计了链下数据库(HBase)和区块链的性能表现，同时测试了与验证相关的操作性能表现，分别是每批次平均插入所需要的时间(每批次默认200条数据)和平均每次验证查询所需要的时间.其中每一批次的数据插入过程中涉及到验证的环节是批次数据需要进行计算消息摘要值，验证查询中涉及到验证的环节就是将查询结果同批次的数据重新计算消息摘要值.

表8 HBase存储结构Table 8 HBase storage structure

如图8(a)所示，实验结果表明，链下数据库的效率是很高的，而且与无链下数据库相比，系统的吞吐量也有明显的提升.在单节点和多节点验证相关的测试中，多节点的表现较单节点相比有一点提升.

图7 链下数据库与区块链资源占比分析Fig.7 Analysis of resource of off-chain database and block chain

如图7所示了每次插入数据HBase和区块链所占用的时间，不论是单节点还是多节点，HBase所占用的时间远远没有区块链占用的时间多.

2)多节点吞吐量及并发性实验

实验中有3个组织并且在一个通道内，其中有两个组织在并发的插入数据或者进行验证查询.

如图8(b)所示，实验结果表明，多节点并行时的HBase与区块链相比依然在执行时占用了较少的时间.在验证相关的测试中，每个节点的每批次数据平均插入时间大概在1.3s左右，平均每次的验证查询时间在1.45s左右.

在加入HBase外源数据库后，整个架构的系统吞吐能力有很大的提升，插入数据系统吞吐量由每秒2个变为每秒75个左右，验证查询也有着不错的效果.

图8 单节点多节点测试对比Fig.8 Comparison of single node and multi-node

5.3 链下数据库与区块链性能对比

为了说明区块链加链下数据库的架构的性能优势，将区块链和链下数据库性能进行了对比试验，如图9所示.

图9 链下数据库与区块链TPS对比Fig.9 Compare of off-chain database and block chain

实验表明，当只使用HyperledgerFabric时，系统每秒处理事务数量仅为3左右，当加入HBase以后，架构的系统每秒处理事务数量有了很大的提升，在75个左右.而只使用HBase的系统每秒处理事务数量在85个左右.该实验说明区块链加链下数据库的架构，在保证了安全性的同时，也有不错的系统吞吐量性能.

6 结 论

本文提出了一种区块链结合线下数据库的模式，采用该模式能让区块链网络具有较强的事务吞吐能力，链下数据库还为整个区块链网络提供查询、存储服务.在这个模式的基础上，本文提出了一种多模式可验证查询和异步可验证查询的方法，根据节点之家信任程度的不同，提供不同代价花费的验证查询方式.通过Hyperledger Fabric平台和HBase构建了一个外源数据库区块链平台，并进行了实验，实验结果表明该模式使得区块链网络具有更高的事务吞吐能力和验证查询能力.

接下来的工作要将链下数据库与区块链能够更好的结合，到目前为止链下数据库还是独立于区块链的存在，并不是区块链的一部分，以Hbase为例子，将ledgerDB换为Hbase这样的更加高效的、查询更加强大的数据库，通过Hbase维护Merkle Tree这样的数据结构，让外源数据库成为区块链的一个内部组件；节点之间的关系管理方面：目前为止节点之间的信任模型还不完善，可以尝试引入图的概念，建立节点网络，量化节点之间的信任关系.