ZK 跨鏈通信協議：構建全鏈 DApp 的安全低成本解決方案

ZK 為跨鏈通信提供了一種安全，低成本的方式

跨鏈通信協議仍處于早期階段，但有望允許 DApp 訪問不同鏈上的數據

DeFi，全鏈 DApp 將從跨鏈 DApp 的發展中受益

跨鏈 DApp 的影響預計在未來幾年內會非常大，就像全球化的影響一樣。

開發人員正在努力探索構建跨鏈 DApp 的最佳模式

延遲，安全和成本是 ZK 跨鏈信息協議的主要指標

ZK 跨鏈協議四個主要的組件是：生成存儲證明，結合存儲證明和 ZKP，中繼 ZKP， 展開承諾

文末還提供了由本文訓練的AI，你可以提出與本文有關的任何問題。

前言

以前只有以太坊和比特幣。他們擁有最多的流動性，最多的用戶，最多的應用和最多的交易。2020 年后，出現了許多新的區塊鏈，如 Avalanche，Polygon 和 BSC。

在這些鏈的主網推出后，我們看到了從以太坊和比特幣到 ALT Chain 的范式轉變。用戶從以太坊轉移到 ALT Chain 來尋找新的機會。開發者從以太坊轉移到 ALT Chain 來分叉現有項目。這些開發者為尋求高回報的用戶創造了新的機會。

以太坊曾經擁有加密貨幣世界中除比特幣之外的所有流動性。在 2020 年底，以太坊 TVL 占比急劇下降到 60% 左右。以下是 165 個鏈的 TVL 數據。

今天，各大鏈 TVL 餅圖看起來是這樣的。以太坊占據了大部分的流動性。Tron 和 BSC 占據第二和第三的位置。

在將資產和流動性分散到不同的鏈上后，用戶開始考慮如何在不同的鏈上管理和移動資產。資產發行者也考慮如何通過擴展到不同的鏈來擴展他們的用戶。

跨鏈資產橋在 2022 年開始流行。用戶不再使用 CEX 作為跨鏈橋，而是嘗試轉向去中心化的跨鏈橋。資產跨鏈橋有時會卡住，并容易受到攻擊，但它更容易使用和用來轉移大量資金。

然而，資產跨鏈橋還處于早期階段，并且不能滿足 DApp 開發者的需求。資產跨鏈橋只能讓相同的資產在不同的網絡之間流動。這對于開發者來說用處過于局限。開發者正在尋找一種更加通用的跨鏈方式。

跨鏈通信擁有強大的自定義性。開發者完全可以基于跨鏈通信開發全鏈 DApp。DApp 構建者希望在不同鏈之間傳遞消息并獲取必要的區塊信息。有了這些的特性，全鏈 DApp 的構建范式從互不通信，轉向分布式的設計。在互不通信，相互獨立的模型中，不同鏈上的 Dapp 實例無法彼此共享數據。在分布式設計中，Dapp 實例可以相互通信，并可以定期將數據同步到一個實例。該實例獲取所有數據并可以修改其他實例上的參數。

借助 ZK 驅動的跨鏈通信，因為 ZKP 可以提供簡潔的證明，它可以消耗更少的存儲，將源鏈狀態中繼到目標鏈。此外，在目標鏈上驗證 SNARK 證明相對便宜。ZKP 的這兩個重要特性可以實現低成本的跨鏈消息和狀態傳遞。在目標鏈上的驗證源鏈狀態可以實現 IBC 風格的跨鏈橋接。這大大增加了跨鏈的安全性。

當下

大多數區塊鏈網絡相互隔離，無法直接交換資產或代幣。跨鏈資產橋允許用戶在不同的區塊鏈網絡之間轉移資產或代幣。

隨著 Wormwhole、cbridge 和 Stargate 等項目的推出，跨鏈資產橋的概念在過去幾年開始受到關注。這些項目旨在創建可互操作的區塊鏈橋，用戶可以無縫地交換資產和代幣。

跨鏈資產橋無法滿足開發者的需求。開發人員正在尋找一種更通用的跨鏈方法，即跨鏈消息協議。為了滿足開發者的需求，這些跨鏈橋大多都有自己的跨鏈消息協議，例如 Celer IM、LayerZero、Multichain 的 anyCall、Connext 的 xcall。他們提供了類似這樣的 API

跨鏈消息通信協議是基于其跨鏈資產協議實現的。通過一些修改，這些跨鏈資產協議現在可以在鏈之間傳遞消息。這使得他們很難為跨鏈消息協議實現定制功能，因為整體設計需要兼容跨鏈資產轉移。它們缺乏構建跨鏈應用程序的一些關鍵功能，例如將消息從一條鏈廣播到不同鏈上的所有其他部署合約。這使得開發人員很難構建實用的全鏈 DApp。

跨鏈消息通信協議仍處于早期階段。沒有大型全鏈 DApp 完全建立在這些跨鏈通信協議之上。

為什麼需要 ZK？

雖然這些跨鏈橋帶來了很多便利好，例如提高資金利用率和改善用戶體驗，但它們也帶來了安全風險。針對跨鏈橋的攻擊給用戶造成了巨大的經濟損失。這使得安全性成為跨鏈橋開發的重中之重。這些攻擊使用戶損失了超過 15 億美元。

一年內，跨鏈橋在黑客事件中的總損失約為 13 億美元。跨鏈橋的使用手續費用在 5‱ 左右。Multichain 是跨鏈橋中的頭部項目。Multichain 的 30 天交易量為 $1.7B，手續費收入為 $635K。那麼一年的交易量約為 204 億美元，手續費收入為 760 萬美元。按照這樣預估，跨鏈橋市場的手續費總收益遠小于被黑客盜走的資金。

通過驗證源鏈區塊頭，ZKP 跨鏈消息協議可以緩解部分安全問題。用戶可以直接在目標鏈上訪問源鏈證明并自行驗證證明。如果沒有 ZKP，這將很難做到。在傳統項目中，這種驗證成本太高，用戶無法承受。

設計

在這一部分，我們將討論 ZKP 是如何實現低成本，安全的跨鏈信息通信。

將 ZKP 用來中繼消息的想法很直觀，但詳細設計可能很復雜。整個工作流程可以分解為以下步驟：

決定將哪些數據傳遞給目標鏈

獲取存儲證明（證明數據存在 EVM 存儲中）

根據存儲證明生成 ZK 證明

將 ZK 證明從起始鏈傳遞到目標鏈

在目標鏈上展開 ZK 證明

在目標鏈讀取跨鏈信息

生成存儲證明

大多數 EVM 兼容鏈都提供了這個功能。一旦用戶明確了存儲槽位，他們就可以使用 RPC 調用此方法來生成存儲證明。

EVM 兼容鏈使用 Merkle Tree 來存儲賬戶和數據。這使得創建 Merkle Proof 來驗證這些數據變得相對簡單。

Merkle Tree 是計算機科學中使用的一種數據結構。在密碼學和區塊鏈中的使用較多。它以其發明者 Ralph Merkle 的名字命名，也被稱為二叉哈希樹。Merkle Tree 背后的基本思想是將大量數據分成較小的部分，對每個部分進行哈希處理，然后組合哈希值以形成單個根哈希值。此根哈希充當整個數據集的指紋，允許對數據的完整性進行高效和安全的驗證。

在區塊鏈中，Merkle Tree 用于匯總和驗證區塊中的交易。每筆交易都經過哈希處理并添加到樹中，哈希值以特定方式組合形成單個根哈希值，然后添加到區塊頭中。這允許以一種高效且安全的方式來驗證區塊中大量交易的有效性，而無需單獨驗證每個交易。如果交易中的任何數據發生變化，根哈希也會發生變化，表明數據已被篡改。

Merkle 證明，也稱為 Merkle path，是一種密碼學證明，證明特定數據包含在 Merkle Tree 中。Merkle Tree 證明提供了一種驗證交易或其他數據真實性的方法，而無需下載和驗證整個 Merkle Tree。

在 Merkle 證明中，用戶提供了從 Merkle Tree 底部到根哈希的一系列哈希，以及要驗證的具體數據。通過從特定數據開始并沿著樹向上，接收者可以計算根哈希并將其與存儲在塊頭中的根哈希進行比較。如果計算出的根哈希值與存儲的根哈希值匹配，則接收者可以確信特定數據包含在塊中并且未被更改。

Merkle 證明是確保區塊鏈網絡的效率和可擴展性的重要組成部分。通過允許在無需下載和驗證整個 Merkle Tree 的情況下驗證特定數據。Merkle Proof 減少了需要傳輸和處理的數據量，從而提高了網絡的整體性能。

結合存儲證明和 ZKP

將整個存儲證明發布到目標鏈上是不切實際的，因為它太大了，大約 4kb。對于證明進行驗證也很昂貴。在以太坊上進行驗證需要 600k gas。如果 gas 價格為 30 gwei，則總費用為 0.018 ETH（30 美元）。

在這種情況下，ZKP 可以提供壓縮和可組合性。開發者可以基于 Merkle Tree Proof 創建 ZKP。這可以大大減少證明的大小，并且使證明更容易驗證。驗證 Plonk 大約需要 290k gas。如果 gas 價格為 30 gwei，則總費用為 0.009 ETH（15 美元）。一次 Groth16 驗證使用了大約 210k gas。如果 gas 價格為 30 gwei，則總費用為 0.006 ETH（10 美元）。

借助可組合性，開發人員甚至可以將不同的存儲證明組合到一個 ZKP 中以節省資源。

中繼 ZKP

為了安全地將相關承諾，如狀態根或相關的 ZKP 傳遞到目標鏈，我們需要設計一個共識機制。

中繼 ZKP 有 3 種常見的方式：

消息傳遞：使用一些消息傳遞協議傳遞 ZKP，并通過 OP CODE 獲得相關承諾

共識驗證：通過運行共識算法來驗證相關承諾

Optimistic MPC relayer：部分思路與我們在很多跨鏈資產橋和 OPRU 設計中看到的類似。初始鏈和目標鏈之間有一個委員會。委員會的參與者決定中繼承諾的有效性。任何人都可以挑戰有效性。但是當挑戰發生時，橋不能像 Rollup 那樣回滾。需要一組單獨的挑戰者真正阻止惡意消息的傳遞。在這種情境下，挑戰成本高，且延遲高，因為這涉及不斷將根哈希和所有 CALL DATA 上傳到初始鏈。并且它也只能以點對點的方式工作。

中繼 ZKP 最為重要的是以下因素：

延遲

成本

信任

鏈下計算

消息傳遞的延遲相當高，因為消息傳遞需要時間來確認。在區塊產生后，用戶才能確認傳遞成功。在成本方面，消息傳遞需要與兩個鏈進行交互，因此比較高。這種方式需要的信任較少，因為安全性等同于鏈的安全性。這種方式沒有進行任何的鏈下計算。

共識驗證是一種可行的方法。它與信息傳遞具有類似的延遲，信任假設和成本。然而，它必須在鏈外驗證簽名。這引入了大量鏈外計算的開銷。但共識驗證今天也可以通過 ZKP 完成。

Optimistic MPC relayer 犧牲了一些信任，但獲得了更低的延遲。用戶只需要將交易發布到中繼器網絡。具體的延遲取決于具體的 optimistic MPC relayer 機制。挑戰期可能會導致更大的延遲。用戶需要對中繼網絡有最小的信任。這種方式沒有大量的鏈外計算，但需要在中繼網絡中進行通信和欺詐證明。

展開承諾

在得到承諾后，目標鏈上的用戶可以展開承諾，訪問初始鏈過去的狀態。

三種常見的展開方式是：

鏈上積累

鏈上壓縮

鏈下壓縮

鏈上積累是一種在區塊鏈網絡中展開承諾的方法。在這種方法中，從承諾中重新創建區塊頭的整個過程直接在區塊鏈上執行。正確編碼的區塊頭作為交易中 CALL DATA，由區塊鏈來執行計算。這種方法的好處是在證明時間方面沒有額外開銷。并且延遲很低，因為證明不需要在區塊鏈之外進行驗證。然而缺點是成本可能很高，因為計算可能是消耗很多資源。

鏈上壓縮是一種減少需要存儲在區塊鏈上數據量的方法。它用于最小化在區塊鏈上存儲大量數據的成本。鏈上壓縮背后的想法是使用壓縮算法來減小數據的大小，從而減少它在區塊鏈上占用的空間。這可以通過從數據中刪除冗余或不必要的信息，或使用針對空間效率優化的數據結構來完成。然后將壓縮后的數據存儲在區塊鏈上，需要使用時可以解壓。

鏈上壓縮具有降低存儲成本和提高區塊鏈可擴展性的優勢。但是，它也有一些缺點。例如，壓縮和解壓縮數據的過程在計算上可能很昂貴，這會增加區塊鏈的延遲。此外，所使用的壓縮算法可能會對數據的安全性產生負面影響，因為它可能容易受到篡改或攻擊。

鏈下壓縮和鏈上壓縮類似。

下面是這三種方法的對照表：

相關項目

很多 ZK 橋項目希望能提高不同鏈的互操作性，降低潛在的黑客風險。

這一領域有很多項目，例如：

Succinct Labs

Lagrange

zkBridge

Herodotous

=nil; Foundation

Succinct Labs 使用輕客戶端方法。它使用輕客戶端在目標鏈驗證起始鏈共識層的共識。ZKP 用于生成共識證明。

Lagrange Labs 構建非交互式跨鏈狀態證明。Lagrange Attestation Network 負責創建狀態根。每個 Lagrange Node 都包含一部分分片私鑰，用于證明特定鏈的狀態。每個狀態根都是一個閾值簽名的 Verkle Root，可用于證明特定鏈在特定時間的狀態。狀態根是完全通用的，可以在狀態證明中使用，以證明鏈中任何合約或錢包的當前狀態。

Herodotus 使用 ZKP 的存儲證明來為智能合約提供對來自以太坊的鏈上數據的訪問。它有一個 MPC Optimistic Relayer 來中繼承諾。它采用鏈下壓縮，在鏈下展開中繼的區塊鏈標頭并創建證明。

zkBridge 使用 MPC 中繼網絡生成區塊頭的 ZKP 并將其中繼到目標鏈。它使用 deVrigo 和遞歸證明來實現非常快的證明時間，但 MPC 部分有較高的復雜度。

第一個用戶發起跨鏈消息請求。初始鏈中的發送者接著將區塊頭轉發到中繼網絡。中繼網絡中的驗證者生成區塊頭的證明，并將其傳遞給更新合約。更新合約驗證證明后， 接受證明。更新合約將證明轉發給接收者，接收者將其轉發給目標鏈中的應用程序和用戶。

=nil; Foundation 也致力于 ZK 跨鏈消息協議。它使開發人員能夠在以太坊上訪問 Mina 的狀態。他們在 2021 年底推出了一個演示，可以在以太坊上驗證 Mina 狀態。該基礎設施允許以太坊上的智能合約驗證 Mina 狀態的有效性。有了這個基礎設施，智能合約就有能力識別無效的跨鏈交易。

Mina 有自己的狀態證明，但在以太坊上驗證它們的成本很高。=nil; Foundation使用自己的 Placeholder 證明系統來生成輔助狀態證明，這種證明在以太坊上驗證起來很便宜。該基礎設施使以太坊智能合約能夠完全在鏈上驗證 Mina 狀態證明。未來跨鏈應用可以直接通過這個基礎設施來驗證跨鏈交易的合法性。

一個基于此的資產跨鏈橋將包含以下幾個步驟：

跨鏈橋在 Mina 上鎖定 $Mina

此基礎設施生成 Mina 狀態證明

此基礎設施將 Mina 狀態證明提交至以太坊上

以太坊鏈上合約驗證狀態證明的有效性

以太坊鏈上合約接收并存儲 Mina 狀態證明，如果證明有效

跨鏈橋在以太坊鏈上檢驗 Mina 和交易狀態，釋放 $WMINA

后來=nil; Foundation正在努力解決單向性問題。之前的 demo 中只支持單向的跨鏈通信。現在他們理論上支持雙向橋接。初始鏈上的狀態證明將在 Placeholder 證明系統中生成，并再次用 Kimichi 證明系統生成一個證明。然后再將證明提交給 Mina 驗證者。驗證者會將起始鏈狀態證明視為 Mina 原生 zkApp 生成的證明。

=nil; Foundation 還發布了 Proof Market。用戶/項目方在其中購買/出售大部分 SNARK 證明。目前有兩種交易對，ARITHMETIC-EXAMPLE 和 MINA-STATE。

這是這些項目的詳細比較：

應用場景

借助基于 ZK 的跨鏈消息中繼協議，開發者可以輕松地將應用擴展到不同的區塊鏈。

過去，合約部署主要集中在一條鏈上。當擴展到另一個鏈時，必須重新部署應用程序。使用基于 ZK 的跨鏈消息中繼協議，將實現從單鏈應用到跨鏈應用的范式轉變。大型項目可以輕松擴展到不同的鏈。這將產生與全球化類似的效果。我們希望看到更多的國際公司或大型跨鏈 DApps。

低延遲/實時和低成本的跨鏈消息中繼協議將打開具有多種可能性的市場。DeFi、DID，治理和開發將從中受益

DeFi

DeFi 可以從中獲益良多。跨鏈消息中繼協議可以幫助 DeFi 產品整合來自不同鏈的流動性。

DEX、跨鏈交易和聚合器可以提供更好的用戶體驗、更低的滑點和更高的交易對流動性。不同鏈上的同一個交易對將有一個統一的流動性池。不同鏈 DEX 之間的價格差異會更小。DEX 顯然可以聚集更多的流動性并提供堪比 CEX 的用戶體驗。

Farming 可以有更靈活的策略。他們現在可以在不同的鏈上尋找更多的獲利機會。

借貸協議可以與不同鏈上的更多 DeFi 協議合作，并接受更多不同鏈上不同代幣的存款。

鏈上衍生品將在流動性方面受到很大益處。通過安全的跨鏈通信，衍生品市場可以接觸到更多不同鏈上的潛在客戶，并且聚集更多的流動性。這可以提供更好的交易體驗。

資金管理應用可以訪問更多來自不同鏈上的資產。他們還可以訪問來自不同鏈上的衍生品。這使理財經理可以使用更多的投資策略。

應用鏈

應用鏈 或 自定義 Rollup 為 Dapps 提供了更多的自由。Dapp 開發人員可以自定義應用鏈以滿足他們自己的需求，例如性能或一些技術特性。Dapp 開發人員還可以自定義手續費結構以激勵用戶。Cosmos 上有很多應用鏈，因為 Cosmos 具有更好的互操作性。ZK 支持的跨鏈協議將是連接非 Cosmos 應用鏈與 EVM 或 layer2 生態系統的更好工具。許多正在開發的 Rollup SDK 可以受益于 ZK 支持的跨鏈協議。

Cosmos 生態在 APP 鏈上領先于其他所有主要生態。Cosmos 在跨應用鏈共享安全方面取得了良好進展。ZKP 可能會促進 Cosmos 生態系統的擴展。Composable finance 正在努力將 Cosmos 擴展到 Polkadot 和 NEAR。Electron Labs 和 zkBridge 正在將 Cosmos 帶到以太坊。

利用不同鏈的特性

沒有一條區塊鏈是完美的。它們以犧牲其他功能為代價為一個目的而優化。借助跨鏈消息傳遞協議，開發人員可以利用每個區塊鏈的優勢并避免其缺點。

DApp 開發人員可以在不同的鏈中部署他們的 DApp 組件。例如，由于計算費用低，某些鏈可能是計算的不錯選擇。一些鏈可能針對隱私進行了優化，這將作為 Dapp 的隱私功能。有些鏈可以托管文件，有些則適合提供前端。跨鏈消息傳遞協議可以將這些組件粘合在一起，并允許開發人員充分利用每個區塊鏈。

總結

ZKP 為跨鏈通信提供了一種全新的方式。它雖然不能完全解決傳統跨鏈橋的安全問題，但借助 ZKP 的力量，安全的跨鏈消息通信現在大大降低了成本。證明的大小比以前小得多。鏈上驗證成本也降低了很多。能夠在目標鏈上驗證源鏈狀態，可以實現類似 IBC 式的共享安全性。在過去是不可能低成本的實現的。

ZK 跨鏈通信協議賦予不同鏈上協議互相交流的能力。開發者能夠基于 ZK 跨鏈協議開發全鏈 DApp。DeFi，應用鏈將從中受益。

跨鏈通信協議仍處于起步階段。開發人員正在努力開發這些協議，諸如如何在不同鏈之間實時同步狀態等問題仍然沒有解決。調試跨鏈 DApp 也可能很痛苦。開發者在探索構建跨鏈 Dapp 的最佳模式，我們將在未來幾年看到跨鏈 Dapp 的影響。作為連接不同區塊鏈的跨鏈通信協議，它將與全球化一樣具有影響力。

戳這里調戲AI?https://glazec-zkbridge-streamlit-app-ord6v2.streamlit.app/

參考

https://medium.com/@ingonyama/bridging-the-multichain-universe-with-zero-knowledge-proofs-6157464fbc86

https://www.ingonyama.com/blogs/bridging-the-multichain-universe-with-zero-knowledge-proofs