什麼是Rollup？
以太坊的Rollup擴容是一種Layer 2（第二層）擴容解決方案，旨在提高以太坊區塊鏈的交易吞吐量和效能。它透過將大量的交易資料轉移到以太坊區塊鏈之外的第二層網路來實現這一目標。
Rollup的核心思想是將交易資料彙總到k個稱為Rollup鏈的智慧合約中，然後將這些彙總資料提交到以太坊主鏈上進行驗證。這樣做的好處是，Rollup鏈可以處理大量的交易，並將結果提交到以太坊主鏈上進行最終的驗證和確認，從而減輕了主鏈的負擔。
目前有兩種主流的rollup,一種是arbitrum所屬的op rollup（樂觀rollup，下面簡稱op），一種是zk rollup（基於零知識證明的rollup,下面簡稱zk）.
這兩者的區別主要在於以太坊驗證rollup交易的方式不同。
對於 op rollup,它的原型是 -- 我們預設的認為在L2上發生的交易是沒問題，在預設情況下，以太坊不驗證rollup的交易。當然，這裡只是以太坊不驗證，op方案存在鏈下的驗證人，所以op 的交易一般都有一個供驗證者驗證的視窗期。
而zk rollup則與之相反，zk悲觀的認為L2上的每一筆交易都是不可信的，每一筆交易都必須在以太坊原鏈上驗證。而零知識證明在這裡的作用就是，減少驗證過程中的gas消耗。比如我們在L2上有一個合約執行的交易，如果L1需要驗證L2的交易，我們不能把交易再放到L1上執行一次（一方面這會有很多L1,L2上的對映問題，另一方面，如果驗證的時候需要再執行一遍，那我為什麼不直接在L1上執行）。零知識證明做到的就是，我們在L2上做了一個複雜的操作（例如一個合約執行），我們可以為這個操作生成一個零知識證明（這裡給出我的一個猜測，例如L2為一個提現操作生成了一個零知識證明 p,將p傳送至L1,L1上的合約存在驗證邏輯，他可以驗證當且僅當L2上確實發生了對應的銷燬操作，這個證明才可能被構造出來），L1上只需要驗證這個證明。
在正式開始之前需要先澄清一點：
rollup並不是去執行L1上的交易，你不可能在L2上執行一個L1的合約，L2是獨立於L1而存在的（在資料上來看），L2不主動擁有L1上的任何資料，他只是借用L1提供的去信任機制，L2將自己的資料，高度壓縮/轉換為Kz然後儲存在L1上，實際上L1完全看不懂L2傳過來的資料是什麼意思，而他將資料儲存在L1上是為了證明，在任何時候，你都可以透過L1上的這些資料還原L2的狀態，從而來確保L2上資料的去信任化。
aribtrum介紹
aribtrum結構
那麼我們回到arbitrum的 op rollup，我們先看一下arbitrum的整體架構圖：
我們將aribtrum分成三個（四個）部分。第一部分是兩個紅色框裡面的 排序器 sequencer，第二部分是綠色框中的 驗證者 validator，第三部分是在L1中的藍色框裡面的rollup 合約，以及第四部分沒有畫框的資產橋（資產橋不影響aribtrum的主要邏輯，可以看作是aribtrum的增值服務，不過對於公鏈，資產橋是核心業務)
先來看一下排序器：
排序器的主要功能是將L2上的大量交易排序並打包，傳送至L1裡面的 sequencer inbox 合約（airbitum稱之為快箱）
排序器主要對接使用者的請求，接受使用者請求，排序，執行，返回結果，排序起中一批交易一般會在0-2s內被執行（aribtrum邏輯與以太坊相似，這裡的執行實際上是落快，但是排序器落快不代表最終結果，他只是因為基於以太坊，所以才有落塊這個操作，實際上後面會談到的Rblock更加貼近區塊鏈的概念），並迅速返回結果給使用者，響應速度幾乎匹及web2平臺。
排序器會週期性的向L2上的其他節點廣播區塊。另外，排序器通常會每隔幾分種將這段時間內收集到的區塊進行一個壓縮（使用谷歌的一個壓縮率還可以的演算法做的壓縮，這裡的壓縮的唯一目的是減少L1上的gas消耗）打包成一個batch儲存在sequencerInbox合約中。
從以上流程中我們可以概括：Layer2 有自己的節點網路，但這些節點數量稀少，且一般沒有公鏈慣用的共識協議，所以安全性是很差的，必須要依附於以太坊來保證，資料釋出的可靠性與狀態轉換的有效性。
排序器實際上不參與rollup的過程，他是一個快速執行交易，打包的工具，實際上arbitrum可以不依靠排序起執行，使用者可以直接把交易傳送給rebitrun one 節點。
Arbitrum Rollup 協議：
定義 Rollup 鏈的區塊 RBlock 的結構，鏈的延續方式，RBlock 的釋出，以及挑戰模式流程等⼀系列的合約。注意，這裡說的 Rollup 鏈並不是大家理解的 Layer2 賬本，而是 Arbitrum One 為了施展欺詐證明機制，而獨立設定的一條抽象出來的「鏈狀資料結構」。
⼀個 RBlock 可以包含多個 L2 區塊的結果，⽽且資料也迥異，它的資料實體 RBlock 儲存在 RollupCore 的⼀系列合約中。如果⼀個 RBlock 存在問題，Validator 將⾯向該 RBlock 的提交者對其進⾏挑戰。
驗證者 validator
Arbitrum 的驗證者節點其實是 Layer2 全節點的特殊子集，目前有白名單准入。
validator是arbitrum中產生rbolck的主體，驗證者節點會監聽鏈上的dequencerInbox合約，下載排序器打包的batch來建立Rblock.同時監聽以太坊上的rollup合約，驗證其他節點提交的rblock,向異常rblock發起挑戰。
挑戰：
基礎步驟可以概括為多輪互動式細分、單步證明。在細分環節，挑戰雙⽅先對有問題的交易資料進行多輪迴合制細分，直至分解出有問題的那⼀步操作碼指令，並進行驗證。「多輪細分-單步證明」這種正規化，被 Arbitrum 開發者認為是欺詐證明中最節省 gas 的實現方式。所有環節都在合約控制之下，沒有⼀方可以作弊。
挑戰期：
由於 OP Rollup 的樂觀 optimistic 本質，每個 RBlock 提交上鍊後，合約並不主動檢查，預留給驗證者一段時間窗摳期去證偽。此時間視窗即為挑戰期，在 Arbitrum One 主網上為 1 周。挑戰期結束後，該 RBlock 才會被最終確認，塊內對應的從 L2 傳遞到 L1 的訊息（比如透過官方橋執行的提款操作）才能被放行。
挑戰的原理等後面講ArbOs的WAVM時一起講
L2交易的生命週期
-
使用者向排序器傳送交易指令。
-
排序器先對待處理交易進數字簽名等資料的驗證，剔除無效交易，並進行排序和運算。
-
排序器將交易回執傳送給⽤戶（通常都⾮常快），但這只是排序器在 ETH 鏈下進行的「預處理」，處於 Soft Finality 的狀態，並不可靠。但對於信任排序器的⽤戶（大部分使用者），可以樂觀的認為交易已經完成，不會被回滾。
-
排序器將預處理後的交易原始資料，⾼度壓縮後封裝為⼀個 Batch（批次）。
-
每隔⼀段時間（受到資料量、ETH 擁堵程度等因素影響），排序器會向 L1 上的 Sequencer Inbox 合約釋出交易 Batch。此時可認為，交易已擁有最終性 Hard Finality。