zkRouter如何實現安全跨鏈

原文作者：hiweiwei.eth

多鏈生態的蓬勃發展，使得跨鏈協議變得不可或缺。但是由於跨鏈橋抵押了大量資產，再加上跨鏈協議邏輯較一般的 Swap 更爲複雜，因此跨鏈協議遭到黑客攻擊的可能性也就越來越高。截止 2022 年底，因跨鏈橋安全問題導致的損失就達到 20 億美金以上，其中損失上億美元的的跨鏈橋就有 Ronin Network、Horizon、BNB Chain、Wormhole、Nomad 等。

跨鏈橋主要解決的是跨鏈互操作問題。以往大量跨鏈橋安全事件說明，現行的跨鏈互操作方案還有極大的優化空間。近期 Multichain 就推出了基於零知識證明的去信任跨鏈解決方案 zkRouter。

Multichain 是跨鏈領域的龍頭項目，其 21 年底就獲得了 Binance 領投的 6000 萬美金投資，目前佔跨鏈市場份額第一。之前 Uniswap 跨鏈治理投票鬧的沸沸揚揚，但是穩定幣 DEX 王者--Curve 早就使用 Multichain 的 anyCall 完成了多鏈 LP 激勵分配。表 1 給出了當前主要跨鏈項目相關數據對比。

表 1 當前主要跨鏈項目相關數據對比

（數據來源:https://gov.uniswap.org/t/cross-chain-bridge-assessment-process/20148）

本文將重點分析 Multichain 基於 ZKP 推出的最新去信任產品 zkRouter，同時對市場上其他優秀 ZK 跨鏈項目作一對照。

一、ZKP 成爲解決去信任化跨鏈的最佳方案

區塊鏈的主權區域特徵導致鏈上合約難以獲取準確鏈外信息，而不得不依賴於第三方進行資產和消息的中繼跨鏈，維護不同鏈上合約間資產的安全和信息傳遞的可信可靠。這與預言機的作用是類似的。這意味着跨鏈之間的交易需要建立在對第三方的中繼跨鏈或預言機的信任基礎上，而中繼跨鏈和預言機在一些時候卻又是難以被完全信任的。因此，如何通過去信任的手段獲取鏈外信息，變成了一個重要的研究課題。

無論是通過中繼網絡，預言機或者鏈實現跨鏈中繼，都可以做到部分甚至完全去中心化，但卻做不到去信任化。目前市場上通過主流跨鏈橋構建的應用，其安全都託管給了第三方，用戶需要信任跨鏈中繼網絡從而採信其傳遞的源鏈狀態，而無法對其安全進行驗證，而這阻礙了真正的跨鏈生態的出現。從某種意義上說，跨鏈橋最重要的特徵應該是實現完全的去信任化。如果能夠以一種去信任的方式構建跨鏈服務，由鏈上輕客戶端獨立進行驗證從而直接採信源鏈信息，這將極大推動多鏈生態的進一步發展，以及原生多鏈應用的大規模涌現。

ZKP 技術的出現，以及由 ZKP 技術構造的跨鏈橋，將成爲實現去信任跨鏈的最佳方案。

二、基於 ZKP 實現的跨鏈去信任化

一個優秀的跨鏈協議首先一定是安全的，其次是生態豐富，最後纔是跨鏈費用低、速度快。由此，優秀的跨鏈協議應該具有去信任程度高、去中心化程度高、可拓展性好、跨鏈速度快和成本低等特性。這個觀點大部分人都比較認可，筆者認爲這個觀點可能存在一些問題。如果一個跨鏈協議實現了完全去信任化，還需要考慮是否去中心化的問題嗎？

現在很多跨鏈項目使用一條專門的鏈來實現跨鏈操作，這種做法是使跨鏈協議更加去中心化，但沒有實現去信任化。去中心化仍然是跨鏈的發起方將其跨鏈的安全寄託在一個去中心化的網絡上。但跨鏈協議應該實現的是去信任化，而不是去中心化，因爲一旦實現跨鏈操作的去信任化，就不存在去中心化這個問題了。試想一下，當中繼者生成的 ZKP 用戶自身就可以輕易驗證了，那還需要再去討論去中心化的必要性嗎？

在跨鏈操作過程中，信任源鏈共識和目標鏈共識是跨鏈操作得以存在的前提。此外，信任任何組織都會降低資產的安全性。跨鏈操作最好能夠實現去信任化，而去信任化最終是無信任假設。要實現去信任化跨鏈，最好的途徑就是使用 ZKP 構建跨鏈互操作協議的底層信任機制，實現去信任跨鏈。

基於 ZKP 構建的跨鏈橋一般涉及三個邏輯角色：

1.Proof 的生成者，其功能是觀察原鏈狀態，並使用原鏈數據生成 ZKP。

2. 中繼者，將 ZKP 傳遞到目標鏈。

3. 鏈上輕客戶端，鏈上輕客戶端也是驗證者，可以獨立完成對 ZKP 的驗證。

證明者和中繼可以是同一個人也可以是不同的人，因爲決定是否採納 ZKP 的是鏈上輕客戶端。因此，這種設置不會帶來任何安全問題。此外，在 ZKP 中，只要有一個誠實的中繼節點，就可以保證協議的正常運行。

現行的所有 ZK 互操作協議基本都是圍繞 Ethereum 展開的，有些實現的是 Ethereum 與其他異構鏈的互操作，有些要完成的是 Ehtereum 與其同構鏈的互操作。但無論實現的是 Ehtereum 與哪一條鏈的互操作，都需要生成 Ethereum 的共識證明，並且在其他鏈上實現 Ethereum 輕客戶端對該共識證明的驗證。

三、zkRouter 與其他 ZK 互操作協議

基於 ZKP 構建的跨鏈協議可以完美地實現去信任。當前最典型的協議應該就是 Multichain 推出的 zkRouter 了。

1.zkRouter 是如何基於 ZKP 實現跨鏈

無論是資產跨鏈、消息跨鏈，還是跨鏈互操作，其本質上做的都是同一件事情，那就是用戶通過智能合約在源鏈發起一個動作，並在目標鏈上驗證該動作。只要這個動作能夠被去信任化地驗證，就可以支撐起真正意義上的原生多鏈，也就能夠實現真正的多鏈互操作。

zkRouter 白皮書描述的是將 Ethereum 的消息傳遞到 Fantom，這涉及以下幾個步驟：

首先在源鏈發生一筆交易（該交易可以通過區塊頭 hash 配合默克爾樹路徑驗證）；

中繼者將該交易提交到目標鏈上的輕客戶端；

鏈上輕客戶端驗證該交易。

讀者看到這裏會有兩個疑問：

輕客戶端與鏈上輕客戶端是什麼？

在以上幾個步驟中哪裏體現了 ZKP，以及 ZKP 的作用是什麼？

（1）輕客戶端與鏈上輕客戶端

自從 LayerZero 協議推出後，輕客戶端的概念似乎被濫用了，在 LayerZero 協議中的超輕節點和通常意義上的輕客戶端是有差異的。LayerZero 超輕節點只是驗證中繼者傳遞過來的數據是否和預言機傳遞過來的數據相匹配，並不直接驗證鏈上交易。而通常意義上的輕客戶端是直接驗證鏈上交易的，從本質上講 LayerZero 還是需要信任中繼者和預言機不會聯合作惡，沒有實現去信任化。

我們從如何驗證一筆鏈上交易開始探討什麼是真正的輕客戶端與鏈上輕客戶端。

什麼是輕客戶端？Ethereum 同一時間會發生很多筆交易，歷史上也發生過很多筆交易，在沒有輕客戶端的情況下，用戶要驗證這筆交易就必須同步所有區塊的所有交易數據，這顯然是不可能的。

在比特幣網絡中，每個區塊都有區塊頭，區塊頭包含了一個指向上一個區塊的指針，和當前區塊鏈內所有交易的哈希的默克爾根。其中指向上一個區塊的指針能保證上一個區塊內的交易數據不被篡改，而每個區塊內的默克爾樹包含當前區塊所有交易，而通過根哈希值可以驗證當前所有交易。如圖 1 所示。這就可以確保當前和歷史區塊包含的所有交易信息都不會被篡改。Ethereum 繼承了這種驗證方法。Ethereum 網絡的區塊頭也包含默克爾根和指向上一個區塊的指針，可以用於驗證存儲的任何類型的數據。

圖 1 比特幣網絡的默克爾樹結構示意圖

如圖 1 所示，對交易 L1、L2、L3、L4 分別進行哈希運算, 得到 Hsh0-0=hash(L1), Hash0-1=hash(L2), Hash1-0=hash(L3), Hash1-1=hash(L4)。

輕客戶端要獲取根哈希（Top Hash），只需要再計算：

Hash0=hash（Hsh0-0,Hash0-1）

Hash1=hash（Hash1-0,Hash1-1）

Top Hash=hash(Hash0,hash1)

hash 運算只能是單向的，即只能通過 X 計算出 Y=Hash(X)，但卻無法通過 Y 計算出 X。由此，輕客戶端只需同步區塊內的根哈希值，並詢問全節點路徑哈希數據，便可驗證交易真僞。

如果輕客戶端想要驗證 L1 的交易。輕客戶端如果有了根哈希值，通過向全節點申請 Hash1 與 Hash0-1 的值，然後就可以驗證 L1 的交易了，具體的做法是：

1. 計算出 Hash0-0；

2. 根據全節點同步過來的 Hash0-1 和上一步計算出來的 Hash0-0，可以計算出 Hash0=hash(Hash0-0，Hash0-1)。

3. 根據全節點同步過來的 Hash1 和上一步計算出的 Hash0，計算出根哈希 RootH=hash（Hash0，Hash1）, 並比較計算出來的根哈希 RootH 是否等於輕客戶端同步的 Top Hash。如果兩者是相同的，證明 L1 交易確實在鏈上並且沒有被更改。整個區塊鏈正是通過這種方式實現了可信的輕客戶端。

上述過程演示了輕客戶端如何對鏈上交易進行驗證。那如果在目標鏈上能夠實現源鏈的輕客戶端，也就是鏈上輕客戶端，是不是就可以實現在目標鏈驗證源鏈交易了呢？

試想一下，在跨鏈這個具體的應用當中，關鍵性的困難就是在目標鏈上無法去信任地驗證源鏈發生的交易，而需要通過第三方進行中繼，無形中降低了跨鏈的安全性。如果使用智能合約在另一條鏈上實現輕客戶端，便可以在目標鏈上驗證源鏈發生的交易，實現去信任化的跨鏈了。

（2）爲什麼鏈上輕客戶端需要使用 ZKP 技術

上一小節說明了通過鏈上輕客戶端驗證源鏈交易的方式，完全可以實現跨鏈。那爲什麼要使用 ZKP 技術呢？

輕客戶端驗證涉及到大量共識產生過程中的計算，如果這些計算都在鏈上完成，需要消耗極高的 Gas 費用，不具有推廣的可行性。而零知識證明技術可以將大量共識產生過程中的計算轉移到鏈下可信地進行，進而生成簡潔的證明結果，該結果在鏈上只需花費較少的 Gas 即可驗證。

但凡涉及到中繼，用戶就會覺得有中心化的嫌疑，不夠去信任化。但是在基於 ZKP 實現的跨鏈橋中的中繼者只負責中繼消息，並不負責驗證消息，驗證的工作由目標鏈的輕客戶端完成。這其中嚴謹的數學和密碼學證明可以保證目標鏈的輕客戶端可以完成驗證，實現了去信任化。

（3）zkRouter 如何使用 ZKP 技術實現跨鏈

zkRouter 實現的跨鏈方案在其白皮書上有詳細的說明，但是當前市場上並無對其進行解讀的文檔。爲理解 zkRouter，需要補充一些背景知識。

目前零知識證明的應用領域出現了幾種典型的圖靈完備證明算法，其中最爲流行的是 zkSnark（zero-knowledge succinct non-interactive arguments of knowledge，零知識簡潔非交互知識論證）和 zk-Stark（Zero-Knowledge Scalable Transparent Argument of Knowledge，零知識可拓展的透明知識論證）。zk-Stark 生成的 ZKP 文件大小爲 200KB 左右，zk-Snark 生成的 ZKP 文件大小爲 192B 左右。zk-Stark 生成的 ZKP 文件過大，如果使用 zk-Stark 實現跨鏈，目標鏈消耗的 Gas 會很大，因此在具體應用當中，不具備經濟優勢。而 zk-snark 生成的 ZKP，因其非交互、證明生成速度快、證明結果簡短的優勢，在區塊鏈中應用較多，目前市場上絕大部分 ZK 跨鏈橋都是使用的 zk-Snark，或者是 zk-Snark 技術的變體，zkRouter 使用的也是 zk-Snark。

zkRouter 協議主要包含四個步驟。

1. 初始設置（Setup）

目標鏈輕客戶端要完成對源鏈 ZKP 證明的驗證，就必須有上一個源鏈區塊的共識狀態，區塊鏈的共識狀態具有連續性，即當前的區塊共識結果是基於上一個區塊的共識結果的更新。因此目標鏈輕客戶端必須先獲取源鏈當前的共識狀態，然後才能驗證後續區塊共識的正確性。

目標鏈的輕客戶端在一開始需要初始 initial_data，這個數據包括初始的區塊高度，區塊頭 hash 等。這個初始設置只需要設置一次，後續隨着跨鏈行爲發生，該數據會自動被更新。

2. 共識證明生成（Proof Gen）

這個步驟發生在具體的跨鏈行爲中。當源鏈產生新的區塊後，目標鏈需要同步新的信息，這些新的信息包括了前一區塊的狀態，出塊節點選擇，簽名節點的合法性等內容。對於非即時最終性的共識機制，還需要設置一定的冗餘區塊數，避免分叉帶來的損失。然後中繼者通過鏈下 ZKP 技術計算生成鏈下 ZKP，同步到目標鏈。

3. 驗證共識證明（ProofVerify）

當簡潔 ZKP 被中繼者提交到目標鏈後，就需要對該 ZKP 進行驗證了，這部分工作由鏈上輕客戶端完成。驗證通過後返回驗證結果，並在目標鏈更新源鏈的共識狀態信息。

4. 互操作合約調用（InterOperCall）

當目標鏈輕客戶端通過對源鏈共識（包含源鏈交易）的驗證後，參與者就可以發起跨鏈合約互操作調用，完成跨鏈交互了。

例如對於跨鏈 Swap，任意參與者提交對應源鏈交易的 TXS 和對應的默克爾樹證明路徑，根據輕客戶端已有的源鏈共識信息，合約可以很簡單地驗證交易的真僞。

在 Multichain 的白皮書當中還有相當部分的 Ethereum->Fantom ZK 跨鏈實現的說明，步驟與上面的過程類似，這裏不再贅述。

2. 其他主要 ZK 跨鏈方案

目前很多團隊都在致力於 ZK 跨鏈橋的開發。由於 ZKP 的生成和源鏈共識緊密相關，而不同鏈達成共識的方式、使用的簽名算法都不相同，因此在實踐當中，項目方所要實現的不同鏈上輕客戶端所用的方法也會有所不同，但是核心算法基本都與 zkRouter 的做法相似。

（1）Electronlabs

Electronlabs 實現了 Ethereum 測試網到 Near 測試網的雙向跨鏈橋，這表明 Electronlabs 不僅在 Near 上實現了 Ethereum 的輕客戶端，也在 Ethereum 網絡上實現了 Near 的輕客戶端。Cosmos 支持 Ed25519[ Ed25519 已成爲 Cosmos、NEAR、Solana 等區塊鏈生態系統的首選簽名方案。驗證區塊鏈共識需要驗證大量的 Ed25519 簽名（驗證者簽名）。因此，需要對一批 Ed25519 簽名進行簡潔驗證。] 簽名算法，但是 Ethereum 並不支持該算法。因此，要在以太坊進行 Ed25519 簽名的鏈上驗證就需要一些額外的工作。

此外 Ed25519 算法不支持聚合簽名，因此 Eletronlabs 使用遞歸的方式實現了對大量 Ed25519 算法的驗證。驗證簽名會生成大型電路，因此，其關鍵問題是如何在以太坊鏈上高效、低成本地驗證來自 Cosmos SDK 中任何區塊鏈的 Ed25519 簽名。Electronlabs 的解決方案是構建一個 zk-Snark 在鏈下生成簽名有效性的證明，並且只在以太坊鏈上驗證該證明。

從 Electronlabs 目前的成果上看，其在異構鏈部署上有一些進展，包括 Cosmos 系的公鏈簽名算法都是 Ed25519，未來其拓展 Ed25519 簽名算法的公鏈能力應該較強。

（2）Succinct

Succinct 同樣也只上線了單向的 ZK 跨鏈橋，所不同的是其上線的是 Goerli->Gnosis，Optimism，Polygon，Avalanch 等測試網的 ZK 跨鏈橋。源鏈只有 Goerli 一條鏈。

ZK 跨鏈當中最複雜的部分就是根據源鏈共識設置電路，目標鏈客戶端的開發工作並不會太多。因此 Succinct 上線 Goerli->Gnosis，Optimism，Polygon，Avalanch 等測試網的 ZK 跨鏈橋，其實和只上線一個單向的跨鏈橋處於同一進度。Succinct 使用的也是 zk-Snark 方案，其基本方案與通用方案區別不是很大，這裏不做贅述。

Succinct 主要目標是圍繞 Ethereum 周邊二層網絡進行拓展。從目前進度上看，如果未來其能完成 Gnosis，Optimism，Polygon，Avalanch->Goerli 的跨鏈，則想象空間較大。但是鑑於源鏈 ZKP 生成需要大量的電路設置，共識不同差異很大，這部分工作內容是 ZK 跨鏈實現最耗時的部分，Succinct 目前還沒有完成。

（3）nil.foundation

Nil 實現了在 Ethereum 測試網與 Polygon 測試網上驗證 Mina 測試網的狀態，但並未實現在 Mina 測試網上驗證 Ethereum 測試網與 Polygon 測試網的狀態，因此在進度上，Nil 與其他的 ZK 跨鏈項目處於同一梯隊。

但是 nil.foundation 項目得到了 ZK 賽道頭部機構 Starkware 和 Mina 的投資，其技術實力可見一斑。另外，Nil 開源了 zkLLVM 產品，該產品定位於幫助開發者使用高級語言編譯 ZKP，極大地降低了開發者的准入門檻。通過這個工具，開發者可以使用自己熟悉的語言專注於電路設計，而不是陷入特定領域語言--DSL 學習的怪圈。編譯零知識電路往往需要特定領域語言與工具包，需要花費大量時間。

（4）Herodotus

Herodotus 官方說明使用的是「MPC+輕客戶端+ZKP」實現的跨鏈橋，使用樂觀的 MPC 方式挑戰中繼者中繼的消息。但既然任意中繼者都可以將生成的 ZKP 中繼到目標鏈，驗證由目標鏈上的輕客戶端完成。如果還需要可信的 MPC 網絡，再加入 ZKP，則意義不大，當然其測試網尚未上線，具體的方案還有待項目方後續公佈。

（5）Polyhedra

Polyhedra 是目前上線測試網最多的跨鏈橋，上線的測試網包括了 Goerli、BNB Chain Testnet、Polygon Testnet、Fantom Testnet、Avalanche Testnet。Polyhedra 目前推出的是 NFT 跨鏈，用戶可以通過 Polyhedra 生成跨鏈 NFT，然後可以使用其 NFT 跨鏈橋進行跨鏈。Polyhedra 獲得了包括 Binance Labs，Polychain Capital 等機構 1000 萬美金的支持。

但我們經過分析測試，發現該項目測試網並沒有使用 ZKP，輕客戶端也沒有驗證默克爾樹，具體如下。

測試交易源鏈地址：

https://mumbai.polygonscan.com/tx/0xc89904563b9f26a2eaeae5da91e87f6c86a8a2ebc33ca9d23a02b9ffb0e58aca

測試目標鏈地址：

https://testnet.bscscan.com/tx/0xbcbe3f47ae9b2d17c38d0ee4271669690e5c5049b2dd150c90ad50efbaa9848b

中間嵌套合約地址：

https://testnet.bscscan.com/address/0x7b95cf4cefdd218017e0e0e4da99f3b2c6f9e2a5

最終調用驗證默克爾樹合約地址：

https://testnet.bscscan.com/address/0x3BBd3ECa3C1bA24603f8C8EC247f225fb629a40B

圖 2 polyhedra 相關合約代碼

在合約代碼如圖 2 所示。Hash 頭驗證直接返回 true。並沒有沒有使用的 ZK 技術，哈希頭也未驗證，就默認跨鏈消息的正確性。從測試網合約上看，並不能看到其進展，當然我們也會持續關注其測試網動態。

四、基於 ZKP 的跨鏈項目發展展望

當前 ZK 跨鏈已經成爲行業熱點，相關解決方案還有很多，未來的競爭極可能圍繞以下幾個方面展開。

1. 合約安全性。儘管很多 ZK 跨鏈方案都在努力實現去信任化，但是 ZKP 給出的只是底層的技術架構。底層技術架構穩固了，但還是難以避免智能合約在編寫和運行方面可能產生的安全問題。

2. 多鏈雙向部署。這一方向的進展目前還不是很分明，以上幾個案例都沒有實現多鏈雙向部署。如果哪一家的跨鏈橋能夠率先實現多鏈雙向部署，將會成爲很大的競爭優勢。

3. 是否是去信任的 ZK 跨鏈橋，從上述論述中，讀者可以發現，ZK 跨鏈橋最重要的優勢就是可以實現去信任化的跨鏈，如果不能實現去信任化跨鏈，那麼將 ZKP 應用在跨鏈領域意義不大。

五、總結

我們從測試網進度、Non-EVM 支持性、產品可靠性、團隊技術能力、是否去信任等維度比較了 ZK 跨鏈賽道內的幾個知名項目，具體如表 2 所示。

表 2 當前幾個主要 zk 跨鏈賽道項目比較

由表 2 可以看到，目前幾個主要的 zk 跨鏈項目基本都處於起步階段，技術方案也大致相同。但 ZKP 在理論上的完全去信任化，使得未來基於 ZKP 去信任化地實現跨鏈，進而對推動多鏈生態、多鏈宇宙、原生多鏈應用的發展而具有了更加重要的意義。

根據 Multichain 公佈的路線圖，其從 Anyswap 誕生的時候就有兩種方案，一種是基於 MPC 的跨鏈方案，一種是基於 ZKP 的方案。對於 Multichain 開發的 zkRouter 我認爲有幾點是值的期待的：

1.Multichain 深厚的跨鏈技術背景。Multichain 深耕跨鏈業務多年，技術背景深厚，基於此，我們可以期待 Multichain 的 zkRouter 在 ZK 跨鏈的賽道上取得更大進展。在 zkRoutr 測試網上線後，用戶也可以親自感受一下 zkRouter 的使用體驗。當然，作爲 POC 階段的產品，普通用戶還是難以從使用中獲得直接的去信任體驗，包括 zkRouter 未來可能達到的跨鏈速度、跨鏈費用等指標。這些內容還有待更多專家從更專業的層面和角度進行研判。

2. 龐大的生態夥伴。Multichain 與上千個多鏈項目有深入的合作，這個優勢是其他跨鏈協議不具備的。因此，zkRouter 一旦進入實用階段，藉助 Multichain 的龐大生態，zkRouter 就完全有可能成爲下一代跨鏈有力的競爭者。

原文鏈接

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia