EtherのCancunハードフォーク後、次のアップグレードはどのようになるべきか

この記事の目的は、Paradigm Rethチーム^[4]のプラハハハードフォークに対する見解、プラハがカンクンの次のELハードフォークであること、そして私たちの2024年の「ELコア開発」プログラムについての概要を提供することです。"プログラムについての見解です。以下の見解は開発中のものであり、現在のRethチームの見解を表しており、必ずしもParadigmチーム全体の見解ではありません。

これには以下が含まれるはずです:

EIP-7002のような、再ステーキングと信頼性のないプレッジプールを可能にするプレッジ関連のEIP。

独立したEVMの変更。

私たちは、Braggや他の将来のELハードフォークをさらに調べたいチームと協力することを望んでいます。

サポート:

私たちは、以下のEIPが優先されなければならないと考えています:

私たちは、以下のEIPが優先されなければならないと考えています:

7002^[5]、6110^[6]、2537^[7である。

私たちは、仕様^[8]に記述されているようにEOFをサポートしていますが、できるだけ早くスコープを定義し、そのスコープにコミットするメタEIPを作成したいと考えています。

私たちはEIP-4844 Maximum Blob Gas^[9]のバージョンを追加したいと考えています。私たちは正しい番号について意見を持っていませんが、私たちと一緒にこの問題を調査してくれるデータ関係者を募っています。

私たちは、ベースレイヤーが精査に耐えられるように、EIP-7547: Inclusion List^[10]のバージョンを公開したいと考えています。

サポート対象外：

私たちはBraggにおけるVerkle Tries^[11]の使用をサポートしませんが、2024年第2四半期以降にそれを実装しようとするクライアント側のチームをサポートします！2025年中下旬に大阪でリリースすることを約束し、それに向けて取り組んでいます。

私たちは、L1実行ガスの上限や契約サイズを増やすべきだとは考えていませんが、ネットワークへの影響を調査するために、私たちと一緒に働くデータ関係者を募集しています。過去のテストでは、Rethノードは問題なく負荷の増加に対応できることが示されているため、私たちの見解を変更することも厭いません。

ウォレット/アカウント抽象化EIPは、トレードオフの空間をよりよく理解するために、互いに対してより多くのテストが必要だと考えています。

もしコミュニティが^[12]噂されている^[13]NSAの^[14]バックドア^[14]に対して^[12]OKであれば、^{EIP-7212 (}[14]) を受け入れることができます。EIP-7212（secp256r1）を受け入れることができます。

その他のロードマップのトピック: CL EIPまたはCL/ELフォークの結合について具体的な見解を持っていませんが、EIP 7549^[15]と7251^[16]は有望に思えます。また、EL側でも可能な限りPeerDASの作業に貢献したいと考えています。SSZルーツの導入は当面避けたい（EIP 6404, 6465, 6466）。最後に、EIP-4844^[17]もEIP-4444^[18]もこれを指定していないため、期限切れのBlob、履歴、および状態のための長期的なデータアーカイブソリューションを提供する機会と、そのようなソリューションを提供するイーサネットの意欲に注目します。

以下にその理由を示します。

サポート

抽象的には、1) CL と EL の間のギャップをさらに埋めること、2) シングルプレーヤーのジョブとして実行でき、分離して並行してテストできる EVM の修正をサポートします。

EIP-7002^[19]

このEIPは、信頼されていないリプレッジとプレッジプールのロックを解除します。プレッジプールのロックを解除します。少なくとも、既存の誓約プールが、その引き出しを実行するスマートコントラクトから中心性のレイヤーを取り除くことを可能にするためです。

EVMの実装にステートフル・プリコンパイルを導入することは、EVMの実装で捕捉する必要がある新しい抽象化ですが、それ以外は、これは実装するのが簡単なEIPだと考えています。

EIP-(英語)6110^[20]

このEIPはEL状態に預金を導入し、CLで実行する必要がある状態管理を簡素化します。実装という点では、これはCLの引き出しを追跡するのと似ているので、全体として、これも実装が簡単で独立したEIPだと考えています。

EIP-2537^[21]

BLS12-381の実装は複数存在し、多くのSNARK、BLS署名アルゴリズム、EIP- 4844で頻繁に使用される曲線です。SNARK、BLS署名アルゴリズム、EIP- 4844で頻繁に使用される4844曲線。この実装は、プリコンパイルされたインターフェイスを通して曲線の検証アルゴ リズムを公開するだけなので、複雑さは少ないと考えています。おそらく私たちは、BLS12-381曲線へのHashのプリコンパイルも望んでいるでしょう。

EOF^[22] Ethernet Object Format

TL;DR：SolidityとVyperが使用する予定のスコープ付きバージョンのサポート。解析を容易にするコード フォーマットと検証の微調整は当然のことであり、私たちはさらなる刈り込みを推奨します。

利点:

EVMのみの変更で、Ether/testsでテストでき、1人で実装できます。

VyperとSolidityが望むEVMの変更を行う！

パフォーマンスを向上させ、コントラクトの上限サイズを増やします。

EVMによる実行時のバイトコード解析の必要性を排除します。キャッシュがない場合、最大50%の時間がかかりますが、コントラクトのサイズとともに増加します。

コードを部分的にロードできるので、大規模なコントラクトの実行に役立ちます。

Devex:他のツールの改良の中で、SolidityでdupN/swapNを使用して「Stack Too deep」を修正できるようになります。

フューチャープルーフ: 新しい機能を安全にL2に導入することができ、ツールは何が互換性があるのかを知ることができます。

欠陥：

ターゲットの変更。

サポーターがいない。

古いコードをサポートする必要性がまだある

採用されるまでは、メインのイーサリアムネットワークと他のEVMチェーンの間に一時的な乖離が生じる。

私たちは、以下のEOF機能が2024年に導入されるべきだと考えています。できるだけ早くスコープを作成し、コンプライアンスにコミットすることをお勧めします。それ以外のものは、その後の展開を検討すべきです。

EIP-3540: EOF - EVM Object Format v1^[23]: コードおよびデータ コンテナーを導入し、Ethernet バイトコードに構造とバージョニングを追加します。

EIP-3670: EOF - Code Validation^[24]: デプロイ時にEOFフォーマットに従わないコントラクトを拒否します。より構造化されたコードを強制し、無効および未定義の命令を無効にします。

EIP-663: Unlimited SWAP and DUP commands^[25]: これは、Solidity の「Stack Too Deep」問題を、Solidity の「Stack Too Deep」を使用することで解決します。これは、即値としての JUMPDEST 分析が副作用を持つ可能性がある Solidity の「深すぎるスタック」問題を解決し、EVM 言語はこの機能を持つことを望みます。

EIP-4200: EOF - 静的相対ジャンプ^[26]: より良い静的解析、不確定ジャンプなし。Aotコンパイルが向上。相対ジャンプはコードの再利用性により優れています。

EIP-4750: EOF - Functions^[27]: 動的ジャンプはあっても静的ジャンプはないサブルーチンを扱う必要があります。これはまた、Verkleとうまく機能する部分的なコードロードを可能にし、コントラクトサイズの制限を追加します。

EIP-5450: EOF - スタック検証 ^[28]: コードとスタック要件を検証します。CALLF (EIP-4750) を除くすべての命令は、実行時のスタック アンダーフローおよびオーバーフロー チェックを削除します。

EIP-7480: EOF - データセグメントアクセス命令 ^[29]: バイトコードのデータセグメントへのアクセスを許可します。

EIP-7069：改良されたCALL命令^[30]：CALLのガス観測値を消滅させ、将来的にガスの再価格付けを容易にします。EOFとは無関係ですが、これを導入する良い機会だと考えています。

私たちは、EIP-6206: EOF - JUMPFおよび非返却関数^[31]についてはあまり確信していません。これはEOF関数におけるテールコールの最適化を可能にしますが、その有用性についての言語解析を見る必要があります。これがなければ、スコープから削除し、後続のEOF更新に含めることができると考えています。

上記の予算は、1名によるフルタイムの作業で1～2ヶ月分としています。勢いを維持するためであれば、上記の範囲をさらに削減することも厭いません。

レガシー バイトコードに関する注意:

新しいレガシー/非EOFバイトコードを禁止することはできますが、既存のレガシー バイトコードを非推奨にすることはできません。v0".レガシー バイトコードは、EOF 後も JUMPDEST 解析を必要とし、Verkle Tries に分割するための特別なコード処理を必要とします。

私たちの知る限り、ソースアーティファクトにアクセスすることなく、非EOFバイトコードからEOFへの検証可能な変換はありませんが、私たちはこの変換を容易にするメカニズムを調査することに前向きです。

あるいは、EOFへの状態移行を強制するための期限切れメソッドの調査にも前向きです。

EIP-4844 Blob の数を増やす

私たちはこの変更に前向きです。TARGET_BLOB_GAS_PER_BLOCKが追加される可能性があります。PER_BLOCKおよびMAX_BLOB_GAS_PER_BLOCKの値は、ブロックあたり3ブロブ（0.375MB）、最大6ブロブ（0.75MB）をターゲットに選択されています。これらの小さな初期制限は、このEIPがネットワークに与える負担を最小限に抑えることを意図しており、将来的なアップグレードでは、より大きなブロックでもネットワークが確実に動作するように、増加することが期待されています。

実際には、これはマイナーなコード変更であり、txpoolでの実際の影響を調査する必要がありますが、EIP-4844のストレステストのインフラを再利用できると考えています。コンセンサス層は、より多くのblobを伝播することに問題があるかもしれません。

サポートされていません

ヴァークル・トライ^[33]

TL。2024年第2四半期にリソースを割り当て、2025年第2四半期から第3四半期に大阪ハードフォークでデプロイすることを約束することをお勧めします。

メリット：

より小さいストレージ証明で、より安価で軽いクライアントを可能にします。

ブロックヘッダーに読み取り前の状態を含めることで、ステートレス実行を可能にします。

バイトコードをチャンキングし、部分的なコードロードを有効にすることで、コントラクトのサイズ制限を改善します。

状態を「復活」させるコストが低くなるため、状態の有効期限がより魅力的になります。

欠点:

重い作業負荷: 変更の影響、実装するための統合作業、テスト。

ガス価格の変更: バークル・トライはガス計算機能に立会人サイズを導入しました。

貯蔵価格の変更がまだ検討されていないことを懸念しています（たとえば、Verkle後のガス消費量の上位者のコストはどうなるのでしょうか）。

アプリの統合: オーバーレイ移行が実行されるとき、Merkle Patricia Trie バリデーターを持つアプリは何をすべきでしょうか?eth_getProofの動作はどのようにすべきですか?

私たちはVerkle Triesの利点を理解していますが、サードパーティのツールや契約をどのように適合させる必要があるのか、また、移行がたとえばレイヤー2のソリューションにどのような影響を与えるのかを理解するためには、もっと熟考する必要があると考えています。当初は、既存のMPTから状態を読み込む際にVerkle Trieを更新する必要があるとしていたため、移行戦略に懐疑的であったが、現在はそうではないようである。したがって、私たちはオーバーレイツリーのアプローチを実行可能な移行経路として支持します。

ほとんどのリソースでは、VerkleトライはMPTから状態を読み込むときに更新されるべきであると述べられていますが、これは事実ではないようです。私たちは、この優れた文書^[34]のような、主要な移行の文書が最新の方法論に更新されることを望みます。

ですから、私たちは2025年のヴァークルの展開をまだ支持していますが、プラハのアップグレードの展開経路は見ていません。

L1ガス上限

私たちは、L1ガス上限を引き上げても、需要誘発の観点から実際にはあまり意味がないと考えています。また、ほとんどのクライアントは負荷平均の増加に対処できると思いますが、最悪のシナリオを警戒したいので、今のところL1ガス制限を増やすことはお勧めしません。私たちは、ブロブガスの制限を増やすことが、短期的にはより有望な解決策であると考えています。

私たちは、EVMでリソースが計量される方法から脱却することと同様に、この方向でのあらゆる研究について、私たちと協力するよう人々を招待します。

アカウントの抽象化

私たちは、これらのEIP（またはプロトコルを実装するERC）の1つ以上を含めることを望んでいます。提案のトレードオフ空間とツール統合の労力をよりよく理解するために。

EIP-3074：AUTHおよびAUTHCALLオペコード^[36]

ERC-433;[36]

ERC-433。left;">ERC-4337: Alt Mempoolを用いたアカウントの抽象化^[37]

EIP-5806: Delegate transaction^[38]

EIP-5920: PAY opcode^[39]

EIP-6913: SETCODE命令^[40]

EIP-7377: Migration Transaction^[41]

RIP-7560: Migration Transaction^[41]

RIP-7560.">RIP-7560: Native Account Abstraction - Core EIPs - Fellowship of Ethereum Magicians^[42]

上記の中で、以下のことを明確にしたいと思います。上記の文脈で「アカウントの抽象化」とは、「キーローテーションを可能にし、マルチ署名を第一級の機能にし、自動化された量子抵抗経路を提供することを主な目的とした検証機能の抽象化」（h/t VB）を指し、これは4337と7560にのみ適用されるのに対し、他の提案は2つのカテゴリに分類されます。他の提案は、ガススポンサーと運用バッチ処理の2つのカテゴリに分かれています。

著者：