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チェーンは各ブロックのガス容量上限を3000万に設定し、ブロック生成間隔を3秒に安定させました。このようなパラメータ設定の下で、BSCは100以上のTPS上限（さまざまな取引が混在したTPS）を実現しました。2021年6月、BSCのブロックガス上限は6000万に引き上げられましたが、同年7月に「CryptoBlades」というチェーンゲームがBSC上で爆発的に人気を博し、日々の取引数が800万を超え、手数料が急騰しました。事実、この時点でのBSCの効率のボトルネックはかなり明らかでした。

（データ出典：BscScan）

ネットワーク性能の問題を解決するために、BSCは再び各ブロックのガス上限を引き上げ、その後長期間8000万〜8500万の範囲で安定しました。2022年9月、BSCチェーンの単一ブロックのガス上限は1.2億に引き上げられ、年末には1.4億に達し、2020年の約5倍に達しました。以前、BSCはブロックガス容量上限を3億に引き上げる計画を立てていましたが、バリデータノードの負担が大きすぎることを考慮し、上述の超大ブロックの提案は実施されていません。

（データ出典：YCHARTS）

その後のBNB Chainは、モジュール化/Layer2トラックに重心を置き、Layer1の拡張に固執しなくなったようです。昨年下半期に立ち上がったzkBNBから今年初めのGreenFieldに至るまで、この意図はますます明らかになっています。モジュール化ブロックチェーン/Layer2に対する強い関心から、本記事の著者はopBNBを調査対象とし、opBNBとEthereum Layer2の異なる点を通じて、Rollupの性能ボトルネックを簡単に明らかにします。

BSCの高スループットがopBNBのDA層に与える影響

ご存知の通り、Celestiaはモジュール化ブロックチェーンのワークフローに従い、4つの重要なコンポーネントをまとめました：

• 実行層 Execution：契約コードを実行し、状態変換を完了する実行環境；
• 決済層 Settlement：詐欺証明/有効性証明を処理し、L2とL1間のブリッジ問題を処理します。
• コンセンサス層 Consensus：取引の順序に関する合意を形成します。
• データ可用性層 Data availability (DA)：ブロックチェーンの帳簿に関連するデータを公開し、検証者がこれらのデータをダウンロードできるようにします。

この中で、DA層とコンセンサス層はしばしば結合されています。例えば、楽観的RollupのDAデータには、L2ブロック内の取引シーケンスが含まれており、L2フルノードがDAデータを取得すると、実際にはこの取引の各Txの順序がわかります。（そのため、EthereumコミュニティはRollupの層分け時にDA層とコンセンサス層が関連していると考えています）

しかし、Ethereum Layer2にとって、DA層（Ethereum）のデータスループットはRollup性能の最大のボトルネックとなります。なぜなら、現在のEthereumのデータスループットは非常に低く、RollupはEthereumメインネットがL2から生成されるデータを処理できないのを防ぐために、できるだけTPSを抑えなければならないからです。

また、低いデータスループットにより、Ethereumネットワーク内の多くの取引指令が処理待ちの状態になり、ガス料金が非常に高くなり、Layer2のデータ公開コストがさらに引き上げられました。最終的に、多くの二層ネットワークはCelestiaなどEthereum以外のDA層を採用せざるを得なくなり、「近水楼台先得月」のopBNBは高スループットのBSCをDAとして直接選択し、データ公開のボトルネック問題を解決しました。

理解を容易にするために、ここでRollupのDAデータ公開方式を紹介する必要があります。Arbitrumを例にすると、Layer2のソートが制御するEthereumチェーン上のEOAアドレスは、定期的に指定された契約にTransactionを送信し、この指令の入力パラメータcalldataにパッケージ化された取引データを記入し、関連するオンチェーンイベントをトリガーし、契約ログに永久的な記録を残します。

こうして、Layer2の取引データはEthereumブロック内に長期間保存され、L2ノードを運営できる人は関連する記録をダウンロードし、対応するデータを解析できますが、Ethereum自身のノードはこれらのL2取引を実行しません。L2は取引データをEthereumブロックに保存するだけで、ストレージコストが発生し、取引を実行する計算コストはL2自身のノードが負担します。

上記はArbitrumのDA実装方式についての説明であり、Optimismはソータが制御するEOAアドレスが別の指定されたEOAアドレスにTransferを行い、追加データにLayer2の新しい取引データのバッチを含めます。OP Stackを採用したopBNBは、OptimismのDAデータ公開方式と基本的に一致しています。

明らかに、DA層のスループットは単位時間内にRollupが公開できるデータのサイズを制限し、TPSを制限します。EIP1559以降、各ETHブロックのガス容量は3000万に安定し、マージ後のブロック生成時間は約12秒であるため、Ethereumが1秒間に処理できるガスの総量は最大でも250万です。

ほとんどの場合、L2取引データを収容するcalldataは、各バイトが消費するガス=16であるため、Ethereumが1秒間に処理できるcalldataのサイズは最大で150KBです。一方、BSCは平均して1秒間に処理できるcalldataのサイズが最大約2910KBで、Ethereumの18.6倍に達しています。両者のDA層としての差は明らかです。

要約すると、Ethereumは1秒間に最大150KBのL2取引データを収容できます。EIP4844が導入された後でも、この数字はあまり変わらないでしょう。ただし、DA手数料が低下します。では、1秒間150KBで、どれくらいの取引データが含まれるのでしょうか？

ここでRollupのデータ圧縮率について説明する必要があります。Vitalikは2021年に楽観的Rollupが取引データのサイズを元の11%に圧縮できると過度に楽観的に見積もりました。例えば、最も基本的なETHの送金は、元々calldataのサイズが112バイトですが、楽観的Rollupによって12バイトに圧縮できます。ERC-20の送金は16バイトに圧縮され、Uniswapでのスワップ取引は14バイトに圧縮されます。彼の言葉によれば、Ethereumは1秒間に最大1万件のL2取引データを記録できるとされています（さまざまなタイプが混在しています）。しかし、Optimismが2022年に公開したデータによれば、実際のデータ圧縮率は最高でも約37%で、Vitalikの見積もりとは3.5倍の差があります。

（VitalikのRollup拡張効果の見積もりは、実際の状況から大きく外れています）

したがって、合理的な数字を挙げると、現在Ethereumが自らのスループット限界に達した場合、すべての楽観的Rollupを合わせたTPSの最大値は2000を超えることはありません。言い換えれば、Ethereumブロックのすべてのスペースを楽観的Rollupが公開するデータに使用した場合、例えばArbitrum、Optimism、Base、Bobaなどが分け合うと、これらの楽観的RollupのTPSを合計しても3000には達しません。これは圧縮アルゴリズムの効率が最高の場合です。さらに、EIP1559以降、各ブロックが平均して最大値の50%しかガスを収容できないことを考慮すると、上記の数字はさらに半分に減少する必要があります。EIP4844が導入された後、データ公開の手数料は大幅に低下しますが、Ethereumのブロックの最大サイズはあまり変わらないでしょう（あまり変わるとETHメインチェーンの安全性に影響を与えるため）、したがって上記の見積もり値はあまり改善されないでしょう。

ArbiscanとEtherscanのデータによると、Arbitrumのある取引バッチには1115件の取引が含まれ、Ethereum上で181万のガスを消費しました。このように推算すると、DA層の各ブロックを満杯にすると、Arbitrumの理論上のTPS限界は約1500になります。もちろん、L1ブロックの再編成問題を考慮すると、ArbitrumはすべてのEthereumブロックで取引バッチを公開することはできないため、上記の数字は現在のところ理論上のものに過ぎません。

また、EIP4337に関連するスマートウォレットが大規模に採用されると、DAの問題はさらに深刻化します。EIP4337をサポートすると、ユーザーの認証方法をカスタマイズできるようになり、指紋や虹彩のバイナリデータをアップロードすることが可能になります。これにより、通常の取引が占有するデータサイズがさらに増加します。したがって、Ethereumの低いデータスループットはRollupの効率を制限する最大のボトルネックであり、この問題は今後長い間適切に解決されない可能性があります。

一方、BNBチェーンのパブリックチェーンBSCでは、平均して1秒間に処理できるcalldataのサイズが最大約2910KBで、Ethereumの18.6倍に達しています。言い換えれば、実行層の速度が追いつけば、BNB Chain体系内のLayer2は理論的なTPS上限がARBやOPの約18倍に達することができます。この数字は、現在のBNBチェーンの各ブロックのガス容量が最大1.4億、ブロック生成時間が3秒であることから計算されたものです。

つまり、現在BNB Chain体系下のパブリックチェーンにおいて、すべてのRollupを合計したTPSの限界はEthereumの18.6倍です（ZKRollupを考慮しても同様です）。この点からも、多くのLayer2プロジェクトがEthereumチェーン外のDA層を使用してデータを公開する理由が理解できます。なぜなら、差異は明らかだからです。

しかし、問題はそれほど単純ではありません。データスループットの問題に加えて、Layer1自体の安定性もLayer2に影響を与えます。例えば、大多数のRollupは、Ethereumに取引バッチを公開するのに数分間隔を置く必要があります。これはLayer1ブロックに再編成の可能性があることを考慮しているからです。L1ブロックが再編成されると、L2のブロックチェーン帳簿にも影響を及ぼします。そのため、ソータはL2取引バッチを公開するたびに、複数のL1新ブロックが公開され、ブロックの巻き戻し確率が大幅に低下してから次のL2取引バッチを公開します。これは実際にはL2ブロックが最終確認されるまでの時間を遅らせ、大口取引の確認速度を低下させます（大口取引は結果が不可逆である必要があり、安全性を確保するためです）。

簡潔に言えば、L2で発生した取引はDA層のブロック内に公開され、DA層が新たに一定量のブロックを生成した後でなければ不可逆性を持たず、これはRollup性能を制限する重要な理由の一つです。しかし、Ethereumのブロック生成速度が遅く、12秒ごとに1つのブロックが生成されると仮定し、Rollupが15ブロックごとに1つのL2バッチを公開する場合、異なるバッチ間には3分の間隔があり、各バッチが公開された後、さらに複数のL1ブロックが生成されるのを待たなければなりません（前提として挑戦されない限り）。明らかに、Ethereum L2上の取引は発起から不可逆までの待機時間が非常に長く、決済速度が遅いです。一方、BNB Chainは3秒で1つのブロックを生成でき、ブロックの不可逆性は45秒（15個の新ブロックが生成される時間）で達成されます。

現在のパラメータに基づいて、L2取引の数量が同じで、L1ブロックの不可逆性を考慮した場合、単位時間内にopBNBが公開する取引データの回数は、最大でArbitrumの8.53倍に達することができます（前者は45秒ごとに1回、後者は6.4分ごとに1回）。明らかに、opBNB上の大口取引の決済速度はEthereum L2よりもはるかに速いです。同時に、opBNBが毎回公開する最大データ量は、Ethereum L2の4.66倍に達することができます（前者はL1ブロックのガス上限が1.4億、後者は3000万です）。

8.53*4.66=39.74、これがopBNBが現在の実践において、ArbitrumのTPS限界における差です（現在ARBは安全のためにTPSを意図的に低下させているようですが、理論的にはTPSを引き上げる場合、opBNBとは多くの倍数の差があります）。

（Arbitrumのソータは6〜7分ごとに取引バッチを公開します）

（opBNBのソータは1〜2分ごとに取引バッチを公開し、最速で45秒で行います）

もちろん、考慮すべきさらに重要な問題は、DA層のガス料金です。L2が取引バッチを公開するたびに、calldataのサイズに関係なく固定コストが発生します------21000のガス、これも一つの出費です。DA層/L1の手数料が非常に高い場合、L2が毎回取引バッチを公開する固定コストが高くなり、ソータは取引バッチの公開頻度を下げることになります。また、L2手数料の成分を考慮する際、実行層のコストは非常に低く、大多数の場合は無視できるほどであり、DAコストが手数料に与える影響のみを考慮することができます。

要約すると、EthereumとBNB Chainで同じサイズのcalldataデータを公開する場合、消費するガスは同じですが、Ethereumが請求するガス価格はBNBチェーンの10〜数十倍であり、L2手数料に伝導され、現在Ethereum Layer2のユーザー手数料はopBNBの10〜数十倍程度です。総合的に見て、opBNBとEthereum上の楽観的Rollupの違いは依然として明らかです。

（Optimismでの取引のガス消費が15万のもの、手数料は0.21ドル）

（opBNBでの取引のガス消費が13万のもの、手数料は0.004ドル）

しかし、DA層のデータスループットを拡大することは、全体のLayer2システムのスループットを向上させることができますが、単一のRollupの性能向上には限界があります。なぜなら、実行層が取引を処理する速度が十分でない場合、DA層の制限を無視できたとしても、実行層がRollupの性能に影響を与える次のボトルネックとなるからです。Layer2の実行層の速度が非常に遅い場合、溢れた取引需要は他のLayer2に広がり、最終的には流動性の分断を引き起こします。したがって、実行層の性能を向上させることも重要であり、DA層の上にあるもう一つのハードルです。

opBNBの実行層の加算：キャッシュ最適化

ほとんどの人がブロックチェーンの実行層の性能ボトルネックについて話すとき、必ず言及されるのは、EVMの単一スレッドの直列実行方式がCPUを十分に活用できないこと、Ethereumが採用しているMerkle Patricia Trieのデータ検索効率が非常に低いことです。これらは実行層の2つの重要なボトルネックです。要するに、実行層の拡張の考え方は、CPUリソースをより十分に活用することと、CPUができるだけ早くデータを取得できるようにすることです。EVMの直列実行とMerkle Patricia Treeの最適化策は往々にして非常に複雑で、実現が難しいですが、コストパフォーマンスの高い作業はキャッシュの最適化に集中することが多いです。

実際、キャッシュ最適化の問題は、従来のWeb2や教科書でよく議論されるポイントに戻ります。

通常、CPUがメモリからデータを読み取る速度は、ディスクからデータを読み取る速度の数百倍です。例えば、あるデータがCPUによってメモリから読み取られるのに0.1秒かかるとすると、ディスクから読み取るには10秒かかります。したがって、ディスクの読み書きにかかるコストを削減すること、つまりキャッシュの最適化が、ブロックチェーンの実行層の最適化において必要不可欠な要素となります。

Ethereumやほとんどのパブリックチェーンでは、チェーン上のアドレス状態を記録するデータベースが完全にディスクに保存されており、いわゆる世界状態World State trieはこのデータベースのインデックス、またはデータを検索する際に使用されるディレクトリに過ぎません。EVMは契約を実行するたびに関連するアドレス状態を取得する必要がありますが、データがすべてディスクに保存されたデータベースから一つずつ取得される必要がある場合、明らかに取引の実行速度が大幅に低下します。したがって、データベース/ディスクの外にキャッシュを設定することは、必要な速度向上手段です。

opBNBはBNB Chainで使用されているキャッシュ最適化策を直接採用しています。opBNBのパートナーであるNodeRealの情報によれば、最初のBSCチェーンではEVMと状態を保存するLevelDBデータベースの間に3つのキャッシュが設定されており、設計思想は従来の3層キャッシュに似ており、アクセス頻度の高いデータをキャッシュに置くことで、CPUはまずキャッシュから必要なデータを探すことができます。キャッシュのヒット率が十分に高ければ、CPUはディスクからデータを取得する必要がなくなり、全体の実行プロセスの速度が大幅に向上します。

その後、NodeRealはこの上に機能を追加し、EVMが占有していない空いているCPUコアを動員し、EVMが将来処理するデータを事前にデータベースから読み出してキャッシュに置くことで、EVMが将来必要とするデータをキャッシュから直接取得できるようにします。この機能は「状態の事前読み込み」と呼ばれています。

状態の事前読み込みの原理は非常にシンプルです：ブロックチェーンノードのCPUはマルチコアであり、EVMは単一スレッドの直列実行モードで、1つのCPUコアしか使用しないため、他のCPUコアが十分に活用されていません。これに対処するために、EVMが使用していないCPUコアに少し手伝ってもらうことができます。これらのCPUコアは、EVMが未処理の取引シーケンスから、将来EVMが使用するデータが何であるかを知ることができます。そして、これらのEVM外のCPUコアは、データベースからEVMが将来使用するデータを読み取り、EVMのデータ取得コストを削減し、実行速度を向上させます。

キャッシュを十分に最適化した後、十分な性能のハードウェア構成を組み合わせることで、opBNBは実際にノードの実行層の性能をEVMの限界に近づけています：毎秒最大1億ガスを処理できます。1億ガスは基本的に変更なしのEVMの性能の天井です（ある著名なパブリックチェーンの実験データに基づく）。

具体的に要約すると、opBNBは毎秒最大4761件の最も単純な送金を処理し、1500〜3000件のERC20送金を処理し、約500〜1000件のSWAP操作を処理できます（これらのデータはブロックブラウザの取引データから得られました）。現在のパラメータを比較すると、opBNBのTPS限界はEthereumの40倍、BNB Chainの2倍以上、Optimismの6倍以上です。

もちろん、Ethereum Layer2はDA層自体の深刻な制限により、実行層が十分に機能しません。もし前述のDA層のブロック生成時間、安定性などの要因を考慮に入れると、Ethereum Layer2の実際の性能は実行層の性能に基づいて大幅に減少します。一方、BNB Chainのような高スループットのDA層にとって、2倍以上の拡張効果を持つopBNBは非常に価値があります。さらに、このような拡張プロジェクトはBNB Chainが複数搭載できることも考慮すべきです。

予見されるのは、BNB ChainはopBNBを先頭とするLayer2ソリューションを自らの戦略計画に組み込み、今後もモジュール化ブロックチェーンプロジェクトを継続的に取り入れ、opBNBにZK証明を導入し、GreenFieldなどの関連インフラを組み合わせて高可用性のDA層を提供し、Ethereum Layer2システムと競争または協力を試みるでしょう。この階層的な拡張が大勢となっている時代背景の中で、他のパブリックチェーンもBNB Chainのように自らのLayer2プロジェクトを支援するために争って模倣するかどうかは、すべて時間が証明することになるでしょうが、モジュール化ブロックチェーンが大方向として基盤インフラのパラダイム革命が進行中であることは間違いありません。