從 opBNB 來看 Rollup 在 DA 層與執行層的瓶頸與解決方案
作者：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 效率瓶頸還是比較明顯。
為了解決網路性能問題，BSC 再次將每個區塊的 gas 上限上調，此後長時間穩定在 8000 萬~8500 萬附近。 2022 年 9 月，BSC Chain 單個區塊的 gas 上限提高到了 1.2 億，年底時提高到了 1.4 億，達到 2020 年時的近 5 倍。 此前 BSC 曾計劃把區塊 gas 容量上限提升到 3 億，或許是考慮到 Validator 節點的負擔太重，上述超大區塊的提議一直沒有實施。
後來的 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 倍。
所以我們不妨給出一個合理的數位，就是目前乙太坊即便達到自己的輸送量極限，所有樂觀 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 很多倍）
當然還有更重要的問題需要考慮，就是 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，差別還是很明顯的。
但是，擴大 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 專案，一切都有待時間去驗證，但毫無疑問的是，以模組化區塊鏈為大方向得到基礎設施範式革命正在且已經發生了。
免責聲明：作為區塊鏈資訊平臺，本站所發佈文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。 文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
