Paradigm：イーサリアムの歴史的成長問題とその解決策の詳細解説

原文标题：ガス制限を引き上げる方法、第2部：履歴の成長

原文作者：Storm Slivkoff、Georgios Konstantopoulos

原文编译：Luffy，Foresight News

履歴の成長（History growth）は、現在のイーサリアムのスケーリングにおける最大のボトルネックです。意外なことに、履歴の成長は状態の成長よりも大きな問題となっています。数年以内に、履歴データは多くのイーサリアムノードのストレージ容量を超えるでしょう。

良いニュースは：

• 履歴の成長は、状態の成長よりも解決が容易な問題です。
• 解決策は積極的に開発されています。
• 履歴の成長を解決することで、状態の成長問題が緩和されます。

この記事では、前編でのイーサリアムのスケーリング問題の研究を続け、状態の成長から履歴の成長に焦点を移します。詳細なデータセットを使用して、1) 技術的にイーサリアムのスケーリングボトルネックを理解し、2) イーサリアムのガス制限に関する最適解の議論を助けることを目指します。

履歴の成長とは？

履歴は、イーサリアムがその全ライフサイクルにわたって実行したすべてのブロックとトランザクションの集合であり、創世ブロックから現在のブロックまでのすべてのデータです。履歴の成長は、時間の経過とともに新しいブロックと新しいトランザクションが蓄積されることを指します。

図1は、履歴の成長とさまざまなプロトコル指標およびイーサリアムノードのハードウェア制約との関係を示しています。状態の成長と比較して、履歴の成長は異なるハードウェア制約のセットに制限されています。履歴の成長はネットワークIOに圧力をかけ、新しいブロックとトランザクションがネットワーク全体に伝送される必要があります。また、履歴の成長はノードのストレージスペースにも圧力をかけます。なぜなら、各イーサリアムノードは完全な履歴のコピーを保存するからです。履歴の成長がこれらのハードウェア制約を超える速度で進行すると、ノードはそのピアノードと安定したコンセンサスを達成できなくなります。状態の成長や他のスケーリングボトルネックの概要については、本シリーズの記事の第1部を参照してください。

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

最近まで、各ノードの大部分のネットワークスループットは履歴の伝送（例えば、新しいブロックやトランザクション）に使用されていました。しかし、Dencunハードフォークでblobが導入されたことで、この状況は変わりました。blobは現在、ノードのネットワーク活動の大部分を占めています。しかし、blobは履歴の一部とは見なされません。なぜなら、1) ノードはそれらを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部を参照）が、履歴は超線形的に成長していました。線形成長の成長率は全体の規模を二次的に成長させるため、超線形成長の成長率は全体の規模を二次的に超える成長を引き起こします。この加速はDencunの後に突然停止しました。これはイーサリアムが履歴の成長率の大幅な低下を経験した初めてのことです。
• 最近の履歴の成長の大部分はRollupから来ています：各L2はそのトランザクションのコピーをメインネットに公開します。これにより大量の履歴が生成され、Rollupは過去1年間の履歴成長の最も重要な貢献者となりました。しかし、DencunはL2が履歴ではなくblobを使用してトランザクションデータを公開できるようにしたため、Rollupはもはや大部分のイーサリアムの履歴を生成しなくなりました。この記事の後半でRollupについて詳しく説明します。

イーサリアムの履歴成長の最大の貢献者は誰か？

異なる契約カテゴリが生成する履歴の量は、イーサリアムの使用パターンが時間とともにどのように進化してきたかを明らかにします。図3は、さまざまな契約カテゴリの相対的な貢献を示しています。これは図2と同じデータを標準化したものです。

図3：異なる契約カテゴリの履歴成長への貢献

これらのデータは、イーサリアムの使用パターンの4つの異なる時期を明らかにしています：

• 初期（紫）：イーサリアムの最初の数年間はほとんどチェーン上の活動がありませんでした。これらの初期の契約の大多数は現在では識別が難しく、グラフでは「未知」としてマークされています。
• ERC-20時代（緑）：ERC-20標準は2015年末に最終決定されましたが、2017年と2018年まで顕著な発展はありませんでした。ERC-20契約は2019年に最大の履歴成長の源となりました。
• DEX / DeFi時代（茶）：DEXとDeFi契約は2016年にチェーン上に登場し、2017年に注目を集め始めました。しかし、2020年のDeFi夏まで、これらは履歴成長の最大のカテゴリとはなりませんでした。DeFiとDEX契約は2021年と2022年の一部の期間に履歴成長の50％以上を占めました。
• Rollup時代（灰）：2023年初頭、L2 Rollupはメインネットよりも多くのトランザクションを実行し始めました。Dencun以前の数ヶ月間、彼らは約2/3のイーサリアムの履歴を生成しました。

各時代は、以前よりも複雑なイーサリアムの使用パターンを表しています。時間の経過とともに、複雑さはイーサリアムのスケーリングの一形態と見なすことができ、単純な指標である毎秒のトランザクション量では測定できません。

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

では、blobはどうなのか？

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

図4：Dencunが履歴の成長に与えた影響

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

• Dencun以来、Rollupの履歴成長は約2/3減少しました：ほとんどのRollupはコールデータからblobに移行し、生成する履歴の量が大幅に減少しました。しかし、2024年4月時点で、いくつかのRollupはまだコールデータからblobに移行していません。
• Dencun以来、総履歴成長は約1/3減少しました：DencunはRollupの履歴成長を減少させただけです。他の契約カテゴリの履歴成長はわずかに増加しました。Dencun以降も、履歴の成長は状態の成長の8倍です（詳細は次のセクションを参照）。

blobは履歴の成長速度を低下させましたが、それでもイーサリアムの新しい特性です。現在、blobが存在する場合、履歴の成長速度がどのレベルで安定するかは不明です。

どのくらいの履歴の成長が許容されるのか？

ガス上限を引き上げると、履歴の成長率が増加します。したがって、ガス上限を引き上げる提案（例えば、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は、EIP-4444が今後3年間にわたって各ノードのストレージ負担に与える影響を示しています。これは図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：トレントは最も簡単で信頼性の高い方法です。イーサリアムノードは定期的に履歴の一部をパッケージ化し、公共のトレントファイルとして共有できます。例えば、あるノードは100,000ブロックごとに新しい履歴トレントファイルを作成するかもしれません。erigonのようなノードクライアントは、ある程度非標準的な方法でこのプロセスを実行しています。このプロセスを標準化するためには、すべてのノードクライアントが同じデータフォーマット、同じパラメータ、および同じP2Pネットワークを使用する必要があります。ノードはそのストレージと帯域幅の能力に基づいて、このネットワークに参加するかどうかを選択できます。トレントの利点は、すでに多くのデータツールにサポートされている高いリンダイオープンスタンダードを使用することです。
• ポータルネットワーク：Portal Networkは、イーサリアムデータをホストするために設計された新しいネットワークです。これはトレントに似た方法ですが、データの検証を容易にするための追加機能も提供します。ポータルネットワークの利点は、これらの追加の検証層が軽量クライアントに対して、共有データセットを効果的に検証し、クエリを実行するためのユーティリティを提供することです。
• クラウドホスティング：AWSのS3やCloudflareのR2などのクラウドストレージサービスは、履歴を保存するための安価で高性能な選択肢を提供します。しかし、この方法は、これらのクラウドサービスが常に暗号通貨データをホストする意欲と能力を持っているとは限らないため、より多くの法的リスクとビジネス運営リスクをもたらします。

残りの実施課題は、技術的な課題よりも社会的な課題です。イーサリアムコミュニティは、これらの具体的な実施詳細を調整し、各ノードクライアントに直接統合できるようにする必要があります。特に、創世ブロックから完全同期（スナップショット同期ではなく）を実行するには、イーサリアムノードではなく履歴提供者から履歴を取得する必要があります。これらの変更は技術的にはハードフォークを必要としないため、イーサリアムの次のハードフォークPectraよりも早く実現可能です。

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

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

図7：異なるイーサリアムノードタイプのストレージ負担

言い換えれば、

• アーカイブノードは状態データ、履歴データ、およびアーカイブデータを保存します。誰かが履歴のチェーン状態を簡単にクエリできるようにしたい場合、アーカイブノードを使用できます。
• フルノードは履歴データと状態データのみを保存します。今日のほとんどのノードはフルノードです。フルノードのストレージ負担はアーカイブノードの約半分です。
• EIP-4444以降のフルノードは、状態データと最近1年間の履歴データのみを保存します。これにより、ノードのストレージ負担は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の実施を加速させ、将来のガス上限の引き上げのための余地を確保すべきだと考えています。