本文是 Arbitrum 前技術(shù)大使及智能合約自動化審計(jì)公司 Goplus Security 前聯(lián)合創(chuàng)始人羅奔奔對 Arbitrum One 的技術(shù)解讀。
撰文：羅奔奔，前 Arbitrum 技術(shù)大使、極客 web3 貢獻(xiàn)者
本文是 Arbitrum 前技術(shù)大使 及 智能合約自動化審計(jì)公司 Goplus Security 前聯(lián)合創(chuàng)始人羅奔奔 對 Arbitrum One 的技術(shù)解讀。
因?yàn)橹形娜ψ永锷婕?Layer2 的文章或資料，缺乏對 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)算與存儲任務(wù)移交至 L1 鏈下也即 L2 上。L2 大多是運(yùn)?在單臺服務(wù)器也即排序器（Sequencer/Operator）上的?條鏈。
排序器在觀感上接近于一臺中心化服務(wù)器，在「區(qū)塊鏈不可能三?」中舍棄「去中心化」來換取 TPS 與成本上的優(yōu)勢。??戶可以讓 L2 來代替以太坊處理交易指令，成本比在以太坊上交易要低得多。
（圖源：BNB Chain）
安全保障：L2 上的交易內(nèi)容與交易后的狀態(tài)，會同步?以太坊 L1，通過合約來校驗(yàn) 狀態(tài)轉(zhuǎn)換的有效性。同時，以太坊上會保留 L2 的歷史記錄，排序器即便永久宕機(jī)，他?也可以通過以太坊上的記錄，還原出整個 L2 的狀態(tài)。
從根本上來說，Rollup 的安全性是基于以太坊的。排序器如果不知道某個賬戶的私鑰，就無法用該賬戶的名義發(fā)起交易，或者無法篡改該賬戶的資產(chǎn)余額（即便這么做了，也很快被識破）。
雖然排序器作為系統(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 上的合約，并不主動驗(yàn)證提交過來的數(shù)據(jù)，樂觀地認(rèn)為這些數(shù)據(jù)沒有問題。如果提交的數(shù)據(jù)有錯誤，L2 的驗(yàn)證者節(jié)點(diǎn)會主動發(fā)起挑戰(zhàn)。
因此OPR 也暗含一條信任假設(shè)：任意時刻?少有?個誠實(shí)的 L2 驗(yàn)證者節(jié)點(diǎn)。? ZKR 的合約則通過密碼學(xué)計(jì)算，主動但低成本地驗(yàn)證排序器提交的數(shù)據(jù)。?
（樂觀 Rollup 運(yùn)轉(zhuǎn)方式）
（ZK Rollup 運(yùn)轉(zhuǎn)方式）
本文會深度介紹樂觀式 Rollup 中的龍頭項(xiàng)目——Arbitrum One，覆蓋整個系統(tǒng)的方方面面，仔細(xì)閱讀完后你將對 Arbitrum 和樂觀式 Rollup/OPR 有深刻的理解。
Arbitrum 的核心組件與工作流程
核心合約：
Arbitrum 最重要的合約包括SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge 等。后續(xù)將詳細(xì)介紹。
排序器 Sequencer：
接收用戶交易并進(jìn)行排序，計(jì)算交易結(jié)果，并迅速（通常
同時，排序器還會在以太坊鏈下即時廣播最新產(chǎn)生的 L2 Block，任何一個 Layer2 節(jié)點(diǎn)都可以異步的接收。但此時，這些 L2 Block 不具備最終確定性，可以被排序器回滾掉。
每隔幾分鐘，排序器會將排序后的 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ù)量稀少，且一般沒有公鏈慣用的共識協(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)」。
?個 RBlock 可以包含多個 L2 區(qū)塊的結(jié)果，?且數(shù)據(jù)也迥異，它的數(shù)據(jù)實(shí)體 RBlock 存儲在 RollupCore 的?系列合約中。如果?個 RBlock 存在問題，Validator 將?向該 RBlock 的提交者對其進(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)，對排序器提交的錯誤數(shù)據(jù)進(jìn)?挑戰(zhàn)。
主動型的 Validator 需要事先在 ETH 鏈上質(zhì)押資產(chǎn)，有時我們也稱其為 Staker。不進(jìn)?質(zhì)押的 Layer2 節(jié)點(diǎn)雖然也可以監(jiān)控 Rollup 的運(yùn)?動態(tài)，向?戶發(fā)送異常報(bào)警等，但?法在 ETH 鏈上直接對排序器提交的錯誤數(shù)據(jù)進(jìn)行?預(yù)。
挑戰(zhàn)：
基礎(chǔ)步驟可以概括為多輪互動式細(xì)分、單步證明。在細(xì)分環(huán)節(jié)，挑戰(zhàn)雙?先對有問題的交易數(shù)據(jù)進(jìn)?多輪回合制細(xì)分，直?分解出有問題的那?步操作碼指令，并進(jìn)?驗(yàn)證?！?strong>多輪細(xì)分 - 單步證明」這種范式，被 Arbitrum 開發(fā)者認(rèn)為是欺詐證明中最節(jié)省 gas 的實(shí)現(xiàn)?式。所有環(huán)節(jié)都在合約控制之下，沒有??可以作弊。
挑戰(zhàn)期：
由于 OP Rollup 的樂觀 optimistic 本質(zhì)，每個 RBlock 提交上鏈后，合約并不主動檢查，預(yù)留給驗(yàn)證者一段時間窗?期去證偽。此時間窗?即為挑戰(zhàn)期，在 Arbitrum One 主?上為 1 周。挑戰(zhàn)期結(jié)束后，該 RBlock 才會被最終確認(rèn)，塊內(nèi)對應(yīng)的從 L2 傳遞到 L1 的消息（比如通過官方橋執(zhí)行的提款操作）才能被放行。
ArbOS, Geth, WAVM：
Arbitrum 采用的虛擬機(jī)名為 AVM，包含 Geth 和 ArbOS 兩部分。Geth 是以太坊最常?的客戶端軟件，Arbitrum 對其進(jìn)?了輕量化的修改。ArbOS 負(fù)責(zé)所有 L2 相關(guān)的特殊功能，如?絡(luò)資源管理、?成 L2 區(qū)塊、與 EVM 協(xié)同?作等。我們將兩者的組合視為?個 Native AVM，也就是 Arbitrum 采用的虛擬機(jī)。WAVM 是把 AVM 的代碼編譯為 Wasm 后的結(jié)果。Arbitrum 挑戰(zhàn)流程中，最后的那個「單步證明」，驗(yàn)證的就是 WAVM 指令。
在此，我們可以將上述各個組件之間的關(guān)系和?作流?下圖來表示：
L2 交易生命周期
一筆 L2 交易的處理流程如下：
1.用戶向排序器發(fā)送交易指令。
2.排序器先對待處理交易進(jìn)數(shù)字簽名等數(shù)據(jù)的驗(yàn)證，剔除無效交易，并進(jìn)行排序和運(yùn)算。
3.排序器將交易回執(zhí)發(fā)送給?戶（通常都??？欤?，但這只是排序器在 ETH 鏈下進(jìn)行的「預(yù)處理」，處于 Soft Finality 的狀態(tài)，并不可靠。但對于信任排序器的?戶（?部分?戶），可以樂觀的認(rèn)為交易已經(jīng)完成，不會被回滾。
4.排序器將預(yù)處理后的交易原始數(shù)據(jù)，?度壓縮后封裝為?個 Batch（批次）。
5.每隔?段時間（受到數(shù)據(jù)量、ETH 擁堵程度等因素影響），排序器會向 L1 上的 Sequencer Inbox 合約發(fā)布交易 Batch。此時可認(rèn)為，交易已擁有最終性 Hard Finality。
Sequencer Inbox 合約
合約會接收排序器提交的交易 batch，保證數(shù)據(jù)可?性。深?地看，SequencerInbox 中的 batch 數(shù)據(jù)完整記錄了 Layer2 的交易輸入信息，即使排序器永久宕機(jī)，任何?都可以根據(jù) batch 的記錄還原 Layer2 的當(dāng)前狀態(tài)，接替故障 / 跑路的排序器。
?物理的?式理解，我們所看到的 L2，只是 SequencerInbox 中 batch 的投影，光源則是 STF。因?yàn)楣庠?STF 不會輕易變化，所以影?的形狀只由充當(dāng)物體的 batch 來決定。?
Sequencer Inbox 合約?稱為快箱，排序器專門向其提交已經(jīng)被預(yù)處理的交易，且只有排序器可向其提交數(shù)據(jù)。對應(yīng)快箱的是慢箱 Delayer Inbox，其功能在后續(xù)流程中會有描述。
Validator 會一直監(jiān)聽 SequencerInbox 合約，每當(dāng)排序器向該合約發(fā)布 Batch 后，就會拋出一個鏈上事件，Validator 監(jiān)聽到這個事件發(fā)生后，就會去下載 batch 數(shù)據(jù)，在本地執(zhí)?后，向 ETH 鏈上的 Rollup 協(xié)議合約發(fā)布 RBlock 。?
Arbitrum 的 bridge 合約內(nèi)有個叫累加器 accumulator 的參數(shù)，會針對新提交的 L2 batch，以及慢 Inbox 上新接收的交易數(shù)和信息，進(jìn)行記錄。
（排序器向 SequencerInbox 不斷提交 batch）
（Batch 的具體信息，data 字段對應(yīng)著 Batch 數(shù)據(jù)，這部分?jǐn)?shù)據(jù)尺寸很大，截圖沒顯示完）
SequencerInbox 合約有兩個主要函數(shù)：
add Sequencer L2Batch From Origin()，排序器每次都會調(diào)用該函數(shù)向 Sequencer Inox 合約提交 Batch 數(shù)據(jù)。
force Inclusion()，該函數(shù)任何人都可以調(diào)用，用于實(shí)現(xiàn)抗審查交易。這個函數(shù)的生效方式，會在后面談到 Delayed Inbox 合約時詳細(xì)解釋。
上述兩個函數(shù)都會調(diào)用 bridge.enqueueSequencerMessage()，來更新 bridge 合約內(nèi)的累加器參數(shù) accumulator。
Gas 定價
顯然，L2 的交易不可能免費(fèi)，因?yàn)檫@樣會引來 DoS 攻擊，另外則是排序器 L2 本身的運(yùn)?成本，以及在 L1 上提交數(shù)據(jù)都會有開銷。?戶在 Layer2 網(wǎng)絡(luò)內(nèi)發(fā)起交易時，gas 費(fèi)的結(jié)構(gòu)如下：?
占用 Layer1 資源產(chǎn)生的數(shù)據(jù)發(fā)布成本，主要來自于排序器提交的 batch（每個 batch 有很多用戶的交易），成本最終由交易發(fā)起者們均攤。數(shù)據(jù)發(fā)布產(chǎn)生的手續(xù)費(fèi)定價算法是動態(tài)的，排序器會根據(jù)近期的盈虧狀況、batch ??、當(dāng)前以太坊 gas 價格進(jìn)?定價。
用戶因占用 Layer2 資源產(chǎn)生的成本，設(shè)定了?個可以保證系統(tǒng)穩(wěn)定運(yùn)?的，每秒處理的 gas 上限（?前 Arbitrum One 是 700 萬）。L1 和 L2 的 gas 指導(dǎo)價格均由 ArbOS 跟蹤并調(diào)整，公式暫時不在此贅述。
雖然具體的 gas 價格計(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 上并對其進(jìn)行樂觀式證明的一套系統(tǒng)。
在 L1 上有排序器發(fā)布的輸?數(shù)據(jù)，也有驗(yàn)證者發(fā)布的輸出狀態(tài)。我們再仔細(xì)考量?下，是否有必要向鏈上發(fā)布 Layer2 的狀態(tài)呢？
因?yàn)檩?已經(jīng)完全決定了輸出，而輸入數(shù)據(jù)是公開可見的，再提交輸出結(jié)果 - 狀態(tài)似乎是多余的？但這種想法忽略了 L1-L2 兩個系統(tǒng)之間實(shí)際上需要狀態(tài)結(jié)算，也即 L2 向 L1 ?向的提現(xiàn)?為，需要有對狀態(tài)的證明。?
在搭建 Rollup 的時候，?條最核?的思想就是把?部分運(yùn)算和存儲放到 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 賬戶中或完成其他事情。
此時 Layer1 的合約就會問：你在 Layer2 上的狀態(tài)是怎樣的，怎么證明你真的擁有這些聲明要跨走的資產(chǎn)。這個時候用戶要給出對應(yīng)該的 Merkle Proof 等。
所以，如果我們構(gòu)建?條沒有提現(xiàn)功能的 Rollup，理論上不向 L1 進(jìn)?狀態(tài)同步是可以的，也不需要欺詐證明等狀態(tài)證明系統(tǒng)（雖然可能帶來其他問題）。但在現(xiàn)實(shí)應(yīng)?中，這顯然是不可?的。?
所謂的樂觀式證明中，合約不會去檢查提交到 L1 的輸出狀態(tài)是否正確，樂觀地認(rèn)為一切都是準(zhǔn)確無誤的。樂觀證明系統(tǒng)會假設(shè)，在任意時刻都有?少?名誠實(shí)的 Validator，如果出現(xiàn)錯誤的狀態(tài)，則通過欺詐證明進(jìn)?挑戰(zhàn)。
這么設(shè)計(jì)的好處是，不需要主動驗(yàn)證每?個發(fā)布到 L1 上的 RBlock，避免浪費(fèi) gas。實(shí)際上對于 OPR ??，對每?個斷?進(jìn)?驗(yàn)證也是不現(xiàn)實(shí)的，因?yàn)槊總€ Rblock 都包含著一或多個 L2 區(qū)塊，要在 L1 上去對每筆交易重新執(zhí)??遍，與直接在 L1 上執(zhí)行 L2 交易無異，這就失去了 Layer2 擴(kuò)容的意義。
? ZKR 不存在這個問題，因?yàn)?ZK Proof 有簡潔性，只需要驗(yàn)證?個很?的 Proof，不需要真地去執(zhí)?該 Proof 背后所對應(yīng)的許多條交易。所以 ZKR 并不是樂觀式運(yùn)?，每次發(fā)布狀態(tài)都會有 Verfier 合約進(jìn)?數(shù)學(xué)驗(yàn)證。
欺詐證明雖然不能像零知識證明那樣具有?度的簡潔性，但 Arbitrum 使?了?種「多輪分割 - 單步證明」的輪流式交互流程，最終需要證明的僅僅是單?的虛擬機(jī)操作碼，成本相對較?。
Rollup 協(xié)議
我們先來看一下，發(fā)起挑戰(zhàn)和啟動證明的入口，也即 Rollup 協(xié)議是如何工作的。
Rollup 協(xié)議的核心合約是 RollupProxy.sol，在保證數(shù)據(jù)結(jié)構(gòu)一致的情況下，使用了一個罕見的雙重代理結(jié)構(gòu)，一個代理對應(yīng)兩個實(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 中包含了自上一個 RBlock 以來，一個或多個 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) / 欺詐證明時，輸者的質(zhì)押品將被罰沒，這是保障驗(yàn)證者誠實(shí)行為的經(jīng)濟(jì)學(xué)基礎(chǔ)。
圖中右下角的 111 號藍(lán)色塊最終會被證偽，因?yàn)槠涓笁K 104 號區(qū)塊是錯誤的（黃色）。
此外，驗(yàn)證者 A 提出了 106 號 Rollup Block，而 B 不同意，對其進(jìn)行挑戰(zhàn)。
在 B 發(fā)起挑戰(zhàn)后，ChallengeManager 合約負(fù)責(zé)驗(yàn)證對挑戰(zhàn)步驟的細(xì)分過程：
1.細(xì)分是一個雙方輪流互動的過程，一方對某個 Rollup Block 中包含的歷史數(shù)據(jù)進(jìn)行分段，另一方指出是哪部分?jǐn)?shù)據(jù)片段有問題。類似于二分法（實(shí)際是 N/K）不斷漸進(jìn)縮小范圍的一個過程。
2.之后，可以繼續(xù)定位至哪條交易及結(jié)果有問題，再進(jìn)一步細(xì)分至該交易中有爭議的某條機(jī)器指令。
3.ChallengeManager 合約只檢查對原始數(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é)果有問題。
單步證明
單步證明是整個 Arbitrum 的欺詐證明的核心。我們看一下單步證明具體證明的是什么內(nèi)容。
這需要先理解 WAVM，Wasm Arbitrum Virtual Machine，它是一個由 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)證者生成欺詐證明時使用的 WAVM，而驗(yàn)證單步證明的合約上，模擬的也是 WAVM 虛擬機(jī)的功能。
那為什么在生成欺詐證明時，要編譯為 Wasm 字節(jié)碼？主要還是因?yàn)?，?yàn)證單步欺詐證明的合約，要用以太坊智能合約模擬出 能處理某套指令集的虛擬機(jī) VM，而 WASM 易于在合約上實(shí)現(xiàn)模擬。
但 WASM 相比于 Native 機(jī)器代碼，運(yùn)行速度略慢，所以只有在欺詐證明生成及驗(yàn)證的時候，Arbitrum 的節(jié)點(diǎn) / 合約才會用到 WAVM。
在之前的多輪互動細(xì)分后，單步證明最終證明的是 WAVM 指令集中的單步指令。
下面的代碼中可以看到，OneStepProofEntry 首先要判定，待證明指令的操作碼屬于哪個類別，再調(diào)用相應(yīng)的 prover 如 Mem，Math 等，將單步指令傳入該 prover 合約。
最終結(jié)果 afterHash 會回到 ChallengeManager，如果該哈希與 Rollup Block 上記錄的，指令運(yùn)算后的哈希不一致，則挑戰(zhàn)成功。如果一致，則說明 Rollup Block 上記錄的這個指令運(yùn)行結(jié)果沒問題，挑戰(zhàn)失敗。
????
在下一篇文章中，我們將解析 Arbitrum 乃至于 Layer2 與 Layer1 之間處理跨鏈消息 / 橋接功能 的合約模塊，并進(jìn)一步闡明，一個真正意義的 Layer2 應(yīng)該怎么實(shí)現(xiàn)抗審查。
