原作者: ストーム・スリヴコフ、ゲオルギオス・コンスタントプロス
オリジナル編集：ルフィ、フォーサイトニュース
現在、歴史的な成長がイーサリアムの拡大における最大のボトルネックとなっています。驚くべきことに、国家の成長よりも歴史の成長が大きな問題となっている。数年以内に、履歴データは多くのイーサリアム ノードのストレージ容量を超えるでしょう。
良いニュースは次のとおりです。
歴史の成長は国家の成長よりも解決が容易な問題です。
ソリューションはすでに積極的に開発中です。
歴史的な成長に対処することで、州の成長の問題は軽減されます。
この記事では、パート 1 から引き続きイーサリアムのスケーリング問題を検討し、今度は国家の成長から歴史的な成長に注目を移します。詳細なデータセットを使用することで、私たちの目標は、1) イーサリアムのスケーリングのボトルネックを技術的に理解すること、2) イーサリアムのガス制限に対する最適な解決策に関する議論に貢献することです。
歴史的成長とは何でしょうか？
履歴とは、イーサリアムがその存続期間を通じて実行したすべてのブロックとトランザクションの集合であり、ジェネシスブロックから現在のブロックまでのすべてのデータです。歴史的な成長とは、時間の経過とともに新しいブロックと新しいトランザクションが蓄積されることです。
図 1 は、過去の成長とさまざまなプロトコル メトリックおよびイーサリアム ノードのハードウェア制約を示しています。ヒストリーの成長は、状態の成長とは異なるハードウェア制約によって制限されます。歴史的な成長により、新しいブロックやトランザクションをネットワーク全体に送信する必要があるため、ネットワーク IO に圧力がかかります。各 Ethereum ノードは履歴の完全なコピーを保存するため、履歴の増加によりノードのストレージ容量も圧迫されます。履歴がこれらのハードウェア制限を超えるほど急速に増加すると、ノードはピアと安定した合意に達できなくなります。状態の拡大やその他のスケーリングのボトルネックの概要については、このシリーズのパート 1を参照してください。
図 1: イーサリアム拡張のボトルネック
最近まで、各ノードのネットワーク スループットのほとんどは、履歴 (新しいブロックやトランザクションなど) の送信に使用されていました。これは、Dencun ハード フォークに BLOB が導入されたことで変わりました。 BLOB は現在、ノード ネットワーク アクティビティの大部分を占めています。ただし、BLOB は履歴の一部とはみなされません。1) BLOB はノードによって 2 週間のみ保存され、その後破棄されます。2) イーサリアムの作成時のデータを繰り返す必要はありません。 (1) により、BLOB によって各イーサリアム ノードのストレージ負荷が大幅に増加することはありません。 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 次以上の成長につながります。この加速はデンクンを過ぎると突然止まります。イーサリアムが歴史的な成長率の大幅な低下を経験したのはこれが初めてです。
最近の歴史的な成長の多くはロールアップによるもので、各 L2 はトランザクションのコピーをメインネットに公開します。これにより大量の履歴が生成され、その結果、Rollup が過去 1 年間の歴史の成長に最も大きく貢献したものとなりました。ただし、Dencun では、L2 が履歴の代わりに BLOB を使用してトランザクション データを公開できるため、Rollup はイーサリアム履歴の大部分を生成しなくなります。ロールアップについては、この記事の後半で詳しく説明します。
イーサリアムの歴史的成長に最大の貢献者は誰ですか?
さまざまな契約カテゴリによって生成された履歴ボリュームは、イーサリアムの使用パターンが時間の経過とともにどのように進化したかを明らかにします。図 3 は、さまざまな契約カテゴリの相対的な寄与を示しています。これは、図 2 と同じデータを正規化したものです。
図 3: 歴史的成長に対するさまざまな契約カテゴリーの寄与
データは、イーサリアムの使用パターンの 4 つの異なる期間を明らかにしています。
初期 (紫): イーサリアムの最初の数年間は、オンチェーンでの活動はほとんど、またはまったくありませんでした。これらの初期契約のほとんどは現在、特定することが難しく、チャート上では「不明」と表示されています。
ERC-20 時代 (緑): ERC-20 標準は 2015 年末に最終決定されましたが、2017 年と 2018 年まで大きな発展は見られませんでした。 ERC-20契約は2019年の歴史的成長の最大の源泉となった。
DEX/DeFi 時代 (ブラウン): DEX と DeFi 契約は、2016 年にはすでにチェーンに登場し、2017 年に注目を集め始めました。しかし、DeFiが歴史的な成長の点で最大のカテゴリーになったのは2020年の夏になってからでした。 DeFiとDEX契約は、2021年と2022年の一部の歴史的成長の50%以上を占めました。
ロールアップ時代 (グレー): 2023 年初めに、L2 ロールアップはメインネットよりも多くのトランザクションの実行を開始します。 Dencun に至るまでの数か月間で、彼らはイーサリアムの歴史の約 2/3 を生成しました。
各時代は、以前よりも複雑なイーサリアムの使用パターンを表しています。複雑さは、時間の経過に伴うイーサリアムのスケーリングの一形態として見なすことができ、1 秒あたりのトランザクション数などの単純な指標では測定できません。
最新のデータ月 (2024 年 4 月) では、ロールアップはほとんどの履歴レコードを生成しなくなりました。将来の歴史が DEX と DeFi から生まれるのか、それとも新たな使用パターンが出現するのかは不明です。
ブロブについてはどうですか?
Dencun のハード フォークにより BLOB が導入され、これにより歴史的な成長ダイナミクスが大きく変わり、Rollup は履歴レコードの代わりに安価な BLOB を使用してデータを公開できるようになりました。図 4 は、アップグレード前後の Dencun の過去の成長率を拡大したものです。このグラフは図 2 と似ていますが、各縦線が月ではなく日を表している点が異なります。
図 4: Dencun が歴史的成長に与えた影響
このグラフからいくつかの重要な結論を導き出すことができます。
Dencun 以来、ロールアップの歴史的な増加は約 2/3 に減少しました。ほとんどのロールアップは通話データから BLOB に変換され、生成される履歴の量が大幅に減少しました。ただし、2024 年 4 月の時点で、通話データから BLOB に変換されていないロールアップがまだいくつかあります。
Dencun 以降、歴史的な増加の合計は約 1/3 減少しました。Dencun はロールアップの歴史的な増加のみを減少させました。他の契約カテゴリーでは、歴史的な成長がわずかに増加しました。 Dencun の後でも、歴史的な成長は依然として州の 8 倍の成長です (詳細については次のセクションを参照)。
BLOB は歴史的な成長率を鈍化させてきましたが、依然としてイーサリアムの新しい機能です。ブロブの存在下で歴史的な成長率がどのレベルで安定するかは不明です。
歴史的な成長速度はどの程度まで許容できるのでしょうか?
ガス制限を増やすと、過去の成長率が増加します。したがって、Gas キャップを増やす提案 ( Pump the Gasなど) では、歴史的な成長と各ノードのハードウェア ボトルネックとの関係を考慮する必要があります。
許容可能な過去の成長率を決定するには、現在のノード ハードウェアがネットワークとストレージの観点からどれくらいの期間維持できるかを理解することから始まります。ガス制限が引き上げられるまで歴史的な成長率が Dencun 以前のピークに戻る可能性は低いため、ネットワーク ハードウェアは現状を無期限に維持できる可能性があります。ただし、履歴ストレージの負担は時間の経過とともに増加します。現在のストレージ戦略では、各ノードのストレージ ハードディスクが最終的に履歴レコードでいっぱいになることは避けられません。
図 5 は、イーサリアム ノードのストレージ負荷の経時的な変化を示しており、今後 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 も歴史的な成長に対する大きな制限となっています。ストレージ容量とは異なり、ネットワーク IO 制限は短期的にはノードに問題を引き起こしませんが、将来的にガス制限が増加するため、これらの制限は重要になります。
典型的なイーサリアムノードのネットワーク容量がどの程度の歴史的な増加をサポートできるかを理解するには、歴史的な増加と、再編成率、スロットミス、最終ミス、認証ミス、同期委員会ミスなどのさまざまなネットワーク健全性指標との関係を知る必要があります。など、コミット遅延をヒットしてブロックします。これらの指標の分析はこの記事の範囲を超えていますが、コンセンサス層の健全性に関する以前の調査で詳細な情報が見つかります。さらに、イーサリアム財団の Xatu プロジェクトは、そのような分析を高速化するために公開データセットを構築しています。
歴史的な成長問題をどう解決するか?
歴史の成長は国家の成長よりも解決が容易な問題です。これは、候補提案 EIP-4444 によってほぼ完全に解決できます。この EIP により、各ノードはイーサリアムの履歴データ全体を保存することから、1 年間の履歴データのみを保存するように変更されます。 EIP-4444の実装後は、データストレージはイーサリアムの拡張のボトルネックではなくなり、ガス制限の増加は長期的には制約されなくなります。 EIP -4444 は、ネットワークの長期的な持続可能性に必要です。そうでないと、歴史的な成長が急速に進み、ネットワーク ノードのハードウェアの定期的な更新が必要になります。
図 6 は、今後 3 年間の各ノードのストレージ負荷に対する EIP-4444 の影響を示しています。これは図 4 と同じですが、EIP-4444 実装後のストレージ負荷を表すために細い線が追加されています。
図 6 : イーサリアム ノードのストレージ負荷に対する EIP-4444 の影響
この図からいくつかの重要な結論を導き出すことができます。
EIP-4444 により、現在のストレージの負担が半分になります。ストレージの負担は 1.2 TiB から 633 GiB に低下します。
EIP-4444 は履歴ストレージの負担を安定させます。過去の増加率が一定であると仮定すると、履歴データは生成された速度で破棄されます。
EIP-4444 以降、ノードのストレージ負荷が現在の水準に達するには何年もかかります。これは、ストレージ負荷を増加させる唯一の要因はステートの成長であり、ステートの成長は歴史的な成長よりも遅いためです。
EIP-4444 の実装後も、ノードには 1 年分の履歴が保存されるため、履歴の増加によりある程度のストレージ負荷がかかります。しかし、たとえイーサリアムが世界規模になったとしても、この負担を解決するのは難しくないでしょう。過去の記録保持方法の信頼性が証明されれば、EIP-4444 の 1 年間の有効期限は、数か月、数週間、あるいはそれ以下に短縮される可能性があります。
イーサリアムの履歴を保存するにはどうすればよいですか?
EIP-4444 は、イーサリアム ノード自体によって履歴が保存されない場合、どのように保存する必要があるのかという疑問を提起します。歴史はイーサリアムの検証、会計、分析において中心的な役割を果たすため、それを保存することが重要です。幸いなことに、履歴の保存は 1/n の誠実なデータプロバイダーだけを必要とする単純な問題です。これは、参加者の 1/3 から 2/3 の誠実さを必要とする州の合意問題とは対照的です。ノードオペレーターは、1) ジェネシスブロック以降のすべてのトランザクションを再生し、2) これらのトランザクションが現在のブロックチェーン側と同じ状態ルートで再現されることを確認することによって、履歴データセットの信頼性を検証できます。
履歴を保存する方法はたくさんあります。
トレント/P2P: トレントは最も簡単で信頼性の高い方法です。 Ethereum ノードは定期的に履歴の一部をパッケージ化し、パブリック torrent ファイルとして共有できます。たとえば、ノードは 100,000 ブロックごとに新しい履歴 torrent ファイルを作成する場合があります。 erigon などのノード クライアントは、ある程度標準化されていない方法でこのプロセスをすでに実行しています。このプロセスを標準化するには、すべてのノード クライアントが同じデータ形式、同じパラメータ、および同じ P2P ネットワークを使用する必要があります。ノードは、ストレージと帯域幅の能力に基づいて、このネットワークに参加するかどうかを選択できます。トレントには、すでに多数のデータ ツールでサポートされている高品質のオープン スタンダードを使用するという利点があります。
ポータル ネットワーク:ポータル ネットワークは、イーサリアム データをホストするために特別に設計された新しいネットワークです。これは torrent に似たアプローチですが、データ検証を容易にする追加機能も提供します。ポータル ネットワークの利点は、これらの追加の検証レイヤーが、共有データセットを効率的に検証およびクエリするためのユーティリティをライト クライアントに提供することです。
クラウド ホスティング: AWS の S 3 や Cloudflare の R 2 などのクラウド ストレージ サービスは、履歴を保存するための安価で高性能なオプションを提供します。ただし、これらのクラウド サービスが常に暗号通貨データをホストできるという保証はないため、このアプローチでは、より多くの法的およびビジネス運営上のリスクが生じます。
残りの実装上の課題は、技術的なものよりも社会的なものです。 Ethereum コミュニティは、特定の実装の詳細を調整して、すべてのノード クライアントに直接統合できるようにする必要があります。特に、ジェネシス ブロックから始まる完全同期 (スナップショット同期ではなく) を実行するには、イーサリアム ノードではなく履歴プロバイダーから履歴を取得する必要があります。これらの変更は技術的にハードフォークを必要としないため、イーサリアムの次のハードフォークであるペクトラよりも早く実装される可能性があります。
これらの履歴保存方法はすべて、L2 がメインネットに公開する BLOB データを保存するために使用することもできます。履歴保存と比較すると、BLOB 保存は 1) 総データ量がはるかに大きいため、より困難です。2) メインネット履歴の再生には BLOB が必要ないため、重要性が低くなります。ただし、各 L2 が自身の履歴を再生するには、BLOB の保存が依然として必要です。したがって、何らかの形式の BLOB 保存はイーサリアムのエコシステム全体にとって重要です。さらに、L2 が堅牢な BLOB ストレージ インフラストラクチャを開発すれば、L1 の履歴データも簡単に保存できる可能性があります。
EIP-4444 の前後でさまざまなノード構成によって保存されたデータを直接比較すると便利です。図 7 は、さまざまな Ethereum ノード タイプのストレージ負荷を示しています。状態データはアカウントと契約、履歴データはブロックとトランザクション、アーカイブ データはオプションのデータ インデックスのセットです。この表のバイト数は最新の reth スナップショットに基づいていますが、他のノード クライアントのバイト数もほぼ同等であるはずです。
図 7: さまざまな Ethereum ノード タイプのストレージ負荷
言い換えると、
アーカイブ ノードは、アーカイブ データだけでなく、状態データや履歴データも保存します。アーカイブ ノードは、履歴チェーンの状態を簡単にクエリできるようにしたい場合に使用されます。
フルノードには履歴データとステータスデータのみが保存されます。現在、ほとんどのノードはフルノードです。フル ノードのストレージ負荷はアーカイブ ノードの約半分です。
EIP-4444 以降の完全なノードには、状態データと最新年の履歴データのみが保存されます。これにより、ノードのストレージ負荷が 1.2 TiB から 633 GiB に軽減され、履歴データのストレージ容量が定常状態の値になります。
「ライト ノード」とも呼ばれるステートレス ノードは、データ セットを保存せず、チェーンの最後ですぐに検証できます。このノードタイプは、Verkle の試みや他のステートコミットメントスキームがイーサリアムに追加されると可能になります。
最後に、現在の成長率に単に適応するのではなく、過去の成長率を制限する追加の EIP があります。これにより、短期的にはネットワーク IO の制約内に収まり、長期的にはストレージの制約内に収まるようになります。 EIP-4444 はネットワークの長期的な持続可能性に依然として必要ですが、これらの他の EIP は、イーサリアムが将来的により効率的に拡張するのに役立ちます。
EIP-7623: 通話データの価格を再設定して、過剰な通話データを含む特定のトランザクションのコストを高くする。これらの使用パターンをより高価にすると、一部の使用パターンを通話データから BLOB に変換する必要があります。これにより、歴史的な成長率が低下します。
EIP-4488: 各チャンクに含めることができる通話データの総量に制限を実装します。これにより、履歴レコードの増加率に対してより厳しい制限が課されることになります。
これらの EIP は EIP-4444 よりも実装が簡単であるため、EIP-4444 が運用開始される前の短期的な一時しのぎとして機能する可能性があります。
結論
この記事の目的は、データを使用して 1) 歴史的な成長の仕組みと 2) 問題の解決方法を理解することです。この記事のデータの多くは従来の方法では入手が困難であるため、このデータを利用できるようにすることで、歴史的な成長の問題について新たな洞察が得られることを期待しています。
歴史的な成長は、イーサリアム拡大のボトルネックとして十分な注目を集めてきませんでした。ガスの上限を増やさなくても、イーサリアムの現在の履歴保存規約により、多くのノードは数年以内にハードウェアをアップグレードする必要があります。幸いなことに、これは解決するのが難しい問題ではありません。 EIP-4444 にはすでに明確な解決策があります。私たちは、将来のガスキャップの引き上げを考慮して、この EIP の実施を急ぐ必要があると考えています。
