サマリー

• イーサリアムノードにとって、増加するストレージ要件は重大な課題を提供しています。
• 一部のクライアントは、ストレージの制約により、履歴データを削減し始めており、ネットワーク内のフルノードの間で一貫性のないストレージ動作が発生しています。
• すべてのクライアント間で整合性を確保するために、履歴データの整理がEIP-4444およびEIP-4844で標準化されています
• したがって、最新のL1またはL2の状態を再生するには、中央集権的でプロトコル外のサービスに依存する必要があり、より分散型のイーサリアムに合わせたソリューションの探求が促されます
• イーサリアムポータルネットワークは、歴史データを含むあらゆるタイプのイーサリアムデータのための軽量で分散型のP2Pネットワークです。リソースが制約されたデバイス向けに設計されており、イーサリアムのJSON-RPCサービスを提供しています。歴史ネットワークとビーコンネットワークはほぼ使用可能です。
• EthStorageネットワークは、EIP-4844 BLOBs用のインセンティブ付きモジュラーストレージネットワークです。BLOBを格納するには、ユーザーがL1ストレージ契約を呼び出します。put()BLOBハッシュとETHで手数料を支払う方法。手数料は、時間の経過とともにオフチェーンのBLOBの有効なストレージ証明を提出することで、ストレージプロバイダに徐々に分配されます。 EthStorageテストネットは、複数のコミュニティ参加者がローカルストレージを正常に証明しているEthereum Sepoliaテストネット上で稼働しています。
• 将来の取り組みには、分散型の状態ネットワークの開発、動的サイズのデータの保存証明の実装、およびブラウザからの直接分散アクセスが含まれています。

謝辞：EFのPiper Merriam、PolychainのKarthik Raju、EthStorageのQiangに、記事のフィードバックを提供していただき、心から感謝申し上げます。

背景

2023年10月22日、名だたるGo-Ethereum（Geth）の開発リードであるペーテル・シラージ氏がTwitterで深刻な懸念を表明しました。彼は、Gethクライアントがすべての履歴データを保持しているのに対し、NethermindやBesuなどの他のEthereumクライアントは、履歴的なブロック本体やヘッダーなどの一部の過去のEthereumデータをなしで運用するように構成できると指摘しました。これにより、すべてのクライアントが一貫性がなく、Gethに不利です。これはEthereumロードマップ内のEthereumストレージ問題に関する激しい議論と論争を引き起こしました。

ストレージの課題

NethermindとBesuはなぜ過去のデータの保存を停止することを選択するのですか？この決定の背後にある問題は何ですか？私の視点からは、2つの主要な根本原因があります：

• イーサリアムクライアントのストレージ要件はますます厳格になっています。
• イーサリアムの歴史データを保存するためのプロトコル上のインセンティブやペナルティはありません。

最初の理由は、Ethereumクライアントを実行する際の蓄積されるストレージ需要の拡大から生じています。具体的な要件について詳しく調べると、以下の円グラフは、2023年12月13日時点のブロック18,779,761における新しいGethノードのストレージコストの分布を示しています。

写真に示す通り:

• 総ストレージ要件：925.39 GB
• 履歴データ（ブロック/レシート）：約628.69 GB
• Merkle Patricia Trie（MPT）における状態：約269.74 GB

第二の理由は、履歴ブロックの保存に対するプロトコル内のインセンティブやペナルティの不在です。プロトコルはノードにすべての履歴データの保存を義務付けていますが、保存を奨励するメカニズムを提供せず、違反に対するペナルティもありません。ノードによる履歴データの保存と共有は純粋に利他的であり、ノードはいかなる不利益も受けることなくすべての履歴データを削除することができます。一方、例えばバリデータは、無効なブロックの提案/投票を避けるために最新の完全な状態を維持する必要があり、いずれの場合もインセンティブの損失をリスクにさらすことがあります。

したがって、ストレージコストがノードにとって著しい負担となると、一部のノードオペレーターが歴史データを削除することを選択するのは驚くべきことではありません。歴史データを削除して実行することで、ストレージコストを大幅に節約し、約1TBから約300GBに削減することができます。

イラスト：歴史的なブロックボディなしでノードを実行するNethermined構成-現時点で約460GBのストレージコストを節約します。

ストレージの課題は、今後のEthereumデータ利用可能性（DA）のアップグレードによってさらに激化すると予想されています。パスイーサリアムの完全なスケーリングに向けて、EIP-4844がDenCunで始動し、固定サイズのバイナリラージオブジェクト（BLOB）を導入し、blobGasPriceと呼ばれる独立した手数料モデルを伴います。各BLOBは128KBで設定され、EIP-4844では各ブロックに最大6つのBLOBを含めることができます。データのスケーラビリティを向上させるため、この計画には1次元リード・ソロモン符号の実装が含まれ、最初はブロックごとに32個のBLOBを許容し、最終的にはフルスケーリング時にブロックごとに256個のBLOBを達成します。

Ethereum DAが1ブロックあたり256 BLOBでフルデータ容量で稼働している場合、1年間のEthereum DAネットワークは約80 TBのデータを受け入れると予想され、ほとんどのEthereumノードのストレージ容量を超えることが予測されています。

イーサリアムストレージロードマップと結果

ヴィタリクのツイートイーサリアムのロードマップの一部で、パージは主にストレージに関連しています。

イーサリアムエコシステム内の研究者の間で注目を集めているのは、蓄積されるストレージコストの増加です。これを解決し、すべてのクライアント間での整合性を確保するために、ストレージを明示的に縮小するためのいくつかの提案が開発中です。主な2つの提案は次のとおりです。

1. EIP-4444: 実行クライアントでのバウンド履歴データ：この提案により、クライアントは1年以上前の履歴ブロックを刈り込むことができます。平均ブロックサイズが100Kと仮定すると、履歴ブロックデータは約250 GBに制限されます（100K） (3600 (24 * 365) / 12、ブロック時間=12秒)。
2. EIP-4844：シャードBLOBトランザクション：EIP-4844は18日より古いBLOBを破棄します。これはEIP-4444と比較してより積極的なアプローチで、過去のBLOBサイズを約100 GBに制限します（（18 360024)128K6 / 12、ブロック時間 = 12秒の場合）。

すべてのクライアントから履歴データを刈り取るという結果は何ですか？ 主なものは、新しいノードが「フル同期」を介して最新の状態に同期できないことです - ジェネシスブロックから最新のブロックまでのトランザクションを再生する同期。代わりに、イーサリアムのピアから最新の状態を同期するために「スナップ同期」または「ステート同期」に頼る必要があります。このアプローチは、すでにGethに実装されており、デフォルトの同期として実行されています。

同様に、この結果はすべてのL2にも適用されます。つまり、L2の新しいノードは、イーサリアムのL2ジェネシスからL2ブロックをリプレイして最新の状態を完全に再生することはできません。さらに、L1ノードはL2の状態を維持しないため、L2の「スナップ同期」アプローチでは、L1から最新のL2状態を導出することはできません。これにより、イーサリアムのセキュリティ保証を継承するという重要なL2の仮定が崩れることになります。予定されている解決策は、Infura / Etherscan / L2プロジェクト自体などの第三者サービスに依存し、歴史的なL2データや状態のコピーを保存することになりますが、これはプロトコル外の間接的なインセンティブで中央集権化されています。

私たちが問いかけている中心的な問いは

• 問題について、ストレージとアクセスの両方においてより良い分散化ソリューションを持つことは可能ですか？
• イーサリアムに合わせた信頼度最小限のソリューション（例：L1契約の上に）を直接インセンティブソリューションで構築することは可能ですか？
• これらすべてを考慮して、イーサリアムロードマップにおいて、完全に分散化された方法でイーサリアムストレージに直接インセンティブを与えるためのプロトコル内の解決策への道筋を作ることは可能でしょうか？

ソリューション

ソリューション1：イーサリアムポータルネットワーク

Ethereum Portalネットワークは、軽量で分散型のEthereumプロトコルへのアクセスネットワークとして機能します。 eth_call、eth_getBlockByNumberなどのEthereum JSON-RPCインターフェースを提供し、JSON-RPCリクエストをP2Pリクエストに変換して分散ハッシュテーブルに送信します。これはIPFSネットワークと同様です。 IPFSは任意のデータタイプの格納を許可し、スパムの影響を受けやすい一方、Portal P2Pネットワークは歴史的なヘッダーや本体などのEthereumデータのみを専用でホストします。これはPortalネットワーク内に組み込まれたライトクライアント検証技術によって達成されます。

Portalネットワークの重要な特徴の1つは、軽量動作とリソースが制約されているデバイスとの互換性を考慮した設計です。数メガバイトのストレージと低メモリを搭載したノード上で実行でき、分散化を促進します。携帯電話やRaspberry Piデバイスでも、ネットワークに参加してEthereumデータの可用性に貢献する可能性があります。

Portalネットワークの開発は、Rust、JavaScript、Nim、およびGoで書かれたクライアントを使用するEthereumクライアントの多様性の哲学と一致しています。ビーコンネットワークと履歴ネットワークは使用準備ができていますが、状態ネットワークは積極的に開発中です。特筆すべきは、Portalネットワークがデータストレージに直接的なインセンティブを提供していないことです。ネットワーク内のすべてのノードは利他的に運営されています。

イラスト：100MBのストレージ制限でPortalネットワーク（Trin）を実行しています。

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

EthStorageネットワークは、ESPプログラムからの助成金によってサポートされ、EIP-4844 BLOBを特に保存するために設計された分散型のインセンティブ付きストレージネットワークです。

• 最小限の信頼：中央集権型のデータブリッジが必要な既存のソリューションとは異なり、EthStorageはEthereumのコンセンサスと1/m信頼モデルに依存しています。許可なしのEthStorageストレージプロバイダー。 BLOBを保存する手順は次のようになります：ユーザーはBLOBを運ぶトランザクションに署名し、ストレージ契約のput（key、blob_idx）メソッドを呼び出します。 ストレージ契約はその後、BLOBハッシュを記録し、イベントでストレージプロバイダーに通知します。 イベントを受信したストレージプロバイダーは、その後、Ethereum DAネットワークから直接BLOBをダウンロードして保存し、データブリッジの問題を回避します。
• インセンティブとストレージコストを一致させる：呼び出すときput()メソッド、ストレージ料金を送金する必要があります（msg.value)および契約に預けられます。この保管料は、保管証明の提出と検証が成功した場合に、時間の経過とともに保管プロバイダーに徐々に分配されます。現在のイーサリアムの保管料モデルが提案者に一度だけ保管料を支払うのに対して、時間の経過とともに支払われる保管料は、保管コストが時間とともにETHに対して減少すると仮定した割引キャッシュフローモデルに従います。EthStorageによって導入されたこの重要なイノベーションは、ユーザーが支払う料金と保管プロバイダーの貢献が時間とともに一致するようにします。
• ストレージの証明：ストレージの証明は、データ利用可能サンプリングに触発されていますが、EthStorageのサンプリングは、提案されたブロックの代わりに時間の経過とともにBLOBに対して実行されます。チェーン上でサンプリングを効率的に検証するために、EthStorageはスマートコントラクトとSNARK技術の最新の進歩を大いに活用しています。
• Permissionless Network: EthStorage内の任意のノードは、データを格納し、定期的にオンチェーンでストレージの証明を提出する限り、ストレージプロバイダーとして支払われることができます。

ブロックチェーンのモジュラリティの観点から、EthStorageはイーサリアムのレイヤー2として機能しますが、取引手数料の代わりにストレージ手数料を集めます。オンチェーンでBLOBハッシュをインデックス化することで、EthStorageは著しいストレージの拡張性とコスト削減を持つイーサリアムのモジュラストレージレイヤーであり、約1000倍をターゲットにしています。

開発面では、EthStorageはすでにEthereum Sepoliaテストネット上でEIP-4844と統合されています。EthStorageとEthereum Sepoliaテストネットのストレステストが実施され、EthStorageに数百GBのBLOBが書き込まれました。50人以上のコミュニティ参加者がネットワークに参加し、ローカルストレージを成功裏に証明しました。

EthStorageネットワークの主な利点は、現在の知識が及ぶ範囲では先駆的な機能であるEthereumの上に分散型で直接的なインセンティブを提供することにあります。ただし、ネットワークの制限は、固定サイズのBLOBに特化していることです。

Ethereum DevnetのEthStorageのダッシュボード

未来を予測する

イーサリアムのストレージは、あまり注目されていませんが、イーサリアムエコシステム内で重要な意味を持っています。イーサリアムネットワークが急速に成長しているため、イーサリアムデータのストレージとアクセシビリティは重要な課題となっています。PortalネットワークとEthStorageネットワークはまだ初期段階にありますが、長期的にはいくつかの興味深い方向性を展望しています。

• イーサリアムの状態への分散型の低レイテンシアクセス。分散型かつ検証可能な方法でイーサリアムの状態にアクセスすることは、重要ながらも困難な課題です。従来のDHTセットアップでは、通常、異なるP2Pノードに格納された内部トライノードの複数のクエリが必要です。これにより、かなりの長いレイテンシが発生することがよくあります。状態ツリーの構造をどのように活用してアクセスを加速するかが鍵であり、これにはイーサリアム・ポータル・ネットワークの今後の状態ネットワークで取り組まれています。
• Portal NetworkとEthStorage Networkの統合：Portal NetworkはBLOBsをネットワーク内にシームレスに拡張することができ、EthStorageチームによってすでに一部実施されています。これらのネットワークを統合して、BLOBsにアクセス可能なコントラクトを呼び出すことができる分散型JSON-RPCネットワークを提供することが自然な進化です。契約のアプリケーションロジックとEthStorageによるスケーリングされたBLOBストレージを組み合わせることで、動的な分散型Webサイト（例：分散型Twitter/YouTube/Wikipediaなど）など、Ethereum上での新しいdAppsを可能にします。
• ブラウザからの分散アクセス：IPFSネットワーク内のデータにアクセスするために使用されるipfs://プロトコルに類似して、ブラウザからのEthereumネイティブアクセスプロトコルへの需要が高まっています。これにより、トークンの所有権や残高からNFT画像や動的な分散型ウェブサイトまで、スマートコントラクトの機能と将来のEthereumストレージによって可能にされた豊富なデータを活用することができます。この領域では、ERC-4804/6860で定義されたweb3://プロトコルが、この目的を果たすために現在積極的な開発が行われています。
• 動的サイズのデータに対する高度なストレージ証明：固定されたBLOBを超えて、歴史的なブロックや状態オブジェクトなどの動的サイズのデータに対処するために、高度なストレージ証明を探求することが不可欠となります。洗練されたアルゴリズムの開発により、ストレージソリューションの適応性を向上させることができます。

私たちの追求では、これらの取り組みが合わせて、イーサリアムのロードマップに貢献し、イーサリアムエコシステム内で将来の分散型ストレージソリューションの基盤を築くことを望んでいます。

ステートメント:

1. この記事は[から転載されましたテックフローディープタイド], 元のタイトルは「イーサリアムストレージロードマップ：課題と機会」です、著作権は元の著者[ EthStorage ]に属します、転載に異議がある場合はお問い合わせくださいGate Learn チーム、チームは関連手続きに従ってできるだけ早く対処します。

2. 免責事項：この記事で表現されている見解や意見は、著者個人の見解を表しており、いかなる投資アドバイスを構成するものではありません。

3. 他の言語版はGate Learnチームによって翻訳されており、記事には言及されていませんゲート.io, 翻訳された記事の転載、配布、または盗用はできません。