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

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

**本文由Arbitrum前技術大使、智慧合約自動化審計公司Goplus Security前聯合創始人Benben Luo對Arbitrum One的技術解讀。 **

由於華人圈中涉及Layer 2的文章或資料缺乏對仲裁甚至OP匯總的專業解讀，本文試圖通過普及仲裁的運行機制來填補該領域的空白。 由於Arbitrum本身結構的複雜性，全文在盡可能簡化的基礎上還是在10000字以上，所以分為兩篇文章，建議收集轉發作為參考資料！

匯總排序器的簡要說明

匯總縮放的原理可以概括為兩點：

成本優化：將大部分計算和存儲任務卸載到 L1 鏈下，即 L2。 **L2 主要是在單個伺服器上運行的鏈，即排序器/運算符。

音序器看起來接近中心化伺服器，放棄了“區塊鏈不可能三次”中的“去中心化”，以換取TPS和成本優勢。 用戶可以讓L2處理交易指令而不是乙太坊，成本比在乙太坊上交易低得多。

**安全性：L2上的交易內容和交易后的狀態將同步到乙太坊L1，狀態轉換的有效性將通過合約進行驗證。 同時，L2 歷史記錄將保留在乙太坊上，即使排序器永久關閉，其他人也可以通過乙太坊上的記錄恢復整個 L2 狀態。

從根本上說，Rollups的安全性基於乙太坊。 如果排序器不知道帳戶的私鑰，則無法以該帳戶的名義發起交易，或篡改該帳戶中的資產餘額（即使知道，也會很快被識別）。

雖然定序器是中心化的系統骨幹，但在相對成熟的 Rollup 方案中，集中式定序器只能實現交易審查、惡意停機等軟惡行為，但在理想的 Rollup 方案中，有相應的手段來遏制它（如強制提現或訂單證明等抗審查機制）。

防止匯總序列器邪惡的狀態驗證方法分為兩種類型：欺詐證明和有效性證明。 使用欺詐證明的匯總稱為OP匯總（樂觀匯總，OPR），並且由於某些歷史包袱，使用有效性證明的匯總通常稱為 ZK 匯總（零知識證明匯總，ZKR）而不是有效性匯總。

Arbitrum One 是一個典型的 OPR，它在 L1 上部署合約，不主動驗證提交的數據，樂觀地認為數據沒有問題。 如果提交的數據有誤，L2的驗證人節點發起質詢。

因此，OPR 還暗示了一個信任假設：在任何給定時間至少有一個誠實的 L2 驗證者節點。 另一方面，ZKR的合同使用密碼學來主動但經濟高效地驗證測序器提交的數據。

在本文中，我們將深入介紹樂觀匯總中的領先專案 Arbitrum One，涵蓋整個系統的各個方面，仔細閱讀後，您將對 Arbitrum 和樂觀匯總/OPR 有深入的瞭解。

仲裁的核心元件和工作流程

核心合同：

Arbitrum最重要的合同包括SequencerInbox，DelayedInbox，L1 Gateways，L2 Gateways，Outbox，RollupCore，Bridge等。 稍後會詳細介紹。

音序器：

接收並整理使用者交易，計算交易結果，快速（通常<1秒）將收據返回給使用者。 使用者通常可以在幾秒鐘內在 L2 鏈上看到他們的交易，就像 Web2 平台一樣。

同時，排序器還將在乙太坊鏈下實時廣播最新的 L2 區塊，任何 Layer2 節點都可以異步接收。 但此時，這些 L2 塊尚未最終確定，可以由排序器回滾。

每隔幾分鐘，排序器會壓縮排序后的 L2 事務數據，將其聚合成批，並提交給第 1 層的收件匣合約 SequencerInbox，以確保數據可用性和匯總協定的運行。 通常，提交到第 1 層的 L2 數據無法回滾，可以完成。

從上面的過程，我們可以總結一下：Layer2 有自己的節點網路，但這些節點數量稀缺，而且公鏈一般沒有共識協定，所以安全性很差，必須掛在乙太坊上，保證數據發佈的可靠性和狀態轉換的有效性。

仲裁匯總協定：

定義匯總鏈的區塊RBlock結構、鏈的延續、RBlock的釋放和質詢模式過程的一系列合約。 請注意，這裡提到的匯總鏈並不是我們所理解的 Layer2 帳本，而是 Arbitrum One 為了實現防欺詐機制而設置的抽象“鏈數據結構”。

一個 RBlock 可以包含多個 L2 塊的結果，而且數據也有很大不同，它的數據實體 RBlock 存儲在 RollupCore 中的一系列合約中。 如果 RBlock 存在問題，驗證器將質詢該 RBlock 的提交者。

驗證人：

Arbitrum的驗證器節點實際上是Layer2完整節點的一個特殊子集，目前具有允許清單訪問許可權。

驗證器根據排序器提交給 SequencerInbox 合約的一批事務創建新的 RBlock（匯總塊，也稱為斷言），並監視當前匯總鏈的狀態，以質疑排序器提交的錯誤數據。

主動驗證者需要事先在ETH鏈上質押資產，有時也稱為質押者。 雖然不質押的二層節點也可以監控匯總的運行動態，向用戶發送異常告警等，但不能直接干預ETH鏈上排序器提交的錯誤數據。

挑戰：

基礎步驟可以概括為多輪互動式細分和單步證明。 在分段會話中，雙方都被要求對有問題的交易數據執行多輪基於回合的細分，直到有問題的步驟操作代碼指令被分解和驗證。 “多輪分割 - 單步證明”的範式被 Arbitrum 開發人員認為是欺詐證明最省氣的實現。 一切都在合同控制之下，任何一方都不能作弊。

挑戰期：

由於OP匯總的樂觀性，每個RBlock提交到鏈后，合約不會主動檢查，給驗證者留下了偽造的時間視窗。 這個時間視窗是挑戰期，在Arbitrum One主網上是1周。 挑戰期結束后，RBlock 將最終確定，區塊中從 L2 到 L1 的相應消息（例如通過官方橋接執行的提現操作）可以釋放。

ArbOS， Geth， WAVM：

Arbitrum使用的虛擬機稱為AVM，它由兩部分組成：Geth和ArbOS。 Geth是以太坊最常用的用戶端軟體，Arbitrum對它進行了羽量級修改。 ArbOS 負責所有與 L2 相關的特殊功能，例如網路資源管理、生成 L2 塊、使用 EVM 等。 我們將兩者的組合視為本機AVM，這是Arbitrum使用的虛擬機。 WAVM是將AVM的代碼編譯成Wasm的結果。 在仲裁質詢過程中，最終的「單步證明」驗證WAVM指令。

在這裡，我們可以在下圖中說明上述元件之間的關係和工作流：

L2 事務生命週期

以下是 L2 事務的工作原理：

1. 使用者向序列器發送交易指令。

2.排序器首先驗證待處理交易的數位簽名等數據，消除無效交易，並進行排序和計算。

3.排序器將交易收據發送給使用者（通常非常快），但這只是排序器ETH鏈外的“預處理”，處於軟最終狀態，不可靠。 但對於信任排序器的使用者（大多數使用者），樂觀地認為事務已經完成，不會回滾。

4. 排序器將經過高度壓縮的預處理事務原始數據封裝成批處理。

5. 每隔一段時間（受數據量、ETH擁塞等因素影響），排序器會將交易批次發佈到 L1 上的 Sequencer 收件匣合約。 在這一點上，交易可以被認為是具有硬終結性的。

序列器收件匣合同

合約將接收排序器提交的一批交易，以確保數據可用性。 深入一看，SequencerInbox 中的批處理數據完整記錄了第 2 層的事務輸入資訊，即使 Sequencer 永久關閉，任何人都可以根據 Sequencer 記錄恢復第 2 層的當前狀態，替換故障/Rug pull Sequencer。

從物理上講，我們看到的L2只是SequencerInbox中批處理的投影，光源是STF。 由於光源STF不易改變，因此陰影的形狀僅由充當物件的批次決定。

Sequencer 收件匣合約（也稱為 Fastbox）是向其提交預處理事務的排序器，只有排序器可以向其提交數據。 對應的快箱就是慢箱Delayer收件匣，其功能將在後續流程中介紹。

驗證人會一直監聽 SequencerInbox 合約，每當排序器向合約釋放一個批次時，就會拋出一個鏈上事件，驗證人聽到這個事件後，會下載批處理數據，本地執行後會將 RBlock 釋放到 ETH 鏈上的 Rollup 協定合約。

Arbitrum的橋接合約有一個名為累加器的參數，它將記錄新提交的L2批次的數量，以及新收到的交易數量和慢收件匣上的資訊。

SequencerInbox 合約有兩個主要功能：

添加 Sequencer L2Batch From Origin（），Sequencer 每次都會調用該 Sequencer 以將 Batch 數據提交到 Sequencer Inox 合約。

強制包含（），任何人都可以調用，用於實現抗審查事務。 此功能的工作原理將在稍後我們討論延遲收件匣合同時更詳細地解釋。

這兩個函數都調用 bridge.enqueueSequencerMessage（） 來更新橋接合約中的累加器參數累加器。

天然氣定價

顯然，由於 DoS 攻擊、排序器 L2 本身的運行成本以及在 L1 上提交數據的開銷，L2 事務不可能是免費的。 當使用者在第 2 層網路中發起交易時，gas 費用的結構如下：

佔用 Layer 1 資源產生的數據發佈成本主要來自排序器提交的批次（每個批次都有多個使用者事務），成本最終由事務發起方平均分擔。 數據發佈產生的費用定價演演演算法是動態的，排序器將根據最近的損益、批量大小和當前的乙太坊 gas 價格進行定價。

使用者因佔用第 2 層資源而產生的成本設置為每秒可以保證系統穩定運行的最大氣體數量（目前 Arbitrum One 為 700 萬）。 L1 和 L2 的氣體引導價格均由 ArbOS 跟蹤和調整，公式暫時不再在此贅述。

雖然具體的gas價格計算過程比較複雜，但使用者不需要感知這些細節，很明顯，匯總交易費比ETH主網便宜很多。

樂觀的欺詐證明

回顧一下，L2實際上只是Fastbox中排序器提交的交易的批量輸入的投影，即：

事務輸入 -> STF ->狀態輸出。 輸入確定，STF恆定，輸出也確定，欺詐證明系統和Arbitrum Rollup協定是一個以RBlock（又名斷言）的形式將輸出狀態的根發佈到L1並樂觀證明的系統。

在 L1 上，有排序器發佈的輸入數據，也有驗證器發佈的輸出狀態。 讓我們仔細看看，是否有必要在鏈上發佈第 2 層的狀態？

因為輸入已經完全確定了輸出，並且輸入數據是公開可見的，提交輸出-狀態似乎是多餘的，但這個想法忽略了L1-L2系統之間實際上需要狀態沉降的事實，即L2在L1方向上提出的行為，需要有狀態證明。

在構建匯總時，核心思想之一是將大部分計算和存儲放在 L2 上，以避免 L1 的高成本，這意味著 L1 不知道 L2 的狀態，它只説明 L2 排序器發佈所有事務的輸入數據，而不負責計算 L2 的狀態。

提現行為本質上是根據L2給出的跨鏈交互消息，從L1合約中解鎖相應的資金，轉入使用者的L1帳戶或完成其他事情。

此時，第 1 層合約將詢問：您在第 2 層上的狀態是什麼，以及您如何證明您確實擁有您聲稱跨越的資產。 此時，用戶應給出相應的默克爾證明等。

因此，如果我們構建一個沒有提款功能的匯總，理論上可以不將狀態同步到 L1，並且不需要諸如欺詐證明之類的狀態證明系統（儘管它可能會導致其他問題）。 但在實踐中，這顯然是不可行的。

在所謂的樂觀證明中，合約不檢查提交給L1的輸出是否處於正確的狀態，樂觀地認為一切都是正確的。 樂觀證明系統假設在任何給定時間至少有一個誠實的驗證者，如果存在錯誤狀態，它將受到欺詐證明的挑戰。

這種設計的優點是，無需主動驗證發佈到 L1 的每個 RBlock 以避免浪費氣體。 事實上，OPR 驗證每個斷言是不切實際的，因為每個 rblock 包含一個或多個 L2 塊，與直接在 L1 上執行 L2 事務在 L1 上重新執行每個事務沒有什麼區別，這就失去了第 2 層擴展的意義。

ZKR沒有這個問題，因為ZK證明簡單，只需要驗證一個小的證明，不需要在證明後面實際執行很多交易。 因此，ZKR 並不樂觀，每次發佈狀態都由 Verfier 合約進行數學驗證。

雖然欺詐證明不能像零知識證明那樣簡潔，但Arbitrum採用了“多輪拆分單步證明”的逐向交互過程，最終只需要證明單個虛擬機操作代碼，成本相對較小。

匯總協定

讓我們來看看 Rollup 協定（發起挑戰和啟動證明的入口點）是如何工作的。

Rollup 協定的核心合約是 RollupProxy.sol，它使用罕見的雙代理結構來保證數據結構的一致性，一個代理對應 RollupUserLogic.sol 和 RollupAdminLogic.sol 的兩種實現，在 Scan 等工具中無法很好地解析。

此外，還有管理挑戰的ChallengeManager.sol合約，以及確定欺詐證據的OneStepProver系列合約。

在 RollupProxy 中，記錄了不同驗證器提交的一系列 RBlock（又名斷言），它們是下圖中的方塊：綠色 - 已確認，藍色 - 未確認，黃色 - 偽造。

RBlock 包含自上次 RBlock 以來一個或多個 L2 塊執行后的最終狀態。 這些 RBlock 在形態上形成了一個正式的匯總鏈（請注意，L2 帳本本身是不同的）。 在樂觀的情況下，這個匯總鏈不應該被分叉，因為有一個分叉意味著有驗證者提交了衝突的匯總塊。

為了做出或同意一個斷言，驗證者需要首先為這個斷言投入一定數量的ETH，然後成為質押者。 這樣，在發生質疑/欺詐證明時，失敗者的抵押品將被削減，這是保證驗證者誠實行為的經濟基礎。

圖像右下角的藍色方塊111最終會被證偽，因為它的父方塊104是錯誤的方塊（黃色）。

此外，驗證者 A 提出了匯總區塊 106，而 B 不同意，對此提出了質疑。

在 B 發起質詢后，ChallengeManager 合約負責驗證質詢步驟的細分：

1. 分段是雙方輪流交互的過程，一方對匯總塊中包含的歷史數據進行分段，另一方指出數據片段的哪一部分有問題。 類似於逐漸縮小範圍的二分法（實際上是N / K）過程。

2.之後，您可以繼續定位哪個交易和結果有問題，然後進一步細分為該交易中存在爭議的機器指令。

3. ChallengeManager合約僅在細分原始數據後檢查生成的「數據片段」是否有效。

4. 當挑戰者和被挑戰方找到要被質疑的機器指令時，挑戰者調用oneStepProveution（）併發送單步欺詐證明，以證明機器指令的執行結果存在問題。

一步驗證

單步證明是整個仲裁過程中欺詐證明的核心。 讓我們來看看防步證明了什麼。

這需要瞭解WAVM，Wasm Arbitrum虛擬機，這是一個由ArbOS模組和Geth（乙太坊用戶端）核心模組編譯的虛擬機。 由於L2在許多方面與L1非常不同，因此原始的Geth內核必須稍作修改並與ArbOS配合使用。

因此，L2 上的狀態轉換實際上是 ArbOS+Geth Core 的共同特徵。

Arbitrum的Node Client（Sequencer、Validator、Full Node等）將上述ArbOS+Geth核心處理的程式編譯成原生機器代碼（適用於x86/ARM/PC/Mac/等），可以由Node主機直接處理。

如果將編譯的目標語言更改為 Wasm，則會獲得驗證器用於生成欺詐證明的 WAVM，並且驗證單步證明的合約也會類比 WAVM 虛擬機的功能。

主要原因是驗證一步欺詐證明的合約使用乙太坊智慧合約來類比可以處理特定指令集的虛擬機虛擬機，並且WASM很容易在合約上實現。

但是，WASM比本機機器代碼稍慢，因此WAVM僅在生成和驗證欺詐證明時由Arbitrum的節點/合約使用。

經過前幾輪交互分割，單步證明最終被證明是WAVM指令集中的單步指令。

在下面的代碼中可以看到，OneStepProofEntry 首先確定待證明指令的操作代碼屬於哪個類別，然後調用相應的證明者如 Mem、Math 等，並將分步指令傳遞到證明者合約中。

afterHash 的最終結果將返回給 ChallengeManager，如果哈希與匯總塊上記錄的哈希不一致，則質詢將成功。 如果一致，則表示匯總塊上記錄的指令執行結果沒問題，質詢失敗。

在下一篇文章中，我們將分析處理 Arbitrum 甚至第 2 層和第 1 層之間跨鏈交互/橋接功能的合約模組，並進一步闡明真正的第 2 層應該如何抗審查。