基于中继链的联盟链跨链监管机制

陆艺仁，朱友文

南京航空航天大学 计算机科学与技术学院，南京211106

随着互联网技术的快速发展，区块链技术[1]凭借其链上数据不可伪造、不可虚构、不可篡改等优势，逐渐融入企业和个人的生活中，并且在物流溯源、去中心化交易所、政务系统等领域大放异彩。区块链从功能和规模上可以分为三类[2]，公链、私有链、联盟链。考虑到数据的隐私和安全，当前多数企业用户在部署业务时会选择使用联盟链。由于联盟链底层实现差距较大，无法形成有效的数据共享，从而形成一个个数据孤岛，这给联盟链的发展以及监管带来了很大的不便，也促进了跨链技术的发展。

跨链技术[3-4]是指实现区块链之间数据共享与互操作的技术，现有跨链协议大多数注重于链与链之间资产原子交换，且绝大多数基于公链，注重数据共享的联盟链跨链领域存在较大空白。

比特币是区块链的开始，引入智能合约后的以太坊则是区块链2.0的代表。起初智能合约只负责一些简单的链上存储与计算，随着区块链应用场景的不断丰富，业务场景越发复杂，链上计算的复杂度也随之上升，在DeFi[5]之类的金融应用中计算结果错误可能造成严重损失，因此对链上计算正确性监管的需求也日益增加。

目前现有的跨链技术研究多数是基于公链，联盟链跨链并没有比较完善的机制，也没有既定于跨链监管场景的框架。本文提出了一种基于中继链的链上计算跨链监管框架，实现了对链上计算正确性的监管，使用中继链技术保证了跨链过程可溯源与跨链结果不可篡改，通过给接入链划分身份保证了跨链可控，并且设计了一套用于跨链监管的通信协议以确保监管过程的安全性。具体贡献如下：

（1）针对跨链监管的场景，提出了一种基于中继链的联盟链跨链监管机制，采用中继链的跨链方式让跨链全过程中产生的信息上链存储，使得跨链操作可溯源。

（2）设计了一套用于进行链上计算监管的通信流程，实现对链上不同类别计算的监管与验证，保证了监管过程中的安全性。

（3）针对不同的计算资源和类型，制定了不同的Proof 以验证计算的正确性，验证计算的开销要小于原本被监管链上的计算，以线性规划计算为例示例了整体的监管流程。

1 相关研究

现有的跨链技术主要有公证人机制、中继（侧链）机制、哈希时间锁、分布式私钥控制等。

公证人机制是一种相对其他几种机制来说中心化较强的跨链机制，其使用中心化机构实现了可信第三方，这种模式虽然交易处理速度快，兼容性强，技术架构简单，但存在安全与信任问题，以及单点故障等缺陷。目前使用公证人机制实现跨链的最具有代表性的项目是瑞波（Ripple）的Interledger Protoco（lILP）[6]，ILP 协议允许两个不同的区块链系统通过第三方“连接器”来互相自由地转换货币。戴炳荣等[7]针对公信人节点的可信度问题，利用改进的PageRank 算法可以对公证人对可信度进行更好的评估；王洒洒等[8]使用椭圆曲线算法与零知识证明设计了一套用于跨链的身份认证系统，实现了跨链过程中的高效身份认证。

中继（侧链）是一种更为灵活的跨链方式，“中间人”仅仅充当数据收集者的角色，目标链收到发送链数据后由接收链自行验证，完成交易的确认，验证交易的方式由两者区块链系统结构决定。采用这种跨链机制的代表性协议有BTC-Relay[9]、Cosmos[10]、Polkadot[11]等。以BTC-Relay 为例，主要采用SPV（simplified payment verification）证明进行交易的验证，通过在以太坊上部署智能合约实现对BTC区块头的验证。Liu等[12]提出了一种异构区块链互操作框架HyperService，通过开发一种跨链专用的编程语言，实现异构区块链的互操作；叶少杰等[13]提出了一种通用的跨链协议，并实现了跨链平台BitXHub。

哈希时间锁是一种实现异链间资产交换的跨链技术，它要求交易的发起者和接收者在给定时间内给出正确哈希值才可取走锁定在合约内的资产。代表项目为闪电网络HTLC（hashed timelock contract）[14]。分布式私钥控制是将链上资产的所有权和使用权切割来降低跨链过程中中心化的风险，最著名的项目为Fusion[15]，一个为加密金融应用提供服务的基础平台。

尽管目前公链的跨链机制十分丰富，由于两者之间跨链的目标相差较大，联盟链更重要的是实现链与链之间的数据互通与合约互操作，现有公链跨链机制都难以在联盟链上有效应用。

现有的联盟链跨链框架有微众银行的WeCross[16]、陆羽跨链协议[17]等。WeCross框架实现了一个完整的身份系统以及统一的跨链消息与资产协议，缺点是接入链身份信息存储在中心化的服务器之中，安全性和可靠性得不到保障，跨链过程的请求无法进行保存和溯源，没有对接入链进行身份划分，导致跨链操作合法性无法得到保证。陆羽协议与之类似。佘维等[18]针对能源交易场景提出的跨链模型MCST-HEB可以实现分布式能源的有效互补，但无法实现合约之间的互相调用，并且使用场景较为局限。He等[19]针对共享充电桩评分场景，提出了一种基于多链的可信评分计算机制，但是同样存在跨链通信流程缺乏监管的问题。

2 跨链监管框架设计

为了打通链与链之间的通信，实现“以链治链”的联盟链治理与监管，本文提出了一种基于中继链的链上计算跨链监管框架。该框架一共由三层组成，每一层由数个关键组件组成，实现了整体框架的解耦合和模块化，为升级改造和落地应用提供了巨大的便利，整体架构如图1所示。

图1 跨链框架架构图Fig.1 Cross-chain framework architecture

2.1 统一资源层

由于不同联盟链之间的底层实现相差较大，为了实现跨链通信时消息格式的统一，在接入链上层抽象出统一资源层，对区块链底层结构进行抽象和封装，统一资源层并不关心具体联盟链内部的细节，包括共识算法、区块结构、加密算法等，接入链只需要通过跨链路由向中继链注册自己的身份信息和链上资源。联盟链中一般采用基于PBFT的共识算法；接入链中主要资源是智能合约，合约负责在链上根据不同的业务场景完成各种类型的计算，其数据来源主要是链上账本，并且在计算完成后将结果写入账本中；智能合约主要以虚拟化容器的形式隔离运行在区块链系统中。

2.2 跨链路由层

跨链路由层主要由接入链SDK（software development kit）、RPC（remote procedure call）组件以及密码学组件构成。接入链SDK 可以实现在接入链上部署监管合约、调用合约函数、读取账本数据等功能；RPC组件主要用于响应合约调用以及与中继链进行通信；密码学组件主要提供对称加密和公钥签名算法，实现消息的加解密以及身份认证。

接入链SDK 主要是接入链的任何语言的SDK，通过SDK可以实现对接入链的全局掌控，包括添加用户、部署合约、调用合约等。在跨链监管框架中，接入链SDK主要负责调用合约以及从合约账本中读取数据，通过与RPC 组件结合的方式提供了BaaS（blockchain as a service）功能。

RPC组件主要为跨链路由提供了RPC通信的功能，RPC组件中既包含了接收请求的RPC server，也包含发起请求的RPC client。在跨链监管框架中，RPC组件是监管过程中的核心部分，主要负责调用中继链的合约注册信息，以及实现链与链之间的数据传输。

密码学组件主要包含对称加密算法组件和公钥签名算法组件。为了确保监管过程的安全性，监管全程的通信会使用对称加密算法加密，每一轮监管过程的密钥都由中继链随机生成。公钥加密组件主要负责实现身份认证，跨链路由使用私钥对将要发送的消息进行签名，被监管链接收到请求后向中继链的身份合约申请公钥进行鉴权，判断监管链的身份是否合法。

2.3 中继链层

中继链层是跨链框架的关键层，也是跨链通信的主要实现层。中继链主要是由联盟链构成，拥有独立的共识算法，其主要组件有智能合约、RPC 组件以及密码学组件。

智能合约部分主要由身份信息合约与跨链记录合约组成。身份信息合约主要记录了接入链的身份信息，通过将接入链的身份信息上链存储，保证了身份信息的安全性。跨链记录合约主要保存跨链过程中发生的全部通信消息，通过将跨链信息上链存储，实现了监管过程可溯源。

RPC 组件为中继链提供了与接入链互联互通的能力，既可以接受来自跨链路由的请求，也可以通过发起RPC请求的方式进行请求的转发。

密码学组件主要用于生成密钥和解密消息，其中产生的对称加密密钥会发送给监管链与被监管链；非对称加密过程中会产生一个密钥对，其中私钥会发送给申请注册接入的联盟链，公钥则存放于身份信息合约中，用于对监管者身份进行鉴权。由于通信过程中消息都是经过对称加密后发送，在进行跨链请求时对溯源造成了影响，因此密码学组件会将消息解密后以明文的形式存入跨链记录合约中。

3 跨链监管通信流程设计

在链上计算时，业务中经常会出现一些较为复杂的运算，本章会示例监管链对目标链上计算结果正确性验证的全过程。这个过程分为4 个阶段，注册阶段、协商阶段、请求阶段、返回阶段。整体跨链网络拓扑如图2所示。

图2 跨链框架网络拓扑图Fig.2 Cross-chain framework network topology

3.1 注册阶段

为了实现跨链监管框架的可控性与安全性，任何接入跨链框架的区块链首先需要去中继链登记自己的身份信息。其中监管链需要注册的主要信息有跨链路由的RPC地址与端口号、接入链类别，即为监管链或被监管链。被监管链除了上述信息之外，需要额外向中继链注册当前链上的计算资源，最后中继链针对密码学组件会将生成的私钥Sk发送给请求链，公钥Pk则存入身份信息合约中。注册阶段整体流程如图3所示，消息结构如表1所示。

表1 注册消息结构Table 1 Registration message structure

图3 注册过程泳道图Fig.3 Registration process swimlane diagram

在注册过身份信息之后，为了避免监管给被监管链带来额外的计算开销，监管链会为特定的计算资源制定对应的监管合约，并且通过链下的方式部署监管合约至被监管链上。监管合约的主要作用是实现非侵入式的监管，不需要修改原本业务合约的代码逻辑。监管合约在收到监管请求后，会从链上读取计算时的参数和结果，并且针对不同的计算类型制作Proof，监管链可以利用Proof 快速验证被监管链链上计算的正确性，从而实现了对被监管链非侵入式的监管。

3.2 协商阶段

为了保障监管过程中通信的安全性，监管过程中的消息需要进行加密，因此在发起监管之前会有一次密钥协商阶段，在通信全程中会使用中继链生产的对称加密密钥k对消息进行对称加密，并且在每一次监管结束后上一轮对密钥都会销毁，保证了通信过程中的安全性。

3.3 请求阶段

请求阶段主要是由监管链发起，中继链接收到请求后，通过消息中的CID 进行链上查询获得对应通信地址后，调用RPC服务实现请求的转发。监管请求消息结构如表2所示，监管流程见图4。

表2 监管消息结构Table 2 Supervision message structure

图4 监管流程泳道图Fig.4 Supervision process swimlane diagram

（1）监管链管理员通过调用监管链中的监管合约发起一轮监管。监管合约中的RPC client 会将请求m发送至当前链的跨链路由中，请求中主要字段和含义如表2所示，跨链路由会对请求使用上一阶段申请的密钥k对请求进行加密后，使用RPC 组件发送密文Sm至中继链的RPC server中。

（2）中继链的RPC server在收到来自监管链的请求Sm之后，首先使用密钥k对消息进行解密并对请求链的身份进行鉴权，如果消息合法则将明文信息m存入跨链记录合约中。通过消息中的TCID，从身份信息合约中索引到被监管链的RPC 地址后，将加密后到消息Sm转发至目标跨链路由中。

（3）被监管链的RPC 组件在接收到监管请求后，首先对消息进行解密，被监管链跨链路由使用消息中的SCID 字段向中继链的身份信息合约发起请求从而获取对应监管链的公钥。最后使用公钥对消息中的Sign 字段进行签名验证。身份验证通过后调用监管合约，合约根据消息中的CalcType 字段，随机抽取对应计算类型的业务合约中的数条数据，并构造用于快速验证计算的Proof。

3.4 返回阶段

返回阶段主要是被监管链利用监管请求消息与账本数据封装完成返回消息之后，利用中继链将消息转发回监管链中，监管链对计算数据进行校验后产生结果并返回的过程。返回消息结构见表3。

表3 返回消息结构Table 3 Return message structure

被监管链跨链路由取出账本中的监管数据后构造返回消息，使用对称加密处理消息后通过RPC组件将请求发送至中继链。中继链解密消息将消息进行上链存储，同时将消息异步发送至监管链的跨链路由中。

监管链跨链路由接收并解密消息后会将消息中的Proof 字段取出作为参数调用监管合约，监管合约进行对应的验证计算后，将监管结果与监管数据上链存储。

如果验证过程中发现计算结果存在错误，则可通过中继链告知被监管链，此时被监管链的工作人员可通过监管过程发生的消息记录对链上数据进行排查与溯源。

3.5 示例

以线性规划计算为例，说明本文提出的联盟链上跨链监管框架。由于线性规划计算一般计算较为复杂，为了降低验证时计算开销，这里使用初始线性规划问题的对偶问题[20]对计算正确性进行快速验证。

假设线性规划的初始问题如式（1）所示。

通过转化初始问题，得到的对偶问题如式（2）所示。

在计算线性规划问题时，通常会引入松弛变量将问题转变为标准型后求解，初始问题与对偶问题的标准型如下：

被监管链计算初始问题时，在业务合约中通过索引取得业务账本中用户上传的数据，完成业务计算后调用监管合约，监管合约会将初始问题转化为对偶问题后求解，监管合约完成运算将初始问题的解组合为矩阵后上链，并且由于线性规划的向量组成的矩阵是稀疏矩阵，将结果压缩后上链存储可以减少账本的存储压力。最终监管合约账本中存储的解的结构如表4所示。

表4 业务合约存储结构Table 4 Business contract store structure

为了避免对线性规划计算的参数冗余存储，业务合约账本中只保存计算参数的数据对应的索引，在返回阶段跨链路由会根据索引获得真实数据后再发送至监管链。

监管链在获取到数据后，使用监管合约对计算进行验证。验证计算为：

最终结果为0 时，代表验证计算返回值为正确，否则认为验证不通过。

监管结束后监管合约会将本轮的监管结果写入账本中，监管账本中存储结构见表5。

表5 监管合约存储结构Table 5 Supervision contract storage structure

结论1如果被监管链线性规划运算计算错误，那么本方案可以通过监管链验证并得知该错误。

证明由于空间限制，本文只证明当线性规划问题有可行解的情况下通过对偶问题可以验证计算的正确性，无界/无可行解的情况与之类似。

假设被监管链上线性规划问题计算错误，即计算结果x1并非最优解，则存在不等式（5）：

由不等式（6）及其对偶性易知，当x和y为线性规划问题及其对偶问题的最优解时，必存在z和w严格相等。

被监管链上的监管合约计算结果无误，也就是y为对偶问题的最优解，则有不等式（7）：

这与z和w严格相等违背，可知x1并非原本线性规划问题的最优解，从而得知被监管链计算错误，完成了对结论1的证明。

4 方案对比和实验模拟

4.1 对比分析

现有跨链框架都无法应用于跨链监管的主要原因是跨链过程缺少权限控制，跨链监管场景应明确跨链数据流动的方向，监管链的权限应该高于被监管链，被监管链应无权调用监管链的合约，从而保证监管过程的安全性。本文方案在下文中统一简写为CCSF（cross-chain supervision framework）。

本文提出的基于中继链的跨链监管框架则较好地解决了上述问题，实现了接入链的权限管理，同时利用中继链去中心化的特性有效保证了身份信息与跨链记录的安全性，且实现了跨链记录可溯源。表6从功能与应用场景上对比了CCSF和现有的其他方案，可见CCSF在功能较为全面的同时可以良好地适用于跨链监管场景。

表6 方案对比Table 6 Scheme comparison

4.2 实验模拟

本文测试利用了三条联盟链构成了一套跨链计算监管系统，仿真使用的联盟链框架为Hyperledger Fabric 1.4，其中两条为被监管链，一条为中继链；RPC通信协议选择TCP 协议，调用参数编码方式选择JSON编码；用于进行线性规划运算的测试数据集来自于OR-Library[21]；测试指标为发起监管请求直至请求完成后监管结果更新结束的耗时。实验环境的机器配置如表7所示。

表7 测试机器配置表Table 7 Configuration of test machine

每条Fabric 区块链由3 个组织构成，每个组织拥有2个节点。其中RelayChain为中继链，主要负责转发跨链消息，存储跨链身份信息与记录跨链消息；TargetChain为被监管链，主要负责链上业务计算；Supervisor 为监管链，主要负责发起监管请求，并且将监管结果上链存储。具体区块链与合约信息如表8所示。

表8 测试区块链系统配置Table 8 Test blockchain system configuration

实验测试了在100次跨链监管过程中，每一步骤的平均耗时，如表9所示。

表9 跨链各步骤耗时Table 9 Time-consuming for each step in cross-chain

可以看到，RegistChain操作需要将身份信息写入链上，身份信息中公钥部分体积较大，因此耗时需要2 s左右；SendCrossChainMsg 是中继链收到消息后根据消息进行转发的过程，其中只涉及到链上数据的读取，因此是耗时最短的操作；GetPubKeybyId 用于接入链公钥查询，但是传输RSA 公钥耗时较高；GetCrossChainMsgTo是指监管链发出监管请求后直到被监管链收到请求的过程，由于过程中不涉及链上数据写入，因此耗时相对较短；GetCrossChainMsgBack记录的是从被监管链接收到监管请求后直到监管链完成监管的过程，其中包含耗时较多的读取计算数据，构造Proof以及验证Proof等几个步骤，因此耗时最长。

总体来说涉及到数据上链的操作耗时比仅读取链上数据长，这是因为Fabric需要为链上数据变更的交易产生区块并且更新世界状态，因此实验符合预期。为了保证跨链过程的安全性，消息签名主要使用RSA 算法进行签名，RSA 的密钥传输产生了大量的网络通信消耗，因此总体操作耗时较长。

本文同时将CCSF与WeCross以及BitXHub进行了对比，具体对比见图5，其中跨链路由配置指接入链配置跨链路由的步骤耗时；跨链注册是指向中继链注册当前区块链信息的耗时；跨链共享操作指从接入链发送一条消息到另一条接入链的耗时；跨链合约调用指接入链调用另一条接入链合约直到交易完成的耗时；跨链转账是指两条接入链之间的原子交易耗时，本质上是一种特殊的跨链合约调用。

图5 方案耗时对比图Fig.5 Scheme time-consuming comparison chart

可以看见CCSF 在保证了跨链过程更加安全可靠的同时，耗时对比WeCross除了注册阶段都有一定的提升，其主要原因是CCSF 采用的RPC 调用协议要快于WeCross的HTTP通信协议。注册阶段速度慢于WeCross的原因主要如下：WeCross 的身份信息采用单点Mysql数据库存储，虽说存储速度较快但是存在单点故障等安全性问题。CCSF将身份信息保存在去中心化的联盟链中，有效保证了身份信息的安全性，但会在联盟链中产生一笔交易，因此会发生世界状态的改变，从而导致了该步骤耗时明显高于WeCross。由于BitXHub会对跨链交易中的Merkle Path 进行验证，整体跨链耗时略高于CCSF。

5 典型攻击

传统跨链框架一般存在中间人攻击、跨链桥单点故障、越权跨链等风险，本文方案可以较好地抵御上述攻击：

（1）中间人攻击：在跨链网络中存在大量的跨链消息使用传统传输协议进行传输，因此存在中间人攻击的风险。本文方案通过给接入链分发签名证书，并且对跨链消息进行签名与加密，在跨链路由中对消息合法性进行验证，抵御了中间人对跨链请求篡改和重放等攻击手段。

（2）跨链桥单点故障：传统跨链网络中继器数量较少，存在单点故障的风险。本文方案中使用联盟链作为中继链进行跨链请求的鉴权与转发，因此具有区块链去中心化的优点，结点可以动态地加入与退出联盟链网络，因此不存在单点故障的风险。

（3）越权跨链：在跨链网络中存在越权攻击的风险，本文通过在中继链中部署合约对接入链进行权限划分，通过验证跨链消息中的身份信息字段保证了跨链请求的合法性，避免了非法跨链监管请求被执行。

6 总结与展望

本文提出了一种基于中继链的跨链监管框架，并且在跨链框架基础上，设计了一套用于执行跨链监管的通信协议，最后以监管链上线性规划计算为例，展示了通过跨链技术实现对联盟链链上计算进行监管的全流程。通过将身份信息使用联盟链存储，实现了身份信息的去中心化与不可篡改，保证了身份信息的安全性；将跨链过程中的消息记录上链存储，实现了跨链过程可溯源，为监管提供了便利；每一轮监管过程中使用对称加密，保证了通信过程的安全性。跨链路由可能存在单点故障等安全隐患，因此如何将跨链路由去中心化，减少跨链过程中的通信次数，让身份验证过程更加高效都是未来值得研究的问题。