桥接消息模块

消息模块用于将源链的消息传递到目标链。消息对模块是（几乎）透明的，最终目标是把消息交给消息调度机制。

内容

• 概述
• 消息工作流程
• 将消息车道模块集成到运行时
• 非必需功能
• 模块外部的权重

概述

消息通道是一个单向通道，消息从源链发送到目标链。同时，单个消息模块实例支持出站通道和入站通道。因此，模块部署的链（本链），可能作为出站消息的源链（指向跨接链），也可能作为入站消息的目标链（来自跨接链）。

消息模块支持多个消息通道。每个消息通道都有一个4字节的标识符。通过该通道发送的消息被分配一个唯一的（对于该通道）递增整数值，称为nonce（“只能使用一次的数字”）。在同一通道上发送的消息保证按照它们从源链发送的顺序发送到目标链。换句话说，nonce为N的消息将在发送nonce为N+1的消息之前发送。

单个消息通道可以被视为单个应用（链上、链下或混合）的传输通道。同时，模块本身不会指定任何通道或消息规则。最终，是由运行时开发者定义这个运行时中的消息通道和消息的含义。

在我们的Kusama<>Polkadot 桥接中，我们使用通道作为不同中继链的两个平行链之间的通信通道。例如，通道[0, 0, 0, 0]用于Polkadot <> Kusama Asset Hub通信。其他通道可以用来连接其他平行链。

消息工作流程

该组件不打算由最终用户使用，也不提供发送消息的公共调用。相反，它提供了运行时内部方法，允许其他组件（或其他运行时代码）排队出站消息。

当某些运行时代码调用组件的send_message()方法时，“消息”就会出现。提交者指定他们愿意使用的通道以及消息本身。如果发送消息需要支付某些费用，则必须在组件之外支付。如果消息通过了所有检查（包括例如消息大小检查、禁用通道检查等），则会分配nonce并将消息存储在模块存储中。现在，消息处于“未发送”状态。

我们假设存在外部、链外演员，称为中继者，他们向目标和源链提交与模块相关的交易。组件本身对中继者的激励方案没有假设，但它提供了一些支付奖励的回调。有关详细信息，请参阅将消息模块集成到运行时。

最终，某个中继者会发现这个处于“未发送”状态的消息，并决定发送这个消息。然后，中继者为目标链上部署的消息模块实例制作receive_messages_proof()交易（即交付交易）。中继者提供其在源链上的账户ID，消息证明（或多个消息），交易中的消息数量及其累积调度权重。一旦交易被挖掘，消息就认为已经“送达”。

一旦消息被投递，中继器可能希望向源链确认投递。这有两个原因。第一个原因是我们故意限制了入站通道中“已投递”但尚未“确认”的消息数量（请参阅关于消息模块配置特性中其他常量的内容以获取解释）。因此，在某个时刻，目标链可能会停止接受新的消息，直到中继器确认其中的一些。第二个原因是，如果中继器想要因投递而获得奖励，它必须证明它实际上已经投递了消息。而这个证明只能在投递交易被挖矿后生成。因此，中继器为源链上部署的消息模块实例创建了一个receive_messages_delivery_proof()交易（也称为确认交易）。一旦这个交易被挖矿，消息就被认为是“已确认”的。

“已确认”状态是消息的最终状态。但是，与消息相关的一个最后一点是，它现在“已确认”且已向中继器支付了奖励（或者至少已调用此回调），必须向目标链确认这一点。否则，我们可能会达到目标链上“未确认”消息的限制，并且它将停止接受新的消息。因此，中继器有时会在下一个receive_messages_proof()交易中包含最新“已确认”消息的nonce，以证明某些消息已被确认。

将消息模块集成到运行时

如上所述，消息模块支持出站和入站消息通道。因此，如果我们将在某个运行时中集成一个模块，它可能作为出站消息的源链运行时，以及作为入站消息的目标链运行时。在本节中，我们有时会称我们目前正在集成的链为“此链”，而将其他链称为“桥接链”。

消息模块不仅接受声称桥接链为我们有一些更新数据的交易。相反，该模块假设桥接链能够以某种方式证明这些更新数据。这个证明被抽象出来，可以是任何类型的。在我们从Substrate到Substrate的桥接中，我们使用运行时存储证明。其他桥接可能使用交易证明、Substrate头摘要或其他任何可以证明的内容。

重要提示：本章节以下所有内容描述了消息模块配置的细节。但是，如果您对两个基于Substrate的链的深入研究和相对容易的集成感兴趣，您可能想查看bridge-runtime-common crate。这个crate提供了一些用于集成的辅助工具，可以直接在您的运行时中使用。然后，如果您决定更改此方案中的某些内容，请回到这里以获取详细信息。

一般信息

消息模块支持实例。每个模块实例都应该桥接此链和某些桥接链。为了与其他链桥接，建议使用另一个实例（尽管代码中没有任何强制要求）。请注意，该包可以用来在多个链之间建立虚拟通道，正如我们在Polkadot <> Kusama桥中所做的那样。在那里，包实际上只桥接了两个平行链——Kusama桥接中心和Polkadot桥接中心。然而，其他Kusama和Polkadot平行链能够向它们的桥接中心发送（XCM）消息。这些消息将被投递到桥的另一侧，并在桥接链的共识中路由到正确的目标平行链。

消息提交者可以通过检查模块事件来跟踪消息进度。当消息被接受时，会触发MessageAccepted事件。该事件包含消息通道标识符和已分配给消息的随机数。当消息被发送到目标链时，从receive_messages_delivery_proof交易中触发MessagesDelivered事件。该MessagesDelivered事件包含消息通道标识符和已发送消息的随机数的范围。

该组件不提供获取目标链上消息分发结果的方法。如果需要，必须在组件外部完成。例如，XCM消息在发送时会有特殊指令将一些数据发送回发送者。其他分发器可能也会使用类似的机制。

如何将消息模块插入到跨链中发送和接收消息？

pallet_bridge_messages::Config特质包含2个主要关联类型，用于处理入站消息。pallet_bridge_messages::BridgedChain定义了跨链的基本原语。而pallet_bridge_messages::BridgedHeaderChain定义了我们在运行时访问跨链头部的方式。如果你与使用GRANDPA最终性的链桥接，可以使用pallet_bridge_grandpa；如果你与跨链桥接，可以使用pallet_bridge_parachains::ParachainHeaders。

pallet_bridge_messages::Config::MessageDispatch定义了如何分发已发送的消息。除了实际分发消息外，实现必须在调用分发之前返回消息的正确分发权重。

最后一个类型是pallet_bridge_messages::Config::DeliveryConfirmationPayments。当收到确认交易时，我们会调用pay_reward方法，传递已发送消息的范围。你可以使用pallet-bridge-relayers组件及其适配器DeliveryConfirmationPaymentsAdapter作为可能的实现。这允许你为转发消息支付固定奖励，并为确认交付支付其部分。