パラダイム: イーサリアムの歴史的成長の問題と解決策の詳細な説明

オリジナル記事：ストーム・スリヴコフとゲオルギオス・コンスタントポロス

原文翻訳: ルフィ、フォーサイトニュース

履歴の増加は現在、イーサリアムの拡張における最大のボトルネックです。驚くべきことに、履歴の増加は状態の増加よりも大きな問題になっています。数年以内に、履歴データは多くのイーサリアムノードのストレージ容量を超えるでしょう。

良いニュースは次のとおりです。

• 歴史の成長は国家の成長よりもはるかに簡単に解決できる問題です。

• 解決策はすでに積極的に開発されています。

• 履歴成長を解決すると、状態成長の問題が軽減されます。

この投稿では、パート 1 から引き続き Ethereum のスケーリングについて調査し、今度は状態の成長から過去の成長に焦点を移します。洗練されたデータセットを使用して、1) Ethereum のスケーリングのボトルネックを技術的に理解し、2) Ethereum のガス制限に対する最適なソリューションに関する議論を支援することを目標としています。

歴史的成長とは何ですか?

履歴とは、Ethereum のライフサイクル全体を通じて実行されたすべてのブロックとトランザクションのコレクションです。これは、ジェネシス ブロックから現在のブロックまでのすべてのデータです。履歴の成長とは、時間の経過とともに新しいブロックと新しいトランザクションが蓄積されることです。

図 1 は、履歴の増加とさまざまなプロトコル メトリックおよび Ethereum ノードのハードウェア制約との関係を示しています。履歴の増加は、状態の増加とは異なる一連のハードウェア制約によって制限されます。履歴の増加は、新しいブロックとトランザクションをネットワーク全体に送信する必要があるため、ネットワーク IO に負担をかけます。また、各 Ethereum ノードが履歴の完全なコピーを保存するため、ノードのストレージ スペースにも負担をかけます。履歴の増加がこれらのハードウェア制約を超えるほど速い場合、ノードはピアと安定したコンセンサスに達することができなくなります。状態の増加とその他のスケーリング ボトルネックの概要については、次を参照してください。 パート1 このシリーズの。

図1: イーサリアムのスケーリングボトルネック

最近まで、各ノードのネットワーク スループットのほとんどは、履歴 (新しいブロックやトランザクションなど) の転送に使用されていました。これは、Dencun ハード フォークでの BLOB の導入によって変わりました。現在、BLOB はノード ネットワーク アクティビティの大部分を占めています。ただし、BLOB は、1) ノードによって 2 週間だけ保存され、その後破棄される、2) Ethereum ジェネシスからのデータを繰り返す必要がない、という理由で、履歴の一部とは見なされません。(1) のため、BLOB は各 Ethereum ノードのストレージ負荷を大幅に増加させることはありません。BLOB については、この記事の後半で説明します。

この記事では、履歴の成長に焦点を当て、履歴と状態の関係について説明します。状態の成長と履歴の成長には重複するハードウェア制約があるため、これらは関連する問題であり、一方を解決すると他方の解決に役立ちます。

これまでの成長速度はどのくらいだったのでしょうか?

図 2 は、イーサリアムの誕生以来の過去の成長率を示しています。各縦線は 1 か月の成長を表しています。y 軸は、その月の過去の成長のギガバイト数を表しています。トランザクションは「宛先アドレス」によって分類され、RLP (https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/) バイトを使用してサイズが決定されます。簡単に識別できない契約は「不明」に分類されます。「その他」カテゴリには、インフラストラクチャやゲームなどのさまざまな小さなカテゴリが含まれます。

図2: イーサリアムの歴史的成長率の推移

上記のグラフからわかる重要なポイントをいくつか紹介します。

• 履歴は状態よりも 6 ～ 8 倍速く増加します。履歴の増加は最近 36.0 GiB/月でピークに達し、現在は 19.3 GiB/月です。状態の増加はおよそ 6.0 GiB/月でピークに達し、現在は 2.5 GiB/月です。増加と累積サイズの観点から見た履歴と状態の比較については、この記事の後半で説明します。

• Decun 以前は、歴史的成長率は加速していました。状態は長年にわたりほぼ線形に成長していましたが (パート 1 を参照)、歴史は超線形でした。線形成長率が全体のサイズの 2 乗成長につながることを考えると、超線形成長率は全体のサイズの 2 乗以上の成長につながります。この加速は、Dencun 以降突然停止しました。これは、イーサリアムが歴史的成長率の大幅な低下を経験した初めてのケースです。

• 最近の履歴成長のほとんどは、ロールアップによるものです。各 L2 は、トランザクションのコピーをメインネットに公開します。これにより大量の履歴が生成され、ロールアップが過去 1 年間の履歴成長に最も重要な貢献者となりました。ただし、Dencun では、L2 が履歴ではなく BLOB を使用してトランザクション データを公開できるため、ロールアップはもはや Ethereum 履歴の大部分を生成しません。ロールアップについては、この記事の後半で詳しく説明します。

イーサリアムの歴史的な成長に最も貢献したのは誰ですか?

さまざまな契約カテゴリによって生成された契約の履歴数は、Ethereum の使用パターンが時間の経過とともにどのように進化したかを示しています。図 3 は、さまざまな契約カテゴリの相対的な貢献を示しています。これは、図 2 と同じデータを正規化したものです。

図3: 契約タイプ別の成長率の推移

データは、Ethereum の使用パターンの 4 つの異なる期間を明らかにしています。

• 初期（紫色）：イーサリアムの最初の数年間は、オンチェーンのアクティビティはほとんどありませんでした。これらの初期の契約のほとんどは現在では識別が難しく、チャートでは「不明」としてマークされています。

• ERC-20 時代 (緑): ERC-20 標準は 2015 年後半に完成しましたが、2017 年と 2018 年まで大きな勢いを得ることはありませんでした。ERC-20 契約は、2019 年の歴史的な成長の最大の原因でした。

• DEX/DeFi 時代 (ブラウン): DEX と DeFi 契約は 2016 年にはすでにオンチェーンに登場し、2017 年に勢いを増し始めました。しかし、2020 年の DeFi サマーまで、これらが歴史的成長の点で最大のカテゴリになることはありませんでした。DeFi と DEX 契約は、2021 年と 2022 年の一部で 50% 以上の歴史的成長を占めました。

• ロールアップ時代 (グレー): L2 ロールアップは、2023 年初頭にメインネットよりも多くのトランザクションを実行し始めます。Dencun の前の数か月で、ロールアップは Ethereum 履歴の約 2/3 を生成しました。

各時代は、それ以前の時代よりも複雑な Ethereum の使用パターンを表しています。複雑さは、時間の経過に伴う Ethereum のスケーリングの一形態として捉えることができ、1 秒あたりのトランザクション数などの単純な指標では測定できません。

最新のデータ月（2024年4月）では、ロールアップはもはや履歴の大部分を生成しません。将来の履歴がDEXとDeFiから来るのか、それとも新しい使用パターンが出現するのかは不明です。

ブロブはどうですか?

Dencun ハードフォークでは BLOB が導入され、Rollups が履歴レコードの代わりに安価な BLOB を使用してデータを公開できるようになり、履歴成長のダイナミクスが大きく変わりました。図 4 は、Dencun アップグレード前後の履歴成長率を拡大したものです。このグラフは図 2 と似ていますが、各縦線が 1 か月ではなく 1 日を表している点が異なります。

図4: デンクンが歴史的成長に与えた影響

このグラフからいくつかの重要な結論を導き出すことができます。

• Dencun 以降、ロールアップの履歴成長は約 2/3 減少しました。ほとんどのロールアップは通話データから BLOB に変換され、生成される履歴の量が大幅に削減されました。ただし、2024 年 4 月時点で、通話データから BLOB にまだ変換されていないロールアップがまだいくつかあります。

• Dencun 以降、全体的な履歴成長は約 1/3 減少しました。Dencun はロールアップの履歴成長のみを削減しました。他の契約カテゴリの履歴成長はわずかに増加しました。Dencun 後でも、履歴成長は依然として州の成長の 8 倍です (詳細については次のセクションを参照してください)。

ブロブは過去の成長率を低下させましたが、まだイーサリアムの新しい機能であり、ブロブが導入された場合に過去の成長率がどのレベルで安定するかは不明です。

歴史的成長はどの程度の速さであれば許容されるのでしょうか?

ガス制限を増やすと、過去の成長率が上がります。したがって、ガス制限を増やす提案（ ガソリンを入れる ）では、過去の成長と各ノードのハードウェアボトルネックの関係を考慮する必要があります。

許容できる履歴増加率を決定するには、まず、現在のノード ハードウェアがネットワークとストレージの面でどれだけ長く維持できるかを理解する必要があります。履歴増加率がガス制限が引き上げられる前に Dencun 以前のピークに戻る可能性は低いため、ネットワーク ハードウェアはおそらく現状を無期限に維持できます。ただし、履歴のストレージ負荷は時間の経過とともに増加し続けます。現在のストレージ戦略では、各ノードのストレージ ハード ディスクが最終的に履歴レコードでいっぱいになることは避けられません。

図 5 は、Ethereum ノードのストレージ負荷の経時変化を示し、今後 3 年間のストレージ負荷の増加を予測しています。予測は 2024 年 4 月の成長率を示しています。成長率は、将来的に使用パターンやガス制限が変化すると増加または減少する可能性があります。

図5: 歴史の大きさ、 状態、およびフルノードストレージの負荷

この図からいくつかの重要な結論を導き出すことができます。

• 履歴は状態の約 3 倍のストレージ スペースを占有します。履歴は状態の約 8 倍の速さで増加するため、この差は時間の経過とともに大きくなります。

• 1.8 TiB は重要なしきい値であり、多くのノードはストレージ ハード ディスクのアップグレードを余儀なくされます。2 TB は一般的なストレージ ハード ディスクのサイズで、1.8 TiB の空き領域しか提供しません。TB (1 兆バイト) は TiB (= 1024^4 バイト) とは異なる単位であることに注意してください。多くのノード オペレーターにとって、実際の重要なしきい値はさらに低くなります。これは、合併後、バリデーターは実行クライアントと一緒にコンセンサス クライアントを実行する必要があるためです。

• 重要なしきい値は 2 ～ 3 年で到達します。ガス制限を少しでも増やすと、それに応じてこの時間が短縮されます。このしきい値に達すると、ノード オペレーターに大きなメンテナンス負担がかかり、追加のハードウェア ($300 NVME ドライブなど) の購入が必要になります。

状態データとは異なり、履歴データは追加のみ可能で、アクセス頻度ははるかに低くなります。したがって、理論的には、履歴データは状態データとは別に、より安価なストレージ メディアに保存できます。これは、Geth などの一部のクライアントによって実現できます。

ストレージ容量に加えて、ネットワーク IO も過去の成長に対するもう 1 つの大きな制限です。ストレージ容量とは異なり、ネットワーク IO の制限は短期的にはノードに問題を引き起こしませんが、将来ガス制限が増加すると、これらの制限が重要になります。

典型的な Ethereum ノードのネットワーク容量がどの程度の歴史的成長をサポートできるかを理解するには、歴史的成長と、再編成率、スロット ミス、ファイナリティ ミス、証明ミス、同期委員会ミス、ブロック送信遅延などのさまざまなネットワーク ヘルス メトリックとの関係を知る必要があります。これらのメトリックの分析はこの記事の範囲外ですが、コンセンサス レイヤーのヘルスに関する以前の調査でさらに詳しい情報を確認できます。さらに、Ethereum Foundations Xatu プロジェクトでは、このような分析を加速するために公開データセットを構築しています。

歴史的成長の問題をどう解決するか?

履歴の増加は、状態の増加よりもはるかに簡単に解決できる問題です。候補提案 EIP-4444 によってほぼ完全に解決できます。この EIP は、各ノードが Ethereum の履歴全体を保存することから、1 年間の履歴のみを保存するように変更します。EIP-4444 を実装すると、データ ストレージが Ethereum の拡張のボトルネックではなくなり、長期的にはガス制限の増加が制約ではなくなります。EIP-4444 は、ネットワークの長期的な持続可能性に必要です。そうしないと、履歴の増加率が非常に速くなり、ネットワーク ノードのハードウェアを定期的に更新する必要があります。

図 6 は、今後 3 年間における EIP-4444 が各ノードのストレージ負荷に与える影響を示しています。これは図 4 と同じですが、EIP-4444 の実装後のストレージ負荷を表す薄い線が追加されています。

図6 : EIP-4444 が Ethereum ノードのストレージ負荷に与える影響

この図からいくつかの重要な結論を導き出すことができます。

• EIP-4444 により、現在のストレージ負荷が半分になります。ストレージ負荷は 1.2 TiB から 633 GiB に減少します。

• EIP-4444 は、履歴ストレージの負荷を安定させます。履歴の成長率が一定であると仮定すると、履歴データは生成された速度で破棄されます。

• EIP-4444 以降、ノードのストレージ負荷が現在のレベルに達するまでには何年もかかります。これは、状態の増加がストレージ負荷を増加させる唯一の要因であり、状態の増加が過去の増加よりも遅いためです。

EIP-4444 の実装後、ノードは 1 年間の履歴を保存するため、履歴の増加によって一定のストレージ負荷が発生します。ただし、Ethereum が世界規模に達したとしても、この負荷を解決するのは難しくありません。履歴保存方法が信頼できることが証明されれば、EIP-4444 の 1 年間の有効期限は数か月、数週間、またはそれよりも短くなる可能性があります。

Ethereum の履歴を保存するにはどうすればいいですか?

EIP-4444 は、次のような疑問を提起します。履歴が Ethereum ノード自体によって保存されない場合、どのように保存すればよいのでしょうか。履歴は Ethereum の検証、アカウンティング、分析において中心的な役割を果たすため、履歴の保存は非常に重要です。幸い、履歴の保存は、1/n の正直なデータ プロバイダーのみを必要とする単純な問題です。これは、参加者の 1/3 から 2/3 が正直であることを必要とする状態コンセンサス問題とはまったく対照的です。ノード オペレーターは、1) ジェネシス ブロック以降のすべてのトランザクションを再生し、2) これらのトランザクションが現在のブロックチェーン エンドと同じ状態ルートを再現することを確認することで、履歴データ セットの信頼性を検証できます。

歴史を保存する方法はたくさんあります。

• トレント/P2P: トレントは最もシンプルで信頼性の高い方法です。Ethereum ノードは定期的に履歴の一部をパッケージ化し、パブリック トレント ファイルとして共有できます。たとえば、ノードは 100,000 ブロックごとに新しい履歴トレント ファイルを作成する場合があります。Erigon などのノード クライアントは、すでにこのプロセスを多少標準化されていない方法で実行しています。このプロセスを標準化するには、すべてのノード クライアントが同じデータ形式、同じパラメーター、同じ P2P ネットワークを使用する必要があります。ノードは、ストレージと帯域幅の能力に基づいて、このネットワークに参加するかどうかを選択できます。トレントには、多数のデータ ツールですでにサポートされている、非常に柔軟なオープン スタンダードを使用できるという利点があります。

• ポータルネットワーク: ポータルネットワーク は、Ethereum データをホストするために特別に設計された新しいネットワークです。これは Torrent のようなアプローチですが、データの検証を容易にする追加機能もいくつか提供しています。Portal Network の利点は、これらの追加の検証レイヤーにより、軽量クライアントが共有データセットを効率的に検証およびクエリできるユーティリティが提供されることです。

• クラウド ホスティング: AWS の S3 や Cloudflare の R2 などのクラウド ストレージ サービスは、履歴レコードを保存するための安価で高性能なオプションを提供します。ただし、これらのクラウド サービスが常に暗号化されたデータをホストできるという保証がないため、このアプローチには法的およびビジネス運用上のリスクが伴います。

残りの実装上の課題は、技術的なものというよりは社会的なものです。Ethereum コミュニティは、特定の実装の詳細を調整して、すべてのノード クライアントに直接統合できるようにする必要があります。特に、ジェネシス ブロックから完全な同期 (スナップショット同期ではなく) を実行するには、Ethereum ノードではなく履歴プロバイダーから履歴を取得する必要があります。これらの変更は技術的にはハード フォークを必要としないため、Ethereum の次のハード フォークである Pectra よりも早く実装できます。

これらの履歴保存方法はすべて、L2 がメインネットに公開する BLOB データを保存するためにも使用できます。履歴保存と比較すると、BLOB 保存は 1) データの総量がはるかに大きいためより困難であり、2) メインネットの履歴を再生するために BLOB は必要ないため重要性が低くなります。ただし、各 L2 が独自の履歴を再生するには、BLOB 保存が依然として必要です。したがって、何らかの形の BLOB 保存は、Ethereum エコシステム全体にとって重要です。さらに、L2 が強力な BLOB ストレージ インフラストラクチャを開発すれば、L1 履歴データも簡単に保存できる可能性があります。

EIP-4444 の前後でさまざまなノード構成によって保存されたデータセットを直接比較すると役立ちます。図 7 は、さまざまな Ethereum ノード タイプのストレージ負荷を示しています。状態データはアカウントと契約、履歴データはブロックとトランザクション、アーカイブ データはオプションのデータ インデックス セットです。この表のバイト数は最近の reth スナップショットに基づいていますが、他のノード クライアントの数値もほぼ同等であるはずです。

図7: 異なるEthereumノードタイプのストレージ負荷

言い換えると、

• アーカイブ ノードには、アーカイブ データだけでなく、状態データと履歴データも保存されます。アーカイブ ノードは、履歴チェーンの状態を簡単に照会したい場合に使用できます。

• フルノードは履歴データと状態データのみを保存します。現在、ほとんどのノードはフルノードです。フルノードのストレージ負荷は、アーカイブノードの約半分です。

• EIP-4444 以降、フルノードには過去 1 年間の状態データと履歴データのみが保存されます。これにより、ノードのストレージ負荷が 1.2 TiB から 633 GiB に軽減され、履歴データのストレージ容量が安定した値になります。

• ステートレスノードは「ライトノード」とも呼ばれ、データセットを一切保存せず、チェーンの最後ですぐに検証できます。このタイプのノードは、Verkle の試みやその他の状態コミットメントスキームが Ethereum に追加されると可能になります。

最後に、現在の成長率に適応するだけでなく、過去の成長率を制限する EIP がいくつかあります。これにより、短期的にはネットワーク IO 制約内に、長期的にはストレージ制約内に留まることができます。EIP-4444 はネットワークの長期的な持続可能性に依然として必要ですが、これらの他の EIP は、将来的に Ethereum をより効率的に拡張するのに役立ちます。

• EIP-7623: 通話データの価格を再設定し、通話データが多すぎる特定のトランザクションのコストを高くします。これらの使用パターンのコストが高くなると、一部の使用パターンで通話データから BLOB への変換が強制されます。これにより、過去の成長率が低下します。

• EIP-4488: 各ブロックに含めることができる通話データの合計量に制限を課します。これにより、履歴が増加する速度に厳しい制限が課せられます。

これらの EIP は EIP-4444 よりも実装が簡単なので、EIP-4444 が実稼働に入るまでの短期的な暫定措置として使用できます。

結論

この記事の目的は、データを使用して 1) 歴史的成長の仕組みと 2) 問題の解決方法を理解することです。この記事のデータの多くは従来の方法では入手が難しいため、このデータを公開することで歴史的成長の問題に対する新たな洞察が得られることを期待しています。

イーサリアムの拡張のボトルネックとしての履歴の増加は、十分な注目を集めていません。ガス制限を増やさなくても、イーサリアムの現在の履歴保存の慣行により、数年後には多くのノードがハードウェアをアップグレードせざるを得なくなります。幸いなことに、これは解決が難しい問題ではありません。EIP-4444 にはすでに明確な解決策があります。私たちは、将来のガス制限の増加に備え、この EIP の実装を加速する必要があると考えています。

オリジナルリンク

この記事はインターネットから引用したものです: パラダイム: イーサリアムの歴史的成長の問題と解決策の詳細な説明

関連: ビットコインのマイナーは半減期を前に事業維持に苦戦

概要 今年のビットコイン半減期により、マイニング報酬は3.125 BTCに削減され、マイナーの収益性が課題となります。 CryptoQuantは、前回の半減期以降、マイナーのハッシュ価格が30%下落したと報告しており、さらなる下落が見込まれています。 競争とコストが増加し、ビットコインネットワークのハッシュレートが600 EH/sに達し、収益に影響を与えています。 約10日後、ビットコインコミュニティは、ビットコインの半減期という重要なイベントを目撃します。 この現象により、ビットコインブロックのマイニング報酬が6.25ビットコインから3.125ビットコインに半減し、マイナーの収益性が圧迫されます。 マイナーは現在、時間との競争に陥っており、収益を維持するためにビットコインの価格を高くする必要があります。 ビットコインマイナーが課題に直面する理由 BeInCryptoと共有されたCryptoQuantのレポートによると、マイナーのハッシュ価格は、2020年5月の前回の半減期以降、30%下落しています。 現在、1秒あたりテラハッシュあたり$0.11と評価されていますが、これは…