ZKP是安全跨鏈的必經之路嗎?

　　2022 年起，隨著Multichain、Succinct與Celer等眾多跨鏈項目推出ZKP跨鏈測試網，基於ZKP的輕用戶端跨鏈成為行業熱點。ZKP跨鏈本質屬於原生驗證這一大類，可以實現去信任化的源鏈共識驗證，幫助DAPP構建最安全的多鏈（或者說是全鏈）生態系統。之所以說是最安全，是因為相對于目前通過信任協力廠商實現的跨鏈通信的跨鏈方案，ZKP跨鏈不引入任何信任假設，用戶只需要信任源鏈共識和目標鏈共識。從這個維度上看，ZKP跨鏈是最安全的跨鏈方式。但ZKP跨鏈方案技術極其複雜，門檻相對較高。

一、使用ZKP 構建輕用戶端的原生驗證是實現去信任化跨鏈的最好方式

　　跨鏈可操作協定從驗證方式上通常可以分為三類，外部驗證、原生驗證和本地驗證。這三類交互操作協議都有自身的局限性，難以兼顧去信任化、可拓展性和通用性。

1. 外部驗證

　　外部驗證是指引入一組可信的外部節點負責跨鏈消息的驗證，其前提是用戶必須信任這一組外部節點構成的中繼網路。基於MPC、Oracle systems、PoS/PoA、多簽和TEE等實現的跨鏈方案都屬於這個範疇。外部驗證跨鏈交互操作協議建立在對協力廠商的中繼節點或預言機的信任基礎上，無法實現去信任化的消息中繼跨鏈，但中繼者和預言機在有些情況下也難以被完全信任。該類型的跨鏈實現方案是目前市場的主流，包含了Multichain，Wormhole，Axelar，LayerZero等知名項目。

2. 本地驗證

　　本地驗證也稱為P2P驗證，指交易對手直接進行驗證，其核心是基於雜湊時間鎖的原子交換。在交易過程中，交易雙方分別驗證對方的行為，只要有一方作惡，雙方都會面臨損失，因此他們的利益是一致的。在實踐當中，為了撮合交易，會有一個流動性提供者充當交易對手。Connext和Hop都可以算是這個分類中的典型。但是這類方案只適合資產跨鏈，並不適用於通用消息跨鏈，通用性弱。

3. 原生驗證

　　原生驗證是指在目標鏈部署源鏈輕節點，由目標鏈的輕節點對源鏈消息進行驗證，原生驗證無信任假設，理論上用戶只需要信任源鏈共識和目標鏈共識，並且確保源鏈和目標鏈不發生回滾（鏈上輕節點一般會設置一定的區塊冗餘，防止源鏈和目標鏈回滾）。原生驗證的典型專案有Rainbow Bridge，近兩年基於ZK的跨鏈方案也屬於這一範疇，典型的ZKP跨鏈項目包括zkRouter、Succinct Labs、Nil;Foundation等。

　　三類跨鏈交互操作協定驗證方式的綜合比較見表1 所示。

　　表1 跨鏈交互操作協定三類驗證方式綜合比較

　　

　　多鏈生態的繁榮催生了對跨鏈的需求。Multichain(anyCall)、Layerzero、Wormhole等眾多優秀的跨鏈項目先後誕生，這些跨鏈項目更加重視是通用性和可拓展性，也需要可信的中繼網路。

　　但2021 年到2022 年，跨鏈項目Ronin Network、Horizon、BNB Chain、Wormhole、Nomad等都受到了駭客攻擊，都有巨量資產被盜。多鏈生態用戶和跨鏈賽道參與者發現，去信任化跨鏈儘管可拓展性弱，但其去信任化特性對用戶來說是更加安全的選擇。因此，原生驗證就成為實現去信任化跨鏈的最好途徑。

　　但通常意義上的原生跨鏈交互操作協定在目標鏈驗證源鏈共識需要消耗大量Gas，原因是目標鏈輕用戶端需要獲取大量源鏈資料才能生成關於共識的資訊。而將ZKP用於原生驗證，通過生成簡潔的ZKP證明，使得目標鏈輕用戶端只需要獲取ZKP就可以驗證目標鏈交易，因此使用ZKP構建輕用戶端的原生驗證方式就成為一個更好的方案。

二、通過共識傳遞實現去信任跨鏈

　　Polkadot與Cosmos等公鏈生態共識天然支援生態內跨鏈，但對於非同一生態的公鏈，例如Ethereum，Solana等異構鏈卻無法利用其跨鏈優勢。包括Multichain，Layerzero，Wormhole等在內的主流協力廠商跨鏈橋都需要信任中繼網路。而使用ZKP構造的跨鏈方案則不需要信任協力廠商，其直接向目標鏈傳遞源鏈的ZKP共識證明，目標鏈輕用戶端只需要驗證源鏈的共識證明，即可實現共識跨鏈。

　　但是不同鏈共識生成原理和生成方式千差萬別，驗證共識需要的資料也不同。ZKP跨鏈的難點在於如何生成源鏈共識ZKP，而源鏈共識的ZKP又是基於源鏈共識資料產生的，因此源鏈ZKP的生成也需要基於源鏈共識進行。不同源鏈共識生成的ZKP的電路也需要進行定制化設置。

　　不同公鏈共識生成的過程千差萬別，生成ZKP的過程也不同。下面以Ethereum POS為例說明這個過程。

　　Ethereum設計了一套複雜的驗證者選擇機制來生成共識。Ethereum在Altair升級中增加了一個關鍵功能，這個功能是專門為支持輕用戶端同步區塊狀態而設計的同步委員會 (sync committee)。Ethereum使用RANDAO演算法隨機選擇512 個驗證者組成同步委員會，同步委員會的資訊保存在信標鏈Beacon Chain中，每隔256 個Epoch（一個Epoch約6.4 分鐘）更新一次。同步委員會的作用是不斷簽署區塊頭，在2/3 同步委員會成員簽名後，以太坊狀態轉換會被確認。

　　信標鏈Beacon Chain採用 BLS 12-381 演算法，作為驗證者參與 POS 共識的方式。信標鏈區塊中多個驗證者的 BLS 簽名可以進一步聚合為單個簽名，從而有效減輕了原有數個簽名的資料通信與鏈上存儲壓力。同時驗證者也只需驗證單個簽名即可更高效地進行區塊驗證。

　　因為同步委員會作為共識機制的組成部分，輕用戶端可以在不需要訪問整個驗證者集的情況下獲取被驗證過的共識狀態。目標鏈輕用戶端為了驗證源鏈共識狀態，會下載部分資料並進行驗證與計算，包括：

　　（1 ）Merkle路徑證明。驗證對當前區塊簽名的委員會（sync_cmts）是在已驗證區塊頭中指定的下一屆委員會。

　　（2 ）聚合委員會公開金鑰。根據當前區塊同步委員會實際簽名情況可以計算聚合委員會公開金鑰。

　　（3 ）同步委員會的簽名。使用聚合委員會公開金鑰，驗證新區塊中的委員會簽名。

　　上述驗證方法是原生驗證的通用方案，但是在鏈上直接驗證源鏈共識涉及到大量的鏈上資料驗證與計算，Gas消耗高。而使用ZKP技術，在鏈下完成源鏈資料的計算與驗證，並生成簡潔的源鏈共識傳遞到目標鏈可以大大降低鏈上Gas消耗，這也是為什麼基於ZKP的鏈上輕用戶端可以廉價驗證源鏈共識。基於ZKP的跨鏈協議將聚合公開金鑰驗證BLS簽名的過程放在鏈下，並生成ZKP證明，目標鏈用戶端只需要驗證一個零知識證明就可以驗證源鏈共識。具體代碼如圖1 所示。

　　（圖1 共識驗證偽代碼，資料來源：zkPoS: End-to-End Trustless）

　　從上述ZKP輕用戶端同步共識的過程可以發現，其鏈下證明生成過程與源鏈共識機制和輕用戶端的支援情況緊密相關。這也是為什麼要實現鏈上輕用戶端較為困難，而且每次Ethereum升級的時候輕用戶端都需要檢查是否需要更新同步代碼的原因。

三、ZKP 跨鏈專案對比

　　ZKP跨鏈的流程大同小異，進行個例分析時，筆者更加重視每個跨鏈專案的獨特性。ZKP跨鏈的基本原理可以看上一篇博客（https://www.theblockbeats.info/news/35560 ）。

1. zkRouter（Multichain）

　　zkRouter是由Multichain開發的ZKP跨鏈專案，根據其白皮書描述，其願景是要把zkRouter發展成其MBI（多鏈交互操作協議）的一部分，作為底層信任機制服務於其多鏈交互操作協議。這一部分內容在上一篇文章中已經有很多解釋，這裡強調幾個要點。

　　從目前公開的資訊來看，Goerli測試網與Fantom測試網的zkRouter跨鏈橋將在近期上線。zkRouter 協議主要包含初始設置、共識證明生成、驗證共識證明和交互操作合約調用四個步驟。如圖2 所示。

　　（圖2 zkRouter跨鏈過程，資料來源：zkRouter: Trustless, General Cross-Chain Infrastructure）

　　( 1) 初始設置（Setup）

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

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

　　( 2) 共識證明生成（Proof Gen）

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

　　( 3) 驗證共識證明（ProofVerify）

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

　　( 4) 交互操作合約調用（InterOperCall）

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

　　zkRouter 的核心優勢是實現了高TPS跨鏈。根據描述，zkRouter的TPS上限是公鏈TPS，測試網顯示其資料可以達到100 TXS。

　　Goerli測試網源鏈地址：https://goerli.etherscan.io/txs？a=0x91d1d54572ef662419d9e552a013321b5713e3ad

　　Fantom測試網目標鏈位址：https://testnet.ftmscan.com/address/0x91d1D54572Ef662419d9E552A013321b5713E3AD#tokentxns

　　對zkRouter的具體方案，可進一步參考其白皮書具體描述。

2. Hyper Oracle（Hyper Oracle）

　　Hyper Oracle把自己定義為去信任的預言機網路。與其他ZKP跨鏈項目的區別在於，Hyper Oracle強調的是整個共識的傳遞。Hyper Oracle的願景是實現端到端的無信任，需要實現輕用戶端驗證以太坊PoS的整個共識。

　　而在以太坊POS的實現中，同步委員會的共識已經是整個共識的一部分了，為什麼還要強調傳遞整個共識呢？

3. Brevis（Celer）

　　Brevis對自己的定義是全鏈計算和驗證平台，本質上也是一種跨鏈通信方案，也是通過生成ZKP共識證明實現去信任的跨鏈通信。Brevis包括了三個組件，分別為zkFabric、zkQueryNet和zkAggregatorRollup。 從目前情況來看，其覆蓋的範圍包括了EVM和NON-EVM鏈，

　　zkFabric的主要功能是收集區塊頭，並在通過 ZKP 輕用戶端電路證明其有效性後，生成共識證明，相當於ZK跨鏈角色當中的中繼者和證明者。當然在這個系統中，中繼的目的地是zkAggregatorRollup。

　　zkAggregator Rollup是由羽量級 ZKP 虛擬機器提供支援的 ZK rollup 區塊鏈，它匯總了來自 zkQueryNet 和 zkFabric 的不同證明和輸入資訊。根據Celer的描述，zkAggregatorRollup VM runtime 具有以下功能：

　　（1 ）遞迴驗證由 zkQueryNet 和 zkFabric 生成的證明；

　　（2 ）存儲來自 zkFabric 並已被 ZKP 驗證的區塊頭；

　　（3 ）存儲查詢請求和 ZKP驗證結果。

　　zkQueryNet是一個提供 ZKP 查詢引擎的開放市場，可直接接受來自鏈上智慧合約的資料查詢，並通過 ZKP查詢引擎電路生成查詢結果和相應的 ZKP 查詢證明。這個結果也會保存在Query Result中（Query Result屬於zkAggregatorRollup 模組）。

　　具體如圖3 所示。

　　（圖3 Brevis系統組成，資料來源：Brevis: A ZK Omnichain Data Attestation Platform）

　　Brevis相對於其他zk跨鏈項目最大的特點是模組化，這種結構化的設計增強了Brevis的可拓展性，通過對不同功能的封裝，Brevis可以實現統一的介面，在方便DAPP調用的同時，也利於後續拓展更多的公鏈。

4. Telepathy（Succinct）

　　Telepathy是由Succinct團隊開發的協定，目標是使使用者可以在無許可、去信任的情況下實現互通性。通過Telepathy，DAPP可以安全地將消息從源鏈發送到任意目標鏈。該定義符合傳統的跨鏈消息定義模型。

　　Telepathy跨鏈通信模型主要有五個步驟，具體如圖4 所示。

　　( 1) 多鏈DAPP合約發起一個多鏈交互操作指令。

　　( 2) Telepathy Broadcaster接受到這個指令後，約在12 分鐘後，Ethereum主鏈形成最終性的共識。

　　( 3) Telepathy Operator使用Etereum共識生成ZKP共識證明。

　　( 4) Telepathy Relayer將共識證明傳遞到目標鏈合約。

　　( 5) 目標鏈輕用戶端合約驗證ZKP共識證明。

　　這種通用的消息跨鏈模型非常適合多鏈鏈間消息通信，並且知名跨鏈專案Across已經宣佈使用Telepathy構建Avalanche 與BNB Chain 之間的跨鏈橋。

　　（圖4 跨鏈消息傳遞模型，資料來源：Telepathy官方簡介）

5. Nil.foundation

　　Nil與Brevis的定位類似，目標是成為多鏈證明市場，DAPP可以根據自己的需求請求Nil生成證明資料。這裡不做過多贅述。

　　此外上篇文章提到的zkLLVM也是Nil的核心產品之一。該產品定位于説明開發者使用高階語言編譯ZKP，極大地降低了開發者的准入門檻。通過這個工具，開發者可以使用自己熟悉的語言專注於電路設計，而不是陷入特定領域語言DSL學習。

四、總結與展望

　　目前眾多團隊都在致力於ZK跨鏈橋的開發。由於ZKP的生成和源鏈共識緊密相關，而不同鏈達成共識的方式、使用的簽名演算法都不相同，在實踐當中，各種方案的效率與特點也不盡相同，具體如表2 所示。

　　表2 基於 ZKP 的主要跨鏈協議比較

　　雖然這些項目都是基於SNARK技術構建的零知識證明系統，但是實現演算法、演算法優化程度、使用的硬體都難以統一，因此上述ZKP的生成速度僅為參考，更多詳細的資料需要進行更嚴謹的基準測試。

　　目前大部分ZK跨鏈橋都支持NON-EVM，在這一點上各項目區別不大。而在未來ZK跨鏈交互操作協議的主要競爭點將在於演算法優化、多鏈部署與合約安全上。

　　鏈下生成ZKP需要大記憶體高性能伺服器，這意味著高昂的設備成本，而優化的演算法可以節省算力。

　　近兩個月很多跨鏈協議都有所動作，基本上都是圍繞ZKP跨鏈開展，普遍上線測試網跨鏈，上線主網的不多。另外很多跨鏈協定普遍都是連結一兩條鏈，並未實現多鏈互通，因此未來跨鏈橋支持的鏈越多就越有競爭優勢。

　　ZK跨鏈項目普遍沒有經歷大規模的市場檢驗，合約的安全性將決定這些項目是否能在這個市場存活。目前這個問題被大多數人所忽略，而未來安全會成為ZKP項目的最大風險項。

　　跨鏈協議是區塊鏈安全事故的重災區，這引發了幾乎所有從業人員對跨鏈協議的擔憂，更為嚴峻的是，目前主流的跨鏈協議幾乎都屬於外部驗證這一大類，無法實現去信任化，存在嚴重的安全風險。一旦中繼者聯合作惡，多鏈生態參與者將面臨無法估量的損失。而ZKP跨鏈作為原生驗證的一類，不僅具有去信任化，通用性等原生驗證跨鏈獨有的優勢，Gas消耗也比直接在目標鏈驗證原始源鏈資料的方式低，最近跨鏈項目方頻繁地推出ZKP跨鏈測試網說明他們也敏銳地發現了這一點。但ZKP跨鏈協議發展仍處於早期，ZKP跨鏈協議是否能夠給使用者帶來更加安全的跨鏈體驗，還有待進一步跟蹤和觀察。