原文標(biāo)題：《前 Arbitrum 技術(shù)大使解讀 Arbitrum 的組件結(jié)構(gòu)（下）》

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

導(dǎo)語(yǔ)：

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

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

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

跨鏈與橋接的原理

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

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

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

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

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

可重試票據(jù) Retryables

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

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

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

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

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

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

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

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

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

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

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

·一個(gè)在 L1 上部署的代幣，它在 L2 上要如何部署？

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

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

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

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

我們不打算全部回答這些問(wèn)題，因?yàn)檎归_(kāi)太過(guò)復(fù)雜。這些問(wèn)題僅是用來(lái)說(shuō)明 ERC20 跨鏈的復(fù)雜性。

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

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

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

·Gateway Router 負(fù)責(zé)維護(hù) Token L1<->Token L2 之間的地址映射，以及 some token<->some gateway 之間的映射。

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

我們以比較簡(jiǎn)單的 WETH 跨鏈為例，來(lái)說(shuō)明自定義 gateway 的必要性。

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

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

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

·無(wú)法在 L2 上把 WETH 進(jìn)行 Unwrap 變成 ETH，因?yàn)?L2 上并沒(méi)有鎖倉(cāng)對(duì)應(yīng)的 ETH。

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

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

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

慢收件箱 Delayed Inbox

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

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

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

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

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

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

由此可以看出，對(duì)任何?個(gè)方向和層次的交易，排序器最終都無(wú)法永久審查你。?

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

·depositETH()，最簡(jiǎn)單的充值 ETH 的函數(shù)。

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

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

不過(guò)需要注意，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 合約會(huì)記錄哪些 L2 到 L1 的跨鏈消息已經(jīng)被處理過(guò)，以防止有人反復(fù)提交執(zhí)行過(guò)的提現(xiàn)請(qǐng)求。它通過(guò)mapping(uint256 => bytes32) public spent，記錄提現(xiàn)請(qǐng)求的 spent Index 與信息對(duì)應(yīng)關(guān)系，如果 mapping[spentIndex] != bytes32(0) 則該請(qǐng)求已被提現(xiàn)過(guò)。原理類似于防止重放攻擊的交易計(jì)數(shù)器 Nonce。

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

ETH 充值

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

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

3. 排序器監(jiān)聽(tīng)到慢箱中的充值消息，將充值操作反映?L2 數(shù)據(jù)庫(kù)中，?戶可以在 L2 網(wǎng)絡(luò)看到自己充進(jìn)來(lái)的資產(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)請(qǐng)求發(fā)送至快箱。

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

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

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

快速提現(xiàn)

使用樂(lè)觀 Rollup 官方橋提現(xiàn)就會(huì)出現(xiàn)等待挑戰(zhàn)期的問(wèn)題。我們可以用私營(yíng)的第三方跨鏈橋來(lái)規(guī)避這個(gè)問(wèn)題：?

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

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

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

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

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

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

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

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

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

原文鏈接