作者：Lisa A.，Taiko Labs；翻譯：金色財經xiaozou
本文將從rollup角度探討不同L2跨鏈消息傳遞方法，著重探討無需信任的跨鏈通信。我們將簡要了解直接讀取狀態方法、輕客戶端方法以及存儲證明。我們還會涉及到證明聚合機制、可信第三方跨鏈消息傳輸和核心ZK跨鏈解決方案。最後，我們再來看當今不同的L2是如何實現跨鏈消息傳遞的。
1、跨鏈消息傳遞簡介
對於跨鏈通信，所有各方（L2、L3等）必須能夠直接訪問最新的以太坊狀態根。
所有存款層都有一個“內置”的跨鏈機制，可用來訪問L1狀態根，狀態根將作為存款消息傳遞給L2。
1.1 狀態根的兩種訪問類型
類型1：直接讀取狀態根——可以通過操作碼或預編譯完成。然而，至今還沒有實現，所以不需要任何proof證明。
· Brecht Devos在一篇研究文章中描述了一種可能的直接讀取狀態的方法：“……我們可以公開一個預編譯合約，它可以直接調用目標鏈上的智能合約。這種預編譯直接在源鏈中插入並執行另一條鏈的智能合約代碼。這確保了智能合約始終能夠以高效且易於證明的方式訪問最新的可用狀態。”
· 在Optimism的RFP“遠程靜態調用概念證明”中亦有相關描述。
類型2：證明生成——即在另一個區塊鏈上證明關於一個區塊鏈的陳述。
“帶證明的跨鏈消息傳遞”有兩種方法：
· 無需信任的跨鏈通信——也就是說，沒有可信的第三方（例如，使用輕客戶端或存儲證明）。無需信任的方法既可用於第三方生成證明，也可用於跨鏈通信參與者自己生成證明。
· 在不同的rollup之間共享證明，以確保跨鏈操作。這個方法本文不多做討論，目前正處於研究和探索階段，並且不被認為是一個可能廣泛應用的解決方案。
1.2 “帶證明的跨鏈消息傳遞”方法
1.2.1 輕客戶端跨鏈消息傳遞
證明鏈B上的數據
· 從鏈B全節點（如需對某些歷史狀態進行存儲證明則為archive歸檔節點）獲取默克爾證明數據；
· 將與包含我們想要驗證的狀態的鏈B區塊相對應的區塊頭和證明數據作為calldata發送給鏈A上的證明者合約；
· 證明者合約根據區塊頭數據計算區塊哈希值，查詢鏈A上的輕客戶端智能合約（跟踪鏈B的區塊哈希值），並檢查哈希值是否有效；
· 證明數據是根據區塊頭中的bytes32狀態根進行驗證的。
1.2.2 存儲證明
存儲證明有兩個“workflow”選項：
· 生成存儲證明→在鏈上使用
· 生成存儲證明→生成zk證明→在鏈上使用
也可能有一個實體將多個證明收集打包為單個證明（包括存儲證明和zk證明）。這是一個可選的優化步驟，暫不討論。
下面我們來看下存儲證明“workflow”的三個主要階段：生成存儲證明、生成zk證明、鏈上使用。
（1）生成存儲證明
· 存儲證明允許我們使用機密承諾證明某些信息存在於區塊鏈上，並且是真實的；
· 自1979年默克爾樹出現之後，存儲證明一直是加密領域的一部分。然而，vanilla儲存證明通常相當大。現代創新在於將存儲證明與可證明的計算相結合，創造出可以在鏈上驗證的簡潔證明。
要生成存儲證明，必須提供特定的數據塊及其在默克爾樹中的關聯Merkle或Verkle路徑。該路徑由使用相同的哈希算法重建根哈希值所需的兄弟哈希值組成。
要驗證存儲證明，接收方可以使用所提供的數據和Merkle或Verkle路徑來重新計算根哈希值。如果重新計算的根哈希值與已知的根哈希值相匹配，則接收方可以確信該數據是真實的，是已提交數據集的一部分。
（2）生成ZKP（零知識證明）
然而，以太坊類型的存儲證明約為4kb——對於將整個存儲證明發佈到目標鏈上來說相當大，因為證明驗證將非常昂貴。因此，使用ZKP（例如，ZK-SNARK）進行壓縮是合理的，可以使證明更小、驗證成本更低。
（3）Unroll ZKP
獲得ZKP後，目標鏈上的用戶可以unroll他們獲得的證明（例如，通過區塊頭或區塊哈希值訪問歷史狀態）。
Unroll可以通過如下方式進行：
鏈上積累：從證明中重建區塊頭的整個過程直接在區塊鏈上執行。缺點：gas費高，耗費計算資源；優點：沒有額外的證明時間，延遲很低，因為不需要在區塊鏈之外生成證明。
鏈上壓縮：從數據中刪除冗餘或不必要的信息，或使用為提高空間效率優化過的數據結構。壓縮後的數據被發送到區塊鏈，並可以在需要時解壓縮。缺點：壓縮和解壓數據可能意味著需要額外的計算，但是這種延遲也許可以忽略不計。使用的壓縮算法可能會對數據的安全性帶來負面影響；優點：降低數據成本。
鏈下存儲：將數據存儲在鏈下，按需將特定數據塊放在鏈上。這與出於某種原因需要存儲大量數據的解決方案相關（例如，從創世區塊開始的以太坊archive節點）。缺點：與鏈上壓縮相同；優點：進一步降低數據成本。
1.2.3 可信第三方
完整的跨鏈解決方案還應涉及到具有可信第三方（如oracle、中心化橋等）的跨消息傳遞解決方案。
1.2.4 “通用”證明系統
在使用共享證明聚合平台機制的情況下，可以通過接收在聚合平台內結算的區塊哈希值來加快消息傳遞速度，並且此處的結算還將處理消息傳遞（但是如果證明聚合平台出現了問題怎麼辦？）。
1.2.5 ZK跨鏈消息傳遞的一些不明問題
如果沒有可信的第三方（可以是單個實體或多個實體），跨鏈消息傳遞是否可行？跨鏈消息傳遞的有效機制是什麼？一般來說，對於以太坊L2（可以直接訪問L1的區塊哈希值）和以太坊本身來說，如果一條鏈可以在另一條鏈上運行輕客戶端等，它就可以驗證來自該外部鏈的區塊頭，這對無需信任的跨鏈消息傳遞來說足夠了。
用於跨鏈證明生成的ZK電路是否規模適宜？在某些情況下，特別是當共識層（需要對跨鏈操作進行驗證）非常大時，用於ZK跨鏈消息傳遞的電路可能比rollup和鏈上存儲大幾個數量級，並且計算開銷也很大。推測這個問題可以通過更中心化的方法來克服。
2、跨鏈消息傳遞解決方案示例
· Succinct Labs使用輕客戶端來驗證從源鏈到目標鏈共識層的共識。具體想法是存在一個輕客戶端協議，以確保節點可以同步最終區塊鏈狀態的區塊頭。 ZKP用於生成共識證明。
· Lagrange Labs構建非交互式跨鏈狀態證明。 Lagrange證明網絡負責創建狀態根。每個Lagrange節點都包含一個分片私鑰的一部分，用來證明特定鏈的狀態。每個狀態根都是一個閾值簽名的Verkle根，可用於證明特定鏈在特定時間的狀態。狀態根是完全通用的，可以在狀態證明中使用，以證明鏈中任何一個合約或錢包的當前狀態。
· Herodotus使用ZKP存儲證明提供智能合約，同步訪問其他以太坊層的鏈上數據。針對驗證，它使用原生的L1<>L2消息傳遞來同步以太坊rollup之間的區塊哈希值。
· =nil; Foundation（Mina、L1）允許以太坊上的智能合約驗證Mina狀態的有效性。生成特殊用途的狀態證明，在以太坊上進行驗證的成本很低（在以太坊上進行本地Mina證明的成本很高）。假設（在未來的某個時候）應用程序可以直接使用Mina的證明生成工具來檢查跨鏈交易的有效性。 =nil; Foundation還有一個Proof Market（證明市場），用戶/項目可以主要購買/出售SNARK證明，這些證明允許無需信任的數據訪問。
· Axiom：如果Axiom已經為至今為止的賬本生成了ZKP——它不需要為特定的數據塊生成ZKP——它可以將這個ZKP傳遞給鏈（作為Relayer中繼器），甚至可以提供對該ZKP的訪問。
3、L2的跨鏈消息傳遞
聲明：對於大多數L2來說，跨鏈消息傳遞仍在發展進步。下面的所有分析都是基於開源信息。也就是說，文中提到的解決方案可能正處於探索和測試階段，rollup最終可能採用其他方法。
（1）Taiko
· Taiko存儲每個鏈的區塊哈希值。對於每對鏈，它都部署兩個智能合約，存儲彼此的哈希值。在L2←→L1的例子中，每次在Taiko上創建一個L2區塊時，L1上的外圍塊的哈希值就存儲在TaikoL2合約中。在L1←→L2的情況下也是同樣的運行方式。
· 可以通過調用TaikoL1/TaikoL2合約上的getCrossChainBlockHash(0)來獲取存儲在目標鏈上的最新已知Merkle根，並獲得要驗證的值/消息。通過在“源鏈”上使用標準RPC調用eth_getProof請求，可以獲得最新已知的Merkle根的兄弟哈希值。
· 然後，只需發送它們根據存儲在“目標鏈”上列表中的最新已知區塊哈希值進行驗證。驗證者將獲取一個值（默克爾樹上的一片葉子）和兄弟哈希值來重新計算Merkle根，並檢查它是否與存儲在目標鏈的區塊哈希值列表中的根相匹配。
（2）Starknet
Starknet使用存儲證明進行無需信任的跨鏈消息傳遞。
L2→L1消息傳遞協議
· 在Starknet交易執行期間，Starknet上的合約發送一條L2→L1消息。
· 然後將消息參數（包含L1上的接收方合約和相關數據）附加到相關的狀態更新（主存儲樹）。
· L2消息存儲在智能合約的L1上。
· 在L1上發出一個事件（存儲消息參數）。
· L1上的接收方地址可以通過重新提供消息參數來訪問和使用該消息作為L1交易的一部分。
· 跨鏈消息存儲在主幹樹中。
L2 → L1
L1 → L2
（3）Optimism
· L1和L2之間的通信是由兩個稱為“messenger”的特殊智能合約實現的。
· 針對Optimism(L2)到以太坊(L1)的交易，有必要在狀態根寫入後提供關於L1上消息的默克爾證明。在該證明交易成為L1鏈的一部分之後，錯誤挑戰期開始。在此等待期之後，任何用戶都可以通過觸發以太坊上的第二筆交易來“最終完成”交易，將消息發送到目標L1合約。
· 跨鏈消息存儲在主幹樹中。
（4）Arbitrum
· Retryable tickets是Arbitrum用於創建L1到L2消息傳遞的規範方法，即初始化要在L2上執行的消息的L1交易。可以在L1上支付固定費用（僅取決於其calldata大小）提交一個Retryable。主狀態樹用於智能合約中自定義數據格式的跨鏈通信。在L1上提交retryable ticket與L2上的執行是可以分離/異步的。 Retryables提供跨鏈操作之間的原子性。如果L1交易請求提交成功（即沒有回滾），那麼L2上的Retryable執行就有了一個強有力的保證，最終也會成功。
· Arbitrum有兩個樹幹：Nitro鏈以以太坊的狀態樹格式進行維護，為Merkle樹。 Assertion Tree（證明樹）存儲通過“assertion”在以太坊上確認的Arbitrum鏈的狀態。推進Arbitrum鏈的規則是確定性的。這意味著針對給定的一個鏈的狀態和一些新的輸入值，只有一個有效輸出。因此，如果該證明樹包含多個葉子，那麼最多只有一個葉子可以表示有效的鏈狀態。
· Arbitrum的Outbox系統允許任意L2到L1的合約調用，即從L2發起消息，最終在L1上執行。 L2到L1消息（又名“outgoing message”）與Arbitrum的L1到L2消息（Retryable）有許多共同之處，儘管有一些明顯的區別。 Arbitrum鏈的L2狀態的一部分——也就是每個RBlock中證明的部分——是鏈歷史中所有L2到L1消息的默克爾根。在證明的RBlock被確認後（通常為證明後約一周），該Merkle根包含在Outbox合約中被發佈到L1上。然後，Outbox合約允許用戶執行他們的消息。
（5）Polygon zkEVM
· 該zkEVM的Bridge SC為參與通信或資產交易的每個網絡使用一種稱為Exit Tree的特殊默克爾樹。
· 它使用Merkle根（在一個單獨的狀態樹中），可以在github上找到一個橋接架構圖。
· zkEVM Bridge SC的部署在以太坊2.0存款合約的基礎上進行了若干改動。例如，它使用了專門設計的append-only默克爾樹，但採用了與以太坊2.0存款合約相同的邏輯。其他差異與基本哈希值和葉節點有關。
· Polygon zkEVM Bridge智能合約的主要特點是使用Exit Tree和全局Exit Tree，其中全局Exit Tree的根是truth狀態的主要來源。因此，L1和L2有兩個不同的全局Exit根管理器，Bridge SC有一個單獨的邏輯。
（6）Scroll
· 部署在以太坊和Scroll上的橋合約允許用戶在L1和L2之間傳遞任意消息。在此消息傳遞協議之上，我們還構建了一個無需信任的橋接協議，以允許用戶在L1和L2之間橋接ERC-20資產。為了從以太坊向Scroll發送消息或資金，用戶調用Bridge合約上的sendMessage交易。中繼器將在L1上索引此交易，並將其發送到排序器，以包含在L2區塊中。在L2橋合約上，將消息從Scroll發送回以太坊的過程類似。
· 跨鏈消息存儲在常規消息隊列中。排序器從這個隊列中攝取跨鏈消息，並將它們作為常規交易添加到鏈上。
（7）zksync Era
聲明：本部分內容僅關於zksync Era，可能與ZK Stack上的跨鏈消息傳遞不同，ZK Stack是用於構建主權ZK超級鏈的模塊化框架。
· 每個交易包都有一個單獨的L2->L1消息。
· 不可能直接從L2發送交易到L1上。然而，你可以從zkSync Era向以太坊發送任意長度的消息，然後使用L1智能合約在以太坊上處理接收到的消息。 zkSync Era有一個請求證明函數，該函數將返回一個布爾參數，指示消息是否成功發送到了L1。通過觀察以太坊或使用zksync-web3 API的zks_getL2ToL1LogProof方法來檢索消息包含的默克爾證明。
· 對於L1→L2，zkSync Era智能合約允許發送方在以太坊L1上請求交易，並將數據傳遞給zkSync Era L2。
· 橋合約：https://github.com/matter-labs/era-contracts/blob/main/ethereum/contracts/bridge/L1ERC20Bridge.sol
4、結論
跨鏈通信對於區塊鏈大規模採用的“必備”應用程序是不可或缺的（例如，V神文章中描述的跨鏈社交恢復錢包）。目前使用的大多數跨鏈解決方案都是為L1←→L2設計的，以覆蓋提款功能。這些解決方案可以擴展到更多的區塊鏈。但與此同時，可以實施更先進的跨鏈通信解決方案，例如完全不需要證明的“直接讀取狀態”或無需信任的“存儲證明”。對於大多數L2來說，跨鏈通信仍有發展進步的空間。
