History Expiry とは？
Ethereum のノードが、トランザクション、ブロック、イベントログなどの最新1年のデータのみを保存するというアイデア。
これにより、コードの複雑さが軽減され、ノードのストレージ要件が軽減され、より分散化への道が開かれる。
History Expiry 関連の提案
2 つの提案がある。これらは排他的なものではなく、両方とも実施可能。
- Eth 2 マージ後、数ヶ月〜1年でマージ前の PoW チェーンのダウンロード/提供を停止する
- 最新1年のデータのみを保存する（EIP-4444）
History Expiry 提案の背景
Ethereum クライアントは現在、チェーンの検証に必要のない 275 GB の履歴データを保存している。その数は、年間約 140 GB の割合で増加している。
履歴データの使用法は 2 つある：
- 同期
- 完全同期： ジェネシスから、すべてのブロックをダウンロードし、チェーンの先頭に到達するまで実行する
- ステートの同期： ヘッダーのみを同期し、最新のブロックのステートをダウンロードする
- ユーザーのリクエスト
どちらの場合も、クライアントは P2P ネットワークを介して履歴データを要求する。この信頼モデルでは、ジェネシス・ステートを信頼し、他のすべてを完全に検証するか、PoW チェック（検証するためのハッシュ値）で検証する。
PoS ではこれが変わる。ロングレンジ攻撃を避けるため、「WS（Weak Subjectivity）チェックポイント」が作成される。WSチェックポイントを使うと、クライアントは、P2P ネットワークを介して履歴データを要求するブートストラップ的な手順をスキップできる。これで同期のための古い履歴データは不要となる。
古い履歴データを要求するユーザーのリクエストについては、外部のプロトロルなどによって解決できる。
History Expiry 導入後、古いデータを保存するエンティティは？
- Etherscan などのブロックエクスプローラー
- The Graph のような外部プロトコル
- The Portal Network のようなサブプロトコル
- ボランティアノード
Etherscan などのブロックエクスプローラや、The Graph などの外部プロトコルは、それぞれのビジネスモデルを考えると、過去のデータを表示することに金銭的なインセンティブがあるかもしれない。
The Portal Network のような内部プロトコルは、ノードが全履歴の小さな部分を保持することを容易にする。
また、一部のボランティアノードは、純粋な利他主義から全履歴データを保持することがある。
これらエンティティの潜在的なインセンティブは？
- 外部の報酬
- プロトコル内の報酬
- 利他主義（他人の幸福や利益を図ることをまず第一とする考え方）
- 評判
新しいブロック報酬などのプロトコル内の報酬は、完全な履歴データを持つノードを実行するユーザーにインセンティブを与えるように設計されている場合がある。
Dapps から支払われる外部の報酬は、The Graph のようなインデクサーのインセンティブになる可能性がある。また、例えば、そのようなノードを実行する人に与えられるユニークな NFT / バッジ など、評判が機能する場合もある。
純粋な利他主義から、これらのノードを実行するユーザーもいるかもしれない。
注：これらのインセンティブメカニズムはすべて、まだ研究中である。最終的な結果は、コミュニティの貢献によってもたらされるだろう。