了解跨链网关的设计理念

本文由BitXHub编写

在BitXHub跨链系统中，跨链**是连接特定类的区块链和转发跨链消息的重要组成部分。主要提供应用链适配、跨链事务监控、跨链事务执行、跨链事务路由等核心功能。本文主要从跨链**的体系结构、跨链交易流程、应用链与跨链**的解耦模式等方面介绍了跨链**的设计思想。1. 跨链**的整体架构如下图所示:

考虑到不同场景下的跨链需求，跨链**可以灵活地支持两种跨链模式。一种是中继模式，即通过中继链进行跨链操作，更适合更多的区块链进行跨链互操作的场景。另一种是直接连接方式，可以直接连接到其他跨链**进行跨链事务的传输。它更适合于链对链的小的交叉链系统。为了支持不同跨链模式之间的切换，跨链**采用如下分层设计:

第一层是应用链层:该层负责与应用链及其智能契约的交互逻辑，为上层的交互提供统一接口。由于区块链的架构因链而异，为了将应用链适配和跨链**解耦，达到访问方便的效果，我们采用了插件机制。

Layer2是交互层:这一层包含如何提交IBTP包以及如何侦听应用程序链上的跨链事务的特定逻辑。交互层位于交联**的底部，包括执行模块和监听模块。交互层保护上层模块不受来自应用程序链的跨链事务获取和提交的详细信息的影响，提供了更精简的交互接口。

第三层是中继层:这一层作为跨链**中消息流的传输调度层。来自应用程序链的跨链消息和从其他块链接接收的跨链消息将经过此层进行处理和路由。中继层可以掩盖不同跨链模式的复杂性，并统一调用底层模块。

二、跨链交易处理流程

在一个典的过渡链事务过程中,用户对应用程序链发送到应用程序发起一个过渡链事务链B B链对应用程序执行完成后,回执返回给应用程序链A以下细节的处理细节过渡链**在整个过程中,订单的整个过程。

AMPL已经花费AMPL已经花费监控交易

跨链事务由用户发起，以调用部署在应用程序链A上的跨链契约。跨链契约在收到对跨链事务的请求后以特定的格式抛出跨链事件。通过相应的应用程序链插件轮询或订阅跨链事件，收集应用程序链A上跨链事件的证明信息(如Fabric中的背书信息)，连同IBTP包一起发送到跨链**的监控模块。

monitor模块执行跨链事务的基本检查操作(例如跨链事务序列号)，只有通过检查的跨链事务才能提交给分发模块。如果跨链事务出现问题，则执行相应的回滚操作。

AMPL已经花费了AMPL已经花费了分布式事务

在接收到监控模块提交的跨链事务后，由于跨链**支持不同的跨链模式，配送模块需要负责跨链事务的具体交付对象。

在中继模式下，分发模块通过直连和中继链的**模块发送跨链事务。在直接连接模式下，可以通过P2P网络连接到另一个应用链的跨链**(在示例流程中，应用链B的跨链**)，并发送相应的跨链事务。

已经使用了同步事务

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

在中继链模中，跨链事务参与协商一致，并被打包成块。因此，在同步事务时，中继链光节点模块需要不断同步更新块头信息。同步模块同步继电器起重机和相关的所有过渡链交易自己的过渡链**(应用过渡链**的同步链B和B)过渡链事务相关。传递链的同步交易,SPV验证过渡链交易也应与光节点进行,确保过渡链交易的有效性。

在直接连接模式下，跨链**通过P2P网络接收跨链事务(应用程序链B的跨链**接收应用程序A的跨链**发送的跨链事务)。

hae spent AMPL hae spent检查交易

对于与其他链同步的跨链事务，在提交到分发模块进行进一步处理之前，需要由inspection模块进行检查。检查的逻辑与跨链的模式相关。

在中继模式下，跨链事务已经通过中继链的验证引擎，并参与了中继链的共识，因此检查模块只需要验证跨链事务确实来自中继链。在中继链上，中继链节点以协商一致的方式签署跨链事务。check模块验证附加的签名，以验证跨链事务的有效性。

在直连模式下，跨链事务是通过P2P网络获取的跨链事务，因此检测模块需要比中继模式承担更多的验证工作。本次审核主要需要对申请链的注册审核、验证引擎的验证审核。如果应用程序链需要为跨链事务定制验证规则，则可以通过稍后更新验证规则来更动态地完成。

已经花费了，已经花费了贸易

来自中继链或其他跨链**的跨链事务经过检查模块检查后可以提交给执行模块。执行模块直接连接到应用程序链插件，在调用交叉链契约之前，需要检查序列号，以防止重播攻击。

事务提交后，执行模块需要等待在应用链上执行的结果，并通过交叉链回执的方式将结果返回给分发模块。跨链退货收据的交付过程类似于跨链交易。执行模块确保交联事务提交给应用程序链，并需要返回相应的接收信息。

第三，插件机制

对于跨链场景，一个棘手的问题是不同架构的区块链的访问适应性。为了简化不同区块链的适配，我们在跨链**中采用了插件机制。交叉链路**主要负责与中继链路或其他交叉链路**的交互和通信。将在应用程序链上运行的所有部件封装到应用程序链插件中，根据跨链**和应用程序链交互的需求，确定一套适合于跨链交互的插件接口。

这样，对于交联**，对接任何新类的应用程序链时，都不需要修改自己，而是根据定义的接口开发一个新的应用程序链插件。

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

1. 提交事务接口

用于跨链**交付IBTP包的接口。交叉链接**和应用程序链接插件之间交互的基础是IBTP:交叉链接**提交给插件的IBTP包也是IBTP包。通过这种方式，插件使跨链**免受不同区块链事务结构的不一致复杂性的影响，并简化了跨链**的设计。

应用程序链插件负责解析IBTP包并对其进行转换，以适应应用程序链提交事务的结构。同时对得到的执行结果进行封装，从应用程序链中获取跨链事务的证明信息。

2. 查询跨链事务信息接口

在IBTP协议级别，协议可以感知的最小粒度是应用程序链。该协议只能将跨链事务转发到与IBTP包中的目标链ID对应的跨链**。对于更细粒度的链上契约、用户帐户地址等，业务结构是自解析的，并在应用程序层的IBTP有效负载字段中定义。

因此，跨链契约需要记录自己的应用程序链与其他链(即跨链事务的元信息)之间的**事务序列号信息，并在执行跨链事务时更新元信息。由于此元信息对于跨链**重启和恢复至关重要，因此插件需要提供一个可以查询此元信息的接口。

3.查询历史交易资料

对于由应用程序链抛出的跨链事件，由于无法控制的原因(如网络抖动或**中断)，一些跨链事件可能无法及时接收。在这种情况下，插件需要提供一个接口，用于查询跨链**缺少的跨链事件，以恢复跨链**处理跨链事件的顺序。

4. 查询应用程序链的基本信息

交联**是对应用程序的使用链接插件,如果交联**需要获得应用程序的基本信息链接(比如应用程序链接类,共识算法类,应用程序链接的名字,等等),需要查询应用程序链接插件。

插件能够满足以上四个条件可以满足过渡链**的需求收集和向前过渡链事务,同时可以完全解耦过渡链**的依赖底层应用程序链,使其更方便和简单的适应新的区块链。

附件:

交叉链接**源代码地址:

https://github.com/meshplus/pier

交叉链接**使用文档:http://dwz.date/aMYr