作为波卡生态共识系统之间交流思想的语言，XCM的主要性不容分说。在《Gavin Wood：详解跨共识消息格式XCM设计原理与运转机制》一文中，Gavin Wood对于XCM设计原理与运转机制进行了非常详细的解说。而在《Gavin Wood：探究XCM的版本控制与兼容性》一文中，Gavin Wood又对其版本控制与兼容性进行了深入探究。

接下来在本文中，Gavin Wood将会就XCM底层设计和执行模型来进行深入研究，以帮助大家更有效的了解XCM的底层虚拟机。

作者：Gavin Wood

来源：Polkadot

编译：陈一晚风

由于XCM是基于XCVM的指令集，而XCVM是一个非常高级的虚拟机，为了熟悉这种机器架构，所以我们先来简单介绍一下XCVM。

XCVM是一个非常高级的、非图灵完备的虚拟机。它是基于寄存器而不是基于堆栈，并且有几个专用寄存器，其中大部分存储高度结构化的数据。与通用处理器不同，XCVM的寄存器不能随意设置为任意值，但有严格的机制来控制它们如何改变。除了与本地链状态交互的某些方式（例如我们已经看到的WithdrawAsset和DepositAsset指令）之外，没有额外的“内存”。没有循环的可能性，也没有明确的分支指令。

在之前的文章中我们已经介绍了Holding Register和Origin Register两种寄存器。Holding Register能够临时持有一个或多个资产，并且可以通过从本地链中提取资产来填充，或者通过从受信任的外部接收资产来填充来源（例如另一个链）；Origin Register在执行开始时持有当前XCM执行起源的共识系统的位置，并且可能只能突变到一个内部位置或完全清除。

而在在其他寄存器中，三个与异常/错误管理有关，两个与跟踪执行权重有关。我们将在本文中重点讲解这些寄存器的执行模型。

执行模型

如前所述，没有显式条件指令或循环原语可以重复执行同一条指令多次。这使得预先确定程序的控制流变得相当简单。这个属性很有用，因为我们想要确定XCM 息在执行点之前可以使用多少执行时间（在整个Substrate/Polkadot中称为权重）。

我们期望执行XCM的大多数共识平台都需要能够在开始执行之前确定最坏情况的执行时间。这是因为区块链通常需要确保单个块的处理时间不会超过某个预定限制，以免导致整个系统停顿。此外，如果系统需要支付费用，那么它必须发生在支付费用的工作负载之前，而且这一支付必须涵盖最坏情况下的执行时间。

由于这种图灵完备性，允许使用图灵完备语言的系统（例如以太坊）实际上无法直接从程序中计算出最坏情况的执行时间。他们通过要求用户预先确定程序的执行资源，然后在执行时计量并在超过支付的数量时中断它来解决这个问题。有时交易会在交易执行之前就发生变化，且权重变得不正确。令人高兴的是，像XCVM这样的非图灵完备的虚拟机可以避免这种计量和权重规定的需要。

权重

权重通常表示为一个有代表性的硬件执行给定操作所需要的皮秒的整数。正如我们在BuyExecution指令中看到的那样，XCVM在处理某些指令时包含了执行时间/权重的概念。

没有权重计量，但为了允许XCVM程序最终取的权重小于最坏情况的权重预测，我们有一个称为剩余权重寄存器的寄存器。因为我们可以准确地预测它们会使用多少权重，所以大多数说明书都不会触及它。然而，偶尔会出现最坏情况权重预测高估的情况，只有在执行时我们才知道有多少。在计算高估了XCM消息权重的块执行时间时，跟踪原始权重被高估的数量，并从账户中减去它，允许链优化其块执行时间配额。

因此，剩余权重寄存器对于我们的块执行时间核算很有用，但它并不能单独解决另一个问题，即确保所支付的金额不会被高估。为此，我们需要一个与BuyExecution相关的指令，它该指令将收取多余权重并退款。自然，这条指令是存在的，叫做“退款剩余”。它使用的第二个寄存器称为“退款权重寄存器”，以确保不会多次退款相同的剩余权重。

流量控制和异常

到目前为止，还有两个寄存器在我们对XCVM的处理中相当含蓄，但仍然很重要。首先是程序寄存器，用于存储当前正在执行的XCVM程序。其次是程序计数器，它存储当前正在执行的指令索引。当程序寄存器改变时，它被重置为零，并在每个成功执行的指令结束时加1。

处理“异常”情况可能性的能力对于编写成熟的代码至关重要。当远程系统上发生了你没有预料到（或确实无法预料到）的事情时，你就需要某种方式来管理它，即使它只是简单地向原始状态发送一个报告。

虽然XCVM指令集不包括任何明确的通用分支指令，但它的执行模型中确实有一个通用的异常处理框架。XCVM包括另外两个代码寄存器，每个寄存器都保存一个XCVM程序，如程序寄存器。这两个寄存器称为附录寄存器和错误处理程序寄存器。如果你熟悉几种流行语言中的try/catch/finally异常系统，那么接下来的内容可能会让你容易理解。

如前所述，XCVM程序的执行是按照其中的每条指令一步一步执行的。当它遵循这些指令到程序结束时，会发生以下两种情况之一：要么成功到达程序末尾，要么发生错误。在第一个成功执行的情况下，错误寄存器被清除，它的权重被添加到剩余权重寄存器。附录寄存器也被清除，其内容被放置在程序寄存器中。如果程序寄存器为空，则停止，否则程序计数器复位为零。简而言之，我们抛出当前的程序和错误处理程序，如果有的话就开始执行附录程序。

此功能本身并不是很有用，但与发生错误时发生的情况相结合时会很有用。在这里，尚未执行的任何指令的权重都被添加到剩余权重寄存器中。错误处理程序寄存器被清除，其内容放置在程序寄存器中，程序计数器复位为零。简单地说，我们抛出当前程序并开始执行错误处理程序。因为我们没有清除附录寄存器，所以除非它被错误处理程序重置，否则它会在成功完成后执行。

由于其组合结构，它允许错误处理程序的任意“嵌套”：如果需要，错误处理程序也可以有错误处理程序，附录可以有自己的附录。

有两条指令允许操作这些寄存器：SetAppendix和SetErrorHandler.。前者设置附录寄存器，后者设置错误处理程序寄存器。其中每一个的预测权重都比其参数的权重略高。然而，当执行时，寄存器中将被替换的XCM消息的权重被添加到剩余权重寄存器中，从而允许回收任何未使用的附录或错误处理程序的权重。

投掷错误

有时，确保错误发生并自定义错误的某些方面可能是有用的。这已经在编写测试代码时使用，但它最终可能会在活动链中找到使用。这这可以通过指令Trap在XCVM中完成，该指令总是导致错误发生。抛出的错误类型共享名称Trap。指令和错误都携带一个整数参数，允许在错误抛出者和外部观察者之间传递某种形式的信息。

这是一个简单的例子：

Trap导致最终的DepositAsset被跳过，而错误处理程序的DepositAsset被运行，将 1 DOT（减去执行成本）置于平行链2000的所有权下。我们将始终倾向于RefundSurplus在错误处理程序代码的开头使用，因为如果它是运行，我们知道很可能使用的预测权重（以及因此购买的权重）是高估的。

错误报告

能够引入处理错误的代码是非常有用的，但其中经常被要求使用的功能是能够将XCM消息的结果报告给原始发送者。QueryResponse指令允许一个共识系统向另一个系统报告一些信息，剩下的就是能够以某种方式将XCM的结果插入其中QueryResponse并将其发送给希望被告知的人结果。

事实证明，只有一个指令完成了这个任务，它叫ReportError。它通过使用我们尚未遇到的寄存器来工作：错误寄存器。错误寄存器是一种可选类型（可以设置或清除）。如果已设置，则它包含两条信息：数字索引和XCM错误类型。

它具有极其简单的操作机制。首先，每当指令导致错误时，它总是被设置；错误类型设置为该错误的类型，数字索引设置为程序计数器寄存器的值。其次，只有当ClearError指令被执行时它才被清除。该指令是绝对可靠的指令之一，因为它本身永远不会导致错误。它在发生错误时被设置，并在你发出适当的指令时被清除。

现在应该可以清楚地理解ReportError指令是如何工作的：它只是QueryResponse使用错误寄存器的内容组成一条指令并将其发送到特定目的地。当然，在它之前发生的任何错误都会导致指令被跳过，因为执行首先跳转到错误处理程序寄存器的代码，然后跳转到附录寄存器的代码。然而，解决这个问题的方法很简单：将reportterror放在附录中将确保它被执行，而不管主代码是否导致执行错误。

我们来看一个简单的例子。我们会将资产（1 DOT）从中继链传送到Statemint（平行链 1000），在那里购买一些执行时间，然后使用Statemint作为储备，我们将资产存入平行链 2000。原始（非错误报告） ) 消息如下所示：

有了基本的错误报告，我们将改为使用这个：

正如你所看到的，唯一的变化是引入了两条SetAppendix指令，以确保 Statemint 和平行链 2000中的错误或缺失将报告给中继链。这假设中继链已将自身设置为能够识别和处理来自Statemint和parchain 2000的QueryResponse消息，查询ID为42，权重限制为1000万。令人高兴的是，这确实是Substrate很好的支持，但现在已经超出了范围。

资产陷阱

当在处理资产的程序中发生错误时（大多数情况下都是这样，因为它们经常需要为执行BuyExecution支付费用)），那么问题就会很大。可能存在BuyExecution指令本身导致错误的情况，可能是因为权重限制不正确或用于支付的资产不足。或者，资产可能被发送到一条无法以有用的方式处理它的链上。在这些情况下，息的XCVM执行结束时资产仍留在Holding Register中，与其他寄存器一样，这些资产是瞬态的，我们期望被遗忘。

团队和他们的用户会很高兴知道，Substrate的XCM允许链完全避免这种损失。该机制分两步工作。首先，当Holding Register中的任何资产被清除时，都不会被完全遗忘。如果在XCVM停止时Holding Register不为空，则发出一个包含三个信息的事件：Holding Register的值；Origin Register的原始价值；以及这两条信息的哈希值。Substrate的XCM系统然后将这个哈希值放在存储中。这部分机制称为资产陷阱。

理赔系统

该机制的第二步是能够要求Holding Register的一些先前内容。这实际上不是通过任何专门为此目的而设计的，而是通过我们尚未遇到的通用指令ClaimAsset. 这是它在《Rust》中的声明方式：

此指令的名称可能让人想起我们遇到的某些其他“资助”指令，例如WithdrawAsset和ReceiveTeleportedAsset。与其他方法一样，它试图将资产（由assets此处的参数给出）放入Holding Registe。与WithdrawAsset减少账户链上资产余额的不同，无论Origin Register的值是多少，都会为这些资产ClaimAsset寻找有效的索赔。为了帮助系统找到有效的索赔，可以通过ticket参数提供信息。如果找到有效的索赔，则将其从链中删除，并将资产添加到Holding Register中。

现在，什么构成索赔完全取决于链本身。不同的链可能支持不同种类的要求，Substrate允许你轻松组合它们。但是，正如你可能猜到的那样，一种特定的声明已经准备好了，当然，那就是先前被丢弃的Holding Register内容。

那么让我们来看看这在实践中是如何运作的。假设我们用户的平行链2000向Statemint发送一条消息，其中它从其主权账户中提取0.01 DOT以支付费用，并通知它有100单位的原生代币被转移到Statemint的主权账户中。如下图所示：

假设0.01 DOT是足够的费用，并且Statemint支持平行链2000的本地资产的链上存款（以及使用平行链2000作为它的储备），那么这应该可以正常工作。然而，也许Statemint尚未成立以识别平行链2000的原生资产。在这种情况下，DepositAsset将不知道如何处理资产并因此引发错误。在执行将向平行链2000通知此故障的附录之后，我们将剩下100个平行链2000的本地资产，以及可能在Holding Registe中的一些DOT。假设费用仅为0.005 DOT，剩余0.005 DOT。

然后，Statemint的XCM仪表盘会记录这些新的可索赔资产的事件，例如：

一条消息将被发送回平行链2000，如下所示：

平行链2000将在稍后的某个阶段（也许一旦它确定Statemint能够接受其本地资产的存款），能够通过一种相当简单的方法收回这100个单位：

在这种情况下，ticket参数没有提供帮助定位索赔的特殊信息。这通常适用于资产陷阱索赔，尽管在其他类型的索赔中可能需要使用。

结论

希望这些内容有助于你更多地了解XCM的底层虚拟机，以及它如何帮助您管理和从意外情况中恢复。本系列的下一篇文章将介绍XCM的未来方向以及如何对格式提出改进建议，并深入探讨Substrate的XCM Rust实现以及如何使用它来提供一个链能够轻易地解释XCM。