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

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

導(dǎo)語：

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

在上一篇文章《Arbitrum 的組件結(jié)構(gòu)解讀（上）》，我們介紹了 Arbitrum 核心組件中的 排序器、Validator、Sequencer?Inbox 合約、Rollup Block、非交互式欺詐證明的作用，而在今天的文章中，我們將重點講解 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)的網(wǎng)絡(luò)上，用見證人模式的跨鏈橋進(jìn)行的跨鏈，這種跨鏈的安全性取決于跨鏈橋的運營者，歷史上基于見證人模式的跨鏈橋被盜事件頻繁發(fā)生。

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

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

可重試票據(jù) Retryables

需要注意，跨鏈都是異步和非原子性的，它不可能像在一條鏈上一樣做完一筆交易確認(rèn)后就知道結(jié)果，也不能保證另一側(cè)一定會在某個時間點發(fā)生某些事。因此跨鏈有可能因為一些軟性問題而失敗，但只要使用正確的手段，諸如可重試票據(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ù)的保存支付一定費用來續(xù)租。

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

·提現(xiàn)的過程中不存在自動兌付，因為 EVM 沒有定時器或自動化，而 L2 上可以實現(xiàn)自動兌付，是排序器幫忙實現(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 型代幣，自增長生息代幣，如何跨鏈？

我們不打算全部回答這些問題，因為展開太過復(fù)雜。這些問題僅是用來說明 ERC20 跨鏈的復(fù)雜性。

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

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

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

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

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

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

WETH 是一種 ETH 的 ERC20 等價物。Ether 作為主幣，很多 dApp 中的復(fù)雜功能是無法實現(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，因為 L2 上并沒有鎖倉對應(yīng)的 ETH。

·Wrap 功能可以使用，但這些新生成的 WETH 如果跨回到 L1，也無法在 L1 上解封裝為 ETH，因為L1 和 L2 上的 WETH 合約不是「對稱的」。

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

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

慢收件箱 Delayed Inbox

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

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

在這個例子中，用戶直接向快箱提交充值交易是不合適的，因為提交到快箱 Sequencer Inbox 中的交易，會干擾到 Layer2 正常的交易排序，然后會影響到排序器的工作。

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

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

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

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

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

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

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

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

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

出站箱 Outbox

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

·我們知道，Arbitrum 官方橋的提現(xiàn)需要等待約 7 天的挑戰(zhàn)期結(jié)束，Rollup Block 最終敲定后，提款行為才可以實施。?戶在挑戰(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)過。原理類似于防止重放攻擊的交易計數(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é)點根據(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)。但問題是流動性比較稀缺，需要點對點地尋找對手方。

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

強制提現(xiàn)

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

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

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

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

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

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

原文鏈接