Vitalik：Ethereum Protocolの可能性のある未来 – パージ

著者：イーサリアムの創設者であるVitalik

注：この記事は、最近Ethereumの創設者であるVitalikが発行した一連の記事の5番目の部分です。イーサリアムプロトコルの可能性のある先物、パート5：パージ」、4番目の部分を参照してください」Vitalik：イーサリアムの寸前“。 見る “Vitalik：scourge段階の重要な目的」、2番目の部分を参照してください」vitalik：イーサリアムプロトコルはサージ段階でどのように発展するべきですか」、最初の部分を参照してください」Ethereum Posで他に何を改善できるか」。

---

イーサリアムが直面している課題の1つは、デフォルトでは、ブロックチェーンプロトコルの膨満感と複雑さが時間とともに増加することです。これは2つの方法で発生します。

• 履歴データ：歴史的な瞬間に作成されたトランザクションおよびアカウントは、すべてのクライアントによって永続的に保存され、ネットワークと完全に同期されている新しいクライアントによってダウンロードされる必要があります。これにより、チェーンの容量が同じままであっても、クライアントの負荷と同期時間が時間とともに増加します。

• プロトコル関数：新しい機能を追加することは、古い機能を削除するよりもはるかに簡単であり、その結果、コードの複雑さが時間とともに増加します。

Ethereumが長期にわたって持続するためには、両方の傾向に強化された逆圧を置き、時間の経過とともに複雑さと膨満感を減らす必要があります。しかし同時に、iブロックチェーンの重要な属性の1つである持続性を保持する必要があります。NFT、トランザクションコールデータにラブレター、またはチェーンに100万ドルを含むスマートコントラクトを入れて、10年間洞窟に入ることができます。DAPPが完全に分散化され、自信を持ってアップグレードキーを削除するためには、依存関係がそれらを破る方法で、特にL1自体を壊す方法でアップグレードされないことを確認する必要があります。

パージ、2023ロードマップ。

これら2つのニーズに焦点を合わせてバランスをとると、継続性を維持しながら拡大、複雑さ、不況を最小限に抑えるか逆転させることが絶対に可能です。生物はこれを行うことができます：ほとんどの生物は時間の経過とともに老化していますが、幸運なことに、少数の生物は加齢ではありません。社会システムでさえ、非常に長い寿命を持つことができます。場合によっては、Ethereumが成功しました。作業の証明が消え、SelfDestruct Opcodeが基本的に消え、ビーコンチェーンノードは最大6か月間古いデータを保存しています。より一般的な方法でイーサリアムのこの道を見つけることと、長期的な安定した最終結果への移行は、イーサリアムの長期的なスケーラビリティ、技術の持続可能性、さらにはセキュリティの究極の課題です。

パージ：主な目的

• 各ノードがすべての履歴を永続的に保存する必要性を削減または排除することにより、クライアントのストレージ要件を削減し、それを最終決定することもできます

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

履歴データが期限切れになりました

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

この執筆時点では、完全に同期したイーサリアムノードには、クライアントを実行するために約1.1 TBのディスクスペースが必要であり、コンセンサスクライアントに使用される数百GBのスペースが必要です。それらのほとんどは履歴データです。履歴ブロック、トランザクション、領収書に関するデータ、そのほとんどは何年も前のものです。これは、たとえガス制限がまったく増加しなくても、ノードのサイズが年間数百GB増加することを意味します。

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

歴史的ストレージの問題の重要な単純化された機能は、各ブロックがハッシュリンク（および他の構造）を介して前のブロックを指しているため、現在のコンセンサスが歴史に関するコンセンサスに到達するのに十分であることです。ネットワークが最新のブロックで一致する限り、履歴ブロック、トランザクションまたはステータス（アカウント残高、乱数、コード、ストレージ）は、単一の参加者がMerkle Proofを提供することができ、証明により他の誰もがそれを確認できるようにします。正しいセックスです。コンセンサスはN/2-of-Nトラストモデルですが、履歴は1-of-Nトラストモデルです。

これにより、履歴の保存方法に関する多くのオプションが開かれます。自然な選択とは、各ノードがデータのごく一部しか保存しないネットワークです。これは、Torrentネットワークが何十年も機能してきた方法です。ネットワークは何百万ものファイルを合計で保存および配布していますが、各参加者はそれらのいくつかのみを保存して配布します。おそらく直感的に、このアプローチはデータの堅牢性を減らすことさえできないかもしれません。各ノードが履歴の10％をランダムに保存するノード操作のコストを削減することにより、100,000ノードのネットワークを実装できる場合、各データは10,000回コピーされます。各ノードネットワークはまったく同じです。

今日、Ethereumはすべてのノードがすべての履歴を永久に保存するモデルを取り除き始めました。コンセンサスブロック（つまり、ステークコンセンサスの証明に関連する部分）は、約6か月間しか保存されません。ブロブは約18日間しか保管されていません。EIP-4444は、過去のブロックと領収書に1年間の保管期間を導入するように設計されています。長期的な目標は、各ノードがすべてを保存する責任を負う調整された期間（おそらく約18日）を持つことです。その後、古いデータを分散方法で保存するイーサリアムノードのピアツーピアネットワークがあります。 。

コードを消去することは、複製係数を変更せずに堅牢性を向上させるために使用できます。実際、データの可用性サンプリングをサポートするために、ブロブは消去コードを採用しています。最も簡単な解決策は、この消去コードを再利用し、実行とコンセンサスのブロックデータをBLOBに入れることです。

どのような研究が利用可能ですか？

EIP-4444：https://eips.ethereum.org/eips/eip-4444

急流とEIP-4444：https://ethresear.ch/t/torrents-and-eip-4444/19788

ポータルネットワーク：https://ethereum.org/en/developers/docs/networking-layer/portal-network/

ポータルネットワークとEIP-4444：https://github.com/ethereum/portal-network-pecs/issues/308

ポータル内のSSZオブジェクトの分散ストレージと検索：https://ethresear.ch/t/distributed-storage-and-cryptographically-secured-retrieval-of-ssz-objects-for-portal-network/19575

ガス制限を増やす方法（パラメーター）：https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2

残りは何ですか、そしてどのようなトレードオフがありますか？

残りの主な作業には、履歴履歴を保存するための具体的な分散ソリューションを構築および統合することが含まれますが、最終的にはコンセンサスとブロブも含まれます。最も簡単な解決策は、（i）既存のトレントライブラリを単に導入することと、（ii）ポータルネットワークと呼ばれるイーサリアムネイティブソリューションです。これらのいずれかが導入されたら、EIP-4444を有効にすることができます。EIP-4444自体はハードフォークを必要としませんが、ネットワークプロトコルの新しいバージョンが必要です。そのため、すべてのクライアントに同時に有効にすることは価値があります。そうしないと、完全な履歴をダウンロードするが実際には実装されていない他のノードに接続するためにクライアントが失敗する可能性があるためです。

主なトレードオフには、「以前の」履歴データを利用できるようにするための取り組みが含まれます。最も簡単な解決策は、明日以前のデータの保存を停止し、既存のアーカイブノードとさまざまな集中プロバイダーに頼ることです。これは簡単ですが、永続的なデータの記録としてのイーサリアムの立場を弱めます。より難しいがより安全なアプローチは、最初に急流ネットワークを構築および統合して、分散した方法で履歴を保存することです。ここに2つの次元があります：

• すべてのデータを保存するノードの最大数を保証するために、どの程度の労力が必要ですか？

• 履歴ストレージをプロトコルとどの程度統合しますか？

（1）の場合、最も厳格なアプローチには監護証明が含まれます。実際、歴史の一定の割合を保存し、暗号化を通じてそうするかどうかを定期的に確認するには、それぞれのステーク検証者が必要です。より控えめなアプローチは、クライアントごとに保存されている履歴の割合に対して自発的な基準を設定することです。

（2）の場合、基本的な実装には、今日の行われたことのみが含まれます。ポータルは、イーサリアム履歴全体を含むERAファイルを保存しています。より徹底的な実装では、実際にそれを同期プロセスに接続することで、誰かが完全な履歴ストレージノードまたはアーカイブノードを同期したい場合、他のアーカイブノードがオンラインでなくても、ポータルネットワークから直接同期することでこれを行うことができます。

ロードマップの残りの部分とどのように相互作用しますか？

ノードを実行または非常にシンプルに開始する場合、履歴ストレージ要件を削減することは、間違いなくステートレスよりも重要です。ノードで必要な1.1 TBのうち、約300 GBが状態であり、残りの約800 GBは履歴です。StatelessとEIP-4444が同時に達成された場合にのみ、スマートウォッチと設定で実行されているEthereumノードのビジョンがわずか数分で達成されます。

また、履歴ストレージを制限することにより、最新のバージョンのプロトコルのみをサポートするために、新しいEthereumノードの実装がより実現可能になり、それらをより簡単にします。たとえば、2016年のDOS攻撃中に作成されたすべての空のストレージスロットが削除されているため、多くのコード行を安全に削除できます。ステークの証明に切り替えることが履歴であるため、クライアントは作業証明に関連するすべてのコードを安全に削除できます。

ステータスデータの有効期限が切れました

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

クライアントストレージ履歴の必要性を排除したとしても、クライアントのストレージ需要は、アカウントの残高と乱数、契約コード、契約ストレージなど、州が成長し続けるにつれて、年間約50 GBの成長を続けます。ユーザーは1回限りの料金を支払うことができます。これにより、常に現在および将来のイーサリアムクライアントに負担がかかります。

EVMの基本的な設計の仮定は、状態オブジェクトが作成されると永久に存在し、いつでも取引によって読むことができるということであるため、州は歴史よりも「満足」するのが難しいです。ステートレスを導入すると、この問題はそれほど悪くないかもしれないと考える人もいます。特殊なブロックビルダーのクラスのみが状態の実際の保存を必要とし、他のすべてのノード（リスト生成を含む！も）がステートレスに実行できます。しかし、一部の人々は、私たちが無国籍にあまり頼りたくないと考えており、最終的にはイーサリアムを分散化するために国家が期限切れになることを望むかもしれません。

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

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

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

• ユーザーフレンドリー：誰かが洞窟に5年戻ってきた場合、彼らはETH、ERC20、NFT、CDPの位置へのアクセスを失うべきではありません…

• 開発者の親しみやすさ：開発者は、まったく馴染みのない思考モデルに切り替える必要はありません。さらに、現在硬くて非可用になっているアプリケーションは、合理的に実行され続ける必要があります。

これらの目標を達成することなく、問題は簡単に解決できます。たとえば、各状態オブジェクトにカウンターを保存して有効期限を記録することもできます（読み取りまたは書き込み時に自動的に発生するETHを破壊することで拡張できます）。オブジェクトのプロセス。ただし、これは追加の計算（ストレージ要件さえ）を導入し、ユーザーフレンドリーな要件を確実に満たしていません。また、開発者が保存された値を含む極端なケースをゼロにリセットすることを推論することも困難です。契約範囲内で有効期限タイマーを設定すると、これにより技術的に開発者の作業が容易になりますが、エコノミーをより困難にします。開発者は、継続的なストレージコストをユーザーに「渡す」方法を検討する必要があります。

これらは、「ブロックチェーンレンタル」や「再生」などの提案を含む、イーサリアムコア開発コミュニティが長年にわたって解決するために一生懸命働いてきた問題です。最終的に、提案の最良の部分を組み合わせて、「既知の最も悪い解決策」の2つのカテゴリに焦点を当てます。

• いくつかの州の満了ソリューション。

• アドレスサイクルに基づく状態の満了提案。

いくつかのステータスが期限切れになりました

一部の州の満了提案は、同じ原則に従います。状態をチャンクに分けます。誰もが「トップレベルのマップ」を永久に保存し、どのブロックが空または空でないかを保存します。各ブロックのデータは、最近訪問された場合にのみ保存されます。ブロックが保存されなくなった場合、誰でもそれが何であるかを証明することでそのデータを回復できる「復活」メカニズムがあります。

これらの提案の主な違いは次のとおりです。（i）「最近」をどのように定義するのか、（ii）「ブロック」をどのように定義するのか？特定の提案はEIP-7736で、Verkle Treesに導入された「ステムアンドリーフ」デザインに基づいています（バイナリツリーなどのあらゆる形態の無駄な木と互換性があります）。この設計では、互いに隣接するヘッダー、コード、ストレージスロットが同じ「ステム」の下に保存されます。STEMの下に保存されているデータは、最大256 * 31 = 7,936バイトです。多くの場合、アカウントのタイトルとコード全体、および多くのキーストレージスロットが同じバックボーンの下に保存されます。特定のバックボーンの下のデータが6か月以内に読み取られたり書かれたりしない場合、データは保存されなくなりますが、データへの32バイトのコミットメントのみ（「スタブ」）です。このデータにアクセスする将来のトランザクションでは、データを「復活」する必要があり、スタブで確認の証明を提供します。

同様のアイデアを実装する他の方法があります。たとえば、アカウント間隔で十分でない場合、ツリーの各1/232部分が同様のステムと葉のメカニズムによって制御される計画を作成できます。

これは、動機付けの要因のためにさらにトリッキーです。攻撃者は、大量のデータを単一のサブツリーに入れ、毎年単一のトランザクションを送信し、クライアントに大量の状態を永久に保存することを強制することで「ツリーを更新する」ことができます。更新のコストをツリーのサイズに比例させる場合（または更新期間はツリーサイズに反比例します）、誰かが他のユーザーを傷つける可能性があります。サブツリーのサイズに基づいてアカウント間隔を動的に調節することにより、これら2つの問題を制限することを試みることができます。たとえば、連続した2^16 = 65536状態オブジェクトは「グループ」として扱うことができます。ただし、これらのアイデアはより複雑であり、通常、STEMのすべてのデータが同じアプリケーションまたはユーザーに関連するため、インセンティブを調整できます。

アドレスサイクルに基づく状態の満了提案

32バイトのスタブでさえ、永続的な状態の成長を完全に避けたい場合はどうなりますか？パズルは次のとおりです。状態オブジェクトが削除され、後でEVM実行が別の状態オブジェクトをまったく同じ位置に配置した場合はどうなりますか？一部の状態の満了では、スタブは新しいデータの作成を防ぎます。完全なステータスの有効期限のために、スタブを保存することさえできません。

アドレスサイクルベースの設計は、この問題を解決するための最良の方法です。州全体を州の木で保存する代わりに、州の木のリストが増えており、読み書きのある状態が最新の状態の木に保存されています。サイクルごとに新しい空の状態ツリーを追加します（1年と考えてください）。古い州の木が固定されています。完全なノードは、最も近い2つのツリーを保存するだけで済みます。状態オブジェクトが2つのサイクル内で触れず、したがって期限切れのツリーに分類されている場合でも、読み書きができますが、トランザクションはそれをメルクルの証明を証明する必要があります – 完了したら、コピーは最新のツリーミドルに再び保存されます。

これをすべてユーザーと開発者に優しいものにする重要なアイデアは、アドレスサイクルの概念です。アドレスサイクルは、アドレスの一部である数字です。重要なルールは、アドレス期間nのアドレスは、期間nまたは後に読み取ることができないことです（つまり、ステータスツリーリストが長さnに達する場合）。新しい状態オブジェクト（たとえば、新しい契約や新しいERC20バランスなど）を保存する場合、NまたはN-1の住所期間と状態オブジェクトを契約に入れるようにする場合は、保存できますすぐにそれを提供することなく、以前は何も提供しませんでした。一方、古いアドレスサイクルでの状態の追加または編集には、証明が必要です。

この設計は、非常に少ない追加計算でイーサリアムの現在のプロパティのほとんどを保持しているため、アプリケーションを現在と同じように記述できるようにします（ERC20を書き直す必要があります。期間n）そして、「ユーザーが5年間洞窟に入る」という問題を解決しました。ただし、大きな問題があります。アドレスは、アドレスサイクルに適合するために20バイト以上に拡張する必要があります。

住所スペース拡張

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

0x01000000000157AE408398DF7E5F4552091A69125D5DFCB7B8C2659029395BDF

赤はバージョン番号です。ここでは、4つのオレンジ色のゼロが空白を表しており、将来のシャード数に対応できます。緑はアドレス期間番号です。青は26バイトのハッシュです。

ここでの重要な課題は、後方互換性です。既存の契約は20バイトのアドレスを約20バイトで設計されており、しばしばタイトなバイトパッケージング手法で使用されているため、アドレスがちょうど20バイトの長さであることが明らかになります。この問題を解決するための1つのアイデアは、新しいスタイルのアドレスと対話する古いスタイルの契約が新しいスタイルのアドレスの20バイトのハッシュが表示される変換グラフを使用することです。ただし、安全性を確保するにはかなりの努力が必要です。

空間の収縮に対処します

その他の方法：サイズ2128のアドレスサブレンジ（0xffffffffffから始まるすべてのアドレスなど）の一部のアドレスサブレングをすぐに無効にし、その範囲を使用して、アドレス期間と14バイトハッシュのアドレスを導入します。

0xffffffff000169125D5DFCB7B8C2659029395BDF

このアプローチの重要な犠牲は、反事実的アドレスにセキュリティリスクを導入することです：資産または許可を保持しているが、コードがチェーンに公開されていないアドレス。リスクには、（まだ公開されていない）コードがあると主張するアドレスを作成する人が含まれますが、ハッシュ値が同じアドレスを指す別の有効なコードがあります。今日の衝突を計算するには、280のハッシュが必要です。

単一の所有者が保持している財布の反事実的アドレスではなく、重大なリスク領域は、今日では比較的まれな状況ですが、Multi-L2の世界に入ると、この状況がより一般的になる可能性があります。唯一の解決策は、このリスクを単純に受け入れることですが、問題が発生し、効果的なソリューションを考え出す可能性のあるすべての一般的なユースケースを特定することです。

どのような研究が利用可能ですか？

初期の提案

ブロックチェーンレンタル料金：https://github.com/ethereum/eips/issues/35

再生：https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-the-burden-of-large-blockchain-and-tate/7582

イーサリアム州の規模管理理論：https://hackmd.io/@vbuterin/state_size_management

ステートレスおよび状態の有効期限のためのいくつかの可能なパス：https://hackmd.io/@vbuterin/state_expiry_paths

いくつかのステータス有効期限の提案

EIP-7736：https://eips.ethereum.org/eips/eip-7736

拡張されたドキュメントをアドレスします

元の提案：https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bites/5485

イプシロンのコメント：https://notes.ethereum.org/@ipsilon/address-pace-extension-exploration

ブログ投稿のコメント：https://medium.com/@chaisomsri96/statelessness-series-part2-ase-address-pace-extion-60626544b8e6

衝突に対する抵抗を失うとどうなりますか：https://ethresear.ch/t/whatwould-break-if if we-lose-address-collision-resistant/11356

他に何が残されていますか？何を計量しますか？

将来、4つの実行可能なパスがあると思います。

• 私たちは無国籍を練習し、州の満了を導入することはありません。状態は成長しています（遅くなりますが、数十年で8 TB以上は表示されない場合があります）が、比較的プロフェッショナルなユーザーカテゴリが保持するだけです。POSバリデーターでさえ状態を必要としません。

  部分状態へのアクセスが必要な機能の1つは、リスト生成を含めることですが、分散型の方法でこれを実装してください。各ユーザーは、独自のアカウントを含むステータスツリーパーツを維持する責任があります。トランザクションをブロードキャストすると、検証ステップ中にアクセスされたステータスオブジェクトの証明をブロードキャストします（これはEOAおよびERC-4337アカウントに適用されます）。Stateless Balidatorは、これらの証明をリストを含む全体の証明に組み合わせることができます。

• 部分的な状態の有効期限を実装し、はるかに低いがゼロの永続的な状態サイズの成長率を受け入れます。この結果は、ピアツーピアネットワークを含む歴史的な有効期限の提案に似ている可能性があります。ピアツーピアネットワークは、各クライアントが履歴データの低いが固定された割合を保存する必要があるが、はるかに低いがゼロではないという恒久的な履歴ストレージ成長率を受け入れます。

• 有効期限を宣言し、アドレス空間を拡張します。これには、既存のアプリケーションを含むアドレス形式の変換方法が効果的かつ安全であることを保証するための複数年のプロセスが含まれます。

• 有効期限を宣言し、アドレス空間を縮小しました。これには、クロスチェーンの状況を含む住所の競合に関連するすべてのセキュリティリスクが処理されるようにするための複数年のプロセスが含まれます。

重要なポイントは、アドレス形式の変更に依存する状態の有効期限スキームが実装されているかどうかにかかわらず、アドレス空間拡張と収縮の問題を最終的に解決する必要があるということです。今日、アドレス競合を生成するために約2^80のハッシュが必要であり、この計算負荷は非常にリソースが豊富な参加者にとってすでに実現可能です。GPUは約2^27のハッシュを実行できます計算されるため、世界の約2^30 GPUは、年間約1/4で競合を計算でき、FPGAとASICはこのプロセスをさらに高速化できます。将来的には、そのような攻撃はますます多くの人々に開かれます。したがって、とにかくこの非常に挑戦的なアドレスの問題を解決する必要があるため、完全な状態の有効期限を実装する実際のコストは、見た目ほど高くないかもしれません。

ロードマップの残りの部分とどのように相互作用しますか？

状態の有効期限の実行は、変換プロセスが必要ないため、ある状態ツリー形式から別の状態の形式への変換を簡単にする可能性があります。新しい形式で新しいツリーを作成し始めてから、後でフォークを強化して古いツリーを変換できます。したがって、状態の満了は複雑ですが、ロードマップの他の側面を簡素化するのに役立ちます。

機能的なクリーニング

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

セキュリティ、アクセシビリティ、信頼性の重要な前提条件の1つは、シンプルさです。プロトコルが美しくてシンプルな場合、エラーの可能性が低下します。新しい開発者が参加してその一部を使用できる可能性が高くなります。公正である可能性が高く、特別な利益に抵抗する可能性が高くなります。残念ながら、プロトコルは、あらゆる社会システムと同様に、時間とともにデフォルトでより複雑になります。イーサリアムをますます複雑なブラックホールに入れたくない場合は、2つのことのいずれかを実行する必要があります。（i）変更を停止し、プロトコルの剛性を削減すると、（ii）機能を実際に削除し、複雑さを減らすことができます。中間ルート、つまり、プロトコルへの変更が少なくなり、少なくとも少しの複雑さを排除することも可能です。このセクションでは、複雑さを軽減または排除する方法について説明します。

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

プロトコルの複雑さを減らす大きな単一の修正はありません。

他の問題に対処する方法の青写真として、つまりSelfDestruct OpCodeを削除する方法の青写真として使用できる基本的に行われた例。SelfDestruct Opcodeは、単一のブロック内で無制限の数のストレージスロットを変更できる唯一のオペコードであり、DOS攻撃を回避するためにクライアントからの複雑さが必要です。このオペコードの本来の目的は、自発的な状態の清算を達成し、時間の経過とともに状態のサイズが減少することです。実際、それを使用する人はほとんどいません。このオペコードは弱体化しており、Dencunハードフォークで同じトランザクションで作成された自己破壊アカウントのみが可能になります。これにより、DOSの問題が解決され、クライアントコードの大幅な簡素化が可能になります。将来的には、最終的にオペコードを完全に削除することは理にかなっているかもしれません。

これまで特定されたプロトコルの単純化の機会のいくつかの重要な例には、以下が含まれます。まず、EVM以外の例は比較的非侵襲的であるため、コンセンサスに到達し、短時間で実装しやすくなります。

• RLP→SSZ変換：当初、Ethereumオブジェクトは、RLPと呼ばれるエンコードを使用してシリアル化されました。今日、ビーコンチェーンはSSZを使用しています。SSZは、シリアル化だけでなくハッシュもサポートするなど、多くの点で大幅に優れています。最終的には、RLPを完全に削除し、すべてのデータ型をSSZ構造に移動し、その結果、アップグレードを容易にしたいと考えています。現在提案されているEIPには、[1] [2] [3]が含まれます。

• 古いトランザクションタイプを削除します：今日、トランザクションにはあまりにも多くの種類があり、それらの多くが削除される可能性があります。完全に削除するより控えめな代替手段は、アカウントの抽象化機能です。スマートアカウントには、レガシートランザクションを処理および検証するためのコードを含めることができます（必要に応じて）。

• ログ改革：ログはブルームフィルターやその他のロジックを作成し、プロトコルに複雑さを追加しますが、遅すぎるため、クライアントは実際には使用しません。これらの機能を削除し、代わりに、Snarkなどの最新のテクノロジーを使用して、プロトコル外の分散型ログリーディングツールなど、代替案にエネルギーを捧げることができます。

• 最後に、ビーコンチェーン同期委員会のメカニズムがキャンセルされます。同期委員会のメカニズムは、元々、イーサリアムの軽いクライアント認証を可能にするために導入されました。ただし、プロトコルの複雑さを追加します。最終的に、Snarkを使用して、Ethereum Consensus Layerを直接検証することができます。これにより、専用のライトクライアント検証プロトコルの必要性が排除されます。Ethereum Consensus Validatorのランダムサブセットから署名を検証することを含む、より「ネイティブ」な照明クライアントプロトコルを作成します。

• データ形式の調整：今日、実行状態はMerkle Patricia Treeに保存され、コンセンサス状態はSSZツリーに保存され、BlobsはKZGの約束として提出されます。将来的には、ブロックデータと状態用に単一の統合形式を作成することは理にかなっています。これらの形式では、すべての重要なニーズをカバーします。（i）ステートレスクライアントの簡単な証明、（ii）データのエンコードの消去、および（iii）標準化されたデータ構造。

• ビーコンチェーン委員会の削除：このメカニズムは、実行シャードの特定のバージョンをサポートするために最初に導入されました。代わりに、L2とBLOBを介してシャードを塗ります。したがって、委員会は不要であり、それを削除するために取り組んでいます。

• 混合バイト順序を削除します：EVMはビッグエンディアンバイトの順序であり、コンセンサスレイヤーは小さなエンディアンバイトの順序です。すべてを再調整し、すべてを大幅にエンディアンにすることは理にかなっているかもしれません（EVMが変化が難しいため、おそらくビッグエンディアンのエンディアン）。

さて、EVM内のいくつかの例：

• ガスメカニズムを簡素化：現在のガスルールはまだ十分に最適化されておらず、ブロックの検証に必要なリソースの数を明示的に制限することは不可能です。これの重要な例には、（i）ブロック内の読み取り/書き込み時間を制限するように設計されたストレージの読み取り/書き込みコストが含まれますが、現在非常にarbitrary意的であり、（ii）メモリフィルルールがあります。 EVM。推奨される修正には、ステートレスガスコストの変更、すべてのストレージ関連コストの単純な式との調整、およびメモリ価格設定の推奨事項が含まれます。

• プレリコンパイルを削除します：イーサリアムが今日持っている事前還元の多くは不必要で比較的使用されていないものであり、コンセンサスの失敗リスクの大部分を占めていますが、実際にはアプリケーションでは使用されていません。この問題に対処する2つの方法は、（i）プリコンパイルを直接削除し、（ii）同じロジックを実装するEVMコードに置き換える（必然的により高価な）EVMコードです。このEIPドラフトでは、最初にアイデンティティの事前コンパイルを行うことをお勧めします。

• ガスの観測可能性を削除します：EVMの実行により、どれだけのガスが残っているかを確認できなくなります。これにより、いくつかのアプリケーション（最も明らかに後援された取引）が破られますが、将来的にはより簡単にアップグレードできます（たとえば、より高度な多次元ガスバージョンの場合）。EOF仕様により、ガスは観察できなくなりましたが、プロトコルの簡素化を促進するには、EOFを必須である必要があります。

• 静的分析の改善：特にジャンプは動的である可能性があるため、今日のEVMコードは静的分析を実行することが困難です。これにより、最適化されたEVM実装（EVMコードを他の言語にPrecompile）することもより困難になります。この問題は、動的ジャンプを削除することで解決できます（または、たとえば、ガスコストは契約のジャンプデストの総数に直線的に関連しています）。これはEOFが行うことですが、プロトコルの簡素化の利点を取得するには、EOFを必須にする必要があります。

どのような研究が利用可能ですか？

パージの次のステップ：https://notes.ethereum.org/i_aihysjttcyau_adoy2ta

selfdestruct：https://hackmd.io/@vbuterin/selfdestruct

SSZ-化EIPS：[1] [2] [3]

ステートレスガスコストの変更：https://eips.ethereum.org/eips/eip-4762

線形メモリの価格設定：https://notes.ethereum.org/ljptsqbgr2knssu0yurwxw

プリコンパイルと削除：https://notes.ethereum.org/iwtx22ymqde1k_fz9psxig

ブルームフィルターの除去：https://eips.ethereum.org/eips/eip-7668

インクリメンタル検証可能な計算を使用したオフチェーンセキュアログ検索の方法（読み取り：再帰的スターク）：https://notes.ethereum.org/xzuqy8znt3keg1pkzpefxw

他に何をすべきか、そしてどのようなトレードオフがありますか？

このような機能的単純化の主なトレードオフは、（i）（ii）後方互換性との単純化の程度と速度です。チェーンとしてのイーサリアムの価値は、アプリケーションを展開し、何年も経っても適切に機能することを確認できるプラットフォームであることです。同時に、ウィリアム・ジェニングス・ブライアンの言葉で、「後方互換性の十字架でのネイル・イーサリアム」の言葉で、この理想をあまりにも遠くに置くことも可能です。イーサリアム全体の2つのアプリのみが機能を使用している場合、そのうちの1つは何年もの間ユーザーがなく、もう1つはほとんど役に立たず、合計57ドルの価値を受け取っている場合、必要に応じて機能を削除する必要があります。犠牲者へのあなた自身のポケットの。

より広範な社会問題は、非緊急の後方互換性の破壊的な変化のための標準化されたパイプラインを作成することです。この問題を解決する1つの方法は、自己破壊プロセスなど、既存の先例を確認して拡張することです。パイプは次のようになります：

• ステップ1：削除関数Xの議論を開始します。

• ステップ2：分析を実行して、xを削除することによってアプリケーションがどれだけ破壊的であるかを判断するか、（i）アイデアを放棄するか、（ii）計画どおりに進むか、（iii）修正された「最小破壊」削除xメソッドを決定し、続く。

• ステップ3：xを非難するために正式なEIPを作成します。人気のある高度なインフラストラクチャ（プログラミング言語、ウォレットなど）がこれを尊重し、機能の使用を停止してください。

• ステップ4：最後に、実際にXを削除します。

ステップ1と4の間には何年にもわたるプロセスがあり、どのプロジェクトがどのステップであるかを明確に述べる必要があります。この時点で、機能除去プロセスの強度と速度と、より多くのリソースをプロトコル開発に投資する他の分野との間にトレードオフがありますが、私たちはまだパレートの最前線からはほど遠いものです。

EOF

EVMに対して提案されている主な変更の1つは、EVMオブジェクト形式（EOF）です。EOFは、ガスの観測可能性の禁止、コードの観測可能性（つまり、コーデコピーなし）、静的ジャンプのみを許可するなど、多くの変更を導入します。目標は、EVMSがより強力なプロパティを実行して、より強力なプロパティを実行できるようにすることです。

これの利点は、新しいEVM機能を追加し、より強力な保証でより厳しいEVMへの移行を促進するための自然な道を作ることです。その欠点は、最終的に古いEVMを非難して削除する方法を見つけられない限り、プロトコルの複雑さを大幅に増加させることです。大きな問題は次のとおりです。特にEVM全体の複雑さを減らすことである場合、EVM単純化の提案でEOFはどのような役割を果たしますか？

ロードマップの残りの部分とどのように相互作用しますか？

残りのロードマップにおける「改善」提案の多くは、古い機能を簡素化する機会でもあります。上記の例を繰り返します：

• シングルスロット最終性に切り替えると、委員会、リエンジニアリング経済学をキャンセルし、ステークの証明に関連する他の単純化を行う機会が得られます。

• アカウントの抽象化を完全に実装すると、すべてのEOAを置き換えることができる「デフォルトアカウントEVMコード」に移動することにより、多くの既存のトランザクション処理ロジックを削除できます。

• Ethereum状態をバイナリハッシュツリーに移動すると、すべてのイーサリアムデータ構造を同じ方法でハッシュできるように、これをSSZの新しいバージョンと調整できます。

より根本的なアプローチ：プロトコルのほとんどを契約コードに変換します

より根本的なイーサリアム単純化戦略は、プロトコルをそのまま維持することですが、プロトコルの多くをプロトコル機能から契約コードに変換することです。

最も極端なバージョンは、Ethereum L1を「技術的には「ビーコンチェーン」にし、他の人が自分自身の概要を作成できる最小限のVM（システムを証明するために特別に使用されるRISC-V、CAIRO、またはよりシンプルなVMなど）を導入することです。次に、EVMはこれらの要約の最初になります。皮肉なことに、これは2019-20実装環境の提案とまったく同じ結果ですが、Snarkは実際に実装することをより実現可能にしています。

より控えめなアプローチは、ビーコンチェーンと現在のイーサリアム実行環境との関係を変えないように保つことですが、EVMを交換することです。RISC-V、カイロ、またはその他のVMを新しい「公式イーサリアムVM」として選択し、すべてのEVM契約を元のコードロジックを解釈する新しいVMコードにキャストできます（コンピレーションまたは解釈によって）。理論的には、EOFバージョンとして「ターゲットVM」でこれを行うことさえ可能です。

ジャスティン・ドレイク、ティム・ベイコ、マット・ガーネット、パイパー・メリアム、マリウス・ファン・デル・ウィジデン、トマス・スタンザックのフィードバックとコメントに感謝します。