前Arbitrum技術大使解讀Arbitrum的組件結構(下)

新手Feb 27, 2024
本文是Arbitrum前技術大使 及 智能合約自動化審計公司Goplus Security前聯合創始人羅奔奔 對Arbitrum One的技術解讀。
前Arbitrum技術大使解讀Arbitrum的組件結構(下)

正文:此前的文章中,我們曾提到,Sequencer Inbox合約專門在Layer1上接收排序器髮布的交易數據包Batch。衕時,我們指出,Sequencer Inbox又被稱作快箱,與之相對的是慢箱Delayed Inbox(簡稱Inbox)。下麵,我們將對Delayed Inbox等與跨鏈消息傳遞相關的組件進行細緻解讀。

跨鏈與橋接的原理

跨鏈交易可分爲L1到L2(充值)與L2到L1(提現)。註意這⾥所説的充值和提現未必與資産跨鏈相關,可以是不直接附帶資産的消息傳遞。所以這兩個詞僅僅錶示跨鏈相關行爲的兩個⽅曏。

跨鏈交易與純L2交易相⽐,跨鏈交易在L1和L2這兩個不衕的繫統中進⾏了信息互換,因此過程更覆雜。

另外,通常我們説的跨鏈⾏爲,是在兩個毫不相關的⽹絡上,⽤⻅證⼈模式的跨鏈橋進⾏的跨鏈,這種跨鏈的安全性取決於跨鏈橋的運營者,歷史上基於見證人模式的跨鏈橋被盜事件頻繁髮生。

⽽在Rollup與ETH主⽹之間的跨鏈⾏爲,與上述跨鏈有本質不衕,因爲Layer2的狀態是由記録在Layer1上的數據決定的,隻要你使⽤的是Rollup官⽅的跨鏈橋,其在運作結構上是絶對安全的。

這也凸顯出Rollup的本質,它隻是在⽤戶角度看,像⼀條獨立的鏈,但實際上所謂的“Layer2”隻是Rollup對⽤戶敞開的快速展示窗⼝,它的真實鏈式結構還是刻録在Layer1上。所以,我們可以認爲L2算半條鏈,或者説是“在Layer1上創造出的一條鏈”。

可重試票據 Retryables

需要註意,跨鏈都是異步和非原子性的,它不可能像在一條鏈上一樣做完一筆交易確認後就知道結果,也不能保證另一側一定會在某個時間點髮生某些事。因此跨鏈有可能因爲一些軟性問題而失敗,但隻要使用正確的手段,諸如可重試票據(Retryable Ticket),就不會髮生資金卡住等硬性問題。

可重試票據是通過Arbitrum官方橋充值時,用到的基本工具,ETH和ERC20的充值都會使⽤到。其⽣命周期分爲三步:

  1. 在L1上提交票據。在Delayed Inbox合約中使用createRetryableTicket()方法創建充值票據,併提交。

  2. L2上自動兌付。大部分情況下,排序器可以自動幫用戶兌付票據,無需後續的手動操作。

  3. L2上手動兌付。部分邊緣情況,如L2上gas價格突然激增,票據上預付的gas不夠,則無法自動兌付。此時需要用戶手動操作。註意,如果自動兌付失敗,需要在7日內手動兌付票據,否則要麽票據將會被刪除(資金會永久損失),要麽需要爲票據的保存支付一定費用來續租。

另外,對於Arbitrum官方橋的提現流程,雖然和充值行爲在流程上有一定對稱相似性,但併沒有Retryables這個概念,一方麵可以從Rollup協議本身理解,另一方麵我們可以從一些區別進行理解:

  • 提現的過程中不存在自動兌付,因爲EVM沒有定時器或自動化,而L2上可以實現自動兌付,是排序器幫忙實現的,所以L1上用戶要手動與Outbox合約交互,以Claim取回資産。

  • 提現也不存在票據過期的問題,隻要過了挑戰期,可以在任意時間領取。

ERC-20資産跨鏈 Gateway

ERC-20資産的跨鏈是覆雜的。我們可以思考幾個問題:

  • 一個在L1上部署的代幣,它在L2上要如何部署?
  • 它的L2對應合約需要預先手動部署,還是繫統可以自動爲跨過來的、但尚未部署合約的代幣 自動部署資産合約?
  • L1上的ERC-20資産,在L2對應的合約地址是什麽?是否該和L1一緻?
  • 在L2上原生髮行的代幣,如何跨鏈至L1?
  • 擁有特殊功能的代幣,如可調整數量的Rebase型代幣,自增長生息代幣,如何跨鏈?

我們不打算全部回答這些問題,因爲展開太過覆雜。這些問題僅是用來説明ERC20跨鏈的覆雜性。

目前非常多擴容方案使用的都是白名單+手動清單的方案,來規避各種覆雜的問題和邊界情況。

Arbitrum使用了Gateway繫統,解決了大部分ERC20跨鏈的痛點,具有以下特性:

  • Gateway組件在L1和L2成對出現。
  • Gateway Router負責維護Token L1<->Token L2之間的地址映射,以及some token<->some gateway之間的映射。
  • Gateway本身可分爲StandardERC20 gateway,Generic-custom gateway,Custom gateway等等,用以解決不衕類型的和功能ERC20的橋接問題。

我們以比較簡單的WETH跨鏈爲例,來説明自定義gateway的必要性。

WETH是一種ETH的ERC20等價物。Ether作爲主幣,很多dApp中的覆雜功能是無法實現的,因此需要一個ERC20的等價物。曏WETH合約內轉入一些ETH,它們會被鎖在合約內,併生成出相衕數量的WETH。

衕理,也可以銷毀WETH,取出ETH。顯然,流通的WETH和鎖倉的ETH數量永遠是1:1的。

如果現在把WETH直接跨鏈到L2上,我們會髮現一些奇怪的問題:

  • 無法在L2上把WETH進行Unwrap變成ETH,因爲L2上併沒有鎖倉對應的ETH。
  • Wrap功能可以使用,但這些新生成的WETH如果跨回到L1,也無法在L1上解封裝爲ETH,因爲L1和L2上的WETH合約不是“對稱的”。

顯然這違反了WETH的設計原理。那麽WETH在跨鏈時,不論是充值還是提現,都需要先Unwrap成ETH後,再跨到對麵,然後Wrap成WETH。這個也就是WETH Gateway的作用。

其他有更覆雜邏輯的代幣衕理,需要更覆雜和精心設計的Gateway才能正常在跨鏈環境下工作。Arbitrum的自定義Gateway繼承了普通Gateway的跨鏈通信邏輯,併允許開髮者自定義與代幣邏輯相關的跨鏈行爲,可滿足大部分需求。

慢收件箱Delayed Inbox

與快箱也即 SequencerInbox相對應的是慢箱 Inbox (全稱Delayed Inbox)。爲什麽要有快慢之分呢?因爲快箱是專⻔接收排序器髮布的L2交易Batch的,所有未經排序器在L2網絡內預處理的交易,都不該出現在快箱合約中。

慢箱的第⼀點作⽤是,處理L1到L2的充值⾏爲。⽤戶通過慢箱進⾏充值,排序器監聽到後再反映在L2上,最終這筆充值記録會被排序器包含進L2的交易序列中,併提交⾄快箱合約Sequencer Inbox。

在這個例⼦中,⽤戶直接曏快箱提交充值交易是不合適的,因爲提交到快箱Sequencer Inbox中的交易,會幹擾到Layer2正常的交易排序,然後會影響到排序器的工作。

慢箱的第⼆個作⽤,是抗審查。用戶直接提交⾄慢箱合約中的交易,排序器⼀般會在10分鐘內歸集到快箱中。但如果排序器惡意忽略你的請求,慢箱還有⼀個強製歸集force inclusion功能:

如果交易被提交至Delayed Inbox中,經過24小時,慢箱中的交易仍未被排序器包含至交易序列中,用戶可以在Layer1上手動觸髮force inclusion函數,把被排序器忽略掉的交易請求,強製歸集到快箱Sequencer Inbox中,之後就會被全體Arbitrum One節點監聽到,會被強製包含進Layer2交易序列裡。

我們剛才提到過,快箱⾥的數據就是L2的歷史數據實體。所以在被惡意審查的情況下,通過慢箱可以讓交易指令最終包含進L2賬本中,這涵蓋了強製提款等逃離Layer2的場景。

由此可以看出,對任何⼀個⽅曏和層次的交易,排序器最終都⽆法永久審查你。

慢箱Inbox的幾個核心函數:

  • depositETH(),最簡單的充值ETH的函數。
  • createRetryableTicket(),可用於ETH和ERC20以及消息的充值。相較depositETH()而言,有更高的靈活性,例如可指定充值後L2的收款地址等。
  • forceInclusion(),也即強製歸集功能,任何⼈都可以調⽤。該函數會校驗,提交至慢箱合約中的某筆交易,是否過了24小時還沒被處理。如果條件滿⾜,則將對消息進⾏強製歸集。

不過需要註意,force Inclusion函數實際上位於快箱合約中,隻是爲了⽅便理解,我們將其放在慢箱這⾥⼀起講解。

出站箱Outbox

出站箱Outbox隻與提現有關,可以理解爲提現行爲的記録和管理繫統:

  • 我們知道,Arbitrum官方橋的提現需要等待約7天的挑戰期結束, Rollup Block 最終敲定後,提款行爲才可以實施。⽤戶在挑戰期結束後,曏Layer1上的Outbox合約提交相應的Merkle Proof,它再與其他職能的合約通信(如解鎖其他合約中鎖定的資産),最終完成提現。
  • OutBox合約會記録哪些L2到L1的跨鏈消息已經被處理過,以防止有人反覆提交執行過的提現請求。它通過
    mapping(uint256 => bytes32) public spent,記録提現請求的spent Index與信息對應關繫,如果mapping[spentIndex] != bytes32(0)則該請求已被提現過。原理類似於防止重放攻擊的交易計數器Nonce。

下⾯我們將以ETH爲例完整講解充值與提現的流程。ERC20與之不衕的僅僅是⾛了Gateway,就不再贅述。

ETH充值

  1. 用戶調用慢箱的depositETH()函數。

  2. 該函數會繼續調用bridge.enqueueDelayedMessage(),在bridge合約中記録該消息,併將ETH髮送往bridge合約。所有的ETH充值資金,都保管在bridge合約中,相當於一個充值地址。

  3. 排序器監聽到慢箱中的充值消息,將充值操作反映⾄L2數據庫中,⽤戶可以在L2網絡看到自己充進來的資産。

  4. 排序器將該筆充值記録包含進交易批次batch,提交給L1上的快箱合約。

ETH提現

  1. ⽤戶在L2上調⽤ ArbSys合約的withdrawEth()函數 ,在L2上銷毀相應數量的ETH。

  2. 排序器將該提現請求髮送⾄快箱。

  3. Validator節點根據快箱中的交易序列,創建新的Rollup Block,其中會包含上述提款交易。

  4. Rollup Block度過了挑戰期併被確認後,⽤戶可以在L1上調用Outbox.execute Transaction()函數,證明參數由前麵提到的ArbSys合約給出。

  5. Outbox 合約確認⽆誤後,解鎖bridge中相應數額的ETH髮送給⽤戶。

快速提現

使⽤樂觀Rollup官方橋提現就會出現等待挑戰期的問題。我們可以⽤私營的第三方跨鏈橋來規避這個問題:

  • 原⼦鎖交換。這種⽅式隻是在雙⽅在各⾃的鏈內進⾏了資産的互換,併且具有原⼦性,隻要⼀⽅提供了Preimage,雙⽅⼀定可以得到應有的資産。但問題是流動性⽐較稀缺,需要點對點地尋找對⼿⽅。
  • ⻅證⼈跨鏈橋。⼀般類型的跨鏈橋都屬於⻅證⼈橋。⽤戶提交⾃⼰的提現請求,提現⽬的地指曏第三方橋的運營者或流動性池。⻅證⼈髮現跨鏈交易已提交到L1的快箱合約後,就可以直接在L1端曏⽤戶轉賬。這種⽅式本質上是⽤另⼀套共識繫統來監視Layer2,併根據其已提交至Layer1上的數據進⾏操作。問題是,這種模式下的安全繫數不如Rollup官方橋⾼。

強製提現

force Inclusion()強製歸集功能用於對抗定序器的審查,任何L2本地交易、L1到L2交易和L2到L1交易,都可以使用該功能實現。定序器的惡意審查嚴重影響了交易體驗,大部分情況下我們會選擇提現離開L2,因此下麵以強製提現爲例介紹forceInclusion的用法。

回顧在ETH提現步驟中,隻有步驟1、2是涉及到定序器審查的,所以隻需要更改這兩步:

  • 調用L1上慢箱合約中的inbox.sendL2Message(),輸入參數就是在L2上調用withdrawEth()時需要輸入的參數。該消息會共享給L1上的bridge合約。
  • 等待24小時的強製歸集等待期後,調用快箱中的force Inclusion()進行強製歸集,快箱合約會檢視bridge中是否有對應消息。

最終用戶可以在Outbox中提現,其餘步驟由衕正常的提現相衕。

另外,arbitrum-tutorials中也有使用Arb SDK的詳細教程去指導用戶如何通過forceInclusion()去進行L2本地交易和L2到L1交易。

聲明:

  1. 本文轉載自[極客 Web3],著作權歸屬原作者[羅奔奔,前Arbitrum技術大使,極客web3貢獻者],如對轉載有異議,請聯繫Gate Learn團隊,團隊會根據相關流程盡速處理。
  2. 免責聲明:本文所錶達的觀點和意見僅代錶作者個人觀點,不構成任何投資建議。
  3. 文章其他語言版本由Gate Learn團隊翻譯, 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。
即刻開始交易
註冊並交易即可獲得
$100
和價值
$5500
理財體驗金獎勵!
立即註冊