XCM: 跨共識消息格式 (第一部分)

隨著 Polkadot 1.0 的最終發佈,以及平行鏈的完成,跨共識消息格式,簡稱 XCM,正在接近其第一個可生產的版本。這是對該格式的介紹,它的目標,它是如何工作的,可以用來實現典型的跨鏈任務。

首先要說明一個有趣的事實……XCM 是 "跨共識"的消息傳遞格式,而不僅僅是 "跨鏈"。這一區別表明瞭該格式的目標,它是為交流各種想法而設計的,不僅在鏈之間,而且在智能合約和 pallet 之間,以及在橋和分片的聚居地(如 Polkadot 的 Spree)上發送。

一個格式,而不是協議

為瞭更好地瞭解 XCM,必須瞭解它的邊界以及它在 Polkadot 技術棧中的位置。XCM 是一種消息傳遞格式。它不是一個消息傳輸協議。它不能用來在系統之間實際 "發送" 任何消息;它的作用隻是表達接收方應該做什麼。

不包括橋和合約 pallet,Polkadot 有三個不同的系統,用於在其組成鏈之間實際交流 XCM 消息。UMP、DMP 和 XCMP。UMP(向上消息傳遞)允許平行鏈鏈向其中繼鏈發送消息。DMP(向下消息傳遞) 允許中繼鏈將消息向下傳遞給他們的一個平行鏈。XCMP,也許是其中最著名的,這允許平行鏈在它們之間發送消息。XCM 可以用來表達這三個通信通道上的每一個消息的含義。

除瞭在鏈之間發送消息外,XCM 在其他情況下也很有用,比如與一個你不一定提前知道交易格式的鏈進行交易。對於業務邏輯變化不大的鏈(比如,比特幣),交易格式 — 或者說錢包用來向鏈發送指令的格式 — 往往會無限期地保持完全相同,或者至少是兼容。有瞭高度可進化的基於元協議的鏈,如 Polkadot 及其組成的平行鏈,商業邏輯可以通過一個交易在整個網絡中升級。這可以改變任何東西,包括交易格式,為錢包維護者帶來瞭潛在的問題,特別是對於那些需要保持離線的錢包(如 Parity Signer)。由於 XCM 是良好版本管理的,抽象的和通用的,它可以作為一種手段,為錢包提供一個持久的交易格式,用來創建許多常見的交易。

目標

XCM 的目標是成為一種在共識系統之間交流思想的語言。它應該具有足夠的通用性,以便在一個不斷增長的生態系統中適當地發揮作用。它應該是可擴展的。由於可擴展性將不可避免地意味著變化,它也應該是面向未來和向前兼容的。最後,它應該足夠高效,可以在鏈上運行,也可能在計量環境中運行。

像所有的語言一樣,有些人傾向於使用一些元素而不是其他。XCM 的設計方式並不是讓每個支持 XCM 的系統都能解釋任何可能的 XCM 消息。有些信息在某些系統下將沒有合理的解釋。其他情況信息可能是合理的,但由於資源限制,或由於同樣的內容可以用更清晰、更規范的方式表達,解釋器仍然有意不支持。系統將不可避免地隻支持可能的消息的一個子集。資源嚴重受限的系統(如智能合約)可能隻支持非常有限的 "方言"。

這種通用性甚至延伸到瞭執行 XCM 消息的費用支付等概念。由於我們知道 XCM 可能用於不同的系統,包括 gas 計量的智能合約平臺和社區平行鏈,一直到系統平行鏈和其中繼鏈之間的可信互動,我們不想在協議中過深和不可逆地烘托諸如費用支付等元素。

為什麼不直接使用本地信息格式?

在某些情況下,利用鏈或智能合約的原生消息/交易格式是很有用的,但也有一些很大的缺點,使其對 XCM 的目標不太有用。首先,鏈與鏈之間缺乏兼容性,所以一個打算向多個目的地發送消息的系統需要瞭解如何為每個目的地編寫消息。在這一點上,即使是單一的目的地也可能隨著時間的推移而改變其本地交易/消息格式。智能合約可能會得到升級,區塊鏈可能會引入新的功能或改變現有的功能,這樣就會改變其交易格式。

其次,區塊鏈上的常見使用情況不容易被納入單一交易;可能需要特殊的技巧來提取資金,交換資金,然後將結果存入單一交易中。連貫的儲備資產框架所需的轉賬通知,在不瞭解其他鏈的情況下是不存在的。

第三,像支付費用這樣的操作並不容易適應一個假設費用支付已經像智能合約信息一樣被協商好的模型。相比之下,交易信封提供瞭一些處理支付的系統,但一般也被設計為包含簽名,這在共識系統之間通信時是沒有意義的。

一些初步的使用案例

雖然 XCM 的目標是通用的、靈活的和面向未來的,但當然也有它必須解決的實際需求,特別是鏈之間的代幣轉移。可選的費用支付(也許使用這些代幣)是另一個問題,還有一個問題是進行交換服務的通用接口,這在整個 DeFi 世界是很常見的。最後,應該可以使用 XCM 語言來進行一些平臺特定的行動;例如,在一個 Substrate 鏈中,可能希望向其一個 pallet 發出一個遠程調用,以訪問一個利基功能。

除此之外,還有許多我們想要支持的轉移代幣的模式。我們可能想簡單地控制一個遠程鏈上的賬戶,允許本地鏈在遠程鏈上有一個地址用於接收資金,並最終將其控制的這些資金轉移到該遠程鏈上的其他賬戶。

我們可能有兩個共識系統,這兩個系統都是某一特定代幣的本地傢園。想象一下,像 USDT 或 USDC 這樣的代幣,在幾個不同的鏈上都有實例,都是完全可替換的。應該可以在一個鏈上銷毀這樣的代幣,並在另一個支持的鏈上鑄造一個相應的代幣。在 XCM 的術語中,我們稱之為遠程傳輸 (teleport),因為資產的表面移動實際上是通過在一側摧毀它並在另一側創建一個克隆來實現的。

最後,可能有兩條鏈想提名第三條鏈,一條鏈上的資產可能被認為是原生的,作為該資產的儲備。這些鏈上的資產的衍生形式將得到充分支持,允許衍生資產與支持它的儲備鏈上的基礎資產進行交換。這種情況可能是兩個鏈不一定相互信任,但(至少就有關資產而言)願意信任該資產的原生鏈。這裡的一個例子是,我們有幾個社區平行鏈,它們想在彼此之間發送 DOT。他們每個人都有一個本地形式的 DOT,由 Statemint 鏈(DOT 的本地樞紐)上的平行鏈控制的 DOT 完全支持。當本地形式的 DOT 在鏈之間發送時,在後臺,"真正的" DOT 在 Statemint 的平行鏈賬戶之間移動。

即使是這種明顯的適度的功能水平,也有相對大量的配置,其可用性是可取的,需要一些有趣的設計,以避免過度擬合。

XCM 的剖析

XCM 格式的核心是 XCVM。與一些人的看法相反,這不是一個(有效的)羅馬數字(盡管如果是的話,它可能意味著 905)。事實上,這代表瞭跨共識虛擬機。它是一種超高層的非圖靈完備計算機,其指令被設計成與交易大致處於同一水平。

XCM 中的 "消息" 實際上隻是一個在 XCVM 上運行的程序。它是一條或多條 XCM 指令。該程序一直運行到最後或遇到錯誤為止,這時它就會結束(我暫時故意不解釋)並停止。

XCVM 包括一些寄存器,以及對承載它的共識系統整體狀態的訪問。指令可能會改變一個寄存器,也可能會改變共識系統的狀態,或者兩者都改變。

這種指令的一個例子是 TransferAsset,它被用來將資產轉移到遠程系統的一些其他地址。它需要被告知要轉移哪些資產,以及資產要被轉移到誰/哪裡。在 Rust 中,它是這樣聲明的:

enum Instruction {
TransferAsset {
assets: MultiAssets,
beneficiary: MultiLocation,
}
/* snip */
}

赞(0)