從 opBNB 和以太坊 Layer2 的性能差異來理解 Rollup 的瓶頸與優化方式

作者：Faust，極客 web3

導語：如果用一個關鍵詞來概括 2023 年的 Web3，大多數人或許會本能想到「Layer2 之夏」。雖然應用層創新此起彼伏，但能像 L2 一樣經久不衰的長期熱點卻難得一見。隨著 Celestia 成功推廣模塊化區塊鏈概念，Layer2 和模塊化幾乎成為了基礎設施的代名詞，單片鏈的往日輝煌似乎難以重現。在 Coinbase、Bybit 和 Metamask 相繼推出專屬的二層網絡後，Layer2 大戰如火如荼，像極了當初新公鏈間炮火連天的場面。

在這場由交易所引領的二層網絡大戰中，BNB Chain 必然不肯甘居人下。早在去年他們就曾上線 zkBNB 測試網，但因為 zkEVM 在性能上還無法滿足大規模應用，採用 Optimistic Rollup 方案的 opBNB 成為了實現通用 Layer2 的更優方案。本文旨在對 opBNB 的工作原理與其商業意義進行簡要概括，為大家梳理 BSC 公鏈在模塊化區塊鏈時代邁出的重要一步。

BNB Chain 的大區塊之路

與 Solana、Heco 等由交易所扶持的公鏈類似，BNB Chain 的公鏈 BNB Smart Chain (BSC) 鏈對高性能的追求由來已久。從 2020 年上線初，BSC 鏈就把每個區塊的 gas 容量上限設定在 3000 萬，出塊間隔穩定在 3 秒。在這樣的參數設置下，BSC 實現了 100+ 的 TPS 上限（各種交易雜糅在一起的 TPS）。2021 年 6 月，BSC 的區塊 gas 上限提升到了 6000 萬，但在當年 7 月一款名為 CryptoBlades 的鏈遊在 BSC 上爆火，引發的日交易筆數一度超過 800 萬，導致手續費飆升。事實證明，此時的 BSC 效率瓶頸還是比較明顯。

（數據來源：BscScan）

為了解決網絡性能問題，BSC 再次將每個區塊的 gas 上限上調，此後長時間穩定在 8000 萬~8500 萬附近。2022 年 9 月，BSC Chain 單個區塊的 gas 上限提高到了 1.2 億，年底時提高到了 1.4 億，達到 2020 年時的近 5 倍。此前 BSC 曾計劃把區塊 gas 容量上限提升到 3 億，或許是考慮到 Validator 節點的負擔太重，上述超大區塊的提議一直沒有實施。

（數據來源：YCHARTS）

後來的 BNB Chain 似乎將重心放在了模塊化 /Layer2 賽道，而沒有再執著於 Layer1 的擴容。從去年下半年上線的 zkBNB 到今年年初時的 GreenField，這一意圖表現的愈加明顯。出於對模塊化區塊鏈 /Layer2 的濃厚興趣，本文作者將以 opBNB 為調研對象，從 opBNB 與以太坊 Layer2 表現出的不同，來為讀者簡單揭示 Rollup 的性能瓶頸所在。

BSC 的高吞吐量對 opBNB 的 DA 層加成

眾所周知，Celestia 按照模塊化區塊鏈的工作流程，歸納出了 4 個關鍵組件：

• 執行層 Execution：執行合約代碼、完成狀態轉換的執行環境；
• 結算層 Settlement：處理欺詐證明 / 有效性證明，同時處理 L2 與 L1 之間的橋接問題。
• 共識層 Consensus：對交易的排序達成一致共識。
• 數據可用性層 Data availability (DA)：發布區塊鏈賬本相關數據，使得驗證者可以下載到這些數據。

其中，DA 層與共識層往往被耦合在一起。比如，樂觀 Rollup 的 DA 數據包含了一批 L2 區塊中的交易序列，當 L2 全節點獲取到 DA 數據時，其實就知道了這批交易中每筆 Tx 的先後次序。（正因如此，以太坊社區對 Rollup 分層時，認為 DA 層和共識層是關聯的）

但對於以太坊 Layer2 而言，DA 層（以太坊）的數據吞吐量成為了制約 Rollup 性能的最大瓶頸，因為目前以太坊的數據吞吐量太低，Rollup 不得不盡量壓制自己的 TPS，防止以太坊主網無法承載 L2 產生的數據。

同時，低下的數據吞吐量使得 Ethereum 網絡內大量交易指令處於待處理狀態，這使得 gas 費被拉到了極高水準，進一步抬高了 Layer2 的數據發布成本。最後，很多二層網絡不得不採用 Celestia 等以太坊之外的 DA 層，「近水樓台先得月」的opBNB 則直接選用高吞吐量的 BSC 實現 DA，以解決數據發布上的瓶頸問題。

為了方便理解，此處需要介紹一下 Rollup 的 DA 數據發布方式。以 Arbitrum 為例，Layer2 排序器控制的以太坊鏈上 EOA 地址，會定期往指定的合約發出 Transaction，在這個指令的輸入參數 calldata 中，寫入打包好的交易數據，並觸發相應的鏈上事件，在合約日誌中留下永久記錄。

這樣一來，Layer2 的交易數據被長期保存在了以太坊區塊中，有能力運行 L2 節點的人可以下載相應的記錄，解析出對應數據，但以太坊自己的節點並不執行這些 L2 交易。不難看出，L2 只是把交易數據存放到以太坊區塊中，產生了存儲成本，而執行交易的計算成本被 L2 自己的節點承擔了。

上面講到的就是 Arbitrum 的 DA 實現方式，而 Optimism 則是由排序器控制的 EOA 地址，向另一個指定的 EOA 地址進行 Transfer，在附加的數據中攜帶 Layer2 的新一批交易數據。至於採用了 OP Stack 的 opBNB，和 Optimism 的 DA 數據發布方式基本一致。

顯而易見，DA 層的吞吐量會對單位時間內 Rollup 可發布的數據尺寸大小產生限制，進而限制 TPS。考慮到 EIP1559 後，每個 ETH 區塊的 gas 容量穩在 3000 萬，merge 後出塊時間約為 12 秒，則以太坊每秒處理的 gas 總量最多僅 250 萬。

絕大多數時候，容納 L2 交易數據的 calldata，每個字節消耗的 gas = 16，則以太坊每秒能處理的 calldata 尺寸最多只有 150 KB。而 BSC 平均每秒可處理的 calldata 尺寸最大約 2910 KB，達到了以太坊的 18.6 倍。兩者作為 DA 層的差距是顯而易見的。

可以概括一下，以太坊每秒最多可承載 150 KB 左右的 L2 交易數據。即便在 EIP 4844 上線後，這個數字也不會有多大改變，只不過降低了 DA 手續費。那麼每秒 150KB，大概能包含多少筆交易的數據？

這裡需要解釋下 Rollup 的數據壓縮率。 Vitalik 在 2021 年曾過分樂觀的估計，樂觀 Rollup 可以把交易數據尺寸，壓縮至原先的 11%。比如，一筆最基礎的 ETH 轉帳，原本佔用 calldata 大小是 112 字節，可以被樂觀 Rollup 壓縮到 12 字節，ERC-20 轉帳可以壓縮到 16 字節，Uniswap 上的 Swap 交易壓縮到 14 字節。按照他的說法，以太坊每秒最多能記錄 1 萬筆左右的 L2 交易數據（各類型掺雜在一起）。但按照 Optimism 官方在 2022 年披露的數據，實踐中的數據壓縮率，最高只能達到約 37%，與 Vitalik 的估算差了 3.5 倍。

（Vitalik 對 Rollup 擴容效應的估算，很大程度偏離了實際情況）

（Optimism 官方公布的各種壓縮算法實際取得的壓縮率）

所以我們不妨給出一個合理的數字，就是目前以太坊即便達到自己的吞吐量極限，所有樂觀 Rollup 加起來的 TPS 最大值，也只有 2000 多。 換句話說，如果以太坊區塊全部空間都用來承載樂觀 Rollup 發布的數據，比如被 Arbitrum、Optimism、Base、Boba 等瓜分，這些樂觀 Rollup 的 TPS 加起來根本不夠 3000，這還是在壓縮算法效率最高的情況下。此外，我們還要考慮到 EIP1559 後，每個區塊平均承載的 gas 量僅為最大值的 50%，所以上面的數字還應該砍掉一半。EIP4844 上線後，儘管會把發布數據的手續費大幅降低，但以太坊的區塊最大尺寸不會有多大變化（變化太多會影響 ETH 主鏈的安全性），所以上面估算的數值不會有多少進步。

根據 Arbiscan 和 Etherscan 的數據，Arbitrum 某個交易批次包含了 1115 筆交易，在以太坊上消耗了 181 萬的 gas。如此推算，如果把 DA 層每個區塊都裝滿，Arbitrum 理論上的 TPS 極限約為 1500，當然考慮到 L1 區塊重組問題，Arbitrum 不可能在每個以太坊區塊上都發布交易批次，所以上面的數字目前只是紙面上的。

同時，在 EIP 4337 相關的智能錢包被大規模採用後，DA 問題會愈加嚴重。因為支持 EIP 4337 後，用戶驗證身份的方式可以自定義，比如上傳指紋或虹膜的二進制數據，這會進一步加大常規交易佔用的數據尺寸。所以，以太坊低下的數據吞吐量是限制 Rollup 效率的最大瓶頸，這個問題今後很長時間可能都無法妥善解決。

而在 BNB chain 的公鏈 BSC 身上，平均每秒可處理的 calldata 尺寸最大約 2910 KB，達到了以太坊的 18.6 倍。換言之，只要執行層速度跟得上，BNB Chain 體系內的 Layer2，理論 TPS 上限可以達到 ARB 或 OP 的 18 倍左右。這個數字是以當前 BNB chain 每個區塊 gas 容量最大 1.4 億，出塊時間為 3 秒，計算得來的。

也就是說，目前 BNB Chain 體系下的公鏈，所有 Rollup 加總 TPS 極限，是以太坊的 18.6 倍（就算考慮進 ZKRollup，也是如此）。從這一點也可以理解，為什麼那麼多 Layer2 項目用以太坊鏈下的 DA 層來發布數據，因為差異是顯而易見的。

但是，問題沒有這麼簡單。除了數據吞吐量問題外，Layer1 本身的穩定性也會對 Layer2 造成影響。比如大多數 Rollup 往往要間隔幾分鐘才往以太坊上發布一次交易批次，這是考慮到 Layer1 區塊有重組的可能性。如果 L1 區塊重組，會波及到 L2 的區塊鏈賬本。所以，排序器每發布一個 L2 交易批次後，會再等多個 L1 新區塊發布完，區塊回滾概率大幅下降後，才發布下一個 L2 交易批次。這其實會推遲 L2 區塊被最終確認的時間，降低大宗交易的確認速度（大額交易要結果不可逆轉，才能保障安全）。

簡要概括，L2 發生的交易只有發布到 DA 層區塊內，且 DA 層又新產生了一定量的區塊後，才具備不可逆轉性，這是限制 Rollup 性能的一個重要原因。但以太坊出塊速度慢，12 秒才出一個塊，假設 Rollup 每隔 15 個區塊發布一個 L2 批次，不同批次間會有 3 分鐘的間隔，而且每個批次發布後，還要等待多個 L1 區塊產生，才會不可逆轉（前提是不會被挑戰）。顯然以太坊 L2 上的交易從發起到不可逆轉，等待時間很長，結算速度慢；而 BNB Chain 只需 3 秒就可以出一個塊，區塊不可逆轉只需要 45 秒（產生 15 個新區塊的時間）。

根據目前的參數，在 L2 交易數量相同且考慮到 L1 區塊不可逆轉性的前提下， 單位時間內opBNB 發布交易數據的次數，最多可以達到 Arbitrum 的 8.53 倍 （前者 45s 發一次，後者 6.4min 發一次），顯然 opBNB 上大額交易的結算速度，要比以太坊 L2 快很多。同時，opBNB 每次發布的最大數據量，可以達到以太坊 L2 的 4.66 倍（前者 L1 區塊的 gas 上限 1.4 億，後者是 3000 萬）。

8.53*4.66=39.74，這就是 opBNB 目前實踐中，與 Arbitrum 在 TPS 極限上的差距（目前 ARB 為了安全，貌似主動壓低了 TPS，但理論上如果要調高 TPS，還是和 opBNB 很多倍）

（Arbitrum 的排序器每隔 6~7 分鐘發布一次交易批次）

（opBNB 的排序器每隔 1~2 分鐘就會發布一次交易批次，最快只需要 45 秒）

當然還有更重要的問題需要考慮，就是 DA 層的 gas 費。L2 每發布一個交易批次，都有與 calldata 尺寸無關的固定成本------21000 的 gas，這也是一筆開銷。如果 DA 層 /L1 手續費很高，使得 L2 每次發布交易批次的固定成本居高不下，排序器就會降低發布交易批次的頻率。同時，在考慮 L2 手續費成分時，執行層的成本很低，大多數時候可以把它忽略，只考慮 DA 成本對手續費的影響。

總結下來，在以太坊和 BNB Chain 上發布同樣尺寸的 calldata 數據，雖然消耗的 gas 相同，但以太坊收取的 gas price 約是 BNB chain 的 10---幾十倍，傳導到 L2 手續費上，目前以太坊 Layer2 的用戶手續費大概也是 opBNB 的 10---幾十倍左右。綜合下來，opBNB 與以太坊上的樂觀 Rollup，差別還是很明顯的。

（Optimism 上一筆消耗 15 萬 gas 的交易，手續費 0.21 美元）

（opBNB 上一筆消耗 13 萬 gas 的交易，手續費 0.004 美元）

但是，擴大 DA 層的數據吞吐量，雖然可以提升整個 Layer2 體系的吞吐量，但對單個 Rollup 的性能提升還是有限，因為執行層處理交易的速度往往不夠快，即便 DA 層的限制可以忽略掉，執行層也會成為影響 Rollup 性能的下一個瓶頸。如果 Layer2 執行層的速度很慢，溢出的交易需求就會蔓延到其他 Layer2 上，最終造成流動性的割裂。所以，提升執行層的性能也很重要，是 DA 層之上的又一道門檻。

opBNB 在執行層的加成：快取優化

當大多數人談到區塊鏈執行層的性能瓶頸時，必然會提到：EVM 的單線程串行執行方式無法充分利用 CPU、以太坊採用的 Merkle Patricia Trie 查找數據效率太低，這是兩個重要的執行層瓶頸所在。說白了，對執行層的擴容思路，無非是更充分的利用 CPU 資源，再就是讓 CPU 儘可能快的獲取到數據。針對 EVM 串行執行和 Merkle Patricia Tree 的優化方案往往比較複雜，並不是很好實現，而投入性價比更高的工作常聚集在對快取的優化上。

其實快取優化問題，回到了傳統 Web2 乃至教科書中經常討論到的點。

通常情況下，CPU 從內存讀取數據的速度，是從磁碟讀取數據速度的上百倍，比如一段數據，CPU 從內存中讀取只需要 0.1 秒，從磁碟中讀取則需要 10 秒。所以，降低在磁碟讀寫上產生的開銷，也即快取優化，成為了區塊鏈執行層優化中必需的一環。

在以太坊乃至絕大多數公鏈中，記錄鏈上地址狀態的數據庫被完整存儲在磁碟當中，而所謂的世界狀態 World State trie 只是這個數據庫的索引，或者說查找數據時用到的目錄。EVM 每次執行合約都需要獲取相關的地址狀態，如果數據都要從存放在磁碟裡的數據庫中一條條拿過來，顯然會嚴重降低執行交易的速度。所以在數據庫 / 磁碟之外設置快取，是必要的提速手段。

opBNB 直接採用了 BNB Chain 用到的快取優化方案。按照 opBNB 的合作方 NodeReal 披露的信息，最早的 BSC 鏈在 EVM 與存放狀態的 LevelDB 數據庫之間設置了 3 道快取，設計思路類似於傳統的三級快取，把訪問頻率更高的數據放到快取中，這樣 CPU 就可以先去快取中尋找需要的數據。如果快取的命中率足夠高，CPU 就不需要過分依賴磁碟來獲取數據，整個執行過程的速度就可以實現大幅提升。

後來 NodeReal 在此之上增設了一個功能，調動 EVM 沒佔用的空閒 CPU 核心，把 EVM 未來要處理的數據，提前從數據庫中讀出來，放入快取中，讓 EVM 未來能從快取直接獲得需要的數據，這個功能被稱為「狀態預讀」。

狀態預讀的道理其實很簡單：區塊鏈節點的 CPU 是多核心的，而 EVM 是單線程的串行執行模式，只用到 1 個 CPU 核心，這樣其他的 CPU 核心就沒有被充分利用。對此，可以讓 EVM 沒用到的 CPU 核心幫忙做點事，它們可以從 EVM 未處理的交易序列中，獲知未來 EVM 會用到的數據都有哪些。然後，這些 EVM 之外的 CPU 核心，會從數據庫中讀取 EVM 未來會用到的數據，幫 EVM 解決數據獲取上的開銷，提升執行速度。

在對快取進行了充分優化後，搭配上性能足夠的硬件配置，opBNB 其實已經把節點執行層的性能逼近到了 EVM 的極限：每秒最多能處理 1 億 gas。1 億 gas 基本就是無改動的 EVM 的性能天花板（來自於某明星公鏈的實驗測試數據）。

具體概括的話，opBNB 每秒最多可處理 4761 筆最簡單的轉帳，處理 1500~3000 筆 ERC20 轉帳，處理約 500~1000 筆 SWAP 操作（這些數據根據區塊瀏覽器上的交易數據獲知）。以目前的參數對比看的話，opBNB 的 TPS 極限，是以太坊的 40 倍，BNB Chain 的 2 倍多，Optimism 的 6 倍多。

當然，以太坊 Layer2 因為 DA 層本身的嚴重限制，執行層根本施展不開，如果把此前曾提到的 DA 層出塊時間、穩定性等因素都考慮進去，以太坊 Layer2 的實際性能要在執行層性能基礎上大打折扣。而對於 BNB Chain 這樣的高吞吐量 DA 層而言，擴容效應達到 2 倍多的 opBNB 是很有價值的，更何況這樣的擴容項目 BNB Chain 可以搭載多個。

可以預見的是，BNB Chain 已經把 opBNB 為首的 Layer2 方案列入自己的佈局計劃中，未來還會不斷收納更多的模塊化區塊鏈項目，包括在 opBNB 裡引入 ZK proof，並搭配 GreenField 等配套基礎設施來提供高可用的 DA 層，嘗試與以太坊 Layer2 體系競爭亦或合作。在這個分層擴容已成為大勢所趨的時代背景下，其他公鏈是否也會爭相模仿 BNB Chain 扶持自己的 Layer2 項目，一切都有待時間去驗證，但毫無疑問的是，以模塊化區塊鏈為大方向得到基礎設施範式革命正在且已經發生了。