作為波卡生態共識系統之間交流思想的語言，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，
