什么是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交易的生命周期

1. 用戶向排序器發送交易指令。

2. 排序器先對待處理交易進數字簽名等數據的驗證，剔除無效交易，并進行排序和運算。

3. 排序器將交易回執發送給?戶（通常都??？欤?，但這只是排序器在 ETH 鏈下進行的「預處理」，處于 Soft Finality 的狀態，并不可靠。但對于信任排序器的?戶（大部分用戶），可以樂觀的認為交易已經完成，不會被回滾。

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

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

未完待續