Rollup最大的信任風險:無法忽視的“人治”問題

2023-07-24 14:54 極客 Web3


作者:林克,《極客Web3》

導語:自Solana逐步衰落和OP發行Token以來,Layer2和Rollup似乎成爲了無數Web3從業者新的港灣。隨着熊市的持續蔓延和FTX暴雷出局、Multicoin損失慘重,以太坊的競爭對手們陸續淡出了Web3這個大舞台,不斷失去了和ETH一較高下的底氣。越來越多的人开始將Rollup視爲新一輪敘事核心,越來越多的項目如同雨後春筍般在L2上扎堆湧現。

但這一切是否是“虛假的繁榮”,是否是“隨時可能被戳破的泡沫”?Rollup和L2真的如同大多數人所鼓吹的那般美好嗎?它真的像人們所認知的那樣安全嗎?且不談許多OP Rollup沒有欺詐證明,Rollup的安全隱患還有哪些?

本文受到L2BEAT近期發布的“Upgradeability of Ethereum L2s”啓發,針對Rollup升級背後的多籤與委員會信任風險(立即升級Rollup合約,卷走用戶資產)及此前關於Rollup的老生常談,聯想到前不久的Multichain,綜合聊下L2爲何不像許多人所想的那么“美好”。

Rollup原理簡述

Rollup運作原理簡述:

以太坊Rollup = Layer1上的一組合約 + Layer2網絡自己的節點。

Layer2網絡節點這個群體可以拆分出幾類角色,其中最重要的當屬定序器(Sequencer)。它接收Layer2上發生的交易請求,決定它們的執行次序,然後把交易序列打包爲批次(Batch),傳送給Rollup項目在Layer1上的合約(下文中將統稱爲Rollup合約)。

Layer2的全節點可以直接從定序器處獲取交易序列,也可以讀取定序器發到Layer1上的交易批次(Batch),但後者具備比前者更高的最終確定性(不可更改性)。通常,當一批交易被定序器傳送到Layer1上後,這批交易的次序便不可變更(只要以太坊不發生區塊回滾,Rollup的交易序列就不會變更)。

由於交易執行會更改區塊鏈账本的狀態,所以除了交易次序外,Layer2全節點還需要和定序器同步账本狀態,這樣才能保證一致性。

因此,定序器不光要往Layer1的Rollup合約傳送交易批次,還要把交易執行後的狀態更新結果(Stateroot/State diff)傳送至Layer1。

不難看出,L1(以太坊)實際上充當了L2節點們的公告板,它要遠比L2自己的網絡更去中心化、更Trustless、更安全。對L2的全節點而言,只要獲取了L1上的Rollup交易序列 + 最开始的Stateroot,就可以還原出L2的區塊鏈账本,計算得出最新的Stateroot。如果L2全節點自己算出的Stateroot和定序器發布到L1的Stateroot不一致,就說明定序器存在欺詐行爲

最直觀的假想案例是:L2的定序器可不可以盜取用戶資產。比如,它可不可以僞造一些本不該發生的交易(ps:把某些L2用戶的Token轉移至定序器運行者的地址,然後再把這些Token轉移到L1上)。這類問題可以歸結爲:定序器發布了錯誤的交易數據或錯誤的Stateroot後,該怎么辦?

針對定序器的欺詐風險,不同類型的Rollup有不同的應對措施。Optimistic Rollup(樂觀Rollup)允許L2全節點提供欺詐證明(Fraud Proof),證明定序器在L1發布的數據存在錯誤。比如Arbitrum設置了一個節點白名單,允許白名單上的L2節點發布欺詐證明。

除此之外,考慮到大多數交易所和私營跨鏈橋項目方都會運行L2全節點,可以立即發現錯誤,大多數Rollup定序器盜幣的成功率基本爲0(因爲它最後要套現,還是要在交易所完成,或者把盜來的幣轉移至L1後再另謀出路)。

(圖中的Aggregator實際就是定序器)

但對於沒有欺詐證明的Optimism,定序器可以通過Rollup自己的跨鏈橋bridge合約來盜幣。比如,定序器運行者可以僞造交易指令,將其他人在L2的資產轉移至自己的地址,再通過Rollup自帶的bridge合約,把盜來的幣轉移至L1。因爲沒有欺詐證明,OP的全節點無法對錯誤交易發起挑战,所以理論上,OP的定序器可以盜取用戶在L2的資產(只要它真的想這么做)。

解決這種問題的方法是“社會共識”(靠社區成員和社交媒體等輿論監督),或者靠OP官方的信用背書。

有趣的是,近期某交易所降低了Arbitrum 和 Optimism 用戶向所內轉幣的延時(從100個L2區塊降低到1個L2區塊),這其實是信任ARB和OP的定序器不會作惡(默認它們是有官方背書的中心化服務器)

不同於樂觀Rollup,除了依靠L2全節點外,ZK Rollup通過有效性證明Validity Proof(往往與ZK Proof相混淆)解決定序器欺詐問題。ZK Rollup網絡裏有一種稱爲Prover的節點,專爲定序器發布的交易批次Batch生成有效性證明。同時,L1上有專門驗證有效性證明的合約(一般稱爲Verifier),只要交易批次及Stateroot/State diff對應的證明通過Verifier合約的驗證,便被最終確認(Finalized)。ZK Rollup的官方bridge只會給通過有效性證明驗證的提款交易放行,顯然這要比Optimism可靠太多。

理論上來說,OP Rollup的安全性靠L2全節點來保證(至少要有1個能發布欺詐證明的誠實節點)。ZK Rollup的安全由L1上的Verifier合約保證(由L1節點完成交易最終確認)。表面上看,它們都可以“繼承L1的安全性”(借助L1完成交易的最終確認/結算),以太坊最大主義者甚至將其稱作“等價於L1的安全性”(與L1的交易結果最終性一致),但實際情況卻並非如此,甚至是遠非如此。

那些“老生常談”的點

首先,ZK Rollup的有效性證明生成速度極爲緩慢,定序器可以在1秒內執行幾千筆交易,但爲這幾千筆交易生成Proof最多可能要幾小時。但這個問題也容易解決,主流的ZKR基本都會通過切分Proof生成任務、交由不同的Prover節點並行處理的方式,大幅提高Proof生成速度。

其次,要考慮L2節點在L1發布數據的延遲。因爲定序器或Prover每次往L1發送數據,都會有一個固定成本(就好比每次運貨都要消耗一個集裝箱)。頻繁在L1上發布數據是不劃算甚至虧本的,所以定序器和Prover會盡量減少在L1上發布數據的頻率,等一次性湊夠了大量的數據再打包發布。

換言之,當用戶數量不足、發起的交易筆數不夠多時,定序器會延遲向L1發布數據。比如在去年用戶較少時,Optimism半小時才向L1發送一次交易批次。現在,因爲用戶多了起來,這個問題得到了有效解決。與OP不同的是,Starknet採用了減少State diff發布頻率的方式降低數據成本,這使得Starknet的交易最終確認延時被拉長到了7~8小時。

除此之外,多數ZK Rollup爲了進一步降低成本,往往會“聚合許多個Proof,再一次性發到L1上”。也就是說,Prover不會在生成一個Proof後就立刻發到L1,而是等多個Proof都生成完,聚合在一起,再發給L1的Verifier合約。(其實聚合Proof的過程,就是用一個Proof來包含掉驗證多個Proof產生的計算步驟)

這樣做的後果是,Proof的發布頻率進一步降低了,交易從發起到最終確認的延時進一步拉長了。

根據區塊瀏覽器顯示,Polygon ZKEVM的交易確認延時大概是30~50分鐘,Starknet和Zksync Era在7小時以上。顯然這只是“部分繼承L1的安全性”,與以太坊支持者們所說的“等價於L1的安全性”有很遙遠的距離。

當然,以上問題都可以靠技術進步來解決,在不久的未來實現。比如很多項目方在研發高性能硬件,降低有效性證明的生成時間;Optimism也承諾將很快發布欺詐證明系統;以太坊的Danksharding方案將把Rollup的數據成本降低幾十倍甚至更高,這可以有效解決上面羅列的問題。

難以解決的“人治”問題

與Defi等應用類項目一樣,Rollup網絡的運轉需要依靠L1上的相關合約,而這些合約是“可升級”的,也就是說部分代碼可以更換(大多數Rollup都用了代理合約),並且可以在多籤或安全委員會的授權下立刻進行。先說結論:Rollup可以通過少數人控制的多籤或安全委員會,快速更改L1上的合約代碼,然後盜取用戶資產。

首先“Rollup合約爲什么需要升級”和“它是怎么升級的”。以太坊上的合約代碼在部署後,是不可更改的,但Rollup在开發過程中難免存在各種各樣的bug,可能導致錯誤的結果;同時Rollup也在頻繁的進行產品迭代,需要頻繁增加新的功能;更極端的情況下,還可能有黑客攻擊Rollup合約,所以Rollup合約需要有可升級性,這往往通過代理合約來實現。

代理合約其實是以太坊合約开發中常用的一種方法,就是將合約的數據和業務邏輯分开,分別保存在不同的合約中。數據(狀態變量)存儲在代理合約中,業務邏輯(函數)保存在邏輯合約中。代理合約(Proxy)通過delegatecall,將函數的執行過程全權委托給邏輯合約(Implementation),再把最終的結果返回給調用者(Caller)。

代理模式下的合約升級,只需要將代理合約指向新的邏輯合約(改寫代理合約裏存儲的邏輯合約的地址)。大多數Rollup項目都採用了這種給合約升級的方法,可謂簡單粗暴。

不難想到,Rollup的合約可升級其實是巨大的雷:如果升級後的合約裏包含惡意的代碼,比如把Rollup自帶的Bridge合約的提款放行條件加以修改,或者把Verifier合約判定有效性證明正確性的條件加以更改,定序器就可以盜幣(原理在前面講了)。

但問題在於,又不能不允許Rollup合約可升級,理由在前面說的很清楚。權衡之下,絕大多數Rollup會通過DAO治理、安全委員會或多籤授權,用人治的方式來決定要不要升級Rollup的合約。除此之外,還會通過時間鎖Timelock,來爲合約升級設置延時窗口期。

考慮到大多數的DAO提案都有自動化的執行流程(通過鏈上合約來實現),即便要升級合約,也要先獲取足夠多的投票,然後再經過時間鎖Timelock規定的延時(往往要經過很多天),升級合約的操作才會執行。如果有人想搞惡意的合約升級,需要通過治理攻擊的方式度過DAO治理這關(比如發生在Tornado Cash上的治理攻擊),但這樣做的成本很高,要先獲取足夠多的Token才行,正常情況下不會成功。即便治理攻擊成功了,由於有時間鎖的限制,用戶會有足夠多的時間把資產從L2撤出,Rollup官方也會有足夠多的時間採取緊急措施。

看起來時間鎖是解決惡意的合約升級的法寶。但問題在於,所謂的“Rollup官方可採取的緊急措施”,其實就是繞开DAO治理和時間鎖,通過多籤或者安全委員會授權,立即升級Rollup合約。考慮到目前主流的Rollup托管了動輒幾十億美元的用戶資產,由多籤和安全委員會來授權的“合約可立即升級”,是終極的應急措施,但也是懸在所有用戶頭頂上的達摩克利斯之劍。

顯然這是信任最大化問題:你需要信任Rollup官方不會有盜取你的資產的念頭。如果從Trustless的角度來考慮(尼克薩博的視角),所有由多籤和安全委員會控制的Rollup都是不安全的。Avalanche創始人Emin Gun Sirer和Solana創始人Anatoly、著名黑子Justin Bons都曾強調過這類問題。

哪些Rolllup被多籤/委員會操控?

根據知名L2研究機構L2 BEAT發布的報告“Upgradeability of Ethereum L2s”,及L2BEAT數據可視化網站顯示,Arbitrum、Optimism、Loopring(路印)、ZKSync Lite、ZkSync Era、Starknet、Polygon ZKEVM等主流Rollup都存在多籤或委員會授權的可升級合約,並且可以繞开時間鎖限制。

dYdX雖然有一個EOA地址可以繞开DAO治理升級合約,但受到時間鎖限制(至少有2天的延時)。Immutable X則存在14天的合約升級延時,所以,按照L2BEAT的說法,dYdX和Immutable X要比其他已上线主網的主流Rollup更Trustless。

那么該怎么降低多籤和安全委員會帶來的信任風險?答案其實和Multichain事件類似:可以歸結爲反女巫問題。必須要保證,多籤/委員會由多個不同的、無高度利益重合的、串謀風險低的實體來控制。目前看來,除了加大DAO去中心化治理的成熟度、邀請有名望有信譽的名人或機構來參與多籤/委員會以外,似乎沒有什么太好的辦法。而以上場景似乎早已在現實世界的民主政治中屢見不鮮。

當然,也可以通過時間鎖給多籤/委員會管理的合約升級行爲加以限制,但這需要針對許多因素進行權衡,因爲多籤/委員會的存在目的就是爲了快速處理一些緊急情況;同時,如果Rollup項目方在去信任化問題上沒有什么堅定的決心,這個問題也不可能被解決。

所以,盡管不同的Rollup項目通過精妙的機制設計,可以在絕大多數時候保障用戶資產的安全,但由於存在多籤和委員會,Rollup發生黑天鵝事件的概率並不爲0。即便多籤和委員會成員串謀的概率只有萬分之一,考慮到L2托管的資產價值(假設爲100億美元),L2用戶資產每天的風險仍高達100萬美元。聯想到Multichain事件,着實令人毛骨悚然。

所以我個人認爲,就像Polynya此前所說的那樣,以太坊生態內的大多數資金仍然會傾向於在L1流通和鎖倉,而非L2,Rollup生態長期內都無法捕獲以太坊生態內的大部分價值。對於大戶和鯨魚,以太坊主網顯然是一個比L2更合適、更可靠的資金去處。所以,很多人此前考慮的“L2的崛起會不會導致L1的冷清”,其實早已有了答案。

正如東野圭吾在其著作中所說,人心要遠比數學公式更難捉摸,更難理解,更爲復雜,也更難改變。許多事情無法靠單純的技術手段來解決,但凡涉及到“人性”的因素,永遠都是這個世上最不可控、最難預測、也最需要嚴肅對待的問題。在此,請讓我們牢記康德墓碑上的那句傳世經典:

“有兩樣事物始終圍繞着我的心靈,我越是加深對他們的思考,心中喚起的驚奇和敬畏越是日漸加深:這便是 內心的道德律和頭頂燦爛的星空。

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

標題:Rollup最大的信任風險:無法忽視的“人治”問題

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

相關閱讀: