11 月 21 日，Bifrost 支持了 $MOVR/$GLMR 的流动性质押，开启了 vMOVR 和 vGLMR 的铸造。这是 Bifrost 继 vETH、vDOT、vKSM 之后，开启的又一组新的 vToken 系列。

MOVR/GLMR 分别是 Moonriver 和 Moonbeam 的工作通证，Moonriver 是 Moonbeam 的金丝雀网络，二者分别是 Kusama 和 Polkadot 的平行链。vMOVR/vGLMR 是 Bifrost 推出的第一组基于 XCMP (当前版本为 HRMP) 实现的 vToken 实例。此前的 vDOT/vKSM 是基于 VMP 实现的。

XCMP（Cross-Chain Message Passing）是 Polkadot 上的跨链消息传输协议，用于平行链/平行线程之间的跨链通讯。 VMP 则是用于平行链/平行线程与中继链之间的跨链通讯。 XCM 是波卡制定的一个通用跨链消息格式， XCM 不仅可以用于平行链之间的通讯，还可以用于任意两条 Substrate 链之间的通讯，因此基于 XCM 的通讯是个更广泛的概念。

vMOVR/vGLMR 的铸造 & 赎回

Bifrost 将如何用 XCMP 支持 vMOVR/vGLMR 的铸造和赎回呢，接下来我们以 vMOVR 为例进行说明。

如这篇文章所述，所有的 vToken 都是 Bifrost 链上的原生资产，也默认会被发行在 Bifrost 链，这样策略会为跨链集成提供更多的便利。

我们先罗列所需组件：

• Bifrost 链 : 这里指 Bifrost Kusama Parachain。(Bifrost 还有一条 Bifrost Polkadot Parachain)
• Moonriver 链 ：Moonbeam 的金丝雀网络，Kusama 的平行链。
• Bifrost Sovereign Address : Bifrost 链上有一个 Bifrost 的主权账户，可以通过部署 runtime 来控制，事实上，每条平行链/线程都有自身的主权账户。
• Bifrost Sovereign Address on Moonriver ：每个平行链/平行线程在中继链上以及其他平行链/平行线程上都有自己的主权账户，该地址受主权链的代码控制。因此，Bifrost 并不需要在 Moonriver 创建一个托管地址，而是可以用 Moonriver 上的 Bifrost 主权地址来执行质押和解除质押。
• SLP Module ：这是 Bifrost 链上的一个 runtime ，负责发出一系列和 vToken 铸造/赎回有关的指令。
• XCMP：我们通过它传输 XCM 指令。

vMOVR 铸造流程：

1. 用户 A 将 MOVR 跨链转入 Bifrost 链；
2. 用户调用 SLP Module ，将 MOVR 锁入 Bifrost 主权账户；
3. SLP Module 按照当前汇率为用户 A 铸造 vMOVR；
4. SLP Module 将 Bifrost Sovereign Address 中的 MOVR 跨链转入 Bifrost Sovereign Address on Moonriver，并发出 XCM 指令，执行质押。

vMOVR 赎回流程：

1. 用户 A 调用 SLP Module，将 vMOVR 发送到销毁地址；
2. SLP Module 向 Bifrost Address on Moonriver 发出 XCM 指令，按照当前汇率，解除质押对应数量的 MOVR，并跨入 Bifrost Address（由于解除质押有一个解锁期，该步骤不会立即完成）；
3. Bifrost Address 将这些 MOVR 返回给用户 A 。

闪电赎回：

用户如果希望立即获得 MOVR ,不想等待解锁期，也可以选择闪电赎回，闪电赎回的实质是 swap，因此需要向流动性提供者支付一部分费用。

由于 Bifrost Kusama Parchain 和 Moonriver 都是 Kusama 平行链，所以二者之间可以直接使用 XCMP 通讯， vMOVR / vGLMR 的铸造和赎回过程中的跨链通讯用的都是 XCMP 。我们知道， XCMP 是波卡平行链间的原生通讯桥梁，使用 XCMP 不会像使用其他第三方跨链桥一样，引入新的安全风险，也就是说，vMOVR/vGLMR 的安全性是波卡中继链级别的。

XCMP 是如何工作的

要理解 XCMP 的工作原理，首先要了解几个核心概念：

Channel

两条平行链如果需要通讯，需要首先建立 Channel 。Channel 是单向的，两条平行链（A 和 B）之间如果想要双向通讯，就需要建立两条通道（A → B Channel， B → A Channel）。

Egress 和 Ingress

当平行链 A 与平行链 B 建立 A → B Channel 时，平行链 A 上会被创建一个平行链 B 的 egress（出口队列），而平行链 B 上会被创建一个平行链 A 的 ingress（入口队列）。

MR（Message Root）

XCMP 采用了消息树的结构，所有的待发消息作为叶子节点构成一个默克尔树，树的根值被称为 MR（Massage Root），每有一个新的消息作为叶子节点插入，都会产生一个新的 MR 。因此每一个 Egress 里除了存储待发消息队列的原文之外，还需要维护一个 MR 队列（Message Queue Hash Chain）。

我们来看下 XCMP 中的消息生命周期：（以 A → B Channel 为例）

1. Chain A 上用户通过源链上的应用程序发起跨链请求，想要将消息 M 送到 Chain B 。该消息会被放入 Chain A 上为 Chain B 专设的出口队列（我们简写为：Egress A → B）。该消息将被包含进最新的 MR 中。
2. Chain A 的收集者在打包当前区块的时候，会将最新的 MR 放入区块头。当区块被中继链分配给 Chain A 的验证者验证后，会被提交到中继链，并被中继链的区块包含。此时，我们认为该 MR 被中继链验证了。
3. Chain B 的收集者会不断轮询所有其他链上为 Chain B 建立的出口队列，这里就包括 Egress A → B，Chain B 的收集者将 Egress A → B 中的消息原文及 MR 队列放入自己对应的入口队列：Ingress A → B 。（* 有另一种说法，该过程不是收集者完成，而是验证者完成的，这点的设计在 XCMP 中还没有完全确定，但谁来完成并非 XCMP 设计的关键点，因为这项任务是无信任的，谁来完成都可以）。
4. Chain B 的验证人从中继链获取 Channel A → B 的最新被中继链验证的 MR 。
5. Chain B 用该 MR 来判断 Ingress A → B 哪些消息已经被包含到中继链中，然后更新这些消息的状态为已验证。
6. 已验证的消息就可以被目标应用程序执行了。

我们为了表达方便，只描述一个 Channel 的消息流，事实上 XCMP 在处理跨链消息的时候，所有的 Channel 是同时处理的。中继链会维护一个 CST 表格（Channel State table），用于存储所有 Channel 的 MR 。

XCMP 的特点

我们发现，XCMP 的设计非常精巧，它让平行链/线程 之间的跨链消息能够快速、有效、安全、廉价的进行。

快速：从发送链打包好区块，被验证后提交给中继链，并在中继链被最终确定，这个时间很短，对于用户而言几乎是感觉不到延迟的。

有序：通过 Egress 和 Ingress，使得一个 Channel 内的所有消息遵循一个严格的队列结构，有明确的先后顺序（不同 Channel 的消息之间则没有时序属性。）消息在被目标链执行之前，始终存在于 Egress，直到在被目标链执行之后，才能从 Egress 删除。这将确保消息不会被遗漏。

安全：所有的跨链消息都经过了中继链的验证。

廉价：尽管消息必须经过中继链的验证，但通过消息树的机制，让中继链只验证 MR ，而不直接验证消息原文，消息原文的传递直接通过发送链和接收链本身完成，不通过中继链。这样最大程度避免了占用中继链的资源，从而使得跨链消息传递的成本控制在较低的水平。

跨链消息传递是跨链互操作的基础，无论是跨链的资产传输、跨链功能调用、跨链计算，其基础都是跨链消息传输。因此，XCMP 为众多的平行链提供了互操作性。

Bifrost 作为最早立足波卡生态的 DeFi 项目之一，对波卡的多链架构有着坚实的信仰，这来源于我们对多链互操作性的认知。以太坊的 Rollup 虽然可以在继承以太坊安全性的基础上，扩展出更多的应用运行空间，但 Rollup 之间缺乏互操作性。

Cosmos 虽然也是多链架构，并且通过 IBC 可以实现很好的互操作性，但 Cosmos 的各个 Zone 的安全性是各自为政的，各个 Zone 之间存在一个授信问题，每个 Zone 都要自己去选择相信哪些 Zone ，而不相信哪些 Zone ，尽管 Cosmos 2.0 增加了向 Hub 租用安全性的选项，但这仍然不能确保所有租用安全性的 Zone 的安全性处于同一水平。而波卡的多链架构的第一特性就是共享安全性，各平行链的安全级别与中继链一致，可以无条件互相信任，在此之上， XCMP 所提供的互操作性的安全级别，也是与中继链一致的。

基于 XCM 的通讯

Gavin 曾在一次演讲中提到，XCMP 只是波卡跨链解决方案的一半，另一半是 XCM 。XCM 是波卡制定的一个消息格式标准。在 XCMP 中，所有的跨链请求都会格式化为 XCM ，然后才能进入 Egress 。XCM 上可以包含一组指令，目标应用程序收到 XCM 消息之后将执行该指令。

XCM 不止是 XCMP 通讯的标准格式，也是所有 Substrate 链之间跨链通讯的标准格式，Gavin 还希望，XCM 未来能通行于更多的异构跨链场景。因此，基于 XCM 的通讯将是一个比 XCMP 更广泛的概念，它能够扩展到所有的 Substrate 链，从而构建其一个泛 Substrate 生态。它甚至有希望击穿 Substrate 生态，连接包括 EVM 生态在内的更多异构生态。

小结

在众多的 Web3 应用类型中，或许有些类型的应用，诸如游戏、社交对互操作性的要求不高，但 DeFi 应用一定是对互操作性要求最高的类型。可以说，互操作性是 DeFi 应用的根基。Bifrost 作为 DeFi 应用当然也需要互操作性，我们需要 vToken 能够更广泛的流通，被更多的 DeFi 应用集成，与更多的 DeFi 应用互动。

由 XCMP 连接的平行链生态，将是一个具有无缝互操作性且无需考虑跨链授信问题的多练系统。我们相信 Bifrost 及 vToken 能被该系统充分赋能。此外，基于 XCM 的通讯能够把我们带到更广阔的天地。vMOVR/vGLMR 是我们启航的地方，终点是星辰大海。