CN113850599A

CN113850599A - 一种应用于联盟链的跨链交易方法及***

Info

Publication number: CN113850599A
Application number: CN202111445431.5A
Authority: CN
Inventors: 石宁; 吴怀江
Original assignee: Nanjing Jinninghui Technology Co ltd
Current assignee: Nanjing Jinninghui Technology Co ltd
Priority date: 2021-12-01
Filing date: 2021-12-01
Publication date: 2021-12-28
Anticipated expiration: 2041-12-01
Also published as: CN113850599B

Abstract

本申请公开了一种应用于联盟链的跨链交易方法及***，包括证书秘钥组件根据客户端发送的账户注册请求建立跨链账户；跨链中间件根据身份信息、跨链账户以及交易数额构建跨链请求，并调用所述跨链账户对所述跨链请求进行签名；跨链中间件将带有签名的跨链请求分别发送至源节点和目标节点；源节点和目标节点分别对所述跨链请求进行校验，生成跨链交易证明；跨链中间件对源节点和目标节点反馈的跨链交易证明进行校核，得到校核结果反馈至客户端；本申请通过引入跨链中间件来完成不同链之间的消息交互、交易的有效性验证以及交易核对工作，通过引入证书秘钥管理组件来有效保证跨链交易所属方的隐私以及权限问题。

Description

一种应用于联盟链的跨链交易方法及***

技术领域

本发明涉及数据交易技术领域，特别涉及一种应用于联盟链的跨链交易方法及***。

背景技术

区块链作为一种分布式的公共记账***，具有数据不可伪造、可追溯、防篡改以及数据隔离等多种特性。目前业界的区块链产品（联盟链）分布于多种不同的行业中，对于某个特定的区块链产品来说，单链的容量总是有限的，加之区块链的处理能力有限，就要求某些业务中需要进行链间的横向扩容。因此，势必要实现不同结构链间的互联互通。然而，由于不同结构链之间的区块结构等机制存在很大不同，往往实现跨链交易比较复杂。

目前的联盟链跨链技术中，一部分是同构链之间的跨链，此类技术往往对链的结构有特殊的要求，比如需要开发一个特定的跨链引擎，来专门进行跨链交易的验证和执行。这种方式的局限性比较大，对于现有的链来说，进行链结构的改造困难性较高。还有一部分是异构链之间跨链，此类技术主要使用了公证人模式、中继链以及哈希锁定的一种或者几种的结合。现有方案在实施过程中存在复杂度较高的情况，而且在实际应用中也存在一定的弊端。例如：公证人模式虽然通过第三方信任机构执行跨链消息的转发和验证，可以支持异构的区块链跨链，但是，第三方机构仍具有中心化风险，且仅能实现交互而并不能实现转移；而中继链是利用侧链技术来完成不同链间的资产交换，由于侧链直接锚定主链，可以满足去中心化的要求，但是，由于侧链的加入，必须要对主链的协议相应进行定制化的改造，使其兼容侧链，这样的主链不具有通用性，应用范围较窄；此外，哈希锁定是利用哈希锁定合约HTLC实现的，利用哈希锁和时间锁进行区块链上等值资产的交换，同样不能实现资产的跨链流转。

发明内容

本申请提供了一种应用于联盟链的跨链交易方法及***，以解决现有技术中实现跨链的复杂度较高的问题，并且不需要对链的结构做任何修改，不对交易参与方数量做约束。

第一方面，本申请提供了一种应用于联盟链的跨链交易方法，包括：

根据客户端发送的账户注册请求建立跨链账户；所述账户注册请求包括至少一个源节点和至少一个目标节点的身份信息及数字证书；

跨链中间件根据所述身份信息、跨链账户以及交易数额构建跨链请求，并调用所述跨链账户对所述跨链请求进行签名；

跨链中间件将带有签名的跨链请求分别发送至源节点和目标节点；

源节点和目标节点分别对所述跨链请求进行校验，若校验通过，则按照所述跨链请求执行跨链交易，生成跨链交易证明；

跨链中间件对源节点和目标节点反馈的跨链交易证明进行校核，得到校核结果反馈至客户端。

在一些实施例中，所述跨链请求包括跨链交易序列号，源节点和目标节点分别对所述跨链请求进行校验的步骤包括：

提取所述跨链请求中的签名，验证签名是否合法；

若是，则判断所述跨链交易序列号与客户端账户交易序列字段是否一致，若是则校验通过；

当每执行一次跨链交易后，所述客户端账户交易序列字段加1。

在一些实施例中，所述跨链账户根据配置的证书密钥组件提供证书密钥的托管服务，所述跨链中间件调用跨链账户对跨链请求进行签名的步骤包括：

权限模块验证跨链请求中的用户签名，若验证成功，则向跨链账户发起签名指令；

跨链账户根据签名指令，调取存储在证书托管模块中对应的源节点和目标节点的数字证书以及密钥对跨链请求进行签名。

在一些实施例中，所述跨链交易证明包括交易执行所在链标识以及跨链交易哈希值；跨链中间件对源节点和目标节点反馈的跨链交易证明进行校核的步骤包括：

根据交易执行所在链标识，调用跨链账户中链绑定的私钥对跨链交易哈希值进行校验，得到校验结果；

根据跨链交易内容重新计算交易哈希值，得到校验哈希值，比对校验哈希值和跨链交易哈希值是否一致。

在一些实施例中，跨链中间件对源节点和目标节点反馈的跨链交易证明进行校核的步骤还包括：

核算源节点和目标节点反馈的跨链交易证明中，前后交易总额是否相等，以及，交易变化量的和是否为零。

在一些实施例中，所述方法还包括：

若跨链中间件在预设时间内未收到源节点或目标节点反馈的跨链交易证明，则将交易失败的信息加入到跨链请求中并反馈至客户端；

跨链中间件构建下一个跨链请求时，采用与上一个跨链请求相同的跨链交易序列号。

在一些实施例中，跨链中间件将带有签名的跨链请求分别发送至源节点和目标节点之前，所述方法还包括：

跨链中间件获取源节点和目标节点所在链的其它节点对所述跨链请求的投票结果；

若所述投票结果满足预设规则，则继续执行将带有签名的跨链请求分别发送至源节点和目标节点的步骤。

在一些实施例中，跨链中间件将带有签名的跨链请求分别发送至源节点和目标节点包括：

跨链中间件将带有签名的跨链请求发送至联盟链中任意一个节点；

以收到跨链请求的节点作为参考节点，查询参考节点所在链中是否存在源节点或目标节点，若是则将跨链请求由参考节点发送至源节点或目标节点；

若否，则将参考节点所在链内其它任意节点作为新的参考节点；

查询新的参考节点所在链中是否存在源节点或目标节点；

当新的参考节点为收到过跨链请求的节点，或者查询次数超过预设阈值时，停止查询，并生成交易失败信息反馈至客户端。

在一些实施例中，所述预设规则包括：

所有节点的投票结果为同意，或者，超过第一百分数的节点的投票结果为同意，和/或，所在链管理节点的投票结果为同意。

第二方面，本申请还提供了一种应用于联盟链的跨链交易***，包括客户端、跨链中间件、位于不同链的源节点和目标节点、以及证书密钥管理组件；所述密钥管理组件包括权限模块、跨链账户以及证书托管模块；所述***被配置为执行第一方面所述的方法。

本申请提供的方法和***具有下列有益效果：

一、本申请提出的跨链交易模型基于公证人模式，而公证人只需要进行交易的跨链请求构造、发送以及交易的核算即可，极大降低其工作复杂度；

二、通过引入秘钥管理和跨链账户，解决了跨链交易双方的隐私及权限问题，任何操作只有双方同意才可以进行，用户自己的秘钥不用暴露给对方；

三、通过设计跨链交易序列号保证跨链交易不会重复执行；

四、需要进行权限管理时，可以通过新增通道跨链策略来实现细粒度管理；

五、在特定场景下，可配置路径搜索算法来保证跨链交易顺利进行。

附图说明

为了更清楚地说明本申请的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请提供的一种应用于联盟链的跨链交易方法执行跨链交易的调用时序图；

图2为本申请提供的一种应用于联盟链的跨链交易方法的流程图；

图3为本申请提供的另一种应用于联盟链的跨链交易方法执行跨链交易的调用时序图；

图4为本申请方法所采用的证书秘钥管理组件结构及调用示意图；

图5为本申请方法所采用的另一种证书秘钥管理组件结构及调用示意图；

图6为一种实施例下转移跨链请求至节点的示意图。

具体实施方式

在执行本申请提供的方法前，需要建立跨通道资产交换模型，即，本申请的方法是基于特定的模型来完成的，下面先对建立的模型进行说明。

参见图1，为本申请提供的一种应用于联盟链的跨链交易方法执行跨链交易的调用时序图；

由图1可知，在本申请所建立的模型主要由客户端（用户所在端）、跨链中间件、位于不同链（A/B）的任意节点（交易节点），以及跨链账户构成；其中，跨链中间件主要负责根据用户的需求构建跨链请求，以及，调用跨链账户为跨链请求签名，并将签名后的跨链请求发送至交易的双方，接收到请求的节点在验证请求通过后，分别执行交易，再向跨链中间件反馈交易执行结果，在跨链中间件完成对交易执行结果的校核后，交易完成，并向用户反馈交易成功的信息。

参见图2，为本申请提供的一种应用于联盟链的跨链交易方法的流程图；

由图2可知，本申请提供的方法包括：

S100：根据客户端发送的账户注册请求建立跨链账户；所述账户注册请求包括至少一个源节点和至少一个目标节点的身份信息及数字证书；

在本实施例中，对于一次跨链交易来说，通常交易的双方是指位于两条不同链上的节点，这里为了区分，分别将两个节点定义为源节点和目标节点，应当认为，一次交易的交易并非仅是由两方，还可能涉及多方，例如用户A将一笔资金同时转给用户B和用户C，或者用户A和用户B同时将资金转给用户C等，本申请不仅适用于一对一的交易，还适用于一对多、多对一以及多对多的交易（例如图3所示的调用时序图就是基于三方的交易）。这两种节点是属于不同机构所有的，为了保证链间的数据隔离不被破坏，不能将两个节点的秘钥和数字证书交给同一个实体，而应该每次操作都需要获得跨链双方（多方）的授权。

因此，本申请通过建立跨链账户来管理交易双方节点的秘钥和数字证书。需要说明的是，在本申请中的跨链账户并非第三方平台，其与现有技术的区别在于，本发明是通过一个专门的证书秘钥管理组件进行证书秘钥的托管服务的，具体的，由图4可示出本实施例中跨链账户管理秘钥、证书的过程；

例如，不在同一链上的用户A和用户B想要进行一个跨链的转账交易，则用户A或用户B可以通过客户端发送一个账户注册请求来申请注册一个跨链账户，在注册时，账户注册请求应当包括用户A和用户B的身份信息以及数字证书（用户可以自行加密成密文形式，自己保留解密的私钥），这里的身份信息和数字证书可以是由注册的一方进行线下的收集，当跨链账户注册成功后，用户A或用户B可将自己的私钥托管到该跨链账户对应的证书托管模块中，该跨链账户通过关联两个节点的证书和秘钥；当有人需要调用跨链账户进行跨链交易的签名时，首先需要权限模块验证用户的签名，当验证成功后才能通过跨链中间件去调用跨链账户，对跨链请求进行签名操作。相对应的，当涉及三个交易方时，跨链账户管理秘钥、证书的过程可由图5所示出，过程可参照上述说明，在此不再赘述。

S200：跨链中间件根据所述身份信息、跨链账户以及交易数额构建跨链请求，并调用所述跨链账户对所述跨链请求进行签名；

在本实施例中，对于跨链请求可采用多种范式来构建，例如，可采用下表中的范式结构：

上述范式结构的跨链请求可以清楚表述出具体含义：通道1（节点1）的001账户向通道2（节点2）的002账户转账10，交易序号为1。001账户和002账户可以不同，只要保证资金数额相等即可。

进一步的，上述交易范式不限于两方交易，也兼容三方以及以上的多方交易，其中跨链操作的转出链和转出链可以为多个。三方交易的一个示例范式如下：

上述范式结构的跨链请求可以清楚表述出具体含义：由通道1（节点1）的账户001和通道3（节点3）的账户003向通道2（节点2）的账户002进行转账，转账数额分别为2和8,交易序号为2。

类似的，该范式可以表达多个跨链转入方以及多个跨链转出方同时参与跨链操作的场景，但是需要注意的是，涉及的跨链参与方越多，跨链操作的效率越低，跨链交易的失败率也会增加。

进一步的，由于跨链账户的设置，当对跨链请求进行签名时，跨链账户要根据配置的证书密钥组件提供证书密钥的托管服务，上述步骤S200具体包括：

S300：跨链中间件将带有签名的跨链请求分别发送至源节点和目标节点；

在本实施例中，跨链中间件可以是通过跨链请求迅速定位到源节点和目标节点的位置，并将跨栏请求直接发送到对应节点，在一些其它实施例中，还可以有其它的方式传递跨链请求，下面介绍一种另外的传递方式，由图6所示，本申请提出了一种路径搜索算法，使得在传递跨栏请求时，无需关注跨链请求是否能直达源节点或目标节点，而是先发送至任意一个节点，再利用节点搜索至源节点或目标节点，相应的，具体方法包括：

跨链中间件将带有签名的跨链请求发送至联盟链中任意一个节点；由图6举例，图中有三个通道，每个通道都包含了多个节点，同一个节点也可以加入多个通道。为了直观清晰的标识通道和节点之间的关系。我们可以使用集合来进行表示。通道n->{node(i)} (n为通道标识号，i为节点标识号，使用正整数来进行表示)。按照这种表示方法，图6中的通道关系可以表示为：通道1->{节点A，节点B，节点C}，通道2->{节点B，节点C，节点D}，通道3->{节点D，节点E、节点F}。

假设用户向通道1中的节点A发送了跨链读取交易，读取的通道为通道3中的节点E，但是在交易体中没有指定E节点的peerUrl，那么节点A接收到交易之后，可以通过下列方式去搜索到节点E。

以收到跨链请求的节点作为参考节点，查询参考节点所在链中是否存在源节点或目标节点，若是则将跨链请求由参考节点发送至源节点或目标节点；即，查询节点A所在通道的所有节点，是否有节点E，如果有则返回数据，如果没有则将节点A加入的所有通道中的节点放入到邻居集合中，记为neighbour11：{节点B，节点C}；

查询新的参考节点所在链中是否存在源节点或目标节点；将neighbour1中的节点集合作为搜索起点，按照同样的方法去查找neighbour11集合中的每个节点的neighbour。这样，当以节点D为参考节点时，就能够查询到位于同一链上的节点E，就可以将跨链请求转至节点E中。

然而，可能最终的目的节点E距离节点A相隔了数个链，如果一直按上述方法查询，将使得跨链交易确认时间变长，所以，要设定一定的规则来简化确认时长、或者避免发送到对节点不存在通往跨链目标通道的路径，可以设置为：

当新的参考节点为收到过跨链请求的节点，或者查询次数超过预设阈值（例如超过5个链）时，可以认为无法查询到节点，可停止查询，并生成交易失败信息反馈至客户端。

S400：源节点和目标节点分别对所述跨链请求进行校验，若校验通过，则按照所述跨链请求执行跨链交易，生成跨链交易证明；

进一步的，在上述实施例中，所述跨链请求可以包括跨链交易序列号，在源节点和目标节点分别对所述跨链请求进行校验时，可以先验证跨链交易序列号Serial num，如果验证失败则可直接拒绝请求，具体的步骤S400包括：

提取所述跨链请求中的签名，验证签名是否合法；

若是，则判断所述跨链交易序列号Serial num与客户端账户交易序列accountnounce字段是否一致，若是则校验通过；

这里的具体过程为：客户端在发起交易的时候，在客户端有一个account nounce字段，用来记录发起交易的总数，初始值为1。在跨链中间件构建跨链交易的时候，会将交易的序列号作为交易的一个字段，记录在跨链交易中。当链接收到交易的时候，首先校验签名，然后会校验交易中的序列号是否和客户端的一致。由于客户端的nounce增加是原子性的，每次都加1，这就保证了，跨链交易同一个交易序列号的交易只能被处理一次，从而防范了重放攻击。客户端加1的操作应该在完成整个跨链交易之后，即客户端收到交易成功的通知。

在步骤S400中，除了上述对跨链交易序列号的校验，还可包括对身份信息、数字证书等真实性的验证，在此不予限定多种校验方式，应当认为，必须满足所有校验后，才能执行跨链交易；跨链交易证明用于记录交易过程数据、以及标识执行交易的时间、执行者身份等信息的数据，因此跨链交易证明可以是一个包含多种数据的数据包，必要时还要带有时间戳，保证数据的唯一性及可追溯性。

在本实施例中，跨链交易证明的范式结构可以采用下表中的格式设置：

S500：跨链中间件对源节点和目标节点反馈的跨链交易证明进行校核，得到校核结果反馈至客户端。

在本实施例中，步骤S500中的校核具有两部分含义，一是对跨链交易证明包括交易执行所在链标识以及跨链交易哈希值进行校核，校核方法为：

除了对所在链标识以及跨链交易哈希值的真实性校核，另一部分是对交易前后数据的校核，具体为：

具体核算过程如下表所示，需要核算：

sum(old value) = sum(new value)；

change(channel 1) + change(channel 2) = 0；

change(channel 1) = cct transaction(quota)；

类似的，如果是三方交易，可以核算如下

需要说明的是，在以上技术方案中，均是校验、校核通过时的方法步骤，但实际应用场景下存在不通过的情况，对于校验、校核不通过的情况，通常是以交易失败，向用户反馈失败信息作为处理方式，在一些特定场景，还需要设置对应的处理方案，例如：本申请的方法还可以包括：

若跨链中间件在预设时间内未收到源节点或目标节点反馈的跨链交易证明，则将交易失败的信息加入到跨链请求中并反馈至客户端；这里考虑的情况是，当跨链中间件未收到任何一方反馈的跨链交易证明，或者在预设时间内仅收到其中一方的跨链交易证明时，应当认为至少一方没有执行交易或无法执行交易，这时就需要判定交易失败或默认为是提交失败。

在交易失败的情况下，跨链中间件构建下一个跨链请求时，采用与上一个跨链请求相同的跨链交易序列号，即，客户端会重新使用上一个serial num构造一条新的跨链交易，并且需要在构建的跨链请求中，将reset一项的字段由false改为true，重新发送给相应节点。节点在接收到该跨链交易请求时，如果本地已经提交了同一个serial num的交易，则会首先执行撤销的操作，再重新执行收到的新交易。如果没有找到同一个serial num的交易，则直接按步骤S400执行该交易即可。

由上述技术方案可知，本申请提供的方法可以实现跨链的交易，并且，相对于现有的公证人模式，本申请的方法流程更为简单，同时，由于跨链账户的设置考虑了密钥证书的管理隐私问题，可以保证跨链交易在安全隐私的环境下顺利执行。

在上述实施例中，并没有对提出跨链请求的权限进行规定，在实际应用中，由于区块链作为一种去中心化的公共账本，在执行跨链操作时也应该由参与方或所在链各节点共同授权（或经共识）才是合理的，因此，在一些实施例中，本申请的方法还包括下列步骤：

在跨链中间件将带有签名的跨链请求分别发送至源节点和目标节点之前，所述方法还包括：

其中，所述预设规则可以设置为：

具体的，可以在通道的基本参数中新增两个基本参数，分别为跨链读取策略以及跨链写入策略。策略的内容可以用元组表示如下：

（“ALL_AGREE”,“MOST_AGREE”,“MANAGER_AGREE”）

策略说明如下：

ALL_AGREE:通道中的所有节点同意；

MOST_AGREE：通道中超过第一百分数的节点同意；第一百分数可以根据需求制定，例如超过2/3的节点同意，或者超过80%的节点同意等；

MANAGER_AGREE:通道管理员同意；

其内容也可以进行自定义，在跨链中间件发起跨链交易的时候，首先需要去收集每条链的参与方对该交易的投票集合，以满足投票策略，收集完投票之后，在进行上述步骤S200，同时节点在收到跨链交易的时候，首先需要进行策略检查，即检查收到跨链交易的投票数是否满足该通道的跨链读取策略，如果符合才按照模型的正常步骤往下进行，不符合则可以直接拒绝。

由上述技术方案可知，本申请提供了一种应用于联盟链的跨链交易方法，通过引入跨链客户端组件来完成不同链之间的消息交互、交易的有效性验证以及交易核对工作，同时使用事务来保证链间的数据交换的原子性，通过引入证书秘钥管理组件来有效保证跨链交易所属方的隐私以及权限问题。

对应于上述方法，本申请还提供了一种执行上述方法的应用于联盟链的跨链交易***，其特征在于，包括客户端、跨链中间件、位于不同链的源节点和目标节点、以及证书密钥管理组件；所述密钥管理组件包括权限模块、跨链账户以及证书托管模块。

上述***中在应用前述方法时的作用效果可参见前述方法实施例中的说明，在此不再赘述。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由本申请的权利要求指出。

Claims

1.一种应用于联盟链的跨链交易方法，其特征在于，所述方法包括：

2.根据权利要求1所述的一种应用于联盟链的跨链交易方法，其特征在于，所述跨链请求包括跨链交易序列号，源节点和目标节点分别对所述跨链请求进行校验的步骤包括：

提取所述跨链请求中的签名，验证签名是否合法；

3.根据权利要求1所述的一种应用于联盟链的跨链交易方法，其特征在于，所述跨链账户根据配置的证书密钥组件提供证书密钥的托管服务，所述跨链中间件调用跨链账户对跨链请求进行签名的步骤包括：

4.根据权利要求1所述的一种应用于联盟链的跨链交易方法，其特征在于，所述跨链交易证明包括交易执行所在链标识以及跨链交易哈希值；跨链中间件对源节点和目标节点反馈的跨链交易证明进行校核的步骤包括：

5.根据权利要求4所述的一种应用于联盟链的跨链交易方法，其特征在于，跨链中间件对源节点和目标节点反馈的跨链交易证明进行校核的步骤还包括：

6.根据权利要求2所述的一种应用于联盟链的跨链交易方法，其特征在于，所述方法还包括：

7.根据权利要求1所述的一种应用于联盟链的跨链交易方法，其特征在于，跨链中间件将带有签名的跨链请求分别发送至源节点和目标节点之前，所述方法还包括：

8.根据权利要求1所述的一种应用于联盟链的跨链交易方法，其特征在于，跨链中间件将带有签名的跨链请求分别发送至源节点和目标节点包括：

查询新的参考节点所在链中是否存在源节点或目标节点；

9.根据权利要求7所述的一种应用于联盟链的跨链交易方法，其特征在于，所述预设规则包括：

10.一种应用于联盟链的跨链数据交易***，其特征在于，包括客户端、跨链中间件、位于不同链的源节点和目标节点、以及证书密钥管理组件；所述密钥管理组件包括权限模块、跨链账户以及证书托管模块；所述***被配置为执行权利要求1至9中任意一项所述的方法。