本技术涉及区块链数据处理技术领域,尤其涉及一种基于Fabric联盟链的交易并发冲突优化方法,包括客户端执行提案发起操作并生成交易发送至排序节点;排序节点接收不同客户端发送的交易,根据预处理操作将所接收的全部交易划分到4类集合中;将重排序交易集合中每一交易作为一个节点,通过读写依赖关系构建交易冲突依赖图;根据交易冲突依赖图对重排序交易集合中所有交易进行重排序;对待合并交易集合中的所有交易进行分组修改;根据只读交易集合、重排序结果和分组修改结果生成交易调度序列,将交易调度序列打包形成区块;本发明保证数据一致性,并通过缓存、重排序、合并的方法,减少区块内交易失败率,提升系统整体性能和资源利用率。
背景技术
Hyperledger Fabric(以下简称Fabric)是Linux Foundation管理的企业级开源联盟区块链平台。它提供一些模块化设计和可插拔组件,以满足广泛的行业需求。与现有的其他联盟区块链(例如FISCO BCOS)不同,Fabric联盟区块链采Execute-Order-Validate交易处理模式,由于在Fabric联盟区块链中,每笔交易只需要在满足交易背书策略所需的背书节点的子集执行即可。这允许交易一定程度并行执行,从而提高了系统的整体性能和规模。
但Fabric联盟区块链采用多版本并发控制(MVCC)机制,当联盟区块链应用到实时股票交易系统、电子商务系统、实时信息发布系统等高频次交易场景中时,多个用户可能并发的提交多个对同一数据集进行修改的交易请求。这些交易请求被发送到区块链网络中进行共识,然后存储到账本时,导致一个区块内存在冲突的交易。由于冲突的交易会几乎走完整个交易流程,直到交易验证阶段才被标记为无效,进而导致联盟区块链的性能下降和资源浪费。同时,冲突交易越多越不利于交易的并行验证写入。具体来说,交易处理要依次经过模拟阶段、排序节点、验证提交阶段。其中交易的读写集在模拟阶段生成,在验证提交阶段验证,时间跨度较大,这使得当多个交易并发地修改同一个数据时可能发生并发冲突问题,从而导致大量交易失败。并发冲突主要包括两种情况:第一种情况是在上一区块提交之前,当前交易背书生成读写集,由于上一区块的提交,导致当前交易在到达验证提交阶段时,读写集已过时,发生区块间的冲突,被标为无效;第二种情况是在同一区块中,冲突的交易在模拟阶段背书生成相同版本号的读写集,但是由于第一个交易的提交会更新版本,使得后续交易的版本过时,发生区块内的冲突,在验证提交阶段被标记为无效。无效交易占用了的系统的计算资源和网络资源,同时降低了系统性能和用户体验。
现有的解决Fabric并发冲突问题的方法主要分为两类,一类是在交易处理流程中通过缓存机制提前检测冲突,另一类是通过重排序交易减少冲突交易数量。基于缓存机制的方法通常在执行阶段或排序阶段将键值对存储在缓存中,后续交易通过查询对比缓存的信息来检测是否有潜在的冲突要发生并提前中止。但是基于缓存机制的方法并不能减少或消除冲突交易,存在着因冲突交易不断积压而引起的平均时延非常大的问题。基于重排序机制的方法通过在排序阶段调整待处理区块中的交易顺序,使其在验证阶段能够避免部分交易发生版本冲突,提高有效交易数量。但是,仍存在一些从语义的角度可以转化为合法的冲突交易在重排序机制中被提前中止,使得区块中依然有大量交易被标记为无效。
实现思路