【#區(qū)塊鏈# #Arbitrum的組件結(jié)構(gòu)解讀（上）#】

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

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

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

因?yàn)橹形娜ψ永锷婕?Layer2 的文章或資料，缺乏對(duì) Arbitrum 乃至 OP Rollup 的專業(yè)解讀，本文試圖通過科普 Arbitrum 的運(yùn)轉(zhuǎn)機(jī)理，填補(bǔ)這一領(lǐng)域的空缺。由于 Arbitrum 本身的結(jié)構(gòu)太復(fù)雜，全文在盡可能簡化的基礎(chǔ)上，還是超過了 1 萬字篇幅，所以分成了上下兩篇，建議作為參考資料收藏轉(zhuǎn)發(fā)！

Rollup 排序器簡述

Rollup 擴(kuò)容的原理可以概括為兩點(diǎn)：

成本優(yōu)化：將大部分運(yùn)算與存儲(chǔ)任務(wù)移交至 L1 鏈下也即 L2 上。L2 大多是運(yùn)?在單臺(tái)服務(wù)器也即排序器（Sequencer/Operator）上的?條鏈。

排序器在觀感上接近于一臺(tái)中心化服務(wù)器，在「區(qū)塊鏈不可能三?」中舍棄「去中心化」來換取 TPS 與成本上的優(yōu)勢(shì)。??戶可以讓 L2 來代替以太坊處理交易指令，成本比在以太坊上交易要低得多。

（圖源：BNB Chain）

安全保障：L2 上的交易內(nèi)容與交易后的狀態(tài)，會(huì)同步至以太坊 L1，通過合約來校驗(yàn)狀態(tài)轉(zhuǎn)換的有效性。同時(shí)，以太坊上會(huì)保留 L2 的歷史記錄，排序器即便永久宕機(jī)，他?也可以通過以太坊上的記錄，還原出整個(gè) L2 的狀態(tài)。

從根本上來說，Rollup 的安全性是基于以太坊的。排序器如果不知道某個(gè)賬戶的私鑰，就無法用該賬戶的名義發(fā)起交易，或者無法篡改該賬戶的資產(chǎn)余額（即便這么做了，也很快被識(shí)破）。

雖然排序器作為系統(tǒng)中樞帶有中心化色彩，但在成熟度比較高的 Rollup 方案中，中心化排序器僅能實(shí)施交易審查等軟性作惡行為，或者惡意宕機(jī)，但在理想狀態(tài)的 Rollup方案中，有相應(yīng)的手段進(jìn)行遏制（比如強(qiáng)制提款或排序證明等抗審查機(jī)制）。

（路印協(xié)議在 L1 上的合約源碼中設(shè)置的，供用戶調(diào)用的強(qiáng)制提款函數(shù)）

而防止 Rollup 排序器作惡的狀態(tài)校驗(yàn)?式，分為欺詐證明（Fraud Proof）和有效性證明（Validity Proof）兩類。使?欺詐證明的 Rollup方案稱為 OP Rollup（Optimistic Rollup，OPR），而因?yàn)橐恍v史包袱，使?有效性證明的 Rollup 往往被稱為 ZK Rollup（Zero-knowledge Proof Rollup，ZKR)，而不是 Validity Rollup。

Arbitrum One 是典型的 OPR，它部署在 L1 上的合約，并不主動(dòng)驗(yàn)證提交過來的數(shù)據(jù)，樂觀地認(rèn)為這些數(shù)據(jù)沒有問題。如果提交的數(shù)據(jù)有錯(cuò)誤，L2 的驗(yàn)證者節(jié)點(diǎn)會(huì)主動(dòng)發(fā)起挑戰(zhàn)。

因此 OPR 也暗含一條信任假設(shè)：任意時(shí)刻?少有?個(gè)誠實(shí)的 L2 驗(yàn)證者節(jié)點(diǎn)。而ZKR 的合約則通過密碼學(xué)計(jì)算，主動(dòng)但低成本地驗(yàn)證排序器提交的數(shù)據(jù)。?

（樂觀 Rollup 運(yùn)轉(zhuǎn)方式）

（ZK Rollup 運(yùn)轉(zhuǎn)方式）

本文會(huì)深度介紹樂觀式 Rollup 中的龍頭項(xiàng)目——Arbitrum One，覆蓋整個(gè)系統(tǒng)的方方面面，仔細(xì)閱讀完后你將對(duì) Arbitrum 和樂觀式 Rollup/OPR 有深刻的理解。

Arbitrum 的核心組件與工作流程

核心合約：

Arbitrum 最重要的合約包括 SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge 等。后續(xù)將詳細(xì)介紹。

排序器 Sequencer：

接收用戶交易并進(jìn)行排序，計(jì)算交易結(jié)果，并迅速（通常<1s）返還給用戶回執(zhí)。用戶往往在幾秒內(nèi)就能看到自己的交易在 L2 上鏈，體驗(yàn)就如同 Web2 平臺(tái)。

同時(shí)，排序器還會(huì)在以太坊鏈下即時(shí)廣播最新產(chǎn)生的 L2 Block，任何一個(gè) Layer2 節(jié)點(diǎn)都可以異步的接收。但此時(shí)，這些 L2 Block 不具備最終確定性，可以被排序器回滾掉。

每隔幾分鐘，排序器會(huì)將排序后的 L2 交易數(shù)據(jù)進(jìn)行壓縮，聚合成批次（Batch），提交至 Layer1 上的收件箱合約 SequencerInbox，以保證數(shù)據(jù)可用性和 Rollup 協(xié)議的運(yùn)轉(zhuǎn)。一般而言，被提交至 Layer1 上的 L2 數(shù)據(jù)無法回滾，可以具備最終確定性。

從以上流程中我們可以概括：Layer2 有自己的節(jié)點(diǎn)網(wǎng)絡(luò)，但這些節(jié)點(diǎn)數(shù)量稀少，且一般沒有公鏈慣用的共識(shí)協(xié)議，所以安全性是很差的，必須要依附于以太坊來保證，數(shù)據(jù)發(fā)布的可靠性與狀態(tài)轉(zhuǎn)換的有效性。

Arbitrum Rollup 協(xié)議：

定義 Rollup 鏈的區(qū)塊 RBlock 的結(jié)構(gòu)，鏈的延續(xù)方式，RBlock 的發(fā)布，以及挑戰(zhàn)模式流程等?系列的合約。注意，這里說的 Rollup 鏈并不是大家理解的 Layer2 賬本，而是 Arbitrum One 為了施展欺詐證明機(jī)制，而獨(dú)立設(shè)置的一條抽象出來的「鏈狀數(shù)據(jù)結(jié)構(gòu)」。

?個(gè) RBlock 可以包含多個(gè) L2 區(qū)塊的結(jié)果，?且數(shù)據(jù)也迥異，它的數(shù)據(jù)實(shí)體 RBlock 存儲(chǔ)在 RollupCore 的?系列合約中。如果?個(gè) RBlock 存在問題，Validator 將?向該 RBlock 的提交者對(duì)其進(jìn)?挑戰(zhàn)。

驗(yàn)證者 Validator：

Arbitrum 的驗(yàn)證者節(jié)點(diǎn)其實(shí)是 Layer2 全節(jié)點(diǎn)的特殊子集，目前有白名單準(zhǔn)入。

Validator 根據(jù)排序器提交至 SequencerInbox 合約的交易批次 batch，來創(chuàng)建新的 RBlock（Rollup 區(qū)塊，也叫斷?assertion），并監(jiān)控當(dāng)前 Rollup 鏈的狀態(tài)，對(duì)排序器提交的錯(cuò)誤數(shù)據(jù)進(jìn)行挑戰(zhàn)。

主動(dòng)型的 Validator 需要事先在 ETH 鏈上質(zhì)押資產(chǎn)，有時(shí)我們也稱其為 Staker。不進(jìn)行質(zhì)押的 Layer2 節(jié)點(diǎn)雖然也可以監(jiān)控 Rollup 的運(yùn)行動(dòng)態(tài)，向用戶發(fā)送異常報(bào)警等，但無法在 ETH 鏈上直接對(duì)排序器提交的錯(cuò)誤數(shù)據(jù)進(jìn)行干預(yù)。

挑戰(zhàn)：

基礎(chǔ)步驟可以概括為多輪互動(dòng)式細(xì)分、單步證明。在細(xì)分環(huán)節(jié)，挑戰(zhàn)雙?先對(duì)有問題的交易數(shù)據(jù)進(jìn)行多輪回合制細(xì)分，直至分解出有問題的那?步操作碼指令，并進(jìn)行驗(yàn)證。「多輪細(xì)分-單步證明」這種范式，被 Arbitrum 開發(fā)者認(rèn)為是欺詐證明中最節(jié)省 gas 的實(shí)現(xiàn)方式。所有環(huán)節(jié)都在合約控制之下，沒有?方可以作弊。

挑戰(zhàn)期：

由于 OP Rollup 的樂觀 optimistic 本質(zhì)，每個(gè) RBlock 提交上鏈后，合約并不主動(dòng)檢查，預(yù)留給驗(yàn)證者一段時(shí)間窗摳期去證偽。此時(shí)間窗口即為挑戰(zhàn)期，在 Arbitrum One 主網(wǎng)上為 1 周。挑戰(zhàn)期結(jié)束后，該 RBlock 才會(huì)被最終確認(rèn)，塊內(nèi)對(duì)應(yīng)的從 L2 傳遞到 L1 的消息（比如通過官方橋執(zhí)行的提款操作）才能被放行。

ArbOS, Geth, WAVM：

Arbitrum 采用的虛擬機(jī)名為 AVM，包含 Geth 和 ArbOS 兩部分。Geth 是以太坊最常用的客戶端軟件，Arbitrum 對(duì)其進(jìn)行了輕量化的修改。ArbOS 負(fù)責(zé)所有 L2 相關(guān)的特殊功能，如網(wǎng)絡(luò)資源管理、生成 L2 區(qū)塊、與 EVM 協(xié)同?作等。我們將兩者的組合視為?個(gè) Native AVM，也就是 Arbitrum 采用的虛擬機(jī)。WAVM 是把 AVM 的代碼編譯為 Wasm 后的結(jié)果。Arbitrum 挑戰(zhàn)流程中，最后的那個(gè)「單步證明」，驗(yàn)證的就是 WAVM 指令。

在此，我們可以將上述各個(gè)組件之間的關(guān)系和工作流用圖來表示：

L2 交易生命周期

一筆 L2 交易的處理流程如下：

1. 用戶向排序器發(fā)送交易指令。

2. 排序器先對(duì)待處理交易進(jìn)數(shù)字簽名等數(shù)據(jù)的驗(yàn)證，剔除無效交易，并進(jìn)行排序和運(yùn)算。

3. 排序器將交易回執(zhí)發(fā)送給?戶（通常都??？欤?strong>但這只是排序器在 ETH 鏈下進(jìn)行的「預(yù)處理」，處于 Soft Finality 的狀態(tài)，并不可靠。但對(duì)于信任排序器的?戶（大部分用戶），可以樂觀的認(rèn)為交易已經(jīng)完成，不會(huì)被回滾。

4. 排序器將預(yù)處理后的交易原始數(shù)據(jù)，?度壓縮后封裝為?個(gè) Batch（批次）。

5. 每隔?段時(shí)間（受到數(shù)據(jù)量、ETH 擁堵程度等因素影響），排序器會(huì)向 L1 上的 Sequencer Inbox 合約發(fā)布交易 Batch。此時(shí)可認(rèn)為，交易已擁有最終性 Hard Finality。

Sequencer Inbox 合約

合約會(huì)接收排序器提交的交易 batch，保證數(shù)據(jù)可用性。深入地看，SequencerInbox 中的 batch 數(shù)據(jù)完整記錄了 Layer2 的交易輸入信息，即使排序器永久宕機(jī)，任何人都可以根據(jù) batch 的記錄還原 Layer2 的當(dāng)前狀態(tài)，接替故障/跑路的排序器。

用物理的方式理解，我們所看到的 L2，只是 SequencerInbox 中 batch 的投影，光源則是 STF。因?yàn)楣庠?STF 不會(huì)輕易變化，所以影?的形狀只由充當(dāng)物體的 batch 來決定。?

Sequencer Inbox 合約又稱為快箱，排序器專門向其提交已經(jīng)被預(yù)處理的交易，且只有排序器可向其提交數(shù)據(jù)。對(duì)應(yīng)快箱的是慢箱 Delayer Inbox，其功能在后續(xù)流程中會(huì)有描述。

Validator 會(huì)一直監(jiān)聽 SequencerInbox 合約，每當(dāng)排序器向該合約發(fā)布 Batch 后，就會(huì)拋出一個(gè)鏈上事件，Validator 監(jiān)聽到這個(gè)事件發(fā)生后，就會(huì)去下載 batch 數(shù)據(jù)，在本地執(zhí)行后，向 ETH 鏈上的 Rollup 協(xié)議合約發(fā)布 RBlock。?

Arbitrum 的 bridge 合約內(nèi)有個(gè)叫累加器 accumulator 的參數(shù)，會(huì)針對(duì)新提交的 L2 batch，以及慢 Inbox 上新接收的交易數(shù)和信息，進(jìn)行記錄。

（排序器向 SequencerInbox 不斷提交 batch）

（Batch 的具體信息，data 字段對(duì)應(yīng)著 Batch 數(shù)據(jù)，這部分?jǐn)?shù)據(jù)尺寸很大，截圖沒顯示完）

SequencerInbox 合約有兩個(gè)主要函數(shù)：

add Sequencer L2Batch From Origin()，排序器每次都會(huì)調(diào)用該函數(shù)向 Sequencer Inox 合約提交 Batch 數(shù)據(jù)。

force Inclusion()，該函數(shù)任何人都可以調(diào)用，用于實(shí)現(xiàn)抗審查交易。這個(gè)函數(shù)的生效方式，會(huì)在后面談到 Delayed Inbox 合約時(shí)詳細(xì)解釋。

上述兩個(gè)函數(shù)都會(huì)調(diào)用 bridge.enqueueSequencerMessage()，來更新 bridge 合約內(nèi)的累加器參數(shù) accumulator。

Gas 定價(jià)

顯然，L2 的交易不可能免費(fèi)，因?yàn)檫@樣會(huì)引來 DoS 攻擊，另外則是排序器 L2 本身的運(yùn)?成本，以及在 L1 上提交數(shù)據(jù)都會(huì)有開銷。用戶在 Layer2 網(wǎng)絡(luò)內(nèi)發(fā)起交易時(shí)，gas 費(fèi)的結(jié)構(gòu)如下：?

占用 Layer1 資源產(chǎn)生的數(shù)據(jù)發(fā)布成本，主要來自于排序器提交的 batch（每個(gè) batch 有很多用戶的交易），成本最終由交易發(fā)起者們均攤。數(shù)據(jù)發(fā)布產(chǎn)生的手續(xù)費(fèi)定價(jià)算法是動(dòng)態(tài)的，排序器會(huì)根據(jù)近期的盈虧狀況、batch大小、當(dāng)前以太坊 gas 價(jià)格進(jìn)?定價(jià)。

用戶因占用 Layer2 資源產(chǎn)生的成本，設(shè)定了?個(gè)可以保證系統(tǒng)穩(wěn)定運(yùn)行的，每秒處理的 gas 上限（目前 Arbitrum One 是 700 萬）。L1 和 L2 的 gas 指導(dǎo)價(jià)格均由 ArbOS 跟蹤并調(diào)整，公式暫時(shí)不在此贅述。

雖然具體的 gas 價(jià)格計(jì)算過程比較復(fù)雜，但用戶無需感知到這些細(xì)節(jié)，可以明顯感到 Rollup 交易費(fèi)用比 ETH 主網(wǎng)便宜的多。?

樂觀式欺詐證明

回顧上文，L2 實(shí)際上只是排序器在快箱中提交的交易輸入 batch 的投影，也即：

Transaction Inputs -> STF -> State Outputs。輸入已經(jīng)確定，STF 是不變的，則輸出結(jié)果也是確定的，而欺詐證明和 Arbitrum Rollup 協(xié)議這套系統(tǒng)就是把輸出的狀態(tài)根，以 RBlock（aka 斷言）的形式發(fā)布到 L1 上并對(duì)其進(jìn)行樂觀式證明的一套系統(tǒng)。

在 L1 上有排序器發(fā)布的輸入數(shù)據(jù)，也有驗(yàn)證者發(fā)布的輸出狀態(tài)。我們?cè)僮屑?xì)考量?下，是否有必要向鏈上發(fā)布 Layer2 的狀態(tài)呢？

因?yàn)檩斎胍呀?jīng)完全決定了輸出，而輸入數(shù)據(jù)是公開可見的，再提交輸出結(jié)果-狀態(tài)似乎是多余的？但這種想法忽略了 L1-L2 兩個(gè)系統(tǒng)之間實(shí)際上需要狀態(tài)結(jié)算，也即 L2 向 L1方向的提現(xiàn)行為，需要有對(duì)狀態(tài)的證明。?

在搭建 Rollup 的時(shí)候，?條最核心的思想就是把大部分運(yùn)算和存儲(chǔ)放到 L2 上來規(guī)避 L1高昂的費(fèi)用，這也就意味著，L1 并不知道 L2 的狀態(tài)，它僅僅幫助 L2 排序器發(fā)布全體交易的輸入數(shù)據(jù)，但并不負(fù)責(zé)計(jì)算出 L2 的狀態(tài)。

而提現(xiàn)行為，本質(zhì)上是依照 L2 給出的跨鏈消息，從 L1 的合約?解鎖相應(yīng)資金，劃轉(zhuǎn)到用戶的 L1 賬戶中或完成其他事情。

此時(shí) Layer1 的合約就會(huì)問：你在 Layer2 上的狀態(tài)是怎樣的，怎么證明你真的擁有這些聲明要跨走的資產(chǎn)。這個(gè)時(shí)候用戶要給出對(duì)應(yīng)該的 Merkle Proof 等。

所以，如果我們構(gòu)建?條沒有提現(xiàn)功能的 Rollup，理論上不向 L1 進(jìn)?狀態(tài)同步是可以的，也不需要欺詐證明等狀態(tài)證明系統(tǒng)（雖然可能帶來其他問題）。但在現(xiàn)實(shí)應(yīng)?中，這顯然是不可行的。?

所謂的樂觀式證明中，合約不會(huì)去檢查提交到 L1 的輸出狀態(tài)是否正確，樂觀地認(rèn)為一切都是準(zhǔn)確無誤的。樂觀證明系統(tǒng)會(huì)假設(shè)，在任意時(shí)刻都有至少一名誠實(shí)的 Validator，如果出現(xiàn)錯(cuò)誤的狀態(tài)，則通過欺詐證明進(jìn)行挑戰(zhàn)。

這么設(shè)計(jì)的好處是，不需要主動(dòng)驗(yàn)證每?個(gè)發(fā)布到 L1 上的 RBlock，避免浪費(fèi) gas。實(shí)際上對(duì)于 OPR而言，對(duì)每?個(gè)斷言進(jìn)行驗(yàn)證也是不現(xiàn)實(shí)的，因?yàn)槊總€(gè) Rblock 都包含著一或多個(gè) L2 區(qū)塊，要在 L1 上去對(duì)每筆交易重新執(zhí)行?遍，與直接在 L1 上執(zhí)行 L2 交易無異，這就失去了 Layer2 擴(kuò)容的意義。

而ZKR 不存在這個(gè)問題，因?yàn)?ZK Proof 有簡潔性，只需要驗(yàn)證?個(gè)很小的 Proof，不需要真地去執(zhí)行該 Proof 背后所對(duì)應(yīng)的許多條交易。所以 ZKR 并不是樂觀式運(yùn)行，每次發(fā)布狀態(tài)都會(huì)有 Verfier 合約進(jìn)行數(shù)學(xué)驗(yàn)證。

欺詐證明雖然不能像零知識(shí)證明那樣具有?度的簡潔性，但 Arbitrum 使用了?種「多輪分割-單步證明」的輪流式交互流程，最終需要證明的僅僅是單?的虛擬機(jī)操作碼，成本相對(duì)較小。

Rollup 協(xié)議

我們先來看一下，發(fā)起挑戰(zhàn)和啟動(dòng)證明的入口，也即 Rollup 協(xié)議是如何工作的。

Rollup 協(xié)議的核心合約是 RollupProxy.sol，在保證數(shù)據(jù)結(jié)構(gòu)一致的情況下，使用了一個(gè)罕見的雙重代理結(jié)構(gòu)，一個(gè)代理對(duì)應(yīng)兩個(gè)實(shí)現(xiàn) RollupUserLogic.sol 和 RollupAdminLogic.sol，在 Scan 等工具中目前還無法很好的解析。

另外還有 ChallengeManager.sol 合約負(fù)責(zé)管理挑戰(zhàn)，OneStepProver 系列合約來判定欺詐證明。

（圖源：L2BEAT 官網(wǎng)）

在 RollupProxy 中，記錄由不同 Validator 提交的一系列 RBlock（aka 斷言），也即下圖中的方塊：綠色-已確認(rèn)，藍(lán)色-未確認(rèn)，黃色-已證偽。

RBlock 中包含了自上一個(gè) RBlock 以來，一個(gè)或多個(gè) L2 區(qū)塊執(zhí)行后的最終狀態(tài)。這些 RBlock 在形態(tài)上構(gòu)成了一條形式上的 Rollup Chain（注意 L2 賬本本身相區(qū)別）。在樂觀情況下，這條 Rollup Chain 應(yīng)該是沒有分叉的，因?yàn)橛蟹植嬉馕吨?Validator 提交了彼此沖突的 Rollup Block。

要提出或認(rèn)同斷言，需要驗(yàn)證者先為該斷言質(zhì)押一定數(shù)量的 ETH，成為 Staker。這樣在發(fā)生挑戰(zhàn)/欺詐證明時(shí)，輸者的質(zhì)押品將被罰沒，這是保障驗(yàn)證者誠實(shí)行為的經(jīng)濟(jì)學(xué)基礎(chǔ)。

圖中右下角的 111 號(hào)藍(lán)色塊最終會(huì)被證偽，因?yàn)槠涓笁K 104 號(hào)區(qū)塊是錯(cuò)誤的（黃色）。

此外，驗(yàn)證者 A 提出了 106 號(hào) Rollup Block，而 B 不同意，對(duì)其進(jìn)行挑戰(zhàn)。

在 B 發(fā)起挑戰(zhàn)后，ChallengeManager 合約負(fù)責(zé)驗(yàn)證對(duì)挑戰(zhàn)步驟的細(xì)分過程：

1. 細(xì)分是一個(gè)雙方輪流互動(dòng)的過程，一方對(duì)某個(gè) Rollup Block 中包含的歷史數(shù)據(jù)進(jìn)行分段，另一方指出是哪部分?jǐn)?shù)據(jù)片段有問題。類似于二分法（實(shí)際是 N/K）不斷漸進(jìn)縮小范圍的一個(gè)過程。

2. 之后，可以繼續(xù)定位至哪條交易及結(jié)果有問題，再進(jìn)一步細(xì)分至該交易中有爭議的某條機(jī)器指令。

3.ChallengeManager 合約只檢查對(duì)原始數(shù)據(jù)進(jìn)行細(xì)分后，產(chǎn)生的『數(shù)據(jù)片段』是否有效。

4. 當(dāng)挑戰(zhàn)者和被挑戰(zhàn)者定位到了將被挑戰(zhàn)的那條機(jī)器指令后，挑戰(zhàn)者調(diào)用 oneStepProveExecution()，發(fā)送單步欺詐證明，證明這條機(jī)器指令的執(zhí)行結(jié)果有問題。

單步證明

單步證明是整個(gè) Arbitrum 的欺詐證明的核心。我們看一下單步證明具體證明的是什么內(nèi)容。

這需要先理解 WAVM，Wasm Arbitrum Virtual Machine，它是一個(gè)由 ArbOS 模塊和 Geth（以太坊客戶端）核心模塊共同編譯成的虛擬機(jī)。由于 L2 與 L1 有許多截然不同的地方，原始的 Geth 核心必須經(jīng)過輕量修改，并且配合 ArbOS 一起工作。

所以，L2 上的狀態(tài)轉(zhuǎn)換其實(shí)是 ArbOS+Geth Core 的共同手筆。

Arbitrum 的節(jié)點(diǎn)客戶端（排序器、驗(yàn)證者、全節(jié)點(diǎn)等），是將上述 ArbOS+Geth Core 處理的程序，編譯為節(jié)點(diǎn)主機(jī)能直接處理的原生機(jī)器代碼（for x86/ARM/PC/Mac/etc.）。

如果把編譯后得到的目標(biāo)語言更改為 Wasm，就得到了驗(yàn)證者生成欺詐證明時(shí)使用的 WAVM，而驗(yàn)證單步證明的合約上，模擬的也是 WAVM 虛擬機(jī)的功能。

那為什么在生成欺詐證明時(shí)，要編譯為 Wasm 字節(jié)碼？主要還是因?yàn)?，?yàn)證單步欺詐證明的合約，要用以太坊智能合約模擬出 能處理某套指令集的虛擬機(jī) VM，而 WASM 易于在合約上實(shí)現(xiàn)模擬。

但 WASM 相比于 Native 機(jī)器代碼，運(yùn)行速度略慢，所以只有在欺詐證明生成及驗(yàn)證的時(shí)候，Arbitrum 的節(jié)點(diǎn)/合約才會(huì)用到 WAVM。

在之前的多輪互動(dòng)細(xì)分后，單步證明最終證明的是 WAVM 指令集中的單步指令。

下面的代碼中可以看到，OneStepProofEntry 首先要判定，待證明指令的操作碼屬于哪個(gè)類別，再調(diào)用相應(yīng)的 prover 如 Mem，Math 等，將單步指令傳入該 prover 合約。

最終結(jié)果 afterHash 會(huì)回到 ChallengeManager，如果該哈希與 Rollup Block 上記錄的，指令運(yùn)算后的哈希不一致，則挑戰(zhàn)成功。如果一致，則說明 Rollup Block 上記錄的這個(gè)指令運(yùn)行結(jié)果沒問題，挑戰(zhàn)失敗。

在下一篇文章中，我們將解析 Arbitrum 乃至于 Layer2 與 Layer1 之間處理跨鏈消息/橋接功能 的合約模塊，并進(jìn)一步闡明，一個(gè)真正意義的 Layer2 應(yīng)該怎么實(shí)現(xiàn)抗審查。

原文鏈接