イーサリアムの可能な未来：The Purge

作者：ヴィタリック・ブテリン

翻訳：夫はどうか

フィードバックとレビューを提供してくれた Justin Drake、Tim Beiko、Matt Garnett、Piper Merriam、Marius van der Wijden、Tomasz Stanczak に感謝します。

イーサリアムが直面している課題の一つは、デフォルトで、あらゆるブロックチェーンプロトコルの膨張と複雑性が時間とともに増加するということです。これは二つの場所で発生します：

履歴データ：歴史上のあらゆる瞬間に行われたあらゆる取引および作成されたあらゆるアカウントは、すべてのクライアントによって永続的に保存され、任意の新しいクライアントによってダウンロードされる必要があり、ネットワークに完全に同期されます。これにより、クライアントの負荷と同期時間は時間の経過とともに増加し続け、チェーンの容量が変わらない場合でもそうなります。

プロトコルの機能：新しい機能を追加することは古い機能を削除することよりもはるかに簡単であるため、時間の経過とともにコードの複雑性が増加します。

イーサリアムが長期的に維持されるためには、これら二つのトレンドに強力な逆圧力を加え、時間の経過とともに複雑性と膨張を減少させる必要があります。しかし同時に、ブロックチェーンを素晴らしいものにする重要な特性の一つである持続性を保持する必要があります。NFT、一通の取引通話データ内のラブレター、または100万ドルを含むスマートコントラクトをチェーン上に置き、洞窟に10年入って出た時、それがまだあなたの読解と相互作用を待っていることを発見することができます。DAppが安心して完全に分散化し、アップグレードキーを削除するためには、依存関係が彼らを破壊する方法でアップグレードされないことを確信する必要があります - 特にL1自体が。

もし私たちが決意し、これら2つの需要の間でバランスを取り、連続性を維持しながら冗長性、複雑さ、衰退を最小限に抑えたり逆転させたりすることが可能です。生物はこれを実現できます：ほとんどの生物は時間とともに老化しますが、少数の幸運な生物はそうではありません。社会システムでさえ非常に長い寿命を持つことができます。いくつかのケースでは、イーサリアムは成功を収めています：プルーフ・オブ・ワークは消え、SELFDESTRUCT操作コードの大部分も消え、ビーコンサインノードは最大6ヶ月間の古いデータを保存しています。イーサリアムのためにこの道をより一般的な方法で見つけ、長期的な安定した最終結果に向かうことは、イーサリアムの長期的なスケーラビリティ、技術的持続可能性、さらには安全性にとって究極の課題です。

! ヴィタリック:イーサリアムの未来の可能性、パージ

ザ・パージ：主要な目標。

各ノードがすべての履歴や最終状態を永続的に保存する必要を減らすことによって、クライアントのストレージ要件を軽減します。

不要な機能を排除することで、プロトコルの複雑さを下げる。

目次:

履歴の有効期限

ステートエクスパイア（状態到期）

フィーチャークリーニング（特征清理）

###履歴の有効期限

どのような問題を解決しますか？

この記事執筆時点では、完全に同期されたイーサリアムノードには、クライアントを実行するために約1.1TBのディスクスペースが必要であり、さらにコンセンサスクライアント用に数百GBのディスクスペースが必要です。その大部分は履歴です：歴史的なブロック、取引、および領収書に関するデータで、そのほとんどは数年前のものです。これは、Gas制限がまったく増加しなくても、ノードのサイズが毎年数百GB増加し続けることを意味します。

それは何ですか、どのように機能しますか？

履歴の保存に関する問題の重要な簡略化された特徴は、各ブロックがハッシュリンク（およびその他の構造）を通じて前のブロックを指しているため、現在の合意に達することが歴史的な合意に達するのに十分であるということです。ネットワークが最新のブロックに対して合意に達している限り、任意の過去のブロックやトランザクションまたは状態（アカウント残高、ランダム数、コード、ストレージ）は、任意の単独の参加者によって提供され、マーケル証明によって確認され、他の誰でもその正当性を検証することができます。合意はN/2-of-N信頼モデルであり、歴史はN-of-N信頼モデルです。

これにより、履歴を保存する方法について多くの選択肢が提供されます。自然な選択肢の一つは、各ノードがデータの小さな部分のみを保存するネットワークです。これが、数十年にわたってシードネットワークが機能してきた方法です：ネットワークは合計で数百万のファイルを保存し配布していますが、各参加者はその中のいくつかのファイルのみを保存し配布します。直感に反するかもしれませんが、この方法は必ずしもデータの堅牢性を低下させるわけではありません。ノードをより経済的に運営することで、各ノードがランダムに10%の履歴を保存する100,000のノードを持つネットワークを構築できるなら、各データは10,000回コピーされます - これは、すべての内容を保存する各ノードを持つ10,000のノードの複製因子と完全に同じです。

今、イーサリアムはすべてのノードがすべての履歴を永久に保存するモデルから脱却し始めています。コンセンサスブロック（すなわち、プルーフ・オブ・ステークコンセンサスに関連する部分）は約6ヶ月間のみ保存されます。Blobは約18日間のみ保存されます。EIP-4444は、履歴ブロックとレシートに1年間の保存期間を導入することを目指しています。長期的な目標は、すべてのノードがすべての内容を保存する責任を持つ統一された期間（おそらく約18日）を確立し、その後、イーサリアムノードで構成されるピアツーピアネットワークを構築し、古いデータを分散ネットワーク方式で保存することです。

! Vitalik:イーサリアムの可能な未来、パージ

エラージャーコードは、ロバスト性を向上させるために使用でき、複製係数を同じに保つことができます。実際、Blobはデータの可用性サンプリングをサポートするためにエラージャーコードを適用しています。最も簡単な解決策は、このエラージャーコードを再利用し、実行およびコンセンサスブロックデータもBlobに入れることになるでしょう。

既存の研究との関連は何ですか？

EIP-4444;

トレントとEIP-4444；

ポータルネットワーク；

ポータルネットワークと EIP-4444；

Portal における SSZ オブジェクトの分散ストレージと検索；

ガス制限をどのように引き上げるか（パラダイム）。

何をまだ行う必要があり、何を考慮する必要がありますか？

残りの主要な作業は、履歴を保存するための具体的な分散ソリューションを構築し統合することです------少なくとも実行履歴ですが、最終的にはコンセンサスと blob も含まれます。最も簡単なソリューションは (i) 既存のトレントライブラリを単純に導入することと、(ii) エーテルのネイティブソリューションであるPortalネットワークを導入することです。それらのいずれかを導入すれば、EIP-4444を開くことができます。EIP-4444自体はハードフォークを必要としませんが、新しいネットワークプロトコルバージョンが必要です。したがって、すべてのクライアントに同時に有効にすることは価値があります。そうしないと、他のノードに接続し、完全な履歴をダウンロードすることを期待しながら実際には取得できないために、クライアントが故障するリスクがあります。

主要なトレードオフは、私たちが「古代」の履歴データを提供するためにどのように努力するかに関係しています。最も簡単な解決策は、明日から古代の履歴を保存するのを停止し、既存のアーカイブノードとさまざまな中央集権的プロバイダーに依存して複製することです。これは簡単ですが、イーサリアムが永久記録の場としての地位を弱めます。より困難ですが、より安全な方法は、まずトレントネットワークを構築し、統合して、分散方式で履歴を保存することです。ここで、「私たちはどれだけ努力しているか」には2つの次元があります：

私たちはどのようにして最大のノードセットがすべてのデータを確実に保存していることを保証するために努力していますか？

プロトコルに統合された歴史的ストレージの深さはどのくらいですか？

（1）に対する極端な偏執的アプローチの1つは、プルーフ・オブ・ステークの保管を含むものであり、実際には各ステーク検証者が一定の割合の履歴を保存し、定期的にそれを暗号化してチェックすることを要求します。より穏健なアプローチは、各クライアントが保存する履歴の割合に対して任意の基準を設定することです。

(2)に関して、基本的な実装は今日完了した作業にのみ関係しています：ポータルは、イーサリアムの全歴史を含むERAファイルをすでに保存しています。より徹底的な実装は、実際にそれを同期プロセスに接続することを含むため、誰かが完全な歴史を保存するノードまたはアーカイブノードを同期したい場合、他のアーカイブノードがオンラインで存在しなくても、ポータルネットワークから直接同期することで達成できます。

それはロードマップの他の部分とどのように相互作用しますか？

ノードの実行または起動を非常に簡単にしたいのであれば、履歴ストレージの要求を減らすことは無状態性よりも重要であると言えます。ノードに必要な1.1 TBのうち、約300 GBが状態で、残りの約800 GBは履歴となっています。無状態性とEIP-4444を実現することで、スマートウォッチでエーテルノードを実行し、数分で設定できるというビジョンが実現できるのです。

履歴ストレージの制限は、より新しいイーサリアムノードの実装をより実行可能にし、プロトコルの最新バージョンのみをサポートします。これにより、ノードがよりシンプルになります。たとえば、2016年のDoS攻撃の際に作成された空のストレージスロットがすべて削除されたため、現在多くのコード行を安全に削除できるようになりました。プルーフ・オブ・ステークへの移行が歴史的なものとなったので、クライアントはプルーフ・オブ・ワークに関連するすべてのコードを安全に削除できます。

ステートの有効期限

どの問題を解決しますか？

クライアントが履歴の保存を必要としなくなったとしても、クライアントのストレージ需要は毎年約50GB増加し続けます。これは、アカウントの残高やランダム数、コントラクトコード、コントラクトストレージなどの状態が持続的に増加するためです。ユーザーは一度の料金を支払うことで、現在および将来のイーサリアムクライアントに永遠に負担をかけることになります。

状態は歴史よりも"期限切れ"になることが難しい。なぜなら、EVMは根本的にこの仮定に基づいて設計されているからだ：一度状態オブジェクトが作成されると、それは常に存在し、いつでもどんなトランザクションからでも読み取ることができる。無状態性を導入すると、ある人々はこの問題はそれほど悪くないと考えている：特別なブロックビルダーのクラスだけが実際に状態を保存する必要があり、他のすべてのノード（リスト生成を含む！）は無状態で動作できる。しかし、無状態性に過度に依存したくないという見解もあり、最終的にはイーサリアムの分散化を維持するために状態を期限切れにすることを望むかもしれない。

! Vitalik:イーサリアムの可能な未来、パージ

それは何ですか、それはどのように機能しますか

今日、新しい状態オブジェクトを作成するとき（次の3つの方法のいずれかで発生する可能性があります：（i）新しいアカウントにETHを送信する、（ii）コードを使用して新しいアカウントを作成する、（iii）以前に触れていないストレージスロットを設定する）、その状態オブジェクトは永遠にその状態に留まります。逆に、私たちが望んでいるのは、オブジェクトが時間とともに自動的に期限切れになることです。重要な課題は、3つの目標を達成する方法でそれを実現することです：

効率：期限プロセスを実行するために、大量の追加計算は必要ありません。

ユーザーフレンドリー：誰かが5年間洞窟に入って戻ってきた場合、彼らはETH、ERC20、NFT、CDPポジションへのアクセス権を失うべきではない......

開発者の親しみやすさ：開発者は全く馴染みのない思考モデルに切り替える必要がありません。また、現在は硬直化しており更新されていないアプリケーションは引き続き正常に動作するべきです。

これらの目標を満たさないと、問題を解決するのは簡単です。たとえば、各状態オブジェクトが期限日カウンターを保存するようにすることができます（ETHを燃やすことで期限日を延長でき、これはいつでも読み取りまたは書き込み時に自動的に発生する可能性があります）、そして、期限日を削除するための状態オブジェクトをループで巡回するプロセスがあります。しかし、これにより追加の計算（さらにはストレージの要求）が発生し、ユーザーの使いやすさの要求を確実に満たすことはできません。開発者は、ストレージ値が時々ゼロにリセットされるエッジケースを推論するのが難しいです。契約の範囲内で期限のカウントダウンタイマーを設定すると、技術的には開発者の生活を楽にしますが、経済的にはより困難になります：開発者は持続的なストレージコストをユーザーに"転嫁"する方法を考慮しなければなりません。

これらはすべて、イーサリアムのコア開発コミュニティが長年にわたって解決に取り組んできた問題であり、「ブロックチェーンレンタル」や「再生」などの提案を含んでいます。最終的に、私たちは提案の中で最も優れた部分を組み合わせ、「既知の最悪でない解決策」の2つのカテゴリに集中しました：

• 一部のステータスの期限切れ解決策
• アドレス周期に基づくステータスの期限に関する提案。

部分的な状態の有効期限

部分状態の期限切れ提案は、同じ原則に従います。私たちは状態をブロックに分けます。誰もが"トップマッピング"を永久に保存します。