Vitalik の新しい記事: Ethereum (V) の将来可能性 — The Purge

31 0 0

原題: イーサリアムプロトコルの将来可能性、パート 5: パージ

元記事：ヴィタリック・ブテリン

原文翻訳: Odaily Planet Daily Husband How

10月14日以来、イーサリアムの創設者ヴィタリック・ブテリンは、イーサリアムの将来についての議論を次々と発表している。合併 , 急増 , スカージ , ザ・ヴァージ最新リリースパージ、それらはすべて、イーサリアムメインネットの将来の発展と現在の問題を解決する方法に関する Vitalik のビジョンを強調しています。ソリューション。

The Merge: PoS に移行した後、参加を増やしてトランザクションの確認を高速化するために、Ethereum がシングルスロットのファイナリティを改善し、ステーキングしきい値を下げる必要があることについて説明します。

The Surge: Ethereum をスケーリングするためのさまざまな戦略、特に Rollup 中心のロードマップと、スケーラビリティ、分散化、セキュリティの観点から見た課題と解決策を探ります。

The Scourge: PoS への移行において Ethereum が直面する集中化と価値抽出のリスクを調査し、分散化と公平性を高めるための複数のメカニズムを開発し、ユーザーの利益を保護するためにステーキング経済を改革します。

The Verge: Verkle ツリーや STARK などのテクノロジーがブロックチェーンの分散化と効率性をどのように高めることができるかに焦点を当て、Ethereum のステートレス検証の課題と解決策を探ります。

10月26日、Vitalik Buterin氏はThe Purgeについての記事を公開し、イーサリアムが直面している課題は、チェーンの耐久性と分散性を維持しながら、長期的に複雑さとストレージ要件を削減する方法であると述べました。主な対策としては、履歴の有効期限と状態の有効期限を通じてクライアントのストレージ負荷を軽減すること、機能のクリーンアップを通じてプロトコルを簡素化し、ネットワークの持続可能性とスケーラビリティを確保することなどが挙げられます。

以下はOdaily Planet Dailyによって翻訳されたオリジナルコンテンツです。

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

Ethereum の課題の 1 つは、デフォルトでは、ブロックチェーンプロトコルは時間の経過とともに肥大化し、複雑化していくことです。これは次の 2 つの場所で発生します。

履歴データ: 履歴のどの時点で行われたトランザクションや作成されたアカウントも、ネットワークに完全に同期するには、すべてのクライアントによって永続的に保存され、新しいクライアントによってダウンロードされる必要があります。これにより、チェーンの容量が一定であっても、クライアントの負荷と同期時間は時間の経過とともに増加します。
プロトコル機能: 古い機能を削除するよりも新しい機能を追加する方がはるかに簡単であり、時間の経過とともにコードの複雑さが増加します。

イーサリアムが長期的に持続可能であるためには、これらの両方の傾向に強い反対圧力をかけ、時間の経過とともに複雑さと肥大化を減らす必要があります。しかし同時に、ブロックチェーンを優れたものにする重要な特性の 1 つである耐久性を維持する必要があります。NFT、トランザクションコールデータ内のラブレター、または $1 百万のスマートコントラクトをチェーン上に置き、10 年間洞窟に閉じこもった後、出てきたときには、まだそこにあり、読んだり操作したりできるのを待っています。DApps が完全に分散化され、アップグレードキーが削除されることに安心感を持つためには、依存関係がアップグレードされても、特に L1 自体が壊れることはないという確信が必要です。

Vitalik の新しい記事: Ethereum (V) の将来可能性 — The Purge

決意さえすれば、これら2つのニーズのバランスを取り、継続性を維持しながら肥大化、複雑化、衰退を最小限に抑えたり逆転させたりすることは絶対に可能です。生物はこれが可能です。ほとんどの生物は時間の経過とともに老化しますが、幸運な少数の人は社会システムでさえ寿命が非常に長いイーサリアムはいくつかのケースで成功しています。プルーフオブワークはなくなり、SELFDESTRUCT オペコードはほぼなくなり、ビーコンチェーンノードは最大 6 か月前のデータを格納しています。イーサリアムのこの道筋をより一般的な方法で、そして長期的に安定した最終結果に向けて理解することは、イーサリアムの長期的なスケーラビリティ、技術的な持続可能性、さらにはセキュリティにとって究極の課題です。

パージ: 主な目的。

クライアントのストレージ要件の低減 各ノードがすべての履歴や最終状態を永続的に保存する必要性を減らすか排除することによって。
不要な機能を排除することでプロトコルの複雑さを軽減します。

記事ディレクトリ:

履歴の有効期限

それはどんな問題を解決するのでしょうか?

この記事の執筆時点では、完全に同期されたEthereumノードには約1.1TB ディスク容量実行クライアント、コンセンサスクライアントにはさらに数百 GB の容量があります。この容量の大部分は履歴です。つまり、過去のブロック、トランザクション、領収書に関するデータで、その多くは何年も前のものです。つまり、ガス制限がまったく増加しなかったとしても、ノードのサイズは毎年数百 GB ずつ増加し続けることになります。

それは何であり、どのように機能するのでしょうか?

履歴保存問題の重要な単純化の特徴は、各ブロックがハッシュリンクを介して前のブロックを指しているため（そして他の構造 )、現在のコンセンサスは履歴のコンセンサスに達するのに十分です。ネットワークが最新のブロックに同意する限り、過去のブロックやトランザクション、状態（口座残高、乱数、コード、ストレージ）は、マークル証明とともに任意の参加者によって提供され、その証明によって他の誰もがその正しさを検証できます。コンセンサスはN/2-of-N信頼モデルですが、履歴は N-of-N信頼モデル .

これにより、履歴の保存方法には多くの選択肢が残されています。自然な選択肢の 1 つは、各ノードがデータのごく一部だけを保存するネットワークです。これは、Seed ネットワークが数十年にわたって運用してきた方法です。ネットワークは合計で数百万のファイルを保存および配布しますが、各参加者はそのうちのほんの一部だけを保存および配布します。直感に反するかもしれませんが、このアプローチでは、必ずしもデータの堅牢性が低下するわけではありません。ノードの実行コストを低く抑えて、各ノードが履歴のランダムな 10% を保存する 100,000 ノードのネットワークを構築できる場合、各データは 10,000 回複製されます。これは、各ノードがすべてのデータを保存する 10,000 ノードのネットワークとまったく同じ複製係数です。

現在、イーサリアムは、すべてのノードがすべての履歴を永続的に保存するモデルから離れ始めています。コンセンサスブロック (つまり、プルーフオブステークコンセンサスに関連する部分) は約 6 か月間のみ保存されます。BLOB は約 18 日間のみ保存されます。 EIP-4444 過去のブロックと領収書の保存期間を 1 年間にすることを目標としています。長期的な目標は、各ノードがすべての保存を担当する均一な期間 (おそらく約 18 日間) を確立し、分散ネットワーク方式で古いデータを保存する Ethereum ノードのピアツーピアネットワークを確立することです。

Vitalik の新しい記事: Ethereum (V) の将来可能性 — The Purge

消去コードを使用すると、レプリケーション係数を同じに保ちながら堅牢性を向上させることができます。実際、BLOB はデータ可用性のサンプリングをサポートするためにすでに消去コード化されています。最も簡単な解決策は、おそらくそのような消去コードを再利用し、実行ブロックとコンセンサスブロックのデータも BLOB に配置することです。

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

他に何を行う必要があり、どのようなトレードオフを行う必要があるのでしょうか?

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

主なトレードオフは、「古代」の履歴データを利用できるようにするためにどれだけ努力するかということです。最も簡単な解決策は、明日から古代の履歴を保存するのをやめ、既存のアーカイブノードとさまざまな集中型プロバイダーにレプリケーションを頼ることです。これは簡単ですが、永続的な記録場所としての Ethereum を弱体化させます。より困難ですが、より安全な方法は、最初にトレントネットワークを構築して統合し、分散型で履歴を保存することです。ここで、「どれだけ努力するか」には 2 つの側面があります。

最大のノードセットが実際にすべてのデータを格納するようにするにはどうすればよいでしょうか?
履歴ストレージをプロトコルにどの程度深く統合しますか?

（１）に対する極度に偏執的なアプローチは、監護権の証明 : 事実上、各プルーフオブステークバリデーターに一定の割合の履歴を保存することを義務付け、定期的に暗号それをグラフィカルにチェックします。より穏健なアプローチとしては、各クライアントが保存する履歴の割合について自主的な基準を設定することが挙げられます。

（2）については、基本的な実装には現在すでに行われている作業のみが含まれます。Portal はすでに Ethereum の全履歴を含む ERA ファイルを格納しています。より徹底した実装には、実際にそれを同期プロセスに接続することが含まれます。これにより、完全な履歴ストレージノードまたはアーカイブノードを同期したい場合、他のアーカイブノードがオンラインに存在しない場合でも、Portal ネットワークから直接同期することで同期できます。

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

ノードの実行やスピンアップを極めて簡単にしたい場合、履歴ストレージ要件の削減はステートレスであることよりもおそらく重要です。ノードに必要な 1.1 TB のうち、約 300 GB が状態であり、残りの約 800 GB が履歴です。ステートレスと EIP-4444 によってのみ、スマートウォッチで Ethereum ノードを実行し、わずか数分でセットアップするというビジョンを実現できます。
履歴ストレージを制限することで、新しいイーサリアムノード実装がプロトコルの最新バージョンのみをサポートすることがより現実的になり、はるかにシンプルになります。たとえば、2016年のDoS攻撃中に作成された空のストレージスロットがすべて削除されたため、多くのコード行を安全に削除できるようになりました。削除されましたプルーフ・オブ・ステークへの移行は過去のものとなったため、クライアントはプルーフ・オブ・ワーク関連のコードすべてを安全に削除できます。

州の有効期限

それはどんな問題を解決するのでしょうか?

クライアントが履歴を保存する必要がなくなったとしても、アカウント残高と nonce、契約コード、契約ストレージなどの状態が拡大し続けるため、クライアントのストレージ要件は年間約 50 GB ずつ増加し続けます。ユーザーは 1 回限りの料金を支払うことになり、現在の Ethereum クライアントと将来の Ethereum クライアントに永久に負担をかけることになります。

状態は履歴よりも期限切れになりにくいです。なぜなら、EVM は基本的に、状態オブジェクトが作成されると常に存在し、いつでもどのトランザクションでも読み取ることができるという前提で設計されているからです。ステートレス性を導入すれば、この問題はそれほど深刻ではないと考える人もいます。特殊なブロックビルダークラスだけが実際に状態を保存すればよく、他のすべてのノード (リスト生成も!) はステートレスに実行できます。ただし、ステートレス性にあまり依存したくないという議論もあり、最終的には Ethereum を分散化するために状態を期限切れにしたいと考えるかもしれません。

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

現在、新しい状態オブジェクトを作成すると (次の 3 つの方法のいずれかで発生します: (i) ETH を新しいアカウントに送信する、(ii) コードを使用して新しいアカウントを作成する、(iii) 以前に変更されていないストレージスロットを設定する)、その状態オブジェクトは永久にその状態のままになります。代わりに、オブジェクトが時間の経過とともに自動的に期限切れになるようにします。重要な課題は、次の 3 つの目標を達成する方法でこれを実現することです。

効率: 有効期限プロセスを実行するために、大量の追加計算は必要ありません。
使いやすさ: 誰かが 5 年間洞窟に閉じこもってから戻ってきたとしても、ETH、ERC 20、NFT、CDP のポジションへのアクセスを失うことはありません。
開発者にとって使いやすい: 開発者は、まったく馴染みのないメンタルモデルに切り替える必要がありません。また、現在硬直化して更新されていないアプリケーションも、引き続き正常に動作するはずです。

これらの目標を満たさない問題を解決するのは簡単です。たとえば、各状態オブジェクトに有効期限カウンターも保存し (有効期限は ETH を燃やすことで延長でき、これは読み取りまたは書き込み時に自動的に実行できます)、状態をループして期限切れの状態オブジェクトを削除するプロセスを用意することができます。ただし、これにより追加の計算 (およびストレージ要件) が導入され、ユーザーフレンドリーの要件を確実に満たすことはできません。また、開発者が、保存された値がゼロにリセットされることがあるエッジケースについて推論することも困難です。有効期限タイマーを契約の範囲内で設定すると、開発者の作業は技術的に簡単になりますが、経済的には難しくなります。開発者は、継続的なストレージコストをユーザーに転嫁する方法を検討する必要があります。

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

部分的なステータスの有効期限切れの解決策
アドレスサイクルに基づいて状態の有効期限の推奨を設定します。

部分的な状態の有効期限

部分的な状態の有効期限の提案はすべて同じ原則に従います。状態をチャンクに分割します。各チャンクには、チャンクが空か空でないかのいずれかであるトップレベルのマップが永続的に保存されます。各チャンクのデータは、そのデータが最近アクセスされた場合にのみ保存されます。保存されなくなったチャンクを復活させる復活メカニズムがあります。

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

Vitalik の新しい記事: Ethereum (V) の将来可能性 — The Purge

同様のアイデアを実装する方法は他にもあります。たとえば、アカウントレベルの粒度が十分でない場合は、ツリーの各 1/2 32 部分が同様の幹と葉のメカニズムによって制御されるスキームを作成できます。

これはインセンティブがあるため、さらに難しくなります。攻撃者は、大量のデータを単一のサブツリーに配置し、毎年単一のトランザクションを送信してツリーを更新することで、クライアントに大量の状態を永続的に保存させることができます。更新コストをツリーのサイズに比例させる (または更新期間に反比例させる) と、誰かが大量のデータを同じサブツリーに配置することで、他のユーザーに損害を与える可能性があります。サブツリーのサイズに応じて粒度を動的にすることで、これらの問題の両方を制限できます。たとえば、連続する 216 = 65536 個の状態オブジェクトをそれぞれグループと見なすことができます。ただし、これらのアイデアはより複雑です。ステムベースのアプローチは単純で、通常、ステムの下にあるすべてのデータは同じアプリケーションまたはユーザーに関連しているため、インセンティブを調整できます。

アドレスサイクルに基づく状態の有効期限の推奨事項

32バイトのスタブであっても、永続的な状態の増加を回避したい場合はどうすればよいでしょうか。これは難しい問題です。復活の争い : 状態オブジェクトが削除され、その後 EVM 実行によってまったく同じ場所に別の状態オブジェクトが配置されたが、その後元の状態オブジェクトに関心のある人が戻ってきてそれを復元しようとした場合はどうなりますか? 状態の一部が期限切れになると、スタブは新しいデータの作成を防止します。状態が完全に期限切れになると、スタブを保存することさえできなくなります。

アドレスサイクルベースの設計は、この問題を解決するための最もよく知られたアイデアです。1 つの状態ツリーに状態全体を格納する代わりに、状態ツリーのリストが拡大し、読み書きされた状態はすべて最新の状態ツリーに保存されます。新しい空の状態ツリーは、エポック (例: 1 年) ごとに 1 回追加されます。古いツリーは固定されています。フルノードには、最新の 2 つのツリーのみが格納されます。状態オブジェクトが 2 つのエポックで変更されず、期限切れのツリーに含まれる場合、そのオブジェクトは引き続き読み書きできますが、トランザクションは Merkle 証明を証明する必要があります。証明されると、コピーが最新のツリーに再度保存されます。

Vitalik の新しい記事: Ethereum (V) の将来可能性 — The Purge

これをユーザーや開発者に優しいものにする重要なアイデアは、アドレス期間の概念です。アドレス期間とは、アドレスの一部である数字です。重要なルールは、アドレス期間 N のアドレスは、期間 N 中または期間 N 以降 (つまり、状態ツリーリストが長さ N に達したとき) にのみ読み取りまたは書き込みができるということです。新しい状態オブジェクト (新しいコントラクト、または新しい ERC 20 残高など) を保存する場合、状態オブジェクトをアドレス期間 N または N-1 のコントラクトに配置すると、以前に何もなかったことを証明する必要なく、すぐに保存できます。一方、古いアドレス期間中に行われた追加や編集には、証明が必要になります。

この設計は、Ethereum の現在の特性のほとんどを保持し、追加の計算を必要とせず、アプリケーションをほぼ現状のまま記述できます (アドレスサイクル N のアドレスバランスが、アドレスサイクル N を持つサブコントラクトに格納されるように ERC 20 を書き直す必要があります)。また、ユーザーが 5 年間洞窟内に留まる問題を解決します。ただし、大きな問題があります。アドレスサイクルに対応するには、アドレスを 20 バイト以上に拡張する必要があります。

アドレス空間拡張

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

0x 01 （赤）0000 （オレンジ）000001 （緑）57 え 408398 dF 7 え 5 ふ 4552091 あ 69125 d5 FWf 7 B 8 Ｃ 2659029395 bdF（青）。

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

ここでの主な課題は、下位互換性です。既存のコントラクトは 20 バイトのアドレスを中心に設計されており、アドレスが正確に 20 バイトの長さであると明示的に想定する厳密なバイトパッキング手法を使用することがよくあります。これを解決する一つのアイデア変換マッピングが含まれ、新しいスタイルのアドレスとやり取りする従来の契約では、新しいスタイルのアドレスの 20 バイトのハッシュが表示されます。ただし、これが安全であることを保証するには、かなりの複雑さがあります。

アドレス空間の縮小

もう 1 つのアプローチは逆の方向に進みます。サイズ 2 128 のサブ範囲 (たとえば、 0x ffffffff で始まるすべてのアドレス) を直ちに禁止し、その範囲を使用して、アドレスサイクルと 14 バイトのハッシュ値を持つアドレスを導入します。

0x ふぅふぅ 000169125 d5 FWf 7 B 8 C2659029395bdF

このアプローチによって犠牲になる主なものは反事実的アドレスを導入することによるセキュリティリスク : 資産または権限を保持しているが、コードがまだチェーンに公開されていないアドレス。リスクは、誰かが (まだ公開されていない) コードを所有していると主張するアドレスを作成し、同じアドレスにハッシュされる別の有効なコードも持っていることです。現在、このような衝突を計算するには 2 80 ハッシュが必要ですが、アドレス空間の縮小により、この数は簡単にアクセスできる 2 56 ハッシュに減少します。

主要なリスク領域である、単一の所有者によって保持されていないウォレットの反事実的アドレスは、現在では比較的まれですが、マルチ L2 の世界に移行すると、より一般的になる可能性があります。唯一の解決策は、このリスクを単純に受け入れる一方で、問題が発生する可能性のある一般的な使用例をすべて特定し、効果的な回避策を考え出すことです。

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

初期の提案

部分的なステータスの有効期限の提案

EIP-7736 ;

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

他に何を行う必要があり、どのようなトレードオフを行う必要があるのでしょうか?

今後の道筋としては、次の 4 つが考えられます。

私たちはステートレスにし、ステートの有効期限を導入しません。ステートは成長していますが (ゆっくりではありますが: おそらく今後数十年は 8 TB を超えることはないでしょう)、比較的特殊なクラスのユーザーによってのみ成長しています。PoS バリデーターでさえステートを必要としません。
状態の一部へのアクセスを必要とする機能の 1 つは包含リストの生成ですが、これは分散型の方法で実行できます。各ユーザーは、自分のアカウントを含む状態トライの部分を維持する責任があります。トランザクションをブロードキャストすると、検証ステップ中にアクセスされた状態オブジェクトの証明とともにトランザクションがブロードキャストされます (これは EOA アカウントと ERC-4337 アカウントの両方で機能します)。その後、ステートレスバリデーターは、これらの証明を組み合わせて包含リスト全体の証明を作成できます。
部分的な状態の有効期限を実行し、はるかに低いが、依然としてゼロではない永続的な状態サイズの増加率を受け入れます。この結果は、ピアツーピアネットワークを含む履歴有効期限の提案が、各クライアントが低いが固定の割合の履歴データを保存する必要がある、はるかに低いが、依然としてゼロではない永続的な履歴ストレージの増加率を受け入れる方法とほぼ同様です。
私たちは、アドレス空間の拡張を通じて状態の有効期限を設定しています。これには、既存のアプリケーションを含め、アドレス形式の変換方法が効果的かつ安全であることを確認するための複数年にわたるプロセスが含まれます。
アドレス空間を縮小することで状態の有効期限切れを実行します。これには、アドレス競合 (クロスチェーン状況を含む) に関連するすべてのセキュリティリスクが確実に処理されるように、数年にわたるプロセスが必要になります。

重要な点は、アドレス形式の変更に依存する状態有効期限スキームが実装されるかどうかにかかわらず、アドレス空間の拡大と縮小という難しい問題は最終的に解決されなければならないということです。現在、アドレス衝突を生成するには約2 80 ハッシュが必要ですが、この計算負荷は、非常にリソースの豊富なアクターにとっては既に実現可能です。GPUは約2 27 ハッシュを実行できるため、1年間で2 52 を計算できます。世界に約230台のGPU 衝突を約 1/4 年で計算することができ、FPGA と ASIC はこのプロセスをさらに加速できます。将来的には、このような攻撃はますます多くの人々に公開されるようになります。したがって、完全な状態の有効期限を実装するための実際のコストは、見た目ほど高くない可能性があります。なぜなら、いずれにしてもこの非常に困難なアドレス問題を解決しなければならないからです。

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

状態の有効期限を設定すると、変換プロセスが不要になるため、ある状態トライ形式から別の状態トライ形式への移行が容易になります。新しい形式で新しいツリーを作成し、ハードフォークを実行して古いツリーを変換するだけです。したがって、状態の有効期限は複雑ですが、ロードマップの他の側面を簡素化できるという利点があります。

機能のクリーンアップ

それはどんな問題を解決するのでしょうか?

重要な前提条件の1つはセキュリティ、アクセシビリティ、信頼できる中立シンプルさです。プロトコルが美しくシンプルであれば、バグが発生する可能性は低くなります。新しい開発者がプロトコルのどの部分でも参加できる可能性が高まります。公平になる可能性が高く、特定の利益に対する防御が容易になります。残念ながら、プロトコルは、他の社会システムと同様に、時間の経過とともにデフォルトで複雑になります。Ethereum が複雑さの増大というブラックホールに陥らないようにするには、次の 2 つのいずれかを行う必要があります。(i) 変更をやめてプロトコルを硬直化させる、または (ii) 実際に機能を削除して複雑さを軽減できるようにする。中間の道も可能です。プロトコルへの変更を減らし、時間の経過とともに少なくとも少しの複雑さを排除します。このセクションでは、複雑さを軽減または排除する方法について説明します。

それは何であり、どのように機能するのでしょうか?

プロトコルの複雑さを軽減する単一の大きな修正はありません。問題の本質は、小さな修正が多数あることです。

ほぼ完成しており、他の例への取り組み方の青写真として役立つ例が1つあります。 SELFDESTRUCT オペコードの削除 SELFDESTRUCT オペコードは、1 つのブロック内のストレージスロットを無制限に変更できる唯一のオペコードであり、DoS 攻撃を回避するためにクライアントがはるかに複雑な実装を行う必要がありました。オペコードの本来の目的は、自発的な状態の清算を可能にし、時間の経過とともに状態のサイズを縮小できるようにすることでした。実際には、それを使用する人はほとんどいませんでした。オペコードが弱体化された Dencun ハードフォークと同じトランザクションで作成された自己破壊アカウントのみを許可するようにしました。これにより、DoS 問題が解決され、クライアントコードが大幅に簡素化されます。将来的には、オペコードを完全に削除することが合理的になる可能性があります。

これまでに特定されたプロトコル簡素化の機会の主な例には、次のものがあります。まず、EVM 以外の例です。これらは比較的非侵襲的であるため、合意に達しやすく、より短時間で実装できます。

RLP → SSZ変換: 元々、Ethereumオブジェクトは、 RLP RLPは型付けされておらず、不必要に複雑です。現在、ビーコンチェーンは SSZ これは、シリアル化だけでなくハッシュ化もサポートするなど、多くの点で大幅に優れています。最終的には、RLPを完全に排除し、すべてのデータ型をSSZ構造に移行したいと考えています。これにより、アップグレードがはるかに簡単になります。現在のEIPには以下が含まれます。 [1] [2] [3] .
レガシートランザクションタイプの削除: 現在、トランザクションタイプが多すぎるため、その多くは削除される可能性があります。完全な削除のより控えめな代替手段は、アカウント抽象化機能です。これにより、スマートアカウントには、必要に応じてレガシートランザクションを処理および検証するコードを含めることができます。
ログ改革: ログ作成ブルームフィルタやその他のロジックはプロトコルに複雑さを追加しますが、遅すぎるためクライアントでは実際には使用されません。これらの機能を削除する SNARK などの最新技術を使用したプロトコル外の分散ログ読み取りツールなどの代替手段に取り組みます。
最終的に、ビーコンチェーン同期委員会のメカニズムを削除します。同期委員会の仕組み当初はイーサリアムの軽量クライアント検証を可能にするために導入されました。しかし、プロトコルの複雑さが大幅に増加しました。最終的には、 SNARKを使用してEthereumコンセンサスレイヤーを直接検証するこれにより、専用の軽量クライアント検証プロトコルが不要になります。潜在的には、コンセンサスの変更により、Ethereum コンセンサス検証者のランダムなサブセットからの署名を検証する、よりネイティブな軽量クライアントプロトコルを作成することで、同期委員会を早期に削除できる可能性があります。
データ形式の統一: 現在、実行状態はMerkle Patriciaツリーに保存され、コンセンサス状態は SSZツリー、そしてブロブは KZGのコミットメント将来的には、ブロックデータと状態の両方に単一の統一フォーマットを用意することが合理的です。これらのフォーマットは、(i) ステートレスクライアントのシンプルな証明、(ii) データのシリアル化と消去コーディング、(iii) 標準化されたデータ構造など、すべての重要な要件を満たすことになります。
ビーコンチェーン委員会の削除: このメカニズムはもともとサポートするために導入されました実行シャーディングの特定のバージョン代わりに、私たちはシャーディングをしました L2とブロブ経由 . そのため、委員会は不要であり、それを排除する動きが起こっている .
混合エンディアンを排除: EVM はビッグエンディアン、コンセンサスレイヤーはリトルエンディアンです。すべてをいずれかの方法で調整して、他の方法で調整することは理にかなっている可能性があります (EVM は変更が難しいため、おそらくビッグエンディアン)

次に、EVM のいくつかの例を示します。

ガスメカニズムの簡素化: 現在のガスルールは、ブロックの検証に必要なリソースの量に明確な制限を与えるように最適化されていません。主な例としては、(i) ブロック内の読み取り/書き込み回数を制限することを意図しているが、現在はかなり恣意的であるストレージ読み取り/書き込みコスト、(ii) EVM の最大メモリ消費量を見積もることが現在難しいメモリパディングルールなどがあります。提案されている修正には、次のものがあります。ステートレスなガスコストの変更（ストレージ関連のコストをすべて単純な式に統合）メモリ価格提案 .
プリコンパイルの削除: 現在 Ethereum が備えているプリコンパイルの多くは、不必要に複雑で、比較的使用されていないため、アプリケーションでほとんど使用されていない場合にコンセンサスエラーの大部分を占めています。これに対処するには、(i) プリコンパイルを単純に削除するか、(ii) 同じロジックを実装する (必然的にコストが高くなる) EVM コードに置き換えるという 2 つの方法があります。このEIP草案では、最初のステップとして、アイデンティティプリコンパイルに対してこれを実行します。その後、RIPEMD 160、MODEXP、および BLAKE が削除の候補になる可能性があります。
ガスの観測可能性を削除: EVM実行時にガスの残量を確認できないようにします。これにより、一部のアプリケーション(特にスポンサー付きトランザクション)が機能しなくなりますが、将来的にアップグレードしやすくなります(たとえば、多次元ガス ). EOF仕様すでにガスを観測不可能にしていますが、プロトコルを簡素化するために、EOF を必須にする必要があります。
静的解析の改善: EVM コードは、特にジャンプが動的になる可能性があるため、現在では静的解析が困難です。これにより、EVM 実装の最適化 (EVM コードを他の言語にプリコンパイルする) も困難になります。これを修正するには、ダイナミックジャンプの削除 (または、より高価にする、たとえば、コントラクト内の JUMPDEST の合計数に応じてガスコストが線形になる)。EOF はまさにそれを行いますが、プロトコルの簡素化のメリットを得るには EOF を強制する必要があります。

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

削除の次のステップ ;
自爆
SSZ ベースの EIPS: [1] [2] [3] ;
ステートレスガスコストの変更 ;
リニアメモリ価格設定 ;
プリコンパイルされた削除 ;
ブルームフィルターを削除 ;
増分検証計算を使用したオフチェーンの安全なログ取得方法（再帰的 STARK と読みます）

他に何を行う必要があり、どのようなトレードオフを行う必要があるのでしょうか?

こうした機能の簡素化を行う際の主なトレードオフは、(i) 簡素化の量と速度と (ii) 後方互換性です。イーサリアムのチェーンとしての価値は、アプリケーションを展開して数年後も機能することを確信できるプラットフォームであることにあります。同時に、この理想は行き過ぎてしまうこともあり、ウィリアム・ジェニングス・ブライアンの言葉を借りれば「イーサリアムを下位互換性の十字架に釘付けにする」。イーサリアム全体で特定の機能を使用するアプリケーションが 2 つしかなく、1 つのアプリケーションが何年もユーザーゼロで、もう 1 つのアプリケーションはほとんど使用されず、合計 $57 の価値を獲得している場合、その機能を削除し、必要に応じて被害者に $57 を自腹で支払う必要があります。

より広範な社会問題は、緊急性がなく、下位互換性を壊す変更を行うための標準化されたパイプラインを作成することです。これに対処する 1 つの方法は、自己破壊プロセスなどの既存の前例を調査して拡張することです。パイプラインは次のようになります。

機能 X の削除について話し始めます。
X を削除した場合の申請への影響を判断するための分析を実施し、その結果に応じて、(i) アイデアを放棄する、(ii) 計画どおりに進める、または (iii) X を削除して続行するための修正された「最も混乱の少ない」アプローチを決定する。
X を非推奨にする正式な EIP を作成します。一般的な上位レベルのインフラストラクチャ (プログラミング言語、ウォレットなど) がこれを尊重し、機能の使用を停止することを確認します。;
最後に、実際に X を削除します。

ステップ 1 と 4 の間には、どのプロジェクトがどのステップにあるかが明確に示された、複数年にわたるパイプラインが必要です。この時点では、機能削除プロセスの活発さとスピードと、より保守的になってプロトコル開発の他の領域にリソースをもっと投資することの間にトレードオフがありますが、私たちはまだパレート限界からは程遠い状態です。

終了

EVMに提案された主な変更点は次のとおりです。 EVM オブジェクトフォーマット (EOF) EOF では、ガス可観測性、コード可観測性 (CODECOPY なし) の無効化、静的ジャンプのみの許可など、多くの変更が導入されています。目標は、下位互換性を維持しながら、EVM をより強力なプロパティでアップグレードできるようにすることです (EOF 以前の EVM がまだ存在するため)。

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

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

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

シングルスロットファイナリティに切り替えることで、委員会を廃止し、経済性を再設計し、その他のプルーフオブステーク関連の簡素化を行う機会が得られます。
アカウント抽象化を完全に実装することで、既存のトランザクション処理ロジックの多くを削除し、すべての EOA が置き換えることができる「デフォルトのアカウント EVM コード」に移行できるようになります。
Ethereum の状態をバイナリハッシュツリーに移行すると、新しいバージョンの SSZ と調和して、すべての Ethereum データ構造を同じ方法でハッシュできるようになります。

より根本的なアプローチ：プロトコルの大部分を契約コードに変換する

Ethereum を簡素化するためのより根本的な戦略は、プロトコルをそのまま維持しながら、その大部分をプロトコル機能からコントラクトコードに移動することです。

最も極端なバージョンは、イーサリアムL1を「技術的に」ビーコンチェーンだけとし、最小限の仮想マシン（例： RISC-V , カイロ、または証明システムに特化したさらに最小限のもの）で、他の人が独自のロールアップを作成できるようにします。EVMは、これらのロールアップの最初のものになります。皮肉なことに、これは 2019-20年実行環境提案ただし、SNARK を使用すると、実際に実装することがより実現可能になります。

Vitalik の新しい記事: Ethereum (V) の将来可能性 — The Purge

より控えめなアプローチとしては、ビーコンチェーンと現在の Ethereum 実行環境の関係は変更せずに、EVM をその場で交換する方法があります。RISC-V、Cairo、または別の VM を新しい公式 Ethereum VM として選択し、すべての EVM コントラクトを、元のコードのロジックを解釈する新しい VM コードに強制的に変換することができます (コンパイルまたは解釈のいずれかによって)。理論的には、ターゲット仮想マシンが EOF のバージョンであっても、これを実行できます。

この記事はインターネットから引用したものです: Vitalik の新しい記事: Ethereum (V) の将来可能性 — The Purge