オリジナル：What comes after Ethereums Cancun hard fork?》
著者: ゲオルギオス コンスタントプロス
編集：オデイリーモニ
1. コンテンツ概要
この記事では、プラハ (プラハ) ハード フォーク (カンクン アップグレード後の次の実行層ハード フォーク) に含まれる重要な EIP (イーサリアム ネットワーク改善プロトコル) についての Paradigm Reth チームの理解と、2024 年の「EL コア開発」についての理解を分析します。 「計画の様子。
プラハのハードフォークは、2024 年の第 3 四半期にイーサリアム テストネットで行われ、年末までにメインネットに実装される可能性があります。アップグレード内容には以下が含まれます：
1. 外部の信頼を必要としない再ステーキングおよびステーキング プールを有効にするために、EIP-7002 などのステーキングに関連する EIP を含めることをお勧めします。
2. 独立した EVM の変更。
さらに、Paradigm は、プラハなどの EL ハード フォークにおける困難な問題をさらに調査したいと考えているチームと協力する用意があり、Reth コード ベースの変更を含むガイダンスを喜んで提供します。
パラダイムによって認識される方向性:
1. Paradigm では、EIP 7002、6110、2537 が優先されるべきであると考えています。
2. パラダイムは、仕様に記載されているイーサリアム オブジェクト フォーマット (EOF) をサポートしていますが、できるだけ早くスコープを決定し、このスコープ専用のメタ EIP を作成したいと考えています。
3. Paradigm は EIP-4844 Max Blob Gas を追加する意向であり、正確な数値についてはあまりコメントしませんが、EIP の調査に協力するようデータ サイエンティストを招待します。
4. パラダイムは、ベース層の検閲に抵抗するのに役立つ EIP-7547: 包含リスト バージョンのリリースに前向きです。
パラダイムが同意しない方向性:
1. パラダイムは、プラハのハード フォークで使用されている Verkle Tries データ構造をサポートしていませんが、クライアント チームが 2024 年の第 2 四半期にこのデータ構造に取り組み始めることをサポートし、2025 年半ば/後半に大阪でアップグレードしてリリースすることを約束しています。
2. パラダイムは、L1 実行ガスの制限や契約サイズを増やすべきではないと考えていますが、イーサリアム ネットワークに対するこのアプローチの影響を調査するためにデータ担当者に協力するよう呼びかけます。同時に、過去のテストで Reth ノードが増加した負荷を問題なく処理できることが示されているため、Paradigm は自社の見解を和らげる意向です。
3. パラダイムは、サイバースペースにおけるトレードオフをよりよく理解するために、ウォレット/アカウントの抽象化 EIP を相互にテストする必要があると考えています。ウォレット/アカウントの抽象化が相互に排他的でない場合、将来的にはアカウントの抽象化に関連する複数の EIP をデプロイする意欲が生まれるでしょう。
4. コミュニティが噂の NSA バックドアに同意すれば、Paradigm は EIP-7212 (secp 256 r 1) の一線を越えられると信じています。
5. その他のロードマップのトピック: Paradigm はコンセンサス層 EIP または CL/EL (コンセンサス層/実行層) フォーク結合について実際には理解していませんが、EIP 7549 と EIP 7251 の 2 つの提案は有望であるようです。また、Paradigm は EL 側から PeerDAS の取り組みにできる限り貢献したいと考えており、現在 SSZ ルート (EIP 6404、6465、6466) の導入を避けたいと考えています。最後に、パラダイムは、EIP-4844 も EIP-4444 もこれを指定していないため、期限切れの BLOB、履歴、および状態の長期データ アーカイブ ソリューションがあるべきだと考えていますが、イーサリアムがそのようなソリューションを提供する意思があるかどうかはまだ決定されていません。 。
詳細は次のとおりです。
識別のパラダイムの方向性
抽象的に言えば、Paradigm は主に次の 2 つの側面をサポートします。
1) コンセンサス層と実行層の間のギャップをさらに狭める。
2) EVM の変更は 1 人の作業として実行でき、独立してまたは並行してテストできます。
EIP-7002
この EIP は、実行層側のスマート コントラクトがコンセンサス層側の単一または複数のバリデータを制御できるようにすることで、トラストレスな再ステーキングとステーキング プールのロックを解除します。パラダイムの観点からすると、この EIP はある程度理にかなっており、少なくとも既存のステーキングプールが引き出しを可能にするスマートコントラクトから集中化の層を取り除くことができるようになります。
さらに、EVM へのステートフル プリコンパイルの導入も、EVM 実装で満たす必要があるとパラダイムが同意している機能ですが、それ以上に、これは直接実装できる EIP であるとパラダイムは考えています。
EIP-6110
この EIP では、実行層の状態にデポジット機能が導入され、コンセンサス層で行う必要がある状態管理が簡素化されます。実装の点では、これはコンセンサス層の撤回を追跡することに似ているため、パラダイム全体としては、これも実装が簡単で独立した EIP であると考えています。
EIP-2537
現在、BLS 12-381 には複数の実装があり、多くの SNARK、BLS 署名アルゴリズム、および EIP-4844 で一般的に使用される曲線です。 BLS 12-381 はプリコンパイルされたインターフェイスを通じて曲線の検証アルゴリズムを公開するだけなので、BLS 12-381 曲線のプリコンパイルされたハッシュも必要になる可能性があるため、BLS 12-381 の実装の複雑さは低いとパラダイムは考えています。
イーサリアム オブジェクト フォーマット (EOF)
簡単に言うと、EOF は Solidity と Vyper の両方をサポートします。リリースの範囲が広くなると、分析を容易にするためのコードのフォーマットと検証の調整も正当化されます。Paradigm は、これを超えるものについては慎重に検討することを推奨しており、以下で推奨しています。一部の EIP も喜んでサポートします。さらに調整を加えます。
良い面:
● EVM のみの変更。イーサリアム/テストネットを使用してテストでき、1 人で実装できます。
● Vyper と Solidity が望む EVM の変更。
● パフォーマンスを向上させ、契約サイズの制限を増やすのに役立ちます。
● 実行時に EVM がバイトコード分析を実行する必要がなくなりました。これには、キャッシュを使用しないと時間の最大 50% がかかる可能性があり、コントラクト サイズが大きくなるにつれて時間がかかります。
● 部分的なコードの読み込みを可能にし、浙江省は大規模なスマート コントラクトの実行を支援します。
● Devex: dupN/swapN およびその他のツールの改善により、「スタックが深すぎる」問題を修正できるようになります。
● 将来適用可能な機能: 新しいセキュアなクロス L2 機能を導入でき、ツールはどの機能に互換性があるかを認識します。
悪い面：
● 範囲と移動ターゲット。
● これを含めるための大規模な推進には支持がありません。
● レガシーコードは依然としてサポートが必要です。
● 導入前は、イーサリアムメインネットと他の EVM チェーンの間に一時的な相違がありました。
Paradigm は、次の EOF 機能が 2024 年までに展開されるべきであると考えており、できるだけ早く範囲を定めて実装に取り組むことを推奨しています。今後の展開では、追加の問題を考慮する必要があります。したがって、パラダイムでは次のことを推奨しています。
● EIP-3540 (EOF - EVM オブジェクト フォーマット v1): コードとデータ コンテナを導入し、イーサリアム バイトコードに構造とバージョン管理を追加します。
● EIP-3670 (EOF - コード検証): デプロイ時に EOF 形式に従わないコントラクトは拒否され、より構造化されたコードのみが実行可能になり、無効な命令や未定義の命令は無効になります。
● EIP-663 (無制限の SWAP および DUP 命令): この EIP は、JUMPDEST 分析をイミディエート値として使用すると副作用が生じる可能性がある、Solidity の「スタックが深すぎる」問題を解決しますが、EVM が言語になる際に切望されていた機能です。
● EIP-4200 (EOF - 静的相対ジャンプ): 静的解析が改善され、未定義のジャンプがなくなりました。 aot コンパイルと相対ジャンプを改善すると、コードの再利用がより容易になります。
● EIP-4750 (EOF – 機能): 動的ジャンプは使用できるが静的ジャンプは使用できないサブルーチンの問題を解決する必要があります。また、Verkle データ構造とうまく連携し、コントラクト サイズの制限を増やすことができる部分的なコードの読み込みも許可する必要があります。
● EIP-5450 (EOF - スタック検証): コードとスタックの要件を確認します。 CALLF (EIP-4750) を除くすべての命令に対するランタイム スタックのアンダーフロー チェックとオーバーフロー チェックを削除します。
● EIP-7480 (EOF - データ部分アクセス命令): バイトコードのデータ部分へのアクセスを許可します。
● EIP-7069 (改善された CALL 命令)CALL から Gas の可観測性を削除できることにより、将来的に Gas の価格を再設定することが容易になります。この EIP は EOF から独立していますが、Paradigm は、このハードフォークがこの EIP を導入する良い機会であると考えています。
右のパラダイムEIP-6206 (EOF-JUMPF および戻らない関数)よくわかりませんが、この EIP により EOF 関数の末尾呼び出しの最適化が可能になりますが、Paradigm はその有用性を言語分析する必要があります。そうでない場合、Paradigm は対象から削除し、後続の EOF 更新に含めることが適切であると判断します。
パラダイムは、上記の作業量をフルタイムベースで約 1 ～ 2 人月と推定していますが、評価される作業量がさらに大きくなる場合は、上記の範囲をさらに狭める予定です。
レガシーバイトコードに関する注意:
● 新しいレガシー/非 EOF バイトコードは抑制できますが、既存のレガシー バイトコードは事実上 EOF v 0 として機能するため、非推奨にすることはできません。従来のバイトコードでは依然として EOF 後の JUMPDEST 分析が必要であり、Verkle Trys でバイトコードをチャンクにセグメント化するには特別なコード処理が依然として必要です。
● Paradigm の知る限りでは、ソース コードにアクセスせずに非 EOF バイトコードから EOF への変換を検証することはできませんが、Paradigm はこの変換を容易にするメカニズムを調査する意向です。
● あるいは、Paradigm は EOF への状態移行を強制する有効期限の方法を検討するつもりです。
EIP-4844 BLOB の数を増やす
パラダイムはこの変更を受け入れており、それに応じて「MAX_BLOB_GAS_PER_BLOCK および TARGET_BLOB_GAS_PER_BLOCK」を追加します。
ブロックあたり 3 BLOB (0.375 MB) のターゲット (最大 6 BLOB、約 0.75 MB) に対応する TARGET_BLOB_GAS_PER_BLOCK および MAX_BLOB_GAS_PER_BLOCK の値を選択します。これらの初期制限は大きくありませんが、この EIP がネットワークに与えるストレスを最小限に抑え、ネットワークがより大きなブロックで信頼性を示すため、その後のアップグレードで増加させることができます。
実際には、関連するコードの変更はそれほど大きなものではありませんが、EIP-4844 ストレス テスト インフラストラクチャを再利用できるように、パラダイムは txpool でこれらの変更による実際の影響を調査する必要があります。コンセンサス レイヤーは、より多くの blob を伝播するのが難しい場合があるため、Paradigm はコンセンサス レイヤー チームの意見も尊重します。
パラダイムが方向性と一致しない
Verkle Tries
簡単に言えば、Verkle の展開が 2024 年末から 2025 年初めまでに完了する可能性は低いと考えられます。パラダイムは、チームが 2024 年の第 2 四半期にこれにリソースを割り当て、2025 年の第 2 四半期から第 3 四半期の展開で大阪のハードフォークに取り組むことを推奨しています。
良い面:
● ストレージプルーフの容量を小さくすることで、ライトクライアントのコストを削減します。
● ブロックヘッダーに読み取り前の状態を含めることによるステートレス実行。静的な状態へのアクセスによりパフォーマンスの向上にもつながる可能性があります。
● バイトコードをチャンク化し、部分的なコードの読み込みを有効にすることで、コントラクト サイズの制限を増やします。
● 状態を「復元」するコストが低くなるため、状態の有効期限がより受け入れやすくなります。
悪い面：
● 実装およびテストされた変更と統合の取り組みの影響。
● ガス会計の変更：Verkle Tries は、ガス会計機能に監視サイジングを導入していますが、Paradigm は、ストレージ価格の変更がまだ検討されていないことを懸念しています（たとえば、Verkle 後のガス消費者一人あたりのコストなど）。
● アプリケーションの統合: オーバーレイ変換の実行中に、Merkle Patricia Trie バリデーターを備えたアプリケーションは何を行う必要がありますか? eth_getProof はどのように動作すべきでしょうか?
Verkle Tries には一定の利点がありますが、パラダイムは、サードパーティのツール/契約がどのように適応する必要があるか、移行が第 2 層のソリューションなどにどのような影響を与えるかについて、さらに考慮する必要があると考えています。当初、Paradigm は、既存の MPT から状態が読み取られるときに Verkle Tries を更新する必要があると規定していたため、この移行ポリシーに懐疑的でしたが、現在はそうではないようです。したがって、Paradigm は実行可能な移行パスとしてオーバーレイ方式をサポートしています。
Verkle 移行戦略のドキュメントは、多くの場合、時代遅れであるように見えます。これは、事実ではないにもかかわらず、MPT から状態を読み取るときに Verkle トライを更新する必要があるとほとんどのリソースが依然として述べているためです。パラダイムでは、主要な移行ドキュメントが最新の方法で更新されることを望んでいます。以下を参照してください。このドキュメント。パラダイムはまた、移行戦略に関する環境投資計画の草案を見たいと考えている。
したがって、Paradigm は 2025 年の発売を依然としてサポートしており、このハード フォークには展開されていません。
L1 ガス制限
Paradigm は、需要側に何らかの「誤解を招く」可能性があると考えており、実際、L1 ガスの制限を引き上げても実際には大きな影響はありません。また、パラダイムは、ほとんどのクライアントが平均負荷の増加に対処できると考えていますが、最悪のシナリオを警戒したいため、現時点では L1 ガス制限を増やすことは推奨していません。 Paradigm は、ブロブ ガスの制限を増やすことが、短期的にはより有望な解決策であると考えています。
パラダイムは、多くの場合、EVM でのリソース メータリングの破壊を中心に、関連する方向での研究に協力するようコミュニティを招待したいと考えています。投稿者: 壊れたメーター紙この分野の研究の良い出発点となるはずです。
アカウントの抽象化
Paradigm は、ハード フォークに 1 つ以上の EIP を含める (または ERC を組み込む) ことに意欲的ですが、理想的には、各提案間のユーザー エクスペリエンスと開発者エクスペリエンスをより多く比較したいと考えています。ツールのトレードオフ スペースと労力を理解することがより適切です。統合。 Paradigm は次の EIP/ERC に焦点を当てており、コミュニティはいつでも Paradigm に提案を行うことができます。
● EIP-3074: AUTH および AUTHCALL オペコード
● ERC-4337: Alt Mempool を使用したアカウントの抽象化
● RIP-7560: ネイティブ アカウントの抽象化 - コア EIP - イーサリアム マジシャンのフェローシップ
最後に注意していただきたいのは、「アカウントの抽象化」は前述の EIP-4337 と EIP-7560 にのみ適用され、他の提案は主にガス スポンサーシップとバッチ操作の 2 つの領域をカバーしているということです。 (「アカウントの抽象化」は検証機能を抽象化するようなもので、主な目的は鍵のローテーションを可能にし、複数の署名を鍵要素にし、量子耐性への自動化されたパスを提供することです。)
