**文:Georgios Konstantopoulos氏、Paradigm、CTO****コンパイラ:ルフィ、フォーサイトニュース**この記事の目的は、プラハハードフォーク(カンクンハードフォーク後のコンセンサスイーサリアムへの次のメジャーアップグレード)に含めるべきEIPと、2024年の「EL Core Dev」の全体的な計画に関するParadigm Rethチームの見解の概要を提供することです。 以下の見解は常に進化しており、Rethチームの現在の見解を表しており、必ずしもParadigmチーム全体を表すものではありません。プラハのハードフォークは、2024年第3四半期にイーサリアムテストネットで、年末までにメインネットで実現する可能性が高いと考えています。 これには、次のものを含める必要があります。* 再ステーキングやトラストレスステーキングプールをサポートするEIP-7002など、ステーキングに関連するEIP。* EVM のバリエーションを分離します。* 私たちは、プラハやその他の将来のELハードフォークをさらに調査したいチームと喜んで協力し、Rethコードベースを変更する場所のガイダンスと支援を喜んで提供します。対応策:* EIP 7002、6110、2537 を優先する必要があると考えています。*仕様に記載されているEOFをサポートしており、スコープを確定し、できるだけ早くメタEIPを作成したいと考えています。* EIP-4844 Max Blob Gasを追加しても構いません。 具体的な数字について意見はありませんが、データ関係者にこのテーマについて協力してもらいます。* EIP-7547 のバージョンをリリースできることを嬉しく思います: ベースレイヤーが検閲に抵抗するのに役立つリストが含まれています。してはいけないこと:* プラハのハードフォークにVerkle Trysを含めることはサポートしていませんが、クライアントチームが2024年第2四半期にこれに取り組み始め、2025年の大阪アップグレードでリリースすることを約束します。* L1 実行ガス制限や契約サイズを増やすべきではないと考えていますが、ネットワークへの影響を調査するために、データ担当者に協力していただくようお願いします。 過去のテストでは、Reth Nodeが負荷の増加を問題なく処理できることが示されているため、認識を変更することをいとわない。* ウォレット/アカウント抽象化EIPは、トレードオフ空間をよりよく理解するために、互いにより敵対的にテストする必要があると考えています。 これらが相互に排他的でない場合は、将来的に複数のAA関連のEIPを展開することをいとわないでしょう。* コミュニティが噂のNSAバックドアに同意するなら、EIP-7212(secp256r1)で一線を越えることができます。* その他のロードマップのトピック: CL EIP または CL/EL フォークの結合については実際に理解していませんが、EIP 7549 と 7251 は有望に見えます。 また、EL側からPeerDASの業務に少しでも貢献していきたいと考えています。 現時点では、SSZルート(EIP 6404、6465、6466)の導入は避けたいと考えています。 最後に、EIP-4844とEIP-4444の両方がこれを明確にしているため、期限切れのブロブ、履歴、および状態に対する長期的なデータアーカイブソリューションを提供する機会があると考えていますが、イーサリアムがそのようなソリューションを提供する意思があるかどうかはまだ決定されていません。以下で詳しく説明します。### やる事要約では、1)CLとELの間のギャップをさらに埋めること、および2)EVMの変更を単独作業として実行でき、個別に並行してテストできることを支持します。#### **EIP-7002**このEIPは、EL側のスマートコントラクトがCL側の1つ以上のバリデーターを制御できるようにすることで、トラストレスな再ステーキングとステーキングプールのロックを解除します。 私たちの見解では、少なくとも既存のステーキングプールは、出金を可能にするスマートコントラクトから中央集権化の層を取り除くことができます。EVMにステートフルなプリコンパイルを導入することは、EVM実装で取得する必要がある新しい抽象化ですが、それ以上に、これは単純なEIPであると考えています。#### **EIP-6110**EIPはEL状態でのデポジットを導入し、CLで行う必要のある状態管理を簡素化します。 実装の面では、これはCLの引き出しを追跡するのと似ているため、全体として、これもシンプルでスタンドアロンのEIPであると考えています。#### **EIP-2537**現在、BLS12-381は複数の実装があり、これは多くのSNARK、BLS署名アルゴリズム、およびEIP-4844で頻繁に使用される曲線です。 プリコンパイルされたインターフェイスを介して曲線の検証アルゴリズムのみを公開するため、実装の複雑さは低いと考えています。 また、BLS12-381曲線のハッシュをプリコンパイルする必要がある場合もあります。#### **EOF***翻訳者注:EOFはEVM Object Formatの略で、イーサリアムオブジェクトフォーマットに変換され、イーサリアムの実行をより効率的で一貫性があり、アップグレード可能にすることを約束する一連のEIPが含まれています。 初期の計画は上海アップグレードで実施されましたが、後に削除されました。 *EOFはSolidityとVyperの両方をサポートします。 コードのフォーマットと検証の調整により、バイトコード分析がはるかに簡単になることは間違いありませんが、それ以外は慎重に検討することをお勧めします。 以下にいくつかのEIPを推奨していますが、さらに調整しても構いません。肯定的な面:* イーサリアム/テストネットを使用してテストし、1人で実装できるEVMのみの変更。* VyperとSolidityが求めるEVMの変更* パフォーマンスの向上と契約サイズの制限の引き上げに役立ちます。* EVM のランタイム時のバイトコード解析が不要になる。 キャッシュを使用しないため、分析時間は50%にもなり、契約サイズが大きくなるにつれて長くなります。*部分的なコードの読み込みを有効にして、大規模なスマートコントラクトの実行を支援します。* Devex: dupN/swapN やその他のツールの改善により、「スタックが深すぎる」問題を修正できるようになります。* 将来性: 新機能は L2 全体で安全に導入でき、ツールは互換性を認識します。悪い点:*範囲と動的ターゲット。*それを含めるための支持者による強いプッシュはありません。* レガシ コードのサポートは引き続き必要です* 採用に先立ち、Ethereumメインネットと他のEVMチェーンとの間に一時的な意見の相違がありました。2024 年には、次の EOF 機能がデプロイされると考えています。 できるだけ早くスコープを設定し、実装にコミットすることをお勧めします。 それ以外は、その後の展開で考慮する必要があります。 推奨事項は次のとおりです。* EIP-3540 (EOF - EVM Object Format v1): コードとデータコンテナを導入し、イーサリアムのバイトコードに構造とバージョン管理を追加。* EIP-3670 (EOF - Code Validation): デプロイ時に EOF 形式に従わないコントラクトを拒否します。 より構造化されたコードを実行し、無効なディレクティブや未定義のディレクティブを無効にします。* EIP-663 (Infinite SWAP & DUP Instructions): これは、ソリッド性における「スタックが深すぎる」問題を解決し、JUMPDEST解析による即時値としての副作用があります。 EVM言語の非常に望ましい機能です。* EIP-4200 (EOF - Static Relative Jumps): 不確かなジャンプのない静的解析を改善しました。 AOTコンパイルの改善。 ジャンプは、コードの再利用を助長します。* EIP-4750 (EOF - 関数): 動的ジャンプは使用できるが静的ジャンプは使用できないサブルーチンの解決が必要です。 また、部分的なコードを読み込むことができ、Verkleと完全に連携してコントラクトサイズの制限を増やすことができます。* EIP-5450 (EOF - Stack Validation): コードとスタックの要件を検証します。 CALLF を除くすべての命令のランタイムスタックのアンダーフローおよびオーバーフローチェックを削除(EIP-4750)* EIP-7480 (EOF - Data Section Access Instruction): バイトコードのデータ部分へのアクセスを許可します。* EIP-7069 (Improved CALL Directive): CALLからガスの可観測性を削除し、将来のガスの価格変更を容易にする機能。 EOFとは無関係ですが、これを導入の良い機会と捉えています。EIP-6206(EOF - JUMPFおよび逆戻り関数)についてはよくわかりません。 EOF関数で末尾呼び出しの最適化が可能になりますが、言語プロファイリングがそれに対してどのように機能するかを確認する必要があります。 そうでない場合は、スコープから削除して、その後のEOF更新に含めることができると思います。上記の仕事量は、1人がフルタイムで1〜2か月働いていると見積もっています。 さらに絞り込んでいきます。レガシーバイトコードに関する注意:* 新しいレガシー/非EOFバイトコードを禁止することはできますが、実質的にEOFの「v0」として機能する既存のレガシーバイトコードを非推奨にすることはできません。 レガシーバイトコードは、EOF後もJUMPDEST解析が必要であり、Verkle Trysでチャンクにフラグメント化するための特別なコード処理が必要です。* 私たちの知る限り、ソースコードにアクセスせずに非EOFバイトコードからEOFへの変換を検証することはできませんが、この変換を容易にするメカニズムを検討する用意があります。* あるいは、EOFへの州の移行を強制する方法を模索する用意があります。#### **EIP-4844 ブロブの数を増やす**MAX\_BLOB\_GAS\_PER\_BLOCK と TARGET\_BLOB\_GAS\_PER\_BLOCK の増加に対応するこの変更を歓迎します。 EIP-4844 には次のように記載されています。ブロックあたり 3 ブロブ (最大 6 ブロブ) のターゲットに対応する TARGET\_BLOB\_GAS\_PER\_BLOCK と MAX\_BLOB\_GAS\_PER\_BLOCK の値を選択します。 これらの小さな初期制限は、EIP によって引き起こされるネットワークへの負荷を最小限に抑えるように設計されており、ネットワークがより大きなブロックで信頼性を示すにつれて、将来のアップグレードで BLOB の数が増加すると予想されます。実際には、これは小さなコード変更であり、トランザクションプールでの実際の影響を調査する必要がありますが、EIP-4844ストレステストインフラストラクチャを再利用できると考えました。 CLがこれ以上ブロブを広めるのは難しいかもしれませんし、CLチームの意見を尊重します。### やってはいけないこと#### **ヴェルクルトライ**Tl; TL;DR: 2024 年後半から 2025 年初頭に Verkle を展開する試みは見当たりません。 チームは 2024 年第 2 四半期にこのためのリソースを割り当て、2025 年第 2 四半期から第 3 四半期に大阪ハードフォークにデプロイすることを約束することをお勧めします。肯定的な面:*より小さなストレージプルーフでより安価なライトクライアントを有効にします。* ブロックヘッダに読み出しの事前状態を含めることでステートレスに実行し、静的な状態アクセスによるパフォーマンスの向上にもつながる可能性がある。* バイトコードをチャンク化し、部分的なコード読み込みを有効にすることで、コントラクトサイズの制限を増やします。*ステータスの「復元」のコストが低いため、ステータスの有効期限がより受け入れられるようになりました。欠点：* 変更と実装とテストの努力の影響。* ガス計算の変更: Verkle Tries は、ガス計算機能に監視人のサイズを導入します。 我々は、貯蔵価格の変更がまだ検討されていないことを懸念している(例えば、Verkleに次ぐガス消費のトップのコストはいくらか)?* アプリケーション統合: Merkle Patricia Trie バリデーターを持つアプリは、オーバーレイトランジションの実行時に何をすべきですか? eth\_getProofはどのように振る舞うべきですか?Verkle Tryの利点は理解していますが、サードパーティのツール/コントラクトがどのように適合する必要があるか、およびこれが移行期間中にレイヤー2などにどのような影響を与えるかについて、さらに検討する必要があると考えています。 当初は、既存の MPT から状態が読み取られたときに Verkle トライを更新する必要があると述べられていたため、移行戦略に疑問を抱いていましたが、現在はそうではないようです。 そのため、実行可能な移行パスとしてオーバーレイ アプローチをサポートしています。ほとんどのリソースでは、MPT から状態を読み取るときに Verkle トライを更新する必要があると記述されているため、Verkle 移行戦略のドキュメントは古くなっているようです。 私たちは、この優れたアプローチのような最新のアプローチを含む移行ドキュメントを見たいと思っています。 また、移行戦略に関するEIPの草案も見たい。そのため、プラハのハードフォークで展開するのではなく、2025年の展開を引き続きサポートしています。#### **L1ガスリミット**L1ガスリミットを引き上げても、実際には大きな違いはないと考えています。 また、ほとんどのお客様は平均的な負荷の増加に対応できると考えていますが、最悪のシナリオを警戒したいため、現時点ではL1ガスリミットを増やすことはお勧めしません。 ブロブガスの上限を引き上げることは、短期的にはより有望な解決策であると考えています。私たちは、この方向で、多くの場合、EVMのリソースメータリングを壊すことについて、私たちと一緒に研究するよう呼びかけています。 ブロークンメーターの論文は、この分野の研究の良い出発点です。#### **アカウントの抽象化**1 つ以上の EIP を含めたいと考えていますが、ツール統合のトレードオフと労力をよりよく理解するために、各提案間でユーザー エクスペリエンスと開発者エクスペリエンスをもっと比較したいと考えています。 以下のEIP/ERCを検討していますが、お気軽にアドバイスください。* EIP-3074:AUTHおよびAUTHCALL命令コード* ERC-4337:アカウントの抽象化にAlt Mempoolを使用する* EIP-5806: 委任されたトランザクション* EIP-5920:PAY操作コード* EIP-6913:SETCODEディレクティブ* EIP-7377:移行トランザクション* RIP-7560:ネイティブアカウントの抽象化 - コアEIP - イーサリアムマジシャンのフェローシップ上記で注意する必要があるのは、「アカウントの抽象化」は「抽象検証機能」のようなもので、主な目的は秘密鍵のローテーションを実装し、マルチシグ鍵を作成し、自動的に量子耐性を達成するためのパスを提供することです。
パラダイムCTO:イーサリアムカンクンアップグレード後のプラハハードフォークの解釈
文:Georgios Konstantopoulos氏、Paradigm、CTO
コンパイラ:ルフィ、フォーサイトニュース
この記事の目的は、プラハハードフォーク(カンクンハードフォーク後のコンセンサスイーサリアムへの次のメジャーアップグレード)に含めるべきEIPと、2024年の「EL Core Dev」の全体的な計画に関するParadigm Rethチームの見解の概要を提供することです。 以下の見解は常に進化しており、Rethチームの現在の見解を表しており、必ずしもParadigmチーム全体を表すものではありません。
プラハのハードフォークは、2024年第3四半期にイーサリアムテストネットで、年末までにメインネットで実現する可能性が高いと考えています。 これには、次のものを含める必要があります。
対応策:
してはいけないこと:
以下で詳しく説明します。
やる事
要約では、1)CLとELの間のギャップをさらに埋めること、および2)EVMの変更を単独作業として実行でき、個別に並行してテストできることを支持します。
EIP-7002
このEIPは、EL側のスマートコントラクトがCL側の1つ以上のバリデーターを制御できるようにすることで、トラストレスな再ステーキングとステーキングプールのロックを解除します。 私たちの見解では、少なくとも既存のステーキングプールは、出金を可能にするスマートコントラクトから中央集権化の層を取り除くことができます。
EVMにステートフルなプリコンパイルを導入することは、EVM実装で取得する必要がある新しい抽象化ですが、それ以上に、これは単純なEIPであると考えています。
EIP-6110
EIPはEL状態でのデポジットを導入し、CLで行う必要のある状態管理を簡素化します。 実装の面では、これはCLの引き出しを追跡するのと似ているため、全体として、これもシンプルでスタンドアロンのEIPであると考えています。
EIP-2537
現在、BLS12-381は複数の実装があり、これは多くのSNARK、BLS署名アルゴリズム、およびEIP-4844で頻繁に使用される曲線です。 プリコンパイルされたインターフェイスを介して曲線の検証アルゴリズムのみを公開するため、実装の複雑さは低いと考えています。 また、BLS12-381曲線のハッシュをプリコンパイルする必要がある場合もあります。
EOF
*翻訳者注:EOFはEVM Object Formatの略で、イーサリアムオブジェクトフォーマットに変換され、イーサリアムの実行をより効率的で一貫性があり、アップグレード可能にすることを約束する一連のEIPが含まれています。 初期の計画は上海アップグレードで実施されましたが、後に削除されました。 *
EOFはSolidityとVyperの両方をサポートします。 コードのフォーマットと検証の調整により、バイトコード分析がはるかに簡単になることは間違いありませんが、それ以外は慎重に検討することをお勧めします。 以下にいくつかのEIPを推奨していますが、さらに調整しても構いません。
肯定的な面:
悪い点:
*範囲と動的ターゲット。 *それを含めるための支持者による強いプッシュはありません。
2024 年には、次の EOF 機能がデプロイされると考えています。 できるだけ早くスコープを設定し、実装にコミットすることをお勧めします。 それ以外は、その後の展開で考慮する必要があります。 推奨事項は次のとおりです。
EIP-6206(EOF - JUMPFおよび逆戻り関数)についてはよくわかりません。 EOF関数で末尾呼び出しの最適化が可能になりますが、言語プロファイリングがそれに対してどのように機能するかを確認する必要があります。 そうでない場合は、スコープから削除して、その後のEOF更新に含めることができると思います。
上記の仕事量は、1人がフルタイムで1〜2か月働いていると見積もっています。 さらに絞り込んでいきます。
レガシーバイトコードに関する注意:
EIP-4844 ブロブの数を増やす
MAX_BLOB_GAS_PER_BLOCK と TARGET_BLOB_GAS_PER_BLOCK の増加に対応するこの変更を歓迎します。 EIP-4844 には次のように記載されています。
ブロックあたり 3 ブロブ (最大 6 ブロブ) のターゲットに対応する TARGET_BLOB_GAS_PER_BLOCK と MAX_BLOB_GAS_PER_BLOCK の値を選択します。 これらの小さな初期制限は、EIP によって引き起こされるネットワークへの負荷を最小限に抑えるように設計されており、ネットワークがより大きなブロックで信頼性を示すにつれて、将来のアップグレードで BLOB の数が増加すると予想されます。
実際には、これは小さなコード変更であり、トランザクションプールでの実際の影響を調査する必要がありますが、EIP-4844ストレステストインフラストラクチャを再利用できると考えました。 CLがこれ以上ブロブを広めるのは難しいかもしれませんし、CLチームの意見を尊重します。
やってはいけないこと
ヴェルクルトライ
Tl; TL;DR: 2024 年後半から 2025 年初頭に Verkle を展開する試みは見当たりません。 チームは 2024 年第 2 四半期にこのためのリソースを割り当て、2025 年第 2 四半期から第 3 四半期に大阪ハードフォークにデプロイすることを約束することをお勧めします。
肯定的な面:
*より小さなストレージプルーフでより安価なライトクライアントを有効にします。
欠点：
Verkle Tryの利点は理解していますが、サードパーティのツール/コントラクトがどのように適合する必要があるか、およびこれが移行期間中にレイヤー2などにどのような影響を与えるかについて、さらに検討する必要があると考えています。 当初は、既存の MPT から状態が読み取られたときに Verkle トライを更新する必要があると述べられていたため、移行戦略に疑問を抱いていましたが、現在はそうではないようです。 そのため、実行可能な移行パスとしてオーバーレイ アプローチをサポートしています。
ほとんどのリソースでは、MPT から状態を読み取るときに Verkle トライを更新する必要があると記述されているため、Verkle 移行戦略のドキュメントは古くなっているようです。 私たちは、この優れたアプローチのような最新のアプローチを含む移行ドキュメントを見たいと思っています。 また、移行戦略に関するEIPの草案も見たい。
そのため、プラハのハードフォークで展開するのではなく、2025年の展開を引き続きサポートしています。
L1ガスリミット
L1ガスリミットを引き上げても、実際には大きな違いはないと考えています。 また、ほとんどのお客様は平均的な負荷の増加に対応できると考えていますが、最悪のシナリオを警戒したいため、現時点ではL1ガスリミットを増やすことはお勧めしません。 ブロブガスの上限を引き上げることは、短期的にはより有望な解決策であると考えています。
私たちは、この方向で、多くの場合、EVMのリソースメータリングを壊すことについて、私たちと一緒に研究するよう呼びかけています。 ブロークンメーターの論文は、この分野の研究の良い出発点です。
アカウントの抽象化
1 つ以上の EIP を含めたいと考えていますが、ツール統合のトレードオフと労力をよりよく理解するために、各提案間でユーザー エクスペリエンスと開発者エクスペリエンスをもっと比較したいと考えています。 以下のEIP/ERCを検討していますが、お気軽にアドバイスください。
上記で注意する必要があるのは、「アカウントの抽象化」は「抽象検証機能」のようなもので、主な目的は秘密鍵のローテーションを実装し、マルチシグ鍵を作成し、自動的に量子耐性を達成するためのパスを提供することです。