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

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

・履歴データ：過去に行われた取引や作成されたアカウントは、すべてのクライアントによって永久に保存され、新しいクライアントがダウンロードすることでネットワーク全体に完全に同期される必要があります。これにより、時間の経過とともにクライアントの負荷と同期時間が増加し続けるため、チェーンの容量が変わらなくても影響を受けます。

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

イーサリアムが長期的に維持されるためには、これら2つの傾向に強力な抵抗を加える必要があります。時間の経過とともに、複雑さと膨張をドロップさせる必要があります。しかし同時に、ブロックチェーンを偉大にするための重要な特性の1つである持続性を保持する必要があります。あなたはオンチェーンに代替不可能なトークン、トランザクション通話データのラブレター、または100万ドルのスマートコントラクトを置くことができます。それを10年間洞窟に入れておいて、読むことや相互作用することを待っていると出てきて、まだそこにあることに気付きます。DAppsが完全に分散化され、秘密鍵をアップグレードすることなく安心して削除できるようにするために、彼らの依存関係が彼ら自身を破壊する方法でアップグレードされないことを確認する必要があります-特にL1自体。

もし私たちが決意を持って、これら2つの要求のバランスを取り、連続性を維持しながら、不要な複雑さと退化を最小限に抑えるか逆転させることができれば、それは絶対に可能です。生物体はこれを実現することができます。ほとんどの生物体は時間の経過とともに老化しますが、ごくわずかな幸運な者はそうではありません。社会システムでさえも非常に長寿命になることがあります。ETH坊は一部成功しています：プルーフオブワークが消え、SELFDESTRUCTオペコードもほとんど消えました。ビーコンチェーンノードは最大6ヶ月の古いデータを保存しています。ETH坊の長期的な拡張性、技術的な持続可能性、さらにはセキュリティに向けて、より一般的な方法でこの道筋を見つけることができるかどうかは、ETH坊の最終的な挑戦です。

粛清:主な目的。

・ 各ノードが永続的にすべての履歴記録や最終状態を保存する必要性を低減または排除することにより、クライアントのストレージ要件をドロップします。

· 不必要な機能を削除することで、プロトコルの複雑さをドロップします。

目次:

· 履歴の有効期限

· 状態の有効期限

· 機能のクリーンアップ

履歴の有効期限

何を解決するのか？

この記事の執筆時点では、完全に同期されたETH Fangには、実行クライアント用に約1.1TBのディスク容量が必要であり、さらにコンセンサスクライアント用に数百GBのディスク容量が必要です。 その大部分は履歴データであり、過去のブロック、取引、領収書に関するデータであり、そのほとんどは数年前のものです。 つまり、ガスリミットが全く上がらなくても、ノードのサイズは毎年数百ギガバイトずつ増え続けることになります。

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

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

これは、私たちが歴史を保存する方法について多くの選択肢を提供しています。自然な選択肢の一つは、各ノードがデータの一部しか保持しないネットワークです。これが数十年にわたってシードネットワークが機能してきた方法です：ネットワーク全体で何百万ものファイルが保存され、配信されていますが、各参加者はその中のわずかなファイルしか保持および配信しません。直感とは異なり、この方法はデータの堅牢性を必ずしも低下させるわけではありません。ノードをより効率的に稼働させることで、私たちは、各ノードがランダムに10％の履歴を保存する100,000ノードのネットワークを構築することができます。この場合、各データは10,000回複製されます-つまり、10,000ノードの複製係数と完全に同じ-ノードネットワークで、各ノードがすべてのコンテンツを保存します。

今、ETH坊はすべてのノードが永久にすべての歴史を保存するモデルから脱却し始めました。コンセンサスブロック（Proof of Stakeコンセンサスに関連する部分）だけが約6ヶ月保存されます。Blobは約18日保存されます。EIP-4444では、履歴ブロックとレシートに1年の保存期間を導入することを目指しています。長期的な目標は、すべてのノードがすべてのコンテンツを保存する責任を負う統一された期間（おそらく18日程度）を設定し、その後、ETH坊ノードから構成されるピア・ツー・ピアのネットワークを構築し、古いデータを分散型ネットワークに保存することです。

Erasure codesは、耐久性を高めつつ複製ファクターを維持するために使用できます。実際、Blobはデータ可用性サンプリングをサポートするためにすでにイレイサーコードを実行しています。もっとも簡単な解決策はおそらく、このようなイレイサーコードを再利用し、実行およびコンセンサスブロックデータもblobに格納することでしょう。

既存の研究との関連性はありますか？

· EIP-4444;

· トレントとEIP-4444 ；

· ポータルネットワーク；

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

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

・ガス制限（パラダイム）の改善方法は？

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

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

主要なトレードオフは、「古代」の歴史データを提供する方法についてです。最も簡単な解決策は、明日から古代の歴史の保存を停止し、既存のアーカイブノードとさまざまな集中型プロバイダーに依存することです。これは簡単ですが、ETHブロックチェーンが永続的な記録の場所としての地位を弱めます。より困難ですが、より安全なアプローチは、まずトレントネットワークを構築し統合することで、分散型で歴史を保存することです。ここで、「どれほど努力するか」という点には2つの側面があります：

1. 私たちはどのようにして最大のノード集がすべてのデータを確実に保存していることを保証するのですか？

2. 私たちは、歴史的なデータをプロトコル内のデプスに統合しましたか？

（1）に対する極端な偏執的手法は、委託プルーフを含みます：実際には、各プルーフオブステーク検証者に、一定割合の履歴を保存し、定期的にそれらがそうしているかどうかを暗号化して確認することを要求します。より穏やかな方法は、各クライアントに保存されている履歴の割合に対して自発的な基準を設定することです。

（2）について、基本的な実装は、すでに完了している作業に関連しています：Portal は、完全なイーサリアムの歴史を含む ERA ファイルをすでに保存しています。より徹底的な実装では、実際にそれを同期プロセスに接続することに関わります。したがって、完全な歴史記録を保存ノードまたはアーカイブノードと同期したい場合でも、他のアーカイブノードがオンラインに存在しなくても、直接同期を行うことができます。

01928374656574839201

ノードの実行や起動を非常に簡単にするためには、状態の保存要件を削減することが無状態性よりも重要と言えます。ノードに必要な1.1TBのうち、約300GBは状態であり、残りの約800GBは過去のデータとなっています。無状態性とEIP-4444を実現することで、スマートウォッチでETHノードを実行し、数分で設定できるビジョンを実現することができます。

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

ステートの有効期限

何を解決するのか？

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

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

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

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

1. 効率：到期処理に大量の追加計算が必要ありません。

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

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

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

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

· 一部分のステータスの期限切れの解決策

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

部分的な状態の有効期限

一部分のステータスの有効期限切れ提案は同じ原則に従います。私たちはステータスをブロックに分割します。誰もが「トップマップ」を永久に保存し、そのブロックが空であるかどうかを示します。データが最近アクセスされた場合にのみ、各ブロックのデータが保存されます。データが保存されない場合は、「復活」メカニズムがあります。

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

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

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

アドレス周期に基づくステータスの期限切れの提案

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

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

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

この設計は、追加の計算を必要とせず、現在とほぼ同じようにアプリケーションを書くことができるようにし、イーサリアムの多くの特性を保持しています（ERC20は、サブコントラクトにアドレスサイクルNのアドレス残高が保存されるように書き直す必要があり、自体にアドレスサイクルNがあります）、「ユーザーが5年間洞窟に閉じ込められる」問題を解決します。ただし、大きな問題があります：アドレスは、アドレスサイクルに対応するために20バイト以上に拡張する必要があります。

アドレス空間拡張

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

0x01 (赤)、0000 (オレンジ)、000001 (緑)、57 aE408398、dF7、E5、f4552091、A69125、d5dFcb7B8C2659029395bdF (青)。

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

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

アドレス空间收缩

別の方法は逆方向を取ることです：私たちはすぐに0xffffffffで始まるすべての2^128のアドレスのサブレンジを禁止し、その後、アドレスサイクルと14バイトのハッシュ値を持つアドレスを導入します。

0xffffffff000169125 d5dFcb7B8C2659029395bdF

この方法によって生じる主な犠牲は、逆事実アドレスのセキュリティリスクを導入することです：資産や権限を所有するアドレスがありますが、そのコードはまだチェーン上に公開されていません。リスクは、誰かがアドレスを作成し、そのアドレスが（まだ公開されていない）コードを所有していると主張するが、同じアドレスに有効な別のコードがハッシュされている場合に関与します。今日、そのような衝突を計算するには2^80のハッシュが必要です。アドレス空間の収縮により、この数値は2^56のハッシュ値に減少します。

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

既存の研究との関連性はありますか？

初期の提案

ブロックチェーンクリーン；

再生;

イーサリアムの状態サイズ管理理論;

無状態と状態の期限切れのいくつかの可能な経路;

部分的なステータスの期限切れのプロポーザル

EIP-7736;

アドレス空間拡張文書

当初の提案;

イプシロンレビュー;

ブログのコメント；

もしも衝突抵抗力が失われると、何が破壊されるでしょうか。

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

私は将来には4つの可能な道があると考えています。

・私たちは状態を持たず、状態の期限を設けません。状態は着実に上昇しています（ゆっくりとではありますが：数十年後には 8 TB を超えるかもしれませんが、特定のユーザーによってのみ必要とされます：たとえ PoS バリデータでさえ状態は必要ありません）。

一部分の状態にアクセスする機能は、リスト生成を含みますが、この操作を分散的な方法で行うことができます。各ユーザーは、自分のアカウントを含む状態ツリーの一部を維持する責任があります。彼らがトランザクションをブロードキャストするとき、彼らはトランザクションをブロードキャストし、アクセスされた状態オブジェクトの証明を添付します（これはEOAおよびERC-4337アカウントに適用されます）。その後、ステートレスバリデーターはこれらの証明を組み合わせてリスト全体を含む証明を作成できます。

· 私たちは一部のステートが期限切れになり、はるかに低いがゼロでない永続的な状態のサイズの増加率を受け入れます。この結果は、対等ネットワークに関連するように言えます。過去の期限切れの提案は、各クライアントがはるかに低いが固定のパーセンテージの歴史データを保存する必要があるという点で、低いがゼロでない永続的な歴史的な保存の増加率にどのように受け入れられるかを示しています。

・私たちはアドレス空間の拡張によって状態の期限切れを行います。これには数年のプロセスが関与し、アドレスの形式変換方法が有効で安全であり、既存のアプリケーションを含めることを確認します。

· 我々はアドレススペースの収縮によってステートの期限切れを行います。これには数年にわたるプロセスがかかり、アドレスの衝突に関連するすべてのセキュリティリスク（クロスチェーンインタラクションの場合を含む）が処理されることを保証します。

重要なのは、アドレス形式の変更に依存する状態の有効期限切れの計画を実施するかどうかにかかわらず、最終的にはアドレススペースの拡張と収縮に関する問題を解決する必要があるということです。現在、アドレスの衝突を生成するには約2 80のハッシュ値が必要です。非常に豊富なリソースを持つ参加者にとって、このような計算負荷は実行可能です：GPUは約2 27のハッシュ値を実行できるため、1年間で2 52を計算できます。したがって、世界中に約230のGPUが約1/4年で1回衝突を計算できます。そして、FPGAとASICはこのプロセスをさらに加速することができます。将来、この種の攻撃はますます多くの人々に開放されるでしょう。したがって、完全な状態の有効期限切れを実装する実際のコストは、見かけ以上に高くないかもしれません。というのも、非常に挑戦的なアドレスの問題を解決する必要があるからです。

01928374656574839201

状態の期限切れは、1つの状態ツリー形式から別の状態ツリー形式への変換を容易にする可能性があります。なぜなら、変換プロセスが不要だからです。新しい形式で新しいツリーを作成し、古いツリーを変換するためにハードフォークを行うだけで済みます。したがって、状態の期限切れは複雑ですが、他の側面のロードマップを単純化することに役立ちます。

機能のクリーンアップ

それはどんな問題を解決しますか？

安全性、アクセシビリティ、および信頼性の中心的な先決条件の1つは、シンプルさです。プロトコルが見栄えよく、シンプルであれば、エラーが発生する可能性が低くなります。それによって新しい開発者がどの部分でも参加できる機会が増えます。それは公正であり、特定の利益に対抗しやすくなります。残念ながら、プロトコルはどんな社会システムも同様に、時間の経過とともにより複雑になる傾向があります。イーサリアムが複雑性の増加に飲み込まれないようにしたい場合、以下の2つのことのいずれかを行う必要があります：（i）変更を停止し、プロトコルを硬直化させる、（ii）実際に機能を削除し、ドロップする複雑さ。また、プロトコルへの変更を最小限に抑え、時間の経過とともに少なくとも少し複雑さを取り除くことも可能です。本節では、複雑さを減らすか、または取り除く方法について議論します。

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

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

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

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

・RLP→SSZ変換：最初、イーサリアムオブジェクトはRLPと呼ばれるエンコーディングを使用してシリアライゼーションされていました。RLPは無型であり、不必要に複雑です。現在、ビーコンチェーンではSSZが使用されており、シリアライゼーションだけでなくハッシュもサポートしているため、多くの面で明らかに優れています。最終的には、RLPを完全に廃止し、すべてのデータタイプをSSZ構造に移行することで、アップグレードをより容易にすることが期待されています。現在のEIPには[1][2][3]が含まれています。

· 旧し取引タイプを削除する：現在の取引タイプは多すぎて、そのうち多くは削除される可能性があります。完全に削除する代わりに、より穏やかな代替案は、アカウントの抽象化機能です。スマートアカウントは、この機能を使用して、古い取引を処理および検証できます（希望すれば）。

・LOG改革：ログ作成ブルームフィルターとその他のロジックを追加し、プロトコルの複雑さを増しましたが、実際にはクライアントで使用されていません。遅すぎるため、これらの機能を削除し、SNARKなどの現代技術を使用したプロトコル外の分散型ログ読み取りツールに取り組むことができます。

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

・データ形式の統一：現在、実行状態はMerkle Patricia Treeに格納され、コンセンサス状態はSSZ Treeに格納され、ブロブはKZGコミットメントを介して提出されます。将来的には、ブロックデータに対して単一の統一形式を、状態に対して単一の統一形式を規定することが意味があります。これらの形式は、すべての重要な要件を満たします：（i）ステートレスクライアントの単純な証明、（ii）データのシリアライズとイレイズコーディング、（iii）標準化されたデータ構造。

· 削除ビーコンチェーン委員会：このメカニズムは元々特定バージョンの実行シャーディングをサポートするために導入されました。代わりに、我々は最終的に L2 と blob を使用してシャーディングします。したがって、委員会は不要であり、そのため委員会の削除措置が採られています。

・混合バイトオーダーを削除します：EVM はビッグエンディアンであり、コンセンサス層はリトルエンディアンです。調整し、すべての内容が一方または他方になるようにすることは意味があります（EVM は変更が難しいため、ビッグエンディアンかもしれません）

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

・Gas 机制の簡略化：現行のGas規則はまだ十分に最適化されておらず、ブロックの検証に必要なリソース量に明確な制限を与えることができません。この点の重要な例は（i）ストレージの読み書きコストであり、ブロック内の読み書き回数を制限することを目的としていますが、現在はかなり任意的です。また、（ii）メモリの充填ルールであり、現在、EVMの最大メモリ消費を見積もるのが非常に難しい状況です。提案されている修正策には、ステートレスGasコストの変更（ストレージに関連するすべてのコストを単純な式に統一する）およびメモリ価格提案が含まれます。

· 削除予約済みコンパイル：ETH坊は現在、不要に複雑でほとんど使用されていない多くの予約済みコンパイルを持っており、コンセンサスの失敗の大きな要因となっています。この問題を解決するための2つの方法は、(i) 予約済みコンパイルを削除すること、および(ii) 同じロジックを実現する（より高価な）EVMコードに置き換えることです。このEIPドラフトでは、最初のステップとしてアイデンティティ予約済みコンパイルをこの操作に従うことを提案しています。後日、RIPEMD 160、MODEXP、およびBLAKEも削除の候補となるかもしれません。

・ ガスの除去観測性：EVMの実行から残存ガスが見えなくなります。これにより一部のアプリケーション（特にスポンサード取引）が破損しますが、将来的にはアップグレードが容易になります（例えば、より高度なガスの多次元バージョンのため）。EOF仕様によりガスが観測不能となりましたが、プロトコルを簡素化するためにEOFが強制される必要があります。

・静的解析の改善：現在、EVMコードの静的解析は非常に困難であり、特にジャンプが動的であるためです。これにより、EVMの実装を最適化することがより困難になります（EVMコードを他の言語に事前コンパイルする）。この問題を解決するために、動的なジャンプを削除することができます（または、それらをより高価にすることができます。例：ジャンプデスティネーションのガスコストは線形になります）。これがEOFの役割であり、EOFを強制的に実行することでプロトコルの簡素化の利点を得ることができます。

既存の研究との関連性はありますか？

· クリーンアップの後続手順;

· 自爆

· SSZ ベースの EIPS: [ 1 ] [ 2 ] [ 3 ];

· ステートレスガスコストの変更。

· リニアメモリプライシング；

· コンパイル前の削除；

· ブルームフィルター削除；

・増分検証可能な計算を使用して、オフチェーンのセキュリティログ検索を行う方法（読み：再帰的STARK）；

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

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

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

1. 削除機能 X について話し始めます；

2. 分析を行い、アプリケーションへの影響を特定し、以下の結果に基づいて決定します：(i) この考えを放棄する、(ii) 予定通り続行する、または(iii) X を削除し続けるための「最小限の破壊」の方法を特定する。

3. Xを廃止するための公式なEIPを策定します。より高度なインフラストラクチャ（プログラミング言語、ウォレットなど）がこれを尊重し、その機能の使用を停止することを確認します。

4. 最后、X を実際に削除します；

第1ステップと第4ステップの間には、長年にわたるパイプラインが必要であり、どのプロジェクトがどのステップにあるかを明確に示す必要があります。この時点で、特に特徴の削除プロセスの活力と速度と、より保守的でプロトコル開発により多くのリソースを投入する他の領域とのバランスを取る必要がありますが、私たちはまだパレート最適ではありません。

EOF

EVMに提案された主な変更の1つはEVM Object Format（EOF）です。EOFは、ガスの観測性、コードの観測性（つまり、CODECOPYを禁止）を含む多くの変更を導入し、静的ジャンプのみを許可します。目標は、EVMがより強力な属性を持つ方法でさらに多くのアップグレードを行うことを可能にする一方で、後方互換性を維持することです（EOF以前のEVMも引き続き存在するため）。

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

01928374656574839201

ロードマップの他の部分には、多くの「改善」提案があり、古い機能を単純化する機会でもあります。上記のいくつかの例を繰り返すと：

・シングルスロットファイナリティに切り替えることで、委員会をキャンセルしたり、経済学を再設計したり、その他のプルーフオブステークに関連する簡素化を行う機会が与えられます。

· 完全にアカウントの抽象化を実現することで、大量の既存のトランザクション処理ロジックを削除し、それをすべてのEOAが置き換え可能な「デフォルトアカウントEVMコード」に移動することができます。

・ イーサリアムの状態をバイナリーハッシュツリーに移行すると、すべてのイーサリアムデータ構造を同じ方法でハッシュ処理できるようになり、新しいバージョンのSSZと調和することができます。

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

より積極的なETH坊の簡略化戦略は、プロトコルを変更せず、その大部分をプロトコル機能から契約コードに移すことです。

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

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

原文リンク