一种面向以链治链的业务链交易监管方法

本发明涉及区块链技术与应用、大数据环境下政府信息化管理领域，具体应用于面向金融、通信、能源、物流等行业的区块链应用监管领域。

背景技术：

1、区块链起源于比特币，是一种新型分布式账本技术。区块链账本由顺序增长的区块通过哈希方式链接而成，并利用密码学技术保证账本不可篡改。每个区块链上的节点都保存了一份账本的副本。区块链通过共识算法保证所有节点之间账本的一致性。联盟链(consortiumblockchain)是一种新的区块链技术，利用ca确认参与者身份，使用基于密码学的背书策略验证交易，从而提升了区块链的吞吐量。近年来，区块链技术受到越来越多的关注，并得到广泛的应用。利用区块链账本分布式存储、不可篡改等特性，将其与实体行业相结合，已成为当今发展趋势。

2、然而，区块链的广泛应用带来了监管难题。传统中心化的监管模式不仅破坏了区块链去中心化的特性，还无法满足各行业内对业务链的多方监管的需求。近年来，一些研究者认为区块链本身去中心化、数据不可篡改、服务公开可验证的优点有利于实现对大规模业务链的监管，并提出了“以链治链”的概念。多个监管机构通过共同部署一条监管链，实现对行业内多条业务链的监管。监管链上的节点不仅能够巡查业务链上的数据，还能够验证业务链已经完成的交易。

3、“以链治链”的构想满足了行业内多方监管的需求，提供了公开可验证的监管服务。然而，业务链数量的增加为监管链长期高效的运行提出了挑战。分片是提高区块链可扩展性的关键技术，但已有研究工作大都关注于公链上的交易吞吐量提升，因此移植到监管链上存在两大技术难题。首先，业务链之间相互独立，易造成监管链上数据分片的冲突与不均问题。在基于公链的分片方案中，数据按照输入的地址前缀被分配到不同的分片中。由于地址是随机生成的，因此上述做法能够避免冲突并实现分片间的数据平衡。然而，在跨链监管的场景下，来源于不同业务链的数据有独立的命名空间，大幅提升了监管链上数据存储冲突的可能性，也容易造成监管链上的数据分片不均衡的问题。其次，在基于分片的监管链上验证跨分片交易存在困难。如果一笔交易的数据被存储在监管链的不同分片上，那么它的验证过程不仅需要突破分片的壁垒，还需要保证交易过程中每一步的正确性。一些学者提出部署一条公共链来实现跨分片交易验证，但这种做法会随着交易数量的增加而出现大幅地性能退化。此外，一些学者提出了基于utxo格式的交易拆分方法，但它们都是针对公链上的数字货币交易而设计的。在验证一笔utxo格式的交易之前，可以先确定交易所涉及的分片，再由相关分片中的节点完成验证过程。然而，业务链上的交易需要通过运行智能合约来验证。只有当智能合约运行到特定步骤才能确定交易所涉及的分片。因此，基于utxo格式的交易拆分方法不能应用于对业务链交易进行跨链监管的场景。

4、针对上述问题，本发明提出了一种面向“以链治链”的业务链交易监管方法。图1展示了基于分片的“以链治链”区块链跨链监管场景。通过基于分片的监管链构建、业务链数据上链和业务链交易验证，本方法解决了监管链在监管过程中面临的扩展性问题，推进了区块链应用监管的落地，促进了区块链行业健康有序地发展。

技术实现思路

1、本发明针对当前区块链跨链监管中存在的难题，深入分析相关监管技术与监管方案，在此基础上提出了面向“以链治链”的业务链交易监管方法。针对跨链监管过程中监管链可扩展性差的问题，提出采用分片技术对监管链进行优化。针对分片带来的数据存储冲突和分配不均的问题，提出在监管链上对所有来自业务链的数据进行统一标签。针对跨分片交易难验证的问题，提出将智能合约分解为子合约再顺序进行验证。本发明通过采用分片技术减少了在监管业务链交易过程中的计算、通信以及存储开销，提高了监管链的可扩展性；本发明使用基于智能合约的交易验证技术对分片内交易进行验证，通过分解智能合约实现了对跨分片交易的验证，从而在基于分片的监管链上实现了对业务链交易的监管功能。综上，本方法分为基于分片的监管链构建、业务链数据上链和业务链交易验证3个主要步骤。

2、s1：基于分片的监管链构建。为了满足对行业内多条业务链同时进行监管的需求，构建一条包含多个分片的监管链。具体过程可以分成以下3个步骤：监管链构建、监管链节点分片、设计监管应用与分片交互功能。

3、s11：监管链构建。在实现对业务链交易的跨链监管之前，需要构建一条监管链。本步骤完成监管组织、监管链节点与成员的身份构建，监管链网络的构建以及相关的初始化工作。具体过程可以分为以下6个步骤：

4、(1)构建监管组织的身份。监管链由多个监管组织共同构建。在构建监管链时，需要先为所有监管组织构建身份。首先，确定一个公认的证书颁发机构(ca)。然后，各监管组织在本地生成公私钥对，并向ca发送证书颁发请求。最后，ca完成各组织身份的注册，并为其颁发公钥证书。

5、(2)构建监管组织的ca。各监管组织利用步骤(1)中获得的证书，构建属于本组织的ca。

6、(3)构建监管链节点与监管成员的身份。首先，确定监管链节点或监管成员在监管组织内的所属部门和权限，并以域名的形式表示其身份。然后，监管链节点或监管成员在本地生成公私钥对并向所属组织的ca发送证书颁发请求。最后，所属监管组织的ca完成监管链节点或监管用户身份的注册，并为其颁发公钥证书。

7、(4)构建监管链网络。在所有监管链节点上配置监管链的网络信息，保证监管链节点之间的网络通信。

8、(5)启动监管链节点程序。利用步骤(3)获得的监管链节点证书信息，在独立的主机上启动监管链节点程序。

9、(6)生成初始区块。监管链节点创建监管链配置文件，生成监管链起始区块。

10、s12：监管链节点分片。本步骤完成对监管链节点的分片。具体过程分为以下6个步骤：

11、(1)确定监管链性能指标。根据监管链的业务需求，设计监管链吞吐量th，监管链处理交易的延迟d。

12、(2)确定分片内节点数量n。从1个节点开始，不断增加分片内节点数量，测试单个分片延迟指标d，在d不大于d的情况下选择最大的分片内节点数量作为n。

13、(3)确定分片数量m。测试单个分片的吞吐量指标th，选择分片数量

14、(4)划分监管链节点。首先，为监管链上的m个分片依次分配序号[0,m-1]。然后，对所有监管链节点统一分配序号。最后，根据节点序号的取模结果，将该节点划分入id与取模结果相同的分片中。

15、(5)创建分片初始区块。在每个分片中先选择一个节点生成分片配置信息，创建分片内区块链账本的初始区块。

16、(6)节点加入分片。根据步骤(4)的结果，节点复制对应分片的初始区块，广播自身加入分片的请求，最终加入分片。

17、s13：设计监管应用与区块链交互功能。完成监管应用、以及应用与监管链交互接口的定义。具体过程可分为以下6个步骤：

18、(1)设计监管链调用接口。设计监管链智能合约，根据监管者的不同需求提供通用的功能接口，并部署在监管链上。

19、(2)设计监管应用访问接口。按照监管功能，设计监管应用访问监管链接口，将步骤(1)中监管链提供的调用接口封装成监管应用的访问接口。

20、(3)监管应用配置监管链信息。为监管应用配置描述监管链的文件。文件内容包括监管链的节点信息、监管链的分片信息等。

21、(4)监管应用配置监管者信息。监管应用端为监管者创建监管账户，保存监管者的公钥证书等相关信息，用于登录监管链。

22、(5)连接监管应用与监管链。监管应用基于步骤(3)生成的配置文件和步骤(4)生成的监管账户，在本地生成连接不同分片的信息。

23、(6)测试监管应用的功能。监管者在监管应用上调用步骤(2)设计的访问接口，测试可用性。

24、s2：业务链数据上链。为实现监管链对业务链监管，需要将业务链数据保存在监管链上。具体过程分为以下3个步骤：获取业务链数据、生成统一数据标签和数据存储上链。

25、s21：获取业务链数据。监管链从业务链获取业务链账本中的交易数据。具体流程分为以下6个步骤：

26、(1)建立跨链通信连接。监管应用和业务链之间建立跨链通信连接，用于传输监管请求与响应信息。

27、(2)发送监管请求。监管者根据需求通过监管应用向目标业务链发送监管请求。监管请求包括监管者的公钥证书，被监管对象的身份标识以及请求监管的内容。

28、(3)业务链验证监管请求。业务链端在收到监管请求后，验证监管者的公钥证书，判断其是否具有所请求的监管权限。若监管者不具有相关权限，进入步骤(4)，否则，进入步骤(5)。

29、(4)业务链拒绝监管请求。如果监管者不具有访问权限，业务链向监管应用返回一条拒绝消息，表明无法为监管者提供相关业务链数据。

30、(5)业务链返回相关数据。业务链根据监管请求，查询账本中的相关数据，并封装成响应消息发送给监管链。

31、(6)监管应用接收业务链响应。监管应用从跨链通信连接中接收业务链返回的消息。若超时未接收到任何消息或接收到拒绝消息，则返回步骤(2)尝试重新发送监管请求；若收到业务链的响应消息，则进入步骤s22。

32、s22：生成统一数据标签。为了解决来自不同业务链数据在分片时存在存储冲突与分配不均的问题，在分片存储之前需要为所有来自业务链的数据生成统一标签。具体过程如算法1所示，分为10个步骤：

33、(1)解析业务链数据。首先，判断步骤s21中从业务链上获取的数据所属类型。将来自业务链的数据分为三类：交易、区块以及账户快照。然后，根据类型，确定数据在业务链上的索引，其中交易的索引为交易序号，区块的索引为区块高度，账户的索引为账户标识。最后，判断当前数据类型是否为区块或者交易。若是，则进入步骤(2)；否则，直接进入步骤(3)。

34、(2)计算交易或区块标签。将数据在业务链上的索引与业务链名称拼接成一个字符串s。将s作为哈希函数的输入，计算出标签l。结束后，直接进入步骤(8)。

35、(3)计算账户标签。对与账户快照类型的数据，计算账户标签，依次执行步骤(4)～(7)。

36、(4)确定保留位数k。设置变量k，k代表同一个账户的数据在标签中的公共位数。k的长度取决于分片的数量，要求2k≥m。

37、(5)计算账户公共标签。将账户的索引与业务链名称拼接成一个字符串s。将s作为哈希函数的输入，计算出账户的公共标签i。

38、(6)计算账户独有标签。将在步骤(5)中生成的字符串s与监管序号seq拼接为一个字符串s′。将s′作为哈希函数的输入，计算出结果t。

39、(7)生成账户标签。账户标签l由2部分构成。从步骤(6)的计算结果t中取前n-k个比特位，从步骤(5)的计算结果i中取后k个比特位。将两部分拼接成n位的账户标签l。

40、(8)检查数据标签是否存在。在监管链的账本上查询当前数据的标签l是否存在。若存在，进入步骤(9)；否则，直接进入步骤(10)。

41、(9)重新生成数据标签。首先，根据数据类型，重新生成标签。若为交易或区块，直接用相同的哈希函数对标签l再次哈希生成新的标签l；若为账户快照，用相同的哈希函数对标签l再次哈希生成新的标签l′，将l′的低k位重新设置为原l对应的低k位，得到新的标签l。最后，返回步骤(8)。

42、(10)绑定数据标签。将标签l与对应数据作为一个键值对，绑定在一起。

43、

44、s23：数据存储上链。在根据数据类型为其生成标签之后，需要将数据存储到监管链的不同的分片上。具体流程分为以下5个步骤：

45、(1)序列化业务链数据。监管应用将来自业务链的数据、数据在业务链上的索引、监管者标识和监管时间等必要信息合并后进行序列化，并将结果作为存储在监管链的值。

46、(2)确定数据索引。将步骤s22生成的数据标签l作为存储在监管链的键。

47、(3)计算目标分片索引。取标签l后k位，进行取模m运算，结果作为数据存储的目标分片索引。

48、(4)监管应用保存数据。监管应用调用在步骤s13封装的与监管链交互的方法，向监管链节点发起数据存储请求。

49、(5)监管链节点存储业务链数据。处于目标分片内的监管链节点对来自监管应用的数据存储请求达成共识，并将业务链数据保存到共同维护的账本上。

50、s3：业务链交易验证。为了在监管链上验证发生在业务链上交易的正确性，需要在监管链上执行业务链的智能合约。具体过程分成3个步骤：判断交易类型、分片内交易验证和跨分片交易验证。

51、s31：判断交易类型。为了选择交易验证方法，需要先判断交易类型。将交易分成分片内交易和跨分片交易。具体过程可以分为以下6个步骤：

52、(1)实现业务链账本操作方法。将业务链对其账本的操作方法在监管链上重新实现，以确保监管链节点对保存在监管链上的不同业务链数据都具有相应的操作能力。

53、(2)转换业务链智能合约。针对业务链上的智能合约，遍历其调用的操作方法，将其转化为步骤(1)中重新实现的监管链上的操作方法，并最终形成在监管链上可执行的智能合约。

54、(3)遍历检查智能合约。遍历步骤(2)生成的所有智能合约，顺序检查每个智能合约中的所有步骤，提取并顺序排列所有对监管链上业务链数据的相关操作。

55、(4)检查操作参数。针对一个智能合约，检查在步骤(3)中提取的所有操作的参数。判断每一个操作是否只涉及单个业务链账户。若是，则将对应账户添加到账户集合中；否则，直接进入步骤(6)。

56、(5)检查账户集合。如果步骤(4)生成的账户集合中包含多个业务链上的账户，则进入步骤(6)；否则，进入步骤(4)，检查下一个智能合约的操作参数。

57、(6)确定交易类型。如果一个智能合约的操作涉及多个业务链上的账户，那么将其对应的交易定为跨分片交易；否则，定义为分片内交易。

58、s32：分片内交易验证。监管应用确认一笔交易所属某一个分片后，该分片内的监管链节点需要对该笔交易进行验证。具体过程分为以下4个步骤：

59、(1)发起交易验证。监管应用向分片内的监管链节点发送交易请求。

60、(2)监管链节点验证交易。首先，监管链节点检查交易发起者身份，以验证合法性。然后，监管链节点在本地运行对应的智能合约以验证交易。最后，分片内的所有监管链节点根据本地的验证结果，对交易进行共识。如果达成共识，进入步骤(3)；否则，进入步骤(4)。

61、(3)监管链节点提交交易。当分片内的监管链节点对该笔交易成功执行达成共识后，将本地的交易及验证结果打包成区块，并存入区块链账本。

62、(4)监管链节点拒绝交易。若分片内的监管链节点发现交易错误，则广播交易错误结果。当分片内的监管链节点对该笔交易失败达成共识后，将失败交易打包成区块，并存入区块链账本。

63、s33：跨分片交易验证。监管应用确认一笔交易涉及多个分片后，所涉及分片内的所有监管链节点需要对该笔交易进行验证。具体过程分为智能合约分解与子合约顺序验证2个步骤：

64、(1)智能合约分解。为验证跨分片智能合约，需要先将整个智能合约分解成能够在单个分片内验证的子合约。算法2展示了智能合约的分解算法，具体过程分为以下6个步骤：

65、a)将一个智能合约分解为多个顺序的子合约。将每一次对业务链数据的操作都分解成一个独立子合约，并将这些子合约按照调用顺序排序。

66、b)创建一幅有向无环图(dag图)g，以及一个节点列表startlist。

67、c)顺序遍历每一个子合约，为其在图g中创建节点vi，并为其构建依赖的子合约集合c。通过检查输入参数，判断其它子合约是否应加入到当前子合约的集合c中。

68、d)如果经过步骤c)后节点vi所依赖的子合约集合c为空集，那么将节点vi加入到startlist中。

69、e)如果节点vi所依赖的子合约集合c非空，遍历c中的每一个节点vj，并在图g中添加对应的边<vj,vi>。

70、f)在为所有子合约创建完节点并标记依赖关系后，输出图g与节点列表startlist。

71、

72、

73、(2)子合约顺序验证。在完成对智能合约分解之后，对所有子合约进行顺序验证。具体过程如算法3所示，分为以下6个步骤：

74、a)为图g中的每个节点vi构建一个等待队列wi，包含vi依赖的所有节点。

75、b)遍历startlist中的所有节点，利用智能合约的输入参数完成这些节点对应子合约的验证。若一个子合约验证成功，那么将其对应节点从startlist中移除。若该合约对应的节点在其它节点的等待队列中，那么也将其从等待队列中移除。

76、c)startlist中的所有节点被移除后，遍历图g中的剩余节点。只有当节点vi的等待队列wi被清空后，节点vi才能开始对应子合约的验证。

77、d)若所有节点已从图g中移除，则所有子合约都完成验证。

78、e)当所有子合约的验证结果都为真时，将返回结果t设为真，并将响应字符串resp的内容设置与智能合约在业务链上的验证结果一致。

79、f)如果其中一个子合约验证失败，将返回结果t设为假，并将resp设为空字符串。

80、

81、