一文探討Rollup擴容方案的演進思路和設計緣由

原文作者：ORFEO

原文來源：The SeeDAO

L2 項目再次成為萬眾焦點。

作為L2 中Rollup 擴容路線的代表，前腳Arbitrum 空投完，後腳zkSync Era 就上線了。層出不窮的新設計、路線圖背後，Rollup 到底有一條什麼主線，演進的思路是怎樣的，今天就來理一理。

本文要點：

• 寫給三年級看的L1 的擴容思路
• 從零設計一個Rollup 方案
• 如何用零知識證明讓Rollup 再進化

從一個類比說起

對比特幣、以太坊而言，自誕生起，來自普通用戶的最大詬病有二：

• 慢：本來就車道窄，車稍微一多就堵得水洩不通。
• 貴：平峰過路費就不便宜，要遇到高峰期想快點過，更是要使用「鈔能力」，加錢讓礦工開直升機來撈你。

這倆詬病之處，分別源於區塊鏈設計上的2 個因素：

• 區塊容量：類比車道，區塊容量越大，能容納的車就越多，就越不容易堵。
• 激勵機制：再大的車道，都有堵的可能，這種時候讓誰先過呢，看誰有急事，但不能光聽人嘴上說，得看掏錢意願，比如叫救護車一趟就要好幾百。

要是區塊鏈真可以類似車道，那麼治本之策自然是奔著拓寬車道去，同時配合價格手段來在出門時間上進行疏導，不急的就先別出門了。

然而，拓寬車道，提升區塊容量，雖然是個誘人的通行效率解決方案，但在區塊鏈設計上，卻是捨本逐末了。因為區塊容量越大，對礦工的硬件要求就越高，能達到要求的礦工就越少；按這種思路，要想做到像Visa 那樣每秒處理成千上萬條交易，最終只會做出另一個中心化的Visa，與區塊鏈去信任的核心目的南轅北轍。

那還有其他解法嗎？有的，除了在時間上疏導，我們在空間上也可以優化，包括但不限於：

• 開闢不同車道，大貨車走一條，小轎車走一條，公交車走一條，互不干擾 — — 基於這個思路，我們可以來些各有所長的主鏈、側鍊或Plasma。
• 優化路線設計，適當分流，別進城干點啥都要走這條主幹道，都要過這裡的檢查站了 — — 基於這個思路，我們可以分片（Sharding）。
• 幹嘛一定要出門呢？遠程開會，達成一致了，線下簽協議再出門也不遲 — — 基於這個思路，我們可以有狀態通道（State Channel）。
• 大家出門不一定都得自己開車，也可以拼車，或乘坐公共交通工具 — — 基於這個思路，我們就有了本文的主角，Rollup。

作為區塊鏈上的公交車，Rollup 的關鍵其實就是省空間和省汽油（Gas，pun intended）：

• 省空間，從而不容易堵，而且每人分攤的過路費相比自己開車，也要少很多；
• 省汽油，從而票價親民，大家都坐得起。

這樣一來，「慢」和「貴」這兩個槽點就被Rollup 解決了。

下面我們回到區塊鏈上，看看Rollup 的具體方案。

從零設計一個Rollup;方案

與其偷看看標準答案（何況沒有），不如來點懸念，想像自己接到為以太坊設計Rollup 的任務，會怎麼做。

我們不妨從減少計算成本（省汽油）和減少存儲成本（省空間）;2 個角度出發，先提一個比較激進的方案，叫Rollup 1.0;。

匯總 1.0；

Rollup 1.0 包含3 個要點：

• 有一個服務商（Operator），專門收集大家的「拼車」交易（Transaction），拼滿了，或者沒滿但約定時間到了就「派單」，兼顧價格和時效；
• 大家提交的交易中涉及的所有計算都由這個服務商在鏈下進行，因為鏈下計算比鏈上快，而且計算往往是鏈上成本中的大頭，這樣可以省不少錢；
• 計算完後，得到更新後的狀態（比如大家賬戶裡的最新余額），上鍊存儲，這樣一來存儲成本低了很多。

簡單來說，就是定時定量收集大家的交易請求，鏈下計算後，只把計算結果固化到鏈上。

這個方案完美地解決了「慢」和「貴」這2 大痛點，但又似乎衍生了新的問題：

• 動機問題（Incentive）：誰來提供「拼車」服務，有什麼好處。
• 審查問題（Censorship）：服務商故意不處理我的單（或者掛了、不干了），我該怎麼辦；
• 欺詐問題（Fraud）：如果服務商使詐，篡改計算結果，導致我給別人轉賬，錢被他私吞了該怎麼辦。

針對這3 個新問題，我們可以迭代一版方案。

匯總 2.0；

動機問題最好解決，能用錢解決的問題都不是問題。服務商可以平攤「拼車」成本，再額外收一點「小費」，即便如此和「拼車」人之間仍然是雙贏。

審查問題稍微麻煩點，但解法在區塊鏈領域很常見，那就是去中心化。一群人都是服務商，比只有一個服務商好；任何人都能當服務商，又比固定一群人當服務商好。在後面這種玩法下，如果所有服務商都不乖，你也能自己當服務商，或者直接去L1 發起仲裁。

欺詐問題就有點難度了。它可以拆分成兩個問題 — — 一個是如何識別欺詐，另一個是如何防範欺詐。

首先，要識別欺詐，我們需要知道大家的交易（Transaction）數據，交易前的狀態（State），從而計算交易後的新狀態（State'），拿來和服務商鏈上存儲的新狀態對比，如果一樣說明服務商誠實，否則說明他撒了謊。然而，我們並不知道交易數據，因為它們沒有上鍊。這就導致我們只能將信將疑，無法判斷服務商是否誠實。

接著，防範欺詐，最好的方式就是讓欺詐不可能出現，這個比較難，除非鏈上每次都檢查一遍服務商的計算對不對，但這樣一來就沒有「拼車」的優勢了。所以我們只能退一步，讓欺詐的成本很高，讓服務商有所顧忌（have skin in the game），比如交個押金（Stake），如果發現欺詐就將其沒收。 （這種方式叫社會共識，屬於基於博弈的安全性，在《週報#3;》中亦有提及。）

匯總 3.0；

Rollup 2.0 還不錯，但識別欺詐的問題沒解決。

根據之前的推論，要識別欺詐，我們必須要知道交易數據，所以這部分數據，必須和狀態數據一樣上鍊。

那由誰來發現他們欺詐呢？很顯然，這個不大能是普通用戶，因為大家不可能7;x;24 小時監督服務商的一舉一動，所以只能是專業的「賞金獵人」（Validator）。如果服務商「派單」後的7 天內，有「賞金獵人」舉報欺詐，並且驗證屬實，那麼交易就會回滾，服務商就會受到懲罰。當然，如出一轍，「賞金獵人」也需要有激勵，比如發現欺詐後，服務商的押金將分一部分給「賞金獵人」（只會是一部分，避免服務商和賞金獵人共謀）。

匯總 4.0；

到Rollup 3.0 階段，整個方案已經能夠跑通了，但又引入了新的成本。到目前為止，成本包括：

• 給服務商的費用（包含成本和「小費」）；
• 交易、狀態數據的鏈上存儲成本；
• 「賞金獵人」認為服務商欺詐時，鏈上驗證其所言非虛的計算成本。

下面我們來看看，有哪些成本是可以優化的。

交易數據

通過特定的方式，多條交易聚合在一起，所佔的空間是可以比每條交易所佔空間的總和要小的。

以最簡單的ETH 轉賬交易為例，我們拆解下每條交易的內容構成，可以看到，簽名的空間佔比最大。我們可以將所有交易的簽名，合成一個（Key Aggregation)，這樣就省了很大一筆存儲的開銷（類比比特幣中的Schnorr）。此外其他部分我們也可以優化，比如把Nonce 甩掉，以及「拼車」的時候盡可能選擇「肥瘦相間」、嚴絲合縫的「拼車人」，最大限度地利用「車內」空間。

來源：

就這麼三兩下，每條ETH 轉賬交易的大小就由112 字節，縮減為12 字節，接近以前的十分之一；當然，還有其他手段，可以進一步壓縮交易數據。

在實際操作中，我們可以在鏈上部署的合約裡，安插這麼一個方法：

function storeTxData(bytes calldata data) external {;// 啥事兒不干}

然後每次「拼車」成功後，把合併壓縮後的交易數據，作為calldata 傳入這個方法。 calldata 不需要永久保存，社會共識的公示挑戰期（Challenge Period）過後，被剪枝（Prune）也不會有所謂；本身價格很低，而且之後隨著Danksharding、Data Blob 等EIP 落地，會更便宜，這種將L1 應用於數據存儲分發（Data Availability）的形式也會更正式。

狀態數據

既然交易數據已經上鍊，那任何人都可以通過交易數據來計算更新後的狀態了，狀態數據就沒那麼大必要了。我們可以只保留狀態數據的Merkel Root，用於在服務商不配合時，讓普通用戶（「拼車人」）可以直接向L1 申請提款，靠Merkel Proof 證明自己賬上有錢。

欺詐仲裁成本

當「賞金獵人」舉報服務商說有欺詐時，鏈上合約計算（Replay）一次，對比狀態結果，這理論上固然可行。但是，這樣做一是成本不低（雖然已經不錯了），二是Rollup 「拼車單」包含的交易的Gas 總和可能超過了以太坊的Gas 上限，致使無法驗證。

所以仲裁需要減負，減負的方式自然也是把不必要的計算操作放到鏈下進行。其中一種解法叫交互式證明（Interactive Proving），大致過程如下：

• 「賞金獵人」交押金，然後舉報，並將整個計算過程按順序拆分成n 段，指出服務商在第k 段（1;≤k≤n）有欺詐；
• 服務商將第k 段再下鑽、拆解為k 段，並指出「賞金獵人」在哪一段算得不對；
• 如此往復，知道計算操作再也不可下鑽、拆解，比如拆到「賞金獵人」認為1+;1;=;2;，服務商認為1+;1;=;3;；
• 這時，鏈上合約介入，計算1+;1;，得出2;，從而判定服務商欺詐，沒收其押金，並將一部分獎勵給「賞金獵人」。

（整個過程中，若某一方超時未回复，則這一方失敗。）

這樣一來，整個鏈上仲裁成本就非常非常低了。

說到這裡，我們便完整地構建了一個Rollup 方案。因為這種方案默認假定服務商是誠實的，除非有「賞金獵人」舉報，所以這一派別叫做樂觀主義者的Rollup，所謂Optimistic Rollup。

那麼，我們的Rollup 4.0;，就是最優的方案了嗎？

Rollup 再進化

經過我們的多輪迭代，Rollup 4.0 依然有些不完美的地方：

• 欺詐需要有「賞金獵人」來發現，但如果長時間沒有欺詐，「賞金獵人」可能因為無利可圖就都歇業了，於是缺口就有了（儘管不大可能，因為Rollup 鏈的應用商等相關利益方大概率會作為「賞金獵人」）；
• 要確信沒有欺詐，基於社會共識，需要等待好幾天，影響提款等操作；
• 上鍊的數據挺多的，成本還是有；
• 目前靠一層Rollup 擴容，吞吐量可能也就提升10 倍，有沒有可能更高些呢？

有沒有一種方案，能讓欺詐根本無從實施，讓最終性（Finality）更快，讓需要上鍊的數據更少，讓擴容更上一個量級呢？想要的簡直不要太多，但還真有這樣一類幾乎能滿足一切想像的方案 — — Zero Knowledge Rollup（簡稱ZK-Rollup）。

ZK-Rollup 是一種採用零知識證明（ZKP）的Rollup 思路。所謂ZKP，指的是在不透露任何敏感信息的前提下，讓對方確信你知曉這一信息的技術。解釋ZKP，我最喜歡的比方有2 個：

• 想像在中世紀的歐洲城鎮，我有一份藏寶圖，上面標記了一處寶藏。為了向你證明我有藏寶圖，但是又不讓你知道寶藏的確切位置，我給你戴上眼罩，把你拽上馬車，才城鎮裡彎彎繞繞半小時，確保你喪失方向感，最後到達目的地，下車給你看一眼寶藏，再把你彎彎繞繞帶回去。這便是ZKP 的一種樸素形式。
• 另一個比方比較常見。假設有一個數獨難題，我知道答案而你不知，但你不相信我知道；我想向你證明我知道，但我又不想讓你知道答案。怎麼辦？我可以把數獨在桌上用卡片擺出來，然後把公開的數字朝上，需要填寫的數字朝下，讓你選擇按行還是按列來檢查我的答案。如果按行，我就將每一行的數字歸在一起，打散，給你看每一行都是1 到9;。重複幾次，都沒問題，這樣你就能相信我極大概率是真知道答案的。這是ZKP 的其中一種交互式證明方式（區塊鏈因為很難做到即時的鏈上交互，所以一般採用非交互式證明，靠Hash 函數來產生隨機挑戰）。

用不夠嚴謹的話來講，ZKP 的核心思路是證明方（Prover）先把秘密知識藏好，「買定離手」（Commit），然後由驗證方（Verifier）發起隨機挑戰（Challenge），如果證明方能成功通過挑戰，那麼大概率他有相應的秘密知識。

ZKP 要滿足3 個要求：

• 如果證明方說謊就極大概率不能通過挑戰（Soundness）；
• 如果證明方有知識就一定能通過挑戰（Completeness）；
• 雙方的交互過程中，證明方不會洩露任何有用信息（Zero-knowledgeness）。

為了滿足這3 個要求，ZKP 利用了多種多樣的NP 難題，包括最簡單的質數分解，以及離散對數（如Schnorr 就是）等。

ZKP 並不是為區塊鏈而生的技術，但是恰好可以用於L2 擴容，這主要是因為一個好的ZKP 有以下有用的特性：

• 證明者（服務商）能很快地給出一個證明，從而保證鏈下計算效率很高，不會成為瓶頸；
• 證明的大小很小，或者至少和要證明的計算量成正比，受數據量的影響盡可能小，從而鏈上存儲成本低；
• 驗證者（L1 合約）能很快地驗證證明是否有效，從而鏈上計算成本低。

利用這些特性，我們的Rollup 方案可以：

• 不再需要「賞金獵人」，L1 合約自己就能當場發現是否有欺詐；
• 只要ZKP 驗證有效，馬上就能提款，最終性從天級縮短到分鐘級；
• 只需要狀態之間的diff 上鍊，空間很小，存儲成本很低（一個額外的bonus — — 隱私性也提升了）；
• 通過對證明和驗證過程進行定制的軟硬件優化，擴容能力可以再提升一個量級。

當然，任何安全機制都會有潛在的前提條件，ZKP 也不是區塊鏈的萬能藥。 ZKP 目前還有不少局限性，需要逐步去克服，比如：

• 拿區塊鏈上應用最普遍的zk-SNARK 來說，不少方案需要在一開始引入盡可能多的有聲望的人或公司，做一個Trusted Setup，來生成一個真正的隨機數，並保證生成過程可驗證但不完全公開（比如在Power of Tau 儀式中，只要有一方可信就行，但仍然算是瑕疵）。當然，一些新的zk-SNARK 方案，以及後面改進的zk-STARK 可以解決這個問題，但有時又會引入新的問題。
• 很多問題很難歸納為ZKP 問題來表述，這也導致以前很長時間，可編程性都沒有得到很好的解決，要在以太坊上實現完全兼容EVM 的ZKP 很難，或者即便能實現，但在其他方面（比如驗證效率）又會受到影響。

來源：

這也是為什麼，在ZK-Rollup 這一面向未來的擴容領域中，每次進步，都難能可貴，可喜可賀。

來源：

寫在最後

就擴容的未來而言，筆者認為，與L1 的原生擴容相比，包括Rollup 在內的分層設計是更為可靠的思路。模塊化，每層解決每層的關切，比在已是「鐵板一塊」（monolithic）的L1 上不斷堆疊，風險更小；而且，底層L1 因擴容而損失的去中心化，理論上不大可能在上層找補回來。況且這種分層設計的思路，在區塊鏈以外的領域，也有看似成功的應用。觀點不一定對，但這是筆者目前的認知。

本文嘗試以一種無關特定項目（project-agnostic）的口吻，梳理了Rollup 擴容方案中的思考脈絡和設計緣由。由於水平有限，有些地方還是略顯生硬，可能不僅未解釋到位，反而徒增了理解難度；作為日新月異的一個垂直領域，很多新的發展筆者可能也未能及時知曉和考慮進來。真誠歡迎朋友們指正，交流。