イーサネット・ストレージ・ソリューションのロードマップ：今後の課題と機会

ソース: geek Web3

Abstract:

- EIP-4844以来、イーサネットネットワークのデータスループットとストレージの圧力は増加し続けており、増え続けるストレージ需要はイーサネットノードにとって大きな課題となっています。ストレージの圧力を減らすために、一部のイーサネットクライアントはローカルに保存された過去のイーサネットデータを検閲しており、異なるフルノード間のストレージ動作の一貫性は徐々に崩壊しています。

- すべてのイーサネット クライアントがその動作に同意できるように、EIP-4444 とEIP-4844 は履歴データのカリング動作を標準化しました。これは将来イーサネットノードの標準になるでしょう。

- そのため、最新のレイヤー1またはレイヤー2の状態を復元するために履歴データを再生することは、集中型のプロトコル外のイーサ サービスに依存しており、より分散型のイーサに沿ったストレージ ソリューションの探求を促しています。ポータルネットワークは、履歴データを含むあらゆるタイプのイーサネットデータ用の、軽量で分散型のP2Pネットワークです。リソースに制約のあるデバイス向けに設計されており、イーサネットJSON-RPCサービスを提供します。History NetworkとBeacon Chain Networkはほぼ完成しています。

- EthStorageは、EIP-4844 BLOBsデータのためのインセンティブ付きモジュール式ストレージネットワークです。BLOBを保存するために、ユーザーはL1上でストレージ契約を起動し、ETHをストレージ料として使用してチェーン上にBLOBのハッシュを記録することができます。時間の経過とともに、保管料はチェーン下のBLOBの保管証明を提供するストレージプロバイダに徐々に割り当てられる。

-  EthStorageテストネットワークは現在、Ether Sepoliaテストネットワーク上で実行されており、複数のコミュニティ参加者がローカルストレージのステータスの証明に成功しています。将来の計画には、分散型イーサネット・ステート・ネットワークの開発、動的なサイズのデータに対するプルーフ・オブ・ストレージの実装、ブラウザから直接分散型方法でEthStorageネットワークにアクセスする機能などが含まれます。

謝辞：Ethernet FoundationのPiper Merriam氏、PolychainのKarthik Raju氏、EthStorageのQiang Zhu氏には、本記事に対するフィードバックをいただき、ありがとうございました。

背景:

2023年10月22日、Go-Ethereum（Geth）の開発責任者として有名なPéter Szilágyi氏は、Twitterでイーサネットのデータストレージソリューションに対する懸念を表明しました。彼は、Gethクライアントがすべての履歴データを保持する一方で、NethermindやBesuなどの他のタイプのイーサリアムクライアントは、特定のイーサリアム履歴データ（履歴ブロックなど）を削除するように設定できると指摘した。このため、一部のクライアントノードの挙動が他のクライアントと矛盾する可能性があり、Gethクライアントランナーにとっては不公平です。上記のトピックは、イーサロードマップにおけるストレージオプションについての熱い議論を呼び起こしました。

ストレージの課題

なぜNethermindとBesuはクライアントランナーがローカルの履歴データを再編集できるようにしたのでしょうか？この決定にはどのような問題が反映されているのでしょうか？

私たちの観点からは、主に2つの理由があります：

• Ethereum クライアントは、ストレージ要件に関してますます厳しくなっています。

• 過去のイーサデータを保存するためのプロトコル内のインセンティブやペナルティはありません。

最初の理由は、イーサクライアントのストレージニーズの高まりに起因しています。下の円グラフは、2023年12月13日時点の新しいGethノードのストレージの配分を示しており、ブロックの高さは18,779,761です。

• 総ストレージサイズ：925.39 GB

• Historical data (blocks/transaction receipts): about 628.69 GB

• State data in the Merkle Patricia Trie (MPT): about 269.74 GB

Ethernetノードは、履歴ブロックを保存するためのプロトコル内のインセンティブやペナルティを欠いています。プロトコルは、ノードがすべての履歴データを保存することを促進しますが、保存を奨励したり、違反を罰したりするメカニズムを提供していません。ノードは、インセンティブがあるからというよりも、利他的な気持ちから、履歴データを保存し、抽出のために履歴データへのアクセスを外部に提供することを望んでいます。

もちろん、クライアントランナーはペナルティなしにすべての履歴データを自由に削除または変更できます。

したがって、ストレージのコストがノードにとって大きな負担になったときに、履歴データを削除することを選択するノードオペレータがいても不思議ではありません。履歴データがない場合、ノードクライアントはストレージコストを大幅に削減し、占有するストレージ容量を約1TBから約300GBに減らすことができます。

Illustration: ブロックの履歴がないノードを実行するNethermined構成 - 現在、ストレージコストで～460GBを節約

イーサネット・データ・アベイラビリティ(DA)の今後のアップグレードにより、ストレージの課題は激化します。イーサネットDAの完全なスケーリングへの道は、DenCunアップグレードのEIP-4844から始まり、固定サイズのバイナリラージオブジェクト(BLOB)と、blobGasPriceと呼ばれる個別の料金モデルを導入しました。各BLOBは128KBに設定され、EIP-4844の実装により、各ブロックは最大6つのBLOBを含むことになります。データ・スループットをスケールアップするために、イーサネットは1Dリード・ソロモン訂正符号化を使用する計画で、当初はブロックあたり32のBLOBを可能にし、完全にスケールアップされたときには、ブロックあたり256のBLOBという桁に達する予定です。

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

The Ether Storage Roadmap and Its Consequences

Vitalikが投稿したEtherロードマップのツイートは、主にストレージを扱うPurgeに言及しています。に言及しています。

ストレージのコスト上昇は、イーサのエコシステムの研究者の注目を集めています。これに対処し、すべてのクライアントで一貫性を確保するために、研究者たちは、Ether クライアントから履歴データを明示的に削除するための多くの提案に取り組んでいます。2つの主な提案は次のとおりです:

- EIP-4444:クライアントにおける履歴データの強制に関する制限: この提案は、クライアントが1年以上前の過去のブロックを削除できるようにするものです。平均ブロックサイズを100Kと仮定すると、過去のブロックデータの上限は約250GBになります（100K * (3600 * 24 * 365) / 12、ブロック時間=12秒と仮定）。

- EIP-4844: スライスされたBLOBトランザクション：18日より古いBLOBデータを破棄します。これはEIP-4444と比べてより積極的なアプローチで、過去のBLOBサイズを約100GBに制限します（(18 * 3600 * 24) * 128K * 6 / 12、ブロック時間= 12秒と仮定）。

すべてのクライアントから履歴データを削除すると、どのような結果になりますか?主な問題の1つは、新しいノードが「完全同期」モードによって最新の状態に同期できないことです。これは、ジェネシスブロックから最新のブロックまで履歴データを同期するデータ再生スキームです。同期スキーム。したがって、イーサネット・ノードの最新の状態を直接同期する「スナップ同期」または「状態同期」を取らなければならない。この方法はGethに実装されており、デフォルトの同期操作です。

メインイーサネットネットワークから履歴データを削除するノードは、イーサネットL2でも問題を引き起こす可能性があります。これにより、新しく追加されたレイヤー2ノードは、レイヤー2の履歴データをすべて再生することで、現在の最新の状態に同期することができません。さらに、L1 ノードは L2 の状態を維持しないため、L2 の「スナップ同期」メソッドは、レイヤー1 ブロックから最新のレイヤー2 の状態を直接導き出すことができず、レイヤー2 がイーサネットのセキュリティを継承するために必要な重要な前提条件に違反します。

予測されるソリューションは、過去のレイヤー2データや状態のコピーを保存するために、Infura/Etherscan/L2プロジェクト自身によるサードパーティのサービスに依存することになりますが、これはプロトコル外の間接的なインセンティブによって達成される集中型のソリューションです。

• ストレージとアクセスについて、より良い分散型ソリューションを見つけることはできるでしょうか？

• イーサリアムネットワーク自体によって保証される直接的なインセンティブをノードに与えるソリューションを見つけることは可能でしょうか（例えば、L1コントラクトによって実装されます）？

• これらすべてを踏まえて、イーサネットストレージルートに対して、完全に分散化された、プロトコル内の、直接インセンティブを与えるソリューションを提供することは可能でしょうか？

解決策

解決策1: Etherポータルネットワーク

Etherポータルネットワークは、Etherプロトコルに接続するための軽量で分散化されたネットワークです。これは、eth_call、eth_getBlockByNumber、およびその他のイーサネットJSON-RPCインターフェースを提供し、JSON-RPCリクエストをIPFSネットワークに似た分散ハッシュテーブル(DHT)へのP2Pリクエストに変換します。あらゆるデータタイプの保存を可能にし、スパムの影響を受けやすいIPFSとは異なり、Portal P2Pネットワークは、過去のブロックヘッダーやトランザクションデータなどのEtherデータのみをホストします。

ポータルネットワークの主な特徴の1つは。軽量な運用設計と、リソースに制約のあるデバイスとの互換性です。数MBのストレージと低RAMのノード上で実行できるため、分散化が促進されます。携帯電話やRaspberry Piデバイスでさえ、ネットワークに参加し、イーサネットDA問題の解決に貢献する可能性を秘めています。

ポータルネットワークは、Rust、JavaScript、Nimで書かれたイーサネットクライアントの多様性の考えに沿って開発されました。ビーコン・ネットワークとヒストリー・ネットワークはすでに利用可能で、ステート・ネットワークは現在活発に開発中です。注目すべきは、ポータル・ネットワークがデータ保存の直接的なインセンティブを提供していないことだ。

図版ポータルネットワークのラストクライアント(Trin)と100MBのストレージ制限の動作

ソリューション2：EthStorageネットワーク

EthStorageネットワークは、EIP-4844のBLOBを保存するための分散型インセンティブストレージネットワークです。ESPプロジェクトによって資金提供されています。

最小限の信頼：中央集権的なデータブリッジを必要とする既存のソリューションとは異なり、EthStorageはイーサのコンセンサスと、パーミッションのないEthStorageストレージノードのための1/mの信頼モデルに依存しています。BLOBの保存は次のように動作します：ユーザーはBLOBを運ぶトランザクションに署名し、ストレージ契約のput(key, blob_idx)メソッドを呼び出します。その後、ストレージコントラクトはBLOBのハッシュをチェーン上に記録する。その後、ストレージ・プロバイダはイーサネットDAネットワークから直接BLOBをダウンロードして保存し、データブリッジの問題を回避する。

- ストレージコストはインセンティブと一致する： put()メソッドが呼び出されると、トランザクションは（msg.valueを介して）ストレージコストを送信し、それをコントラクトに預けなければならない。この保管コストは、ダウンチェーンの保管ノードが保管証明を提出・検証した後、時間の経過とともに徐々に保管ノードに分配される。提案者に1回限りの保管料を支払う既存のイーサリアムの保管料モデルとは対照的に、時間の経過とともに支払われる保管料は割引キャッシュフローモデルに従います。EthStorageは、手数料をストレージノードのストレージ貢献度に合わせるという重要な革新を導入しています。

- ストレージの証明：ストレージの証明は、データの可用性サンプリングに触発されていますが、EthStorageのサンプリングは、時間をかけて保存されたBLOBのためのものです。オンチェーンサンプリングを効率的に検証するために、EthStorageはスマートコントラクトと最新のSNARK技術開発を活用しています。

- ライセンスフリーの運用：EthStorageのどのストレージノードも、データを保存し、チェーン上に保存の証明を定期的に提出することで報酬を得ることができます。

モジュラーブロックチェーンの観点から、EthStorageはEtherStorage L2として機能しますが、トランザクション手数料ではなくストレージ手数料を請求します。チェーン上でBLOBハッシュにインデックスを付けることで、EthStorageは、ストレージのスケーラビリティを向上させ、コストを削減する（〜1000倍を目標にする）Etherモジュラーストレージレイヤーです。

開発面では、EthStorageはEther SepoliaテストネットのEIP-4844と統合されています。私たちはEthStorageとEthernet Sepoliaテストネットのストレステストを行い、約数百ギガバイトのBLOBをEthStorageに書き込みました。

EthStorageネットワークの主な利点は、Etherの上に分散型の直接インセンティブを提供することです。しかし、このネットワークの限界は、固定サイズのBLOB専用に設計されていることです。

EthStorage on Ethernet Sepoliaのカンバン。

Looking Ahead

EthStorage はイーサネットのエコシステムにおいて重要です。ポータルネットワークとEthStorageネットワークはまだ初期段階にあり、長期的に注力すべき重要な方向性がたくさんあります。および検証可能なイーサネット状態へのアクセスは、非常に重要ですが、困難な課題です。従来のDHTネットワークモデルを使用すると、アカウント情報をクエリするには、通常、異なるP2Pノードに格納された内部トライノードへの複数のクエリが必要です。このため、かなりの待ち時間が発生することがよくあります。ステートツリーの構造を活用してアクセスを高速化することが重要です。イーサネット・ポータル・ネットワークの今後のステートフル・ネットワークは、まさにこの問題に対処するように設計されています。

ポータルネットワークとEthStorageネットワークの統合：ポータルネットワークは、EthStorageチームによって部分的に実装された機能である、BLOBデータをサポートするためにシームレスに拡張することができます。次のステップは、これらのネットワークを統合して、コントラクトを通じてBLOBへのアクセスがプログラム可能な分散型JSON-RPCネットワークを提供することです。コントラクト内のアプリケーションロジックとEthStorageが提供するスケーラブルなBLOBストレージを組み合わせることで、動的な分散型ウェブサイト（分散型Twitter/YouTube/Wikipediaなど）のようなEther上の新しいdAppsを可能にすることができます。

ブラウザのための分散アクセス: IPFSネットワークでデータにアクセスするためのipfs://プロトコルと同様に、Web3業界は、イーサネットの豊富なデータの膨大な可能性を解き放つために、ブラウザからの直接アクセスをサポートするイーサネットネイティブのアクセスプロトコルを必要としています。このデータは、トークンの所有権や口座残高から、NFT画像や動的な分散型ウェブサイトまで、幅広い領域をカバーしており、これらはすべてスマートコントラクトと将来のイーサネットストレージ機能によって実現されます。この分野では、ERC-4804/6860で定義されたweb3://プロトコルが現在積極的に開発され、これを可能にするために推進されています。

動的なサイズのデータに対する高度なプルーフ・オブ・ストレージ：固定BLOBに加えて、高度なプルーフ・オブ・ストレージを探求することは、動的なサイズのデータ（例えば、過去のブロック、あるいは状態オブジェクトなど）に対応するために不可欠です。洗練されたアルゴリズムを開発することで、ストレージソリューションの適応性を高めることができます。

私たちの探求において、私たちはこれらの取り組みを通じてイーサネットのロードマップに貢献し、イーサネットエコシステム向けの将来の分散型ストレージソリューションの基礎を築きたいと考えています。