XCM第二部分：版本控制和兼容性

Gavin Wood在9月6日发布第一篇关于XCM：跨共识消息格式，文中介绍了它的基本架构、目标以及如何将其用于一些简单的用例。今天又将继续深入检查 XCM 的一个有趣方面：XCM 如何随着时间的推移而改变，而不会在它要连接的网络之间引入中断。

拥有一种共同的语言可以解决很多人际交往的问题。它使我们能够一起工作，解决冲突并记录信息以备后用。但是语言的有用之处在于它能够表达的概念，在一个不断变化的世界中，语言必须改变和适应其概念库，否则就有被废弃的风险。

不幸的是，过于突然地改变语言会损害其主要目的——促进人与人之间的交流。由于语言必须改变，因此必须有管理这些改变的方法，而不会使外行人无法理解新形式。在这方面，一个非常有用的发明是词典，它可以帮助记录和存档一种语言的概念调色板，以便后代能够更好地理解历史文本。字典的版本可以被认为是一种语言的正式“版本”。

时代可能会改变，但问题仍然非常熟悉。正如我在上一篇文章中所解释的，XCM 只不过是一种语言，尽管它是一种非常专业的语言。它是共识系统相互交流的一种方式，随着对这个 XCM 的需求以加密行业和特别是 Polkadot 生态系统的极速发展，那么必须有一些方法来确保这些变化不会妥协XCM 的最初目标：互操作性。我们现在不仅需要解决共识空间的互操作性，还需要解决共识时间的问题。

? 版本控制

由于我们希望 XCM 的语言在大量使用时会随着时间的推移而改变，因此需要采取的一个非常简单的预防措施是确保在实际消息内容之前确定我们正在通信的 XCM 版本。我们通过使用许多版本包装器类型来做到这一点，之所以如此命名是因为它们按版本包装XCM 消息或其组件。在 Rust 代码中，这看起来非常简单：

当“通过网络”发送（或者更确切地说，在共识系统之间）发送时，XCM 始终放置在此版本化容器中。这确保了太旧而无法解释消息的系统可以安全地接收它们并识别它们不支持消息的格式。它还允许较新的系统识别并相应地解释较旧的消息。

不仅仅是 XCM 消息被版本化；在 XCM 代码库中，我们还对MultiLocation、MultiAsset及其关联类型进行了版本控制。这是因为当链的 XCM 逻辑升级时，它们可能需要被存储和稍后解释。如果没有版本控制，我们可能会尝试将旧的解释MultiLocation为新的，并发现它是不可理解的（或者更糟的是，可以理解但与原始含义不同）。

? 兼容性和翻译

版本控制是第一步，可确保我们能够识别所使用语言的版本。它不保证我们可以解释它，当然也不保证它是我们优先使用的同一版本。这就是兼容性的用武之地。我们所说的“兼容性”是指能够在 XCM 版本中继续解释和表达我们自己，这不是我们首选的版本。

如果我们希望能够按照我们选择的时间表升级我们的网络及其 XCM 版本，那么这种兼容性就变得相当重要，因为我们可能希望与尚未升级或实际上已经升级的其他网络进行通信。这可以分解为向后兼容和向前兼容。基本上来说，向后兼容性是升级后的系统在遗留世界中继续运行的能力，向前兼容是遗留系统在升级后的世界中继续运行的能力。

在我们的例子中，我们希望两者兼而有之，但存在实际限制：在新版本的 XCM 提供以前版本中不存在的功能的情况下，期望旧系统能够解释这些消息是不现实的。这有点像试图将“社交媒体”一词翻译成拉丁语，然后期望 Julius Caesar 从表面上理解它。有些概念根本无法在上下文中表达。

同样，对 XCM 的重大更改可能会导致从其概念模型中删除功能。这种情况较少发生，但类似于将某些古老术语翻译成现代等效术语的问题。有趣的是，“点”的古老含义在这里可能是一个例子（它曾经表示一种相当特殊的金融禀赋形式）。

因此，新版本的 XCM 被设计为主要兼容旧版本和新版本，但通常会有 XCM 消息在替代上下文中根本没有意义并且无法翻译。

? 实际沟通

如前所述，我们确保所有独立存在的消息都包含一个版本标识符。这意味着在系统之间发送的消息或在存储中持久化的消息。但它并不包括所有消息、位置和资产——作为其他数据的一部分存在的数据不需要版本化，因为它的版本可以从它的上下文中推断出来。

虽然版本识别和兼容性/翻译有助于从旧网络接收消息或将消息发送到新网络，但是——单独来看——在相反的情况下就没那么有用了。这是因为从升级网络接收消息的传统网络本身没有能够将新 XCM 转换为它可以解释的某种形式的逻辑——相反，该逻辑仅存在于具有转换代码的发送方用传统术语重新表达新信息。

因此，发送网络必须负责确保它发送的消息能够被接收网络解释。具体而言，用于消息的 XCM 版本不得高于接收网络支持的 XCM 版本。

出于这个原因，Polkadot 和 Kusama 中继链、Statemint、Statemine、Shell 和任何其他基于 Substrate/Frame 的链及其 XCM 引擎都保留了远程链支持的 XCM 版本的注册表。每当这些链发送 XCM 消息时，它首先会通过查询其注册表来确定将消息发送到哪个版本。它将消息转换为较旧的发送方和接收方支持的 XCM 版本。对于保持最新状态的链，大多数情况下它们将是相同的、最新发布的版本，从而提供 XCM 的完整功能集。

该注册表通常由治理流程指定和升级，这有点麻烦和乏味，尤其是随着潜在目的地数量的增加。为此，引入了版本跟踪。

? 版本协商

版本跟踪是 XCM 版本控制故事拼图中的最后一块。它的功能是删除跟踪潜在目的地链的 XCM 版本所需的任何链外或治理流程。相反，该过程是自主和在链上发生的。

从本质上讲，它的工作原理是允许一个网络使用 XCM 查询另一个网络以获取它支持的最新版本的 XCM，并在此更改时收到通知。来自此查询的回复允许有问题的网络填充和维护其版本注册表，确保使用最新的可理解版本发送消息。

具体来说，XCM 中有三个有价值的指令：

SubscribeVersion允许一个人要求另一个人通知它现在和更改时的 XCM 版本；UnsubscribeVersion取消该请求；以及QueryResponse，将某些信息从响应者网络返回到发起网络的一般方法。这是它们在 Rust 中的样子：

所以SubscribeVersion需要两个参数。第一个query_id是 type QueryId，它只是一个整数，用于让我们识别和区分返回的响应。所有导致发送响应的 XCM 指令都有类似的方法来确保它们的响应可以被识别并相应地处理。第二个参数被调用max_response_weight，它是一个Weight值（也是一个整数），指示回复返回时我们应该花费的最大计算时间。像query_id，这将被放入该指令生成的任何响应消息中，并且需要确保任何重量不可预测的可变重量成本在执行之前至少可以限制为最大值。如果没有这个，我们将无法获得回复消息可能需要解释的时间上限，因此无法安排它执行。

UnsubscribeVersion作为指令相当贫瘠，主要是因为一次只允许一个版本订阅在给定位置处于活动状态。这意味着取消只能通过原产地登记簿的内容来识别。

版本注册表及其用法的说明。在这里，链 A（XCM 版本 2）与链 E（XCM 版本 3）协商并最终发送版本 2 消息，E 将在解释之前自动将其转换为版本 3。

? 回复

要注意的第三条指令是QueryResponse，这是一条非常通用的指令，允许一个链回复另一个链，并在这样做时报告一些信息。这是在 Rust 中：

我们已经知道三个参数中的两个，因为它们是从SubscribeVersion. 第三个被调用response，包含我们关心的实际信息。它被放置在一个新类型中Response，它本身是一个网络可能希望用来通知另一个网络的几种类型的联合。在 Rust 中看起来像这样：

就我们目前的目的而言，仅Version需要该项目，但正如我们将在即将发布的文章中看到的，其他项目对于其他上下文也很有用。

? 执行时间

通常，我们不需要QueryResponse指令来购买它们自己的执行时间，BuyExecution因为（假设它们是有效的），现在解释网络首先要求发送它们。同样，我们认为SubscribeVersion是符合发送方和接收方的共同利益，因此不需要为此付费。在任何情况下，由于它会生成的响应的异步和不可预测的性质，支付将相当难以计算。

? 自动化

虽然这些 XCM 指令允许网络完全使用链上逻辑来确定其对话者支持的最新版本，但仍然存在何时启动此版本发现“握手”的问题。当创建用于发送 XCM 的通道时，通常无法完成，因为传输通道的创建在概念上低于 XCM，XCM 是一种（可能是多种）数据格式，可以通过该通道发送。两个浑水在这里可能会损害分层设计的独立性。此外，一些交叉共识传输协议根本不是基于通道的，这将排除在它们开始时进行版本协商的可能性。

在 Polkadot 中继链和 Statemint 等 Substrate 链中，解决方案是在需要包装消息以进行发送但目的地的最新版本未知时自动启动此版本发现过程。这有一个小缺点，即第一条消息将在次优 XCM 版本下发送，这种情况会在收到版本响应之前发生。如果这是一个实际问题，那么治理可以介入强制该目的地的 XCM 的初始版本与默认版本不同（通常设置为在生产中仍可预期的最早 XCM 版本）。

?? XCM 中的代码兼容性

关于版本控制的最后一点是代码创作。完全不同的过度的线XCM的格式，代码兼容性处理是使用 Rust 实现（基于 substrate ）项目代码库必须发生的事情。XCM会随着时间的推移而堆叠。

显然，旨在使用不断发展的语言来表达想法的代码库必须与时俱进。我们已经拥有语义版本控制 (SemVer) 系统，该系统有助于指示特定版本更改可能发生的更改。但是，这在处理 API 和 ABI 时非常有用，而在考虑整体数据格式或语言时则不太有用。值得庆幸的是，XCM 的设计几乎不需要 SemVer。

我们知道，较新版本的 XCM 软件能够在新旧 XCM 消息及其内部数据类型（如位置和资产）之间进行转换。它可以通过在 XCM 代码库中同时保留多个版本的 XCM 语言来实现这一点。Rust 的模块系统使这变得微不足道，新的 XCM 版本只对应一个新的 Rust 模块。如果我们回顾一下VersionedXcm数据类型的 Rust 声明（就在本文的开头），它只是底层Xcm数据类型的每个特定版本的标记联合，每个版本都在它们自己的模块v0, v1, v2, &c 中找到。

由于使用 XCM 及其数据类型的事务和 API 往往只使用版本化的变体，这些变体可以用新旧格式同样构造，最终结果是代码库可以更新为使用最新的 XCM 软件（在 Rust 中，这是被称为板条箱），对其代码进行很少或没有更改。升级 XCM crate 允许网络更好地与其他类似升级的网络互操作，但升级网络使用的 XCM语言的任何片段都需要稍后进行。

我希望这会成为团队保持 XCM 板条箱更新的强大动力，从而保持所有内容快速迭代和发展。

? 结论

我希望这能让您了解 XCM 的版本控制系统以及如何使用它来保持主权链网络的通信，因为它们用于通信的语言在网络之间以不同的速率和时间发展，并且开发人员团队没有大量的运营开销谁保持他们的逻辑。

查看更多

—-

编译者/作者：Polkadot_club

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。