關於 L1、L2 的互操作性問題,四個 L2 方案都採用了近似的思路,不同處在於流動性提供者資金效率問題的解決方法。

撰文:Jiawei,就職於 ZKSwap 團隊

引子

隨着二層擴容方案如 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」。

一文讀懂 L2 互操作性方案設計:StarkEx、Loopring、Hermez 與 Connext

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

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

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

一文讀懂 L2 互操作性方案設計:StarkEx、Loopring、Hermez 與 Connext

該用例中有兩位角色,其中 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 之間轉賬

一文讀懂 L2 互操作性方案設計:StarkEx、Loopring、Hermez 與 Connext

用例 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 互操作性方案設計:StarkEx、Loopring、Hermez 與 Connext

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

延伸閱讀:

《Flash-Mintable Asset-Backed Tokens. OpenZeppelin》

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

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

一文讀懂 L2 互操作性方案設計:StarkEx、Loopring、Hermez 與 Connext

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

一文讀懂 L2 互操作性方案設計:StarkEx、Loopring、Hermez 與 Connext

此外,橋 (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》

一文讀懂 L2 互操作性方案設計:StarkEx、Loopring、Hermez 與 Connext

其思路是:首先,負責進行 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》

一文讀懂 L2 互操作性方案設計:StarkEx、Loopring、Hermez 與 Connext

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

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

一文讀懂 L2 互操作性方案設計:StarkEx、Loopring、Hermez 與 Connext

在 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 數量變少,以此達到通過套利活動平衡流動性的目的。

一文讀懂 L2 互操作性方案設計:StarkEx、Loopring、Hermez 與 Connext

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

小結

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

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