圖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
