歡迎光臨
比特幣資訊網

Monad 聯創:坎昆之後,Rollup 的性能瓶頸是什么?

撰文:Keone Hon,Monad 聯合創始人

編譯:Azuma,Odaily 星球日報

編者按:北京時間 3 月 26 日上午,Monad 聯合創始人Keone Hon 於個人 X 發布了一篇關於 Rollup 性能狀況的深度長文。文中,Keone 詳述了坎昆升級之後 Rollup 的理論 TPS 上限該如何計算,並解釋了爲何升級之後部分 Layer2(Base)的單筆交易費用仍高達數美元,此外 Keone 還概述了Rollup 所面臨的一些瓶頸限制以及潛在的改進方向。

以下爲Keone 的原文內容,由 Odaily 星球日報編譯,爲了方便讀者閱讀,譯者在原文基礎上做了一定補充。

最近市場上有一些關於 Rollup 執行瓶頸和 Gas 限制的討論,這不僅涉及 Layer1,也包括了 Layer2。我將在下文中討論這些瓶頸問題。

數據可用性(DA)

隨着 Blob 數據結構(EIP-4844)在坎昆升級中被引入,以太坊的數據可用性(DA)已得到了大幅改進,Layer2 的數據同步交易已無需再與普通 Layer1 交易在同一個費用市場中競價。

當前,Blob 的容量狀況大概是每個區塊(12秒)產出 3 個 125kb的Blob,即每秒31.25kb,鑑於一筆交易的大小大概是100字節,這意味着所有 Rollup 的共享 TPS 大概是 300 左右。

當然了,這裏有一些信息需要特別備注。

  • 一是如果 Rollup 採用了更好的交易數據壓縮技術,可縮減單筆交易大小的話,TPS 便可實現增長。
  • 二是理論上 Rollup 除了可以採用 Blob 同步數據之外,還可繼續採用 calldata 同步數據(即坎昆升級之前的舊方案),盡管這樣做會帶來額外的復雜性。
  • 三是不同 ZK-rollup發布狀態的方式存在差異(尤其是zkSync Era和Starknet),因此對於這些Rollup來說,計算方式及結果也會有所不同。

Rollup的 gas限制

最近,Base 由於其gas費用的激增而引發了較大關注,一筆普通的交易在該網絡上的費用已上漲到了幾美元。

爲什么坎昆升級之後,Base 網絡只降低了一段時間,現在又回到甚至超過了升級之前的水准呢?這是因爲Base上的區塊存在一個 gas 總額限制,該限制系通過其代碼中的一個參數來執行。

Base目前所採用的 gas 參數與Optimism相同,即每個 Layer2 區塊(2 秒)存在 500萬 gas 的總額限制,當該網絡之上的需求(交易總數)超過供應(區塊空間)之時,價格結算便會採取按需執行的機制,從而導致該網絡 gas 的飆升。

爲什么 Base 不去提高這一 gas 總額限制呢?或者換句話說,爲什么 Rollup 需要設置一個 gas 總額限制呢?

除了前文提到的數據可用性存在 TPS 上限之外,這裏其實還有另外兩大原因,分別是執行吞吐量的瓶頸以及狀態增長的隱患。

問題一:執行吞吐量的瓶頸

一般而言,EVM Rollup 運行的都是一個 fork 自 Geth 的 EVM,這意味着它們與 Geth 客戶端有着相似的性能特徵。

Geth 的客戶端是單线程的(即一次只能處理一個任務),它使用了 LevelDB/PebbleDB 編碼,在 merkle patricia trie(MPT)中存儲其狀態。這是一種通用數據庫,使用着另一種樹結構(LSM 樹)作爲底層在固態硬盤(SSD)上存儲數據。

對於 Rollup 而言,「狀態訪問」(從 merkle trie 讀取數值)和「狀態更新」(在每個區塊結束時更新 merkle trie)是執行過程中成本最高的環節。之所以如此,是因爲從固態硬盤上單次讀取的成本是 40-100 微秒,且由於 merkle trie 數據結構被嵌入到另一個數據結構(LSM 樹)中,導致需要進行許多非必要的額外查找。

這個環節可以想象爲在一個復雜的文件系統中查找特定文件的過程。你需要從根目錄(trie 根節點)一直找到目標文件(葉節點)。在查找每個文件時,都需要查找數據庫 LevelDB 中的特定鍵,而在 LevelDB 內部又必須通過另一個名爲 LSM 樹的數據結構來執行實際的數據存儲操作,這樣的過程造成了許多額外的查找步驟。這些額外的步驟讓整個數據讀取和更新變得相當慢且低效。

在 Monad 的設計中,我們通過 MonadDb 解決了這一問題。MonadDb 是一個自定義數據庫,支持直接在磁盤上存儲 merkle trie,避免了 LevelDb 的开銷;支持異步 IO,允許多個讀取並行處理;繞過了文件系統。

此外,Monad 採用的「樂觀並行執行」(optimistic parallel execution)機制允許多筆交易並行進行,且能夠從 MonadDb 中並行地提取其狀態。

然而,Rollup 沒有這些優化,因此在執行吞吐量上存在瓶頸。

需要注明的是,Erigon/Reth 客戶端對於數據庫的效率有過一定優化,且一些 Rollup 的客戶端也是基於這些客戶端構建的(比如 OP-Reth)。Erigon/Reth使用了一種扁平的數據結構,這在一定程度上減少了讀取時的查詢成本;然而,它們並不支持異步讀取或多线程處理。此外,每個區塊之後都需要重新計算 merkle root,這也是一個相當緩慢的過程。

問題二:狀態增長的隱患

與其他區塊鏈一樣,Rollup 也會限制它們的吞吐量,以防止其活動狀態增長過快。

市場上存在的一個常見論點是,狀態增長速度之所以令人擔憂,是因爲如果狀態數據大幅增長,對固態硬盤(SSD)的設備需求也將不得不上調。然而,我認爲這有點不准確,SSD 相對便宜(一個高質量的 2TB SSD 大約也就 200 美元),而在近 10 年的歷史中,以太坊的全狀態「僅」有大約 200 GB。單純從儲存角度來看,仍有很大的增長空間。

更大的隱患其實在於,隨着狀態持續增長,查詢指定狀態片段的時間會變得更長。這是因爲當前 merkle patricia trie 會在滿足「節點只有一個子節點」的條件時使用「快捷方式」,這可減少 trie 的有效深度,從而加速查詢過程,可如果 merkle trie 的狀態越來越滿,可用的「快捷方式」也就會越來越少。

綜合而言,狀態增長的隱患歸根結底其實就是狀態訪問效率的問題,因此加速狀態訪問是使狀態增長更具可持續性的關鍵。

爲什么僅僅優化硬件並沒有用?

Layer2 目前仍處於相對中心化的狀態,即網絡仍依賴於單一的排序器來維護狀態並產出區塊。有人可能會問,那爲什么不讓排序器運行在具備極高 RAM(隨機存取存儲器)的硬件上,以便讓所有狀態都能存儲於內存中呢?

這也有兩個原因。

其一,這並不會解決以太坊主網所存在的數據可用性瓶頸問題,盡管就目前 Base 的情況來看,該網絡 gas 的飆升並不是因爲主網數據可用性能力不足而導致,但從長遠來看這終將會成爲限制 Rollup 的一大瓶頸。

其二則是去中心化的問題,盡管排序器仍處於高度中心化狀況,但參與網絡運行的其他角色也很重要,他們也需要能獨立運行節點,重放相同的交易歷史並維護相同的狀態。

Layer1 之上的原始交易數據和狀態提交並不足以解开完整的狀態。任何對完整狀態存在訪問需求的角色(例如商家、交易所或自動交易者)都應該運行一個完整的 Layer2 節點來處理交易,並擁有一個最新的狀態副本。

Rollups 仍屬於區塊鏈,而區塊鏈之所以有趣,是因爲它們能夠通過共享的全球狀態實現全球協調。對所有區塊鏈而言,性能強大的軟件是必要的,僅僅優化硬件並不足以解決問題。

社區互動

在Keone 發完此文後,多個頭部 Layer2 項目的關鍵人員均在該動態下方進行了互動。

zkSync 聯合創始人 Alex Gluchowski 針對文中「每個區塊之後都需要重新計算 merkle root」的內容詢問 Monad 在這方面有何不同?

Keone 的回復是會有一種用於在每個區塊後計算merkle root 的優化算法。

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


標題:Monad 聯創:坎昆之後,Rollup 的性能瓶頸是什么?

地址:https://www.globalstockvip.com/article/66075.html