正文

技术指南 | 一文读懂跨链网关的设计理念

趣链科技2020-05-28 02:42:45

跨链网关在跨链体系中，是一个对接具体类型区块链以及转发跨链消息的重要组成部分。它主要提供了应用链适配、跨链交易监听、跨链交易执行、跨链交易路由等核心功能。本文主要从跨链网关的架构、跨链交易流程以及应用链和跨链网关解耦方式等方面介绍跨链网关的设计理念。

一、整体架构

跨链网关的整体架构如下图所示：

考虑到不同场景下的跨链需求，跨链网关可以灵活支持两种跨链模式。一种是中继模式，也就是通过中继链来进行跨链操作，比较适合较多区块链进行跨链互操作的场景。另一种是直连模式，能够直接连接到其他跨链网关，进行跨链交易的传递，比较适合链对链的小型跨链系统。为了支持不同跨链模式之间的切换，跨链网关采用了如下分层的设计。

第一层是应用链层：该层负责和应用链及其智能合约进行交互逻辑，为上层的交互提供统一的交互接口。由于区块链的架构因链而异，为了让应用链适配和跨链网关能够解耦，达到便捷接入的效果，我们采用了插件机制。

第二层是交互层：这一层包含了如何提交IBTP包以及如何监听应用链上的跨链交易等具体逻辑。交互层处于跨链网关中的底层，包括执行模块和监听模块。交互层向上层模块屏蔽了跨链交易从应用链获取和提交的细节，提供了更精简的交互接口。

第三层是中继层：该层作为跨链网关中消息流转的中转调度层，从应用链上来的跨链消息和从其他区块链接收的跨链消息都统一通过该层进行相应的处理和路由。中继层主要能够屏蔽不同跨链模式下的复杂性，统一调用底层的模块。

二、跨链交易处理流程

在一个典型的跨链交易流程中，在应用链A上的用户发起了一笔发送到应用链B的跨链交易，应用链B上执行完成后返回回执到应用链A。以下按照整个流程的顺序详细介绍跨链网关在整个流程中的处理细节。

监听交易

跨链交易由用户发起，调用部署在应用链A上的跨链合约。跨链合约在收到跨链交易的请求后，抛出一个特定格式的跨链事件。由相应的应用链插件轮询或者订阅该跨链事件，并收集应用链A上对于该跨链事件的Proof信息（比如在Fabric中的背书信息），随IBTP包一起发送到跨链网关的监听模块上。

监听模块对于跨链交易做基本的检查操作（比如跨链交易序号的检查），检查通过的跨链交易才能提交到分发模块。如果跨链交易有问题，执行相应的的回滚操作。

分发交易

收到监听模块提交的跨链交易后，由于跨链网关支持不同的跨链模式，所以分发模块需要统筹负责跨链交易具体的传递对象。

在中继模式下，分发模块将跨链交易通过直接和中继链的代理模块发送跨链交易。在直连模式下，可以通过P2P网络连接到其他应用链的跨链网关（在示例流程中，应用链B的跨链网关）并发送相应的跨链交易。

同步交易

不同跨链模式下，同步交易的方式也不同。

在中继链模式下，跨链交易参与共识，并且打包进区块中。所以同步交易时候，需要中继链轻节点模块不断同步更新区块头信息。同步模块则是同步中继链区块中和自身跨链网关相关的所有跨链交易（应用链B的跨链网关同步和B相关的跨链交易）。对于中继链同步的交易，还需要配合轻节点对跨链交易进行SPV验证，确保跨链交易的有效性。

在直连模式下，跨链网关通过P2P网络接收跨链交易（应用链B的跨链网关接收应用A的跨链网关发送过来的跨链交易）。

检查交易

对于同步自其它链的跨链交易，都需要通过检查模块的检查才能交给分发模块进行下一步的处理。检查的逻辑和跨链的模式相关。

在中继模式下，跨链交易已经通过了中继链的验证引擎，并且参与过中继链的共识，所以检查模块只需要验证跨链交易确实来自于中继链即可。而在中继链上，对于通过共识的跨链交易，中继链节点会对其进行签名。检查模块对于附带的签名进行验证即可验证跨链交易的有效性。

在直连模式下，跨链交易是通过P2P网络获取的跨链交易，所以相比中继模式，检查模块需要承担更多的验证工作。主要需要检查的有应用链的注册检查，验证引擎的验证检查等。如果应用链需要定制化跨链交易的验证规则，后续可以通过更新验证规则的方式更加动态的进行。

执行交易

来自中继链或者其他跨链网关的跨链交易，通过检查模块的检查后，就可以提交到执行模块。执行模块直接和应用链插件对接，在调用跨链合约之前，需要检查序号以防止重放攻击。

提交交易之后，执行模块需要等待应用链上执行的结果，并将结果通过跨链回执的方式返回给分发模块，跨链回执的传递流程和跨链交易类似。执行模块要保证跨链交易提交到了应用链上，并且需要返回相应的回执信息。

三、插件机制

对于跨链场景来说，一个比较棘手的问题是不同架构的区块链的接入适配。为了简化不同区块链的适配问题，我们在跨链网关中采用了插件机制。跨链网关主要负责与中继链或者其他跨链网关的交互和通信。而所有具体在应用链上进行操作的部分全部封装到应用链插件中，并按照跨链网关和应用链交互的需求确定了一套适合跨链交互的插件接口。

这样对于跨链网关来说，对接任何新的类型的应用链的时候，都不需要修改自身，而是根据确定的接口开发一个新的应用链插件即可。

插件需要提供的接口主要分为以下四个主要部分：

1.提交交易接口

跨链网关提交IBTP包的接口。跨链网关和应用链插件交互的基础是IBTP：跨链网关向插件提交的IBTP包，得到的回执信息也是IBTP包。这样插件向跨链网关屏蔽了不同区块链交易结构不一致的复杂性，简化了跨链网关的设计。

应用链插件负责解析IBTP包，并转换为适配应用链提交交易的结构。同时也要对于得到的执行结果进行封装，同时从应用链获取对于改跨链交易的Proof信息。

2.查询跨链交易元信息接口

IBTP协议层面，协议能够感知的最小粒度是应用链。协议只能让跨链交易转发到IBTP包中目的链ID所对应的跨链网关。对于更细粒度的链上合约和用户账号地址等，在应用层中对IBTP的payload字段中自行解析和定义业务结构。

所以跨链合约需要记录的是自身应用链与其他链的最新交易序号信息（即为跨链交易的元信息），并且在执行跨链交易时更新这些元信息。因为这些元信息对于跨链网关重启恢复来说至关重要，所以插件需要提供一个能够查询这些元信息的接口。

3.查询历史交易信息

对于应用链抛出的跨链事件，可能会因为网络抖动或者跨链网关宕机等不可控原因，导致部分跨链事件没有及时收到。这种情况下，插件需要提供查询遗漏的跨链事件的接口，用于跨链网关恢复跨链网关处理跨链事件的顺序。

4.查询应用链基础信息

跨链网关对于使用应用链插件是无感知的，所以如果如果跨链网关需要获取应用链的基础信息（如应用链类型，共识算法类型，应用链名称等）时，需要向应用链插件查询。