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

作者：林克，《極客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.torrentbusiness.com/article/52930.html

標籤：