ヴィタリック：イーサの「パージ」フェーズの主な目標

著者：Vitalik（イーサリアム創設者）; Compiled by Deng Tong, Golden Finance

注：この記事は、イーサリアムの創設者であるVitalikが最近発表したイーサリアムプロトコルの未来に関する連載記事の第5回：The Purgeです。https://vitalik.eth.limo/general/2024/10/26/futures5.html" target="_blank">イーサリアムプロトコルの可能な未来、パート5：パージ。"、パート4については、"Vitalik: The Verge、イーサの未来"を参照。パート3は"Vitalik: Ether's The Scourge Phase"で、パート2は"Vitalik: Ether's The Scourge Phase"でご覧いただけます。"Vitalik: EtherプロトコルのThe Surge Phaseはどのように進化すべきか", Part 1は以下でご覧いただけます。"EtherのPoSで他に改善できる点"にあります。

Justin Drake氏、Tim Beiko氏、Matt Garnett氏、Piper Merriam氏、Marius van der Wijden氏、Tomasz Stanczak氏のフィードバックとコメントに感謝します。

イーサネットが直面している課題の1つは、デフォルトでは、どのブロックチェーンプロトコルも時間とともに肥大化し、複雑さが増すということです。

• Historical data:過去のデータ:歴史のどの時点でも作成された取引やアカウントは、永久に保存され、新しいクライアントによってダウンロードされる必要があります。保存され、ネットワークと完全に同期された新しいクライアントによってダウンロードされる必要があります。このため、チェーンの容量が一定であっても、クライアントの負荷と同期にかかる時間は時間とともに増加します。

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

イーサが長期的に持続可能であるためには、私たちはこれらの傾向の両方に強い対抗圧力をかけ、時間の経過とともに複雑さと肥大化を減らしていく必要があります。しかしその間に、私はブロックチェーンの重要な属性の1つである「永続性」を維持する必要があります。あなたはNFT、トランザクションコールデータのラブレター、または100万ドルを含むスマートコントラクトをチェーン上に置くことができます。Dappsが安心して完全分散化し、アップグレードキーを削除するためには、依存関係が壊れるようなアップグレードをされないという確信が必要だ。

『パージ』2023年ロードマップ。

この2つのニーズのバランスを取ることに集中すれば、継続性を維持しながら、拡大、複雑化、衰退を最小限に抑えたり、逆に抑えたりすることは絶対に可能です。ほとんどの生物は時間とともに老化していきますが、幸いなことに、そうでないものもいくつかあります。社会システムでさえ、極めて長い寿命を持つことができる。プルーフ・オブ・ワークは姿を消し、SELFDESTRUCTオペコードはほとんど姿を消し、ビーコン・チェーン・ノードは古いデータを最大6ヶ月間保存している。より一般的な方法でイーサのためのこの道を見つけ、長期的に安定した最終結果に向かって進むことは、イーサの長期的なスケーラビリティ、技術的な持続可能性、さらにはセキュリティのための究極の挑戦です。

粛清：主な目標

• 各ノードがすべての履歴を永久に保存する必要性を減らすかなくすことで、クライアント側のストレージ要件を削減し、おそらく最終的には宣言する

• 不要な機能を排除することで、プロトコルの複雑さを軽減する

履歴データの有効期限

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

この記事を書いている時点では、完全に同期されたイーサネットノードは、実行クライアントに約1.1TBのディスクスペース、コンセンサスクライアントにさらに数百GBのディスクスペースを必要とします。この大部分は履歴データで、過去のブロック、トランザクション、レシートに関するデータで、そのほとんどは何年も前のものです。つまり、ガスの上限がまったく増えなかったとしても、ノードのサイズは毎年数百ギガバイトずつ増えていくことになる。

これは何ですか？どのように機能するのか？

履歴保存問題を単純化する重要な特徴は、各ブロックがハッシュリンク（およびその他の構造）を介して前のブロックを指すため、現在に関するコンセンサスが履歴に関するコンセンサスに十分であるということです。ネットワークが最新のブロックについてコンセンサスに達している限り、どのような履歴ブロック、取引、状態（口座残高、乱数、コード、ストレージ）でも、一人の参加者がメルクル証明で提供することができ、その証明によって他のどの参加者もその正しさを検証することができる。コンセンサスがN/2-of-Nの信頼モデルであるのに対し、履歴は1-of-Nの信頼モデルである。

このことは、履歴をどのように保存するかについて、多くの選択肢を開くことになります。1つの自然な選択肢は、各ノードがデータのごく一部だけを保存するネットワークです。これは、何十年もの間、トレントネットワークがどのように機能してきたかを示しています。ネットワークが合計で何百万ものファイルを保存・配布しているのに対し、各参加者はそのうちの数個のみを保存・配布しています。直感に反するかもしれないが、この方法は必ずしもデータの堅牢性を低下させるものでもない。仮に、ノードの実行コストを削減することで、10万ノードのネットワークを実装し、各ノードがその履歴のランダムな10％を保存するとすると、各データは10,000回複製されることになります。- 各ノードがすべてを保存する10,000ノードのネットワークとまったく同じレプリケーション係数です。

今日、イーサはすべてのノードがすべての履歴を永久に保存するというモデルから脱却し始めています。コンセンサスブロック（すなわち、プルーフ・オブ・ステーク・コンセンサスに関連する部分）は約6ヶ月間しか保存されません。長期的な目標は、各ノードがすべてを保存する責任を負う調整期間（おそらく～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-specs/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を有効にすることができます。それ自体はハードフォークを必要としませんが、ネットワークプロトコルの新バージョンを必要とします。そのため、すべてのクライアントで同時に有効にすることが重要です。そうしないと、履歴の完全なダウンロードを期待しながら、実際にはそれを達成しない他のノードへの接続によって、クライアントが失敗する可能性があるからです。

主なトレードオフは、「前の」履歴データをどのように利用可能にするかということです。最も単純な解決策は、明日から以前のデータを保存するのをやめ、既存のアーカイブノードと、レプリケーションのためのさまざまな集中型プロバイダーに頼ることです。これは簡単だが、永続的なデータの記録としてのイーサの立場を弱めることになる。より難しいが、より安全なアプローチは、まずトレントネットワークを構築し統合して、履歴を分散して保存することだろう。

• 最大数のノードが実際にすべてのデータを保存していることを確認するために、どれだけ努力しなければならないか？すべてのデータを保存することを確認するのは、どれほど難しいことなのでしょうか？

• 履歴ストアをプロトコルとどれだけ深く統合するか？

(1)については、最も厳密なアプローチは、proof-of-custodyを含むことでしょう。事実上、各Proof-of-entitlement検証者に、その履歴の一定割合を保存することを要求し、定期的に暗号的にそうしていることをチェックします。より控えめなアプローチとしては、クライアントごとに保存される履歴の割合に自主的な基準を設けることでしょう。

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

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

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

Status data expiration

What problem does it solve?

クライアントが履歴を保存する必要性をなくしたとしても、アカウント残高と乱数、契約コード、契約ストレージといった状態が増えるため、クライアントのストレージのニーズは年間約50GBと増え続けます。ユーザーは、現在および将来のEtherクライアントに永遠に負担をかけるために、1回限りの料金を支払うことができます。

EVM設計の基本的な前提は、ステートオブジェクトが一度作成されると、それは永遠に存在し、いつでもどのトランザクションでも読み取ることができるというものだからです。実際にステートを保存する必要があるのは特殊なクラスのブロックビルダーだけで、他のすべてのノード（リスト生成でさえ！）はステートレスで実行できる。はすべてステートレスで実行できる。しかし、ステートレスに過度に依存したくないという意見もあり、最終的にはイーサの分散性を維持するために、ステートを失効させたいという意見もあります。

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

今日、新しいステートオブジェクトを作成すると（(i)新しいアカウントにETHを送る、(ii)コードを使用して新しいアカウントを作成する、(iii)以前は触れていなかったストレージスロットを設定する、の3つの方法のいずれかで行うことができます）、そのステートオブジェクトは常にその状態になります。その代わりに私たちが望むのは、オブジェクトが時間とともに自動的に期限切れになることだ。

• EFFICIENCY: 有効期限切れ処理を実行するために、多くの余分な計算を必要としない。

• 有効期限切れ処理を実行するのに余分な計算を必要としない。

• 使いやすさ：誰かが5年間洞窟に入り、その後戻ってきたとしても、ETH、ERC20、NFT、CDPのポジションへのアクセスを失うことはありません......

• 。strong>開発者フレンドリー：開発者は、完全に新しい考え方モデルに切り替える必要はありません。さらに、今日の硬直した、更新されていないアプリケーションは、それなりにうまく機能し続けるはずです。

これらの目標を達成しなくても、問題は簡単に解決できます。たとえば、各状態オブジェクトに、その有効期限を追跡するカウンタも格納させ (これは、読み取りまたは書き込み時に自動的に発生する ETH を破棄することで拡張できます)、有効期限切れの状態オブジェクトを削除するために状態を走査するループを持たせることができます。しかし、これでは追加の計算（さらにはストレージ要件）が発生し、ユーザーの利便性要件を満たすことはできません。また、時々ゼロにリセットされるストレージ値を含む極端なケースについて、開発者が推論することも困難です。契約範囲内になるように有効期限タイマーを設定すれば、技術的には開発者の仕事は楽になりますが、経済的には難しくなります。

これらは、「ブロックチェーン賃貸料」や「再生」といった提案を含め、イーサリアム開発の中核コミュニティが何年も取り組んできた問題です。

• 最終的に、私たちは提案の最良の部分を組み合わせ、「最も最悪な既知のソリューション」の2つのカテゴリーに焦点を当てました。部分的な状態終了ソリューション。

• アドレス サイクル ベースの状態満了案。

Partial state expiration

Partial state expirationの提案はすべて同じ原則に従います。状態をチャンクに分割します。それぞれが、どのブロックが空か空でないかの「トップレベルマップ」を永久に保存します。各ブロックのデータは、最近アクセスされた場合のみ保存される。ブロックが保存されなくなった場合、それが何であるかの証明を提供することで、誰でもデータを復元できるように、「復活」のメカニズムがある。

これらの提案の主な違いは、(i) 「最近」をどのように定義するか、(ii) 「ブロック」をどのように定義するか、です。具体的な提案のひとつはEIP-7736で、これはVerkle木に導入された「stem-and-leaf」設計をベースにしています（ただし、バイナリ木など、あらゆる形式のステートレス木と互換性があります）。この設計では、互いに隣接するヘッダ、コード、スロットは同じ「ステム」の下に格納される。ステムの下に格納されるデータは、256 * 31 = 7,936バイトまで可能である。多くの場合、アカウントのヘッダーとコード全体、および多くの主要な格納スロットが、同じステムの下に格納されます。あるトランクの下にあるデータが6ヶ月以内に読み込まれたり書き込まれたりしなかった場合、そのデータはもはや保存されず、データに対する32バイトのコミットメント（「スタブ」）のみが保存される。今後このデータにアクセスするトランザクションは、データを「復活」させ、スタブとの照合を証明する必要がある。

同様のアイデアを実装する方法は他にもあります。例えば、アカウント間隔が不十分な場合、ツリーの各1/232部分が同様のステム＆リーフメカニズムによって制御されるスキームを開発することができます。

これは、インセンティブがあるため、さらに厄介です。攻撃者は、大量のデータを単一のサブツリーに配置し、毎年単一のトランザクションを送信することによって「ツリーを更新」することができ、クライアントに大量の状態を恒久的に保存させることができます。更新のコストがツリーのサイズに比例する（あるいは更新の期間がツリーのサイズに反比例する）ようにすれば、誰かが自分と同じサブツリーに大量のデータを置くことで、他のユーザーに危害を加えることができるかもしれない。例えば、連続する2^16=65536個のステートオブジェクトを「グループ」とみなすことができる。しかし、これらのアイデアはより複雑です。ステミングベースのアプローチはシンプルであり、インセンティブを調和させることができます。

アドレスサイクル・ベース・ステートエクスパイアの提案

32バイトのスタブであっても、恒久的なステートの成長をまったく避けたい場合はどうすればよいでしょうか?ここに難問があります: 状態オブジェクトが削除され、後のEVMの実行でまったく同じ場所に別の状態オブジェクトが置かれ、元の状態オブジェクトを気にする人が戻ってきて、それを復元しようとしたらどうなるでしょうか?部分的な状態失効の場合、"スタブ "が新しいデータの作成を防ぎます。完全なステートエクスパイアの場合は、スタブを保存することさえできません。

アドレス・サイクル・ベースの設計は、この問題を解決する最善の方法です。ステート全体を1つのステートツリーに格納するのではなく、ステートツリーのリストを増やしていき、読み書きされたステートは最新のステートツリーに格納されます。新しい空の状態ツリーは、1サイクル（1年と考える）ごとに追加される。古いステートツリーは固定される。完全なノードは、最新の2つのツリーだけを保存すればよい。ステートオブジェクトが2サイクルの間触れられず、そのため期限切れのツリーに落ちても、読み書きは可能であるが、トランザクションはそのためのメルクル証明を証明する必要がある。

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

このデザインは、イーサの現在の属性のほとんどを保持し、追加の計算がほとんどなく、アプリケーションを現在とほぼ同じように書くことができます（ERC20は、アドレス期間Nのアドレスの残高が、それ自体がアドレス期間Nを持つサブコントラクトに保存されるように書き換える必要があります）。"という問題を解決する。しかし、1つ大きな問題があります。アドレスは、アドレス周期に収まるように20バイトを超えて拡張する必要があります。

アドレス空間の拡張

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

0x01000000000157aE408398dF7E5f4552091A69125d5d5dFcb7B8C2659029395bdF

赤がバージョン番号です。ここでオレンジ色の4つのゼロは、将来的にスライス番号を収容するための空白を示します。緑はアドレスサイクル番号です。青は26バイトのハッシュです。

ここでの重要な課題は、後方互換性です。既存のコントラクトは20バイトアドレスを中心に設計されており、多くの場合、アドレスが正確に20バイト長であることを明示的に仮定するタイトなバイトパッキング技術を使用しています。この問題を解決する1つのアイデアは、変換グラフを使用することで、新しいアドレスと相互作用する古いコントラクトが、新しいアドレスの20バイトハッシュを参照するようにすることである。しかし、これを安全なものにするにはかなりの労力を要するだろう。

アドレス空間の縮小

他のアプローチは逆で、いくつかの2128サイズのアドレスのサブ範囲(たとえば、0xffffffffで始まるすべてのアドレス)を直ちに無効にし、その範囲を使って、アドレスサイクルと14バイトハッシュを持つアドレスを導入します。

0xffffff000169125d5dFcb7B8C2659029395bdF

このアプローチがもたらす重要な犠牲は、アセットまたはパーミッションを保持しているが、そのコードがまだチェーンに公開されていないアドレスという、偽造アドレスのセキュリティリスクをもたらすことです。このリスクは、誰かが（まだ公開されていない）コードを持っていると主張するアドレスを作成し、同じアドレスを指すハッシュを持つ別の有効なコードを持っているというものだ。このような衝突を計算するには、現在280個のハッシュが必要ですが、アドレス空間が縮小されれば、その数は非常にアクセスしやすい256個のハッシュに減るでしょう。

重要なリスク領域である、単一の所有者によって保持されていないウォレットのための反実仮想アドレスは、今日では比較的まれな状況ですが、マルチL2の世界に移行するにつれて、より一般的になる可能性が高い状況です。唯一の解決策は、単純にこのリスクを受け入れることですが、物事がうまくいかない可能性のあるすべての一般的なユースケースを特定し、効果的な解決策を考え出すことです。

どのような研究が存在するのでしょうか？

初期の提案

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

リジェネシス:https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582

イーサステートサイズ管理の理論https://hackmd.io/@vbuterin/state_size_management

無状態と状態失効のためのいくつかの可能なパス：https://hackmd.io/expiry_paths" _src="https://hackmd.io/@vbuterin/state_expiry_paths">https://hackmd.io/@vbuterin/state_expiry_paths

https://hackmd.io/@vbuterin/state_expiry_pathsstrong>一部状態失効提案

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

Documentation of Address Space Extensions

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

イプシロンがコメント：イプシロンがコメント。exploration"_src="https://notes.ethereum.org/@ipsilon/address-space-extension-exploration">https://notes.ethereum.org/@ipsilon/address-space-extension-exploration

ブログ記事コメント：https://medium.com/@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6。extension-60626544b8e6

衝突抵抗を失うとどうなるか：https://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356

残された課題は？何を計量する必要があるのか？

• ステートレス（無国籍）を実践し、ステートの有効期限を導入しない。ステートは（ゆっくりではありますが）増え続けています（おそらく何十年も8TBを超えることはないでしょう）。

  ステートの一部へのアクセスを必要とする機能の1つは、インクルードリストの生成ですが、これを分散型の方法で実装することができます：各ユーザーは、自分のアカウントを含むステートツリーの一部を維持する責任があります。トランザクションをブロードキャストするとき、検証ステップ中にアクセスされたステートオブジェクトの証明をブロードキャストします（これはEOAとERC-4337の両方のアカウントに適用されます）。ステートレスバリデータは、これらの証明をインクルードリスト全体の証明にまとめることができます。

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

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

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

重要な点は、アドレスフォーマットの変更に依存する状態失効スキームが実装されるかどうかにかかわらず、アドレス空間の拡張と縮小という課題に最終的に対処しなければならないということです。現在、アドレスの競合を生成するには約 2^80 ハッシュが必要ですが、この計算負荷は、リソースが非常に豊富なプレイヤーにとってはすでに実現可能なものです。FPGAやASICを使えば、このプロセスをさらに加速できる。将来的には、このような攻撃はますます多くの人々に開かれたものになるだろう。その結果、いずれにせよこの非常に困難なアドレス問題を解決しなければならないため、完全な状態消去を実装する実際のコストは、見た目ほど高くはないかもしれません。

ロードマップの残りの部分とどのように相互作用するのでしょうか?

状態の有効期限を実行することで、変換プロセスが不要になるため、あるステートツリー形式から別のステートツリー形式への変換が容易になるかもしれません。ですから、ステート・エクスパイアは複雑ですが、ロードマップの他の側面を簡素化するのに役立ちます。

Feature cleanup

どのような問題を解決するのか?

セキュリティ、アクセシビリティ、信頼された中立性のための重要な前提条件の1つは、シンプルさです。プロトコルが美しくシンプルであれば、エラーの可能性は低くなります。新しい開発者がそのプロトコルのどの部分でも参加し、使用できる可能性が高まります。公平である可能性が高くなり、特別な利害関係者に抵抗しやすくなる。残念なことに、プロトコルは他の社会システムと同様、時間が経つにつれて複雑になっていく。(i) 変更を加えてプロトコルを骨抜きにするのをやめる。中間のコース、つまり、プロトコルの変更を少なくしつつ、時間とともに少なくとも少しの複雑さを取り除くことも可能です。このセクションでは、複雑さを減らしたり取り除いたりする方法について説明します。

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

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

本質的にすでに行われており、他の問題に対処する方法の青写真として役立つ例のひとつは、SELFDESTRUCT オペコードの削除です。SELFDESTRUCT opcodeは、1つのブロック内で無制限にストレージスロットを変更できる唯一のものであり、DoS攻撃を避けるために、クライアントはより高度な実装を要求されます。このオペコードの本来の目的は、自発的な状態消去を可能にし、時間の経過とともに状態サイズを減少させることである。実際には、これを使用する人はほとんどいません。このオペコードは、Dencunハードフォークの同じトランザクションで作成された自己破壊アカウントのみを許可するように弱体化された。これはDoS問題を解決し、クライアント側のコードの大幅な簡素化を可能にします。将来的には、最終的にこのオペコードを完全に削除することが理にかなっているかもしれません。

これまでに確認されたプロトコル簡素化の機会の主な例には、以下のようなものがあります。まず、EVM以外のいくつかの例です。これらは比較的押し付けがましくないため、コンセンサスを得やすく、短期間で実装することができます。

• RLP → SSZ 変換:もともと、EtherオブジェクトはRLPと呼ばれるエンコーディングを使ってシリアル化されていました。今日、ビーコンチェーンはSSZを使用しており、シリアライズだけでなくハッシュもサポートするなど、多くの点で格段に優れています。最終的には、RLPから完全に脱却し、すべてのデータ型をSSZ構造に移行したいと考えています。この目的のために現在提案されているEIPには、[1] [2] [3]があります。

• 古いトランザクション型の削除: 今日、非常に多くのトランザクション型があり、それらの多くが削除されるかもしれません。完全に削除するよりも控えめな代替案は、アカウント抽象化機能で、スマートアカウントは（希望すれば）旧式のトランザクションを処理し検証するコードを含めることができる。

• LOG reform:ログは、プロトコルに複雑さを加えるブルームフィルターやその他のロジックを作成しますが、クライアントが実際に使用しないほど遅いです。私たちはこの機能を削除し、代わりにSNARKのような最新の技術を使用したプロトコル外の分散型ログ読み取りツールのような代替に力を注ぐことができます。

• Beacon Chain Synchronisation Committeeメカニズムを最終的に削除する: Synchronisation Committeeメカニズムは当初、Etherの軽いクライアントサイド検証を可能にするために導入されました。しかし、プロトコルに複雑さを加えていました。最終的には、SNARKを使用してイーサネットのコンセンサスレイヤーを直接検証できるようになり、専用のライトクライアント検証プロトコルが不要になります。これにより、イーサネット・コンセンサス・バリデーターのランダムなサブセットからの署名を検証する、より「ネイティブ」なライトクライアント・プロトコルが作成され、専用のライトクライアント・プロトコルの必要性がなくなります。

• データフォーマットの調和：現在、実行状態はMerkle Patriciaツリーに格納され、コンセンサス状態はSSZツリーに格納され、ブロブはKZGコミットメントとして提出されます。将来的には、ブロックデータとステートに単一の統一フォーマットを作成するのが理にかなっている。これらのフォーマットは、(i)ステートレスクライアントのためのシンプルな証明、(ii)データのシリアライズと消去符号化、(iii)標準化されたデータ構造、といった重要なニーズをすべてカバーする。

• ビーコンチェイニング委員会の削除：当初、このメカニズムはバージョン固有の実行シャーディングをサポートするために導入されました。その代わりに、私たちはL2とブロブを介してシャーディングすることになりました。その結果、委員会は不要になったので、削除するための取り組みが進行中です。

• 混合バイトオーダーを削除する: EVMはビッグエンディアンバイトオーダーで、コンセンサスレイヤーはリトルエンディアンバイトオーダーです。EVMはビッグエンディアンバイトオーダーで、コンセンサスレイヤーはリトルエンディアンバイトオーダーです。

さて、EVM内部のいくつかの例です:

• ガスメカニズムの簡略化:現在のガスルールは、EVMに最適化されていません。現在のガス・ルールは、ブロックの検証に必要なリソースの量を明示的に制限するために、うまく最適化されていません。その主な例として、(i) メモリの読み取り/書き込みコスト（ブロック内の読み取り/書き込み回数を制限することを意図しているが、現状では非常に恣意的である）、(ii) メモリ充填ルール（EVMの最大メモリ消費量を見積もることを現状では困難にしている）などがあります。提案されている修正には、すべてのストレージ関連コストを単純な式に調和させるためのステートレス・ガス・コストの変更、およびメモリ価格設定の提案が含まれます。

• プリコンパイルの削除:現在Etherにあるプリコンパイルの多くは、不必要に複雑で、比較的使用されておらず、どのアプリケーションでも実際には使用されていないコンセンサス失敗のクローズコールの大きな割合を占めています。この問題に対処する2つの方法は、(i)プリコンパイルを完全に削除すること、(ii)同じロジックを実装する（必然的に高価な）EVMコードに置き換えることです。このEIP草案では、まずアイデンティティのプリコンパイルについてこれを行うことを提案しており、後にRIPEMD160、MODEXP、およびBLAKEが削除される可能性があります。

• ガス観測可能性の削除:は、EVM実行がガスの残量を確認することを不可能にします。これは、いくつかのアプリケーション（特にスポンサードトランザクション）を壊しますが、将来のアップグレード（例えば、多次元ガスのより高度なバージョン）を容易にします。を観測不可能にしているが、プロトコルの簡素化に貢献するためには、EOFを必須にする必要がある。

• 静的解析の改善:今日のEVMコードは、特にジャンプが動的である可能性があるため、静的に解析することが困難です。また、最適化されたEVM実装（他の言語にコンパイル済みのEVMコード）を作成することも難しくなります。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

Linear memory pricing: https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw

コンパイル前の削除:https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg

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

アンダーチェーンのセキュリティログに漸進的な検証可能な計算を使用する方法。チェーン下のセキュリティログの検索にインクリメンタルな検証可能な計算を使用する方法(再帰的STARKと読む): https://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw

さらに何をする必要があり、トレードオフは何か？

この機能的な簡略化を行う際の主なトレードオフは、(i)どれだけ速く簡略化するか、(ii)後方互換性です。チェーンとしてのイーサの価値は、アプリケーションをデプロイできるプラットフォームであり、数年後も動作すると確信できることです。同時に、この理想が行き過ぎて、ウィリアム・ジェニングス・ブライアンの言葉を借りれば、"Etherを後方互換性の十字架にはりつけにする "ことも可能だ。ある機能を使用しているアプリがEtherium全体で2つしかなく、そのうちの1つは何年もユーザーがおらず、もう1つはほとんど使われておらず、合計57ドルの価値を得ているのであれば、私たちはその機能を削除し、必要であれば私たちのポケットから被害者に57ドルを支払うべきです。

より広範な社会的問題は、緊急ではない後方互換性のある破壊的な変更のための標準化されたパイプラインの作成です。この問題に対処する1つの方法は、SELFDESTRUCTパイプラインのような既存の先例を調べ、拡張することです。

• Step 1:機能Xを削除する議論を開始する

• SELFDESTRUCTパイプラインは次のようになります。strong>ステップ2:Xを削除することがアプリケーションにとってどの程度破壊的であるかを判断するための分析を行い、その結果に基づいて、(i)アイデアを放棄する、(ii)計画通りに進める、または(iii)Xを削除する修正された「最も破壊的でない」方法を決定して進める、のいずれかを選択する。

• ステップ3: Xを非推奨とする正式なEIPを開発し、一般的な高レベルのインフラ（プログラミング言語やウォレットなど）がこれを尊重し、この機能の使用を中止するようにします。

• ステップ4：最後に、Xを物理的に削除します。

ステップ1と4の間には、どのプロジェクトがどのステップにいるのかを明確に示す、数年にわたるプロセスがあるはずです。この時点では、機能削除プロセスの強さと速さと、より保守的になってプロトコル開発の他の分野にリソースを割くことの間にはトレードオフがありますが、パレート フロンティアまでは長い道のりです。