Paradigm：イーサリアムの歴史的な成長課題とその解決策を詳細に解説
TechFlow厳選深潮セレクト
Paradigm：イーサリアムの歴史的な成長課題とその解決策を詳細に解説
EIP-4444は、イーサリアムの歴史的成長問題を解決し、Gasリミットの増加に向けた余地を提供することができる。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Storm Slivkoff、Georgios Konstantopoulos
翻訳：Luffy，Foresight News
歴史データの増加（History growth）は現在、イーサリアムスケーリングにおける最大のボトルネックとなっている。驚くべきことに、これはステートの増加よりも大きな問題になりつつある。数年以内に、歴史データは多くのイーサリアムノードのストレージ容量を超えるだろう。
しかし朗報もある：
-
歴史データの増加は、ステートの増加よりも解決が容易である。
-
既に解決策の開発が積極的に進められている。
-
歴史データの増加を解決すれば、ステートの増加も緩和される。
本稿では、第1部で取り上げたイーサリアムのスケーリング課題をさらに掘り下げ、焦点をステートの増加から歴史データの増加へと移す。詳細なデータセットを用いて、1) イーサリアムのスケーリングボトルネックを技術的に理解し、2) イーサリアムのGasリミットの最適値に関する議論を促進することを目指す。
歴史データの増加とは何か？
「歴史」とは、イーサリアムの創世ブロックから現在のブロックまでに実行されたすべてのブロックとトランザクションの集合であり、ネットワークの全期間にわたるデータそのものである。歴史データの増加とは、時間の経過とともに新たなブロックやトランザクションが積み重なることで生じる現象だ。
図1は、歴史データの増加と各種プロトコル指標、およびイーサリアムノードのハードウェア制約との関係を示している。ステートの増加とは異なり、歴史データの増加は異なる一連のハードウェア制約によって制限される。歴史データの増加はネットワークIOに負荷をかける。なぜなら、新しいブロックとトランザクションはネットワーク全体で伝播しなければならないためだ。また、各イーサリアムノードが完全な履歴のコピーを保存するため、ストレージ容量にも圧力をかける。もし歴史データの増加速度がこれらのハードウェア制約を超えるほど速ければ、ノードはピア間で安定したコンセンサスを維持できなくなる。ステートの増加や他のスケーリングボトルネックの概要については、本シリーズの第1部を参照されたい。
図1：イーサリアムのスケーリングボトルネック
つい最近まで、各ノードの大部分のネットワークトゥルーは履歴データ（例：新規ブロックやトランザクション）の転送に使われていた。しかしDencunハードフォークにより導入されたblobにより、状況は変化した。現在、blobがノードのネットワーク活動の大部分を占めるようになっている。ただし、blobは以下2点の理由から「歴史データ」には含まれない：1）ノードはblobを2週間だけ保存してその後破棄する、2）blobは創世からのデータの再計算を必要としない。特に(1)のため、blobは各イーサリアムノードのストレージ負担を大きく増加させることはない。blobについては後ほど詳しく説明する。
本稿では、歴史データの増加に注力し、歴史とステートの関係について考察する。ステートの増加と歴史データの増加は一部のハードウェア制約を共有しているため、これらは関連する課題であり、一方を解決することで他方の改善にもつながる。
歴史データの増加はどのくらい速いか？
図2は、イーサリアム創世以降の歴史データの増加率を示している。各縦線は1か月分の増加を表しており、Y軸はその月の履歴増加分（ギガバイト単位）を示す。トランザクションは「宛先アドレス」に基づき分類されており、サイズはRLPバイト表現で測定されている。識別困難なコントラクトは「不明」として分類され、「その他」カテゴリにはインフラやゲームなど複数の小規模カテゴリが含まれている。
図2：イーサリアムの歴史データ増加率の推移
上記のグラフから読み取れる主なポイント：
-
歴史データの増加速度は、ステートの増加速度の6〜8倍速い：歴史データの増加率は最近36.0 GiB/月のピークに達し、現在は19.3 GiB/月。一方、ステートの増加率はピーク時で約6.0 GiB/月、現在は2.5 GiB/月程度。歴史データとステートの増加および累計サイズの比較については、後述する。
-
Dencun以前、歴史データの増加率は加速していた：ステートは長年にわたりほぼ線形に増加していた（第1部参照）のに対し、歴史データは超線形的（スーパーリニア）な増加を示していた。線形的な増加率でも全体としては二次関数的に規模が拡大するが、超線形的な増加率ではそれ以上の拡大が生じる。この加速はDencun後に突然停止した。これはイーサリアムが歴史データの増加率の大幅な低下を初めて経験した瞬間だった。
-
直近の歴史データ増加の大部分はRollupによるものだった：各L2は自らのトランザクションのコピーをメインネットに公開している。これにより大量の履歴データが生成され、過去1年間でRollupが歴史データ増加の最大の寄与者となっていた。しかしDencunにより、L2は履歴データではなくblobを使ってトランザクションデータを公開できるようになったため、Rollupはもはや大部分のイーサリアム履歴データを生成しなくなった。Rollupについては後ほど詳しく説明する。
イーサリアムの歴史データ増加に最も大きく貢献しているのは誰か？
異なるコントラクトカテゴリが生成する履歴データ量は、イーサリアムの利用パターンの変遷を浮き彫りにする。図3は、さまざまなコントラクトカテゴリの相対的な貢献度を示している。これは図2と同じデータを正規化したものである。
図3：異なるコントラクトカテゴリの歴史データ増加への貢献度
これらのデータからは、イーサリアムの利用パターンが四つの異なる時代に分けられることがわかる：
-
初期（紫色）：イーサリアムの最初の数年間はオンチェーン活動がほとんどなかった。当時のコントラクトの多くは現在では特定が難しく、図中では「不明」として表示されている。
-
ERC-20 時代（緑色）：ERC-20標準は2015年末に最終確定されたが、2017～2018年になってようやく広く普及した。2019年にはERC-20コントラクトが歴史データ増加の最大の要因となった。
-
DEX / DeFi 時代（茶色）：DEXおよびDeFiコントラクトは2016年頃から登場し、2017年ごろから注目され始めた。しかし、それが歴史データ増加の最大カテゴリとなるのは2020年の「DeFiサマー」以降だった。2021年から2022年にかけて、DeFiおよびDEXコントラクトは履歴データ増加の50％以上を占めた。
-
Rollup 時代（灰色）：2023年初頭から、L2 Rollupがメインネットよりも多くのトランザクションを処理するようになった。Dencun以前の数か月間では、それらがイーサリアム履歴データの約2/3を生成していた。
各時代は、それ以前よりも複雑なイーサリアムの利用方法を象徴している。時間の経過とともに、こうした複雑性の増大はイーサリアムのスケーリングの一形態とも言えるが、これはTPSのような単純な指標では測れない。
最新のデータ（2024年4月）では、Rollupはもはや大部分の履歴データを生成していない。今後の履歴データがDEX・DeFi由来になるのか、あるいはまったく新しい利用パターンが出現するのかはまだ不明である。
では、blobはどうなのか？
Dencunハードフォークにより導入されたblobは、歴史データ増加のダイナミクスを劇的に変えた。Rollupは安価なblobを利用してデータを公開できるようになったのだ。図4は、Dencunアップグレード前後の履歴データ増加率を拡大表示したものである。この図は図2と同様だが、各縦線が1か月ではなく1日を表している点が異なる。
図4：Dencunが歴史データ増加に与えた影響
このグラフから得られる主な結論：
-
Dencun以降、Rollupによる履歴データ増加は約2/3減少：ほとんどのRollupがcalldataからblobへ移行したことで、生成される履歴データ量は大幅に削減された。ただし、2024年4月時点で、まだcalldataからblobへ移行していないRollupも存在する。
-
Dencun以降、全体の履歴データ増加は約1/3減少：DencunはRollupの履歴データ増加のみを抑制した。他のコントラクトカテゴリの履歴データ増加はわずかに増加している。Dencun後も、履歴データ増加はステート増加の8倍の速度（詳細は次節）である。
blobにより履歴データ増加率は低下したものの、これはイーサリアムの新しい機能にすぎない。現時点で、blobがある状況下での履歴データ増加率がどのレベルで安定するかはまだ不明である。
どの程度の履歴データ増加が許容可能か？
Gasリミットを引き上げると、履歴データの増加率も上昇する。そのため、Pump the GasのようなGasリミット引き上げ提案は、履歴データ増加と各ノードのハードウェアボトルネックの関係を考慮しなければならない。
許容可能な履歴データ増加率を判断するには、まず現在のノードハードウェアがネットワークおよびストレージ面でどれだけの期間維持可能かを理解する必要がある。ネットワークハードウェアは、Gasリミットを引き上げるまでは、Dencun以前のピーク増加率に戻ることはないと考えられるため、おそらく無期限に維持可能だろう。しかし、履歴データのストレージ負担は時間とともに蓄積していく。現在のストレージ戦略では、各ノードのHDDはいずれ履歴データで満杯になることが避けられない。
図5は、イーサリアムノードのストレージ負担の推移と、今後3年間の予測を示している。予測は2024年4月時点の増加率を基準としている。将来的な利用パターンやGasリミットの変更により、この増加率は上下する可能性がある。
図5：履歴データ、ステート、フルノードのストレージ負担の大きさ
この図から得られる主な結論：
-
履歴データのストレージ使用量は、ステートの約3倍。この差は今後さらに広がる。なぜなら、履歴データの増加速度はステートの約8倍だからだ。
-
1.8 TiBが臨界点となり、多くのノードがストレージHDDのアップグレードを余儀なくされる。2TBは一般的なHDD容量だが、実際の可用領域は1.8TiBしかない。なお、TB（1兆バイト）とTiB（= 1024^4 バイト）は異なる単位である。また、マージ後のバリデーターは実行クライアントに加えてコンセンサスクライアントも稼働させる必要があるため、多くのノード運営者にとって「真の」臨界点はさらに低い。
-
この臨界点に到達するのはあと2〜3年。Gasリミットをいくら引き上げても、それに応じてこの時期が早まる。この閾値に達すると、ノード運営者は追加のハードウェア購入（例：300ドルのNVMeドライブ）を強いられ、保守負担が増大する。
ステートデータとは異なり、履歴データは「追記のみ」であり、アクセス頻度もはるかに低い。そのため理論的には、より安価なストレージメディアに分離保存することが可能だ。これはGethなどのクライアントで既に実現されている。
ストレージ容量に加え、ネットワークIOも履歴データ増加の主要な制約となる。ストレージとは異なり、ネットワークIOの制約は短期的にはノードに問題を引き起こさないが、将来のGasリミット増加において重要になる。
典型的なイーサリアムノードのネットワーク容量がどの程度の履歴データ増加を支えられるかを知るには、履歴データ増加と各種ネットワーク健康指標（例：リオーガナイゼーション率、スロット未ヒット、ファイナリティ未ヒット、証明未ヒット、同期委員会未ヒット、ブロック提出遅延など）の関係を把握する必要がある。これらの指標の分析は本稿の範疇を超えるが、既存のコンセンサス層の健康調査で詳述されている。また、イーサリアム財団のXatuプロジェクトは、こうした分析を加速するためのパブリックデータセットの構築を継続している。
どうやって履歴データ増加を解決するか？
履歴データ増加は、ステート増加よりもはるかに解決が容易な問題である。事実上、候補EIPであるEIP-4444だけでほぼ完全に解決可能だ。このEIPにより、各ノードが保持するデータは「イーサリアムの全履歴」から「過去1年分の履歴」に変更される。EIP-4444を実装すれば、データストレージはもはやイーサリアムスケーリングのボトルネックではなくなり、長期的にGasリミットの増加も制約されなくなる。EIP-4444はネットワークの長期的持続可能性に不可欠であり、これを採用しない限り、履歴データ増加のスピードが速すぎて、定期的にノードハードウェアの更新が必要になってしまう。
図6は、EIP-4444が今後3年間に各ノードのストレージ負担に与える影響を示している。これは図5と同じだが、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）それらの結果が現在のブロックチェーン末端と同じステートルートを持つことを確認することで、履歴データセットの真正性を検証できる。
履歴データの保存方法はいくつかある。
-
Torrents/P2P： Torrentは最もシンプルで信頼性の高い方法である。イーサリアムノードは定期的に部分的な履歴データをパッケージ化し、公共のTorrentファイルとして共有できる。例えば、10万ブロックごとに新しい履歴Torrentファイルを作成するといった具合だ。erigonなどのノードクライアントは、すでに非標準的な形でこのプロセスを一部実行している。これを標準化するには、すべてのノードクライアントが同じデータ形式、同じパラメータ、同じP2Pネットワークを使用する必要がある。ノードは自身のストレージ容量と帯域幅に応じて、このネットワークへの参加を決定できる。Torrentの利点は、多数のデータツールがサポートする高Lindyなオープン標準を利用できることにある。
-
Portal Network：Portal Networkは、イーサリアムデータのホスティング専用に設計された新しいネットワークである。Torrentに似たアプローチだが、追加の検証機能を備えており、データの検証が容易になる。Portal Networkの利点は、こうした追加の検証レイヤーにより、ライトクライアントが共有データセットを効率的に検証・照会できる点にある。
-
クラウドホスティング： AWSのS3やCloudflareのR2などのクラウドストレージサービスは、履歴データ保存に低コストかつ高性能な選択肢を提供する。しかし、こうしたサービスが常に暗号資産データのホスティングを望み、かつ可能である保証がないため、法的リスクやビジネス運用リスクが高くなる。
残る実装上の課題はむしろ社会的なものであり、技術的なものではない。イーサリアムコミュニティは、各ノードクライアントに直接統合できるよう、具体的な実装細部を調整する必要がある。特に、創世ブロックからの完全同期（スナップショット同期ではなく）を行うには、履歴データをイーサリアムノードではなく履歴データ提供者から取得する必要がある。これらの変更は技術的にはハードフォークを必要としないため、次のハードフォーク「Pectra」よりも早く実装可能である。
これらの履歴データ保存方法は、L2がメインネットに公開するblobデータの保存にも利用できる。履歴データの保存と比べて、blobの保存は 1) 総データ量がはるかに多いためより困難、2) メインネット履歴の再生には不要なため重要度は低い。しかし、各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：calldataの再価格設定により、過剰なcalldataを使うトランザクションを高価にする。こうした利用方法を高価にすることで、一部をcalldataからblobへ移行させる圧力をかける。これにより履歴データ増加率が低下する。
-
EIP-4488：1ブロックあたりに含められるcalldataの総量に上限を設ける。これにより、履歴データの増加速度にさらに厳しい制限をかけることができる。
これらのEIPはEIP-4444よりも実装が容易であるため、EIP-4444が本番環境に導入されるまでの暫定措置として活用できる可能性がある。
おわりに
本稿の目的は、データを通じて 1) 履歴データ増加の仕組みと 2) その解決策を理解することにある。本稿で紹介した多くのデータは従来の方法では入手が困難であったため、こうしたデータを公開することで、履歴データ増加問題に対する新たな洞察を提供できればと考えている。
履歴データ増加は、イーサリアムスケーリングのボトルネックとしてこれまで十分に注目されてこなかった。Gasリミットを引き上げなくても、現在の履歴データ保存慣行は、数年以内に多くのノードに対してハードウェアのアップグレードを強いるだろう。幸い、これは難解な問題ではない。EIP-4444にすでに明確な解決策が存在する。我々は、このEIPの実装を早め、将来のGasリミット増加の余地を確保すべきだと考える。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
Paradigm
