Monad Lianchuang: カンクンの後、Rollup のパフォーマンスのボトルネックは何ですか?

原作者: Keone Hon、Monad 共同創設者

編纂：吾妻デイリー

編集者注: 北京時間 3 月 26 日の朝、Monad の共同創設者 Keone Hon は、Personal X のロールアップのパフォーマンス ステータスに関する詳細な記事を公開しました。この記事では、Keone 氏は、カンクンのアップグレード後のロールアップの理論上の TPS 制限を計算する方法を詳しく説明し、一部のレイヤー 2 (ベース) の単一トランザクション料金がアップグレード後も依然として数ドルも高い理由を説明しました。ロールアップが直面する課題、いくつかのボトルネックの制限と改善の可能性について概説しました。

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

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

データ可用性 (DA)

カンクンのアップグレードにおける Blob データ構造 (EIP-4844) の導入により、イーサリアムのデータ可用性 (DA) が大幅に向上し、レイヤー 2 データ同期トランザクションに通常のレイヤー 1 トランザクションと同じ料金を請求する必要がなくなりました。市場で入札します。

現在、Blob の容量はブロックあたり約 3 つの 125 kb BLOB (12 秒)、つまり 31.25 kb/秒です。トランザクションのサイズが約 100 バイトであることを考慮すると、すべてのロールアップの共有 TPS は約 300 であることを意味します。

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

• まず、Rollup がより優れたトランザクション データ圧縮テクノロジを採用して単一トランザクションのサイズを削減すれば、TPS は拡大する可能性があります。

• 次に、理論上、Blob を使用してデータを同期することに加えて、Rollup は引き続き calldata を使用してデータを同期することもできます (つまり、カンクンのアップグレード前の古いソリューション) が、そうすることでさらに複雑になります。

• 第三に、さまざまな ZK ロールアップでステータスを公開する方法に違いがあるため (特に zkSync Era と Starknet)、これらのロールアップでは計算方法と結果も異なります。

ロールアップガス制限

最近、Base はガス料金の爆発的な高騰により多くの注目を集めており、ネットワーク上の通常の取引では数ドルにまで値上がりしています。

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

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

なぜ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: 国家の成長に隠された危険性

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

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

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

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

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

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

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

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

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

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

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

コミュニティの交流

Keone がこの記事を投稿した後、複数の責任者であるレイヤー 2 プロジェクトの主要担当者が投稿の下で対話しました。

zkSyncの共同創設者であるAlex Gluchowski氏は、「ブロックごとにマークルルートを再計算する必要がある」という記事の内容に関して、この点でどう違うのかをMonadに尋ねた。 」

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

Base の責任者である Jesse Pollak 氏もこれを利用して、カンクンでのアップグレード後に Base のガスコストが下落せずに増加した理由を説明し、EIP-4844 によってレイヤー 1 レベルでの DA コストが大幅に削減されたと述べました。ガスコストは削減されるはずでしたが、ネットワーク取引により需要が 5 倍以上に増加し、ベース ネットワーク上のブロックには 250 ガス/秒の制限があり、需要が供給を上回っているため、ガス料金が上昇しています。