作者：羅奔奔，前Arbitrum技術(shù)大使，極客web3貢獻(xiàn)者

導(dǎo)語：本文是Arbitrum前技術(shù)大使 及 智能合約自動化審計(jì)公司Goplus Security前聯(lián)合創(chuàng)始人羅奔奔 對Arbitrum One的技術(shù)解讀。

在上一篇文章《前Arbitrum技術(shù)大使解讀Arbitrum的組件結(jié)構(gòu)（上）》，我們介紹了Arbitrum核心組件中的 排序器、Validator、SequencerInbox合約、Rollup Block、非交互式欺詐證明的作用，而在今天的文章中，我們將重點(diǎn)講解Arbitrum核心組件中與跨鏈消息傳遞及抗審查交易入口相關(guān)的組件。

正文：此前的文章中，我們曾提到，Sequencer Inbox合約專門在Layer1上接收排序器發(fā)布的交易數(shù)據(jù)包Batch。同時，我們指出，Sequencer Inbox又被稱作快箱，與之相對的是慢箱Delayed Inbox（簡稱Inbox）。下面，我們將對Delayed Inbox等與跨鏈消息傳遞相關(guān)的組件進(jìn)行細(xì)致解讀。

跨鏈與橋接的原理

跨鏈交易可分為L1到L2（充值）與L2到L1（提現(xiàn)）。注意這?所說的充值和提現(xiàn)未必與資產(chǎn)跨鏈相關(guān)，可以是不直接附帶資產(chǎn)的消息傳遞。所以這兩個詞僅僅表示跨鏈相關(guān)行為的兩個?向。

跨鏈交易與純L2交易相?，跨鏈交易在L1和L2這兩個不同的系統(tǒng)中進(jìn)?了信息互換，因此過程更復(fù)雜。

另外，通常我們說的跨鏈?為，是在兩個毫不相關(guān)的?絡(luò)上，??證?模式的跨鏈橋進(jìn)?的跨鏈，這種跨鏈的安全性取決于跨鏈橋的運(yùn)營者，歷史上基于見證人模式的跨鏈橋被盜事件頻繁發(fā)生。

?在Rollup與ETH主?之間的跨鏈?為，與上述跨鏈有本質(zhì)不同，因?yàn)長ayer2的狀態(tài)是由記錄在Layer1上的數(shù)據(jù)決定的，只要你使?的是Rollup官?的跨鏈橋，其在運(yùn)作結(jié)構(gòu)上是絕對安全的。

這也凸顯出Rollup的本質(zhì)，它只是在?戶角度看，像?條獨(dú)立的鏈，但實(shí)際上所謂的“Layer2”只是Rollup對?戶敞開的快速展示窗?，它的真實(shí)鏈?zhǔn)浇Y(jié)構(gòu)還是刻錄在Layer1上。所以，我們可以認(rèn)為L2算半條鏈，或者說是“在Layer1上創(chuàng)造出的一條鏈”。

可重試票據(jù) Retryables

需要注意，跨鏈都是異步和非原子性的，它不可能像在一條鏈上一樣做完一筆交易確認(rèn)后就知道結(jié)果，也不能保證另一側(cè)一定會在某個時間點(diǎn)發(fā)生某些事。因此跨鏈有可能因?yàn)橐恍┸浶詥栴}而失敗，但只要使用正確的手段，諸如可重試票據(jù)（Retryable Ticket），就不會發(fā)生資金卡住等硬性問題。

可重試票據(jù)是通過Arbitrum官方橋充值時，用到的基本工具，ETH和ERC20的充值都會使?到。其?命周期分為三步：

1. 在L1上提交票據(jù)。在Delayed Inbox合約中使用createRetryableTicket()方法創(chuàng)建充值票據(jù)，并提交。

2. L2上自動兌付。大部分情況下，排序器可以自動幫用戶兌付票據(jù)，無需后續(xù)的手動操作。

3. L2上手動兌付。部分邊緣情況，如L2上gas價格突然激增，票據(jù)上預(yù)付的gas不夠，則無法自動兌付。此時需要用戶手動操作。

注意，如果自動兌付失敗，需要在7日內(nèi)手動兌付票據(jù)，否則要么票據(jù)將會被刪除（資金會永久損失），要么需要為票據(jù)的保存支付一定費(fèi)用來續(xù)租。

另外，對于Arbitrum官方橋的提現(xiàn)流程，雖然和充值行為在流程上有一定對稱相似性，但并沒有Retryables這個概念，一方面可以從Rollup協(xié)議本身理解，另一方面我們可以從一些區(qū)別進(jìn)行理解：

• 提現(xiàn)的過程中不存在自動兌付，因?yàn)镋VM沒有定時器或自動化，而L2上可以實(shí)現(xiàn)自動兌付，是排序器幫忙實(shí)現(xiàn)的，所以L1上用戶要手動與Outbox合約交互，以Claim取回資產(chǎn)。

• 提現(xiàn)也不存在票據(jù)過期的問題，只要過了挑戰(zhàn)期，可以在任意時間領(lǐng)取。

ERC-20資產(chǎn)跨鏈 Gateway

ERC-20資產(chǎn)的跨鏈?zhǔn)菑?fù)雜的。我們可以思考幾個問題：

• 一個在L1上部署的代幣，它在L2上要如何部署？

• 它的L2對應(yīng)合約需要預(yù)先手動部署，還是系統(tǒng)可以自動為跨過來的、但尚未部署合約的代幣 自動部署資產(chǎn)合約？

• L1上的ERC-20資產(chǎn)，在L2對應(yīng)的合約地址是什么？是否該和L1一致？

• 在L2上原生發(fā)行的代幣，如何跨鏈至L1？

• 擁有特殊功能的代幣，如可調(diào)整數(shù)量的Rebase型代幣，自增長生息代幣，如何跨鏈？

我們不打算全部回答這些問題，因?yàn)檎归_太過復(fù)雜。這些問題僅是用來說明ERC20跨鏈的復(fù)雜性。

目前非常多擴(kuò)容方案使用的都是白名單+手動清單的方案，來規(guī)避各種復(fù)雜的問題和邊界情況。

Arbitrum使用了Gateway系統(tǒng)，解決了大部分ERC20跨鏈的痛點(diǎn)，具有以下特性：

• Gateway組件在L1和L2成對出現(xiàn)。

• Gateway Router負(fù)責(zé)維護(hù)Token L1Token L2之間的地址映射，以及some tokensome gateway之間的映射。

• Gateway本身可分為StandardERC20 gateway，Generic-custom gateway，Custom gateway等等，用以解決不同類型的和功能ERC20的橋接問題。

我們以比較簡單的WETH跨鏈為例，來說明自定義gateway的必要性。

WETH是一種ETH的ERC20等價物。Ether作為主幣，很多dApp中的復(fù)雜功能是無法實(shí)現(xiàn)的，因此需要一個ERC20的等價物。向WETH合約內(nèi)轉(zhuǎn)入一些ETH，它們會被鎖在合約內(nèi)，并生成出相同數(shù)量的WETH。

同理，也可以銷毀WETH，取出ETH。顯然，流通的WETH和鎖倉的ETH數(shù)量永遠(yuǎn)是1：1的。

如果現(xiàn)在把WETH直接跨鏈到L2上，我們會發(fā)現(xiàn)一些奇怪的問題：

• 無法在L2上把WETH進(jìn)行Unwrap變成ETH，因?yàn)長2上并沒有鎖倉對應(yīng)的ETH。

• Wrap功能可以使用，但這些新生成的WETH如果跨回到L1，也無法在L1上解封裝為ETH，因?yàn)?strong>L1和L2上的WETH合約不是“對稱的”。

顯然這違反了WETH的設(shè)計(jì)原理。那么WETH在跨鏈時，不論是充值還是提現(xiàn)，都需要先Unwrap成ETH后，再跨到對面，然后Wrap成WETH。這個也就是WETH Gateway的作用。

其他有更復(fù)雜邏輯的代幣同理，需要更復(fù)雜和精心設(shè)計(jì)的Gateway才能正常在跨鏈環(huán)境下工作。Arbitrum的自定義Gateway繼承了普通Gateway的跨鏈通信邏輯，并允許開發(fā)者自定義與代幣邏輯相關(guān)的跨鏈行為，可滿足大部分需求。

慢收件箱Delayed Inbox

與快箱也即 SequencerInbox相對應(yīng)的是慢箱 Inbox （全稱Delayed Inbox）。為什么要有快慢之分呢？因?yàn)榭煜涫菍?接收排序器發(fā)布的L2交易Batch的，所有未經(jīng)排序器在L2網(wǎng)絡(luò)內(nèi)預(yù)處理的交易，都不該出現(xiàn)在快箱合約中。

慢箱的第?點(diǎn)作?是，處理L1到L2的充值?為。?戶通過慢箱進(jìn)?充值，排序器監(jiān)聽到后再反映在L2上，最終這筆充值記錄會被排序器包含進(jìn)L2的交易序列中，并提交?快箱合約Sequencer Inbox。

在這個例?中，?戶直接向快箱提交充值交易是不合適的，因?yàn)樘峤坏娇煜銼equencer Inbox中的交易，會干擾到Layer2正常的交易排序，然后會影響到排序器的工作。

慢箱的第?個作?，是抗審查。用戶直接提交?慢箱合約中的交易，排序器?般會在10分鐘內(nèi)歸集到快箱中。但如果排序器惡意忽略你的請求，慢箱還有?個強(qiáng)制歸集force inclusion功能：

如果交易被提交至Delayed Inbox中，經(jīng)過24小時，慢箱中的交易仍未被排序器包含至交易序列中，用戶可以在Layer1上手動觸發(fā)force inclusion函數(shù)，把被排序器忽略掉的交易請求，強(qiáng)制歸集到快箱Sequencer Inbox中，之后就會被全體Arbitrum One節(jié)點(diǎn)監(jiān)聽到，會被強(qiáng)制包含進(jìn)Layer2交易序列里。

我們剛才提到過，快箱?的數(shù)據(jù)就是L2的歷史數(shù)據(jù)實(shí)體。所以在被惡意審查的情況下，通過慢箱可以讓交易指令最終包含進(jìn)L2賬本中，這涵蓋了強(qiáng)制提款等逃離Layer2的場景。

由此可以看出，對任何?個?向和層次的交易，排序器最終都?法永久審查你。

慢箱Inbox的幾個核心函數(shù)：

• depositETH()，最簡單的充值ETH的函數(shù)。

• createRetryableTicket()，可用于ETH和ERC20以及消息的充值。相較depositETH()而言，有更高的靈活性，例如可指定充值后L2的收款地址等。

• forceInclusion()，也即強(qiáng)制歸集功能，任何?都可以調(diào)?。該函數(shù)會校驗(yàn)，提交至慢箱合約中的某筆交易，是否過了24小時還沒被處理。如果條件滿?，則將對消息進(jìn)?強(qiáng)制歸集。

不過需要注意，force Inclusion函數(shù)實(shí)際上位于快箱合約中，只是為了?便理解，我們將其放在慢箱這??起講解。

出站箱Outbox

出站箱Outbox只與提現(xiàn)有關(guān)，可以理解為提現(xiàn)行為的記錄和管理系統(tǒng)：

• 我們知道，Arbitrum官方橋的提現(xiàn)需要等待約7天的挑戰(zhàn)期結(jié)束， Rollup Block 最終敲定后，提款行為才可以實(shí)施。?戶在挑戰(zhàn)期結(jié)束后，向Layer1上的Outbox合約提交相應(yīng)的Merkle Proof，它再與其他職能的合約通信（如解鎖其他合約中鎖定的資產(chǎn)），最終完成提現(xiàn)。

• OutBox合約會記錄哪些L2到L1的跨鏈消息已經(jīng)被處理過，以防止有人反復(fù)提交執(zhí)行過的提現(xiàn)請求。它通過

  mapping(uint256 => bytes32) public spent，記錄提現(xiàn)請求的spent Index與信息對應(yīng)關(guān)系，如果mapping[spentIndex] != bytes32(0)則該請求已被提現(xiàn)過。原理類似于防止重放攻擊的交易計(jì)數(shù)器Nonce。

下?我們將以ETH為例完整講解充值與提現(xiàn)的流程。ERC20與之不同的僅僅是?了Gateway，就不再贅述。

ETH充值

1. 用戶調(diào)用慢箱的depositETH()函數(shù)。

2. 該函數(shù)會繼續(xù)調(diào)用bridge.enqueueDelayedMessage()，在bridge合約中記錄該消息，并將ETH發(fā)送往bridge合約。所有的ETH充值資金，都保管在bridge合約中，相當(dāng)于一個充值地址。

3. 排序器監(jiān)聽到慢箱中的充值消息，將充值操作反映?L2數(shù)據(jù)庫中，?戶可以在L2網(wǎng)絡(luò)看到自己充進(jìn)來的資產(chǎn)。

4. 排序器將該筆充值記錄包含進(jìn)交易批次batch，提交給L1上的快箱合約。

ETH提現(xiàn)

1. ?戶在L2上調(diào)? ArbSys合約的withdrawEth()函數(shù) ，在L2上銷毀相應(yīng)數(shù)量的ETH。

2. 排序器將該提現(xiàn)請求發(fā)送?快箱。

3.Validator節(jié)點(diǎn)根據(jù)快箱中的交易序列，創(chuàng)建新的Rollup Block，其中會包含上述提款交易。

4. Rollup Block度過了挑戰(zhàn)期并被確認(rèn)后，?戶可以在L1上調(diào)用Outbox.execute Transaction()函數(shù)，證明參數(shù)由前面提到的ArbSys合約給出。

5. Outbox 合約確認(rèn)?誤后，解鎖bridge中相應(yīng)數(shù)額的ETH發(fā)送給?戶。

快速提現(xiàn)

使?樂觀Rollup官方橋提現(xiàn)就會出現(xiàn)等待挑戰(zhàn)期的問題。我們可以?私營的第三方跨鏈橋來規(guī)避這個問題：

• 原?鎖交換。這種?式只是在雙?在各?的鏈內(nèi)進(jìn)?了資產(chǎn)的互換，并且具有原?性，只要??提供了Preimage，雙??定可以得到應(yīng)有的資產(chǎn)。但問題是流動性?較稀缺，需要點(diǎn)對點(diǎn)地尋找對??。

• ?證?跨鏈橋。?般類型的跨鏈橋都屬于?證?橋。?戶提交??的提現(xiàn)請求，提現(xiàn)?的地指向第三方橋的運(yùn)營者或流動性池。?證?發(fā)現(xiàn)跨鏈交易已提交到L1的快箱合約后，就可以直接在L1端向?戶轉(zhuǎn)賬。這種?式本質(zhì)上是?另?套共識系統(tǒng)來監(jiān)視Layer2，并根據(jù)其已提交至Layer1上的數(shù)據(jù)進(jìn)?操作。問題是，這種模式下的安全系數(shù)不如Rollup官方橋?。

強(qiáng)制提現(xiàn)

force Inclusion()強(qiáng)制歸集功能用于對抗定序器的審查，任何L2本地交易、L1到L2交易和L2到L1交易，都可以使用該功能實(shí)現(xiàn)。定序器的惡意審查嚴(yán)重影響了交易體驗(yàn)，大部分情況下我們會選擇提現(xiàn)離開L2，因此下面以強(qiáng)制提現(xiàn)為例介紹forceInclusion的用法。

回顧在ETH提現(xiàn)步驟中，只有步驟1、2是涉及到定序器審查的，所以只需要更改這兩步：

• 調(diào)用L1上慢箱合約中的inbox.sendL2Message()，輸入?yún)?shù)就是在L2上調(diào)用withdrawEth()時需要輸入的參數(shù)。該消息會共享給L1上的bridge合約。

• 等待24小時的強(qiáng)制歸集等待期后，調(diào)用快箱中的force Inclusion()進(jìn)行強(qiáng)制歸集，快箱合約會檢視bridge中是否有對應(yīng)消息。

最終用戶可以在Outbox中提現(xiàn)，其余步驟由同正常的提現(xiàn)相同。

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