作为波卡生态共识系统之间交流思想的语言，XCM的主要性不容分说。在《GavinWood：详解跨共识消息格式XCM设计原理与运转机制》一文中，GavinWood对于XCM设计原理与运转机制进行了非常详细的解说。而在《GavinWood：探究XCM的版本控制与兼容性》一文中，GavinWood又对其版本控制与兼容性进行了深入探究。
接下来在本文中，GavinWood将会就XCM底层设计和执行模型来进行深入研究，以帮助大家更有效的了解XCM的底层虚拟机。
作者：GavinWood
来源：Polkadot
编译：陈一晚风
由于XCM是基于XCVM的指令集，而XCVM是一个非常高级的虚拟机，为了熟悉这种机器架构，所以我们先来简单介绍一下XCVM。
XCVM是一个非常高级的、非图灵完备的虚拟机。它是基于寄存器而不是基于堆栈，并且有几个专用寄存器，其中大部分存储高度结构化的数据。与通用处理器不同，XCVM的寄存器不能随意设置为任意值，但有严格的机制来控制它们如何改变。除了与本地链状态交互的某些方式之外，没有额外的“内存”。没有循环的可能性，也没有明确的分支指令。
在之前的文章中我们已经介绍了HoldingRegister和OriginRegister两种寄存器。HoldingRegister能够临时持有一个或多个资产，并且可以通过从本地链中提取资产来填充，或者通过从受信任的外部接收资产来填充来源；OriginRegister在执行开始时持有当前XCM执行起源的共识系统的位置，并且可能只能突变到一个内部位置或完全清除。
V神：使用开放的多个ZK-EVM将面临延迟和数据效率低下两大挑战:金色财经报道，V神在其最新博客文章中建议采取开放的多个ZK-EVM创建一个“多客户端”生态系统，但同时他指出这种解决方案将面临延迟和数据效率低下两大挑战，恶意攻击者可能会延迟发布一个区块，以及对一个客户端有效的证明，如果时间足够长可能会创建一个临时分叉并中断几个插槽的链。此外，如果希望能够为一个区块生成多种类型的证明，则需要实际发布原始签名，继而造成数据效率低下。[2023/4/2 13:40:22]
而在在其他寄存器中，三个与异常/错误管理有关，两个与跟踪执行权重有关。我们将在本文中重点讲解这些寄存器的执行模型。
执行模型
如前所述，没有显式条件指令或循环原语可以重复执行同一条指令多次。这使得预先确定程序的控制流变得相当简单。这个属性很有用，因为我们想要确定XCM息在执行点之前可以使用多少执行时间。
我们期望执行XCM的大多数共识平台都需要能够在开始执行之前确定最坏情况的执行时间。这是因为区块链通常需要确保单个块的处理时间不会超过某个预定限制，以免导致整个系统停顿。此外，如果系统需要支付费用，那么它必须发生在支付费用的工作负载之前，而且这一支付必须涵盖最坏情况下的执行时间。
由于这种图灵完备性，允许使用图灵完备语言的系统实际上无法直接从程序中计算出最坏情况的执行时间。他们通过要求用户预先确定程序的执行资源，然后在执行时计量并在超过支付的数量时中断它来解决这个问题。有时交易会在交易执行之前就发生变化，且权重变得不正确。令人高兴的是，像XCVM这样的非图灵完备的虚拟机可以避免这种计量和权重规定的需要。
权重
权重通常表示为一个有代表性的硬件执行给定操作所需要的皮秒的整数。正如我们在BuyExecution指令中看到的那样，XCVM在处理某些指令时包含了执行时间/权重的概念。
V神：股票市场正变得像加密货币:6月12日消息，V神刚刚发推称，我们的预期是：加密货币将正常化并变得更像股市。实际正在发生的是：外部世界变得疯狂，股票市场变得更像加密货币。[2020/6/12]
没有权重计量，但为了允许XCVM程序最终取的权重小于最坏情况的权重预测，我们有一个称为剩余权重寄存器的寄存器。因为我们可以准确地预测它们会使用多少权重，所以大多数说明书都不会触及它。然而，偶尔会出现最坏情况权重预测高估的情况，只有在执行时我们才知道有多少。在计算高估了XCM消息权重的块执行时间时，跟踪原始权重被高估的数量，并从账户中减去它，允许链优化其块执行时间配额。
因此，剩余权重寄存器对于我们的块执行时间核算很有用，但它并不能单独解决另一个问题，即确保所支付的金额不会被高估。为此，我们需要一个与BuyExecution相关的指令，它该指令将收取多余权重并退款。自然，这条指令是存在的，叫做“退款剩余”。它使用的第二个寄存器称为“退款权重寄存器”，以确保不会多次退款相同的剩余权重。
流量控制和异常
到目前为止，还有两个寄存器在我们对XCVM的处理中相当含蓄，但仍然很重要。首先是程序寄存器，用于存储当前正在执行的XCVM程序。其次是程序计数器，它存储当前正在执行的指令索引。当程序寄存器改变时，它被重置为零，并在每个成功执行的指令结束时加1。
处理“异常”情况可能性的能力对于编写成熟的代码至关重要。当远程系统上发生了你没有预料到的事情时，你就需要某种方式来管理它，即使它只是简单地向原始状态发送一个报告。
虽然XCVM指令集不包括任何明确的通用分支指令，但它的执行模型中确实有一个通用的异常处理框架。XCVM包括另外两个代码寄存器，每个寄存器都保存一个XCVM程序，如程序寄存器。这两个寄存器称为附录寄存器和错误处理程序寄存器。如果你熟悉几种流行语言中的try/catch/finally异常系统，那么接下来的内容可能会让你容易理解。
V神：分片技术的缺点是需在最开始设置参数或依赖治理:以太坊创始人V神刚刚发推称，分片技术（sharding）的一个缺点是，由于没有好的协议和方法告诉你有多少节点，你必须在最开始设置确定容量和最小安全节点数之间的参数，或依赖治理。[2020/3/16]
如前所述，XCVM程序的执行是按照其中的每条指令一步一步执行的。当它遵循这些指令到程序结束时，会发生以下两种情况之一：要么成功到达程序末尾，要么发生错误。在第一个成功执行的情况下，错误寄存器被清除，它的权重被添加到剩余权重寄存器。附录寄存器也被清除，其内容被放置在程序寄存器中。如果程序寄存器为空，则停止，否则程序计数器复位为零。简而言之，我们抛出当前的程序和错误处理程序，如果有的话就开始执行附录程序。
此功能本身并不是很有用，但与发生错误时发生的情况相结合时会很有用。在这里，尚未执行的任何指令的权重都被添加到剩余权重寄存器中。错误处理程序寄存器被清除，其内容放置在程序寄存器中，程序计数器复位为零。简单地说，我们抛出当前程序并开始执行错误处理程序。因为我们没有清除附录寄存器，所以除非它被错误处理程序重置，否则它会在成功完成后执行。
由于其组合结构，它允许错误处理程序的任意“嵌套”：如果需要，错误处理程序也可以有错误处理程序，附录可以有自己的附录。
有两条指令允许操作这些寄存器：SetAppendix和SetErrorHandler.。前者设置附录寄存器，后者设置错误处理程序寄存器。其中每一个的预测权重都比其参数的权重略高。然而，当执行时，寄存器中将被替换的XCM消息的权重被添加到剩余权重寄存器中，从而允许回收任何未使用的附录或错误处理程序的权重。
投掷错误
有时，确保错误发生并自定义错误的某些方面可能是有用的。这已经在编写测试代码时使用，但它最终可能会在活动链中找到使用。这这可以通过指令Trap在XCVM中完成，该指令总是导致错误发生。抛出的错误类型共享名称Trap。指令和错误都携带一个整数参数，允许在错误抛出者和外部观察者之间传递某种形式的信息。
声音 | V神：短期内需并行开发区块链第1层和第2层协议:12月26日，以太坊创始人V神在其个人网站发文探讨区块链协议分层相关问题称，“保持第1层功能简单，在第2层上加以弥补”并不是解决区块链可扩展性和功能性问题的普遍答案，因为它没有考虑到第1层本身必须为此具有足够的可扩展性和功能性，才能实现这种“基于顶层的构建”(除非所谓的“第二层协议”只是可信的中介)。但是，在一定程度上，任何第1层的功能都可以复制到第2层，而且在很多情况下，这是一个好想法，这样做可以提高可升级性。因此，短期内需要第1层（ layer 1）开发与第2层 （layer 2）开发并行进行，从长远来看，需要更多地关注第2层。[2019/12/27]
这是一个简单的例子：
Trap导致最终的DepositAsset被跳过，而错误处理程序的DepositAsset被运行，将1DOT置于平行链2000的所有权下。我们将始终倾向于RefundSurplus在错误处理程序代码的开头使用，因为如果它是运行，我们知道很可能使用的预测权重是高估的。
错误报告
能够引入处理错误的代码是非常有用的，但其中经常被要求使用的功能是能够将XCM消息的结果报告给原始发送者。QueryResponse指令允许一个共识系统向另一个系统报告一些信息，剩下的就是能够以某种方式将XCM的结果插入其中QueryResponse并将其发送给希望被告知的人结果。
事实证明，只有一个指令完成了这个任务，它叫ReportError。它通过使用我们尚未遇到的寄存器来工作：错误寄存器。错误寄存器是一种可选类型。如果已设置，则它包含两条信息：数字索引和XCM错误类型。
Gavin Wood：交易化存储变更等是Web3.0技术栈中仍然缺失的部分:在10月17日由Polkaworld主办的“波卡中国行”深圳站上，波卡创始人Gavin Wood列举了他认为波卡和Web3.0技术栈中仍然缺失，目前正在努力的部分：简化从基准得到Weight的流程、交易化存储变更、让交易能够并行运行的workerthread、改进runtime编写框架FRAME、重启加密DHT“Whisper”项目。[2020/10/17]
它具有极其简单的操作机制。首先，每当指令导致错误时，它总是被设置；错误类型设置为该错误的类型，数字索引设置为程序计数器寄存器的值。其次，只有当ClearError指令被执行时它才被清除。该指令是绝对可靠的指令之一，因为它本身永远不会导致错误。它在发生错误时被设置，并在你发出适当的指令时被清除。
现在应该可以清楚地理解ReportError指令是如何工作的：它只是QueryResponse使用错误寄存器的内容组成一条指令并将其发送到特定目的地。当然，在它之前发生的任何错误都会导致指令被跳过，因为执行首先跳转到错误处理程序寄存器的代码，然后跳转到附录寄存器的代码。然而，解决这个问题的方法很简单：将reportterror放在附录中将确保它被执行，而不管主代码是否导致执行错误。
我们来看一个简单的例子。我们会将资产从中继链传送到Statemint，在那里购买一些执行时间，然后使用Statemint作为储备，我们将资产存入平行链2000。原始)消息如下所示：
有了基本的错误报告，我们将改为使用这个：
正如你所看到的，唯一的变化是引入了两条SetAppendix指令，以确保Statemint和平行链2000中的错误或缺失将报告给中继链。这假设中继链已将自身设置为能够识别和处理来自Statemint和parchain2000的QueryResponse消息，查询ID为42，权重限制为1000万。令人高兴的是，这确实是Substrate很好的支持，但现在已经超出了范围。
资产陷阱
当在处理资产的程序中发生错误时，那么问题就会很大。可能存在BuyExecution指令本身导致错误的情况，可能是因为权重限制不正确或用于支付的资产不足。或者，资产可能被发送到一条无法以有用的方式处理它的链上。在这些情况下，息的XCVM执行结束时资产仍留在HoldingRegister中，与其他寄存器一样，这些资产是瞬态的，我们期望被遗忘。
团队和他们的用户会很高兴知道，Substrate的XCM允许链完全避免这种损失。该机制分两步工作。首先，当HoldingRegister中的任何资产被清除时，都不会被完全遗忘。如果在XCVM停止时HoldingRegister不为空，则发出一个包含三个信息的事件：HoldingRegister的值；OriginRegister的原始价值；以及这两条信息的哈希值。Substrate的XCM系统然后将这个哈希值放在存储中。这部分机制称为资产陷阱。
理赔系统
该机制的第二步是能够要求HoldingRegister的一些先前内容。这实际上不是通过任何专门为此目的而设计的，而是通过我们尚未遇到的通用指令ClaimAsset.?这是它在《Rust》中的声明方式：
此指令的名称可能让人想起我们遇到的某些其他“资助”指令，例如WithdrawAsset和ReceiveTeleportedAsset。与其他方法一样，它试图将资产放入HoldingRegiste。与WithdrawAsset减少账户链上资产余额的不同，无论OriginRegister的值是多少，都会为这些资产ClaimAsset寻找有效的索赔。为了帮助系统找到有效的索赔，可以通过ticket参数提供信息。如果找到有效的索赔，则将其从链中删除，并将资产添加到HoldingRegister中。
现在，什么构成索赔完全取决于链本身。不同的链可能支持不同种类的要求，Substrate允许你轻松组合它们。但是，正如你可能猜到的那样，一种特定的声明已经准备好了，当然，那就是先前被丢弃的HoldingRegister内容。
那么让我们来看看这在实践中是如何运作的。假设我们用户的平行链2000向Statemint发送一条消息，其中它从其主权账户中提取0.01DOT以支付费用，并通知它有100单位的原生代币被转移到Statemint的主权账户中。如下图所示：
假设0.01DOT是足够的费用，并且Statemint支持平行链2000的本地资产的链上存款，那么这应该可以正常工作。然而，也许Statemint尚未成立以识别平行链2000的原生资产。在这种情况下，DepositAsset将不知道如何处理资产并因此引发错误。在执行将向平行链2000通知此故障的附录之后，我们将剩下100个平行链2000的本地资产，以及可能在HoldingRegiste中的一些DOT。假设费用仅为0.005DOT，剩余0.005DOT。
然后，Statemint的XCM仪表盘会记录这些新的可索赔资产的事件，例如：
一条消息将被发送回平行链2000，如下所示：
平行链2000将在稍后的某个阶段，能够通过一种相当简单的方法收回这100个单位：
在这种情况下，ticket参数没有提供帮助定位索赔的特殊信息。这通常适用于资产陷阱索赔，尽管在其他类型的索赔中可能需要使用。
结论
希望这些内容有助于你更多地了解XCM的底层虚拟机，以及它如何帮助您管理和从意外情况中恢复。本系列的下一篇文章将介绍XCM的未来方向以及如何对格式提出改进建议，并深入探讨Substrate的XCMRust实现以及如何使用它来提供一个链能够轻易地解释XCM。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。