Partnered With:

Gavin Wood 分享 Polkadot跨鏈消息傳遞方案

閱讀本文需 22 分鐘

跨鏈消息傳遞方案定義了在除共享中繼鏈的安全性之外沒有其他的信任假設的情況下，消息如何得以在平行鏈之間傳遞。

原文標題：《Polkadot 的跨鏈消息傳遞方案（XCMP）》
原文來源： PolkaWorld
作者:今天Shirazi,洛根Saether Alistair斯圖爾特,Rob Habermier Gavin木頭

最近幾個月，Web3 基金會的研究團隊一直在做跨鏈消息傳遞（XCMP）功能的文字概述。它是 Web3 基金會王牌項目 Polkadot 的關鍵組件。我們很高興與您分享我們的工作！

跨鏈消息傳遞（XCMP）方案是 Polkadot 協議的一個子集。它定義了在除了共享中繼鏈的安全性之外沒有其他的信任假設的情況下，消息如何得以在平行鏈之間傳遞。這篇文章闡述了平行鏈的消息傳遞協議，並在很大程度上依賴於 Polkadot 獨特的中繼鏈體系結構和設計。

協議包括：

·就共識而言：消息的排隊和排序機制。

·與中繼鏈的其他部分結合，特別是 GRANDPA 的最終確定機制：數據可用性。

·與平行鏈驗證功能結合使用：消息輸入和輸出。

此外，本文還回顧了交付、如何實現一致的歷史記錄以及防止 DoS 攻擊的想法。最後，我們結合 SPREE 回顧了 XCMP，並總結了 XCMP 所實現的特性來結尾。

消息語義和網絡細節（如對等發現）在本文中沒有提到。

介紹

Polkadot「1.0 版」的一個關鍵特性，是讓原本隔離的平行鏈以安全和去信任的方式在彼此之間發送消息。

出於此目的，我們定義 message 的方式與定義 transaction 的方式基本相同。兩者都是指來自接收鏈以外的數據，而且都暗示並要求鏈按照其內部邏輯對數據做出反應。考慮到實際系統的延遲水平，鏈不能拒絕或混淆數據的含義。例如，在比特幣的語境中，這種屬性意味着比特幣中的有缺陷或惡意的礦工不能重新分配資金，因此這是一個好的加密經濟共識系統的基礎。

transaction 和 message 之間的關鍵區別在於，transaction 包含一個簽名，以證明數據的出處（從而證明指令的權威性）。而對於 message，出處僅通過 Polkadot 的抗拜占庭加密經濟驗證基礎設施來證明，在很大程度上跟以太坊合約間消息傳遞的方式是一樣的。

例子

在詳細討論 XCMP 的每個組件之前，讓我們先舉一個例子，說明如何將某智能合約平行鏈（圖 1 中的 A）上的出站消息連接到某分佈式金融（DeFi）平行鏈（圖 1 中的 B）的入站隊列，以便從 DeFi 平行鏈的收集人（collator）進入下一個候選區塊。

在中繼鏈 300 區塊高度，智能合約平行鏈發起針對「32」的端點的消息，該端點是 DeFi 平行鏈的平行鏈 ID。消息將首先包含在智能合約平行鏈的出站或出站隊列中。

智能合約平行鏈的所有節點將開始在網絡中對消息進行八卦（參見下面的「傳遞」一節）。如果智能合約鏈中的某些節點也是 DeFi 鏈的完整節點，並且這些節點通過轉發消息來充當兩個八卦網絡之間的粘合劑。如果不存在需要遍歷的網絡共享節點，則調用回退（請參閱下面的回退部分）機制。

一旦消息到達 DeFi 平行鏈的收集人，它們就會接收此消息（以及它接收到的任何其他消息）並將其輸入入站或入口隊列，以便在其下一個候選塊中進行處理。

圖 1：顯示了兩個平行鏈 A 和 B 對應的收集人和全節點。有兩個節點同時是平行鏈 A 網絡和平行鏈 B 網絡的全節點。

DeFi 平行鏈上的收集人將產生中繼鏈區塊 301 的候選塊。此候選塊將要求證明它從 A 的塊上執行的消息是正確的消息。中繼鏈塊 300 包含 A 中區塊的平行鏈區塊頭，也就是包括可用於認證消息的消息根散列的少量數據。

此候選塊將包括中繼鏈輕客戶端證明，證明此消息根位於中繼鏈中，並將此證明與發送鏈發送的消息一起組合。

DeFi 平行鏈的平行鏈驗證人將能夠使用這些證明，來驗證來自 DeFi 平行鏈的提議候選塊的完整性。隨後，智能合約鏈的原始消息被包含在了 DeFi 平行鏈中，無需額外的節點提供安全性，並依賴於來自 Polkadot 的共享安全。

排隊和排序消息

Polkadot 中的每個平行鏈的區塊都可能生成一個空的消息列表發送到其他塊。這些列表被稱爲出口隊列（egress queues）。一旦消息被髮送，它就進入平行鏈的入口隊列。平行鏈必須按順序處理入口列表。

一個收集人或驗證人試圖爲某個平行鏈的出口隊列收集消息，它調用該平行鏈的入口，並在傳播池中搜索相關消息，等待尚未被八卦的消息。

傳遞消息

假設每個平行鏈都有一個全節點的連接網絡。我們假設每個完整節點都知道系統中其他完整節點的子集，我們稱之爲相鄰節點。請注意，我們對這些網絡的拓撲結構和直徑沒有任何假設。

發送消息的最簡單方法是使用八卦協議（gossip protocol）。回想一下，同齡人之間經常就他們對當前假期的看法進行交流。爲了實現更高效的傳遞，未發送的消息只會被傳遞到具有相同視圖的相鄰節點。

如果這兩個網絡之間有共同的節點，消息將從一個平行鏈網絡傳播到另一個平行鏈網絡。

圖 2：顯示了由八卦完成的消息傳遞過程。我們假設這條消息是由粉色 collator 發出的，它產生了最新的平行鏈區塊。

回滾傳遞

但是，如果接收方的平行鏈驗證者意識到消息沒有在接收平行鏈中被八卦，那麼它們會從發送平行鏈的平行鏈驗證者請求消息。一旦收到這些信息，他們就會在接收平行鏈網絡中對這些信息進行八卦。

圖 3：顯示當發送和接收平行鏈不共享任何全節點時的回滾傳遞。

回滾傳遞機制如圖 3 所示，我們假設平行鏈 A 希望向平行鏈 C 發送消息，而平行鏈 C 沒有跟 A 共用的全節點。一旦平行鏈 C 的平行鏈驗證人注意到消息尚未到達，它們就會向發送平行鏈驗證人發出請求，後者負責保存來自其平行鏈的出口消息。一旦對請求的響應到達，平行鏈 C 的驗證人就會在平行鏈 C 中八卦消息。

獲得一致的歷史記錄

我們希望從 XCMP 獲得的一個關鍵特性是規範平行鏈區塊，即那些我們最終認可它已經發生的平行鏈區塊。這意味着，在當前的平行鏈區塊中，只對那些從平行鏈區塊發送的消息起作用，這些平行鏈區塊本身既規範又早於當前平行鏈區塊。

中繼鏈定義了所有平行鏈的歷史記錄。例如，來自平行鏈 B 的區塊頭在中繼鏈區塊 301 中，可以說其作用於區塊 300 之前的所有消息。如果作用於區塊 300 之前的所有消息，那就作用於平行鏈 A 的區塊發送的消息，並且僅當 A 平行鏈區塊頭出現在中繼鏈 300 區塊或更早的時候纔會起作用。

這意味着中繼鏈需要在驗證消息方面發揮作用。然而，由於我們不能在這些平行鏈區塊頭中放置大量數據，中繼鏈本身不應該具有消息的有效負載。相反，我們通過使用嵌套的 Merkle 樹來有效地保持一致的歷史。對應於已發送消息的平行鏈區塊頭將包含一個消息根哈希，即 Merkle 樹的根。反過來，這個 Merkle 樹的葉子是從這個平行鏈到另一個平行鏈的消息散列鏈的區塊頭。

這意味着有一個包含每個消息哈希的哈希序列，讓從一個平行鏈到另一個平行鏈的所有已發送消息得以驗證。這允許收集人通過首先顯示消息根在中繼鏈中，然後證明這些是來自消息根哈希的消息，從而構造一個由許多散列組成的證據，證明它們對消息起作用，並且只對它們應該起作用的消息起作用。

有關此主題的詳細信息，請參見：
https://research.web3.foundation/en/latest/polkadot/XCMP.html

輸入和輸出驗證

回想一下，Polkadot 由一條中繼鏈和多條（暫定高達 100 條）平行鏈組成。

平行鏈區塊頭包含傳出消息的消息根。爲了在基於特定中繼鏈塊的平行鏈上生成平行鏈塊，收集人需要查看在該中繼鏈塊和包括該平行鏈的最後一個平行鏈區塊頭的中繼鏈之間構建了哪些平行鏈頭。對於這些消息，平行鏈需要作用於相應的消息數據。

圖 4：顯示了在第 0、1、2 輪中爲三個平行鏈 A、B、C 構建的平行鏈塊，以及在這些平行鏈中每輪發送的消息。

鏈狀態轉換驗證函數（STVF）使用驗證函數來驗證輸入消息是否被執行。驗證函數是 WebAssembly 的一部分，它檢查平行鏈的狀態轉換是否實際有效。它將平行鏈的新狀態和一組輸出消息與平行鏈的先前狀態摘要、平行鏈塊數據和一組從其他平行鏈或由中繼鏈準確地路由過來的輸入消息相關聯。

圖 4 顯示了一個示例，其中爲第 0、1、2 輪顯示了三個平行鏈 A、B 和 C 之間生成的平行鏈塊和消息。假設平行鏈 B 在第 0 輪中不產生任何平行鏈塊，平行鏈 C 在第 1 輪中不產生平行鏈塊。在第 1 輪中產生的平行鏈塊 B1 需要將消息 m1 作爲輸入消息，並通過在第 1 輪發送消息 m3 來回復平行鏈 A。在第 2 輪中生成的平行鏈塊 C1 需要在其未處理的入口隊列中獲取消息 m2 和 m4。

消息的可用性

一旦消息被包含在出口隊列中，它們就由收集人和發送平行鏈的全節點保存。當發送平行鏈塊的頭包含在中繼鏈中時，平行鏈驗證人也將保留消息。接收平行鏈的收集人和全節點還需要知道平行鏈之間發送的消息的有效負載。所有需要知道消息存在的其他實體只能存儲散列，這些散列可以用來驗證消息。

爲了保證可用性，我們要求所有驗證人持有可恢復任何平行鏈消息的糾刪碼片段（erasure-coded pieces）。這些糾刪碼片段由發送平行鏈的平行鏈驗證者生成和分發。其中 1/3 的糾刪碼片段足以恢復所有消息。最終確認要求投票人（驗證人）收到這些糾刪碼片段，否則他們將因投票而受到懲罰。因此，最終確認時必須有 2/3 的糾刪碼片段可用；由此我們可以保證最終消息也可用。

防止 DoS 攻擊

注意，XCMP 的目的不是規定消息的標準格式。但是，每個平行鏈通過它發送給另一個平行鏈消息的總大小有一個限制。此外，八卦協議使用邊界傳遞來避免較大的信息。

對於不經常將塊放入中繼鏈中的平行線程，未處理的消息隊列可能會大幅增長。爲了限制這一點，發送平行鏈將爲此鏈維護一個具有大小限制的出口隊列。只有當它知道舊消息已經收到時才能刪除它們。接收鏈發佈一個水印，說明它在這個平行鏈的區塊中處理了多少區塊。發送鏈可以使用此水印來精簡其出口隊列。

此外，我們計劃讓接收平行鏈能夠阻止另一個平行鏈發送消息（此功能尚未實現）。平行線程還可以禁用 XCMP 函數，以避免處理大量消息。

XCMP 和 SPREE

SPREE（Shared Protected Runtime Execution Enclaves）是類似於 runtime 模塊的邏輯片段，但它們位於中繼鏈上，可以由平行鏈選擇其功能。

這些邏輯片段是通過治理機制或平行鏈上傳到 Polkadot 的 WebAssembly 代碼塊。一旦這些邏輯片段上傳到 Polkadot，所有其他平行鏈都可以決定選擇加入該邏輯。SPREE 模塊將獨立於平行鏈保留自己的存儲，但可以通過與平行鏈的接口調用。平行鏈將同步向 SPREE 模塊發送消息。有關 SPREE 的更多信息，請參閱其 wiki 文章：

https://wiki.polkadot.network/docs/en/learn-spree。

這些邏輯片段可以將 XCMP 消息尋址到 SPREE 模塊，並保證在對該消息執行操作時，它將使用來自該 SPREE 模塊的與任何其他平行鏈相同的代碼。SPREE 模塊對於整個 XCMP 體系結構非常重要，因爲它們提供了在目標平行鏈上執行代碼的特定解釋的保證。雖然 XCMP 保證消息的傳遞，但它並不保證執行代碼，即接收平行鏈將如何解釋消息。對 SPREE 模塊的代碼更新將與平行鏈同步進行。除了安全性方面的好處之外，這意味着不需要跨多個平行鏈協調更新就可以更改消息格式。

總之，雖然 XCMP 完成了去信任消息傳遞，但是 SPREE 是對消息的去信任解釋也是 XCMP 有用性的關鍵部分。發送到 SPREE 模塊的 XCMP 消息，使調度消息的開發人員和用戶能夠清楚地知道如何處理消息。

XCMP 屬性總結

XCMP 方案可以實現以下屬性：

去信任性：由於同一組驗證人在保證正確消息傳遞的同時確保一個平行鏈與另一個平行鏈的安全，XCMP 所需的信任不超過單個區塊鏈所需的信任。

一致性：我們提供了絕對的保證，即接收到的消息與發送的消息完全一致，即使有任何鏈重組。

有效性：Polkadot 保證消息不會丟失並保持可用。這是通過分發可用於重建消息的糾刪碼片段來實現的。

保持正確的序列：通過輸入/輸出驗證，可以保證保持平行鏈塊輸出消息的正確順序。

效率：這個協議避免了太多的帶寬佔用，並讓消息儘快到達。

有關 Web3 基金會的更多信息，請訪問 web3.foundation。

要深入瞭解 Polkadot 的功能和特性，請查看我們的 Wiki（https://wiki.polkadot.network/），我們正在不斷更新和完善它。

原文：https://medium.com/web3foundation/polkadots-messaging-scheme-b1ec560908b7

翻譯：PolkaWorld

來源鏈接：weixin.qq.com