随着区块链技术在金融、供应链及设备运维等领域的广泛应用,数据的安全性和存储性能问题愈加凸显.以航空发动机全生命周期运维管理为例,系统需要处理运行数据、故障诊断、检修记录等多个来源的异构数据.这些运维数据体量庞大、类型多样,如何提高数据存储的安全性和存储效率是当前亟待解决的技术难题.由于运维数据需要具备长期的防篡改保障与可信溯源能力,这对区块链的数据安全性提出更高要求.并且大量数据的频繁写入与查询,也暴露出链上存储在写入性能、查询效率上存在明显瓶颈.
为了应对这些挑战,本文提出了一种基于Merkle树聚合的Merkle森林结构的区块链混合存储安全验证方法,以提升存储验证效率.该方法结合链上和链下存储的混合存储方案,在区块链主链上仅存储元数据和摘要信息,而将实际数据存储在链下的分布式存储系统中.进一步在传统Merkle树的基础上,采用了Merkle森林结构,通过将多个Merkle树并行处理,从而提升了数据验证的效率,解决了传统Merkle树在大数据量存储和验证过程中的效率问题.
1 相关研究
当前,为解决链上存储空间受限与性能瓶颈问题,学术界和工业界广泛探索了链上索引与链下存储相结合的混合数据管理方案.许继平等
[1]将追溯数据通过链下MySQL中心数据库存储和链上存储数据密文,实现稻米追溯数据链上链下协同扩容.于合龙等
[2]综合分析区块链技术在稻米追溯中的应用场景,提出将追溯数据分类存证,公开追溯数据直接上链存储,隐私数据存储在企业链下数据库,由哈希算法计算信息摘要上链,链上链下协同保证数据安全.张晓蝶等
[3]设计并实现的基于区块链多链架构的农产品追溯系统,通过链下中心化数据库与链上多链协同缓解存储压力.在提高区块链查询速度方面,唐豪等
[4]将非敏感的大文件数据存储至链下数据库,然后利用布隆过滤器的哈希函数快速判断查询元素是否在指定数据集中,来提高链上检测数据的查询效率.
国外学者围绕Merkle树在区块链系统中的应用开展了大量研究,致力于解决数据验证效率低、存储开销大以及系统可扩展性差等问题.在Merkle树结构优化方面,Kuznetsov等
[5]等提出了一种基于路径长度分布的概率模型,用于优化Merkle Patricia Trie中的证明,显著提升了状态验证效率,并降低了链上数据传输成本.Chen等
[6]构建了基于多分支双向链式Merkle树的动态数据审计方案,适用于B5G网络中的高效审计需求.在物联网区块链场景中,Fateminasab等
[7]等设计了无须抵押的PoAct共识机制,利用Merkle树对节点计算能力进行验证,实现了能效优良且公平的交易共识.为了进一步提升链上验证性能,Kuznetsov等
[8]提出了自适应Merkle树结构,可根据访问模式动态重构树形布局,减少平均验证路径长度,提升区块链系统的整体扩展性.在Merkle树的安全性研究方面,Kuznetsov等
[9]针对数据伪造与哈希碰撞风险进行了定量分析,建立了伪造概率与路径长度、哈希位数之间的数学关系,为评估系统安全性提供了理论依据.此外,为降低大规模系统中证明验证的复杂度,Kuznetsov等
[10]提出了基于OR逻辑的聚合机制,实现了紧凑、高效的Merkle树包含性证明.总体来看,国外研究在Merkle树的结构优化、安全建模与共识机制融合等方面取得了显著进展,为区块链在高性能、低能耗和多场景应用中提供了坚实支撑.
此外,零知识证明在区块链技术中的广泛应用,如何在保障系统公开透明特性的同时实现数据隐私保护,也成为研究热点.零知识证明作为一种无须泄露原始数据即可完成正确性验证的密码学工具,逐渐成为提升区块链安全性与隐私性的关键手段.刘易
[11]围绕区块链隐私保护的技术需求,系统综述了零知识证明技术在区块链中的研究与应用现状,探讨了几种典型的零知识证明协议,如zk-SNARKs、zk-STARKs等,并分析了这些技术在区块链中的实际应用与挑战.万巍等
[12]针对区块链环境下的数据隐私保护需求,围绕三类主流零知识证明机制——zk-SNARKs、zk-STARKs 与 Bulletproofs——进行了对比分析,分别从生成与验证效率、可信设置依赖、证明体积、抗量子安全性等角度明确了它们的性能差异与适用场景.张杨等
[13]提出了一种基于区块链与零知识证明的身份认证机制,构建了改进的Shrubs Merkle Tree数据结构用于身份信息存储,结合链上链下分步证明机制,有效降低了计算开销,并实现了身份信息的隐私保护与不可关联性,实验验证显示该方案具有良好的安全性与可行性.此外,蒋诚智等
[14]设计了基于Merkle哈希树的异构通信网络数据异常值概率识别算法,构建哈希树并建立恢复数据包,有效提升了数据异常检测率与系统安全性.在能源区块链场景中,刘颖
[15]设计了链上链下多链协同存储结构,并提出了结合主链与企业链的数据隔离存储策略,以解决大规模敏感数据的安全性与扩展性问题.孙立等
[16]提出了基于布谷鸟过滤器与Merkle树的CMerkle结构,通过将布隆类过滤器和B+树索引机制融合,实现了快速的交易定位与验证.王文娟等
[17]构建了面向水产品交易的多链存储模型,提升了查询性能并缓解节点存储压力.
尽管国内外在Merkle树的结构优化、数据存储安全性和验证效率等方面取得了显著进展,但在大规模数据处理和实际部署过程中,仍面临诸多挑战.特别是在面对海量数据时,传统的区块链存储方式在存储效率、数据验证及系统可扩展性等方面依然存在显著问题,导致其在实际应用中面临瓶颈.因此,本文提出的基于Merkle森林的混合存储方案,通过结合链上索引和链下存储,不仅有效地解决了这些问题,还提升了数据验证效率,并降低了存储开销.
2 基于Merkle森林的区块链数据存储安全性方案设计
2.1 总体架构设计
本文设计的区块链数据存储安全性方案包括四大核心模块:区块链主链、链下存储系统、协同验证模块和隐私模块.各模块通过智能合约和链上链下数据协同验证机制,确保数据的完整性、隐私性和不可篡改性.
1)区块链主链:负责记录所有关键操作的摘要信息(如数据哈希值),通过智能合约执行数据审计与权限控制.
2)链下存储系统:用于存储实际的详细数据.区块链只保存摘要信息,避免大规模数据直接存储在链上.存储系统可以是传统数据库、云存储或分布式存储系统.
3)协同验证模块:负责链上链下数据的一致性校验,确保链下数据的完整性和不可篡改性.
4)隐私模块:通过访问控制和零知识证明技术,确保敏感数据的隐私性,只有具备权限的用户才能访问相关数据.
2.2 混合存储方案
由于链上存储空间有限,直接将海量数据存储在区块链上会导致存储压力增大,查询速度变慢.因此,本文提出了一种混合存储方案.该方案将文件的元数据和摘要信息存储在链上,而将实际数据存储在链下的分布式存储系统中.这种方案通过设计链上索引和文件摘要来减少数据量,并有效提升数据验证的安全性和存取效率.
2.2.1 链上索引和文件摘要
在区块链上存储文件的哈希值、文件路径、文件所有权和访问控制等元数据.具体字段设计如下.
1)文件哈希值(file hash):由文件内容生成的哈希值,确保文件的唯一性和完整性.
2)文件路径(file path):指向链下实际文件存储位置的引用地址.
3)文件所有权(ownership):记录文件的所有者信息.
4)访问控制(access control):通过访问控制列表(ACL)实现对文件访问的权限控制.不同的用户可具有不同的访问权限,如读取、写入、分享等.
2.2.2 链下存储方案
链下存储使用固定长度编码技术,并结合Merkle树的哈希值,生成文件的唯一标识符.在数据存储时,文件首先被分块,每个数据块生成一个哈希值,形成Merkle树的叶节点.最终,根哈希值作为文件的唯一标识符存储在区块链中.通过这种方式,链下存储与链上存储相结合,实现了高效的存储和检索.
2.3 链上链下协同验证算法
该方案的关键在于设计一种链上链下数据协同验证算法,能够在保护链下数据隐私的前提下,验证其完整性和真实性.
1)验证流程.链下存储数据生成摘要:各阶段的详细数据存储在链下的存储系统中,链下存储系统计算数据的哈希值H(D).将数据的哈希值H(D)存储到区块链(主链)上,用于后续的验证.
2)链上存储摘要与事件记录.主链只保存链下数据的哈希值 及对应操作的事件信息,如时间戳、操作类型、操作者身份等.
3)协同验证流程.当需要验证链下数据时,从链下存储系统中取出数据D',重新计算其哈希值H(D').将计算得到的哈希值与主链上存储的进行比对.如果,则证明链下数据D完整且未被篡改.
为了提高链上链下协同验证的效率,需要针对数据存储和验证过程中的关键瓶颈进行设计.以下是详细的优化措施.
2.3.1 Merkle 森林的结构设计
当数据量较大时,每个数据项都需要单独生成哈希并存储在链上,会导致链上存储膨胀和验证效率降低.因此设计Merkle树优化哈希存储,将多个数据的哈希值聚合成一个根哈希值存储在链上.
对此,本研究从存储和验证两个方面优化Merkle树.
在存储层面,设计Merkle森林;在验证层面,引入SNARK证明机制降低验证开销.对于大规模数据集合,单棵Merkle树的深度会导致验证开销较大.可以引入Merkle森林的概念,将数据分为多个集合,每个集合使用一棵独立的Merkle树进行管理.这样,可以通过树间并行计算提高效率.具体分为两部分.
并行验证:通过将数据分成多个独立的集合,每个集合使用单独的Merkle树来减少树的深度,从而提高验证速度.
合并根哈希:通过组合多棵Merkle树的根哈希值,生成一个“森林根哈希”来存储在链上,避免出现单棵树的冗长验证路径.
Merkle 森林由多棵 Merkle 树组成,每棵树可以存储不同的数据集.每棵树的根哈希值可以聚合成一个“超级根”,类似于超级块的概念,这使得整个系统可以处理更多的独立数据集而不增加复杂度.
2.3.1.1 基础结构
多棵Merkle树:每棵Merkle树处理一个独立的数据集合.每棵树的根哈希值存储在链上,保证数据不可篡改和完整性.
超级根哈希:所有 Merkle 树的根哈希可以进一步聚合生成一个超级根哈希,超级根哈希可以作为 Merkle 森林的顶层,存储在区块链中.
本文采用累积哈希 (accumulative hashing)来优化 Merkle 森林的技术,通过对多个 Merkle 树的根哈希进行压缩或合并,生成一个较短的超级根哈希,以降低链上存储和验证的复杂度.将所有 Merkle 树的根哈希按照顺序进行串联,并使用SHA-256哈希算法对串联后的数据进行哈希运算,生成一个新的哈希值,即超级根哈希.公式表示为
式中:
是各棵Merkle树的根哈希值;
是累积后的超级根哈希.如
图1所示.
2.3.1.2 数据分片
根据数据的重要性、大小或类型,将数据分配到不同的Merkle树中.将不同来源的数据存储在不同的树中,每棵树具有独立的结构.具体数据可分为以下类型.
①高优先级数据和低优先级数据:将需要频繁访问或验证的重要数据(如用户权限、核心信息)存储在独立的Merkle树中,以确保其高效验证和快速访问.这类数据占用较少空间,但对系统的安全性和性能至关重要.
②小型数据块和大型数据库块:对于较小的数据块(如短文本、用户记录等),可以将其打包到同一棵 Merkle 树中.这有助于减少树的层数,降低验证路径的复杂度.对于大型文件或数据集(如视频、图片、数据库记录)等大型数据库块,可以将其分配到专门的 Merkle 树中.这不仅可以提高这些大文件的处理效率,也能减少它们对其他数据的影响.
③结构化数据和非结构化数据:结构化数据(如数据库记录、元数据)和非结构化数据(如图像、音频文件)可以分别存储在不同的Merkle树中.这样可以在对数据进行验证时,采用更适合该类型的优化策略.
④动态和静态数据:动态数据(如交易记录、实时传感器数据)更新频繁,可以单独存储在一棵树中,方便增量验证.静态数据(如文档、历史记录)则不需要频繁更新,可以放置在另一棵树中,优化存储空间.
通过设计灵活的分片策略,可以使得数据更加有序,并且不同的数据类型分离存储,方便管理和验证.
2.3.1.3 树的选择策略
可以基于文件大小、数据类别或时间戳等属性来决定哪个 Merkle 树负责存储某个数据片段.
通过这种结构,降低单棵树的高度和验证复杂度,使得大数据集可以通过多个平行树来处理,提升验证效率.
2.3.2 分层验证和并行验证机制
2.3.2.1 分层验证
①树内验证:每棵Merkle树内独立验证.类似传统Merkle树的验证方式,每棵树从叶节点到根节点生成哈希路径,逐层验证数据的完整性.
②树间验证:超级根哈希负责多棵Merkle树的管理.如果需要验证某个数据块,只需验证该块所属的Merkle树,同时验证超级根哈希即可.无须对整个森林中的所有树进行验证.
2.3.2.2 并行验证
Merkle 森林的设计天然支持并行验证.每棵树可以独立处理其内部的数据验证,因此多棵Merkle树可以同时进行验证,从而提升验证速度.如
表1和
表2所示.
2.3.3 Merkle 森林中的 SNARK 优化
SNARK可用于优化Merkle树的验证过程.传统的Merkle树验证要求传递数据块和整个验证路径,而SNARK可以生成一个简洁的证明,使得验证时间非常短.本文将结合利用多项式承诺(polynomial commitment)和变体的Merkle树来构建高效的 SNARK证明,从而实现快速和安全的数据验证.
此方案包括以下4个方面.
①数据输入:用户提交数据块加入多个数据集,每个数据集包含一系列数据块.这些数据块将被分别存储在不同的Merkle树中,形成Merkle森林结构.数据块的分配可依据数据的重要性、大小、来源等标准.
②Merkle森林树构建:构建Merkle树合并成森林并生成根哈希.
③SNARK证明生成:生成Merkle树的SNARK证明.
④链上存储:存储根哈希及SNARK证明.
2.3.3.1 数据分块
首先将数据集Dj 按照固定大小进行划分,得到nj 个数据块:.
随后采用SHA-256哈希算法计算每个数据块的叶子节点哈希值:
式中:Dji 为第j个数据集中的第i个数据块;H表示SHA-256哈希函数;hj,i 表示对应叶子节点哈希值.
2.3.3.2 构建Merkle树
每棵Merkle树根据其分块数据生成,将哈希值逐层组合,构建Merkle树.
式中:数据块通过哈希函数H计算得到的哈希值.
最终,每棵树生成一个独立的根哈希值.这些根哈希会通过累积哈希技术进一步压缩成一个超级根哈希.该超级根哈希表示整个Merkle森林.
2.3.3.3 SNARK证明生成
①数据模型:输入数据,数据块集合,对应其哈希.
②多项式承诺:利用多项式承诺机制,允许用户在不公开数据的情况下验证数据块的有效性.
定义多项式:为每棵Merkle树构造一个多项式 ,其系数为数据块哈希值.
式中:为第j棵树中第i个数据块的哈希值;x为多项式变量,定义域中一个确定值.
承诺:生成对多项式的承诺,使用承诺方案KZG承诺.
③生成SNARK证明:结合Merkle树和多项式承诺生成SNARK证明.
证明过程:用户选择某个数据块及其对应的哈希通过Merkle树生成路径哈希(从叶节点到根哈希的路径哈希).路径哈希pathHash的格式为:.
结合路径哈希与多项式承诺生成SNARK证明π.
式中:是构造的多项式,其系数为数据块哈希值;是对多项式的承诺;是目标数据块的哈希值;pathHash是该数据块在Merkle树中的证明路径.
④验证过程:验证者在链上只需要存储超级根哈希和SNARK证明,无需完整数据.
验证阶段以根哈希、目标数据块哈希值、以及证明作为输入.验证者通过SNARK验证目标数据块的哈希值是否包含在Merkle树中,即.
从数据块的哈希值开始,通过路径哈希向上计算,直到得到根哈希.如果最终计算结果与给定的根哈希相同,并且结合其他分片的哈希,得到最终的合并哈希,同时哈希验证正确,则证明有效.
验证多项式承诺:计算P(r)和承诺的有效性.具体可以通过和与承诺进行比较,如果承诺可以从中推导出,则证明有效.
验证超级根哈希:可以通过所有Merkle树根哈希的累积结果进行验证.
如果超级根哈希验证成功,则证明整个Merkle森林中的数据有效.
2.3.3.4 合并存储方案
将根哈希和SNARK证明存储到区块链上.
2.3.4 系统的定期审计与数据校验
为了确保数据库中大规模异构数据的完整性与防篡改性,本文设计了一种基于Merkle森林的定期审计与完整性验证机制.该机制通过为每类数据或数据表构建一棵独立的Merkle树,并生成整个森林的聚合哈希(即超级根哈希)存入区块链,进而实现链下数据的批量验证能力.
定期任务通过对比当前森林计算出的超级根哈希与链上原始哈希,可快速判断任意一类数据是否存在被篡改的风险.具体流程如下.
步骤1:从区块链获取超级根哈希值.定时任务启动后,系统根据预设的查询条件,从区块链用户端中批量获取相应数据的哈希值.这些哈希值聚合生成根哈希值.
步骤2:从本地数据库获取明文数据.系统根据相同的查询条件,从本地数据库中批量获取对应的明文数据.明文数据包括运维记录的所有详细信息,如维护时间、维护人员、维护内容等.利用本地数据库的高效查询能力,可以快速返回查询结果.
步骤3:计算明文数据哈希值.系统对从本地数据库中获取的每条明文数据进行哈希计算,生成对应的哈希值,作为Merkle树的叶子节点,并根据Merkle树构建规则逐层合并,最终计算得到当前数据集的Merkle森林的根哈希值.
步骤4:对比当前根哈希与链上根哈希.系统将计算得到的每条明文数据的哈希值与从区块链中获取的原始哈希值进行对比.如果两个哈希值相同,表示数据在存储和传输过程中未被篡改;如果两个哈希值不同,表示数据在存储或传输过程中被篡改.
步骤5:记录验证结果.系统将验证结果记录在本地日志与区块链溯源模块中,并生成详细校验报告.若发现异常,将标记对应的数据批次,并向管理员发出告警.该流程如
图2所示.
系统每10 min触发一次定期审计任务,对数据库中新增或更新的批次数据构建Merkle树并进行验证,保障链下数据与链上状态的一致性.当某批数据通过校验,则该数据被视为完整可信.
在本次实验中,我们对数据库中某条记录进行了模拟篡改(如将字段AIRCRAFT_TYPE的值从45更改为50).系统在下一轮数据校验中重新构建Merkle森林并计算根哈希,发现其与链上记录的原始根哈希不一致,从而判定该数据已被篡改.该结果验证了所提出的数据完整性检测机制在识别链下数据异常方面的有效性与可靠性,如
图3~
图5所示.
3 实验分析与验证
本文对比传统全数据上链方案与本方案的链上存储开销.在传统方案中,每条运维数据直接以明文方式写入区块链,数据规模随时间增长而快速膨胀;而本文方案中,链下保存原始数据,仅将Merkle森林中的多个根哈希及聚合后的超级根哈希存储于区块链上.实验中以160 000条记录(4 kB/条)为例,传统方案链上存储为625 MB.若采用每条数据存一个哈希值的方案,即每条数据计算SHA-256并将其结果(32 字节)写入链上,则链上总存储为5.12 MB.而本文方案中,每 4 条数据构建一棵三层Merkle子树,并进一步分成每批 1 000棵Merkle树,每批聚合出一个“超级根哈希”.最终,链上共记录40个超级根哈希,每个为 32 字节,总链上存储空间为1.25 kB.与传统全数据上链方案(625 MB)相比,该结构可实现超过 99.9% 的链上空间压缩.
为了验证所提出方案的有效性,本文通过实验对比了Merkle树和Merkle森林在数据构建、验证、路径计算和文件检索等方面的性能.
3.1 Merkle森林效率实验分析
为了评估Merkle树和Merkle森林在大规模数据处理中的表现,本实验分别对经典的Merkle树和改进后的Merkle森林进行了性能测试.测试主要评估了构造时间、验证时间、获取Merkle路径时间和验证内容的时间等关键指标.实验中的数据集大小从 20 000到160 000个元素逐步增加,以评估两种结构在不同数据量和树的数量下的性能表现.每个数据元素是一个4 kB的随机生成字符串,模拟文件或数据块.
在传统Merkle树实验中,数据被组织成单棵树进行构建与验证.测试过程中计算了构建树、验证树、验证内容和获取路径哈希所需的时间.而在Merkle森林实验中,数据被分割成多个子集,每个子集生成一棵独立的树,测试计算了构建森林、生成超级根哈希、验证森林、验证内容以及获取路径哈希所需的时间.实验结果表明,Merkle森林在处理大规模数据时,相比传统的Merkle树展现出更高的效率,特别是在通过并行处理多棵树、减少树的深度以及快速计算超级根哈希方面,Merkle森林显著提高了构建和验证的效率.
3.1.1 构造Merkle树时间
如
图6所示,在原始Merkle树中,随着数据量的增加,构造时间呈现线性增长趋势.从20 000到160 000个数据元素时,构建时间从约10 ms增加至约61 ms.随着数据量的增加,树的深度和计算的哈希数量也随之增加,导致构建时间增长.相比之下,在Merkle森林中,数据量的增加并没有导致时间显著的线性增长.虽然树的数量和数据量增加时构建时间会增加,但增长速度明显低于Merkle树.这是因为Merkle森林的计算任务被分割成多棵独立的子树,通过并行处理有效提高了效率,从而加快了构建速度.
3.1.2 验证Merkle树时间
如
图7所示,在验证Merkle树时,随着数据量的增加,验证时间呈线性增长趋势.这是由于验证过程中需要遍历整个树结构并验证每一层的哈希值.在Merkle森林的验证过程中,虽然验证时间随着数据量的增加而增长,但其增长速度远低于传统Merkle树.由于Merkle森林采用了并行验证,每棵树的验证时间是独立的,多棵树可以同时验证,大大提高了效率.
3.1.3 验证内容时间
如
图8所示,Merkle树的验证内容时间在数据量较大的情况下仍保持在较低水平,这表明验证内容的时间与数据量的变化关系较小.验证内容时间的主要影响因素是路径验证和哈希查找,Merkle森林在验证内容时也表现出类似的结果.尽管数据量较大,但由于并行验证和树结构的优化,Merkle森林的验证内容时间仍保持在可接受范围内.
3.1.4 获取Merkle路径时间
如
图9所示,在传统Merkle树中,获取Merkle路径的时间呈现线性增长.随着数据量增加,路径长度增加,计算和验证路径哈希所需的时间也随之增加.相比之下,Merkle森林在获取路径哈希时的时间增长速度明显低于传统Merkle树.这是因为通过并行处理和减少树的深度,Merkle森林能够更加高效地进行路径获取.
3.2 SNARK效率实验分析
本实验的主要目的是分析SNARK证明生成和验证的效率,数据量分别是10 000、20 000、30 000、 40 000、50 000、60 000、70 000.通过改变数据量和树的数量来进行测试.由于SNARK公式设计中有系数限制,因此需要评估一颗树最多有1 000个节点和500个节点时的效率变化情况.
当数据量固定(1 000),通过分析证明生成和验证所需的时间,评估随着树的数量增加,SNARK证明的性能如何变化.由于固定了数据量,因此通过不同的树的数量(10 000~70 000)进行SNARK证明生成和验证的时间测量.从
图10可以看出,随着树的数量增加,SNARK证明生成时间明显增加,无论数据量为500还是1 000,当树的数量从10 000增长到70 000时,证明生成时间呈线性增长趋势.这表明生成证明的计算量与树的数量成正比.数据量为1 000时的SNARK证明生成时间普遍高于数据量为500时的生成时间.例如,在树的数量为20 000时,1 000的数据量需要19.25 s,而500的数据量仅需要5.17 s,差距达到14 s以上.这是因为单位数据量越大,生成SNARK证明所需计算的步骤和存储数据越多,导致生成时间更长.尤其是计算系数
P(
x)的过程.在相同的数据量下,随着树的数量增加,验证时间逐渐增加.这是由于树的数量增加了验证路径的长度,进而导致了更多的数据参与验证,验证过程的复杂度增加.数据量的增加(500~1 000)显著提高了生成和验证SNARK证明的时间.这种增加主要表现在生成证明时,因为更多的数据意味着需要更多的计算量.因此为了最优解,需要在权衡存储与计算时,尽可能减少单位树的数目.
3.3 自定义存储与IPFS存储比较
为了比较自定义存储方式(基于Merkle树存储和检索)与IPFS存储方式,每个文件按4 kB分块(固定大小).测试文件的大小从1 MB 到20 MB(包括 1、3、5、7、10、20 MB).自定义存储是计算文件的哈希值,生成Merkle树,然后将根哈希存储到文件中.之后可以基于根哈希检索文件,IPFS存储是将文件上传到IPFS并通过CID进行检索.
图11对比了自定义存储与IPFS存储的效率.
自定义存储的过程涉及到将文件分块后计算每个分块的哈希值,再构建Merkle树,最后存储根哈希.根据实验数据,文件的生成和检索时间随着文件大小的增加而增加,但增幅较小.自定义存储的主要优势是高效的文件检索,不依赖于网络或外部节点.因此,文件检索时间相对较短,且可以完全控制存储位置.
在IPFS存储中,上传和下载文件的时间随文件大小的增加而显著增加.上传时间通常比检索时间更长,且文件的下载速度可能受到网络波动的影响.IPFS的优势在于去中心化存储和分布式检索,适用于大规模的文件共享和存储.然而,在某些情况下,文件的上传和下载速度可能受到网络的限制.
就上传时间来说,IPFS存储在上传大文件时的延迟明显较高.上传时间随着文件大小的增加成比例增长,尤其是对于较大的文件(如20 MB)而言.IPFS 在下载大文件时也表现出较长的延迟,但相比于上传,下载时间相对较短.自定义存储在生成和检索文件方面的效率较高,特别是在较小的文件(1~10 MB)时,生成和检索时间的增幅较小,文件大小对效率的影响相对平缓.
3.4 Fabric上链测试
本次实验基于航空发动机运维系统中的多源异构数据共享场景,选取 Hyperledger Fabric 2.5.9 作为区块链底层平台,验证系统在不同交易负载下的数据上链与查询性能.该系统涉及结构化(元数据)、半结构化(JSON索引)、非结构化(文件摘要)等多类数据,需实现不同来源单位之间的可信共享与存证校验.
本实验通过执行UploadFile函数进行数据存储和事务提交,通过执行 GetFileMetadata函数查询已存储的文件元数据,比较这两个函数在Fabric环境下上链和查询的吞吐量.本次实验执行了不同交易量的吞吐量测试,分别测试了交易提交和数据查询的性能.每秒提交30、50 、70、100、130、150、180、200条交易,统计每个量级的执行时间,并计算吞吐量.每秒查询30、50 、70、100、130,150、180、200条数据,统计查询所用时间,并计算吞吐量.
如
图12所示,随着提交的交易数量增加,吞吐量在不同的范围内波动.在低负载情况下(每秒30~100条交易),吞吐量较高,大约在28~39 TPS之间.在更高负载(每秒200条交易)时,吞吐量降至34.65 TPS.
从数据可以看出,在更高的交易数量下,吞吐量没有呈现出线性增长的趋势,表明系统处理能力可能受到了瓶颈(如共识、网络延迟等因素)的限制.查询操作的吞吐量远高于提交操作.30~200条查询交易时的吞吐量从107.45 TPS增长至219.31 TPS.
查询吞吐量增长较为稳定,随着查询数量的增加,系统能够有效处理更多查询请求,系统的吞吐量受到了较少的瓶颈限制.验证了在面向异构多源数据的区块链共享环境中,Fabric平台具备良好的查询响应能力与中等负载下的数据写入能力,适用于航空装备领域中对数据防篡改、共享可信、高频读写等场景的区块链平台选型需求.
4 结 论
本文提出的基于Merkle森林的区块链数据存储方案通过结合链上和链下存储有效解决了存储压力和验证效率问题.实验结果表明,Merkle森林相比传统的Merkle树,在处理大规模数据时具有更高的效率,特别是在存储和验证过程中降低了时间复杂度.此外,SNARK证明进一步优化了验证过程,为大规模区块链应用提供了高效且安全的数据验证机制.
国家重点研发计划项目(2023YFB4302401)
National Key R&D Program(2023YFB4302401)