イーサリアムのストレージロードマップ：課題と機会

2024.04.12

共有先

TechFlow厳選深潮セレクト

イーサリアムのストレージロードマップ：課題と機会

増大し続けるストレージ需要は、イーサリアムノードに大きな課題をもたらしている。

2024.04.12 - 01:53:31

以太坊

Web3業界の深掘り報道に専念し潮流を洞察

増大し続けるストレージ需要は、イーサリアムノードに大きな課題をもたらしている。

執筆：EthStorage

概要

増加し続けるストレージ需要は、イーサリアムノードに大きな課題をもたらしている。
ストレージ制限のため、一部のクライアントは歴史データの削除を開始しており、ネットワーク内のフルノード間でストレージ動作が不一致になっている。
すべてのクライアントの一貫性を確保するため、歴史データの削除は EIP-4444 および EIP-4844 において標準化されようとしている。
その結果、過去のデータをリプレイして最新のL1またはL2状態を復元するには、中央集権的かつプロトコル外のサービスが必要となり、より分散型でイーサリアムと整合性のある解決策の探索が促されている。
イーサリアムポータルネットワークは、歴史データを含むあらゆる種類のイーサリアムデータ用に設計された、軽量かつ分散型のP2Pネットワークである。リソースに制約のあるデバイス向けに設計されており、イーサリアムJSON-RPCサービスを提供する。歴史ネットワークとビーコンチェーンネットワークはほぼ準備が整っている。
EthStorageネットワークは、EIP-4844 BLOBデータ専用のインセンティブ付きモジュラーストレージネットワークである。BLOBを保存するユーザーは、L1ストレージコントラクトのput()メソッドを呼び出し、ETHをストレージ料金として支払い、BLOBハッシュ値をオンチェーンに記録する。時間の経過とともに、ストレージ料金はオフチェーンのBLOB保存証明を提出したストレージプロバイダーに分配される。EthStorageテストネットはイーサリアムSepoliaテストネット上で稼働中であり、複数のコミュニティ参加者がローカルストレージの証明に成功している。
今後の計画には、分散型イーサリアムステートネットワークの開発、動的サイズデータに対する保存証明の実装、ブラウザからの分散アクセスの実現などが含まれる。

謝辞：EFのPiper Merriam、PolychainのKarthik Raju、EthStorageのQiangによる本稿へのフィードバックに感謝する。

背景

2023年10月22日、有名なGo-Ethereum（Geth）開発責任者であるPéter Szilágyi氏はTwitter上で深い懸念を表明した。彼によると、Gethクライアントはすべての履歴データを保持しているが、NethermindやBesuなどの他のイーサリアムクライアントでは、一部の履歴イーサリアムデータ（例：過去のブロックやブロックヘッダー）を削除するように設定できるため、すべてのクライアントの挙動が不一致になり、Gethにとって不公平であるという。これは、イーサリアムロードマップにおけるストレージ問題に関する激しい議論と論争を引き起こした。

ストレージの課題

なぜNethermindやBesuは履歴データの保存を停止したのか？この決定の背後にある問題とは何か？私たちの見解では、主に二つの理由がある：

イーサリアムクライアントのストレージ要件がますます高くなっている。
イーサリアムの履歴データを保存することに対して、プロトコル内でのインセンティブやペナルティがない。

最初の理由は、イーサリアムクライアントの運営に必要なストレージ量が継続的に増加していることに起因する。具体的な要件を理解するために、以下の円グラフは2023年12月13日のブロック18,779,761時点における新しいGethノードのストレージ構成を示している。

図からわかるように：

総ストレージ容量：925.39 GB
履歴データ（ブロック／トランザクションレシート）：約628.69 GB
Merkle Patricia Trie (MPT) 内のステートデータ：約269.74 GB

二つ目の理由は、履歴ブロックの保存に対するプロトコル内インセンティブやペナルティの欠如である。プロトコル上はノードがすべての履歴データを保持することを求めているものの、それを奨励したり違反を罰する仕組みが存在しない。結果として、ノードが履歴データを保存・共有することは純粋な利他主義に依存しており、運用者は自由に履歴データを削除または変更でき、何の罰則もない。一方、バリデーターノードは無効ブロックを提案・投票することでスラッシング（罰則）を受けないよう、ローカルで完全なステートを維持・更新する必要がある。

そのため、ストレージコストがノードにとって重大な負担となるとき、一部のノード運営者が履歴データを削除するのは当然のことである。履歴データがない場合、ノードクライアントはストレージコストを大幅に削減でき、約1TBから300GB程度まで低減できる。

図：Nethermindで履歴ブロックなしでノードを実行する設定 ― 現在約460GBのストレージコストを節約可能

今後予定されているイーサリアムのデータ可用性（DA）アップグレードにより、ストレージの課題はさらに悪化する。イーサリアムDAの拡張への道は、DenCunアップグレードのEIP-4844から始まり、固定サイズのバイナリ大オブジェクト（BLOB）とblobGasPriceという独立した料金モデルを導入する。各BLOBは128KBに設定され、EIP-4844では各ブロックに最大6個のBLOBを含めることができる。データスループットを拡張するために、イーサリアムは1D Reed-Solomonコードを採用し、当初は各ブロックに32個のBLOBを許可し、完全に拡張された際には各ブロックに256個のBLOBを達成する予定である。

もしイーサリアムDAが全容量で稼働した場合（1ブロックあたり256BLOB）、イーサリアムDAネットワークは年間約80TBのDAデータを受信すると予想され、この数字はほとんどのノードのストレージ能力をはるかに超える。

イーサリアムストレージロードマップとその影響

Vitalikが公開したイーサリアムロードマップツイート。Purgeは主にストレージ関連の内容を指す

増大するストレージコストは、イーサリアムエコシステムの研究者の関心を集めている。この問題を解決し、すべてのクライアント間の一貫性を保つために、履歴データの削除を明確にするいくつかの提案が検討されている。主な二つの提案は次の通り：

EIP-4444：実行クライアントにおける履歴データの制限：この提案により、クライアントは1年以上前の履歴ブロックを削除できるようになる。平均ブロックサイズを100KBと仮定すると、履歴ブロックデータの上限は約250GBとなる（100KB × (3600 × 24 × 365) / 12、ブロックタイム＝12秒と仮定）。
EIP-4844：シャーディングBLOBトランザクション：EIP-4844では、18日以上経過したBLOBは破棄される。EIP-4444と比較してより攻撃的なアプローチであり、履歴BLOBサイズを約100GBに制限する（(18 × 3600 × 24) × 128KB × 6 / 12、ブロックタイム＝12秒と仮定）。

すべてのクライアントが履歴データを削除すると、どのような影響が出るだろうか？最も重要な問題は、新規ノードが「full sync」モードで最新状態に同期できなくなることである。「full sync」とは、創世ブロックから最新ブロックまでのすべてのトランザクションを実行して同期する方法である。これに対応して、「snap sync」または「state sync」によって、イーサリアムノードから直接最新の状態を同期する必要がある。この手法はすでにGethに実装されており、デフォルトの同期方式となっている。

同様に、この影響はすべてのL2にも及ぶ。つまり、新規L2ノードはL2創世から最新L2ブロックまでのリプレイによって、イーサリアムL2創世の最新状態に完全に同期できなくなる。さらに、L1ノードはL2の状態を維持しないため、L2の「snap sync」はL1から最新のL2状態を派生させることができず、L2の重要な仮定であるイーサリアムのセキュリティ保証の継承に反する。予想される解決策はInfura／Etherscan／L2プロジェクト自体といった第三者サービスに依存し、履歴L2データまたは状態のコピーを保存するものになる。これはプロトコル外の間接的なインセンティブによる中央集権的解決策である。

私たちが探求すべき核心的な問題は次の通りである：

ストレージとアクセスにおいて、より優れた分散型の解決策を見つけられるか？
L1コントラクト上など、イーサリアムと整合性を持ち、直接的なインセンティブ機構を持つ解決策は可能か？
これらすべての基盤の上に、完全に分散型でプロトコル内直接インセンティブを持つイーサリアムストレージソリューションを提供できるか？

解決策

解決策1：イーサリアムポータルネットワーク

イーサリアムポータルネットワークは、イーサリアムプロトコルに接続するための軽量かつ分散型のアクセスネットワークである。eth_call、eth_getBlockByNumberなどのイーサリアムJSON-RPCインターフェースを提供し、JSON-RPCリクエストをIPFSネットワークと同様に分散型ハッシュテーブル（DHT）に対するP2Pリクエストに変換する。IPFSのように任意のデータタイプを格納でき、スパムデータの影響を受けやすいのとは対照的に、ポータルP2Pネットワークは履歴ブロックヘッダーやブロックトランザクションデータなど、特定のイーサリアムデータのみをホストする。これはポータルネットワークに組み込まれたライトクライアント検証技術によって実現されている。

ポータルネットワークの重要な特徴の一つは、軽量な設計とリソースに制約のあるデバイスとの互換性である。数MBのストレージと低メモリを持つノードでも動作可能であり、分散化を促進する。スマートフォンやRaspberry Piのようなデバイスさえもネットワークに参加し、イーサリアムデータの可用性に貢献できる可能性がある。

ポータルネットワークの開発は、イーサリアムクライアントの多様性という理念と一致しており、Rust、JavaScript、Nimで書かれたクライアントが開発されている。ビーコンネットワークと履歴ネットワークはすでに利用可能で、ステートネットワークは現在積極的に開発中である。注目すべき点は、ポータルネットワークはデータストレージに対して直接的なインセンティブを提供していない――ネットワーク内のすべてのノードは利他的に動作している。

図：100MBのストレージ制限を持つポータルネットワークRustクライアント（Trin）の動作中

解決策2：EthStorageネットワーク

EthStorageネットワークは、EIP-4844 BLOBの保存専用の分散型インセンティブ付きストレージネットワークであり、ESPプロジェクトの支援を受けている。

最小限の信頼：既存の中央集権型データブリッジに依存するソリューションとは異なり、EthStorageはイーサリアムのコンセンサスと、無許可のEthStorageストレージノードによる1/m信頼モデルに依存している。BLOBの保存プロセスは以下の通り：ユーザーはBLOBを含むトランザクションに署名し、ストレージコントラクトのput(key, blob_idx)メソッドを呼び出す。その後、ストレージコントラクトはBLOBハッシュをオンチェーンに記録する。その後、ストレージプロバイダーはイーサリアムDAネットワークから直接BLOBをダウンロードして保存するため、データブリッジの問題を回避できる。
ストレージコストとインセンティブの一致：put()メソッドを呼び出す際、トランザクションはストレージ料金（msg.value経由）を送信し、コントラクトに預ける必要がある。オフチェーンのストレージノードが正常に保存証明を提出・検証した後、このストレージ料金は時間の経過とともにストレージノードに分配される。既存のブロッカー（proposer）に一時的なストレージ料金を支払うイーサリアムモデルと比べ、時間経過型の支払いは割引キャッシュフローモデルに従う――時間の経過とともに、ストレージコストがETH価格に対して低下すると仮定している。EthStorageが導入したこの画期的な革新により、料金とストレージノードの貢献が一致する。
保存証明：保存証明はデータ可用性サンプリングから着想を得ており、EthStorageでは一定期間にわたって保存されたBLOBに対してサンプリングを行う。オンチェーンでのサンプリングを効率的に検証するために、EthStorageは最新のスマートコントラクトとSNARK技術を活用している。
無許可操作：EthStorage内の任意のストレージノードは、データを保存し、定期的にオンチェーンで保存証明を提出すれば報酬を受け取れる。

モジュラーブロックチェーンの観点から見ると、EthStorageはイーサリアムのストレージL2として機能するが、トランザクション手数料ではなくストレージ料金を徴収する。オンチェーンでBLOBハッシュをインデックスすることで、EthStorageはイーサリアムのモジュラーなストレージレイヤーとなり、ストレージのスケーラビリティを向上させ、コストを削減する（目標は約1000倍）。

開発面では、EthStorageはすでにイーサリアムSepoliaテストネット上のEIP-4844と統合されている。数百GB規模のBLOBをEthStorageに書き込むなどのストレステストも実施した。100人以上のコミュニティ参加者がネットワークに参加し、ローカルストレージの証明に成功している。

EthStorageネットワークの主な利点は、イーサリアム上で分散型の直接インセンティブを提供できる点にある――現時点で知られている限り、これは画期的な機能である。しかし、このネットワークの制限は、固定サイズのBLOB専用に設計されている点にある。

イーサリアムSepoliaテストネット上のEthStorageダッシュボード

今後の展望

イーサリアムストレージはまだ主要な注目を集めていないが、イーサリアムエコシステム内では極めて重要である。イーサリアムネットワークの急速な成長に伴い、イーサリアムデータの保存とアクセス可能性は重要な課題となっている。ポータルネットワークとEthStorageネットワークはまだ初期段階にあり、注目すべき重要な長期的な発展方向がいくつもある：

分散型で低遅延なイーサリアムステートデータネットワーク。分散型かつ検証可能な方法でイーサリアムのステートにアクセスすることは、極めて重要だが困難な課題である。従来のDHTネットワークモデルでは、アカウント情報を照会する際に、異なるP2Pノードに分散された内部trieノードを何度も照会する必要があることが多く、長時間の遅延を招く。ステートツリーの構造を利用してアクセスを高速化することが鍵となる。イーサリアムポータルネットワークが間もなくリリース予定のステートネットワークは、まさにこの問題を解決しようとしている。
ポータルネットワークとEthStorageネットワークの統合：ポータルネットワークはBLOBデータをサポートするようシームレスに拡張可能である。EthStorageチームはすでにこの機能の一部を実装済みである。次なるステップはこれらのネットワークを統合し、コントラクトを通じてBLOBsへプログラム可能なアクセスを提供する分散型JSON-RPCネットワークを構築することである。コントラクト内のアプリケーションロジックと、EthStorageが提供する大規模BLOBストレージを組み合わせることで、動的な分散型Webサイト（例：分散型Twitter／YouTube／Wikipediaなど）といった新たなdAppsをイーサリアム上で実現できる。
ブラウザからの分散アクセス：IPFSネットワーク内のデータにアクセスするipfs://プロトコルと同様に、web3業界にはイーサリアムネイティブなアクセスプロトコルが必要であり、ブラウザが直接アクセスできるようにすることで、イーサリアムの豊かなデータの潜在能力を解放できる。トークン所有権やアカウント残高からNFT画像、動的な分散型Webサイトに至るまで、幅広い分野がスマートコントラクトおよび将来のイーサリアムストレージ機能の恩恵を受ける。この分野では、ERC-4804/6860で定義されたweb3://プロトコルが現在積極的に開発・普及が進められており、この目標の実現を目指している。
動的サイズデータの高度な保存証明：固定サイズのBLOBに加え、動的サイズのデータ（例えば履歴ブロックやステートオブジェクトなど）に対する高度な保存証明の探索も不可欠である。複雑なアルゴリズムを開発することで、ストレージソリューションの適応性を高めることができる。