作为波卡生态共识系统之间交流思想的语言，XCM的主要性不容分说。在《GavinWood：详解跨共识消息格式XCM设计原理与运转机制》一文中，GavinWood对于XCM设计原理与运转机制进行了非常详细的解说。而在《GavinWood：探究XCM的版本控制与兼容性》一文中，GavinWood又对其版本控制与兼容性进行了深入探究。
接下来在本文中，GavinWood将会就XCM底层设计和执行模型来进行深入研究，以帮助大家更有效的了解XCM的底层虚拟机。
作者：GavinWood
来源：Polkadot
编译：陈一晚风
由于XCM是基于XCVM的指令集，而XCVM是一个非常高级的虚拟机，为了熟悉这种机器架构，所以我们先来简单介绍一下XCVM。
XCVM是一个非常高级的、非图灵完备的虚拟机。它是基于寄存器而不是基于堆栈，并且有几个专用寄存器，其中大部分存储高度结构化的数据。与通用处理器不同，XCVM的寄存器不能随意设置为任意值，但有严格的机制来控制它们如何改变。除了与本地链状态交互的某些方式之外，没有额外的“内存”。没有循环的可能性，也没有明确的分支指令。
在之前的文章中我们已经介绍了HoldingRegister和OriginRegister两种寄存器。HoldingRegister能够临时持有一个或多个资产，并且可以通过从本地链中提取资产来填充，或者通过从受信任的外部接收资产来填充来源；OriginRegister在执行开始时持有当前XCM执行起源的共识系统的位置，并且可能只能突变到一个内部位置或完全清除。
波卡创始人Gavin Wood：平行链将于12月在技术上达到可用状态:金色财经现场报道，10月26日，在万向区块链实验室主办的第七届区块链全球峰会活动上，波卡创始人 Gavin Wood 表示，非常自信平行链将于 12 月开始在技术上实现可行性，目前已经完成完整代码审计。另外，Gavin Wood 还分享了 Substrate 和 Polkadot 状态进展，第二次桥审计正在进行中，即将部署一个从测试网 Rococo 到桥测试网 Wococo 的桥，来测试可行性。[2021/10/26 20:57:50]
而在在其他寄存器中，三个与异常/错误管理有关，两个与跟踪执行权重有关。我们将在本文中重点讲解这些寄存器的执行模型。
执行模型
如前所述，没有显式条件指令或循环原语可以重复执行同一条指令多次。这使得预先确定程序的控制流变得相当简单。这个属性很有用，因为我们想要确定XCM息在执行点之前可以使用多少执行时间。
我们期望执行XCM的大多数共识平台都需要能够在开始执行之前确定最坏情况的执行时间。这是因为区块链通常需要确保单个块的处理时间不会超过某个预定限制，以免导致整个系统停顿。此外，如果系统需要支付费用，那么它必须发生在支付费用的工作负载之前，而且这一支付必须涵盖最坏情况下的执行时间。
由于这种图灵完备性，允许使用图灵完备语言的系统实际上无法直接从程序中计算出最坏情况的执行时间。他们通过要求用户预先确定程序的执行资源，然后在执行时计量并在超过支付的数量时中断它来解决这个问题。有时交易会在交易执行之前就发生变化，且权重变得不正确。令人高兴的是，像XCVM这样的非图灵完备的虚拟机可以避免这种计量和权重规定的需要。
权重
权重通常表示为一个有代表性的硬件执行给定操作所需要的皮秒的整数。正如我们在BuyExecution指令中看到的那样，XCVM在处理某些指令时包含了执行时间/权重的概念。
Gavin Wood：WebAssembly是智能合约的未来:金色财经报道，波卡创始人Gavin Wood在2021年共识大会上发表讲话时表示，EVM对Polkadot区块链系统提供支持非常重要，至少在可预见的将来。他认为WebAssembly是智能合约的未来，但“传统” EVM现在就在眼前。据悉，WebAssembly是一种软件格式，可以在网络上使用，并且可以轻松地与多种软件语言一起使用。它是由大型网络公司构建的，并且可以在所有主要的浏览器上运行。[2021/5/26 22:44:19]
没有权重计量，但为了允许XCVM程序最终取的权重小于最坏情况的权重预测，我们有一个称为剩余权重寄存器的寄存器。因为我们可以准确地预测它们会使用多少权重，所以大多数说明书都不会触及它。然而，偶尔会出现最坏情况权重预测高估的情况，只有在执行时我们才知道有多少。在计算高估了XCM消息权重的块执行时间时，跟踪原始权重被高估的数量，并从账户中减去它，允许链优化其块执行时间配额。
因此，剩余权重寄存器对于我们的块执行时间核算很有用，但它并不能单独解决另一个问题，即确保所支付的金额不会被高估。为此，我们需要一个与BuyExecution相关的指令，它该指令将收取多余权重并退款。自然，这条指令是存在的，叫做“退款剩余”。它使用的第二个寄存器称为“退款权重寄存器”，以确保不会多次退款相同的剩余权重。
流量控制和异常
到目前为止，还有两个寄存器在我们对XCVM的处理中相当含蓄，但仍然很重要。首先是程序寄存器，用于存储当前正在执行的XCVM程序。其次是程序计数器，它存储当前正在执行的指令索引。当程序寄存器改变时，它被重置为零，并在每个成功执行的指令结束时加1。
处理“异常”情况可能性的能力对于编写成熟的代码至关重要。当远程系统上发生了你没有预料到的事情时，你就需要某种方式来管理它，即使它只是简单地向原始状态发送一个报告。
GavinWood：Kusama平行链预计下周一上线:波卡创始人GavinWood在波卡社区大会PolkadotDecoded表示，Kusama平行链预计下周一上线。“这个平行链指的是Shell平行链（白板链），我在过去几周里写出了它的Runtime，它非常非常简单，可能是目前为止最简单的Runtime了。它其实几乎做不了什么，唯一能做的就是等待着被批准升级。但这是比较重要的第一步，我们可以看到区块的添加和最终确认的验证过程，在我们真正在上面部署一些很重要的东西，比如Statemine平行链（这是Statemint的Kusama版本）之前，我们会做一些测试。我们发现了一些Bug，但是会很快解决。我们马上要发布0.9.2，应该很快，要么今天要么明天。我们会重点观察其在几个方面的运行情况，差不多等Shell稳定运行24小时之后，我们会将Shell链升级为Statemine。”
此外，公益平行链Statemine预计本周内上线；预计在Kusama拍卖后一两周后开始波卡拍卖。（PolkaWorld）[2021/5/20 22:25:10]
虽然XCVM指令集不包括任何明确的通用分支指令，但它的执行模型中确实有一个通用的异常处理框架。XCVM包括另外两个代码寄存器，每个寄存器都保存一个XCVM程序，如程序寄存器。这两个寄存器称为附录寄存器和错误处理程序寄存器。如果你熟悉几种流行语言中的try/catch/finally异常系统，那么接下来的内容可能会让你容易理解。
如前所述，XCVM程序的执行是按照其中的每条指令一步一步执行的。当它遵循这些指令到程序结束时，会发生以下两种情况之一：要么成功到达程序末尾，要么发生错误。在第一个成功执行的情况下，错误寄存器被清除，它的权重被添加到剩余权重寄存器。附录寄存器也被清除，其内容被放置在程序寄存器中。如果程序寄存器为空，则停止，否则程序计数器复位为零。简而言之，我们抛出当前的程序和错误处理程序，如果有的话就开始执行附录程序。
Gavin Wood撰文回应雪崩协议质疑：雪崩协议不安全也无可拓展性:金色财经报道，7月28日，雪崩协议一名成员收集了雪崩协议社区内部一些对波卡的质疑，发布在了波卡 Riot 官方群，个中不乏对波卡可拓展性、插槽机制、跨链性能的贬损。Polkadot 联合创始人Gavin Wood对此事的回应，雪崩协议所谓的子网安全性和波卡的共享安全性完全不是一回事。何谈性能上的比较。实际上，雪崩协议类似一个中心化的Cosmos，由选出来的重叠的验证人组充当了子网安全性。这将导致整个系统内各个链间的安全性有极大的不均。跨分片攻击是可行的，因为来自一个（低安全性）链的消息可以导致另一个（更安全的）子网上的状态迁移。这样一来整个网络的安全性就等同于安全性最差的那个链。
跟 Cosmos 的问题一样，任何试图设计一个中央区域以执行敏感逻辑的解决方案都会遇到可拓展性瓶颈，且会让一部分链劣化为状态转换无法信任的二等公民。不管程序在哪个链上执行，都有同等级的安全性保障，这才是一个可拓展的系统。
综上，雪崩协议并不安全，也不具备可拓展性。[2020/7/29]
此功能本身并不是很有用，但与发生错误时发生的情况相结合时会很有用。在这里，尚未执行的任何指令的权重都被添加到剩余权重寄存器中。错误处理程序寄存器被清除，其内容放置在程序寄存器中，程序计数器复位为零。简单地说，我们抛出当前程序并开始执行错误处理程序。因为我们没有清除附录寄存器，所以除非它被错误处理程序重置，否则它会在成功完成后执行。
由于其组合结构，它允许错误处理程序的任意“嵌套”：如果需要，错误处理程序也可以有错误处理程序，附录可以有自己的附录。
有两条指令允许操作这些寄存器：SetAppendix和SetErrorHandler.。前者设置附录寄存器，后者设置错误处理程序寄存器。其中每一个的预测权重都比其参数的权重略高。然而，当执行时，寄存器中将被替换的XCM消息的权重被添加到剩余权重寄存器中，从而允许回收任何未使用的附录或错误处理程序的权重。
动态 | 波卡测试网Kusama已恢复出块，Gavin Wood发文详述Bug解决方案:曾于昨日出现宕机的波卡测试网Kusama目前已恢复出块，波卡创始人Gavin Wood针对此次漏洞的排查和修复发布了报告。此前报道，由于将Polkadot主网的运行环境库放置在 Kusama 升级中，整个 Kusama 的测试网于昨日陷入宕机。团队于昨日承诺将于次日着手解决该漏洞。目前，经过更新，Kusama 网络已经恢复出块。在修复版本更新前夕，波卡创始人 Gavin Wood 在 Medium 上分享了此次 Kusama 重大漏洞的修复报告。经过节点社区的共同努力，在几次简单的修复和同步后，Kusama 现已重启。[2020/1/7]
投掷错误
有时，确保错误发生并自定义错误的某些方面可能是有用的。这已经在编写测试代码时使用，但它最终可能会在活动链中找到使用。这这可以通过指令Trap在XCVM中完成，该指令总是导致错误发生。抛出的错误类型共享名称Trap。指令和错误都携带一个整数参数，允许在错误抛出者和外部观察者之间传递某种形式的信息。
这是一个简单的例子：
Trap导致最终的DepositAsset被跳过，而错误处理程序的DepositAsset被运行，将1DOT置于平行链2000的所有权下。我们将始终倾向于RefundSurplus在错误处理程序代码的开头使用，因为如果它是运行，我们知道很可能使用的预测权重是高估的。
错误报告
能够引入处理错误的代码是非常有用的，但其中经常被要求使用的功能是能够将XCM消息的结果报告给原始发送者。QueryResponse指令允许一个共识系统向另一个系统报告一些信息，剩下的就是能够以某种方式将XCM的结果插入其中QueryResponse并将其发送给希望被告知的人结果。
事实证明，只有一个指令完成了这个任务，它叫ReportError。它通过使用我们尚未遇到的寄存器来工作：错误寄存器。错误寄存器是一种可选类型。如果已设置，则它包含两条信息：数字索引和XCM错误类型。
它具有极其简单的操作机制。首先，每当指令导致错误时，它总是被设置；错误类型设置为该错误的类型，数字索引设置为程序计数器寄存器的值。其次，只有当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。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。