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

2023-05-24 12:47 TheSeeDAO


原文作者:ORFEO

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 。

Rollup 1.0 

Rollup 1.0 包含 3 個要點:

  • 有一個服務商(Operator),專門收集大家的「拼車」交易(Transaction),拼滿了,或者沒滿但約定時間到了就「派單」,兼顧價格和時效;

  • 大家提交的交易中涉及的所有計算都由這個服務商在鏈下進行,因爲鏈下計算比鏈上快,而且計算往往是鏈上成本中的大頭,這樣可以省不少錢;

  • 計算完後,得到更新後的狀態(比如大家账戶裏的最新余額),上鏈存儲,這樣一來存儲成本低了很多。

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

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

  • 動機問題(Incentive):誰來提供「拼車」服務,有什么好處。

  • 審查問題(Censorship):服務商故意不處理我的單(或者掛了、不幹了),我該怎么辦;

  • 欺詐問題(Fraud):如果服務商使詐,篡改計算結果,導致我給別人轉账,錢被他私吞了該怎么辦。

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

Rollup 2.0 

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

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

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

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

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

Rollup 3.0 

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

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

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

Rollup 4.0 

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

  • 給服務商的費用(包含成本和「小費」);

  • 交易、狀態數據的鏈上存儲成本;

  • 「賞金獵人」認爲服務商欺詐時,鏈上驗證其所言非虛的計算成本。

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

交易數據

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

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

來源:https://vitalik.ca/general/2021/01/05/rollup.html

就這么三兩下,每條 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 很難,或者即便能實現,但在其他方面(比如驗證效率)又會受到影響。

來源:https://medium.com/minaprotocol/meet-pickles-snark-enabling-smart-contract-on-coda-protocol-7 ede 3 b 54 c 250 

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

來源:https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-e d5 e 48842 fbf

寫在最後

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

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

鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播信息之目的,不構成任何投資建議,如有侵權行為,請第一時間聯絡我們修改或刪除,多謝。

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

地址:https://www.sgitmedia.com/article/847.html

相關閱讀: