四個項目帶你了解 Layer2 互操作性方案設計

原文標題：一文讀懂 L2 互操作性方案設計：StarkEx、Loopring、Hermez 與 Connext

引子

隨着二層擴容方案如 Polygon、Arbitrum 等紛紛上线，以太坊二層生態呈現百花齊放的格局。與此同時，越來越多的 DeFi 協議宣布與 L2 方案進行合作，將其協議部署或遷移到 L2 上。不同 DeFi 協議對於擴容的需求不同，亦可能選擇不同的 L2 方案。在這種趨勢下，如何在 L1 和 L2 之間進行交互，或是在不同的 L2 之間高效地轉移資金成為一個不小的問題。

例如，如果用戶需要在 L2 的 dYdX 和 L2 的 DeversiFi 之間轉移資金，他需要先將資金從 L2 的 dYdX 提取到 L1，再將資金從 L1 存入 L2 的 DeversiFi。這樣，用戶將不得不支付兩次 gas 費，並耗費大量的等待時間。對於採用欺詐證明的 L2 方案，提現到 L1 的時間甚至可能長達數天。

為此，實現 L2 之間的互操作性是很有必要的。StarkWare 提出了 L2 互操作性 (Interoperability) 的概念，即在 L2 之間轉移資金，且使得轉移過程中在 L1 上的摩擦盡可能小。不同 L2 方案對於互操作性的設計思路各有不同，以下對 StarkEx、Loopring、Hermez 和 Connext 的互操作方案作簡要的敘述。

StarkEx

StarkEx 定義了一個稱為條件交易 (Conditional Transaction) 的原語，即一筆交易的生效與否，取決於其該交易的前置條件是否得到滿足。

延伸閱讀：

《The Road to L2 Interoperability》

《Conditional Transfers - The Key to Interoperability》

條件交易使用 Fact Registry 合約來監聽鏈上事件。某個事件在使用條件交易之前必須首先在 Fact Registry 合約中「登記」。例如，如果 Alice 不經過 Fact Registry 合約，而是直接在以太坊鏈上給 Bob 轉账了 1 ETH，則無法滿足用於條件交易的事件。
Fact Registry 合約中有 transfer() 和 isValid() 兩個函數。

如果 Alice 需要給 Bob 轉账 1 ETH，則將 Bob 的地址作為參數傳給 transfer() 函數，這時 transfer() 函數做兩件事。首先把 1 ETH 轉账給 Bob；其次，保存這筆轉账的記錄到合約的存儲項中，例如保存發送方、收款方、轉账金額的哈希值等信息。

isValid() 函數接受哈希值作為參數，如果輸入哈希值等於 Fact Registry 合約中先前記錄的某哈希值，則返回 True。這樣一來，記錄在合約中的哈希值可以當成是一個「Fact」，代表着某個事件已經發生。這個過程通常稱為「Fact Registration」(本文譯作事實登記)。

條件交易中一筆籤過名的鏈上事件包含兩個字段 (哈希值)：Fact Registry 合約的地址以及在執行這筆條件交易前應該登記的「Fact」。

上圖展示了條件交易在 Fact Registry 合約的工作流程。在 StarkEx 的 zkRollup 中，如果某批次的交易中包含條件交易，將確保其相關的 Fact 是做過登記的，否則整批次的交易都將被回滾。

在 L1/L2 的互操作性中，條件交易有兩個用例：

（1）從 L2 提現到 L1(快速取款)

該用例中有兩位角色，其中 Alice 需要把 1 ETH 從 L2 提現到 L1，流動性提供者 (Liquidity Provider, LP) 在 L1 上有一定的資金。首先，Alice 向 LP 發起一筆條件交易，承諾在 L2 上支付 1 ETH 給 LP 的地址，條件是 LP 在 L1 上支付 1 ETH 給 Alice 的地址。接着，Alice 在 L1 收到 1 ETH 後，這筆條件交易的條件就得到滿足了。此時，LP 把這筆條件交易發送給 L2 的 Operator，等待它被打包到下一證明的交易批次中。當條件交易的證明被提交到 L1 驗證通過之後，LP 在 L2 的地址將增加 1 ETH，即從 Alice 處獲得的資金。(通過這種方式進行快速取款，Alice 需要給 LP 支付一定的手續費)

因為在提供提現服務的時候，LP 在 L1 的資金持續減少，在 L2 的資金持續增加，所以 LP 需要定期地從 L2 提現到 L1，進行資金的再平衡。

（2） L2_1 與 L2_2 之間轉账

用例 2 的解決思路與用例 1 類似，即：Alice 向 LP 發起一筆已籤名的條件交易，承諾在 L2_1 上支付 1 ETH 給 LP 的地址，條件是 LP 在 L2_2 上支付 1 ETH 給 Alice 的地址。(Alice 和 LP 同樣需要分別支付手續費和進行資金再平衡)

在用例 2 的基礎上進行延申，無論是使用有效性證明的系統 (zkRollup)，還是使用欺詐證明的系統 (Optimistic Rollup) 都可採用條件交易。當然相較提現確認快的 zkRollup 而言，Optimistic Rollup 上 LP 的資金效率會存在劣勢。

在任一 L2 方案中從 L2 提現資金到 L1，需要最終確定 L2 的狀態更新 (在這次更新中包含提現的那筆交易)。在有效性證明的 L2 方案中，一般至少需要等待 10 分鐘。在欺詐證明的系統中可能需要等待數天。而採用基於條件交易的快速取款則可以使提現擺脫對 L2 狀態更新的依賴，實現在「區塊鏈時間」級別 (blockchain-time) 完成資金的轉移。

StarkEx 提出條件交易來實現 L2 的互操作性，思路跟 Rollup 很類似。即每個用戶提現的多筆費用，轉化為 LP 在進行資金再平衡時從 L2 提現到 L1 的單筆費用。對比高昂的 gas 費，用戶支付給 LP 的少量手續費顯然更加劃算。

Loopring

路印融合了其現有工具包的組件，提出了跨 L1、L2 和 CEX 的網橋產品 Ethport。

延伸閱讀：

《Ethport: Loopring L1/L2/CEX》

關於 L1 和 L2 之間的交互，路印的方案是將多筆 L1 的交易進行批處理，以此來分攤 L1 的 gas 成本。與上述思路近似，路印在 L2 上同樣設置了流動性提供者的角色。但考慮到流動性提供者的資金效率問題，路印提出了單相轉換器 (Single Phase Converter)。

單相轉換器使用了 L2 上 token 的閃電鑄造 (Flash Minting) 功能。即調用閃電鑄造出用戶們想要購买的 token 總量，使得所有交易可以在 L2 上完成 (按照預期的 token 匯率)。之後再提取用戶出售的所有 token，在 L1 上執行這些 token 交易並獲得用戶真正要購买的 token(先前已經通過閃電鑄造分發給用戶了)。最後再把這些 token 償還給閃電鑄造。

延伸閱讀：

《Flash-Mintable Asset-Backed Tokens. OpenZeppelin》

這是一種理想化的情況，在現實情況下，token 匯率可能產生變化，並且在 L1 上的交易也存在失敗的可能性。這時產生了無法償還閃電鑄造的風險，意味着先前 L2 上的所有交易將被回退。

鑑於該問題，路印接着提出了二相轉換器 (Double Phase Converter)。

二相轉換器將交易分為兩個階段。第一階段首先將所有用戶的資金收集到 Vault 中 (針對特定 token 兌換)，給用戶一個表示其資產 Vault 中所佔份額的 token，而不是直接把 token 兌換給用戶。之後再進行 L1 上的交易，以此確定好兌換的匯率。在第二階段則可將兌換完畢的 token 按比例分配給所有的用戶，以此解決匯率變化的問題。

此外，橋 (Bridge) 機制使得多個用戶能夠通過 L1 的智能合約，將資金批量地存入路印中，而不是逐一地單獨加入 L2 網絡。這種設計將多筆存款交易匯集成一筆交易，降低了 gas 花費。借助橋，中心化交易所也可以使用標准的 L1 基礎設施來支持路印的 L2 網絡。

基於以上組件的 Ethport，在實際應用時首先盡可能地使用 L2 上的流動性；如果轉換器可供使用，則用它來將 L1 交易匯集起來，降低交易費用；如果以上條件不滿足則使用橋機制。

Hermez

Hermez 由 iden3 團隊推出，提出的 L2 間交互解決方案是大規模遷移 (Massive Migrations)。

延伸閱讀：

《Introducing the First L2 Interoperability Mechanism with Hermez Massive Migrations》

其思路是：首先，負責進行 L1 資金轉移的智能合約有一個 L2_1 上的地址。在需要跨 L2 轉账時，用戶將把資金轉入到該地址。之後，Hermez 協議將對有着相同 L2_2 地址的一批 L2 轉账進行分組和提取，調用標准的 Hermez 函數將這批 L2 轉账的資金總額提現到 L1，再存入到 L2_2。

Hermez 協議在執行上述聚合提款交易時，包含了在 L2_2 上重構 L2_1 原始轉账所需的信息和對應的账戶信息。在 L2_2 上有一個調度員的角色，負責處理 L1 的取款交易，並從交易信息中分解出資金的流向，再轉入到與用戶的 L2_1 地址對應的 L2_2 地址上。

Connext

Connext 是基於狀態通道的 L2 擴容方案，支持兼容 EVM 的公鏈和 L2 系統之間的快速交易。在今年年初發布了即時跨 L2 轉账產品「Vector」的 0.1.0 版本，旨在連通各 L2 方案之間的流動性，實現資產的跨 L2 轉移，並在三月份推出 xDai-Polygon Bridge 測試版，允許用戶使用狀態通道將 xDai 轉至 Polygon 上的 Dai，或是將 Polygon 上的 Dai 轉至 xDai。

Connext 通過路由器 (Router) 實現跨 L2 的資金轉移。Connext 路由器實際上是一個狀態通道節點，它會自動地轉發在狀態通道內發送給它的交易。對於跨鏈交易來說，路由器相當於流動性提供者，通過在 chainB 上的狀態通道內向用戶轉移資金，來換取用戶在 chainA 上的資金 (這個思路跟 StarkEx 和路印類似)。

延伸閱讀：

《Solving the Liquidity Problem》

例如，如果 Alice 想把 100 USDC 從 Polygon 發送到 Arbitrum，她需要使用路由器把 100 USDC 存入 Polygon 上的狀態通道中。然後，Alice 向該路由器發送一筆狀態通道內轉账，條件是 Alice 在 Arbitrum 上的對應的狀態通道內收到轉账。目前這種條件性的實現依賴於哈希鎖定 (Hashlock)。這些轉账以原子方式解鎖，可實現免信任。路由器在跨 L2 過程中能夠賺取 Alice 支付的手續費。

然而，借助流動性提供者的跨 L2 方案不可避免地會有資金效率的問題。Connext 提出了虛擬 AMMs(Virtual AMMs) 來解決這個問題。

在 Uniswap 中，資金池的兌換比例越不平衡，價格差異就越大。這也創造了一個持續增長的套利機會。虛擬 AMMs 借鑑了 Uniswap 的核心概念來為 L2 間資產轉移做定價。

考慮一種情況：某個時刻 LP 在 Arbitrum 池的 ETH 數量大於其在 Optimism 池的 ETH 數量，系統希望能平衡兩個池子的 ETH 數量。根據上圖公式的比例兌換關系，假設 0.99 個 Optimism 上的 ETH 可以換到 1 個 Arbitrum 上的 ETH，此時產生套利機會。則套利者會用其在 Optimism 的 ETH 去兌換 Arbitrum 的 ETH。這樣一來，對於 LP 來說，其在 Optimism 池的 ETH 數量變多，在 Arbitrum 池的 ETH 數量變少，以此達到通過套利活動平衡流動性的目的。

另外，在 Connext 上任何人都可以啓動自己的路由器來提供流動性。這樣導致流動性不會被聚合——一些路由器可能超負荷，一些路由器可能無人問津。於是，Connext 又提出了流動性拍賣的概念 (Liquidity Auctions)，即動態地尋找提供最低成本的路由器。
在進行轉账時，用戶向網絡廣播想要的發送或接收流動性。路由器會直接向用戶提交密封式的報價 (Sealed Bids)，以最低價格完成轉账。這有點類似於 Uber 將用戶與價格最低的司機匹配。

小結

關於 L1、L2 的互操作性問題，上述四個 L2 方案都採用了近似的思路，即引入流動性提供者，將多筆交易聚合為一筆交易進行處理。面對流動性提供者的資金效率問題，各個項目採用的解決方法有所不同、各有優劣。

總體來看，由於各 L2 方案的採用率有限，上述互操作性的方案實際應用效率如何，仍要經歷實用性的檢驗。

撰文：Jiawei，就職於 ZKSwap 團隊

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。