羅奔奔是前Arbitrum技術大使和極客web3貢獻者，他就Arbitrum One的技術進行了解讀。他認為在中文圈對Arbitrum的專業解讀不足，在本文中試圖透過科普Arbitrum的運作來填補這個空缺。文章介紹了Rollup排序器的原理和工作方式，以及Arbitrum One的特點和工作流程。他指出Arbitrum中進行樂觀情況下，Rollup鏈不應該有分叉，否則就會有驗證者提交了衝突的Rollup Block。欺騙證明和有效性證明是防止Rollup排序器作惡的關鍵方案。文章也對Arbitrum的核心協議和工作流程進行了深入介紹。
作者：羅奔奔，前Arbitrum 技術大使、極客web3 貢獻者
以下是Arbitrum 前技術大使及智慧合約自動化審計公司Goplus Security 前共同創辦人羅奔奔對Arbitrum One 的技術解讀。
因為中文圈子裡涉及Layer2的文章或資料，缺乏對Arbitrum的肯定OP Rollup的專業解讀，本文試圖透過科普Arbitrum的運作補充，填補領域這個空缺。由於Arbitrum本身的結構太複雜，全文在簡單簡化的基礎上，還是超過了1萬字篇幅，所以串聯了上下兩篇，建議作為參考資料收藏轉發！
Rollup排序器簡述
Rollup擴容的原理可以達到兩點：
成本優化：將大部分攻擊與儲存任務移交至L1鏈下也即L2上。 L2大部分是在單一伺服器上運載也即排序器（Sequencer/Operator）上的壹條鏈。
排序器在觀感上接近一個中心化伺服器，在「區塊鏈不可能三⻆」中捨棄「去中心化」來換取TPS 與成本上的優勢。使用戶可以讓L2 來取代以太坊處理交易指令上，成本比在以太坊上交易要低。
安全保障：L2上的交易內容與交易後的狀態，會同步⾄以太坊L1，透過一致性來校驗狀態轉換的效果。同時，以太坊上會保留L2上的歷史記錄，排序器升級永久宕機，他人也可以透過以太坊上的記錄，還原出整個L2的狀態。
從根本上來說，Rollup的安全性是基於以太坊的。排序器如果不知道某個帳戶的私鑰，就無法使用該帳戶的坊名義發起交易，或者無法篡改該帳戶的資產餘額（同樣是了） ，也很快被識破）。
雖然排序器作為系統中樞標記中⼼化色彩，但在成熟度比較高的Rollup 方案中，中心化排序器僅能實施交易審查等軟性作惡行為，或者惡意宕機，但處於理想狀態的Rollup 方案中，有相應的⼿部分推進社會主義（例如強制提款或排序論證等抗審查機制）。
而防止Rollup排序器作惡的狀態計量方案，分成欺騙證明（Fraud Proof）和有效性證明（Validity Proof）兩類。使用途欺騙證明的Rollup計量方案稱為OP Rollup（Optimistic Rollup，OPR） ，⽽因為一些歷史包袱，使利用有效性證明的Rollup 往往被稱為ZK Rollup（零知識證明Rollup，ZKR），而不是Validity Rollup。
Arbitrum One 是典型的OPR，它應用在L1 上的爭論，並不是主動驗證提交的數據，樂觀地認為這些數據沒有問題。如果提交的資料有錯誤，L2 的驗證者節點會主動發起挑戰。
因此OPR也隱含一條信任假設：任意時刻⾄少有以太坊的L2驗證者節點。 ⽽ZKR的合約則透過密碼學計算，主動但實際上是驗證排序器提交的資料。
下文會深入介紹樂觀式Rollup 中的龍頭專案－Arbitrum One，涵蓋整個系統的方方面面，仔細讀完後你會看到Arbitrum 和樂觀式Rollup/OPR 有深刻的理解。
Arbitrum的核心元件與工作流程
核心契約：
Arbitrum最重要的協議包括SequencerInbox、DelayedInbox、L1 Gateways、L2 Gateways、Outbox、RollupCore、Bridge等。後續將詳細介紹。
排序器排序器：
接收用戶交易並進行排序，計算交易結果，並快速（通常
同時，排序器將會在以太坊鏈下即時廣播最新產生的L2 Block，任何一個Layer2節點都可以非同步的接收。但此時，這些L2 Block不具備最終確定性，可以被排序器回滾掉。
每三十個，排序器將排序後的L2交易資料進行壓縮，聚合成批次（Batch），提交至Layer1上的收件匣契約SequencerInbox，以確保資料可用性和Rollup協議的運作。一般而言，被提交至Layer1上的L2資料無法回滾，可以具備最終確定性。
從以上流程中我們可以實現：Layer2有自己的節點網絡，但這些節點數量稀少，且一般沒有公鏈慣用的共識協議，所以安全性是很差的，必須附在以太坊來保證，數據發布可靠性與狀態轉換的功效。
仲裁協議：
定義了Rollup鏈的區塊RBlock的結構，鏈的祖先方式，RBlock的發布，以及挑戰模式流程等一系列的契約。注意，這⾥說的Rollup鏈不是大家理解的Layer2帳本，而是Arbitrum One為了施展詐欺證明機制，而獨立設定的一條抽像出來的「鏈狀資料結構」。
一個RBlock 可以包含多個L2 區塊的結果，⽽且資料也價值異，它的資料實體RBlock 儲存在RollupCore 的一個系列契約中。如果一個RBlock 有問題，Validator 將向該RBlock 的提交者對其正在進行挑戰。
驗證者驗證者：
Arbitrum 的驗證者節點其實是Layer2 所有節點的特殊子集，目前有白名單准入。
Validator根據排序器提交至SequencerInbox同步的交易批次，來創建新的RBlock（Rollup區塊，也叫斷⾔斷言），並監控當前Rollup鏈的狀態，對排序器提交的錯誤數據進當前挑戰。
激活型的驗證者需要事先在ETH 鏈上質押資產，有時我們也稱之為Staker。不進行質押的Layer2 節點雖然也可以監控Rollup 的運輸行為動態，向使用戶發送異常等警報，但⽆法在ETH鏈上直接對排序器提交的錯誤資料進行⼲預。
挑戰：
步驟基礎可實現為多輪互動方式闡釋、單步論證。在細分管道，挑戰雙打先對有問題的交易資料進行進行多輪互動制細分，直⾄分解出有問題的那一步操作碼指令，並進行進行驗證。 「多輪解析– 單步論證」這個範式，被Arbitrum 開發者認為是欺騙論證中最省油的實現日期式。所有的間歇都在合約控制之下，沒有以太坊一週可以作弊。
挑戰期：
由於OP Rollup 的樂觀樂觀本質，每個RBlock 提交上鍊後，契約並不主動檢查，準備給驗證者一段時間窗⼝期證去。這個時間窗⼝即為挑戰期，在Arbitrum One 主⽹上為1週。挑戰期結束後，該RBlock將會被最終確認，區塊內對應的從L2交付到L1的訊息（例如透過官方橋執行的提款操作）才能被放行。
ArbOS、Geth、WAVM：
Arbitrum 採用的虛擬機器稱為AVM，包含Geth 和ArbOS 兩個部分。 Geth 是以太坊最常使用的客戶端軟體，Arbitrum 對其進行了輕量化的修改。 ArbOS 負責所有L2 相關的特殊功能，如⽹網路資源管理、產生L2區塊、與EVM和諧⼯作等。我們將兩者的組合視為一個Native AVM，哦Arbitrum採用的虛擬機器。 WAVM是把AVM的程式碼編譯為Wasm後的結果。 Arbitrum 挑戰流程中，最後的「單步驟證明」，驗證的就是WAVM 指令。
在此，我們可以將上述各組件之間的關係和⼯作流用途下圖來表示：
L2 生命週期
備註L2交易的處理流程如下：
1.用戶向排序器發送交易指令。
2.排序器首先處理處理交易進數字簽章等資料的驗證，清除無效交易，並進行排序與攻擊。
3.排序器將交易回執傳送給使用者（通常都⾮常快），但只是排序器在ETH 鏈下進行的「廢除」，處於Soft Finality 的狀態，並不可靠。但對於信任排序器的使用者（最大部分使用者），可以樂觀的認為交易已經完成，不會被回溯。
4.排序器將採集後的交易原始數據，高精度壓縮後封裝為一個Batch（批次）。
5.每隔一個時間間隔（受到資料量、ETH壅塞程度等因素影響），排序器會向L1上的Sequencer Inbox約定發布交易Batch。此時可以認為，交易已擁有最終性Hard Finality。
定序器收件匣合約
合約會接收排序器提交的交易批次，保證資料可使用性。深獲取地看，SequencerInbox中的批次數據完整記錄了Layer2的交易輸入信息，即使排序器永久宕機，任何人都可以根據批次的記錄還原Layer2 的當前狀態，接替故障/跑路的排序器。
使用物理的公式理解，我們所看到的L2，只是SequencerInbox中批量的投影，光源分割STF。因為光源STF不會輕易變化，所以影子⼦的形狀決定只是由充當瞄準的批量來。
Sequencer Inbox 是合約⼜稱為快箱，排序器專門向其作業已經被重置的交易，並且只有排序器可向其作業資料。對應快箱慢箱Delayer Inbox，其功能在後續流程中會有描述。
Validator 會一直監聽SequencerInbox 合約，定時排序器向該合約發布Batch 後，就會推送一個鏈上事件，Validator 監聽到這個事件發生後，就會去下載批量數據，在本地執行一次後，向ETH鏈上的Rollup 協議約定發布RBlock 。
仲裁的橋約定內有一個稱為累加器累加器的參數，會針對新提交的L2批次，以及慢收件匣上新接收的交易資料和訊息，進行記錄。
SequencerInbox合約有兩個主要函數：
add Sequencer L2Batch From Origin()，排序器每次都會呼叫函數向Sequencer Inox 簽約提交Batch 資料。
force Inclusion()，函數任何人都可以調用，用於實現抗審查交易。函數的生效方式，會在後面對話Delayed Inbox 約定時詳細解釋。
後續函數都會呼叫bridge.enqueueSequencerMessage()，來更新bridge合約內的累加器參數累加器。
天然氣定價
顯然，L2 的交易不可能免費，這樣會引來DoS 攻擊，再加上排序器L2 本身的運發起成本，以及在L1 上提交資料都會有開支，因為用戶在Layer2 網路內交易時，gas費用的結構如下：
佔用Layer1資源產生的資料發布成本，主要來自於排序器提交的批次（每批次有很多使用者的交易），成本最終由交易發起者們平均分配。資料發布產生的手續費定價演算法是動態的，排序器會根據近期的盈虧情況、批量最大⼩、當前以太坊gas價格進行定價。
使用者因佔用Layer2資源所產生的成本，設定了一個可以保證系統穩定運量的，每秒處理的gas上限（⽬前Arbitrum One是700萬）。 L1和L2的gas指導價格皆由ArbOS追蹤調整，公式暫時不在此贅述。
雖然具體的天然氣價格計算過程比較複雜，但使用用戶消耗到這些細節，可以明顯感覺到Rollup 交易費使用比ETH 主網便宜的多。
樂觀方案證明
回顧以上，L2其實只是排序器在快箱中提交的交易輸入批次的投影，也是：
交易輸入-> STF -> 狀態輸出。輸入已經確定，STF 是不變的，則輸出結果也是確定的，而欺詐證明和Arbitrum Rollup 協議底層系統就是把輸出的狀態根，以RBlock （又名斷言）的形式發佈到L1上並由此進行樂觀論證的一套系統。
在L1上有排序器發布的輸出獲取數據，也有驗證者發布的輸出狀態。我們再仔細考慮量一致性下，是否有必要向鏈上發布Layer2的狀態呢？
因為輸出接收已經完全決定了輸出，而輸入資料是公開可見的，再提交結果輸出– 狀態似乎是多餘的？但這種想法忽略了L1-L2 兩個系統之間實際上需要結算狀態，也即L2 向L1 每年向的提現為，需要有對狀態的證明。
在建構Rollup 的時候，壹條最核心⼼的思想就是把最大部分損害和儲存放在L2 上來規避L1 的高昂的費用途，這意味著，L1 並不知道L2 的狀態，它僅僅幫助L2排序器發布全部交易的輸入數據，但不負責計算L2 的狀態。
⽽提現操作為，本質上是根據L2給出的跨鏈訊息，從L1的合約中解鎖對應的資⾦，轉到規劃用戶的L1帳戶中或完成其他事情。
這時Layer1的合約就會問：你在Layer2上的狀態是怎樣的，怎麼證明你真的擁有這些聲明要跨走的資產。這時候要用戶給予對應該的Merkle Proof等。
所以，如果我們建構一條沒有提現功能的Rollup，理論上不向L1 進行狀態同步是可以的，也不需要欺詐證明等狀態證明系統（雖然可能會帶來其他問題）。但在實際應用中，這顯然是不可運作的。
在所謂的樂觀論證中，合約不會去檢查提交到L1的狀態是否輸出正確，樂觀地認為一切都是準確無誤的。樂觀論證系統會假設，在任何時刻都有⾄少一個名誠實的驗證器，如果出現錯誤的狀態，則通過欺詐證明進行挑戰。
設計的好處是，不需要主動驗證每個端點發佈到L1上的RBlock，避免浪費gas。這麼實際對於OPR⽽⾔因為，對每個端點斷⾔進行驗證也是不現實的，每個Rblock都包含著一個或多個L2區塊，要在L1上對每筆交易重新執一個遍，與直接在L1上執行L2交易無異，這就失去了Layer2擴容的意義。
⽽ ZKR 不存在這個問題，ZK Proof 有簡潔性，只需要驗證一致性很⼩的證明，不需要真地去執行該證明，因為背後所對應的許多筆交易。所以ZKR 不是式樂觀運行的，以上發布狀態都會有Verfier合約進行數學驗證。
欺騙證明雖然不能像零知識證明那樣具有高度的簡潔性，但Arbitrum 使用了以太種“多輪分割– 單步證明”的輪流式交互流程，最終需要證明的單以太的虛擬機操作碼，成本相對比較⼩。
匯總協議
我們先來看看，發起挑戰和啟動論證的入口，也也就是Rollup 協定是如何運作的。
Rollup協定的核心約定是RollupProxy.sol，在保證資料結構一致的情況下，使用了一種罕見的雙重代理結構，一個對應兩個實作RollupUserLogic.sol和RollupAdminLogic.sol，在Scan等工具中目前還無法很好的解析。
另外還有ChallengeManager.sol契約負責管理挑戰，OneStepProver系列契約來欺騙欺騙證明。
在RollupProxy 中，記錄由不同Validator 提交的一系列RBlock（又稱斷言），也即下圖中的區塊：綠色– 已確認，藍色– 未確認，黃色– 已證明偽。
RBlock 中包含了自上一個RBlock 以來，一個或多個L2 區塊執行後的最終狀態。這些RBlock 在形態上構成了一條形態上的Rollup Chain（注意L2 帳本本身本相區別）。在樂觀情況下，這條Rollup Chain 應該是沒有分叉的，因為有分叉意味著有Validator 提交了各處衝突的Rollup Block。
要提出或認同保障斷言，需要驗證者先為該斷言質押一定數量的ETH，成為Staker。這樣在發生挑戰/詐欺證明時，輸者的質押品將被罰沒，這是驗證者誠實行為的經濟學基礎。
比喻右下角的111號藍色塊最終會被證明偽，因為其父塊104號藍色塊是錯誤的（黃色）。
另外，驗證者A提出了106號Rollup Block，而B不同意，就此進行挑戰。
在B發起挑戰後，ChallengeManager合約負責驗證挑戰步驟的詳細流程：
1.闡釋是雙向輪流互動的過程，一方面針對某個Rollup Block中所包含的歷史資料進行架構，另一方面指出哪部分資料片段有問題。構成二分法（其實是N/K）不斷逐漸縮小範圍的一個過程。
2.之後，可以定位繼續至哪一筆交易及結果有問題，再進一步剖析至該交易有爭議的某條機器指令。
3.ChallengeManager合約只檢查原始資料解析後，所產生的『資料片段』是否有效。
4.當挑戰者和被挑戰者找到將被挑戰的那條機器指令後，挑戰者調用oneStepProveExecution()，發送單步欺騙證明，證明這條機器指令的執行結果有問題。
單步證明
單步論證是整個Arbitrum 的詐欺論證的核心。我們來看看單步論證具體論證的內容。
這需要先理解WAVM，Wasm Arbitrum虛擬機，它是一個由ArbOS模組和Geth（以太坊客戶端）核心模組共同編譯成的虛擬機。由於L2與L1有許多不同的地方，原始的Geth核心必須經過輕量修改，並且配合ArbOS一起工作。
所以，L2上的狀態轉換其實就是ArbOS+Geth Core的共同手筆。
Arbitrum 的節點客戶端（排序器、驗證者、全節點等），相當於上述ArbOS+Geth Core 處理的程序，編譯為節點節點能直接處理的迭代機器碼（適用於x86/ARM/PC/Mac/ etc） .）。
如果把編譯後的目標語言改為Wasm，就得到了驗證者產生憑證證明時所使用的WAVM，而驗證單步驟證明的合約上，模擬的也是WAVM 虛擬機器的功能。
那為什麼在產生模式證明時，要編譯為Wasm 字節碼？主要還是因為，驗證單步模式證明的合約，使用以太坊智能合約模擬出能夠處理某個套指令集的虛擬機VM，而WASM 很容易在合約上實現模擬。
但WASM 比起Native 機器程式碼，速度略慢，所以只有在執行論證產生及驗證的時候，Arbitrum 的節點/ 合約將會用到WAVM。
在先前的多輪交互解讀後，單步論證最終論證是WAVM指令集中的單步指令。
下面的程式碼中可以看到，OneStepProofEntry首先要判定，待證明指令的操作碼屬於哪個類別，再呼叫對應的證明者如Mem，Math等，將單步指令確定該證明者一致。
最終結果afterHash 會回到ChallengeManager，如果該雜湊與Rollup Block 上記錄的，指令侵犯後的抖動不一致，則挑戰成功。如果一致，表示Rollup Block 上記錄的這個指令運行結果沒問題，挑戰失敗。
在下一篇文章中，我們將解析Arbitrum 那麼在Layer2 與Layer1 之間處理跨鏈訊息/橋接功能的合約模組，並進一步探討，一個真正有意義的Layer2 應該怎麼實現抗審查。
資訊來源：0x資訊編譯自網際網路。版權歸作者極客Web3所有，未經許可，不得轉載！