カンクンのアップグレード後、ロールアップのパフォーマンスのボトルネックは何ですか?

編集者: 東、Odaily Planet Daily

北京時間 3 月 26 日の正午に、Monad の共同創設者 Keone Hon が Rollup のパフォーマンス状況に関する詳細な記事を公開しました。この記事の中で Keone 氏は、ブロック ディスプレイのアップグレード後にロールアップの理論上の TPS 制限をどのように計算すべきかを詳しく説明し、アップグレード後も一部のレイヤー 2 (ベース) の単一トランザクション料金が依然として数ドルもの高さであると説明しました。さらに、Keone 氏は、ロールアップが直面するいくつかのボトルネックと潜在的な改善点についても概説しました。

以下は、Odaily Planet Daily が編集した Keone の原文です。読者の便宜のために、翻訳者が原文にいくつかの追加を加えています。

最近市場では、レイヤー 1 だけでなくレイヤー 2 にも関係する、ロールアップ実行のボトルネックとガス制限についていくつかの議論が行われています。これらのボトルネックについては以下で説明します。

データ可用性 (DA)

EIP-4844 標準に従って、Blob データ構造がブロックチェーンのアップグレードで導入されましたイーサリアムのデータ可用性 (DA) は大幅に改善され、レイヤー 2 データ同期トランザクションは、通常のレイヤー 1 トランザクションと同じ手数料市場で入札する必要がなくなりました。

現在、BLOB の全体的な容量ステータスは、ブロックごと (12 秒)、つまり 31.25 KB ごとに 3 つの 125 KB BLOB を生成することになっています。トランザクションのサイズが約 100 バイトであることを考えると、これは共有すべてのロールアップの TPS は約 300 です。

もちろん、ここには特別な注釈が必要な情報がいくつかあります。

• まず、Rollup がより優れたトランザクション データ圧縮テクノロジを採用して 1 つのトランザクションのサイズを削減すれば、TPS は拡大する可能性があります。
• 2 つ目は、理論上、Blob を使用してデータを同期することに加えて、Rollup は引き続き calldata を使用してデータを同期することもできるということです (つまり、カンクンのアップグレード前の古いソリューション)。さらなる複雑さ。
• 第三に、さまざまな ZK ロールアップでステータスを公開する方法に違いがあるため (特に zkSync Era と Starknet)、これらのロールアップでは計算方法と結果も異なります。

ロールアップのガス制限について

最近、ガス料金の高騰によりBaseが大きな注目を集めており、ネットワーク上の一部の通常トランザクションの手数料が数ドルにまで値上がりしています。

カンクンのアップグレード後、ベース ネットワークが一時的に減少しただけで、今ではアップグレード前のレベルに戻ったか、あるいはそれを超えているのはなぜですか?これは、Base のブロックには総ガス制限があり、コード内のパラメーターを通じて強制されるためです。

Base によって現在使用されているガス パラメータは Optimism と同じです、つまり、Layer2 ブロックあたり 500 万ガス (2 秒) という合計制限があります。ネットワークが供給（エリア）ブロックスペースを超える）、価格決済はオンデマンド実行メカニズムを採用し、その結果ネットワーク上のガスが急増します。

Base が総ガス制限を増やさないのはなぜですか?言い換えれば、なぜロールアップで総ガス制限を設定する必要があるのでしょうか?

上記のデータ可用性に関する TPS の上限に加えて、実際には他に 2 つの大きな理由があります。1 つは実行スループットのボトルネック、もう 1 つは状態増大の隠れた危険です。

質問 1: 実行スループットのボトルネック

一般に、EVM ロールアップは Geth からフォークされた EVM を実行します。つまり、Geth クライアントと同様のパフォーマンス特性があることを意味します。

Geth のクライアントはシングルスレッド (つまり、一度に 1 つのタスクしか処理できません) であり、LevelDB/PebbleDB エンコーディングを使用し、その状態をマークル パトリシア トライ (MPT) に保存します。これは、ソリッド ステート ドライブ (SSD) にデータを保存するための基礎となる層として別のツリー構造 (LSM ツリー) を使用する汎用データベースです。

ロールアップの場合、「状態アクセス」(マークル トライから値を読み取る) と「状態更新」(各ブロックの最後にマークル トライを更新する) は、実行プロセスで最もコストのかかるリンクです。これは、SSD からの 1 回の読み取りコストが 40 ～ 100 マイクロ秒であること、およびマークル トライ データ構造が別のデータ構造 (LSM ツリー) に埋め込まれているため、多くの不必要な追加の Find が必要になるためです。

このリンクは、複雑なファイル システム内で特定のファイルを見つけるプロセスとして想像できます。ルート ディレクトリ (トライ ルート ノード) からターゲット ファイル (リーフ ノード) まで移動する必要があります。各ファイルを検索するときは、データベース LevelDB で特定のキーを見つける必要があり、LevelDB 内で LSM ツリーと呼ばれる別のデータ構造を通じて実際のデータ ストレージ操作を実行する必要があります。このプロセスにより、多くの追加検索が発生します。これらの追加の手順により、データ全体の読み取りと更新が非常に遅くなり、非効率になります。

Monad の設計では、MonadDb を通じてこの問題を解決しました。 MonadDb は、マークル トライをディスク上に直接保存することをサポートし、LevelDb のオーバーヘッドを回避するカスタム データベースです。非同期 IO をサポートし、複数の読み取りを並行して処理できるようにし、ファイル システムをバイパスします。

さらに、Monad が採用している「オプティミスティック並列実行」機構により、複数のトランザクションを並列処理し、そのステータスを MonadDb から並列に抽出することができます。

ただし、Rollup にはこれらの最適化がないため、実行スループットにボトルネックがあります。

Erigon/Reth クライアントにはデータベース効率のために特定の最適化が施されており、一部のロールアップ クライアントもこれらのクライアントに基づいて構築されていることに注意してください (OP-Reth など)。 Erigon/Reth はフラットなデータ構造を採用しているため、ある程度の読み取り時のクエリコストが削減されますが、非同期読み取りやマルチスレッド処理には対応していません。さらに、ブロックごとにマークル ルートを再計算する必要がありますが、これもかなり遅いプロセスです。

質問 2: 状態の成長に隠された危険性

他のブロックチェーンと同様に、Rollup もアクティブな状態が急速に成長するのを防ぐためにスループットを制限します。

市場でよくある議論は、州の成長率が懸念される理由は、州データが大幅に増加すると、ソリッド ステート ドライブ (SSD) 機器の需要も上方調整する必要があるためであるというものです。しかし、これは少し不正確だと思います。SSD は比較的安価で (高品質の 2TB SSD は約 200 ドルです)、イーサリアムの完全な状態は、約 10 年の歴史の中で「わずか」約 200 GB です。純粋なストレージの観点から見ると、まだ成長の余地がたくさんあります。

さらに大きな隠れた危険は、ステータスが増大し続けるにつれて、指定されたステータス フラグメントをクエリする時間が長くなるということです。これは、現在のマークル パトリシア トライは、「ノードに子ノードが 1 つだけある」という条件が満たされた場合に「ショートカット」を使用するため、トライの有効な深さが減り、クエリ プロセスが高速化される可能性があります。マークル トライのステータスはますます充実しており、利用できる「ショートカット」はますます少なくなります。

要約すると、国家の成長に潜む危険は、最終的には国家へのアクセス効率の問題であるため、国家へのアクセスを加速することが、国家の成長をより持続可能にする鍵となります。

なぜハードウェアを最適化するだけではうまくいかないのでしょうか?

Layer2 は現在まだ比較的集中化された状態にあります。つまり、ネットワークは依然として単一のシーケンサーに依存して状態を維持し、ブロックを生成します。では、すべての状態をメモリに保存できるように、非常に大容量の RAM (ランダム アクセス メモリ) を搭載したハードウェア上でソータを実行するのはなぜではないのかと疑問に思う人もいるかもしれません。

これには 2 つの理由があります。

第一に、これはイーサリアムのメインネットワークのデータ可用性のボトルネック問題を解決するものではありません。Base の現在の状況に基づいていますが、ネットワークガスの急増は、イーサリアムのメインネットワークのデータ可用性能力が不十分であることが原因ではありません。しかし、長期的には、これは最終的にロールアップを制限する大きなボトルネックになります。

2 番目の問題は分散化です。シーケンサは依然として高度に集中化されていますが、ネットワーク運用に関係する他の役割も重要です。また、ノードを独立して実行し、同じトランザクションを再生できる必要もあります。履歴と維持同じ状態。

Layer1 の生のトランザクション データと状態コミットだけでは、完全な状態のロックを解除するには十分ではありません。完全な状態にアクセスする必要があるアクター (販売者、取引所、自動トレーダーなど) は、完全な Layer2 ノードを実行してトランザクションを処理し、状態の最新のコピーを保持する必要があります。

ロールアップは依然としてブロックチェーンであり、ブロックチェーンは、グローバルな状態の共有を通じてグローバルな調整を実現できるという点で興味深いものです。すべてのブロックチェーンには強力なソフトウェアが必要であり、ハードウェアを最適化するだけでは問題を解決するのに十分ではありません。

コミュニティの交流

Keone がこの記事を投稿した後、複数の責任ある Layer2 プロジェクトの主要担当者がアップデートの下で交流しました。

zkSync の共同創設者 Alex Gluchowski は、「マークル ルートはブロックごとに再計算する必要がある」という記事に応えて、この点において Monad は違うのではないかと質問しました。

Keone の返答は、各ブロックの後にマークル ルートを計算するための最適化されたアルゴリズムが存在するというものでした。

Base の責任者である Jesse Pollak 氏もこれを使って、カンクンのアップグレード後に Base のガソリン価格が下落するのではなく増加した理由を説明しました。 -4844 は、Layer1 レベルを大幅に削減しました。DA コストとガス料金は削減されるはずでしたが、ネットワーク トランザクション需要が 5 倍以上に増加し、ベース ネットワーク上のブロックには 250 ガス/秒の制限があるため、需要供給量を超えてガス料金が高騰する。

以上がカンクンのアップグレード後、ロールアップのパフォーマンスのボトルネックは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。