基于区块链的审计数据查询框架构建研究

徐超 赵必然 陈勇

【摘 要】 区块链技术具有去中心化、防篡改、可追溯等技术特点，可以为审计数据安全提供帮助。然而在实际审计场景应用中，区块链系统由于其本身查询效率低下和查询功能有限等不足，难以满足审计的及时性和功能性需求。文章提出一种基于区块链的审计数据查询系统框架。首先扩展了区块链上存储的数据结构，满足对被审计数据做数据处理的需求；其次，把区块链中的数据同步到其他数据库中，实现数据的快速查询和多类型查询；最后，通过设计同步规则和构建索引，保证数据从区块链到数据库的一致性和快速更新。从仿真实验结果来看，该框架方案在查询效率、查询功能、数据同步等方面具有良好的表现。

【关键词】 区块链； 查询优化； 审计数据

【中图分类号】 F234.3  【文献标识码】 A  【文章编号】 1004-5937（2023）05-0136-07

一、引言

随着物联网（IoT）[1]、供应链管理[2]、远程信息处理（Telematics）[3]等的快速发展，数据逐渐成为事件驱动的载体，但在数据交互过程中其完整性和安全性无法得到保证，迫切需要新技术来有效地管理数据。区块链作为不可信环境中的可信机器，在数据完整性、去中心化和分布式账本技术方面已被证明是有效的[4]。审计对数据的真实性和完整性的要求是十分严格的，所以在这点上，区块链很好地满足了审计的需求。

在区块链技术和审计的结合方面，一些学者从不同角度开展了研究。毕秀玲等[5]认为区块链技术是审计数据的安全保障，可以构建起“审计智能＋”的免疫系统。郑石桥[6]分析了区块链对审计取证路径的影响，并提出了一个区块链对审计取证影响的理论框架。王琳等[7]基于区块链技术构建了一套适用于现代审计业务发展趋势的实时审计框架，并对框架内各个模块的组成、功能及工作机理进行详细说明。房巧玲等[8]提出并构建了一种区块链技术驱动下的审计模式——基于双链架构的混合审计模式。王涵等[9]提出了一种基于区块链和默克尔哈希树的公共审计数据共享方案，以达到对管理员权限的控制和数据的动态修改，并在实现隐私保护、批量审计和降低系统资源消耗的同时，保证了方案的安全性。综上，目前区块链与审计结合的研究主要还是停留在理论框架上，应用方面的侧重点也没有考虑到数据的查询问题。

二、研究现状

在审计过程中，被审计数据的数量和属性繁杂，审计问题多种多样，而每一个审计问题往往只涉及到部分信息。所以除了要保证数据的完整性以外，如何根据特定的审计问题从区块链上快速地找出所有目标信息也变得越来越重要。

然而，区块链缺少传统数据管理系统中的许多便利，例如强大的查询引擎，在查询语言和查询处理方面使用起来不方便[10]，导致区块链只支持基于哈希的关键字查询，查询方式单一，且需要遵循特定的格式（例如128位十六进制元素）。同时，很多区块链系统为了追求卓越的写性能，都采用键值数据库作为底层数据库，例如Level DB[11]。然而，这类数据库通常基于LSM-tree[12]存储结构，其读取性能勉强令人满意，尤其是随机读取。

近年来的研究主要分为三大方向来解决这些问题。一是通过智能合约驱动数据查询。Abuhashim et al.[13]旨在通过编写不同的智能合约函数将数据放入区块链上的智能合约中，以支持区块链索引和检索。 et al.[14]采用了在以太坊上使用FastQeury智能合约在区块链上存储和查询药物基因组学数据的方案，该方案利用属性值的唯一性进行存储映射，类似于哈希表，以实现高效的键值查询。然而，智能合約存在太多限制，包括智能合约本身的潜在漏洞、Gas限制、Solidity语言转换为字节码时功能边界模糊等。并且，从这些文献的实验部分可以看出，智能合约只能在特定的数据量较小的场景下使用，不具备泛化性。二是把区块链数据存储在其他数据库中。Ether QL系统中包含一个同步管理器模块，用于从区块链系统中获取新的区块数据，解析出区块链字段，存储在Mongo DB中，然后提供查询接口，借助外部数据库实现查询功能[15]。Bragagnolo

et al.[16]提出使用大数据技术来提取和分析区块链中的信息。他们使用Map/Reduce模型的并行索引算法将区块链数据同步到关系数据库中。这些方法是高效的，但将数据从区块链更新到其他数据库时存在延迟，不能很好地满足用户实时查询数据的需求。其次，外部数据库不是防篡改的，无法保证查询数据与区块链数据的一致性。三是在区块链内部构建索引结构。Blockchain DB选择使用红黑树和Merkle树的组合RBTree作为索引结构[17]。Huang et al.[18]设计了一种基于双向链表的区块链，结合了线索二叉搜索树（TBST）和AVL树，提出了一种新的块内搜索结构。由于链上的数据与索引的更新是同步的，所以这些方法支持实时查询，但问题在于在区块链内构建索引结构实施难度较大，并且每种预定义的查询类型都要对应一个数据结构，扩展性弱。

针对以上问题，为满足审计场景的数据查询需求，本文基于数据库和区块链技术提出了一种面向审计的查询系统框架。考虑到链上空间的局限性以及对数据保密性的要求，本文采取“链下审计”+“链上验证”的审计与区块链结合模式，即先对被审数据哈希加密后生成验证码，然后把所有的验证码存放在区块链中，链下进行审计时再从链上返回对应数据的验证码做计算比对，验证被审数据是否被篡改。

三、系统框架

本文提出的系统框架如图1所示，包括数据层、查询层和应用层：数据层包含一个数据库模块和一个区块链模块，分别存储被审数据和验证码；查询层包含一个数据库模块，负责同步区块链上的数据值，并提供快速、多样的查询服务；应用层根据审计问题获取所需的被审数据和验证码，并作计算比对，保证被审数据的完整性。

（一）数据层

在本文的系统中，会根据常见的审计问题维护一张表，该表包含三个属性字段：Audit_desc表示某审计问题的描述；Audit_attr表示该审计问题所涉及到的属性（每条被审数据会有很多属性，而一个审计问题往往只涉及到其中的几个）；Audit_num表示系统为该审计问题生成的唯一编号Ai，其中Ai表示第i个添加到该表中的审计问题。该表存储在数据库模块中。表1表示在医疗收费审计场景下审计问题表的一个具体示例：系统中编号A1对应的审计问题为“超标准收费”，其涉及到的属性有“数次”“单价”“实收金额”“收费类别”“项目名称”等；系统中编号A2对应的审计问题为“多收取患者药品费”，其涉及到的屬性有“药品名称”“成本价”“零售价”“差价”“加价率”等。

在验证码上链的过程中，系统会根据该表中存在的审计问题，自动在被审数据中找出所有与该审计问题相关的信息，逐条按照预先设定好的哈希函数做哈希运算，生成的验证码按照审计问题的编号进行分类。

在比特币[19]系统中，区块结构如图2（a）所示：每个区块都由一个区块头和一个区块体组成，区块头含有多个字段，包括指向前一区块的哈希值、表明区块身份的区块ID和本区块的哈希值、区块形成的时间戳、区块体中所有交易自下而上哈希得到的Merkle根以及该区块被合理生成的证明；区块体包含多条交易，每条交易的结构如图2（b）所示：包括交易的版本号、交易输入、交易输出以及交易生成的时间戳，其中交易输入包含输入数量和附带用户私钥签名的解锁脚本，交易输出包含输出数量和使用对方公钥锁定的锁定脚本。

由于比特币系统是面向交易的，并且数据结构是固定的，因此系统只能处理固定结构的交易数据，其每个交易结构里包含的交易数据的信息字段也都是与交易本身有关，而对于被审数据这种更具一般性的数据而言，比特币系统的交易结构就无法完美地兼容。

为了让比特币系统可以在审计场景中更好地对被审数据进行数据处理，本文的解决方法是，对原本的交易结构进行扩展，如图3所示：扩展后的结构包含系统（System）属性和数据（Data）属性两部分。系统属性部分用来存放区块链系统为交易生成的信息，包含版本号（Version）、签名（Signature）和时间戳（Timestamp）等；数据属性部分用来存放与被审数据本身相关的信息，包括被审数据的链下标识号（Data_id）、审计问题的编号（Audit_num）、验证码（Data_hash）、被审数据本身发生的时间（Data_time）以及部门编号（Department）等。其中Data_id字段用来匹配链上与链下的数据，Audit_num字段用来对链上数据进行分类，Data_hash字段用来存放链下数据经过哈希加密后的结果，Data_time字段用来辅助查询，Department字段表示被审数据原本归属的部门（考虑到审计场景中，被审数据往往是由多个部门的子数据集组成）。

这样区块链系统就与交易脱钩，变成了服务于审计的特定数据库（为了表示这种变化，在下文中，原本区块链系统中的交易改称为记录，即每个区块的区块体中包含多条记录）。

（二）查询层

在提升区块链系统查询效率和查询功能的三个方向中，本文的系统选择的方法是构造查询层，把区块链上的数据同步到传统数据库中。在保证同步数据一致性的方法上，Wu et al.[20]采取的对策是使用哈希函数为每次同步的所有内容和属性生成一个指纹，这样只需要验证指纹的正确性就可以防止数据的伪造。该方法的具体流程为：在每个周期内（可以固定的时间或固定的区块数量为一个周期），系统先把区块链上更新的所有记录提取出来，按照目标属性重组后构建一个微型数据库，并为小数据库生成一个指纹；然后系统按照相同的数据库生成程序，在区块链中构建另一个微型数据库，并用相同的哈希函数为小数据库生成一个指纹；最后系统通过比较两个指纹值来验证同步数据的一致性。若验证失败，则系统中会产生错误报告，当错误报告达到一定数量时，系统会执行一个诊断程序来检查数据库的正确性，直到没有错误报告到达。

该方法的不足之处有：整个同步流程十分耗时，不能很好地满足实时查询的需求；系统对于每个周期内构建的微型数据库只是简单地按时间顺序更新到了大数据库中，没有做合并操作，并且该系统中的区块链是面向交易的，链上数据的属性不能全面地体现被审数据的信息，微型数据库可以提供的查询类别也就比较局限，无法满足审计场景中多个审计问题的需求。

本文基于为同步数据生成指纹的策略，设计了一个新的同步规则，优化了同步流程；在查询层中按照审计问题构建多张预查询表，并把每次同步的数据合并到已有的同类别数据表中，为审计场景提供快速且多类型的查询，优化了同步结果。

新的数据同步规则为：在每个周期内，系统首先按照审计问题的类别（即审计问题的编号）在区块链上更新的记录中找出对应的所有数据，用设定好的哈希函数为其生成一个指纹；然后系统把这些数据提取出来，保存到查询层，并用相同的哈希函数为其生成一个指纹；最后系统比较两个指纹值来判断同步数据是否一致。

为了提高数据同步流程中在区块链上查找数据的效率，本文添加了一个索引机制来加速链上数据的访问。系统会维护一个索引表，表中每个类别的数据都对应一个索引结构。索引结构定义如下：{Ai[b1，b2，…，bn]}，Ai即审计问题在系统中的编号，n表示每个周期内系统中生成的新区块总数，bn对应更新区块在本次周期内的相对位置，bn的取值为“0”或“1”。其本质上是一种位图结构，位图中从左数第j位表示该类别的数据是否存在于第j个区块中（置“0”表示不存在，置“1”表示存在）。当一个类别的记录首次出现时，系统会在表中添加该类别的名称以及对应的空白位图。当有一个新的区块产生时，通过设置相应位置的编码（“0”或“1”）来更新索引表。表2展示的是一次更新周期内索引表的具体示例：在该周期内，系统一共生成了10个区块，其中A1类型的数据存在于第3、4、6、10个区块中，A2类型的数据存在于第1、6、7、8个区块中。

这种索引机制的好处有：由于一个类别的记录可能会存在于不同的区块中，而位图可以精准地显示出记录存在的目标位置，这样系统在区块链上查找数据时就可以避免扫描所有区块；这种索引的构造难度较小，扩展性较高，十分便于系统对索引表的创建与更新。

由于数据层的区块链模块中的记录结构是经过扩展的，每条记录随着审计问题编号的不同而被分成了不同的类别，因此系统会在查询层的数据库模块中为每个审计问题分别构建各自的表，并以其对应的编号命名。除此之外，系统在查询层中会维护一张特定的名称表，用来存放查询层中已经存在的表名（即审计问题的编号），在每次同步数据的一致性验证成功后，系统会先判断查询层中是否存在同类别的表，若存在就添加到该表中，若不存在就创建一张新表，并把表名添加到名称表中。

一个类别的所有记录在系统中的一次更新周期内的同步流程大致如图4所示：首先系统会根据该数据的类别“Ai”，从索引表中获取对应的位图信息Index_table.Ai.Block_distribution；由于位图是由一串“0”“1”数据组成的，每位只是表示对应位置的存在情况，并没有直接指明具体的位置，所以系统会根据位图生成一个具体的位置信息列表Block_loc，里面直接存放具体的区块编号；系统根据位置信息列表在目标区块中获取本次更新周期内的所有类别为Ai的记录，并添加到一个缓存列表Ai.templist中；系统先对缓存列表生成一个指纹Fingerprint（Ai.templist），再把缓存列表同步到查询层的一个临时数据表Ai.temptable中，并对该临时数据表生成一个指纹Fingerprint（Ai.temptable），只有当缓存列表的指纹Fingerprint（Ai.templist）等于临时数据表的指纹Fingerprint（Ai.temptable）时，才能保证数据同步的一致性；当系统判定成功后，会在名称表中查找是否有“Ai”字段的存在，若找不到，说明查询层中还未构建该类别的数据表，则系统先构建一张对应的数据表Ai.table，并把临时数据表中的所有数据存放在该表中，最后在名称表中添加“Ai”字段，若找到，则系统把临时数据表中的所有数据合并到已有的同类别数据表中。到此，整个流程才算结束。

在单次更新周期内，不管某类型的数据存在于多少个区块中，VQL系统都需要进行n次对单个区块的查找步骤（n为每个周期内更新的区块数量），所以其同步流程的时间复杂度永远是O（n）。而在本文的系统中，由于索引的存在，系统对单个区块的查找次数随着该类型数据所分布区块数量的变小而减少，虽然最坏情况下仍然需要执行n次对单个区块的查找操作，但当数据只存在于一个区块中时，系统只需要执行一次对单个区块的查找操作即可，此时同步流程的时间复杂度为O（1）。

（三）应用层

系统中维护的审计问题表可以在应用层中查看，审计人员可以根据表中的信息，直接输入审计问题所对应的编号即可。系统会根据所输入的审计问题编号，自动完成数据的完整性验证，并将被审数据列表、其对应的验证码列表以及验证的结果在应用层中展示。

系统在做完整性验证时，可以直接从查询层中的预查询表中快速地获取验证码列表。因为链上数据的每条记录中也包含数据发生时间和部门编号字段，而这些信息也在数据同步过程中一起同步到了查询层中，所以如果审计人员想对被审数据做进一步的筛选时，比如获取特定时间内或特定部门的信息，由于以上字段的存在，系统也可以在查询层中快速地筛选出对应的验证码列表。而记录中的链下标识号字段可以幫助系统在逐条比对的过程中完美地匹配每一条被审数据与其对应的验证码。而对于某条具体的数据，系统也可以在查询层中快速地定位到对应的验证码。

四、实验与分析

由于本文的主要研究点在于区块链数据的查询方法和同步流程，不涉及网络以及共识协议，所以进行了仿真实验。

（一）数据查询方法

系统对查询效率的需求主要体现在根据审计问题从区块链系统中快速找到被审数据列表中所有数据对应的验证码，最终表现为快速地完成对被审数据的完整性验证。

本文比较在查询过程中通过扫描区块（Scan_block）和使用查询层（Query_

layer）两种方法所需的响应时间，并针对三种查询模式分别做了查询效率对比实验，包括：单值查询，表现为从区块链系统中获取某一条具体的被审数据对应的验证码（比如来自xx部门，产生时间为xxxx-xx-xx，标识号为xx，涉及到的审计问题编号为xx）；范围查询，表现为从区块链系统中获取特定条件下的被审数据对应的验证码（比如某个时间段或某几个部门，涉及到的审计问题编号为xx）；表查询，表现为从区块链系统中获取某一审计问题中的被审数据对应的验证码（比如涉及到的审计问题编号为xx）。

在不同数据总量的条件下，分别测试了Scan_block方法与Query_layer方法的表现。具体的实验结果如表3所示。可以看到，Scan_block方法在任意数据量和任意查询模式下的耗时都远高于Query_layer方法，并且在同一种模式中，随着数据总量的增大，Scan_block方法与Query_layer方法的耗时差在快速扩大。通过分析可知，由于Scan_block方法采用遍历方法，其查询过程需要读取整条链上的所有区块。特别的，由于本文的系统在查询层中已经按照审计问题的编号对所有数据做了分类存储，所以在表查询模式下，Query_layer方法只需要定位到对应的预查询表即可，这就解释了为什么在不同的数据总量下，Query_layer方法在表查询模式中的耗时几乎保持不变的原因。

（二）数据同步流程

因为本文系统和VQL系统在本质上都是把链上数据同步到链外数据库中做查询优化，所以两者单从查询效率上没有实质性的区别（不考虑不同数据库之间的差异）。而本文相较于VQL系统的优势点在于数据同步流程的优化。一方面是对同步结果的优化：由于本文对链上交易结构的扩展，使得本文的系统可以在查询层中按照审计问题的种类来对数据进行分类存储，每次更新的数据也都按照种类合并在了一张表中，这样对于一些常见的审计问题，系统可以直接从这些预查询表中获取数据，并且由于标识号、时间、部门编号等属性的存在，对于在特定范围内的审计问题，系统也能从查询层中做进一步的筛选。

另一方面是对同步效率做了优化：由于索引机制的引入，系统从区块链上查找目标数据的速度有了明显的提升，从而降低了整个同步流程的耗时。这样在一定程度上可以降低将数据从区块链同步到其他数据库时的延迟，以满足用户实时查询数据的需求。

本文针对每个更新周期内的同步流程，在两种场景下对两个系统的同步效率做了对比实验。一个是在区块数量不变的情况下（单次周期内的同步区块数量保持为25个），观察系统在不同区块容量下的表现，结果如图5所示（Improve表示本文提出的同步方法）。另一个是在区块容量不变的情况下（单次周期内的区块最大容量保持为2 500条），观察系统在不同区块数量下的表现，结果如图6所示。可以看到，在两种情况中的每个条件下，Improve方法的同步流程耗时总是低于VQL系统。并且随着实验变量的增加，VQL系统同步流程耗时的增长幅度大于Improve方法。

同时，本文还在以上两种情况下分别对Improve方法中索引的空间大小做了测量。表4展示的是单次的更新周期内，在单个类别数据上构建的索引结构与更新区块在不同条件下的空间开销。可以看到，在任意条件下，索引结构的空间开销都远小于单次更新数据的总空间开销，代价可以说是忽略不计。即使存在多种数据类型，并且在每个数据类别上都构建各自的索引结构，所有索引结构加起来的空间代价仍然是可以接受的。这表明Improve方法中的索引结构在空间上具有很好的扩展性。

五、结语

虽然区块链技术本身的特性十分契合审计场景中对数据的完整性需求，但目前区块链与审计结合的研究并没有考虑到数据的查询问题，并且现有的区块链系统因其自身的查询功能缺陷也无法满足审计场景的查询要求。针对这一问题，本文构造了一种基于区块链的面向审计的查询系统框架。本文考虑到链上空间的局限性以及对数据保密性的现实情况，采取了“链下审计”+“链上验证”的审计与区块链结合模式；首先为了能让区块链系统可以很好地兼容被审数据本身的属性，本文对比特币系统中的交易数据结构做了面向审计的扩展；其次本文选择把链上数据存储在其他数据库的方法来提升区块链系统的查询功能，并且基于VQL系统的验证思路，实现了数据同步的一致性；最后本文通过设计新的同步规则和构建索引对VQL的同步流程和同步结果做出优化。实验结果表明，本文方案在查询效率和数据同步等方面具有良好的表现。

不足之处在于，对于审计问题表的构造和更新需要人员主动去维护，未来可利用机器学习算法，通过训练让系统根据以往的审计经验自动维护审计问题表。

【参考文献】

［1］ MADAKAM S，LAKE V，LAKE V，et al.Internet of things（iot）：a literature review［J］.Journal of Computer and Communications，2015，3（5）：164-173.

［2］ MALIK S，DEDEOGLU V，KANHERE S S，et al.Trustchain：trust management in blockchain and iot supported supply chains［C］.2019 IEEE International Conference on Blockchain.2019：184-193.

［3］ SANG-OUN L E E，HYUNSEOK J，HAN B.Security assured vehicle data collection platform by blockchain：service providers perspective［C］.2019 21st International Conference on Advanced Communication Technology.IEEE，2019：265-268.

［4］ KUMAR R，SHARMA R.Leveraging blockchain for ensuring trust in iot：a survey［J］.Journal of King Saud University-Computer and Information Sciences，2021.

［5］ 畢秀玲，陈帅.科技新时代下的“审计智能”建设［J］.审计研究，2019（6）：13-21.

［6］ 郑石桥.区块链对审计取证的影响：一个理论框架［J］.财会通讯，2021（9）：1-5.

［7］ 王琳，向际钢.基于区块链技术的实时审计框架构建［J］.财会通讯，2020（9）：139-142，147.

［8］ 房巧玲，高思凡，曹丽霞.区块链驱动下基于双链架构的混合审计模式探索［J］.审计研究，2020（3）：12-19.

［9］ 王涵，王绪安，周能，等.基于区块链的可审计数据分享方案［J］.广西师范大学学报（自然科学版），2020，38（2）：1-7.

［10］ ZHU Y，ZHANG Z，JIN C，et al.Towards rich qery blockchain database［C］.Proceedings of the 29th ACM International Conference on Information & Knowledge Management，2020：3497-3500.

［11］ TULKINBEKOV K，PIRAHANDEH M，KIM D H.Cleveldb：coalesced leveldb for small data［EB/OL］.https：//github.com/google/leveldb.

［12］ ONEIL P，CHENG E，GAWLICK D，et al.The log-

structured merge-tree（LSM-tree）［J］.Acta Informatica，1996，33：351-385.

［13］ ABUHASHIM A，TAN C C.Smart contract designs on blockchain applications［C］.2020 IEEE  Symposium on Computers and Communications，2020：1-4.

［14］ GüRSOY G，BRANNON C M，GERSTEIN M.Using ethereum blockchain to store and query pharma-cogenomics data via smart contracts［J］.BMC medical genomics，2020，13（1）：1-11.

［15］ LI Y，ZHENG K，YAN Y，et al.Etherql：a query layer for blockchain system［C］.Internat-ional Conference on Database Systems for Advanced Applications，2017：556-567.

［16］ BRAGAGNOLO S，MARRA M，POLITO G，et al.Towards scalable blockchain analysis［C］.2019  IEEE/ACM 2nd International Workshop on Emerging Trends in Software Engineering for Bloc-kchain，

2019：1-7.

［17］ 焦通，申德榮，聂铁铮，等.区块链数据库：一种可查询且防篡改的数据库［J］.软件学报，2019，30（9）：2671-2685.

［18］ HUANG T L，HUANG J.An efficient data structure for distributed ledger in blockchain systems［C］.2020 International Computer Symposium，2020：175-178.

［19］ NAKAMOTO S.Bitcoin：A Peer-to-Peer electronic Cash System［EB/OL］.https：//bitcoin.org/bitcoin.pdf，2008.

［20］ WU H，PENG Z，GUO S，et al.Vql：efficient and verifiable cloud query services for blockchain systems［J］.IEEE Transactions on Parallel and Distributed Systems，2021，33（6）：1393-1406.