基于区块链数据协同访问控制策略的中间件设计与研究

胡 锦 玲

(广州城建职业学院，510925，广州)

1 问题提出

随着Hyperledger Fabric区块链系统涉及的技术多样且架构复杂[1]。区块链(BlockChain)是一种具有去信任、去中心化、不可篡改、公开透明等特性的新兴技术。在各个主流区块链技术中，Hyperledger Fabric由Linux Foundation于2015年发起[2]，Hyperledger Fabric 是分布式账本解决方案的平台，采用模块化架构，提供高安全性、弹性、灵活性和可扩展性。目前已有包括IBM、Intel、百度等各大互联网公司在内的200余个成员，着力于发展跨行业的企业级区块链的研究,也是时下火热的区块链技术之一[3]。Hyperledger Fabric不仅支持Java、Go、Node.js在内的常见的编程语言用于智能合约的开发，同时不需要使用基于加密货币的共识机制来激励昂贵的挖矿或智能合约的执行，从而大大降低了系统的运营成本。

在使用Hyperledger Fabric进行业务系统开发的过程中，不可避免地涉及到对链上数据的读取和搜索。但是，由于区块链的技术特性，对区块链的数据读取需要遍历整个区块链链条才能计算存储数据的当前状态。尽管Hyperledger Fabric通过内置了LevelDB、CouchDB等数据库存储WorldState的方式在一定程度上解决了区块链数据的读取问题[4-5]，但这种方式面对业务系统中高频且形式复杂的数据访问，在功能和性能上显然力有不逮。因此，在业务开发中通常还需要将链上数据同步写入第3方数据存储中，进而由其解决数据的读取和搜索问题。这就需要应用开发者来解决区块链及第3方数据存储间的数据一致性问题。

为了支持以同样的方式更新信息，并实现一整套账本功能(交易，查询等)，区块链使用智能合约来提供对账本的受控访问。本文旨在针对Hyperledger Fabric链上数据和第3方数据存储间的数据同步问题，设计并实现了Hyperledger Fabric数据协同中间件，确保两者间的安全数据同步，从而降低开发者的开发成本，提高开发效率。

2 数据存储分析

Hyperledger Fabric支持多链[6]。在Hyperledger Fabric中，数据存储一共包括4个部分：账本数据、状态数据库、历史记录数据库、区块索引数据库，如图1所示。其中，账本数据以二进制文件的形式保存了区块链上每个区块的具体数据。状态数据库则有LevelDB和CouchDB两种实现形式，用于存储账本中每个数据项的最新值，方便链码执行时快速调用。历史记录数据库需要通过配置项开启，开启后在LevelDB中保存数据项的版本变化，即哪些区块中的交易变更了数据项的值。区块索引数据库存储了区块文件的索引指针，以便快速找到对应的区块文件。

图1 Hyperledger Fabric数据存储示意图

Hyperledger Fabric的这些设计很好地满足了数据的简单读写需求，但对于实际应用中形式更加复杂的数据搜索条件则力有不逮。在很多现实场景中，用户需要对数据进行更复杂的数据分析，例如在电子存证场景中，用户可能希望以上传用户和上传时间为搜索条件对存证进行搜索。而基于KV数据库设计的状态数据存储显然难以应对这种关系型数据库擅长处理的查询请求。而在一些情况下，应用系统还可能需要区块链上的数据来生产数据报表或进行大数据分析，而需要将区块链数据同步到HBase和Hive这样擅长处理海量数据的存储中。因此，出于应用系统运行过程中高频且形式复杂的数据读取搜索和数据分析的需要，开发中通常需要将区块链中存储的数据同步到第3方存储中，通过第3方存储来实现复杂的数据搜索需求，并提高系统性能。在这种情况下，如何保证两者间数据同步过程中的数据一致性是需要重点解决的问题。为了解决这个问题，本文设计并实现了可插拔的Hyperledger Fabric数据协同中间件，以保证Hyperledger Fabric区块链与第3方存储间的安全数据同步。

3 数据同步访问控制流程设计

通常用户对Hyperledger Fabric联盟链中的数据修改通过调用链码提交交易的方式实现。而用户发出的交易提案首先需要发送到Peer节点，由Peer节点调用链码并对该提案背书，进而提交到排序节点，再经由排序节点验证和排序后才能成功写入区块并下发给Peer节点，最后由Peer节点验证并写入各自持有的账本[4]。从用户提交交易提案到数据写入账本的调用链路漫长，如果同步等待区块链的链码调用结果则会因为漫长的交易提交过程占用大量系统资源。同时，数据上链的过程中还有因为网络波动或交易冲突等多种原因失败的风险，在客户端发出交易提案的同时直接将数据写入第3方存储可能导致数据上链失败却在第3方存储中写入成功，因此还需要考虑数据上链失败条件下的数据回滚或重试机制，逻辑将变得臃肿而复杂。

相比之下，选择异步的将已经确认写入Hyperledger Fabric账本中的数据同步到第3方存储，则可以节省大量因同步等待而消耗的资源，逻辑也更加简单直接。在Hyperledger Fabric联盟链中，提供了基于通道的Peer节点事件服务，在应用程序在对应通道注册监听器后，每当通道中有新区块产生，该服务都会发送一个事件到监听应用程序中，事件中以envelope的形式包含了具体的区块消息。

因此，在具体实现上，数据协同中间件选择通过监听Hyperledger Fabric区块链网络中Peer节点广播的新增区块消息的方式来异步获取新增区块的数据，进而分析区块中打包的交易及读写集数据。最后，使用消息队列将交易对账本数据的更新通知到第3方存储。在这个过程中，仍需要考虑由于网络的不确定性和系统的偶然崩溃等意外导致的数据缺失或数据重复的情况，并考虑对应的手段来确保数据的一致性和消息的幂等性。在此基础上，数据协同中间件的同步工作流程见图2。

图2 数据同步访问控制流程图

4 数据一致性问题解决

实现数据协同访问控制策略，从图2中可以看到，数据在由区块链同步到第3方存储的过程中，主要经过了2次数据传输。第1次是从Peer节点通过广播消息的方式，由区块链传输到数据协同中间件；第2次是由数据协同中间件交至消息队列，通知第3方存储写入数据。由于在每个系统内部可以通过单机事务的方式确保操作的原子性，因此这2次数据传输是最容易发生数据丢失风险的步骤。

经过分析，可能导致产生数据不一致风险的具体原因如下。

1)数据协同中间件监听区块链数据变更的方式是监听Peer节点发送的区块新增事件，如果由于网络波动或中间件服务器宕机等原因导致监听事件的丢失，将会导致数据不一致。

2)数据协同中间件收到区块链系统发出的消息后，通知第3方存储写入数据的消息丢失。

3)第3方存储数据写入成功后，数据协同中间件没有收到确认，重复发送消息导致数据重复写入。在数据协同中间件中，对于问题1)，使用了CheckPoint机制记录区块的处理进度，在发生消息丢失时自动要求Peer节点重发丢失消息；对于问题2)，数据协同中间件通过消息队列传递消息，并使用重试机制确保消息在传递过程中不会丢失；对于有问题3)，则需要第3方存储在收到消息后，通过本地消息表的方式来确保消息的幂等性。

4.1 基于CheckPoint数据协同处理工作流程

数据协同中间件通过监听Peer节点广播的事件消息的形式获取区块链中新增区块的具体信息，进而通过分析得到具体交易的读写集。在监听消息的过程中，可能由于消息丢失、处理异常等原因导致数据出现不一致。因此，数据协同中间件通过CheckPoint机制来确保不会遗漏处理消息，且在数据处理过程中即使发生崩溃异常也能保证数据一致。具体过程如下。

1)在监听到事件消息后，CheckPoint首先会对比收到消息中的区块高度和已同步的区块高度，确认是否存在遗漏的消息。如果存在则会通知Peer节点重发遗漏消息记录。

2)如果不存在遗漏消息，则会在数据库中保存新收到的消息，避免后续处理失败时反复要求Peer节点重放事件消息。在保存时会判断消息记录表中是否已经有相同区块高度且状态为待处理或处理成功的区块消息，如果有则保存失败，流程结束。CheckPoint保存区块消息的记录表结构见表1。

表1 CheckPoint区块消息记录表

3)如果区块消息记录成功，则解析消息的具体内容，得到区块中打包的所有交易及其读写集。

4)通过交易读写集获取数据变更项，通过消息队列发送给第3方存储。

5)消息如果发送成功则在记录表中更新其处理状态为处理成功；否则，重试发送消息。

4.2 消息幂等性保障

通过CheckPoint机制和消息队列，数据协同中间件能够保证将Hyperledger Fabric区块链中写入的数据以消息的形式安全地顺序交付给第3方存储。值得注意的是，为了确保发给第3方的消息不会丢失，数据协同中间件在消息队列中配置了重试机制，消息的接收方在成功消费消息后会自动发回一条Ack确认消息，如果生产者没有收到Ack消息，则会在设定的重试间隔后重新向消费者发送消息。

因此，第3方存储在成功消费消息并写入数据后，向消息队列发回的Ack确认消息也有可能因为网络波动原因丢失，从而导致触发重试机制，消息被重复消费。在这种情况下，需要由消息的消费者保证消息的消费幂等性。一个可行的保证消息消费幂等性的方法是通过一张额外的数据表记录消息的消费状态[7]，如果发现重复消息则不写入数据。由于消息队列中的消息ID可能发生重复，而在Hyperledger Fabric的场景下，每一笔交易都会拥有一个唯一的交易ID。因此可以通过交易ID标记消息是否已经被成功消费，避免数据的重复消费。记录消息消费状态的本地消息表结构见表2。

表2 本地消息表

5 实验测试与结果

部署数据协同中间件后，通过链码向Hyperledger Fabric区块链网络提交交易写入数据，中间件能够成功接收到Hyperledger Fabric发出的广播消息，并将数据写入第3方存储中。结果如图3所示。

图3 数据同步效果图

随后断开数据协同中间件到Hyperledger Fabric网络的连接，并继续向Hyperledger Fabric提交交易，模拟广播消息遗失的情况。在恢复网络连接后，可以看到中间件在收到新的区块广播消息时，会自动向Hyperledger Fabric请求遗失的消息，如图4。

图4 遗失消息效果图

6 结论

本文从区块链数据协同访问控制策略的中间件设计与研究，分析了Hyperledger Fabric中数据存储的形式，在此基础上设计并实现了Hyperledger Fabric数据协同中间件，实现了Hyperledger Fabric和第3方存储间的自动化数据同步，提高开发效率。在此基础上，通过CheckPoint

机制避免遗漏广播消息导致的数据丢失，通过本地消息表避免数据的重复写入，有效地确保两者间的数据一致性。