XCMP & IBC报告

本文沿着跨链通信需要解决的5大难题这一框架，通过深入挖掘XCMP与IBC二者的技术原理，刨析其不同的技术解决路径，结合当前不同项目的开发情况，拆解应用生态的代码部署流程，对二者的通信效率、开发进度、部署便捷性、应用场景、安全性这五个方面进行了对比，旨在为读者提供一个更为全面的分析。

本文认为：相比于IBC，XCMP技术原理更为复杂的根本原因是为了实现平行链通信的去信任化与通信信息的多元化。而这也在同时限制了对平行链安全性的自定义化需求并提高了系统整体崩溃的风险。此外，如忽略技术实现细节，IBC与XCMP的不同表现在：

XCMP中平行链之间能够直接传输信息，但是目前Channel被限制在100个。而IBC依靠Hub进行通信，无法直接传输。
XCMP目前仍在开发，是以HRMP为临时替代协议实现跨链信息交互。而IBC已经完成了上线，并在2020年10月份后稳定。
IBC技术实现细节远简单于XCMP协议，但是好处是大幅降低开发难度于维护成本。
XCMP与IBC都通过高度封装之后的抽象函数调用，目前看来其部署均较为简单，并不存在一方过于复杂的情况。而只要是生态中需要跨链交互的均需要调用这两个协议。
XCMP设计之初，就不仅仅是针对于平行链之间消息的传递，更是为了实现智能合约，pallet，跨链桥、甚至SPREE之间的通信。而IBC设计的初衷与目前的应用场景只针对于平行链之间消息的传输。

XCMP对于平行链的安全性并无要求，其统一由中继链进行保证。而IBC并不保证平行链的安全性，需要依赖于平行链自身的安全性。

跨链通信的难题

目前跨链技术协议有很多，但是归纳下来，跨链通信需要解决以下五个最主要的问题：

有序性：如何使得消息能按序到达目的链。
可验证：如何识别未处理的消息、验证到达的消息确实是由相应发送链发送的，如何验证消息的正确性。
无遗漏：如何确保链公平地接收每条消息、发送链不会无限期等待消息被接收链接收和处理。
有效性：需要防止中继链过载，防止网络拥堵与过载。
安全性：如何解决平行链与中继链的安全性问题。

Substrate框架下的XCMP与Cosmos中的IBC采用了不同的方法来处理与解决上述五个问题，本文将会沿着这一框架来对这两种协议的实现原理、发展现状、优缺点等方面进行深入研究与阐述。

XCMP解决方案

XCMP与XCM的含义、差别及各自实现的功能

XCMP的全程叫做跨链消息传递（Cross-chain Message Passing），XCMP目前还在开发当中，跨链的通信采用HRMP进行替代。总体来说，波卡有4种不同的跨链消息传递方式，每种不同的传递方式具有不同的特点：

中继链与平行链之间UMP（Up Message Passing）、DMP（Down Message Passing）
UMP是指中继链向上向平行链传递消息，DMP指平行链向下向中继链传递消息，如图1所示。这两种消息传递方式早已完全实现，但这两种方式并不能实现平行链之间的消息传递。
平行链之间HRMP、XCMP（Cross-chain Message Passing）
HRMP是指以中继链为中介，来实现两个平行链之间的信息传送功能。由于这种方法使得中继链承担较大储存与运算压力，使得整体的效率非常低，其为波卡推出的临时解决方案，在XCMP上线之后将会取代HRMP方案。XCMP如上文所述，是平行链之间进行跨链信息交互的最终形式，其不会给予中继链过大的运行与存储负担。

要解决跨链信息传输与交互的功能，不仅需要标准化的传输协议对传输的过程与形式进行规范，更需要将传输的消息形式进行统一与标准化，因此，在这里需要将XCMP与XCM（Cross-chain Message）两者定义进行区别：

XCM（Cross-chain Message）
XCM是跨链传输的信息的标准格式，可以类比于ERC20格式。波卡不仅想让跨链的信息在链间进行交互，更可以在智能合约，pallet，SPREE之间进行交互。因此，为了更高效的实现这一点，统一的跨链消息格式是必须的组件。
XCMP（Cross-chain Message Passing）
XCMP如上所述，为跨链传输信息的标准流程。其包含消息传递与消息存取两个关键的部分。消息传递主要是指消息通过什么样的路由方式在平行链之间传递，而消息的存取为中继链、平行链之间如何存取消息及消息的相关证明。本文为了保证逻辑的连贯，将这两个主要部分拆分至下文的部分进行阐述。

值得注意的是，由于区块链可以被是做一个全局的状态转换机器，因此，我们可以将XCM与XCMP总体看作是跨链状态转化过程。

如何实现有序性

由于不同平行链上运行着不同的DAPP，而对于一些类似DEFI的协议来说，按时有序的接收并处理消息显得至关重要。因此可以看出，有序性主要体现在消息的传递过程当中。

总体而言，两条平行链之间传输消息需要分别对彼此建立通道（channel）。当前而言，通道为单向通道（理论上也可以成为双向通道）。当通道处于打开状态时，通道中会包含以一个已发送但是未被接收的有序队列。

此队列的规则为，当消息发送者在此通道中发送新的消息时，将新的消息压到队列的末尾，接收者从队列的排头取出新消息，体现在队列中即为删除最前面的消息。由此，消息的有序性就得到了保证，新发送的消息后接收，已发送的消息先接收。

如何实现可验证性与无遗漏性

对于接收链来说，保证消息有序的接收与处理只是其中一个关键的环节，更需要解决的是，如何去识别哪些消息并未处理，如何取验证获取消息是正确的。想要理解如何解决这一问题需要深入到数据结构层面。

**MQC（Message Queue Chain，消息队列链）。**MQC是每个消息发送链自身负责维护的链，每有一个接收链即会产生一条对应的MQC。
**MQHC（Message Queue Hash Chain，消息队列哈希链）。**其是由MQC每个信息进行哈希计算得到的。MQHC中有三个元素 HC = {H(M), relay_number, H(pre_HC)}， H(M)表示消息的哈希值，relay_number代表该消息发送链上一次对接收链发送消息时的中继链的区块号，也即为上次发送消息的时间，H(pre_HC) 代表上一个区块的哈希值。

可见，如果接收链能够拿到对应发送链的HC，则可以通过对比消息的哈希值来验证获得消息的正确无误性。而relay_number可以用于定位处在某些时间之间的所有消息。

值得注意的是，MQHC的大小决定了消息通道的负载程度。因此，当接收链最终在中继链上确认了消息的接收之后，可以在MQHC中删除相应的消息以维持整个通道中消息的负载程度处在合理的区域。

由于每一条发送链对于每一个接收链都会维护一个MQHC，为了更加高效的查询与定位，将所有的MQHC最新区块头作为Merkle Tree的叶子节点，所得到的根节点值被称为Message Root（MR）。因此，通过提供对应的Merkle Proof 可以查询得到底层的HC。

MR会被包含在发送链区块的区块头中，与此相伴的还有water mark和bitfield两个参数。

Water mark（水印）
其是接收链用于判断是否处理该消息的工具，包含（block_number，para_id）两个参数，其中Block_number 表示中继链的区块号，para_id表示接收链的ID号（substrate对每一个链都会有一个唯一ID号）。
若有两个water_mark，其分别为W1 =（10，B），W2 =（20，B），则可以通过[W1,W2]表示处于[10,20]中继链区块时间的所有发送给B的消息集合。**Water mark首先是由发送链构建，然后验证后传递至中继链上，最后传递至接收链上。因此，接收链收集人可以将当前的water mark与上一个water mark之间的所有消息确认为发送链已发送但未被接收链处理的消息。**由此，解决了识别哪些消息为未处理消息的功能。
Bitfield
其是一组Bit信息，每一个Bit表示有没有对应接收链的消息。若第1，2，3位分别表示链A,B,C，则110 表示此发送链中的此区块有发送给链A,B的信息，无对链C的信息。因此，接收链的收集者可以通过bitfield信息来判断需不需要从此区块中获取信息。

我们用SCH表示发送链区块头，则SCH = {MR, water mark, bitfield,…}，当发送链的验证人验证通过并打包进入中继链后，中继链区块头中也会包含着SCH的信息。此时，中继链会在其链上储存资源中更新CST（Channel State Table）。

不同于消息本身，其并不会在中继链中得到储存，但是中继链会储存关于通道状态的表。表的行由发送链的ID组成，表的列由接收链的ID组成，其中的每一个元素是（sender_mr, block_number）组成。因此每一个cell可以得到一个通道最新更新的时间（block_numer）与发送链的MR。由于发送链的MR对于每行来说是相同的，因此，CST是以行为单元来进行更新的。

将CST每一行的各个cell作为Merkle树的叶子节点来构造出以row_root为根节点的Merkle树，将CST所有的row_root作为新的叶子节点可以构造出以XCMP_root为根节点的Merkle树。所得到的XCMP_root将会被包含进中继链的状态根中。

对于接收链的收集者而言，其通过查询CST表上的通道信息来判断是否有新的消息其需要去对应的发送链的节点上接收信息，由此实现了验证是否有新的消息的功能。接收链上的收集者在构建POV区块的时候，需要从中继链上获取相应的证明来证明此时已经获得尚未被处理的正确信息。证明由一组Merkel证明变体组成的轻客户端证明。此证明包括以下几个部分：

从XCMP_root到MR的一组Merkle证明
从MR到HC的一组Merkle证明

除了这组轻客户端证明之外，构建POV区块还需收集人收集得到以下两个信息：

发送的消息本身
最新water mark与上一次water mark之间的HC

由此，验证人可以通过亲客户端证明定位到发送链的HC，并且利用两次water mark来定位所有最近发送的但是并未处理的消息，通过对比每个HC上消息的哈希值，与自己接收消息的哈希值，验证是否是正确的消息，并且可以验证是否有消息缺失并未接收到的现象。若有，收集人便会向发送链重新索要相应的信息。

由此做到了对消息正确性与无遗漏性的验证。

如何实现有效性

中继链并不能储存过多的信息与执行过多的运算，否则将会严重影响整个系统的运转效率。XCMP的解决方案是只让中继链储存CST，消息并不通过中继链进行处理，而是通过通道来进行传递。

如何实现安全性

依靠中继链本身的验证者为平行链提供安全性，因此无需信任平行链是安全的，整个系统确保每一条平行链都是安全的。

IBC原理

IBC全称叫做链间通信协议（Inter-Blockchain Communication Protocol），是Cosmos中zone与zone通信的协议。

每个zone与zone之间并不直接通信，而是分别与Hub通信来实现zone之间的相互联系。这一点与波卡不一样，波卡通信是通过直接通信来实现的，而通过中继链来传递相关的证明并保证平行链的安全性。 IBC协议中包含了三个主要的交易类型：MsgPacket，MsgAcknowledgement，MsgTimeout。

MsgPacket：跨链交易数据包，包含跨链交易、目的链的超时高度和时间戳。
MsgAcknowledgement：响应数据包，包含跨链交易执行成功或者失败的状态。
MsgTimeout：超时数据包，包含下一个接收包的序列号。

IBC的协议流程总体来说比波卡要简单许多，其简化版的实现流程如下图所示：

首先是外部跨链交易（TX）向发送链A的Tendermint模块发起请求，验证有效后将会改变链A的账户状态，并且构建MsgPackage至其出口队列当中。Hub中的Relayer会不断扫描发送链的出口队列，若发现MsgPackage则会将其传递至接收链B中，接收链B验证通过后会执行并改变相应的账户的状态，执行成功后，会返回MsgAcknowledgement，发送链接收到后，会确认出块。