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

中級2/27/2024, 2:57:45 AM
本文旨在對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項目,一切都有待時間去驗證,但毫無疑問的是,以模塊化區塊鏈爲大方曏得到基礎設施範式革命正在且已經髮生了。

聲明:

  1. 本文轉載自[極客 Web3],著作權歸屬原作者[Faust,極客web3],如對轉載有異議,請聯繫Gate Learn團隊,團隊會根據相關流程盡速處理。
  2. 免責聲明:本文所錶達的觀點和意見僅代錶作者個人觀點,不構成任何投資建議。
  3. 文章其他語言版本由Gate Learn團隊翻譯, 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。

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

中級2/27/2024, 2:57:45 AM
本文旨在對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項目,一切都有待時間去驗證,但毫無疑問的是,以模塊化區塊鏈爲大方曏得到基礎設施範式革命正在且已經髮生了。

聲明:

  1. 本文轉載自[極客 Web3],著作權歸屬原作者[Faust,極客web3],如對轉載有異議,請聯繫Gate Learn團隊,團隊會根據相關流程盡速處理。
  2. 免責聲明:本文所錶達的觀點和意見僅代錶作者個人觀點,不構成任何投資建議。
  3. 文章其他語言版本由Gate Learn團隊翻譯, 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。
Empieza ahora
¡Registrarse y recibe un bono de
$100
!
It seems that you are attempting to access our services from a Restricted Location where Gate.io is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.