免責聲明: 金色財經作為開放的資訊分享平臺,所提供的所有資訊僅代表作者個人觀點,與金色財經平臺立場無關,且不構成任何投資理財建議。
APP
中國版App下載 Android & iPhone
金色專欄
  • 專欄申請

四個項目帶你了解 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」。

一文讀懂 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 方案的采用率有限,上述互操作性的方案實際應用效率如何,仍要經歷實用性的檢驗。

撰文:Jiawei,就職于?ZKSwap?團隊

jinse.com
好文章,需要你的鼓勵
jinse.com
好文章,需要你的鼓勵
發表評論
0/140
發布評論
評論
文章作者: / 責任編輯: 我要糾錯

聲明:本文由入駐金色財經的作者撰寫,觀點僅代表作者本人,絕不代表金色財經贊同其觀點或證實其描述。

提示:投資有風險,入市須謹慎。本資訊不作為投資理財建議。

金色財經 > 區塊鏈 > 四個項目帶你了解 Layer2 互操作性方案設計
乐天堂手机app Fun88| FUN88登录| fun88官网| fun88官网备用| FUN88手机版| Fun88乐天堂| 梦飞翔| 乐体育| 乐体育官网| 乐体育网址| 乐天堂app下载| 乐天堂fun88体育官网| 乐天堂fun88入口| 乐天堂国际| 乐天堂手机app| 乐天堂手机app下载| 乐天使| 热天堂| 热天堂官网| 乐天堂fun88| FUN88电竞| 乐天堂入口| 乐天堂最新网址| 乐天堂备用网址| 乐天堂体育官网| 乐天堂fun88电竞| 乐天堂体育官网平台| 乐天堂注册| 乐天堂fun88国际| 乐天堂备用网站| 乐天堂电竞体育综合平台| fun88地址| fun88首页| fun88乐天堂网址| 天堂fun88| 乐天堂app| 乐天堂网址| 乐天堂电竞平台| fun88亚洲体育| 乐天堂手机版| 乐天堂体育注册| 乐天堂首页| 乐天堂88| 乐天堂fun88体育投注| 乐天堂fun88投注| 乐天堂fun88app| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>