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

コンピレーション:Odaily Planet Daily How

10月14日以降、イーサリアムの創設者であるヴィタリック・ブテリンは、「The Merge」、「The Surge」、「The Scourge」、「The Verge」から「The Purge」の最新リリースまで、イーサリアムの将来の可能性に関する議論を公開し、イーサリアムメインネットの将来の発展に対するヴィタリックのビジョンと、現在直面している問題を解決する方法を強調しています。

《The Merge》：ETH坊がPoSに移行した後、スロットの最終性とドロップステークの閾値を改善して、参加度とトランザクションの確認速度を向上させることを探求しています。

《The Surge》：ETH坊の拡張に関する異なる戦略、特にRollupを中心としたロードマップ、および拡張性、分散化、セキュリティに関する課題と解決策について探究しています。

《The Scourge》：以太坊がPoSへの移行に直面する中心化と価値抽出リスクについて探究し、分散化と公正性を強化するためのさまざまなメカニズムを開発し、同時にユーザーの利益を保護するためのステーク経済改革を行いました。

《The Verge》：ETH坊のステートレス検証の課題と解決策について探求し、VerkleツリーやSTARKなどの技術がブロックチェーンの分散化と効率向上にどのように貢献しているかを重点的に紹介しています。

10月26日、Vitalik Buterinが『The Purge』に関する記事を公開し、記事ではETHが直面する課題がどのようにして長期間にわたり複雑さとストレージ要件をドロップし、同時にチェーンの持続性と分散化を維持するかについて探討されています。主要な対策には、「歴史の期限切れ」および「状態の期限切れ」を通じてクライアントのストレージ負担を軽減し、「特徴のクリーンアップ」を通じてプロトコルを簡素化してネットワークの持続性と拡張性を確保することが含まれています。

以下はオリジナルのテキストです。Odaily星球日報が翻訳しました。

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

ETH坊面临的挑战之一是，默认情况下，任何ブロックチェーンプロトコルの膨張と複雑性は時間の経過とともに増加します。これは2つの場所で発生します:

履歴データ：以前に行われたすべての取引および作成されたすべてのアカウントは、すべてのクライアントによって永久に保存され、新しいクライアントによってダウンロードされる必要があります。これにより、チェーンの容量が変わらなくても、時間の経過とともにクライアントの負荷と同期時間が増加する可能性があります。

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

イーサリアムが長期的に維持されるためには、これら2つのトレンドに強い抵抗力を持たせる必要があります。時間の経過とともに、複雑さと膨張をドロップさせる必要があります。しかし同時に、ブロックチェーンを素晴らしいものにするための重要な属性の1つである永続性を保持する必要があります。非代替トークン、トランザクション通話データ中のラブレター、または100万ドルのスマートコントラクトをオンチェーンに置いて、10年間洞窟に入り、出てきた時にまだそこにあって読み取りや操作ができることを確認するために、DAppsは完全に分散化され、アップグレードキーを削除する必要があります。彼らの依存関係が彼らの方法で破壊的にアップグレードされないことを特にL1自体が確認する必要があります。

もし私たちが決意を持って、これらの2つの要求のバランスを取り、持続性を保ちながら不要な複雑さや退化を最小限に抑えることができれば、それは絶対に可能です。生物はこれを達成することができます。ほとんどの生物は時間とともに老化しますが、ごくわずかな幸運な者はそうしません。社会システムでも非常に長い寿命を持つことができます。一部の場合、イーサリアムは既に成功を収めています：プルーフオブワークがなくなり、SELFDESTRUCTオペコードもほとんどなくなりました。ビーコンチェーンノードは最大で6ヶ月前のデータを保存しています。イーサリアムがこの道をより一般的な方法で見つけ、長期的な安定性に向かう最終的な結果に到達することは、イーサリアムの長期的な拡張性、技術的な持続可能性、そしてセキュリティの究極の課題です。

粛清:主な目的。

ノードごとに永久的にすべての履歴や最終状態を保存する必要性をドロップすることで、クライアントのストレージ要件を削減または排除します。

不要な機能を削除することにより、プロトコルの複雑さを低減します。

目次:

履歴の有効期限

ステート期限切れ

機能のクリーンアップ

履歴の有効期限

何を解決するのか？

本文を執筆する時点で、完全に同期したETHエーテルノードには、クライアントの実行に約1.1 TBのディスクスペースが必要であり、さらにコンセンサスクライアントに数百GBのディスクスペースが必要です。これには、歴史的なデータが含まれており、ほとんどが歴史的なブロック、取引、および受領に関するデータです。したがって、ガス制限が増加しなくても、ノードのサイズは年々数百GB増加し続けることを意味します。

それは何ですか、そしてそれはどのように動作しますか？

歴史的なストレージの問題の1つの重要な簡略化された特徴は、各ブロックがハッシュリンク（およびその他の構造）を介して前のブロックを指すため、現在のコンセンサスに達するだけで歴史的なコンセンサスに達することができることです。ネットワークが最新のブロックにコンセンサスを持っている限り、歴史的なブロックやトランザクション、または状態（口座残高、ランダム数、コード、ストレージ）は、どの個々の参加者でも提供することができ、さらにメルクル証明を通じてその証明を他の誰もが検証できるようになります。コンセンサスはN/2-of-N信頼モデルであり、歴史はN-of-N信頼モデルです。

これにより、私たちはどのように履歴を保存するかについて多くの選択肢が提供されます。 自然な選択肢の1つは、各ノードがデータの一部しか保存しないネットワークです。 これが数十年間機能してきたシードネットワークの仕組みです：ネットワーク全体で何百万ものファイルを保存および配布していますが、各参加者は数個のファイルのみを保存および配布しています。 直感に反して、この方法はデータの信頼性をドロップさせる必要がありません。 より経済的なノードの運用を通じて、各ノードがランダムに過去の記録の10％を保存する、10万のノードを持つネットワークを構築することができます。 その結果、各データは10,000回複製されます- 10,000個のノードの複製ファクターと完全に同じ-各ノードがすべての内容を保存するネットワーク。

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

Erasure codesは、ロバスト性を向上させるために使用され、コピー因子を同じままにします。実際、Blobはすでにエラスアーコードを使用しており、データの可用性サンプリングをサポートしています。最も簡単な解決策は、このErasure codesを再利用し、実行およびコンセンサスブロックデータをblobに入れることです。

既存の研究とはどのような関係がありますか？

EIP-4444;

トレントとEIP-4444；

ポータルネットワーク;

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

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

ガス制限（パラダイム）を改善する方法はありますか。

まだ何をすべきか、何を考慮すべきか？

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

主要な考慮事項は、私たちが「古代」の履歴データを提供する方法です。最も簡単な解決策は、明日から古代の履歴の保存をやめ、既存のアーカイブノードとさまざまな中央集権的なプロバイダーに依存することです。これは簡単ですが、ETH坊が永久的な記録場所としての立場を弱めます。より困難ですが安全なアプローチは、まずトレントネットワークを構築し統合することで、分散型で履歴を保存することです。ここで、「私たちがどれだけ努力しているか」には2つの次元があります:

最大のノード集がすべてのデータを確実に保存するようにするために、どのように努力していますか？

プロトコルに統合されたデプスの深さはどれくらいですか？

（1）の極端な偏執的な方法には、ステークプルーフ検証者が一定割合の履歴を保存し、定期的にそれを暗号化してチェックすることが含まれます。より穏やかな方法は、クライアントごとに保存される履歴の割合に自発的な基準を設定することです。

(2)に関しては、基本的な実装では、すでに今日完了している作業に関連しています：Portalは、完全なイーサリアムの履歴を含むERAファイルを保存しています。より徹底的な実装では、これを同期プロセスに接続する必要があります。これにより、他のアーカイブノードがオンラインでない場合でも、完全な履歴のストレージノードまたはアーカイブノードを同期することができます。

それはロードマップの他の部分とどのように対話しますか？

ノードを実行または起動することを非常に簡単にする場合、歴史的なストレージ要件を削減することは状態を持たないことよりも重要だと言えます：ノードに必要な1.1 TBのうち、約300 GBは状態であり、残りの約800 GBはすでに歴史となっています。状態を持たないこととEIP-4444を実現することで、スマートウォッチでETHノードを実行し、数分で設定できるビジョンを実現できます。

限定された履歴の保存は、より新しいETHノードが最新バージョンのプロトコルのみをサポートするため、より実現可能になりました。これにより、2016年のDoS攻撃中に作成された空のストレージスロットはすべて削除されたため、安全に多くのコード行を削除できます。プルーフオブステークが過去のものとなったため、顧客はプルーフオブワークに関連するすべてのコードを安全に削除できます。

状態の有効期限

何を解決するのか？

クライアントの履歴記録の必要性を排除しても、クライアントのストレージ要件は引き続き上昇し続けます。年間約50 GBの状態の上昇により、アカウント残高やランダム数、契約コードや契約ストレージが含まれます。ユーザーは一度の費用支払いにより、現在および将来のETHブロックチェーンクライアントに負担を与え続けることができます。

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

それは何であり、それはどのように動作するのか

今日、新たな状態オブジェクトを作成する際（以下の3つの方法のいずれかによって発生することができます：（i）ETHを新しいアカウントに送信する、（ii）コードを使用して新しいアカウントを作成する、（iii）以前に触れられていないストレージスロットを設定する）、その状態オブジェクトは常にその状態にあります。一方、時間の経過とともにオブジェクトが自動的に期限切れになるようにしたいです。この3つの目標を達成する方法は重要な課題です。

効率：到着プロセスを実行するための追加の計算が必要ありません。

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

開発者フレンドリー：開発者は完全に不慣れな思考モデルに切り替える必要はありません。さらに、現在固定されて更新されないアプリケーションは引き続き正常に動作するはずです。

これらの目標を満たさないと問題を解決するのは容易です。例えば、各状態オブジェクトに有効期限カウンターを格納しておくことができます（ETH を燃やすことで有効期限を延長することができ、これはいつでも読み取りまたは書き込み時に自動的に発生する可能性があります）、そして有効期限が切れた状態を削除するための状態をループで処理するプロセスがあります。しかし、これには追加の計算（さらには記憶要件）が導入され、それは確かにユーザーフレンドリーの要求を満たすことはできません。開発者は時々、値がゼロにリセットされるストレージ値に関与する推論を立てるのが難しいです。契約範囲内で期限タイマーを設定すると、技術的には開発者の生活をより簡単にすることができますが、経済的にはより困難になります：開発者は持続的なストレージコストをユーザーに「転嫁」する方法を考える必要があります。

これらは、イーサリアムのコア開発コミュニティが長年取り組んできた問題、例えば「ブロックチェーンの賃貸」と「再生」などの提案です。最終的に、最善の提案の一部を組み合わせ、2つの「最も悪くない解決策」に集約しました。

*部分的なステータスの有効期限ソリューション

• アドレスサイクルに基づいた状態の期限切れの提案。

部分的な状態の有効期限

一部分のステータスの期限切れ提案は、同じ原則に従います。状態をブロックに分割します。それぞれのブロックには、ブロックが空であるか空でないかを永久に保存する「トップマップ」があります。データは、最近アクセスされた場合にのみブロック内に保存されます。もう保存されていない場合、復活の仕組みがあります。

これらの提案の主な違いは、（i）「最近」をどのように定義するか、および（ii）「ブロック」をどのように定義するかですか？具体的な提案の1つは、EIP-7736であり、これはVerkleツリーに基づいた「ステムリーフ」デザイン（バイナリツリーなどの任意の形式の状態にも互換性があります）を導入します。このデザインでは、隣接するヘッダ、コード、およびストレージスロットが同じ「ステム」の下に格納されます。ステムに格納されるデータの最大サイズは256 * 31 = 7,936バイトです。多くの場合、アカウントの完全なヘッダとコード、および多くのキースロットは同じステムの下に格納されます。ステム内のデータが6か月間読み取られなかったり書き込まれなかった場合、そのデータは保存されず、32バイトのコミットメント（「スタブ」）のみが保存されます。将来、そのデータにアクセスするトランザクションでは、データを「復活」させ、スタブに基づいてチェックを行う証明が必要です。

他の方法で同様の考え方を実現することができます。たとえば、アカウントレベルの粒度が不十分である場合、同様の茎葉メカニズムによって232分の1ずつ木全体を制御するような計画を立てることができます。

インセンティブの影響で、問題はさらに複雑になりました：攻撃者は、大量のデータを単一のサブツリーに配置し、毎年単一の取引を送信することで「ツリーを更新」し、クライアントに大量の状態を永久に保存させることができます。更新コストをツリーのサイズに比例させる（または更新期間に反比例させる）と、他のユーザーを傷つけるために自分と同じサブツリーに大量のデータを配置することで誰かが試みる可能性があります。これらの問題を制限するために、サブツリーのサイズに基づいて粒度を動的にすることができます。たとえば、連続した 216= 65536 個の状態オブジェクトごとに1つの「グループ」と見なすことができます。ただし、これらの考えはより複雑であり、ステムに基づく方法が簡単であり、通常、ステムの下のすべてのデータが同じアプリケーションやユーザーに関連しているため、インセンティブ措置を調整することができます。

アドレス期間に基づくステータス有効期限の推奨事項

完全な永続的な状態の上昇を完全に避けたい場合、例えば32バイトのスタブの場合、どうすればよいですか？復活の競合があるため、これは問題です。状態オブジェクトが削除された場合、後でEVM実行が完全に同じ位置に別の状態オブジェクトを置きますが、後で元の状態オブジェクトに関心がある人が戻ってきて、それを回復しようとした場合、どうすればよいですか？一部の状態が期限切れになると、 'スタブ' は新しいデータの作成を妨げます。状態が完全に期限切れになるにつれて、私たちはストブを保存できなくなります。

アドレス周期に基づいた設計は、この問題を解決するための最も有名なアイデアです。私たちは状態全体を保存するために状態ツリーを使用せず、上昇し続ける状態ツリーリストを持っており、読み取りまたは書き込みされる状態は常に最新の状態ツリーに保存されます。定期的に（例：1年ごとに）新しい空の状態ツリーが追加されます。古いツリーは完全に凍結されます。完全なノードは最新の2つのツリーのみを保存します。状態オブジェクトが2つの周期で触れられない場合、期限切れのツリーに落ちることがありますが、それでも読み取りや書き込みはできますが、トランザクションはそのMerkle証明を提供する必要があります。証明が行われると、そのコピーは再度最新のツリーに保存されます。

ユーザーと開発者の両方にとって友好的な重要な考えの1つは、アドレスサイクルの概念です。アドレスサイクルはアドレスの一部である数字です。重要なルールは、サイクルNのアドレスには、サイクルN期間またはそれ以降（つまり、状態ツリーリストが長さNに達したとき）にのみ読み取りまたは書き込みを行うことができます。新しい状態オブジェクト（たとえば、新しい契約や新しいERC20残高など）を保存する場合、その状態オブジェクトをサイクルNまたはN-1の契約に入れることを確認すれば、すぐに保存できます。証拠なしに以前に何もなかったことを証明する必要はありません。一方、古いアドレスサイクルで行われる追加や編集には証拠が必要です。

この設計は、イーサリアムの現在の多くの特性を維持しながら、追加の計算を必要とせず、ほぼ現在と同じようにアプリケーションを作成できるようにします（ERC20は、アドレスの周期Nでアドレスの残高をサブコントラクトに格納するため、再記述が必要です）。しかし、それには大きな問題があります：アドレスをアドレスの周期に合わせるには、20バイト以上に拡張する必要があります。

アドレス空間拡張

提案は、バージョン番号、アドレスサイクル番号、および拡張ハッシュを含む新しい32バイトのアドレス形式を導入することです。

0x01 (赤)、0000 (オレンジ)、000001 (緑)、57aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF (青)。

赤いのはバージョン番号です。ここにオレンジ色の四つのゼロは、将来的にシャーディング番号を収容できるようにするための空白スペースです。緑色はアドレスサイクル番号です。青色は26バイトのハッシュ値です。

ここでの主要な課題は後方互換性です。既存の契約は、20 バイトのアドレスを中心に設計されており、通常、厳密なバイトパッキング技術が使用されており、アドレスが正確に20バイトであると明示的に想定されています。この問題を解決する1つのアイデアは、変換マッピングを含みます。新しいアドレスとやり取りする古い契約は、新しいアドレスの20バイトのハッシュ値を見ることになります。ただし、その安全性を確保することには非常に多くの複雑さが存在します。

アドレス空間縮小

もう一つの方法は逆の方向を取ることです：一部の2128サイズのアドレス範囲（例えば、0xffffffffで始まるすべてのアドレス）を即座に禁止し、その範囲を使用してアドレスサイクルと14バイトのハッシュ値を持つアドレスを導入します。

0xffffffff000169125d5dFcb7B8C2659029395bdF

この方法によって達成される主な犠牲は、アンインファクトアドレスのセキュリティリスクを導入することです：資産または権限を保有しているアドレスですが、そのコードはまだチェーンに公開されていません。リスクは、誰かが（まだ公開されていない）コードを持つと主張するアドレスを作成することに関わりますが、同じアドレスに有効な別のコードがハッシュされている場合もあります。このような衝突を計算するには、今日、280個のハッシュが必要です；アドレススペースの縮小により、この数字をアクセスしやすい256個のハッシュ値に減らすことができます。

重要なリスクエリア、つまり単一の所有者が持たないウォレットの非現実的なアドレスは、今日では比較的まれですが、私たちが多様なL2世界に進入するにつれて、より一般的になる可能性があります。唯一の解決策は、このリスクを単純に受け入れることですが、問題が発生する可能性のあるすべての一般的なユースケースを特定し、効果的な解決策を提供する必要があります。

既存の研究とはどのような関係がありますか？

初期の提案

• ブロック链清洁； *再生;
• イーサリアムの状態サイズの管理理論；
• 状態のないと期限切れの可能性のあるいくつかのパス；

一部分のステータスの期限が切れた提案

• EIP-7736;

アドレス空间拡張ドキュメント

• オリジナルの提案； *イプシロンレビュー;
• ブログ記事のコメント；
• 衝突耐性を失った場合、何が破壊されるでしょうか。

まだ何をすべきか、何を考慮すべきか？

私は未来に4つの実現可能な道があると考えています:

• 私たちはステートレスであり、ステートの期限切れを導入しません。ステートは継続的に上昇しています（遅いかもしれませんが、数十年後には8 TBを超えるかもしれません）、しかし、相対的に特別なカテゴリのユーザーによってのみ必要です：たとえPoSバリデータでもステートは必要ありません。ステートの一部にアクセスするための機能はリストの生成に含まれますが、これは分散的に行うことができます：各ユーザーは、自分のアカウントを含むステートツリーの一部を維持する責任があります。彼らがトランザクションをブロードキャストするとき、彼らはトランザクションと、検証中にアクセスしたステートオブジェクトのプルーフを添付します（これはEOAおよびERC-4337アカウントに適用されます）。その後、ステートレスバリデータはこれらのプルーフを組み合わせてリスト全体のプルーフを生成できます。
• 私たちは部分的な状態の期限切れを行い、はるかに低いが非ゼロの永続的な状態のサイズの増加率を受け入れます。この結果は、対等なネットワークに関連する過去の期限切れ提案が、各クライアントが低いが固定された割合の履歴データを格納する必要があるが、はるかに低いが非ゼロの永続的な履歴の保存増加率をどのように受け入れるかといえます。
• 私たちはアドレス空間を拡張して状態の期限切れを行います。これには数年のプロセスがかかり、アドレス形式変換方法が有効かつ安全で、既存のアプリケーションも含まれます。
• 私たちはアドレス空間の収縮によって状態の期限切れを実施します。これには数年のプロセスがかかり、すべてのアドレスの競合に関連する安全リスク（クロスチェーンインタラクションの場合を含む）が処理されることを確認します。

重要な点は、アドレス形式に依存した状態の有効期限に関する計画を実施するかどうかに関係なく、最終的にはアドレススペースの拡張と縮小に関する課題を解決する必要があるということです。現在、アドレスの衝突を生成するには約280のハッシュ値が必要であり、資源が非常に豊富な参加者にとってはこの計算負荷は実行可能です：GPUは約227のハッシュ値を実行できるため、1年間で252を計算することができます。したがって、世界中の約230のGPUが約1/4年で衝突を1回計算することができます。また、FPGAやASICなどはこのプロセスをさらに高速化することができます。将来的には、このような攻撃はますます多くの人々に開放されるでしょう。したがって、完全な状態の有効期限を実施する実際のコストは、非常に困難なアドレスの課題を解決する必要があるため、見かけほど高くない可能性があります。

それはロードマップの他の部分とどのように対話しますか？

ステータスの期限切れ処理は、1つのステータスツリーフォーマットから別のステータスツリーフォーマットへの変換を容易にする可能性があります。なぜなら、変換プロセスが必要ないからです：新しいフォーマットで新しいツリーを作成して、古いツリーを変換するためにハードフォークを行うだけです。したがって、ステータスの期限切れは複雑ですが、ロードマップの他の側面を簡素化するメリットがあります。

機能のクリーンアップ

それは何の問題を解決しますか？

安全性、アクセシビリティ、および中立性の信頼性の重要な先決条件の1つは、シンプルさです。プロトコルが美しくてシンプルであれば、エラーが発生する可能性が低くなります。これにより、新しい開発者が任意の部分に参加できる機会が増えます。公平であり、特殊な利益に対抗しやすくなります。残念ながら、プロトコルは任意の社会システムと同様に、時間とともにより複雑になる傾向があります。イーサリアムが複雑性の増加するブラックホールに陥るのを避けたい場合、以下の2つのいずれかを行う必要があります：（i）変更を停止してプロトコルを硬直化させる、（ii）機能を実際に削除し、ドロップ複雑さ。中間道路も可能であり、プロトコルへの変更を少なくし、時間とともに少なくとも少し複雑さを排除することができます。このセクションでは、複雑さを削減または排除する方法について説明します。

それは何ですか、そしてそれはどのように動作しますか？

重大な単一の修正がドロッププロトコルの複雑さを解消することはできません。問題の本質は多くの小さな解決策があるということです。

ほとんど完成している例は、SELFDESTRUCTオペコードを削除し、他の例の処理方法の設計図として使用できます。 SELFDESTRUCTオペコードは、単一ブロック内の無制限の数のストレージスロットを変更できる唯一のオペコードであり、クライアントはDoS攻撃を避けるためにかなり高度な複雑さを実装する必要があります。このオペコードの最初の目的は、自発的な状態の清算を実現し、時間とともに状態のサイズを減らすことができるようにすることでした。実際には、それを最終的に使用する人はほとんどいませんでした。オペコードは弱体化され、Dencunフォークで同じトランザクション内で作成された自己破壊アカウントのみを許可するようになりました。これにより、DoSの問題が解決され、クライアントのコードが大幅に簡素化されます。将来的には、オペコードを完全に削除することが意味を持つかもしれません。

迄今までに確定したプロトコルの簡素化のいくつかの重要な例は次のとおりです。まず、EVM以外の例。これらは比較的非侵入的であり、そのためより短時間でコンセンサスを形成し、実施することが容易です。

RLP → SSZ変換: イーサリアムオブジェクトは元々RLPと呼ばれるエンコーディングを使用してシリアライズされていました。 RLPは型がなく、不必要に複雑でした。現在、ビーコンチェーンではSSZを使用しており、シリアライズだけでなくハッシュもサポートしています。最終的には、RLPを完全に廃止し、すべてのデータ型をSSZ構造に移行することでアップグレードを容易にすることを目指しています。現在のEIPには[1][2]。

古いトランザクションタイプを削除する：現在のトランザクションタイプは多すぎて、その中には削除される可能性のあるものも多いです。完全に削除する代わりに、より穏やかな代替案はアカウントの抽象化機能であり、スマートアカウントはこの機能を通じて古いトランザクションを処理し、検証するコードを含むことができます（望む場合）。

LOG改革：日誌のブルームフィルターとその他の論理の導入により、プロトコルの複雑さが増しましたが、実際にはクライアントで使用されていないため、遅すぎます。これらの機能を削除し、代わりにSNARKなどの近代技術を使用したプロトコル外の分散型ログ読み取りツールに注力することができます。

最終的にビーコンチェーン同期委員会メカニズムを削除します：同期委員会メカニズムは、元々ETH坊のライトクライアントの検証を実現するために導入されました。しかし、これはプロトコルの複雑さを著しく増加させました。最終的には、SNARKを使用してETH坊コンセンサスレイヤーを直接検証することができるようになります。これにより、専用のライトクライアントの検証プロトコルが不要になります。潜在的には、コンセンサスの変更により、ETH坊コンセンサス検証者からのランダムなサブセットの署名の検証を含む、より「ネイティブ」なライトクライアントプロトコルを作成することで、同期委員会をより早く削除することができます。

データ形式の統一：現在、実行状態はMerkle Patriciaツリーに格納され、コンセンサス状態はSSZツリーに格納され、ブロブはKZGコミットメントを介して提出されます。将来的には、ブロックデータに対して単一の統一形式を、および状態に対して単一の統一形式を定義することが意味を持ちます。これらの形式はすべての重要な要件を満たします：（i）状態を持たないクライアントのシンプルな証明、（ii）データのシリアライゼーションとイレイジング符号、（iii）標準化されたデータ構造。

ビーコンチェーン委員会の削除：このメカニズムは、特定のバージョンのシャーディングの実行をサポートするために最初に導入されました。代わりに、私たちは最終的にL2とブロブを使用してシャーディングを行うことにしました。したがって、委員会は不要であり、委員会の削除が進行中です。

混合バイトオーダーを排除する：EVM はビッグエンディアンで、コンセンサス層はリトルエンディアンです。再調整してすべてを一貫した形式にすることは意味があるかもしれません（EVM の変更が困難なため、ビッグエンディアンである可能性があります）。

現在、EVMでのいくつかの例：

Gasのメカニズムの簡略化：現在のGasルールはまだ最適化されておらず、ブロックの検証に必要なリソースの量を明確に制限することができません。その中でも重要な例は、（i）ストレージの読み取り/書き込みコストで、ブロック内の読み取り/書き込み回数を制限するためのものですが、現在はかなり任意的です。および（ii）メモリの埋め込みルールで、現在はEVMの最大メモリ消費を推定するのが難しいです。提案されている修正策には、ステートレスGasコストの変更（ストレージに関連するすべてのコストを単純な式に統一する）およびメモリ価格の提案が含まれています。

プリコンパイルの削除：ETH坊目前拥有的许多プリコンパイル既不必要地复杂、又相对未使用、并且在ほとんど被任何アプリケーション使用的情况下构成了コンセンサス失败の很大一部分。この問題の対処方法は2つあります。(i) プリコンパイルを削除すること、および(ii) 同じロジックを実現するEVMコードに置き換えること（不可避的にもっと高価になります）。このEIP 草案はまずアイデンティティプリコンパイルを削除することを提案しています；後で、RIPEMD160、MODEXP、そしてBLAKEが削除の候補者となることもあります。

ガスの観測可能性を削除：EVMの実行はもはや残りのガスを見ることができなくなります。これは一部のアプリケーション（特にスポンサー取引）を壊すかもしれませんが、将来的にはアップグレードが容易になります（例えば、より高度なガスの多次元バージョンに対して）。EOF仕様はガスを観測不可能にしましたが、プロトコルを単純化するためにはEOFが強制的になる必要があります。

静的解析の改善：現在、EVMのコードは静的解析が困難です、特にジャンプが動的であるためです。これは、EVMの実装を最適化すること（EVMコードを他の言語に事前コンパイルすること）を困難にします。この問題は、動的ジャンプを削除することで解決できます（または、例えば契約内のJUMPDESTのコストがガスに対して線形であるようにすることで、それらをより高価にします）。EOFがそれを行うのですが、プロトコルの簡素化の利益を得るためには、EOFを強制的に実施する必要があります。

既存の研究とはどのような関係がありますか？

*パージの次のステップ。 *自己破壊

• SSZ ベースの EIPS:[1][2]； *ステートレスガスコストの変更。
• 線形メモリでの価格設定；
• コンパイル前の削除；
• ブルームフィルター移除；
• オフチェーンセキュアログの検索に増分検証計算を使用する方法（読み：再帰STARK）;

まだ何をすべきか、何を考慮すべきか？

この種の機能を簡素化する主なバランスは、（i）私たちの簡素化の度合いと速度と（ii）後方互換性です。ETH坊は、アプリケーションを展開し、数年後も動作することを確信できるプラットフォームであるという価値があります。一方で、この理想はあまりにも遠くに行く可能性があり、William Jennings Bryanの言葉を借りれば、「ETH坊を後方互換性の十字架に打ち付ける」ことがあります。もしも全体のETH坊で特定の機能を使用するアプリケーションが2つしかなく、1つのアプリケーションが数年間ユーザーを一人も持たず、もう1つのアプリケーションがほとんど使用されず、合計57ドルの価値しか得ていない場合、その機能を削除し、被害者に57ドルを支払う必要がある場合は、自腹を切るべきです。

より広範な社会問題は、非緊急の後方互換性の破壊的変更を行うための標準化されたパイプラインの作成です。この問題を解決する方法の一つは、既存の前例を調査して拡張することです。パイプラインの概要は以下の通りです:

• 削除機能Xについて話しましょう；
• 分析を行い、アプリケーションに与える X の削除の影響を決定し、結果に応じて、(i) このアイデアを放棄する、(ii) 計画通りに進む、または (iii) X を削除して継続するための「破壊的な影響が最小限に抑えられた」方法を決定する。
• 正式なEIPを策定してXを廃止する。一般的な高度なインフラストラクチャ（プログラミング言語、ウォレットなど）がこれを尊重し、この機能の使用を停止するようにする。；
• 最后，実際にXを削除します； *第1ステップと第4ステップの間には、数年にわたるパイプラインがあり、どのプロジェクトがどのステップにあるかが明確にされている必要があります。この時点で、機能の削除プロセスの活力と速度と、より控えめでプロトコル開発の他の分野により多くのリソースを投入することとのバランスが必要ですが、私たちはまだパレート境界から遠いです。

EOF

EVMに対する主な変更の1つは、EVMオブジェクト形式（EOF）です。 EOFには、ガスの観測性の禁止、コードの観測性（つまり、CODECOPYがない）、静的ジャンプのみが許可されるなど、多くの変更が導入されています。目標は、EVMがより強力な属性を持つ方法でより多くのアップグレードを実行できるようにすることであり、同時に後方互換性を維持することです（EOF以前のEVMは引き続き存在します）。

これによる利点は、新しいEVM機能を追加するための自然なパスが作成され、より堅牢で厳格なEVMへの移行が促進されることです。欠点は、プロトコルの複雑さが著しく増加することであり、古いEVMを最終的に廃止および削除する方法を見つけることができない限り、です。主な問題の1つは、特にEVMの複雑さを完全にドロップする目標の場合、EVMの簡素化提案においてEOFがどのような役割を果たすかです。

それはロードマップの他の部分とどのように対話しますか？

ロードマップのその他の部分には、旧機能を簡素化するための「改善」提案が多数あります。先ほどのいくつかの例を繰り返します:

• 単一スロットの最終性に切り替えることで、委員会のキャンセル、経済の再設計、およびその他のプルーフオブステークに関連する簡略化が可能になります。
• 完全実現アカウントの抽象化により、大量の既存の取引処理ロジックを削除し、すべての EOA が置き換え可能な「デフォルトアカウント EVM コード」に移動できます。
• イーサリアムの状態をバイナリハッシュツリーに移行すると、新しいバージョンのSSZと一致させることができ、すべてのイーサリアムのデータ構造を同じ方法でハッシュ処理することができます。

より積極的な方法：プロトコルの大部分を契約コードに変換する

より積極的なエーテル坊の簡略化戦略は、プロトコルを変更せず、ほとんどの機能をプロトコルから契約コードに移すことです。

最も極端なバージョンは、ETH坊 L1を単なるビーコンチェーンとし、最小限の仮想マシン（例えばRISC-V、Cairo、またはプルーフシステム用にさらに小さなもの）を導入し、他の人が自分自身の集約を作成できるようにすることです。その後、EVMはこれらの集約の最初のものになります。皮肉なことに、これは2019-20年の実行環境提案の結果とまったく同じですが、SNARKにより実際の実装がより実現可能になりました。

より穏やかな方法は、ビーコンチェーンと現在のETHブロックチェーン実行環境との関係を変えずに、EVMをインプレースで交換することです。RISC-V、Cairo、または他のVMを新しい「公式ETHブロックチェーンVM」として選択し、すべてのEVM契約を、新しいVMコードで元のコードロジックを解釈（コンパイルまたは解釈によって）するように強制的に変換できます。理論的には、これはEOFの1つのバージョンとして、「ターゲット仮想マシン」を介してさえ達成できます。