著者: ヴィタリック・ブテリン
コンパイラー：Odaily Planet Dailyの夫はどうですか？
10月14日以来、イーサリアムの創設者ヴィタリック・ブテリン氏は、「The Merge」、「The Surge」、「The Scourge」、「The Verge」から最新リリースの「The 「パージ」は、イーサリアムメインネットの将来の発展に対するヴィタリックのビジョンと、現在直面している問題を解決する方法を示しています。
「ザ・マージ」: イーサリアムが単一スロットのファイナリティを向上させ、PoS に移行した後にプレッジしきい値を下げて、参加とトランザクション確認の速度を向上させる必要性について議論しました。
「The Surge」: イーサリアム拡張のためのさまざまな戦略、特にロールアップ中心のロードマップと、スケーラビリティ、分散化、セキュリティにおける課題と解決策を探ります。
「The Scourge」: PoS への移行においてイーサリアムが直面する集中化と価値抽出のリスクについて議論し、ユーザーの利益を保護するためにステーキング経済改革を実行しながら、分散化と公平性を強化するためのさまざまなメカニズムを開発しました。
「The Verge」: Verkle ツリーや STARK などのテクノロジーがブロックチェーンの分散化と効率をどのように強化できるかに焦点を当て、イーサリアムのステートレス検証の課題と解決策について議論しました。
10 月 26 日、Vitalik Buterin 氏は「The Purge」に関する記事を公開し、イーサリアムが直面する課題は、チェーンの耐久性と分散化を維持しながら、長期的に複雑さとストレージ要件を軽減することであると論じました。 「履歴の有効期限」と「状態の有効期限」によって負荷を軽減し、「機能のクリーニング」によってプロトコルを簡素化し、ネットワークの持続性と拡張性を確保します。
以下は Odaily Planet Daily が編集したオリジナルのコンテンツです。
フィードバックとレビューをくださった Justin Drake、Tim Beiko、Matt Garnett、Piper Merriam、Marius van der Wijden、Tomasz Stanczak に心より感謝いたします。
イーサリアムが直面している課題の 1 つは、デフォルトでは、ブロックチェーン プロトコルの肥大化と複雑さが時間の経過とともに増大することです。これは次の 2 つの場所で発生します。
履歴データ: 履歴の任意の時点で行われたトランザクションと作成されたアカウントは、すべてのクライアントによって永続的に保存され、新しいクライアントによってダウンロードされる必要があるため、ネットワークに完全に同期されます。これにより、チェーンの容量が一定であっても、クライアントの負荷と同期時間が時間の経過とともに増加します。
プロトコルの機能: 古い機能を削除するよりも新しい機能を追加する方がはるかに簡単なので、時間の経過とともにコードの複雑さが増加します。
イーサリアムが長期的に維持されるためには、時間の経過とともに複雑さと肥大化を軽減し、両方のトレンドに対する強力な対抗圧力が必要です。しかし同時に、ブロックチェーンを優れたものにする重要な属性の 1 つである永続性も維持する必要があります。 NFT、トランザクションコールデータ内のラブレター、または100万ドルを含むスマートコントラクトをチェーンに置き、10年間洞窟に入り、出てくると、それがまだそこにあり、読んで操作するのを待っていることがわかります。 DApps が完全に分散化されてアップグレード キーを削除することに安心するには、依存関係、特に L1 自体が壊れるような方法でアップグレードされないことを確信する必要があります。
これら 2 つのニーズのバランスをとり、継続性を維持しながら、肥大化、複雑さ、衰退を最小限に抑えるか逆転させると決意すれば、それは絶対に可能です。生物はこれを行うことができます。ほとんどの生物は時間の経過とともに老化しますが、幸運な少数の生物は老化しません。社会システムであっても寿命が非常に長い場合があります。場合によっては、イーサリアムが成功しました。プルーフ・オブ・ワークはなくなり、SELFDESTRUCT オペコードはほとんどなくなり、ビーコン チェーン ノードには最大 6 か月分の古いデータが保存されています。より一般的な方法でイーサリアムのこの道を見つけ、長期的な安定性という最終結果に向かって進むことは、イーサリアムの長期的なスケーラビリティ、技術的持続可能性、さらにはセキュリティにとっての究極の課題です。
パージ: 主な目標。
各ノードがすべての履歴や最終状態を永続的に保存する必要性を減らすか排除することで、クライアントのストレージ要件を軽減します。
不要な機能を排除することでプロトコルの複雑さを軽減します。
記事ディレクトリ:
履歴の有効期限が切れました
状態の有効期限
機能のクリーンアップ
履歴の有効期限
どのような問題が解決されましたか?
この記事の執筆時点では、完全に同期された Ethereum ノードには、実行クライアント用に約 1.1 TB のディスク領域が必要で、コンセンサス クライアント用にさらに数百 GB のディスク領域が必要です。その大部分は歴史的なものであり、過去のブロック、トランザクション、領収書に関するデータであり、その多くは何年も前のものです。これは、たとえガス制限がまったく増加しなくても、ノードのサイズは毎年数百 GB ずつ増加し続けることを意味します。
それは何ですか?またどのように機能しますか?
履歴ストレージ問題を単純化する重要な特徴は、各ブロックがハッシュ リンク (およびその他の構造) を介して前のブロックを指しているため、履歴に関する合意を達成するには現在に関する合意で十分であることです。ネットワークが最新のブロックについてコンセンサスに達している限り、過去のブロック、トランザクション、または状態 (アカウント残高、ノンス、コード、ストレージ) は、単一の参加者によってマークル証明を提供され、その証明により他の人がそれを検証できるようになります。正しさ。コンセンサスは N/2-of-N 信頼モデルですが、ヒストリは N-of-N 信頼モデルです。
これにより、履歴を保存する方法について多くのオプションが得られます。自然な選択は、各ノードがデータのごく一部のみを保存するネットワークです。これが何十年もの間、トレント ネットワークがどのように機能してきたかです。ネットワークは合計数百万のファイルを保存および配布しますが、各参加者はそのうちの数ファイルを保存および配布するだけです。おそらく直観に反するかもしれませんが、このアプローチは必ずしもデータの堅牢性を低下させるわけではありません。ノードの実行をより経済的にすることで、各ノードが履歴のランダムな 10% を保存する 100,000 ノードのネットワークを構築できた場合、各データは 10,000 回複製されます。これは、10,000 ノードとまったく同じ複製係数です。 - ノードのネットワーク。各ノードにはすべてが保存されます。
現在、イーサリアムは、すべての履歴を永続的に保存するすべてのノードのモデルから脱却し始めています。コンセンサスブロック（つまり、プルーフ・オブ・ステークのコンセンサスに関連する部分）は、約 6 か月間のみ保存されます。 BLOB は約 18 日間のみ保存されます。 EIP-4444 は、履歴ブロックとレシートに 1 年間の保存期間を導入することを目的としています。長期的な目標は、各ノードがすべてを保存する責任を負う統一期間 (おそらく約 18 日) を確立し、その後、分散ネットワーク方式で古いデータを保存するためのイーサリアム ノードのピアツーピア ネットワークを確立することです。
イレイジャー コードを使用すると、複製係数を同じに保ちながら堅牢性を高めることができます。実際、BLOB はデータ可用性サンプリングをサポートするためにすでに消去コーディングされています。最も簡単な解決策は、おそらく、そのような消去コードを再利用し、実行ブロック データとコンセンサス ブロック データも BLOB に入れることです。
既存の研究とのつながりは何ですか?
EIP-4444;
トレントと EIP-4444;
ポータルネットワーク。
ポータル ネットワークと EIP-4444;
ポータルでの SSZ オブジェクトの分散ストレージと取得。
ガス制限を増やす方法 (パラダイム)。
他に何をする必要があるか、どのようなトレードオフを行う必要があるか?
残りの主な作業は、履歴 (少なくとも実行履歴、最終的にはコンセンサスや BLOB も含む) を保存するための具体的な分散ソリューションの構築と統合で構成されます。最も単純なソリューションは、(i) 単純に既存のトレント ライブラリを導入すること、および (ii) ポータル ネットワークと呼ばれるイーサリアム ネイティブ ソリューションです。これらのいずれかが導入されると、EIP-4444 を開くことができます。 EIP-4444 自体はハード フォークを必要としませんが、新しいネットワーク プロトコル バージョンが必要です。したがって、すべてのクライアントに対して同時に有効にすることには価値があります。そうしないと、クライアントが他のノードに接続して完全な履歴をダウンロードすることを期待していても実際には取得できないため、失敗するリスクがあります。
主なトレードオフは、「古代」の履歴データを提供する方法に関係します。最も簡単な解決策は、明日から古代の歴史を保存するのをやめ、既存のアーカイブ ノードとさまざまな集中プロバイダーにレプリケーションを依存することです。それは簡単ですが、永久的な記録の場所としてのイーサリアムの地位を弱体化させます。より困難ですがより安全な方法は、まずトレント ネットワークを構築して統合し、分散方式で履歴を保存することです。ここで、「どれだけ努力するか」には 2 つの側面があります。
最大のノード セットに実際にすべてのデータが格納されていることを確認するにはどうすればよいでしょうか?
履歴ストレージをプロトコルにどの程度深く統合しますか?
(1) に対する極めて偏執的なアプローチには、プルーフ・オブ・エスクローが含まれます。これは、各プルーフ・オブ・ステークのバリデーターに一定の割合の履歴を保存し、定期的に保存していることを暗号的にチェックすることを事実上要求するものです。より控えめなアプローチは、各クライアントが保存する履歴の割合について自主基準を設定することです。
(2) については、基本的な実装には今日完了した作業のみが含まれます。ポータルには、イーサリアムの全履歴を含む ERA ファイルがすでに保存されています。より完全な実装には、実際に同期プロセスに接続することが含まれます。これにより、完全な履歴ストレージ ノードまたはアーカイブ ノードを同期したい場合、他のアーカイブ ノードが存在しない場合でも、ポータル ネットワークから直接同期することができます。オンライン。
ロードマップの他の部分とどのように相互作用するのでしょうか?
ノードの実行または起動を非常に簡単にしたい場合は、ステートレスであることよりも、履歴ストレージ要件を削減することの方がおそらく重要です。ノードに必要な 1.1 TB のうち、~300 GB が状態であり、残りの ~800 GB が履歴です。ステートレス性と EIP-4444 を実装することによってのみ、スマート ウォッチ上でイーサリアム ノードを実行し、セットアップにわずか数分しかかからないというビジョンを実現できます。
また、履歴ストレージを制限すると、新しいイーサリアム ノードの実装がプロトコルの最新バージョンのみをサポートすることがより実現可能になり、実装が簡素化されます。たとえば、2016 年の DoS 攻撃中に作成された空のストレージ スロットがすべて削除されたため、多くのコード行を安全に削除できるようになりました。 Proof-of-Stake への移行は過去のものとなり、お客様はすべての Proof-of-Work 関連コードを安全に削除できます。
状態の有効期限
どのような問題が解決されましたか?
たとえクライアントが履歴を保存する必要性を排除したとしても、アカウント残高とノンス、契約コード、契約ストレージなどの状態が増加し続けるにつれて、クライアントのストレージ要件は増加し続け、年間約 50 GB になります。ユーザーは一度限りの料金を支払うことができ、現在および将来のイーサリアム顧客に永続的な負担を強いることになります。
EVM は基本的に、一度作成された状態オブジェクトは常に存在し、いつでもどのトランザクションでも読み取ることができるという前提に基づいて設計されているため、状態は履歴よりも「期限切れ」になりにくいです。ステートレスを導入すれば、この問題はそれほど悪くないのではないかと主張する人もいます。実際に状態を保存する必要があるのは専用のブロック ビルダー クラスのみで、他のすべてのノード (リスト生成も!) はステートレスで実行できます。ただし、無国籍にあまり依存したくないという議論もあり、最終的にはイーサリアムの分散化を維持するために州を失効させたいと思うかもしれません。
それは何ですか、そしてそれはどのように機能しますか
現在、新しい状態オブジェクトを作成すると (これは、(i) 新しいアカウントに ETH を送信する、(ii) コードを使用して新しいアカウントを作成する、(iii) 以前に変更されていないストレージ スロットを設定する、の 3 つの方法のいずれかで発生します)、状態オブジェクトは常にこの状態にあります。代わりに、私たちが望んでいるのは、オブジェクトが時間の経過とともに自動的に期限切れになることです。重要な課題は、次の 3 つの目標を達成する方法でこれを行うことです。
効率: 有効期限切れプロセスを実行するために大規模な追加計算は必要ありません。
ユーザーフレンドリー: 誰かが 5 年間洞窟に入って戻ってきたとしても、ETH、ERC20、NFT、CDP ポジションへのアクセスを失うことはありません…
開発者への優しさ: 開発者は、まったく馴染みのないメンタル モデルに切り替える必要はありません。さらに、現在固化していて更新されていないアプリケーションは、引き続き正常に機能するはずです。
これらの目標を達成しないと、簡単に問題が発生する可能性があります。たとえば、各状態オブジェクトに有効期限カウンターも格納し (有効期限は ETH を書き込むことで延長でき、読み取りまたは書き込みが行われるたびに自動的に実行されます)、ループで状態を反復処理して削除することができます。有効期限のプロセスステータスオブジェクト。ただし、これにより追加の計算 (さらにはストレージ要件) が発生し、使いやすさの要件を確実に満たしていません。開発者にとって、保存された値がゼロにリセットされることがあるというエッジ ケースについて推論することも困難です。契約内で有効期限タイマーを設定すると、技術的には開発者の作業が楽になりますが、経済面ではより困難になります。開発者は、継続的なストレージ コストをユーザーに「転嫁」する方法を考えなければなりません。
これらは、「ブロックチェーンのレンタル」や「再生」などの提案を含め、イーサリアムコア開発コミュニティが長年取り組んできた問題です。最終的に、私たちは提案の最良の部分を結合し、「あまり知られていない最悪の解決策」の 2 つのカテゴリに焦点を当てました。
- 部分的なステータス有効期限切れソリューション
- アドレス期間に基づいて有効期限の推奨事項を説明します。
部分的な状態の有効期限部分的な状態の有効期限が切れる
部分的なステータスの有効期限の提案はすべて同じ原則に従います。状態をいくつかのチャンクに分割します。誰もが、空または空でないブロックの「トップレベルマップ」を永続的に保存します。各ブロック内のデータは、データが最近アクセスされた場合にのみ保存されます。保存されなくなった場合は「復活」メカニズムがあります
これらの提案の主な違いは、(i) 「最も近い」をどのように定義するか、(ii) 「チャンク」をどのように定義するか、です。具体的な提案の 1 つは EIP-7736 です。これは、Verkle ツリーに導入された「ステムリーフ」設計に基づいています (ただし、バイナリ ツリーなどのあらゆる形式のステートレス状態と互換性があります)。この設計では、互いに隣接するヘッダー、コード、およびスロットが同じ「トランク」の下に保管されます。ステムの下に保存できる最大データは 256 * 31 = 7,936 バイトです。多くの場合、アカウントのヘッダー全体とコードは、多くのキー ストレージ スロットと同様に、同じトランクの下に保存されます。特定のトランク内のデータが 6 か月間読み書きされなかった場合、そのデータは保存されなくなり、そのデータの 32 バイトのコミットメント (「スタブ」) のみが保存されます。このデータにアクセスする今後のトランザクションでは、データを「復活」させ、スタブに対する検査の証拠を提供する必要があります。
同様のアイデアを実装する他の方法もあります。たとえば、アカウント レベルの粒度が十分でない場合は、ツリーの 1/232 の各部分が同様の幹葉メカニズムによって制御されるスキームを開発できます。
これは、インセンティブによってさらに複雑になります。攻撃者は、大量のデータを 1 つのサブツリーに入れ、毎年 1 つのトランザクションを送信することで「ツリーを更新」し、クライアントに大量の状態を永続的に保存させることができます。更新コストをツリー サイズに比例 (または更新期間に反比例) すると、誰かが他のユーザーと同じサブツリーに大量のデータを入れて損害を与える可能性があります。サブツリーのサイズに応じて粒度を動的にすることで、両方の問題を制限することができます。たとえば、連続する 216 = 65536 個の状態オブジェクトをそれぞれ「グループ」とみなすことができます。ただし、これらのアイデアはより複雑です。ステムベースのアプローチはシンプルであり、通常はステム内のすべてのデータが同じアプリケーションまたはユーザーに関連しているため、インセンティブを調整できます。
アドレス期間に基づいた州の有効期限の推奨事項
たとえ 32 バイトのスタブであっても、永続的な状態の増加を完全に回避したい場合はどうすればよいでしょうか?復活の競合があるため、ここで難しい質問があります。1 つの状態オブジェクトが削除され、その後の EVM 実行により別の状態オブジェクトがまったく同じ場所に配置されたが、その後、元の状態オブジェクトを気にかける誰かが戻ってきて、それを復元しようとした場合はどうなるでしょうか。 「スタブ化」により、状態の一部が期限切れになったときに新しいデータが作成されなくなります。完全に期限切れの状態では半券を保管することもできません。
アドレス サイクル ベースの設計は、この問題を解決する最もよく知られたアイデアです。 1 つの状態ツリーに状態全体を保存する代わりに、状態ツリーのリストが増加し、読み書きされた状態はすべて最新の状態ツリーに保存されます。新しい空の状態ツリーは、期間 (例: 1 年) ごとに 1 回追加されます。古い木々は完全に凍っていました。フル ノードには、最も近い 2 つのツリーのみが保存されます。状態オブジェクトが 2 サイクルタッチされず、有効期限ツリーに分類された場合でも、読み取りまたは書き込みは可能ですが、トランザクションはマークル証明を証明する必要があります。証明されると、遅くともコピーが再度保存されます。木。
これをユーザーと開発者の両方にとって使いやすくするための重要なアイデアは、アドレス サイクルの概念です。アドレスピリオドは、アドレスの一部である数字です。重要なルールは、アドレス期間 N のアドレスは、期間 N の間または期間 N 以降 (つまり、状態ツリーのリストが長さ N に達したとき) にのみ読み書きできるということです。新しい状態オブジェクト (新しい契約や新しい ERC20 残高など) を保存する場合は、その状態オブジェクトをアドレス期間 N または N-1 の契約に入れるようにすれば、すぐに保存できます。以前は何もなかったという証拠を提示せずに。一方、旧住所期間中に行われた追加または編集には証明が必要です。
この設計は、イーサリアムの現在のプロパティのほとんどを保持しており、追加の計算を必要としないため、アプリケーションをほぼ現状と同じように作成できます (アドレス期間 N のアドレスバランスがサブコントラクトに保存されるようにするために、ERC20 を書き直す必要があります。サブコントラクト自体はアドレス期間 N です) ）「ユーザーが5年間洞窟に入る」という問題を解決します。ただし、これには大きな問題があります。アドレス サイクルに合わせてアドレスを 20 バイトを超えて拡張する必要があるということです。
アドレス空間の拡張アドレス空間の拡張
提案の 1 つは、バージョン番号、アドレス期間番号、および拡張ハッシュを含む新しい 32 バイトのアドレス形式を導入することです。
0x01 (赤) 0000 (オレンジ) 000001 (緑) 57aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF (青)。
赤いのはバージョン番号です。ここにある 4 つのオレンジ色のゼロは、将来シャード番号を収容できる空きスペースとなることを目的としています。緑色はアドレスサイクル番号です。青は 26 バイトのハッシュ値です。
ここでの重要な課題は下位互換性です。既存の契約は 20 バイトのアドレスを中心に設計されており、多くの場合、アドレスの長さがちょうど 20 バイトであることを明示的に想定して、厳密なバイト パッキング手法が使用されています。この問題を解決する 1 つのアイデアには、新しい形式のアドレスと対話する古い形式のコントラクトが新しい形式のアドレスの 20 バイトのハッシュを参照する変換マッピングが含まれます。ただし、そのセキュリティを確保するには非常に複雑な作業があります。
アドレス空間の縮小
もう 1 つのアプローチは逆の方向をとります。つまり、2128 サイズのアドレス サブ範囲 (たとえば、0xffffffff で始まるすべてのアドレス) を直ちに禁止し、その範囲を使用してアドレス サイクルと 14 バイト ハッシュを含むアドレスを導入します。
0xffffffff000169125d5dFcb7B8C2659029395bdF
このアプローチによって生じる主な犠牲は、事実に反するアドレス、つまり資産またはアクセス許可を保持しているがコードがまだチェーンに公開されていないアドレスによるセキュリティ リスクの導入です。このリスクには、（まだリリースされていない）コードの一部を所有していると主張するアドレスを作成する誰かが含まれますが、同じアドレスにハッシュされた別の有効なコードも存在します。現在、このような衝突を計算するには 280 個のハッシュが必要ですが、アドレス空間が縮小すると、この数は簡単にアクセスできる 256 個のハッシュに減ります。
主要なリスク領域である、複数の所有者が保有するウォレットの虚偽のアドレスは、現在では比較的まれですが、マルチ L2 の世界に移行するにつれて、より一般的になる可能性があります。唯一の解決策は、このリスクを単純に受け入れることですが、問題が発生する可能性のある一般的な使用例をすべて特定し、効果的な回避策を考え出すことです。
既存の研究とのつながりは何ですか?
早期提案
- ブロックチェーンのクリーニング;
- 再生;
- イーサリアムの状態サイズ管理理論。
- ステートレス状態と状態の期限切れに至る可能性のあるいくつかの経路。
部分的なステータスの有効期限が切れた提案
- EIP-7736;
アドレス空間拡張のドキュメント
- 当初の提案。
- イプシロンのレビュー;
- ブログ投稿のコメント;
- 衝突耐性がなくなったら何が壊れるのか。
他に何をする必要があるか、どのようなトレードオフを行う必要があるか?
私は、将来的には次の 4 つの道が考えられると考えています。
- 私たちはステートレスであり、ステートの有効期限を導入することはありません。状態は (ゆっくりとはいえ、おそらく数十年は 8 TB を超えることはないだろう) 成長していますが、それは比較的特殊なクラスのユーザーによってのみであり、PoS バリデーターでさえ状態を必要としません。ステータスの一部へのアクセスを必要とする機能の 1 つは包含リストの生成ですが、これは分散型の方法で実行できます。各ユーザーは、自分のアカウントを含むステータス ツリーの部分を保守する責任があります。トランザクションをブロードキャストするときは、検証ステップ中にアクセスされた状態オブジェクトの証明とともにトランザクションをブロードキャストします (これは EOA および ERC-4337 アカウントに適用されます)。ステートレス検証者は、これらの証明を組み合わせて、リスト全体を含む証明を作成できます。
- 部分的な状態の有効期限を実行し、はるかに低い、ただしゼロではない永続状態サイズの増加率を受け入れます。この結果はおそらく、ピアツーピア ネットワークに関係する履歴有効期限の提案が、各クライアントが低いが一定の割合の履歴データを保存する必要がある、はるかに低い、ただしゼロではない永久履歴ストレージの増加率を受け入れる方法とほぼ同じです。
- アドレス空間の拡張を通じて状態の有効期限を設定します。これには、既存のアプリケーションを含め、アドレス形式の変換方法が効果的かつ安全であることを確認するために、数年かかるプロセスが必要になります。
- アドレス空間の縮小を通じて状態の有効期限を実行します。これには、クロスチェーン状況を含むアドレス競合を含むすべてのセキュリティ リスクに確実に対処するための、複数年にわたるプロセスが必要となります。
重要な点は、アドレス形式の変更に依存する状態有効期限スキームが実装されるかどうかに関係なく、アドレス空間の拡張と縮小を取り巻く困難な問題に最終的には対処する必要があるということです。現在、アドレス衝突の生成には約 280 個のハッシュが必要であり、この計算負荷はリソースが非常に豊富なアクターにはすでに実行可能です。GPU は約 227 個のハッシュを実行できるため、1 年間の動作で 252 個のハッシュを計算することになります。つまり、世界では衝突を約 1/4 年で計算でき、FPGA と ASIC はこのプロセスをさらに加速できます。将来的には、このような攻撃はますます多くの人に開かれるようになるでしょう。したがって、この非常に困難なアドレス問題をとにかく解決する必要があるため、完全な状態の有効期限を実装する実際のコストは、思っているほど高くない可能性があります。
ロードマップの他の部分とどのように相互作用するのでしょうか?
状態の有効期限を設定すると、変換プロセスが必要ないため、ある状態ツリー形式から別の状態ツリー形式への変換が容易になります。新しい形式で新しいツリーの作成を開始し、ハード フォークして古いツリーを変換するだけで済みます。したがって、ステータスの有効期限は複雑ですが、ロードマップの他の側面を簡素化するという利点もあります。
機能のクリーンアップ
それはどのような問題を解決しますか?
セキュリティ、アクセシビリティ、信頼できる中立性の重要な前提条件の 1 つは、シンプルさです。プロトコルが美しくシンプルであれば、エラーが発生する可能性は低くなります。新しい開発者がその一部に参加できる可能性が高まります。それは公平である可能性が高く、特別な利益に対して抵抗力が強いです。残念ながら、他の社会システムと同様に、デフォルトではプロトコルも時間の経過とともにより複雑になります。イーサリアムが複雑さを増すブラックホールに陥ることを望まない場合は、次の 2 つのうちの 1 つを行う必要があります: (i) 変更をやめてプロトコルを硬直化する、(ii) 実際に機能を削除して複雑さを軽減できる。プロトコルへの変更を少なくし、時間の経過とともに少なくとも多少の複雑さを排除する中間のパスも可能です。このセクションでは、複雑さを軽減または排除する方法について説明します。
それは何ですか?またどのように機能しますか?
プロトコルの複雑さを軽減できる単一の大きな修正はなく、問題の性質として、小さな解決策が多数存在します。
すでにほぼ完成している例の 1 つは SELFDESTRUCT オペコードの削除であり、他の例にアプローチする方法の青写真として機能します。 SELFDESTRUCT オペコードは、単一ブロック内のストレージ スロットを無制限に変更できる唯一のオペコードであり、クライアントは DoS 攻撃を回避するために非常に複雑な実装を必要とします。このオペコードの本来の目的は、自発的な国家清算を可能にして、国家の規模を時間の経過とともに縮小できるようにすることでした。実際、それを使いこなす人はほとんどいません。オペコードは、Dencun ハード フォークと同じトランザクションで作成された自己破壊的なアカウントのみを許可するように弱体化されました。これにより、DoS 問題が解決され、クライアント コードが大幅に簡素化されます。将来的には、最終的にはオペコードを完全に削除することが合理的になる可能性があります。
これまでに確認されているプロトコル簡素化の機会の主な例には、次のようなものがあります。まず、EVM 以外のいくつかの例です。これらは比較的非侵襲的であるため、合意形成が容易で、短期間で実装できます。
RLP → SSZ 変換: 当初、イーサリアム オブジェクトは RLP と呼ばれるエンコーディングを使用してシリアル化されました。 RLP は型がなく、不必要に複雑です。現在、ビーコン チェーンは SSZ を使用しています。これは、シリアル化だけでなくハッシュもサポートするなど、多くの点で大幅に優れています。最終的には、RLP を完全に削除し、すべてのデータ タイプを SSZ 構造に移動し、アップグレードが容易になることを期待しています。現在の EIP には [1][2][3] が含まれます。
古いトランザクション タイプの削除: 現在、トランザクション タイプが多すぎるため、その多くが削除される可能性があります。完全な削除に代わる穏やかな代替手段は、アカウントの抽象化機能です。これにより、スマート アカウントには、必要に応じてレガシー トランザクションを処理および検証するためのコードを含めることができます。
ログの改革: ログは、プロトコルの複雑さを増すブルーム フィルターやその他のロジックを作成しますが、遅すぎるため、実際にはクライアントによって使用されません。これらの機能を削除し、代わりに SNARK のような最新のテクノロジーを使用したオフプロトコルの分散ログ読み取りツールなどの代替手段に取り組むことができます。
ビーコン チェーン同期委員会メカニズムがついに削除されました: 同期委員会メカニズムは元々、イーサリアムのライト クライアント検証を可能にするために導入されました。ただし、プロトコルの複雑さが大幅に増加します。最終的には、SNARK を使用してイーサリアム コンセンサス層を直接検証できるようになり、専用のライト クライアント検証プロトコルが不要になります。潜在的には、コンセンサスを変更することで、イーサリアム コンセンサス検証者のランダムなサブセットからの署名を検証する、より「ネイティブ」なライト クライアント プロトコルを作成することで、同期委員会を早期に削除できる可能性があります。
統一されたデータ形式: 現在、実行状態はマークル パトリシア ツリーに保存され、コンセンサス状態は SSZ ツリーに保存され、BLOB は KZG コミットメントを介してコミットされます。将来的には、ブロック データに対して単一の統一フォーマットを使用し、状態に対して単一の統一フォーマットを使用することが合理的になるでしょう。これらの形式は、(i) ステートレス クライアントの単純な証明、(ii) データのシリアル化と消去コーディング、(iii) 標準化されたデータ構造という重要な要件をすべて満たします。
ビーコンチェーン委員会の削除: このメカニズムは元々、実行シャーディングの特定のバージョンをサポートするために導入されました。代わりに、L2 と BLOB を介してシャーディングすることになります。したがって、委員会は不必要であり、廃止するための措置が講じられています。
混合エンディアンを削除: EVM はビッグ エンディアンで、コンセンサス レイヤーはリトル エンディアンです。すべてを再調整して何らかの方法で作成することは理にかなっているかもしれません（EVMは変更するのが難しいため、おそらくビッグエンディアンです）
次に、EVM の例をいくつか示します。
Gas メカニズムの簡素化: 現在の Gas ルールは十分に最適化されておらず、ブロックの検証に必要なリソースの数に明確な制限を与えることができません。この主な例としては、(i) ストレージの読み取り/書き込みコスト (ブロック内の読み取り/書き込みの数を制限するように設計されているが、現在は非常に任意である)、(ii) メモリ フィル ルール (現時点では最大値を見積もることが困難) が挙げられます。 EVM のメモリ消費量。修正案には、ストレージ関連のすべてのコストを単純な計算式に統合するステートレスなガスコストの変更と、メモリの価格提案が含まれます。
プリコンパイルを削除する: Ethereum が現在備えているプリコンパイルの多くは、不必要に複雑で比較的未使用であり、どのアプリケーションでもほとんど使用されていないにもかかわらず、コンセンサス失敗の大部分を構成しています。この問題に対処する 2 つの方法は、(i) プリコンパイルを単に削除する方法と、(ii) 同じロジックを実装する (必然的に高価な) EVM コードに置き換える方法です。 EIP 草案では、最初のステップとして ID のプリコンパイルのためにこれを実行することを推奨しています。その後、RIPEMD160、MODEXP、および BLAKE が削除の候補となる可能性があります。
ガスの可観測性を削除: EVM 実行でガスがどれだけ残っているかを確認できなくなります。これにより、一部のアプリケーション (特にスポンサー契約) が無効になりますが、将来のアップグレードが容易になります (次元間ガスのより高度なバージョンなど)。 EOF 仕様ではすでに Gas が観測不可能になっていますが、プロトコルを簡素化するには EOF を必須にする必要があります。
静的解析の改善: 今日の EVM コードは、特にジャンプが動的である可能性があるため、静的解析が困難です。これにより、EVM 実装の最適化 (EVM コードを他の言語にプリコンパイルする) も難しくなります。この問題は、動的ジャンプを削除することで解決できます (または、動的ジャンプをより高価にする、たとえば、コントラクト内の JUMPDEST の総数に対するガスコストを線形にするなど)。 EOF はまさにそれを行いますが、プロトコル簡素化によるメリットを得るには EOF を強制する必要があります。
既存の研究とのつながりは何ですか?
- クリーンアップの次のステップ。
- 自爆する
- SSZ-EIPS:[1][2][3];
- 国家を超えたガス料金の変化。
- リニアメモリ価格設定。
- プリコンパイルは削除されました。
- ブルームフィルターの除去。
- 増分検証可能な計算 (再帰的 STARK と読みます) を使用したオフチェーンの安全なログ取得の方法。
他に何をする必要があるか、どのようなトレードオフを行う必要があるか?
この機能を簡素化する際の主なトレードオフは、(i) 簡素化の範囲と速度と、(ii) 下位互換性です。チェーンとしてのイーサリアムの価値は、アプリケーションをデプロイし、何年後も動作するという確信を持てるプラットフォームであるという事実から生まれます。同時に、この理想は行き過ぎである可能性があり、ウィリアム・ジェニングス・ブライアンの言葉を借りれば、「イーサリアムを下位互換性の限界に釘付けにする」ことになります。特定の機能を使用するアプリケーションがイーサリアム全体で 2 つだけで、1 つは何年もユーザーがゼロで、もう 1 つはほぼ完全に使用されておらず、合計 57 ドルの価値が得られた場合、その機能を削除する必要があります。必要に応じて被害者にポケットから 57 ドルを支払います。
より広範な社会問題は、緊急ではない下位互換性を破壊する変更を行うための標準化されたパイプラインを作成することです。この問題にアプローチする 1 つの方法は、自己破壊プロセスなどの既存の前例を調べて拡張することです。パイプラインは次のようになります。
- 機能 X の削除について話し始めます。
- 分析を実施して削除の影響を判断し、続行します。
- X を非推奨にするための正式な EIP を開発します。一般的な高レベルのインフラストラクチャ (プログラミング言語、ウォレットなど) がこれを尊重し、この機能の使用を停止するようにしてください。 ;
- 最後に、実際に X を削除します。
- ステップ 1 と 4 の間には複数年にわたるパイプラインがあり、どのプロジェクトがどのステップにあるかについての明確な指示が必要です。現時点では、機能削除プロセスのダイナミズムと速度と、より保守的になってプロトコル開発の他の領域により多くのリソースを投入することとの間にはトレードオフがありますが、パレートフロンティアにはまだ程遠いです。
終了後
EVM に対して提案されている主要な変更セットの 1 つは、EVM Object Format (EOF) です。 EOF では、ガスの可観測性、コードの可観測性 (つまり CODECOPY なし) の無効化、静的ジャンプのみの許可など、多数の変更が導入されています。目標は、(EOF 以前の EVM がまだ存在するため) 下位互換性を維持しながら、より強力なプロパティを備えた EVM のアップグレードを可能にすることです。
この利点は、新しい EVM 機能を追加するための自然なパスが作成され、より強力な保証を持つより厳密な EVM への移行が促進されることです。欠点は、最終的に古い EVM を非推奨にして削除する方法が見つからない限り、プロトコルの複雑さが大幅に増加することです。大きな疑問は、特に目標が全体的な EVM の複雑さを軽減することである場合、EVM の簡素化提案において EOF はどのような役割を果たすのかということです。
ロードマップの他の部分とどのように相互作用するのでしょうか?
ロードマップの残りの部分にある「改善」提案の多くは、古い機能を簡素化する機会でもあります。上記の例をいくつか繰り返します。
- シングルスロット ファイナリティに切り替えることで、委員会を廃止し、経済性を再設計し、その他のプルーフ オブ ステーク関連の簡素化を行う機会が得られます。
- アカウント抽象化を完全に実装すると、多くの既存のトランザクション処理ロジックを削除し、すべての EOA が置き換えることができる「デフォルトのアカウント EVM コード」に移動することができます。
- これは、イーサリアムの状態をバイナリ ハッシュ ツリーに移動して、すべてのイーサリアム データ構造を同じ方法でハッシュできるようにすれば、SSZ の新しいバージョンと調和させることができます。
より根本的なアプローチ: プロトコルの大部分をコントラクト コードに変換する
より抜本的なイーサリアムの簡素化戦略は、プロトコルを同じに保ちながら、その大部分をプロトコル機能からコントラクト コードに移動することです。
最も極端なバージョンは、イーサリアム L1 を「技術的に」単なるビーコン チェーンにし、他のユーザーが独自のロールアップを作成できるようにする最小限の仮想マシン (RISC-V、カイロ、または最小限の専用証明システムなど) を導入することです。 EVM がこれらのロールアップの最初になります。皮肉なことに、これは 2019 ～ 20 年のエグゼクティブ環境提案とまったく同じ結果ですが、SNARK によって実際の実装がより実現可能になります。
より控えめなアプローチは、ビーコン チェーンと現在のイーサリアム実行環境の間の関係を変更せずに維持し、EVM のインプレース スワップを実行することです。 RISC-V、Cairo、または別の VM を新しい「公式 Ethereum VM」として選択し、すべての EVM コントラクトを、元のコード ロジックを (コンパイルまたは解釈を通じて) 解釈する新しい VM コードに強制することができます。理論的には、これは EOF のバージョンとして「ターゲット VM」を介して実行することもできます。
