解析opBNB技術原理：模組化重要一步，為何採用OP Stack建構Layer2？

本文簡要概括了 opBNB 的工作原理與其商業意義，梳理了 BSC 公鏈在模塊化區塊鏈時代邁出的重要一步。

作者：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 容量上限設定在3,000 萬，出區塊間隔穩定在3 秒。在這樣的參數設定下，BSC 實現了100+ 的TPS 上限（各種交易雜糅在一起的TPS）。 2021 年6 月，BSC 的區塊gas 上限提升到了6,000 萬，但在當年7 月一款名為CryptoBlades 的鏈遊在BSC 上爆火，引發的日交易筆數一度超過800 萬，導致手續費飆升。事實證明，此時的BSC 效率瓶頸仍比較明顯。

為了解決網路效能問題，BSC 再次將每個區塊的gas 上限上調，此後長時間穩定在8,000 萬~8,500 萬附近。 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 容量穩在3,000 萬，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 最大值，也隻有2,000 以上。換句話說，如果以太坊區塊全部空間都用來承載樂觀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 億，後者是3,000 萬）。

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 項目，一切都有待時間去驗證，但毫無疑問的是，以模組化區塊鏈為大方向得到基礎建設範式革命正在且已經發生了。