はじめに
初めまして。 CryptoGamesというブロックチェーンゲーム企業でエンジニアをしている cardene（かるでね） です！ スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。
代表的なゲームはクリプトスペルズというブロックチェーンゲームです。
今回は、1年以上前のトランザクション履歴データを削除する提案しているEIP4444についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
4444は現在（2024年1月21日）では「Stagnant」段階です。
他にも様々なEIPについてまとめています。
概要
クライアントは、P2P（ピアツーピア）レイヤーにおいて、1年以上前の履歴であるヘッダー、ボディ、レシートの提供を停止できます。 クライアントは、この履歴データをローカルで削除することができるようになります。
P2Pネットワークを利用するクライアント（ソフトウェア）に関する指示です。 1年以上前の過去のトランザクションや通信の記録のデータはネットワーク上での提供を停止し、必要に応じてクライアントのローカルストレージから削除することが推奨されています。
この指示の背景には、データ管理の効率化やセキュリティの向上があります。 古いデータはほとんど必要なくなるため、これを保持し続けることはストレージの無駄遣いになります。 また、過去のデータを適切に処理しないと、セキュリティ上のリスクにもなり得ます。 したがって、このような措置は、ネットワーク全体の健全性と効率を保つために重要です。
動機
ブロックチェーンネットワークにおけるデータ管理の問題と提案された解決策について説明しています。
ブロックとレシートの履歴が400GB以上のディスクスペースを占めているため、チェーンを検証するユーザーは大容量のディスクを必要としています。
しかし、新しいブロックの検証にはこの履歴データは必要ありません。
提案されている解決策は、「履歴の剪定（せんてい）」と呼ばれるプロセスです。 これは、クライアントがチェーンの最新状態に同期した後、古いデータを削除することを意味します。 この履歴データは、特定の要求がある場合や他のピアがチェーンを同期しようとするときにのみ取得されます。 このアプローチにより、ユーザーのディスク容量要件が減少し、クライアントのソフトウェアも簡素化されます。 また、各アップグレードに伴う複雑なコードの維持が不要になり、効率的な運用が可能になります。
さらに、この変更により、Proof of Stake（PoS）に基づくより軽量な同期戦略を採用するクライアントが増えることで、ネットワーク全体の帯域幅の使用量も削減されます。 これは、ネットワークの効率化と持続可能性の向上に寄与する重要なステップです。
仕様
ビーコンチェーンにおける履歴データの剪定（削減）とクライアントの同期方法に関する提案です。
「HISTORY_PRUNE_EPOCHS」とは、ビーコンチェーンのエポックで1年間を表す値（82125）です。
この提案によれば、クライアントはこの時間より古いヘッダー、ブロックボディ、レシートをP2Pネットワーク上で提供すべきではなく、ローカルで削除することが推奨されます。
このEIPは、クライアントのブートストラップ（初期設定）と同期方法に大きな影響を与えます。 履歴データが提供されないため、従来のdevp2pを使用した完全同期は不可能になります。 代わりに、クライアントは有効なWeak Subjectivity Checkpointを使用して、チェーンの最新の状態からブートストラップする必要があります。 この方法では、Weak Subjectivity Checkpointは事実上の「ジェネシスブロック」として機能し、「チェックポイント同期」と呼ばれます。
この提案の目的のために、クライアントは常に設定された有効なWeak Subjectivity Checkpointから開始すると仮定されていますが、このチェックポイントをどのように設定するかは、この提案の範囲外です。 この提案は、ネットワークの帯域幅とストレージの要件を削減し、効率を向上させることを目的としています。
Weak Subjectivity Checkpoint
ブロックチェーン、特にProof of Stake（PoS）を採用しているブロックチェーンでは、ネットワークの整合性を維持するために全ノードが同じブロックチェーンの履歴を共有することが重要です。 しかし、新しい参加者がネットワークに参加する時や、長期間オフラインだったノードが再同期する時には、ブロックチェーンの完全な履歴をダウンロードして検証することが非常に時間とリソースを要します。
ここで「Weak Subjectivity Checkpoint」の概念が登場します。 このチェックポイントは、ユーザーがネットワークに初めて参加する時や、長期間オフラインだった後に再同期する時に、ブロックチェーンの一定のポイントから同期を開始するために使用されます。 これにより、ブロックチェーンの完全な履歴をダウンロードし検証する代わりに、特定のポイントからのみデータをダウンロードし、それ以降の履歴のみを検証することができます。
しかし、これには「Weak Subjectivity」という要素が関わります。 チェックポイントを選択する時、ユーザーは通常、信頼できるソースやコミュニティの推奨に基づいて判断します。 これは、完全な客観性ではなく、ある程度の主観性を伴うため、「Weak Subjectivity」と呼ばれます。
このアプローチにより、ネットワーク参加者は迅速に同期を行い、リソースを節約しながらもネットワークのセキュリティと整合性を維持することができます。 ただし、信頼できるチェックポイントを選択することが重要で、間違ったチェックポイントを選ぶとネットワークの安全性に問題が生じる可能性があります。
補足
ブロックチェーンネットワークの運用に関する新しい提案について述べています。 この提案の主な目的は、P2Pネットワーク上でクライアントが提供する古い履歴データを停止することを義務付けることです。 これは、クライアントが履歴データにアクセスする時に、P2Pネットワークに頼らず、代わりに他の情報源を積極的に探索することを奨励するために設計されています。
現在の状況では、いくつかのクライアントが任意に古いデータを提供していますが、これはネットワーク全体の品質に不均一性をもたらし、信頼性やデータの整合性に影響を与える可能性があります。 この提案によって、クライアントは特定の古いデータに依存することなく、より信頼性の高い情報源からデータを取得することが推奨されます。 これにより、ネットワークの品質とデータの整合性が向上し、ユーザー体験が改善されることが期待されます。 また、このアプローチは、ブロックチェーンネットワークのスケーラビリティと効率を高めるためにも重要です。
なぜ一年？
ブロックチェーンデータの履歴を剪定する時の時間枠について説明しています。
この提案では、HISTORY_PRUNE_EPOCHSの値を82125エポック、つまり1年間に設定しています。
この設定の理由は、二つの重要な要素のバランスをとるためです。
まず、「Weak Subjectivity Period」という概念があります。
これは、ブロックチェーンのネットワークに新たに参加するノードが信頼できる情報源から適切なチェックポイントを得るための期間を指します。
82125エポックという数値は、このWeak Subjectivity Periodが十分に成長し、新参者が信頼できる情報を収集するのに適切な時間を提供します。
一方で、履歴ブロックチェーンデータは大量のディスクスペースを必要とします。
したがって、この期間を短く設定することで、必要なディスクスペースを適切に抑えることができます。
82125エポックという値は、これらの要件を満たすための妥当な妥協点として提案されています。
この提案は、ブロックチェーンのセキュリティと整合性を保ちつつ、ディスクスペースの使用量を合理的に抑えるためのバランスの取れたアプローチを提供します。
互換性
履歴データの保存
イーサリアムネットワークにおける履歴データの保存とアクセスに関する提案について説明しています。 特に、履歴データを活用するノードやアプリケーションに与える影響に焦点を当てています。
提案では、イーサリアムの履歴を保存することの重要性を強調し、そのための代替手段としてtorrentやIPFSなどのネットワークを通じてデータを共有する方法、Portal NetworやThe Graphのようなシステムを利用する方法を挙げています。 これらの方法は、ブロックチェーンのトランザクション履歴やアカウントデータを保存し、必要に応じてアクセス可能にするための効果的な手段です。
また、提案ではクライアント（ユーザーが使用するソフトウェア）に、履歴データのインポートとエクスポートを可能にする機能を持たせることが求められています。 これにより、ユーザーは必要なデータを容易に取り込むことができ、また、データの確認や検証を自動化するスクリプトを利用してデータの整合性を保つことができます。
このように、イーサリアムネットワークの履歴データの保存とアクセスの方法を改善し、ネットワークの効率化とスケーラビリティを高めることが目指されています。 ユーザーが履歴データに容易にアクセスし、それを活用することで、イーサリアムエコシステムの全体的な価値と実用性が向上することが期待されます。
ジェネシスからの完全同期
イーサリアムネットワークにおけるジェネシスブロックからの完全な同期の将来について述べています。 以前は、P2Pネットワークを通じてイーサリアムチェーンの完全な履歴を同期することが可能でしたが、この提案ではそれが不可能になることが明らかにされています。 それでも、完全同期に関心のある人には、独自の方法で実行する方法が考えられています。
提案されている解決策は、特別な「フル同期」クライアントを構築することです。 このクライアントは、異なるバージョンの実行エンジンを組み合わせて、イーサリアムチェーンの全履歴をジェネシスブロックから検証し、必要な履歴データを生成するためのツールです。
また、アーカイブノードの開発が進行中であり、これらのノードは「ステート同期」機能を持つものの、現在のところフル同期はこれらのノードを有効にする唯一の信頼できる方法であると強調されています。 アーカイブサポートを提供し続けたいクライアントは、外部から取得したブロック履歴をインポートする機能と、ネットワークの各アップグレードに対応するためのサポートを維持する必要があります。 これにより、イーサリアムチェーンの完全な履歴と整合性が保たれることになります。
ユーザー・エクスペリエンス
履歴データを使用するアプリケーションの設定に関するユーザーエクスペリエンスへの影響と、それに対するクライアントの対応方法について説明しています。
提案された変更を段階的に導入することが提案されています。
第一フェーズでは、クライアントはデフォルトでは履歴データを剪定しませんが、ユーザーが必要に応じて履歴データを剪定できるようにするコマンドラインオプションを提供します。
これはGethの--txlookuplimitオプションに似た機能です。
第二フェーズでは、履歴データの剪定がデフォルトの動作となり、第一フェーズで導入されたコマンドラインオプションは削除されます。 これにより、ユーザーは外部の手段を通じて必要な履歴データを自ら見つけてインポートすることが想定されます。 この段階的なアプローチにより、ユーザーは新しいシステムに順応しやすくなるとともに、クライアントは履歴データの管理をより効率的に行うことができるようになります。 この変更は、ユーザーが履歴データをどのように取得し、使用するかに大きな影響を与えるため、慎重な導入が必要です。
JSON-RPCの変更
提案が実施された後のJSON-RPCエンドポイントにおける変更とその影響について説明しています。
具体的には、特定のJSON-RPCエンドポイントが、与えられたハッシュが無効なものなのか、それとも単に古い履歴なのかを区別できなくなることを指摘しています。
たとえば、getBlockByHashのようなエンドポイントは、特定のハッシュに対応するブロックが存在するかどうかを判断できなくなります。
さらに、getLogsのようなエンドポイントは、ユーザーが要求するログデータをもはや持たなくなる可能性があります。
このような変更は、アプリケーションやクライアントがどのように対応するべきかという問題を引き起こしますが、この提案ではその対応方法については範囲外とされています。 つまり、これらのエンドポイントの変更がアプリケーションやユーザー体験にどのような影響を及ぼすか、そしてそれらの問題をどのように解決すべきかについてのガイドラインは提供されていません。 このため、アプリケーション開発者やクライアントの運用者は、これらの変更に対応するための独自の解決策を考える必要があります。
セキュリティ
weak subjectivityに頼る
Proof of Stake（PoS）への移行におけるセキュリティ上の考慮点、特に「weak subjectivity」に関する提案の重要な側面を説明しています。 PoSシステムでは、長期範囲攻撃（長い時間が経過した後に行われる不正なブロックチェーンの改ざん）を防ぐために、Weak Subjectivity Checkpointの使用が重要です。 このチェックポイントは、ネットワークの特定の状態を信頼できる参照点として使用します。
提案では、クライアントが無効または古いWeak Subjectivity Checkpointでブートストラップしないという前提に基づいています。 これは、クライアントが信頼できる最新のチェックポイントからネットワークに参加することを意味します。
さらに、提案はWeak Subjectivity PeriodがHISTORY_PRUNE_EPOCHS（履歴データが剪定される期間）を超えないと仮定しています。
もしWeak Subjectivity Periodがこの値を超える場合、古いチェックポイントを持つクライアントは、必要な履歴データがP2Pネットワーク上で提供されないため、チェーンを同期することができなくなります。
これは、クライアントがブロックチェーンの現在の状態に追いつくための「チェックポイント同期」機能に影響を与える可能性がある重要なリスクです。
このリスクを回避するためには、Weak Subjectivity Periodとデータ剪定期間のバランスを適切に管理することが不可欠です。
中央集権化／検閲リスク
イーサリアムの履歴データの保持とアクセスに関連する中央集権化と検閲のリスクについて述べています。 特に、履歴データを維持するための十分なインセンティブがない場合、データの可用性や検閲に関する問題が生じる可能性が指摘されています。
この文脈で、イーサリアムの履歴データが独立した組織によって保存され、定期的にその可用性がチェックされることの重要性が強調されています。 しかし、この提案では、そのようなメカニズムの具体的な実装や管理については触れていません。
さらに、フルノードのセットアップがより困難になることにより、dapps（分散型アプリケーション）が履歴データを取得するために中央集権化されたサービスに依存するリスクが高まることが懸念されています。 これは、ブロックチェーンの分散化と無許可の原則に反する動向であり、イーサリアムエコシステムの健全性に影響を与える可能性があります。 このため、dappsの開発者や運用者は、データの分散化された保存とアクセス方法に対する代替案を検討する必要があります。
他の提案との混同
実行クライアントのディスク上の占有スペースを減少させるための様々な代替提案が存在する中で、この特定のEIPを他の提案と区別するための明確なガイドラインが必要であるとされています。 そのため、このEIPの番号は「EIP "four fours"（EIPフォーフォーズ）」と宣言されるべきであり、それ以外の宣言は不正確とされています。
このような指示は、コミュニティ内での混乱を避けるために重要であり、特に多くの提案が同時に議論されている場合には、提案を正確に特定しやすくするために有用です。 この指示は、このEIPに関連するコミュニケーションや議論の中で一貫した用語を使用し、明確な理解を促進することを目的としています。
引用
George Kadianakis (@asn-d6), lightclient (@lightclient), Alex Stokes (@ralexstokes), "EIP-4444: Bound Historical Data in Execution Clients [DRAFT]," Ethereum Improvement Proposals, no. 4444, November 2021. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-4444.
最後に
今回は「1年以上前のトランザクション履歴データを削除する提案しているEIP4444」についてまとめてきました！ いかがだったでしょうか？
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
他の媒体でも情報発信しているのでぜひ他も見ていってください！