BNBチェーンのビッグブロックへの道

BNBチェーンのビッグブロックの道

SolanaやHecoなど、取引所がサポートするパブリックチェーンと同様に、BNB ChainのパブリックチェーンであるBNB Smart Chain(BSC)は、長い間、高いパフォーマンスを追求してきました。 2020年のローンチ以来、BSCは各ブロックのガス容量制限を3,000万に設定し、安定したブロック間隔は3秒です。 このようなパラメータにより、BSCは最大TPS(様々なトランザクションが混在するTPS)100以上を達成しました。 2021年6月、BSCのブロックガス制限が6,000万に引き上げられました。 しかし、同年7月、BSCでCryptoBladesというチェーンゲームが爆発的に爆発的に増加し、1日の取引量が800万件を超え、手数料が高騰しました。 当時、BSCの効率のボトルネックはまだ非常に明白であることが判明しました。

(出典:BscScan)

ネットワークパフォーマンスの問題に対処するために、BSCは各ブロックのガスリミットを再び引き上げ、約8000万〜8500万で長期間安定していました。 2022年9月、BSCチェーンのブロックあたりのガスリミットは1億2,000万に引き上げられ、年末には2020年のほぼ5倍の1億4,000万に引き上げられました。 以前、BSCはブロックガス容量の上限を3億に引き上げることを計画していましたが、Validatorノードへの負担が大きいことを考慮してか、そのような超大型ブロックの提案は実行されていません。

出典:YCHARTS

その後、BNB Chainはレイヤー1の拡張に固執するのではなく、モジュラー/レイヤー2トラックに重点を置いているように見えました。 この意図は、昨年下半期のzkBNBのローンチから今年初めのGreenFieldへのローンチからますます明らかになりました。 モジュラーブロックチェーン/レイヤー2への強い関心から、この記事の著者はopBNBを研究対象として使用し、イーサリアムレイヤー2と比較することでロールアップのパフォーマンスボトルネックを明らかにします。

BSCの高スループットからopBNBのDA層への向上

ご存知のように、Celestiaはモジュラーブロックチェーンのワークフローに従って4つの主要コンポーネントをまとめました。 実行レイヤー:コントラクトコードを実行し、状態遷移を完了します。決済レイヤー:不正証明/有効性の証明を処理し、L2とL1の間のブリッジングの問題に対処します。 コンセンサスレイヤー:トランザクションの順序付けについてコンセンサスに達します。 Data Availability Layer(DA):ブロックチェーン台帳関連のデータを公開し、バリデーターがこのデータをダウンロードできるようにします。

その中で、DA層はコンセンサス層と結合されることが多いです。 たとえば、オプティミスティック ロールアップの DA のデータには、L2 ブロックのトランザクション シーケンスのバッチが含まれています。 L2 フルノードが DA データを取得すると、このバッチ内の各トランザクションの順序がわかります。 (このため、イーサリアムコミュニティは、Rollupを階層化する際にDA層とコンセンサス層が関連していると考えています。

しかし、イーサリアムレイヤー2では、DA層(イーサリアム)のデータスループットがロールアップのパフォーマンスを制限する最大のボトルネックとなっています。 これは、イーサリアムの現在のデータスループットが低すぎるため、RollupはTPSを可能な限り抑制して、イーサリアムメインネットがL2によって生成されたデータに耐えられないようにする必要があるためです。 同時に、データスループットが低いため、イーサリアムネットワーク内の多数のトランザクション命令が保留状態になり、ガス料金が非常に高いレベルに押し上げられ、レイヤー2のデータ公開コストがさらに増加します。 最後に、多くのレイヤー2ネットワークは、Celestiaなどのイーサリアム以外のDAレイヤーを採用する必要があり、水に近いopBNBは、データ公開のボトルネック問題を解決するために、BSCの高スループットを直接使用してDAを実装することを選択しました。 理解しやすいように、RollupのDAデータ公開の方法を紹介しましょう。 アービトラムを例にとると、レイヤー2シーケンサーのEOAアドレスによって制御されるイーサリアムチェーンは、指定されたコントラクトに定期的にトランザクションを送信します。 この命令の入力パラメータcalldataでは、パッケージ化されたトランザクションデータが書き込まれ、対応するオンチェーンイベントがトリガーされ、コントラクトログに永続的な記録が残ります。

このように、Layer2のトランザクションデータはイーサリアムのブロックに長期間保存されます。 L2ノードを実行できる人は、対応するレコードをダウンロードして対応するデータを解析できますが、イーサリアムノード自体はこれらのL2トランザクションを実行しません。 L2はトランザクションデータをイーサリアムブロックにのみ保存するため、ストレージコストが発生し、トランザクションを実行するための計算コストはL2ノード自体が負担していることは容易に理解できます。 上記はArbitrumのDAの実装方法であり、Optimismはシーケンサーで制御するEOAアドレスを使用して、指定された別のEOAアドレスに転送し、追加データにLayer2トランザクションデータの新しいバッチを運びます。 OP Stackを使用するopBNBについては、DAデータの公開方法は基本的にOptimismと同じです。

DA レイヤーのスループットによって、ロールアップが単位時間内に発行できるデータのサイズが制限され、TPS が制限されることは明らかです。 EIP1559後、各ETHブロックのガス容量が3,000万で安定し、マージ後のブロック時間が約12秒であることを考えると、イーサリアムは最大で毎秒250万ガスしか処理できません。 ほとんどの場合、L2トランザクションデータをコールデータに1バイトあたり収容するために消費されるガスは16であるため、イーサリアムは最大コールデータサイズを毎秒150KBしか処理できません。 対照的に、BSCの1秒間に処理される最大平均コールデータサイズは約2910KBで、これはイーサリアムの18.6倍です。 DAレイヤーとしての2つの違いは明らかです。

要約すると、イーサリアムは毎秒約150KBのL2トランザクションデータを伝送できます。 EIP 4844の発売後も、この数字はあまり変わらず、DA料金が下がるだけです。 では、毎秒約150KBにどれだけのトランザクションのデータを含めることができるのでしょうか。 ここでは、Rollupのデータ圧縮率を説明する必要があります。 ヴィタリックは2021年に過度に楽観的であり、オプティミスティックロールアップはトランザクションデータサイズを元のサイズの11%に圧縮できると推定していました。 例えば、もともと112バイトのコールデータサイズを占めていた基本的なETH転送は、オプティミスティックロールアップによって12バイトに圧縮することができ、ERC-20転送は16バイトに圧縮することができ、Uniswapのスワップトランザクションは14バイトに圧縮することができます。 彼の推定によると、イーサリアムは毎秒約10,000のL2トランザクションを記録できます(さまざまなタイプが混在しています)。 しかし、2022年にOptimismチームが開示したデータによると、実際のデータ圧縮率は最大で約37%に過ぎず、Vitalik氏の推定値の3.5倍となっています。

(Vitalik によるロールアップのスケーラビリティ効果の推定は、実際の条件から大きく乖離しています)

(Optimismが開示した様々な圧縮アルゴリズムによって達成された実際の圧縮率)

イーサリアムがスループットの限界に達したとしても、すべてのオプティミスティックロールアップを合わせた最大TPSは2000をわずかに上回る程度です。 言い換えれば、アービトラム、オプティミズム、ベース、ボバに分散されたデータなど、オプティミスティックロールアップによって公開されたデータを運ぶためにイーサリアムブロックが完全に使用された場合、これらのオプティミスティックロールアップの合計TPSは、最も効率的な圧縮アルゴリズムの下でも3000にも達しません。 さらに、EIP1559後、各ブロックのガス容量は最大値の平均50%しかないため、上記の数値を半分にする必要があることを考慮する必要があります。 EIP4844のローンチ後、データを公開するための取引手数料は大幅に削減されますが、イーサリアムの最大ブロックサイズはあまり変わらないため(変更が多すぎるとETHメインチェーンのセキュリティに影響を与えるため)、上記の推定値はあまり進みません。

ArbiscanとEtherscanのデータによると、Arbitrumのトランザクションのバッチには1115のトランザクションが含まれており、イーサリアムで181万ガスを消費しています。 外挿により、DA層がすべてのブロックで埋められている場合、Arbitrumの理論上のTPS制限は約1500です。 もちろん、L1ブロック再編の問題を考慮すると、Arbitrumはすべてのイーサリアムブロックでトランザクションバッチを公開することはできないため、上記の数値は現時点では理論上のものです。 さらに、EIP 4337に関連するスマートウォレットの普及に伴い、DAの問題はさらに深刻になります。 EIP 4337のサポートにより、指紋や虹彩のバイナリデータをアップロードするなど、ユーザーが本人確認を行う方法をカスタマイズできるため、通常のトランザクションで占めるデータサイズがさらに大きくなります。 そのため、イーサリアムのデータスループットの低さがロールアップの効率を制限する最大のボトルネックとなっており、この問題は長期間にわたって適切に解決されない可能性があります。 一方、BSCパブリックチェーンのBNBチェーンでは、1秒間に処理される最大平均コールデータサイズは約2910KBで、イーサリアムの18.6倍です。 言い換えれば、実行層が追いつくことができる限り、BNBチェーンエコシステム内のLayer2の理論上のTPS上限は、ARBまたはOPの約18倍に達する可能性があります。 この数値は、現在のBNBチェーンの最大ブロックガス容量1億4000万、ブロックタイム3秒に基づいて計算されます。

言い換えれば、BNBチェーンエコシステム内のすべてのロールアップの現在の合計TPS制限は、イーサリアムの18.6倍です(ZKRollupを考慮しても)。 この観点から見ると、多くのレイヤー2プロジェクトがイーサリアムチェーンの下のDAレイヤーを使用してデータを公開している理由は、その違いが非常に明白であるため、簡単に理解できます。 しかし、問題はそれほど単純ではありません。 データスループットの問題に加えて、レイヤー1自体の安定性もレイヤー2に影響を与える可能性があります。 たとえば、ほとんどのロールアップは、レイヤー1ブロックの再編成の可能性を考慮して、トランザクションのバッチをイーサリアムに公開する前に数分待つことがよくあります。 Layer1ブロックが再編成されると、Layer2のブロックチェーン台帳に影響が出ます。 したがって、シーケンサーは、L2 トランザクション バッチがリリースされるたびに、いくつかの新しいレイヤー 1 ブロックが公開されるのを待機し、ブロック ロールバックの可能性を大幅に減らしてから、次の L2 トランザクション バッチを発行します。 これにより、L2ブロックが最終的に確認される時間が遅れ、大規模なトランザクションの確認速度が低下します(大規模なトランザクションでは、セキュリティを確保するために不可逆的な結果が必要です)。 要約すると、L2で発生したトランザクションは、DAレイヤーブロックで公開され、DAレイヤーが一定数の新しいブロックを生成した後にのみ、元に戻せなくなります。 これは、ロールアップのパフォーマンスを制限する重要な理由です。 しかし、イーサリアムはブロック生成速度が遅く、ブロックを生成するのに12秒かかります。 ロールアップが 15 ブロックごとに L2 トランザクションのバッチを発行すると仮定すると、異なるバッチ間には 3 分の間隔があり、各バッチがパブリッシュされた後も、複数のレイヤー 1 ブロックが生成されるのを待ってから元に戻せるようにする必要があります (チャレンジされていないと仮定します)。 明らかに、イーサリアムのレイヤー2でのトランザクションの開始から不可逆性までの時間は非常に長く、決済速度が遅くなります。一方、BNBチェーンはブロックを生成するのに3秒しかかからず、ブロックはわずか45秒(15個の新しいブロックを生成するのにかかる時間)で元に戻せなくなります。 現在のパラメータに基づいて、同じ数のL2トランザクションを仮定し、L1ブロックの不可逆性を考慮すると、opBNBが単位時間内にトランザクションデータを公開できる回数は、Arbitrumの最大8.53倍(前者は45秒に1回、後者は6.4分に1回)に達する可能性があります。 明らかに、opBNBでの大規模なトランザクションの決済速度は、イーサリアムのレイヤー2よりもはるかに高速です。 さらに、opBNBが毎回公開する最大データサイズは、イーサリアムのレイヤー2の4.66倍に達する可能性があります(前者のL1ブロックのガス制限は1億4000万、後者の3000万)。 8.53 * 4.66 = 39.74。 これは、実用化におけるTPS制限の点でopBNBとArbitrumのギャップを表しています(現在、ARBはセキュリティ上の理由からTPSを積極的に減らしているようですが、理論的にはTPSを上げたとしても、opBNBに比べて何倍も低くなります)。

(Arbitrumのシーケンサーは6〜7分ごとにトランザクションバッチを公開します)

(opBNBのシーケンサーは1〜2分ごとにトランザクションバッチを公開し、最速のものはわずか45秒で完了します)。 もちろん、DA層のガス料金という、もう一つ重要な問題があります。 L2 がトランザクション バッチを発行するたびに、コールデータのサイズとは無関係に 21,000 ガスの固定コストが発生し、これは費用です。 DA層/L1のガス料金が高く、L2でトランザクションバッチを公開するための固定コストが高いままである場合、シーケンサーはトランザクションバッチの公開頻度を減らします。 さらに、L2手数料の構成要素を考慮すると、実行レイヤーのコストは非常に低く、DAコストが取引手数料に与える影響のみに焦点を当てて無視できることがよくあります。 まとめると、同じサイズのコールデータを公開すると、イーサリアムとBNBチェーンで同じ量のガスを消費しますが、イーサリアムが請求するガス価格はBNBチェーンの約10倍から数十倍になります。 L2取引手数料に換算すると、イーサリアムLayer2の現在のユーザー取引手数料もopBNBの約10倍から数十倍です。 全体として、イーサリアムのopBNBとオプティミスティックロールアップの違いは非常に明白です。

(Optimismで150,000ガスを消費するトランザクションは0.21ドルかかります)

(opBNBで130,000ガスを消費するトランザクションは0.004ドルかかります) ただし、DAレイヤーのデータスループットを向上させると、レイヤー2システムの全体的なスループットを向上させることができますが、個々のロールアップのパフォーマンス向上への影響は限定的です。 これは、実行レイヤーがトランザクションを十分な速度で処理しないことが多いためです。 DA 層の制限を無視できる場合でも、実行層がロールアップのパフォーマンスに影響を与える次のボトルネックになります。 Layer2の実行レイヤーの実行速度が遅いと、トランザクション需要のオーバーフローが他のLayer2に広がり、最終的に流動性の断片化を引き起こします。 したがって、実行層のパフォーマンスを向上させることも重要であり、DA層の上の別のしきい値として機能します。

実行層におけるopBNBのブースト:キャッシュの最適化

ブロックチェーン実行レイヤーのパフォーマンスのボトルネックについて議論するとき、ほとんどの人が必然的に2つの重要なボトルネックを挙げます:CPUを十分に活用できないEVMのシングルスレッドシリアル実行と、イーサリアムが採用したマークル・パトリシア・トライの非効率的なデータ検索です。 基本的に、実行レイヤーのスケーリング戦略は、CPU リソースをより効率的に使用し、CPU が可能な限り迅速にデータにアクセスできるようにすることを中心に展開します。

シリアルEVM実行とMerkle Patricia Trieの最適化ソリューションは、多くの場合、複雑で実装が困難ですが、より費用対効果の高い取り組みは、キャッシュの最適化に重点が置かれる傾向があります。 実際、キャッシュの最適化は、従来のWeb2や教科書の文脈でさえ頻繁に議論されるポイントに立ち返らせます。

通常、CPU がメモリからデータを取得する速度は、ディスクからデータを取得する速度の数百倍高速です。 たとえば、メモリからのデータの取得には 0.1 秒しかかかりませんが、ディスクからのデータの取得には 10 秒かかる場合があります。 したがって、ディスクの読み取りと書き込みによって生成されるオーバーヘッドの削減、つまりキャッシュの最適化は、ブロックチェーン実行レイヤーを最適化する上で不可欠な側面になります。

イーサリアムやその他のほとんどのパブリックチェーンでは、オンチェーンアドレスの状態を記録するデータベースは完全にディスクに保存されていますが、いわゆるワールドステートトライは、このデータベースのインデックス、またはデータ検索に使用されるディレクトリにすぎません。 EVMは、コントラクトを実行するたびに、関連するアドレスの状態にアクセスする必要があります。 ディスクベースのデータベースからデータを 1 つずつフェッチすると、トランザクションの実行が大幅に遅くなります。 したがって、データベース/ディスクの外部にキャッシュを設定することは、高速化するために必要な手段です。

opBNBは、BNB Chainが使用するキャッシュ最適化ソリューションを直接採用しています。 opBNBのパートナーであるNodeRealが開示した情報によると、初期のBSCチェーンは、EVMと状態を格納するLevelDBデータベースの間に3層のキャッシュを設定していました。 設計コンセプトは、アクセス頻度の高いデータがキャッシュに格納される従来の 3 レベル キャッシュと似ています。 これにより、CPU は最初にキャッシュ内の必要なデータを検索できます。 キャッシュヒット率が十分に高い場合、CPUはデータを取得するためにディスクに過度に依存する必要がなくなるため、全体的な実行速度が大幅に向上します。

その後、NodeRealはこれに、未使用のCPUコアを活用して、EVMが将来処理する必要があるデータをデータベースからプリエンプティブに読み取り、キャッシュに格納する機能を追加しました。 この機能は「状態プリロード」と呼ばれます。

ステート・プリロードの原理は単純で、ブロックチェーン・ノードのCPUはマルチコアであるのに対し、EVMはシングルスレッドのシリアル実行モードで動作し、1つのCPUコアのみを使用し、他のCPUコアは十分に活用されません。 これに対処するために、EVM で使用されていない CPU コアは、まだ処理されていないトランザクション・シーケンスから EVM が必要とするデータを予測することで、タスクを支援できます。 評価基板 (EVM) の外部にあるこれらの CPU コアは、評価基板 (EVM) が必要とするデータをデータベースから取得し、評価基板 (EVM) がデータ取得のオーバーヘッドを削減し、実行を高速化するのに役立ちます。

キャッシュの最適化と十分なハードウェア構成により、opBNBはノードの実行層のパフォーマンスを効果的にEVMの限界に近づけ、毎秒最大1億個のガスを処理しています。 この1億ガスは、著名なパブリックチェーンの実験テストデータによって実証されているように、本質的に未改造のEVMの性能の上限です。

簡潔に言うと、opBNBは、ブロックチェーンエクスプローラーで観察されたトランザクションデータに基づいて、毎秒最大4761回の単純な転送、毎秒15003000回のERC20トークン転送、毎秒約5001000回のSWAP操作を処理できます。 現在のパラメータを比較すると、opBNBのTPS制限はイーサリアムの40倍、BNBチェーンの2倍以上、オプティミズムの6倍以上です。

もちろん、イーサリアムのレイヤー2ソリューションの場合、DA層自体の厳しい制限により、DA層のブロック生成時間や安定性などの要因を考慮すると、実行層のパフォーマンスに基づいてパフォーマンスが大幅に割り引かれます。

opBNBのような高スループットのDAレイヤーを持つBNB Chainにとって、特にBNB Chainがそのようなスケーリングプロジェクトを複数ホストできることを考えると、スケーリングの倍増効果は貴重です。 BNB Chainは、すでにopBNB主導のレイヤー2ソリューションを戦略計画に組み込んでおり、イーサリアムのレイヤー2エコシステムと競争または協力するために、opBNBにZKプルーフを導入し、GreenFieldなどの補完的なインフラストラクチャを備えた高可用性DAレイヤーを提供するなど、より多くのモジュール式ブロックチェーンプロジェクトを引き続きオンボードしていくことが予想されます。

レイヤードスケーリングがトレンドとなった時代に、他のパブリックチェーンも独自のレイヤー2プロジェクトのサポートを急ぐかどうかはまだわかりませんが、モジュラーブロックチェーンインフラストラクチャへのパラダイムシフトがすでに起こっていることは間違いありません。

免責事項：

1. この記事は【极客Web3】からの転載ですが、すべての著作権は原作者【Faust, 极客web3】に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。