前仲裁技術大使解釋仲裁的組成部分結構（第二部分）

作者：Benben Luo，前Arbitrum技術大使，極客web3貢獻者

在上一篇文章“前仲裁技術大使解釋仲裁的元件結構（第一部分）”中，我們介紹了排序器、驗證器、SequencerInbox 合約、匯總區塊和非互動式欺詐證明在 Arbitrum 核心元件中的作用，在今天的文章中，我們將重點介紹 Arbitrum 核心元件中與跨鏈交互消息傳遞和抗審查交易入口相關的元件。

正文：在上一篇文章中，我們提到 Sequencer 收件匣合約專門接收排序器在第 1 層上發佈的一批事務數據包。 同時，我們指出，Sequencer Inbox也被稱為Fast Box，而不是Slow Box Delay Inbox（簡稱Inbox）。 **下面，我們將仔細研究與跨鏈交互消息相關的元件，例如延遲收件匣。

跨鏈交互和橋接原理

跨鏈交互交易可分為L1至L2（存款）和L2至L1（提現）。 需要注意的是，這裡提到的存取款不一定與資產跨鏈交互有關，可以是不直接附加資產的消息。 所以這兩個詞只表示跨鏈交互相關行為的兩個方向。

跨鏈交互交易比純L2交易更複雜，跨鏈交互交易在兩個不同的系統中交換資訊，L1和L2。

另外，我們通常所說的跨鏈交互行為，就是在見證模式下具有跨鏈交互橋的兩個不相關的網路上的跨鏈交互，這種跨鏈交互的安全性取決於跨鏈交互橋的運營商，基於見證模型的跨鏈交互橋的盜竊在歷史上屢見不鮮。

Rollup 和 ETHMainnet 之間的跨鏈交互行為與上述跨鏈交互有著根本的不同，因為第 2 層的狀態是由第 1 層記錄的數據決定的，只要使用官方的 Rollup 跨鏈交互橋，在操作結構上是絕對安全的。 **

這也凸顯了 Rollup 的本質，它只是從使用者的角度出發，就像一個獨立的鏈，但實際上，所謂的**“Layer2”只是 Rollup 向使用者開放的一個快速展示視窗，其真正的鏈結構仍然燒在第 1 層上。 因此，我們可以將 L2 視為半條鏈，或“在第 1 層創建的鏈”。

可重試票證 可重試

需要注意的是，跨鏈交互是異步和非原子的，不可能像在鏈上那樣在完成交易確認后知道結果，也不能保證在某個時間點另一端會發生一些事情。 因此，跨鏈交互可能會因為一些軟問題而失敗，但只要使用正確的手段，例如可重試票證，就不會發生資金卡住等硬問題。

**可重試的門票是通過官方仲裁橋存款時使用的基本工具，**ETH 和 ERC20 存款是使用的。 其生命周期分為三個步驟：

**1. 在 L1 提交工單。 **使用“延遲收件匣”合同中的 createRetryableTicket（） 方法創建存款單並提交。

**2. 在L2上自動兌換。 **在大多數情況下，排序器可以自動為用戶兌換帳單，而無需後續手動操作。

**3. L2. **在某些邊際情況下，例如L2的汽油價格突然飆升，票據上預付的汽油不足，它不會自動贖回。 在這種情況下，需要由使用者手動完成。

請注意，如果自動贖回失敗，您需要在 7 天內手動贖回票據，否則帳單將被刪除（資金將永久丟失），或者您需要支付費用續訂租約以保存票據。

此外，雖然 Arbitrum 官方橋的提現過程與入金行為有一定的對稱相似性，但並不存在可重試的概念，一方面可以從 Rollup 協定本身來理解，另一方面也有一些差異：

提現過程中沒有自動贖回，因為EVM中沒有計時器或者自動化，在L2上可以實現自動贖回，這是在排序器的説明下實現的，所以L1上的使用者需要手動與寄件匣合約交互，才能用Claim檢索資產。 提款不存在逾期帳單的問題，只要過了質疑期，就可以隨時申領。

ERC-20資產跨鏈交互網關

• ERC-20資產的跨鏈交互很複雜。 有幾個問題我們可以思考：
• 令牌部署在 L1 上，如何在 L2 上部署？
• 其L2對應方是否需要提前手動部署，或者系統可以自動部署交叉但尚未部署合約的代幣資產合約？
• L1 上 ERC-20 資產與 L2 對應的合約地址是什麼？ 它應該與L1一致嗎？
• 對於在L2上原生發行的代幣，如何跨鏈交互到L1？
• 具有特殊功能的代幣，如數量可調的變基代幣、自增長計息代幣、如何跨鏈互動？

我們不會回答所有這些問題，因為它太複雜了，無法擴展。 這些問題僅用於說明ERC20跨鏈交互的複雜性。

目前，許多擴展解決方案使用允許清單+手動清單解決方案來避免各種複雜的問題和邊界情況。

Arbitrum使用閘道系統解決了ERC20跨鏈交互的大部分痛點，具有以下特點：

• 閘道元件成對顯示在 L1 和 L2 處。 網關路由器負責維護令牌 L1<->令牌 L2 之間的位址映射，以及某些令牌<->某些閘道之間的位址映射。
• 閘道可分為標準ERC20閘道、通用定製閘道、自訂閘道等，解決不同類型和功能的ERC20橋接問題。

讓我們以相對簡單的WETH跨鏈交互為例，說明自定義閘道的必要性。

WETH 相當於 ERC20 ETH。 由於乙太幣是主要硬幣，dApp 中的許多複雜功能是不可能的，因此需要 ERC20 等價物。 將一些ETH轉移到 WETH 合約中，它們將被鎖定在合約中，並將生成相同數量的 WETH。

同樣，也可以燒掉 WETH 並取出ETH。 **顯然，流通中的WETH數量和ETH鎖定頭寸的數量將始終為1：1。 **

如果我們現在將跨鏈交互 WETH 直接放在 L2 上，我們會發現一些奇怪的問題：

• 無法在 L2 上將 WETH 解包到ETH中，因為在 L2 上沒有與ETH相對應的鎖定位置。
• 可以使用 Wrap 函數，但這些新生成的 WETH 如果穿越回 L1，則無法作為 L1 上的ETH解封，因為 L1 和 L2 上的 WETH 合約不是“對稱的”。

顯然，這違反了WETH的設計原則。 **那麼當WETH是跨鏈交互時，無論是充值還是取款，都需要先解包成ETH，然後再交叉到對面，再包裝成WETH。 這就是 WETH 閘道的用武之地。

其他具有更複雜邏輯的令牌也會做同樣的事情，需要更複雜和設計良好的閘道才能在跨鏈交互環境中正常工作。 Arbitrum的自定義閘道繼承了普通閘道的跨鏈交互邏輯，並允許開發人員自定義與令牌邏輯相關的跨鏈交互行為，可以滿足大多數需求。

延遲收件匣

SequencerInbox 的對應項是延遲收件匣（Delay Inbox）。 由於快速盒專用於接收排序器發佈的一批 L2 事務，因此 L2 網路中所有未被排序器預處理的交易都不應出現在快盒合約中。

**慢箱的第一個功能是處理從 L1 到 L2 的充值行為。 **用戶通過慢箱進行存款，排序器監聽，然後反映在L2上，最後存款記錄將被排序器包含在L2交易序列中，並提交到排序器收件匣。

在此示例中，使用者不宜將存款交易直接提交到 Sequencer 收件匣，因為提交到 Sequencer 收件匣的交易會干擾第 2 層的正常交易排序，進而影響 Sequencer 的工作。

慢箱的第二個功能是抵制審查。 **使用者直接提交給Slowbox合約的交易將在10分鐘內由排序器收集。 但是，如果音序器惡意忽略您的請求，則慢箱還具有強制包含功能：

如果交易提交到延遲收件匣，24小時后，慢箱中的交易尚未被排序器包含在交易序列中，使用者可以在第 1 層手動觸發強制包含功能，排序器忽略的交易請求被強制分組到 Fastbox 排序器收件匣中，然後它們將被所有 Arbitrum One 節點監控，並被強制包含在第 2 層交易序列中。

如前所述，快框中的數據是 L2 的歷史數據實體。 因此，在惡意審查的情況下，** 最終可以通過慢箱將交易指令包含在 L2 帳本中，涵蓋強制提現逃離第 2 層等場景。 **

由此可見，對於任何方向和級別的交易，排序器最終都無法永久審查您。

慢箱收件匣的幾個核心功能：

• 存款ETH（），最簡單的存款ETH函數。 創建RetryableTicket（），可用於存入ETH和ERC20以及消息。 與depositETH（）相比，它具有更高的靈活性，例如能夠在存款后指定L2的接收位址。
• forceInclusion（），這是強制聚合函數，任何人都可以調用。 此函數驗證提交到 Slowbox 合約的交易在 24 小時後是否未被處理。 如果滿足條件，消息將被強制聚合。

但是需要注意的是，力包含函數其實位於慢箱合約中，只是為了方便理解，我們將放在這裡的慢箱中，一起解釋一下。

寄件匣

寄件匣僅與提現相關，可以理解為提現行為的記錄和管理系統：**

• 我們知道，從 Arbitrum 官方橋牌提款需要等待大約 7 天的挑戰期結束，才能在匯總區塊最終確定後實施提款。 在質疑期結束時，使用者向第 1 層的寄件匣合約提交相應的 Merkle 證明，該合約與其他功能合約（如解鎖鎖定在其他合約中的資產）進行通信，最終完成提現。
• 寄件匣合約將記錄哪些 L2 到 L1 跨鏈交互消息已被處理，以防止有人重複提交已執行的提款請求。 它使用映射（uint256 => bytes32）公共spen來記錄提款請求的花費索引和資訊之間的對應關係（如果映射）[spentIndex] ！= 位元組32（0），請求已被撤回。 其原理類似於防止重放攻擊的事務計數器隨機數。

下面我們將以ETH為例，全面解釋存款和取款過程。 ERC20 和 ERC20 的區別在於它只是通過閘道，所以我不會重複它。

ETH存款

1. 使用者調用慢箱的存款 ETH（） 函數。

2. 函數會繼續調用 bridge.enqueueDelayedMessage（），將消息記錄在橋接合約中，並將ETH發送到橋接合約。 **所有ETH存款資金都保存在過橋合同中，相當於一個存款位址。 **

3.排序器監聽慢框內的存款消息，並將存款操作反映到L2資料庫中，以便使用者可以看到他們在L2網路中存放的資產。

4. 排序器會將存款記錄包含在批次中，並將其提交給 L1 的快遞合同。

ETH提款

1. 使用者在 L2 上調用 ArbSys 合約的 withdrawEth（） 函數，在 L2 上燒掉相應數量的ETH。

2. 排序器將提款請求發送到快速箱。

**3.驗證人節點根據快速框中的交易順序創建一個新的匯總區塊，其中包含上述提現交易。 **

4. 在匯總塊通過質詢期並確認后，用戶可以調用 L1 上的 Outbox.ute Transaction（） 函數來證明參數是由上述 ArbSys 合約給出的。

5. 寄件匣合同確認正確后，將解鎖網橋中相應的ETH量發送給使用者。

快速提現

使用樂觀匯總官方網橋提款將導致挑戰期的等待期。 我們可以通過私有第三方跨鏈交互橋來規避這個問題：

*原子鎖交換。 這種方法只允許雙方在各自的鏈內交換資產，而且是原子的，只要一方提供原像，雙方就一定會得到自己應得的資產。 但問題是流動性相對稀缺，需要點對點尋找交易對手。

• 見證跨鏈交互橋。 **跨鏈交互橋的一般類型是見證橋。 使用者向第三方橋接或流動性池的運營商提交自己的提款請求。 見證人發現跨鏈交互已經提交L1快盒合約后，可以直接將錢轉給L1端的使用者。 這種方法本質上是使用另一個共識系統來監控第 2 層，並對其已提交到第 1 層的數據進行操作。 **問題是這種模式下的安全係數沒有官方的Rollup橋那麼高。 **

強制提現

force Inclusion（） 用於對抗排序器審查，可用於任何 L2 本地、L1 到 L2 和 L2 到 L1 事務。 序列器的惡意審查嚴重影響了交易體驗，大多數情況下我們會選擇退出退出 L2，所以下面就是一個強制退出引入使用 forceInclusion 的例子。

回想一下，在ETH退出步驟中，只有步驟 1 和 2 涉及排序器審查，因此只需要更改這兩個步驟：

• 在 L1 上的慢箱合約中調用 inbox.sendL2Message（），輸入參數是在 L2 上調用 withdrawEth（） 時需要輸入的參數。 該消息與 L1 上的橋接合約共用。
• 等待 24 小時強制聚合等待期后，調用快盒中的強制 Inclusion（） 強制收集，快盒合約會檢查橋中是否有對應的消息。

最終使用者可以在寄件匣中提款，其餘步驟與正常提款相同。

此外，仲裁教程還有關於如何使用 Arb SDK 的詳細教程，指導使用者如何使用 forceInclusion（） 進行 L2 本地事務和 L2 到 L1 事務。