硬核解析部分 L2 gas 不降反增的原因。
作者：Keone Hon，Monad 聯合創始人
編譯：Azuma，Odaily 星球日報
封面：Photo by Milad Fakurian on Unsplash
編者按：日期：3 月 26 日上午，Monad 聯合創始人 Keone Hon 於個人 X 發佈了一篇關於 Rollup 性能狀況的深度長文。 文中，Keone 詳述了坎昆升級之後 Rollup 的理論 TPS 上限該如何計算，並解釋了為何升級之後部分 Layer 2（Base）的單筆交易費用仍高達數美元，此外 Keone 還概述了 Rollup 所面臨的一些瓶頸限制以及潛在的改進方向。
以下為 Keone 的原文內容，由 Odaily 星球日報編譯，為了方便讀者閱讀，譯者在原文基礎上做了一定補充。
最近市場上有一些關於 Rollup 執行瓶頸和 Gas 限制的討論，這不僅涉及 Layer 1 ，也包括了 Layer 2 。 我將在下文中討論這些瓶頸問題。
資料可用性（DA）
隨著 Blob 數據結構（EIP-4844）在坎昆升級中被引入，乙太坊的數據可用性（DA）已得到了大幅改進，Layer 2 的數據同步交易已無需再與普通 Layer 1 交易在同一個費用市場中競價。
當前，Blob 的容量狀況大概是每個區塊（12 秒）產出 3 個 125 kb 的 Blob，即每秒 31.25 kb，鑒於一筆交易的大小大概是 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 相同，即每個 Layer 2 區塊（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 相對便宜（一個高品質的 2 TB SSD 大約也就 200 美元），而在近 10 年的歷史中，乙太坊的全狀態 “僅” 有大約 200 GB。 單純從儲存角度來看，仍有很大的增長空間。
更大的隱患其實在於，隨著狀態持續增長，查詢指定狀態片段的時間會變得更長。 這是因為當前 merkle patricia trie 會在滿足 “節點只有一個子節點” 的條件時使用 “快捷方式”，這可減少 trie 的有效深度，從而加速查詢過程，可如果 merkle trie 的狀態越來越滿，可用的 “快捷方式” 也就會越來越少。
綜合而言，狀態增長的隱患歸根結底其實就是狀態訪問效率的問題，因此加速狀態訪問是使狀態增長更具可持續性的關鍵。
為什麼僅僅優化硬體並沒有用？
Layer 2 目前仍處於相對中心化的狀態，即網路仍依賴於單一的排序器來維護狀態並產出區塊。 有人可能會問，那為什麼不讓排序器運行在具備極高 RAM（隨機存取記憶體）的硬體上，以便讓所有狀態都能存儲於記憶體中呢？
這也有兩個原因。
其一，這並不會解決乙太坊主網所存在的數據可用性瓶頸問題，儘管就目前 Base 的情況來看，該網路 gas 的飆升並不是因為主網數據可用性能力不足而導致，但從長遠來看這終將會成為限制 Rollup 的一大瓶頸。
其二則是去中心化的問題，儘管排序器仍處於高度中心化狀況，但參與網路運行的其他角色也很重要，他們也需要能獨立運行節點，重放相同的交易歷史並維護相同的狀態。
Layer 1 之上的原始交易數據和狀態提交並不足以解開完整的狀態。 任何對完整狀態存在訪問需求的角色（例如商家、交易所或自動交易者）都應該運行一個完整的 Layer 2 節點來處理交易，並擁有一個最新的狀態副本。
Rollups 仍屬於區塊鏈，而區塊鏈之所以有趣，是因為它們能夠通過共用的全球狀態實現全球協調。 對所有區塊鏈而言，性能強大的軟體是必要的，僅僅優化硬體並不足以解決問題。
社區互動
在 Keone 發完此文後，多個頭部 Layer 2 專案的關鍵人員均在該動態下方進行了互動。
zkSync 聯合創始人 Alex Gluchowski 針對文中 “每個區塊之後都需要重新計算 merkle root” 的內容詢問 Monad 在這方面有何不同？ ”
Keone 的回復是會有一種用於在每個區塊后計算 merkle root 的優化演算法。
Base 負責人 Jesse Pollak 亦藉此解釋了為何 Base 在坎昆升級之後 gas 費用不降反增，其表示 EIP-4844 已大幅降低了 Layer 1 層面的 DA 成本，gas 費用本該降低，但由於網路交易需求增長了 5 倍有餘，且 Base 網路之上的區塊存在 250 gas/s 的限制，需求大於供給使得 gas 費用出現了上漲。
免責聲明：作為區塊鏈資訊平臺，本站所發佈文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。 文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
