基于区块链的数据完整性多方高效审计机制

周家顺，王娜，杜学绘

（信息工程大学，河南 郑州 450001）

1 引言

大数据技术高速发展，并深入人们的生活。政务大数据[1]、司法大数据[2]、医疗大数据[3]等大数据技术正在逐渐为社会的进步提供有力的数据技术支撑。但是大数据具有与传统数据不同的特点，需要使用适合大数据特点的技术进行处理。

大数据最显著的特点就是数据量大，据Statista公司预测2025年的全球数据量将达到175 ZB。数据量的激增促使相应的存储技术的发展，本地存储、分布式存储、云存储等存储技术为大数据存储提供了技术支撑。为保证大数据存储的安全，需要进行数据完整性验证[4]判断数据是否被篡改或者损坏。

数据完整性验证技术一般通过挑战应答机制实现数据完整性的判断。数据拥有者将数据存储于数据存储系统中，在数据进行存储之前利用BLS签名等技术实现存储数据的签名，并生成证明元数据。数据拥有者从证明元数据中选取相应的数据生成挑战，并将挑战发送给数据存储系统。数据存储系统依据收到的挑战，利用存储的数据生成相应的数据完整性的证据。数据完整性审计机构对数据存储系统生成的证据进行判断，确定数据是否与原始数据一致。

对于大数据进行数据完整性审计需要充分考虑大数据的特点。

1) 大数据数据量大的特点要求数据完整性验证技术能够满足审计的效率要求，实现数据完整性的高效判决。

2) 由于大数据的来源广泛，大数据的数据类型变得多样，数据可以分为结构化、半结构化和非结构化3种类型[5]。例如，政务大数据中的数据类型可以分为4类：业务数据、民意社情数据、环境数据和分散性公共数据[6]。大数据环境下的数据主要为非结构化数据，据IDC统计显示，大数据中非结构化数据占比80%，非结构化数据完整性验证成为大数据完整性验证的关键。

3) 同时，信息化时代，数据成为越来越重要的资源。通过共享大数据来打破数据孤岛，成为信息企业面临的重要挑战。数据共享不仅需要实现数据交换，也要保证数据的真实性。例如，对于政务大数据、司法大数据和医疗大数据这些较为敏感的数据，数据真实性的重要程度表现极为突出。

大数据的完整性验证不仅需要向数据拥有者提供数据未被篡改或者未被破坏的证明，对于共享数据的使用者同样需要进行证明。

中本聪发表文章Bitcoin: a peer to peer electronic cash system[7]，标志着区块链技术的诞生。从此之后，区块链技术以其去中心化，不易篡改等良好特性吸引大批学者研究。数据的完整性验证技术实际上是对于数据存储者等多方信用的验证，将区块链技术与数据完整性验证技术结合能够发挥数据完整性验证体系更大的价值。

基于此，本文提出基于区块链的数据完整性多方高效审计机制（MBE-ADI），解决大数据环境下数据完整性的审计问题，主要贡献如下。

1) 提出大数据环境中数据域的概念并构建基于数据域的混合Merkle DAG结构，实现对非结构化数据的管理，借助此结构实现证明元数据的生成，解决大数据环境下大量非结构化数据同时验证的问题。

2) 设计基于BLS签名多副本确定性验证方法，实现数据完整性的多副本同时确定性验证，满足大数据环境下数据完整性高效验证的需求。

3) 设计基于联盟链的双验证审计架构，相应智能合约以及验证过程元数据上传方法，实现数据完整性去中心化自动审计以及审计历史可信追溯，同时为数据拥有者和数据使用者提供数据完整性验证服务，保证数据进行共享之前的历史一致性，提高数据的可信度。

4) 基于阿里云服务器进行MBE-ADI系统部署并进行相关测试，验证系统的可行性以及数据完整性审计的高效性。

2 研究现状

Deswarte等[8]提出基于MAC码的完整性验证机制，该机制将MAC值作为认证元数据实现数据的完整性验证，但存在通信开销大且容易泄露隐私的问题。Ateniese等[9]提出数据持有性证明（PDP，provable data possession）机制，将数据分块并使用RSA签名机制进行抽样检测数据块的完整性，提高了检测效率，减少了通信开销。Wang等[10]提出支持全同态操作的PDP机制，该机制使用Merkle树验证数据块位置的正确性，采用BLS签名对数据块的完整性进行验证。谢四江等[11]提出使用多分支路径树MBT进行完整性验证的机制，该机制增加了节点的出度，相较于基于Merkle树的完整性验证机制能够验证更大规模的数据，且利用MBT的结构能够较好地实现数据块替换等动态操作。

多副本机制能够提高数据的抗风险能力，即时使用多副本对损坏数据进行修复，对于重要的数据，多副本机制重要性更为突出。刘洪宇等[12]提出支持动态操作的多副本验证机制，该机制对Merkle树结构进行改造，提出基于等级的Merkle树，实现对动态验证的支持。该机制通过对多个副本进行关联，实现多副本的同步更新。Curtmola等[13]通过随机掩码技术实现多副本数据的生成，为任意数量的副本使用恒定数量的元数据，可以动态创建新副本而无须再次预处理数据，且多副本完整性验证的时间和单副本数据的验证时间接近。但是多副本机制存在生成的随机数等元数据过多、处理大数据量的文件时会出现元数据管理负担过重的问题，不适合数据量大且包含大量非结构化数据的大数据环境。

以上的数据完整性验证的审计主要使用可信第三方机构，但可信第三方机构寻找困难，容易发生第三方攻击的问题。应用区块链技术进行数据的完整性验证成为新的选择[14-21]。

Liu等[18]采用区块链智能合约取代第三方审计机构，并认为在共享数据之前，数据使用者应该对数据的完整性进行验证。为了实现公平的完整性审计，Zhao等[19]考虑使用区块链技术进行数据完整性的验证。数据拥有者将数据块的签名上传到区块链账本，将加密后的数据上传到云上，验证的时候对数据进行下载，利用区块链账本记录的数字签名对数据的完整性进行验证。Wei等[20]通过虚拟代理机制实现基于区块链的数据完整性验证，并结合基于角色的访问控制技术对存储的数据进行管控。魏艳等[21]提出基于以太坊[22]的数据完整性验证机制，该机制在智能合约中存储数据的哈希值以及数据签名等信息，在进行数据完整性验证的时候，将现有数据的哈希与智能合约中存储的哈希进行对比实现验证。目前基于区块链的数据完整性验证机制没有考虑数据使用者获取共享数据真实性的需求，仅对数据拥有者提供服务。

目前有学者注意到对于大数据进行完整性验证的问题。Chang等[23]对外包大数据完整性验证技术进行了总结，但与谭霜等[4]提出的技术基本一致，未体现大数据完整性验证的特点。Chen等[24]实现数据块的细粒度更新，采用平衡更新树作为ADS（authenticated data structure）来减少动态更新后的更新验证，从而减少计算和通信资源。Nasonov等[25]提出基于区块链实现数据交易完整性的分布式大数据平台，重点设计完整性管理器模块，确保数据的真实性与一致性。Lebdaoui等[26]考虑到大数据来源广泛以及大数据数据量大的特点，并提出数据输入验证模型实现对数据来源的验证，提出连续完整性监测模型实现数据在使用过程中的完整性验证，但仅提出了模型的框架。

综上分析可得，目前仍需要对适合大数据环境的数据完整性验证机制进行研究，对大数据环境下数据量大、包含大量非结构化数据和倾向共享等特点进行充分考虑。

3 基于数据域的混合Merkle DAG结构

由于大数据环境中的数据来源广泛，且大多为结构不一的非结构化数据（例如，数据拥有者获得的一组数据中可能同时包含图像、视频、文档等），实现对这些非结构化数据的有效组织是进行高效验证的前提。本节针对大数据环境数据中的特点，为实现对数据的有效管理，并在此基础上生成数据完整性审计的证明元数据，提出基于数据域的混合Merkle DAG结构。在数据域层面，使用Merkle DAG结构构造非结构化数据间的组织关系；在数据块层面，对单个数据的数据分块构造多分支平衡Merkle树。

本节提出数据域的概念，借助此概念实现对非结构化数据进行组织。这里的域是指对一类关联的数据或者子数据域的包含。对于一批需要进行存储的数据，数据拥有者根据数据的内在联系，（如数据的来源、获取日期、类别等）关系，对数据进行划分，将一类数据归置于一个域中。从而获得一个包含所有数据和子数据域的最大域。

在该存储结构中使用Merkle DAG。在Merkle树的基础上构建Merkle DAG，打破了Merkle树的子节点个数的限制，无须进行数据的平衡操作，能够根据实际的需要构建更为灵活的数据结构。Merkle DAG保留Merkle树循环计算节点哈希获得Merkle Root的特点，父节点的哈希值由子节点的哈希值决定，同时父节点包含指向子节点的信息。在IPFS[27]中将Merkle DAG作为数据的存储结构，现实分布式文件存储网络。

构建基于数据域的混合Merkle DAG结构的过程如下：

1) 根据非结构化数据的包含与并列关系，构建包含所有数据的Merkle DAG文件结构；

2) 对域内的每条数据构建多分支平衡Merkle树结构，获取Merkle DAG节点信息中的nodeid。

3.1 构建基于数据域的Merkle DAG文件结构

针对非结构化数据构建数据域，相关联的数据放在一个域内，数据域中包含子数据域，各级数据域表示数据不同的关联程度，域中同时存放相关联的多条数据，并规定域内至少包含两个数据文件。如图1所示，数据域为 {A,A1,A2}。A域包含 {A1,A2,d7,d8,d9}。A1域包含 {d1,d2}。A2域包含 {d3,d4,d5,d6}。

图1 数据域结构Figure 1 Data field structure

基于数据域的混合Merkle DAG结构包含域节点和数据节点两种节点。为每个域构建域节点标识该域，域节点如图2所示， nodeid为该域节点的唯一标识信息，能够使用 nodeid区分节点；Lr为右指针，指向同级域中的其他节点；{Id1, Id2,… ,Idi}为子指针，指向数据节点或者子数据域节点。

图2 基于数据域的Merkle DAG结构域节点信息Figure 2 Domain-based Merkle DAG structure domain node information

在基于数据域的混合Merkle DAG结构中，每个非结构化数据由一个数据节点标识，数据节点如图3所示， nodeid为该数据节点的唯一标识信息，能够使用 nodeid区分数据节点；Lr为右指针，指向同级域中的数据节点。对图1的数据域可以构建图4所示的Merkle DAG文件结构。

图3 基于数据域的Merkle DAG结构化数据节点信息Figure 3 Domain-based Merkle DAG structure data node information

图4 基于数据域的Merkle DAG文件结构Figure 4 Merkle DAG file structure based on data domain

3.2 获取Merkle DAG节点 nodeid信息

构建基于数据域的Merkle DAG文件结构之后，需要获取各个域节点或者数据节点中的nodeid。本文通过对非结构化数据构建多分支Merkle树结构获取标识不同节点的 nodeid。设非叶子节点最大的子节点的个数为Nmax；数据块分割大小恒定为D。

构建多分支Merkle树结构流程如下：

1) 数据分片。依据数据块的分片大小对数据文件进行分片，分片之后剩余不足分片大小的数据充当最后一个数据块。设将文件Df分成了n块，则Df可以表示为Df= {m1,m2,… ,mn}。

2) 计算多分支平衡Merkle树第一层节点哈希。对数据块 {m1,m2,…,mn}分别计算哈希，获得多分支平衡Merkle树第一层（i为1）哈希{h(m1),h(m2),…,h(mn)}。

3) 对哈希节点分组。依据Nmax对平衡Merkle树的第i层哈希层进行分组，每组的个数为Nmax。如果最后一组的个数不足Nmax，则将剩余的数据哈希归为一组。

4) 计算i+1层哈希。对各组进行i+1层哈希节点的计算：hh=h(h1||h2||… ||hNmax)，hh表示i+1层节点，{h1,h2,…,hNmax}表示i层某组节点，各组获得的哈希节点组成平衡Merkle树第i+1层哈希节点。

5) 循环计算获得新的哈希层。对步骤3)和步骤4)进行循环，直到某层哈希节点的个数为1，将该哈希节点作为该条数据的Merkle Root，计为nodedi。

Nmax取3，数据d1可以构建如图5所示的多分支平衡Merkle树结构。该结构能够满足大数据量的表示。设非叶子节点的最大子节点的个数为Nmax，数据块分割大小为D，设哈希层数为k，则该结构可以表示的数据量为Nmaxk-1∙D。当Nmax取27，D取24 MB，k取4，则表示的数据量为461 GB。

图5 数据d1的多分支平衡Merkle树结构Figure 5 Multi-branch balanced Merkle tree structure of data 1d

获得数据nodedi之后，利用域中的各个数据节点的 nodeid计算数据域节点的 nodeid。例如，nodeA1表示为h(noded1||noded2)。获得域节点和数据节点的 nodeid信息之后，便可获得完整的基于数据域的混合Merkle DAG结构。完整的基于数据域的混合Merkle DAG结构如图6所示。

图6 完整的基于数据域的混合Merkle DAG结构Figure 6 Integrate hybrid Merkle DAG structure based on data domain

当数据域中的非结构化数据的数据量小于构建多分支Merkle树的分片大小时，非结构化数据不经过分片直接计算数据的哈希， nodeid=h(d)。图7表示非结构化数据较小时，基于数据域的混合Merkle DAG结构，其构造简单，能够对数据个数多但数据量小的非结构化数据进行有效组织，并有利于在此基础上生成完整性审计的证明元数据。

图7 数据较小时，基于数据域的混合Merkle DAG结构Figure 7 Hybrid Merkle DAG structure based on data domain for small data

4 方案设计

4.1 MBE-ADI系统

本文考虑为某类数据相关的各方建立联盟链系统。数据拥有者、数据使用者与数据存储系统均会加入区块链系统并且成为区块链系统中的节点。基于联盟链的双验证审计架构如图8所示，DO表示数据拥有者，DU表示数据使用者，SP表示数据存储系统。

图8 基于联盟链的双验证审计架构Figure 8 Dual verification audit architecture based on consortium blockchain

各个参与方在系统中包含链下基础设施部分和链上区块链节点部分。链下基础设施包含存储设施和计算设施，完成审计流程主要的存储和计算任务。系统中通过区块链网络连接参与的各个节点，完整性审计的流程通过区块链的元数据上传合约、完整性判决合约和审计历史索引合约实现，审计过程的关键数据通过区块链账本进行记录。

在本文方案中，区块链部分通过Hyperledger Fabric平台实现。Hyperledger Fabric是由Linux基金会牵头研发的面向企业应用的联盟链平台[28]。Hyperledger Fabric中的账本分为世界状态和区块链两部分。世界状态以键值对的方式存储账本状态的当前值，相较于遍历整个交易日志能够获得更快的访问速度。区块链是交易日志，它记录了区块链账本的完整数据，世界状态的改变由这些交易日志决定。当链上数据的键唯一的时候，世界状态的值就不会被改变，能够稳定记录数据的键值对。

对某个数据域的完整性审计的所有历史记录会在区块链账本上保存，通过检索并审查审计历史实现对数据域历史可信度的增强。为保证对数据完整性审计历史检索的速度，本文对状态数据库进行检索。为实现多类型索引查询操作，状态数据库采用CouchDB数据库。各个流程相关信息以JSON格式进行存储，存储的数据可以表示为：

ObjectType标识数据类型，分为data_up、challenge、prove、audit，分别代表上链数据、挑战数据、证明数据、审计数据。时间戳Timestamp作为该条状态数据的唯一标识，由区块链智能合约自动生成。Node_block为需要进行数据完整性审计的数据域df节点标识，对于审计数据域，构建基于数据域的混合Merkle DAG结构，获得Node_block= nodedf。data1和data2为其他信息，由不同的数据类型决定。

本文的完整性验证方案通过BLS签名实现。BLS[29]为数字签名算法，其签名长度较RSA和DSA签名方案更短。

DH四元组定义:G为阶为素数q的循环群，D=(g1,g2,u1,u2)∊G4为四元组，其中g1、g2为G的生成元，。判断α=β是否成立，如果成立，则称D为DH四元组。

设G为间隙群，g为G的生成元，H:{0,1}*→G为全域哈希函数。随机整数x为私钥，y=gx为公钥。M∊{ 0,1}*为待签名的消息，h=H(M)，则σ=h x∊G为消息M的签名。如果四元组(g,h,y,σ)为DH四元组，则签名判断为True，否则签名判断为False。

4.2 基于BLS签名多副本确定性验证方法

4.2.1初始化阶段

对于数据的加密，本文选用AES对称加密。该阶段生成数据加密所需的AES加密密钥以及BLS签名所需的公钥和私钥。该阶段在每个数据拥有者链下计算设施中分别进行。

设需要产生μ个数据域副本，生成μ个AES加密密钥 {K1,K2,… ,Kμ}，密钥长度为kbit。g为生成元，随机选择令x为数据拥有者DO的BLS签名私钥，数据拥有者DO的BLS签名公钥y满足y=gx。启动区块链网络，在区块链各个节点部署智能合约。

4.2.2证明元数据生成阶段

数据拥有者使用AES加密密钥 {K1,K2,…,Kμ}分别对数据域df中每个数据进行加密，获得μ个数据域副本 {df1,df2,… ,dfμ}。为实现对多个副本完整性的同时验证，对多副本拼接获得复合数据域DF，对DF进行数据完整性验证实现对多副本的同时验证。获得数据域证明元数据流程如下。

1) 获取复合数据域DF。获取复合数据域需要对数据域中的数据进行逐个复合，以实现对多副本数据完整性的同时验证。设原始数据域中的某个数据为d，数据域副本的个数为3，则数据d有3个数据副本 {d1,d2,d3}，数据副本被划分成n个数据 块，表 示为j∊ (1,2,3)。数据拥有者确定生成证明元数据数量为k，并使用伪随机数发生器生成k个随机序列：L= {l1,l2,…,lk}，并为每个随机序列生成一个随机序列拼接策略S= {s1,s2,… ,sk}。设随机序列li对应的拼接策略是si：{md1||li||md2||md3}，其中md1、md2、md3分别表示数据副本d1、d2、d3的数据块，不同的拼接策略规定随机序列插入的位置不同。则数据d的复合数据D可以表示为为复合数据D的各个数据块的集合。逐个获得数据域df中非结构化数据的复合数据。

2) 利用获得的复合数据获得df的复合数据域DF，并构建基于数据域的混合Merkle DAG结构，获得复合数据域DF节点信息 nodeDF。图9为获取 nodeDF示意。

图9 获取证明元数据Figure 9 Obtain proof metadata

3) 计算h=H(nodeDF)，使用私钥x对h进行BLS签名，σi=hx，则数据域df的证明元数据可以表示为 {nodedf,li,si,σi,y}。

4.2.3数据副本存储阶段

数据存储系统通过安全通道接收数据拥有者需要存储的数据域副本 {df1,df2,… ,dfμ}，并通过签名机制生成数据存储凭证storage_credentials。

在该阶段，数据拥有者上传上链数据，docType取data_up，data1取数据名称data_name，data2取数据存储凭证storage_credentials。

4.2.4挑战阶段

在该阶段，数据拥有者确定进行挑战的数据域df，选取df对应的证明元数据为挑战数据{nodedf,l i,si,σi,y}，docType取challenge，data1取挑战数据，data2取数据存储凭证storage_credentials。

4.2.5证据生成阶段

数据存储系统作为区块链节点，在线监听数据拥有者对自己的挑战，获取挑战元数据{nodedf,l i,si,σi,y}，依据 nodedf，从存储数据库中获取数据域的副本 {df1,df2,…, dfμ}，依据随机序列li和拼接策略si获得复合数据域DF′，对复合数据域DF构建基于数据域的混合Merkle DAG结构获得证据Ki=H(nodeDF')。

在该阶段，存储系统上传证明数据，docType取prove，data1取证据Ki，data2取对应的挑战时间戳challenge_timestamp。

4.2.6完整性判决阶段

完整性判决合约获得挑战元数据{nodedf,li,si,σi,y}和证据Ki，并判断(g,K i,y,σi)是否为DH四元组，如果是，则判断数据完整，audit_results=True；如果不是，则判断数据不完整，audit_results=False。

在该阶段，数据完整性判决合约上传审计数据，docType取audit，data1取审计结果audit_results，data2取对应的证据时间戳prove_ timestamp。

4.3 数据完整性审计历史可信追溯

为实现对审计历史的高效检索，创建索引文件并与本文使用的智能合约一起安装到区块链系统节点。索引文件内容如下：

上述索引文件创建了两个索引，索引1依据Node_block进行索引，能够索引与某个数据域相关的所有信息，包括上链数据、挑战数据、证明数据、审计数据；索引2依据docType和Node_block进行索引，能够分别索引某个数据域的上链数据、挑战数据、证明数据、审计数据信息。

5 方案分析

5.1 安全性分析

5.1.1验证流程安全性

完整性验证流程概括为数据副本生成、证明元数据生成、证据生成、证据审计4个阶段。非结构化数据通过基于数据域的Merkle DAG文件结构进行组织，节点信息中的 nodedf保证节点的唯一性，节点信息中指针信息保证Merkle DAG文件结构确定，数据在数据存储系统SP中以确定的方式进行存储。副本生成机制保证数据损坏能够即时修复。数据副本生成阶段，通过设置μ个不同的AES密钥 {K1,K2,… ,Kμ}对数据加密实现副本生成，防止存储系统进行数据多副本伪存储。该副本生成机制，能够减少副本参数存储，防止海量参数丢失与损坏。在证明元数据生成阶段，使用随机序列拼接方式组合获得复合数据域nodeDF，对 nodeDF进行签名获得证明元数据{nodedf,l i,si,σi,y}。在证据生成阶段，存储系统同样使用随机序列拼接方式获得复合数据域nodeDF'，该方式能够保证元数据生成必须使用完整副本数据块，保证完整性审计的可行性。在证据验证阶段通过检验(g,K i,y,σi)是否为DH四元组，判断数据是否遭到破坏，保证校验结果的可信度。

5.1.2区块链账本记录可信度

本文的完整性验证流程通过智能合约实现，验证的相关数据记录在区块链账本上。智能合约取代可信第三方对证据的审计，这样能够解决防止第三方对验证流程进行攻击的问题。区块链账本能够实现账本数据的安全可信多方存储，验证流程数据记录在区块链账本上，防止各方对验证流程的篡改，保证数据完整性验证历史的真实性。在区块链账本上记录数据在区块链账本上的唯一标识Node_block，唯一标识的确定能够保证数据存储与完整性验证的一致性，实现对某一数据完整性验证历史的检索。通过数据完整性验证历史的检索，能够保证数据在进行共享之前的历史一致性，保证数据的可信度。

5.2 方案对比

表1 为本文方案与现有方案的对比。本文方案包含多个数据拥有者与数据使用者，以及多个数据存储系统，能够实现同领域数据或者联盟成员间数据的多方审计。本文方案选用智能合约作为系统审计机构，能够避免寻找可信第三方。与抽样验证相比，基于数据域的混合Merkle DAG结构能够实现多副本数据的确定性验证，提高数据完整性审计的效率与准确度。同时，本文方案设计数据完整性审计历史高效检索机制，实现数据完整性验证历史高效检索以及多方验证，保证数据历史的一致性，增强数据的可信度。本文方案没有实现数据的动态修改，降低了数据存储的灵活性，但可以增加数据的历史一致性，适合本文探讨的倾向数据共享的场景。

表1 方案对比Table 1 Scheme comparison

6 系统测试

本文实验部署6台阿里云服务器，其功能标识如表2所示。云服务器配置Intel Xeon Platinum 8269CY @2.5GHz处理器，256 GB内存，Ubuntu 16.04 64位操作系统。通过Java实现CBC模式128 bit密钥AES加密。证明元数据生成阶段使用go语言编程实现，并利用go语言的并发机制加快计算速度，使用SHA256算法进行数据摘要提取。BLS签名验证的部分通过Java的JPBC库实现。区块链部分基于Hyperledger Fabric 2.2实现。区块链系统的背书策略为：将智能合约安装在6台服务器中的peer节点上，在进行区块链交易时，6台服务器中的peer节点均进行交易背书。

表2 云服务器功能Table 2 Cloud server function

证明元数据生成过程与证据生成过程相似，在本文的测试中，对证明元数据生成效率进行测试。为验证系统对大数据环境中广泛存在的小数据量数据进行完整性验证的效率，测试了包含大量小数据的数据域生成证明元数据的速度。并进行证据校验效率测试。

6.1 证明元数据生成效率测试

对数据量为1～10 GB的数据进行证明元数据生成效率的测试如图10所示。在该测试中，数据副本的数量为3，多分支Merkle树结构中参数Nmax取27，分别构建数据块大小为16 MB、24 MB、32 MB的基于数据域的混合Merkle DAG结构。图11所示的是对1 GB以内数据进行证明元数据生成效率的测试。数据副本的数量为3，多分支Merkle树结构中参数Nmax取27，分别构建数据块大小为1 MB、4 MB、8 MB的基于数据域的混合Merkle DAG结构。

图10 1～10 GB证明元数据的生成测试Figure 10 1～10 GB proof metadata generation test

图11 1 GB以内证明元数据的生成测试Figure 11 Data within 1 GB to prove metadata generation test

通过两组曲线可以看出，相同的数据量使用不同大小的分块进行处理，耗时基本相同。在实际的应用中，数据分块大小可以根据数据量的大小以及实际的需求进行确定。证明元数据生成的时间与数据量成正比，耗时与数据量的比例关系约为1.25 s/GB，数据处理效率较高。

图12 所示的是对1 000～10 000条非结构小数据进行证明元数据生成效率的测试。非结构化数据大小为1 MB左右，数据副本的数量为3，多分支Merkle树结构中参数取27，构建数据块大小为1 MB的基于数据域的Merkle DAG文件结构。从获得的曲线可以看出证明元数据生成的速度与数据条数成正比，约为870 条/秒，数据处理效率较高。

图12 非结构化小数据证明元数据生成测试Figure 12 Unstructured small data proof metadata generation test

6.2 证据校验效率测试

图13 为对数据量1～10 GB的数据进行证据真实性校验的效率测试。图14为对数据量100～900 MB的数据进行证据真实性的效率测试。由结果可知，完整性证据的耗时与数据量的大小无关，证据真实性校验的时间约为40 ms，能够实现对证据真实性的快速校验。

图13 1～10 GB数据证据校验测试Figure 13 1～10 GB data evidence verification test

图14 1 GB以内数据证据校验测试Figure 14 Data proof verification test within 1 GB

6.3 性能分析

从实验的结果可以看出数据完整性证明元数据生成以及完整性审计的速度都较高，能够满足数据异构以及数据量大的要求。需要说明的是，以上的测试均是在3个数据副本的基础上进行的，测试消耗的时间是对3个数据副本同时进行数据完整性证明所用的时间。如果减少副本的数量，则将成比例减少时间消耗。在实际使用中，数据拥有者可以根据数据的重要程度选取合适的数据副本数或者不使用副本技术。

7 结束语

本文针对大数据环境下数据特点构建基于区块链的数据完整性多方高效审计机制，实现非结构化小数据以及大体积数据的高效多副本审计。通过智能合约实现数据完整性审计过程，对审计历史追溯实现对审计过程多方监督，保证数据共享之前的历史一致性，增加数据可信度。但是本文方案证明元数据的生成需要在生成随机序列的基础上实现，下一步计划研究更灵活的证明元数据生成方式。