基于智能合约的细粒度数据交易计量验证方法

唐经纬，王玲芳，李杨

（1.中国科学院大学，北京 100049；2.中国科学院声学研究所国家网络新媒体工程技术研究中心，北京 100190）

在大数据时代，单一数据价值有限，数据不断地被收集分析，才能用于引领科技创新和经济增长[1]。数据流通交易是释放数据价值的有效途径，也是不可避免的趋势和需求[2]，现已有大量中心化数据交易平台出现，但存在隐私和安全等问题。信息中心网络是一种以数据信息为中心的网络架构，包括NDN、MobilityFirst、SEANet[3]等项目，其分布式的数据交付模式可解决中心式数据交易如单点故障的部分问题，但此模式又给数据服务的计量提出了新的需求，且存在分布式场景下的安全与隐私问题[4]。

随着区块链技术不断发展，各行业都在探索与区块链的结合应用[5-6]，引入区块链能一定程度解决第三方服务的不可信问题[2]。针对分布式场景下的数据交易，文中提出一种基于区块链上Merkle 树的细粒度数据交易计量及验证方法，并通过在以太坊私有链上的部署实现验证。

1 相关研究

1.1 数据交易平台

现有的数据交易平台主要可以分为集中式和分布式两类[7]。

集中式数据交易平台主要由互联网企业以及政府两类组织机构运营，集中式数据交易模式又可分为托管模式和聚合模式[7]。托管模式数据所有方将数据上传至第三方数据交易中心托管数据，所有者对数据的后续使用与交易可能失去控制。聚合式数据所有方各自保存和管理自身数据，一定程度解决托管式失去对数据控制的问题，但是聚合平台有能力在数据流经平台时，获取并留存数据[8]。此外集中模式均存在单点故障问题。

分布式平台主要结合区块链，建立一个无第三方的数据交易平台，交易链上记录，避免单点故障，各方用户通过链上记录达成协商，直接发起交易。文献[9]设计了一种基于区块链的自动数据交易框架，数据加密上传，但需用户主动上传数据到中心式的存储服务器。文献[4,10]构建基于区块链的计算任务市场架构以及文献[11]提出的数据交易解决方案，均将数据在链下分布式存储，无第三方保存数据副本的问题。但两个方案需要在链下非匿名通信协商交易。

1.2 区块链技术

区块链是一种分布式数字账本系统，将数据区块按照时间顺序组合成链式结构，由去中心化系统中各节点共享和维护[12]。区块链凭借不可篡改性以及可追溯性，使得其在数据资产交易领域有所应用，区块链可以构建数据资产交易的索引，帮助数据溯源确权。以太坊区块链首次引入智能合约[13]，为区块链提供更多数字货币外的应用场景[6]。区块链常用共识算法有工作量证明（Proof of Work，PoW）、权益证明（Proof of Stake，PoS）等[14]。

1.3 数据存储技术

区块链的数据存储根据存储位置分为链上存储和链下存储。

在区块链上进行大量数据的存储是不可接受的[15]，在区块链存储数据会导致所有节点均存储副本，在节点数众多时开销巨大，以太坊通过燃气费设计来限制用户的存储和计算。

常见与区块链结合的存储方式是基于分布式存储的链下存储方案，指将数据的哈希值或链下存储的索引存于链上，如星际文件系统（Inter Planetary File System，IPFS）[16]。结合IPFS 进行数据存储时在链上存储数据的索引哈希值，能够保证数据到链下查询获取并验证是否篡改。

2 方法设计

文中提出一种区块链上智能合约中基于Merkle树的数据块细粒度数据交易及验证方法，结合IPFS存储，提供数据交易、数据获取过程中细粒度计量和验证。该方法可以在链上无需信任地完成密钥交付，在数据获取过程多次进行结算，基于Merkle 树的验证方法也提供了不同大小数据交易的伸缩能力。

2.1 数据存储

链上存储采用基于智能合约的存储。在以太坊虚拟机（Ethereum Virtual Machine，EVM）的智能合约中，计算与存储均需要以gas 为单位的执行开销支付费用，为限制用户向链上大量存储，设置了每32 B 的链上数据存储开销为20 000 gas，作为对比加法操作开销为3 gas，乘法操作为5。因此链上数据通常只存储账户状态数据、交易数据以及智能合约数据，保证账本的可观察性、可验证性及智能合约的可执行性。

链下存储采用IPFS。IPFS 将文件存储为默克尔有向无环图（Merkle Directed Acyclic Graph，Merkle-DAG），文件被拆分为拥有独自的哈希指纹作为标识的数据块，标识称为内容标识符（Content Identifier，CID）用于访问数据块或文件，数据块再通过链接节点呈树结构排列连接[17]。每一个数据块将被赋予CID，以Merkle-DAG 的形式分块存储，分块均拥有独立CID，并作为索引构建有向无环图，链接分块需要增加链接块从而能够将分块恢复数据文件，链接块同样将拥有独立CID。在该方案中需要利用此特性，因此存储数据时DO 需要提取原始数据（Original Data，OD）的CID 用于后续加密传输。而数据在IPFS存储时各数据块均为数据密文（Encrypted Data，ED）。

2.2 数据加密

由于非对称加密和对称加密的性能差距显著，对称加密适用于加密大文件，采用非对称加密和对称加密两阶段的方式，IPFS 数据采用AES 对称加密处理，对称密钥SKAES进行非对称加密处理。

对称加密阶段，将需要上传到IPFS 的文件进行AES 的ECB 模式加密，数据切割成分组长度相等的块，各块独立加密[18]，在IPFS 按数据块获取后也能够单独解密，不需要其他数据块就能正确得到块的明文。使用IPFS 存储的默认数据块大小为256 kB，在进行AES 加密时能够在不进行填充的情况下加密，密文数据块与明文数据块的占用存储空间相同。最末尾数据块可能存在未存满情况，仅需根据AES 加密需求进行少量填充。而CID 作为获取数据的索引，在链上同样需要进行加密，得到多个CID密文Enc(CID,SKAES)，CID 密文数量为需要上链的数据量。

非对称加密阶段，DO 监听数据请求者(Data User，DU)向链上发起的交易请求，请求发生时DO 能够获得DU 的公钥PKDU，则使用PKDU加密AES 对称密钥SKAES得到密钥密文Enc(SKAES,PKDU)然后上链，从而保证密钥传输的安全。DU 监听到DO 的上链日志，则用自己的以太坊地址的私钥SKDU进行解密得到SKAES，再解密Enc(CID,SKAES)，得到实际存储的CID 再进行数据的获取。由于提供的CID 只能获取整个数据的一部分，因此需要多次获取多份CID 才能够下载到完整的数据，从而实现细粒度的数据交易控制。根据此特性，可以控制数据的获取粒度为分块数量，从而在数据获取的过程中即可进行价值计量。而在数据的存储阶段则可以设置IPFS 的Merkle-DAG 分支数量，若分支数量较小则能够以更小的粒度进行计量。

2.3 身份注册及数据注册

该文方案中，注册包含用户身份注册及数据注册两类。各身份实体均是EVM 模型下的外部账户，通过公私钥对的形式向区块链注册。身份注册将在链上对DO 及DU 身份进行记录，数据在交易合约中进行注册，供后续下载时索引和使用。合约管理方（Contract Manager，CM）可以要求实体用户提供真实身份及注册匿名账号的映射关系，进行监管。由于链上数据的透明性，映射信息的提供和保管均由CM在链下进行。针对匿名问题，尽管用户以匿名地址的方式加入区块链网络，但仍有被获取真实信息、追踪到真实实体的可能[19]。该方案中一个实体可以通过多个不同账户注册，从而一定程度上避免追踪，但是在注册阶段要求实体主动向CM 提供对应关系，从而保障账户均受监管。数据注册流程如图1 所示。

图1 数据注册流程图

数据注册时提供元数据，包括描述信息、所有者、数据大小、价格、CID 密文等，DO 可以根据自己的数据价值进行定价，总价值需要与数据的大小锚定。该方法支持在较大数据传输时，确保已下载的数据和已支付的款项相一致，而非在交易结束后进行一次性的结算。一个文件的各部分数据有可能存储有用的数据信息，因此在传输过程中出现故障时，该方法可以保证支付金额和获取数据的价值对等。

2.4 数据获取

在数据获取阶段采用多轮微验证及微支付完成，具体获取流程如图2 所示。该方法中针对链上存储开销进行优化，使用区块链中事件日志的形式进行消息存放，较大程度减少执行开销。

图2 数据交易流程图

1）DU 订阅数据注册合约，根据订阅的链上日志发现自己需求的数据，主动向链上发起交易请求，发起请求时提供己方公钥PKDU给DO，用于加密对称密钥SKAES。随后DO 根据日志请求，响应对称密钥密文Enc(SKAES,PKDU)。

2）DO 在链上监听到DU 的日志请求，上传单轮次的IPFS 数据CID 密文Enc(CID,SKAES)进行传输，并通过数据交易合约自动调用通证质押合约，进行当前交易部分的数据的微支付，实现单次密文调用。

3）数据获取和验证同时进行，DU 向临近区块链节点订阅日志，收到属于自己的日志消息则用己方私钥SKDU解密得到CID 明文，再向IPFS 发起数据下载。当完成下载后通过交易发起时收到的对称密钥对数据块进行解密，完成数据获取。再利用解密的数据，通过构建Merkle 树的方法获得Merkle 根，向链上发起验证日志记录。若直接获取所有数据块的CID，则获取日志和验证日志条数将与数据块数量一致，而单个文件被分块存储后可能由数万块构成，因此获取以及验证的代价极大。该方法中利用IPFS的DAG 结构，DO 仅提供中间链接节点，从而DU 能够自行获取子节点，减少获取开销；再利用Merkle 树将数据块统一验证，减少验证开销。Merkle 树的构建需要单轮获取的所有数据块明文，逐一生成块的哈希值，作为Merkle 树的叶节点内容。中间节点哈希值由它的两个子节点内容的哈希值再次进行哈希获得，根节点则是整棵树结构的最顶部节点，同样由两个子节点内容的哈希值组成。构建完成后将根节点哈希值记录上链，DO 监听到反馈的验证日志，对比日志中的Merkle 根哈希值和己方生成的哈希值是否一致，完成微验证。

4）数据在DU 获取并在DO 验证通过后，DO 重复执行第2）、3）步，直到DU 获取到全部数据块，结束数据获取过程。

3 实验评估

该方案采用以太坊PoW 共识私有链进行测试，测试环境：Intel(R) Xeon(R) Silver 4208 CPU@2.10 GHz，128G 内存，CentOS Linux release 7.9.2009(Core)操作系统，以太坊使用geth 客户端实例，golang版本1.17.3。

使用PoW 共识算法的情况下，共识速度为平均13～15 s 生成一个新区块，远慢于智能合约数据交易处理速度的毫秒量级，因此交易过程中性能瓶颈会出现在共识算法产生新区块处，在测试时不考虑共识速度影响。通过实验得到相关智能合约函数调用开销如表1 所示。

表1 智能合约函数调用开销

函数调用中单次开销最大为constructor，但该函数用于在合约首次部署上链时调用，且合约全生命周期中仅调用一次，因此不是开销总和最大方法。表中requestData 函数虽然单次调用开销最小，但是其调用次数与数据大小相关，若单轮获取量较少，则能够控制为更小的计量以及验证的粒度，但调用总开销增加。

不同数据大小下，验证方法的执行开销对比如图3 所示。基准方法为基于每个数据块CID 进行验证，优化方法为该方案采用的基于Merkle 树的方式聚合验证。从图中可以看出，当数据较小时，两种方法的开销基本一致，而当数据量增大到10 MB 及以上时，两方法开销差异增大，10 MB 数量级时开销优化方法执行开销比基准方法降低65%。该文方法的优势在于数据量较大时，通过Merkle 树进行聚合的验证，极大降低了与区块链的验证次数，如在100 MB数据大小时，该文方法验证次数相比对比方法降低99.75%，因此减少执行开销。

图3 不同数据大小验证方法执行开销对比

不同数据大小下，验证耗时对比如图4 所示。如前文所述，实验的PoW 共识速度为平均出块时间15 s，远大于验证耗时，因此对比中排除共识生成区块耗时，仅包含交易验证交互的时间。

图4 不同数据大小验证耗时对比

从图4 中可发现，在数据量较小时，两种方法的验证耗时均在50 μs 量级，但在数据量增大时优化方法的验证耗时一直保持在50 μs 量级，而基准方法则会随着数据大小增加而线性增加，在数据大小为500 MB 时，优化方法比基准方法验证耗时减少88%。在验证时由于Merkle 树可以直接验证单轮传输的所有数据块，因此只需要向链上发送一个树根哈希值即可验证，而每块均独立验证的方式则需要接收数据块数量的哈希值，验证时间随块数量线性增加。

4 结束语

文中研究了现有数据交易方案及其缺陷，提出了一种基于Merkle 树的快速验证方法，结合IPFS 存储，实现数据块细粒度交易计量，最后进行实验验证。实验结果表明，该方法能够实现数据块级别细粒度的数据计量，在链上高效稳定完成计量、交易与验证。该文方案适用于大数据服务，仍有部分设计需要改进，如数据获取时发生错误可能导致需重新获取错误部分的索引并下载，导致效率低下；无整合众多的小型数据能力。在未来工作中，需进一步研究设计以改进上述问题。