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