Paradigm CTO：イーサリアムのカンクンアップグレード後、次のプラハアップグレードではどのような動きがありますか？

原文タイトル：イーサリアムのカンクンハードフォークの後は何が来るのか？

原文著者：Georgios Konstantopoulos，Paradigm Research Partner \& CTO

原文翻訳：defioasis，吴说区块链

要約

この記事の目的は、Paradigm Rethチームがプラハ（Prague）に含めるべきEIP（イーサリアム改善提案）についての見解を概説することです。プラハはカンクンの次のEL（イーサリアム実行層）ハードフォークであり、2024年の「ELコア開発者」プランの概要も示します。以下の見解は進化し続けており、Rethチームの現在の見解を代表するものであり、より広範なParadigmチームの見解を必ずしも反映するものではありません。

私たちは、2024年第3四半期にプラハハードフォークがイーサリアムテストネットで実施可能であり、年末までにメインネットに実装できると考えています。これには以下が含まれるべきです：

（1）ステーキングに関連するEIP、例えばEIP-7002は、再ステーキング（re-staking）と信頼不要のステーキングプールを可能にします。

（2）独立したEVMの変更。

（3）プラハや他の将来のELハードフォークの難しい問題をさらに探求したいチームと協力する意向があり、Rethコードベースの変更に関する提案を歓迎します。

推奨事項：

（1）以下のEIPを優先的に考慮すべきと考えています：7002、6110、2537。

（2）私たちは、規範に記載されているようにEOFを支持しますが、範囲を早急に特定し、この範囲を約束するmeta-EIPを作成したいと考えています。（注：EOFはEVMオブジェクトフォーマットを指し、イーサリアムのコード実行環境にいくつかの変更を加えます。開発者は次回の実行層アップグレードプラハにEOFを含めることを提案していますが、現在の見解は分かれており、いくつかはその規範が最終決定されていないと考え、他はVerkle Triesが次回のアップグレードの焦点であると考えています）

（3）私たちはEIP-4844の最大Blob Gasの増加に対してオープンな態度を持っています。正確な数字については具体的な見解はありませんが、データ分野の専門家と協力してこのテーマを調査することを招待します。（注：BlobはL2からL1に取引データを提出するためのストレージ構造であり、独自の価格設定システムBlob Gasを持っています）

（4）私たちはEIP-7547：包含リスト（Inclusion lists）の導入に対してオープンな態度を持っており、基盤の審査抵抗力を高めるのに役立ちます。

推奨しない事項：

（1）私たちはプラハにVerkle Triesを導入することを支持しませんが、クライアントチームが2024年第2四半期からこの方向に努力することを支持し、2025年中頃から後半の大阪（Osaka）での実装を約束します。（注：将来のイーサリアムが移行するデータ構造であり、現在のMerkle Trie構造に比べて、Verkleは証明サイズや検証効率などの面での利点を持ち、将来のイーサリアムの無状態実現に不可欠な要素です）

（2）私たちはL1実行Gas制限や契約サイズを増加させるべきではないと考えていますが、データ専門家と協力してこれがネットワークに与える影響を研究することを招待します。過去のテストではRethノードが問題なく増加した負荷を処理できることが示されているため、私たちはオープンな態度を持っています。

（3）私たちはウォレット/アカウント抽象のEIPが相互に実戦テストをもっと必要とし、それらの間のトレードオフをよりよく理解する必要があると考えています。もしそれらが相互排他的でないなら、将来的にAA（アカウント抽象）に関連する複数のEIPを展開する意向があります。

（4）EIP-7212（secp256r1）について、コミュニティが噂されるNSA（アメリカ国家安全保障局）のバックドアに対して異議を唱えない場合、私たちはそれを支持するかもしれません。

（5）その他のロードマップテーマ：私たちはCL（コンセンサス層）EIPやCL/EL（実行層）フォークの結合について直接的な見解を持っていませんが、EIP-7549とEIP-7251は非常に有望に見えます。可能な場合、ELの観点からPeerDASの作業に貢献する意向があります。私たちは現在、SSZルート（EIP-6404、6465、6466）の導入を避けたいと考えています。最後に、期限切れのblobs、履歴、状態について、長期的なデータアーカイブソリューションの機会があることに注意しています。EIP-4844とEIP-4444はこの点を指定しておらず、イーサリアムがそのようなソリューションを提供したいかどうかは未定です。

具体的な理由は以下の通りです

推奨事項

私たちは1）コンセンサス層（CL）と実行層（EL）の間のギャップをさらに縮小すること；2）EVMの変更、これらの変更は単独の作業として実行でき、隔離して並行してテストできることを支持します。

EIP-7002

このEIPは、実行層（EL）のスマートコントラクトがコンセンサス層（CL）の1つまたは複数のバリデーターを制御できるようにすることで、信頼不要の再ステーキングとステーキングプールを解放します。私たちの観点からは、これは考えるまでもないEIPです。なぜなら、少なくとも既存のステーキングプールがその引き出しを実行するスマートコントラクトから1つの集中化レイヤーを取り除くことができるからです。

私たちはEVM実装において状態プリコンパイルの新しい抽象を取り入れる必要がありますが、それ以外には、これは直接実行可能なEIPだと考えています。

EIP-6110

このEIPは、実行層（EL）状態にデポジットを導入し、コンセンサス層（CL）で必要な状態管理を簡素化します。実装の観点からは、コンセンサス層の引き出しを追跡することに似ているため、全体的に見てこれも実装が容易で独立したEIPだと考えています。

EIP-2537

現在、市場には複数のBLS12-381の実装があり、これは多くのSNARK（ゼロ知識証明技術）、BLS署名アルゴリズム、EIP-4844で頻繁に使用される曲線です。私たちは実装の複雑さが低いと考えています。なぜなら、これはプリコンパイルインターフェースで曲線の検証アルゴリズムを公開するだけだからです。私たちはBLS12-381曲線プリコンパイルのハッシュアルゴリズムも必要になるかもしれません。

EOF

簡潔にまとめると：SolidityとVyperが採用する明確な範囲のバージョンを支持します。コードフォーマットと検証の調整により分析が容易になり、これは疑いの余地のない選択です。私たちはこれ以外の内容については慎重に検討することを提案します。以下にいくつかのEIPを推奨しますが、さらに精緻化する意向もあります。

利点：

（1）EVMの変更のみで、ethereum/testsを通じてテストでき、1人で実施できます。

（2）VyperとSolidityが望むEVMの変更。

（3）パフォーマンスの向上と契約サイズ制限の増加に寄与します。

（4）EVMが実行時にバイトコード分析を行う必要がなく、キャッシュを伴わない場合、この分析には最大50％の時間がかかる可能性があり、契約サイズの増加に伴って増加します。

（5）部分的なコードの読み込みをサポートし、大規模なスマートコントラクトの実行を助けます。

（6）開発者体験：SolidityでdupN/swapNを使用して「スタックが深すぎる」問題を修正し、他のツールを改善することを可能にします。

（7）将来の検証：L2で新機能を安全に導入でき、ツールはどれが互換性があるかを知っています。

欠点：

（1）範囲と移動目標。

（2）支持者が強力にこれを推進することはありません。

（3）レガシーコードのサポートが必要です。

（4）採用される前に、イーサリアムメインネットと他のEVMチェーンの間に一時的な不一致があります。

私たちは以下のEOF機能を2024年に展開すべきだと考えています。範囲を早急に特定し、約束を守ることを提案します。他の内容は後続の展開に考慮されるべきです。私たちの提案：

（1）EIP-3540：EOF - EVMオブジェクトフォーマットv1：コードとデータコンテナを導入し、イーサリアムバイトコードに構造とバージョン管理を追加します。

（https://eips.ethereum.org/EIPS/eip-3540）

（2）EIP-3670：EOF - コード検証：EOFフォーマットに従わない契約のデプロイを拒否します。より構造化されたコードの強制実施と無効および未定義の命令の無効化を行います。

（https://eips.ethereum.org/EIPS/eip-3670）

（3）EIP-663：無制限のSWAPおよびDUP命令：これはSolidityの「スタックが深すぎる」問題を解決します。なぜなら、JUMPDEST分析が即値として副作用を引き起こす可能性があるからです。これはEVM言語に非常に有益です。

（https://eips.ethereum.org/EIPS/eip-663）

（4）EIP-4200：EOF - 静的相対ジャンプ：より良い静的分析、不確定なジャンプなし。より良いAOTコンパイル。相対ジャンプはコードの再利用に有利です。

（https://eips.ethereum.org/EIPS/eip-4200）

（5）EIP-4750：EOF - 関数：動的ジャンプは使用できるが静的ジャンプは使用できないサブルーチンの問題を解決する必要があります。また、部分的なコードの読み込みを許可し、これはVerkleおよび契約サイズ制限の増加機能と非常に良く組み合わさります。

（https://eips.ethereum.org/EIPS/eip-4750）

（6）EIP-5450：EOF - スタック検証：コードとスタック要件を検証します。CALLF（EIP-4750）命令を除いて、すべての命令の実行時スタックの下溢れおよび上溢れチェックを削除します。

（https://eips.ethereum.org/EIPS/eip-5450）

（7）EIP-7480：EOF - データセグメントアクセス命令：バイトコードのデータセグメントへのアクセスを許可します。

（https://eips.ethereum.org/EIPS/eip-7480）

（8）EIP-7069：改善されたCALL命令：CALLからGasの観測可能性を取り除くことを可能にし、将来的にGasの再価格設定を容易にします。EOFとは関係ありませんが、これを導入する良い機会だと考えています。

（https://eips.ethereum.org/EIPS/eip-7069）

EIP-6206について：EOF - JUMPFおよび非戻り関数について、私たちの見解はそれほど確定的ではありません。EOF関数内で尾部呼び出し最適化を行うことを許可しますが、私たちは言語がその有効性を分析するのを見る必要があります。この分析がなければ、私たちは範囲からそれを除外し、後続のEOF更新に含めることが可能だと考えています。

私たちは上記の作業が1人によってフルタイムで行われ、1-2ヶ月の時間が必要だと予想しています。上記の範囲を縮小することが進捗を維持することを意味するなら、私たちはさらに縮小する意向があります。

レガシーバイトコードに関する説明：

（1）新しいレガシー/非EOFバイトコードを禁止することはできますが、既存のレガシーバイトコードを排除する方法はありません。これは実際にEOFの「v0」バージョンとして機能します。レガシーバイトコードはEOFの後でもJUMPDEST分析が必要であり、Verkle Triesでそれをセグメント化するには特別なコード処理が必要です。

（2）私たちの知る限り、ソースコードのアーティファクトなしに非EOFバイトコードを検証可能にEOFに変換する方法はありませんが、そのような変換を促進するメカニズムを探求する意向があります。

（3）さらに、EOFへの状態移行を強制する無効化方法を探求する意向もあります。

EIP-4844 Blob数の増加

私たちはこの変更に対してオープンな態度を持っており、これによりMAXBLOBGASPERBLOCK（各ブロックの最大Blob Gas制限）およびTARGETBLOBGASPERBLOCK（各ブロックの目標Blob Gas制限）が相応に増加します。

EIP-4844を背景に：TARGETBLOBGASPERBLOCKおよびMAXBLOBGASPERBLOCKの値は、各ブロックに3つのblobs（0.375 MB）の目標と6つのblobs（0.75 MB）の最大値に対応するように選定されました。これらの小さな初期制限は、このEIPがネットワークに与える圧力を最小化することを目的としており、ネットワークがより大きなブロックでの信頼性を示すにつれて、将来的に増加することが予想されています。

実際、これは小さなコード変更であり、取引プールにおける実際の影響を調査する必要がありますが、私たちはEIP-4844の圧力テストインフラを再利用してこの作業を行うことができると考えています。CL（コンセンサス層）は、より多くのblobsを伝播する上でより大きな困難を抱える可能性があります。私たちはCLチームの意見に従います。

推奨しない事項：

Verkle Tries

私たちは2024年末から2025年初頭にVerkle triesを展開する道筋を見出せません。私たちはチームが2024年第2四半期にこれにリソースを割り当て、2025年第2四半期から第3四半期の大阪ハードフォークでの展開を約束することを提案します。

利点：

（1）より小さなストレージ証明を通じて、より安価な軽量クライアントを実現します。

（2）ブロックヘッダーに読み取り前状態を含めることにより、無状態実行を実現します。これにより静的状態アクセスによるパフォーマンス向上も期待できます。

（3）バイトコードを分割し、部分的なコードの読み込みを有効にすることで、契約サイズ制限を引き上げます。

（4）「revive」状態のコストが低下することで、状態の期限切れがより実行可能になります。

欠点：

（1）変更の影響および実装とテストの統合作業量。

（2）Gas計算の変更：Verkle triesはGas計算関数に証明サイズを導入します。私たちはストレージ価格の変化についての議論がまだ行われていないことを懸念しています（例えば、Verkleの後、トップGas消費者のコストはどのようになるのか）。

（3）アプリケーション統合：Overlay変換が実行される間、Merkle Patricia Trieバリデーターを持つアプリケーションは何をすべきか？eth_getProofはどのように振る舞うべきか？

私たちはVerkle triesの利点を理解していますが、第三者ツール/契約がどのように適応する必要があるか、また変換がLayer 2ソリューションなどにどのような影響を与えるかについて、さらに考える必要があると考えています。最初は移行戦略に懐疑的でした。なぜなら、既存のMPT（Merkle Patricia Trie）から状態を読み取る際にVerkle triesを更新する必要があると規定されていたからですが、今ではそうではないようです。したがって、私たちはオーバーレイツリー方式を実行可能な移行経路として支持します。

Verkle移行戦略に関する文書は、全体的に見て時代遅れのようです。なぜなら、ほとんどのリソースが、MPTから状態を読み取る際にVerkle trieを更新すべきだと指摘しているからです。私たちは、最新の方法で重要な変換文書（例：https://notes.ethereum.org/@parithosh/verkle-transition）を更新することを望んでいます。また、移行戦略に関するEIP草案も見たいと考えています。

したがって、私たちは2025年に展開することを支持しますが、プラハフォークでの展開はすべきではないと考えています。

L1 Gas制限

私たちは、派生需要によりL1 Gas制限を引き上げることが実際にはあまり効果がないと考えています。また、ほとんどのクライアントは平均負荷の増加に対処できると考えていますが、最悪の事態に対して警戒を保ちたいと考えているため、L1 Gas制限の引き上げを提案することはできません。短期的には、Blob Gas制限の増加がより有望な解決策だと考えています。

アカウント抽象

私たちは1つまたは複数のEIP（またはERCを含む）を取り入れることに対してオープンな態度を持っていますが、各提案間のユーザー体験と開発者体験の比較をもっと見たいと考えています。これにより、ツール統合のトレードオフと作業量をよりよく理解できると考えています。私たちは以下のEIP/ERCに注目していますが、他の提案も歓迎します：

（1）EIP-3074：AUTHおよびAUTHCALLオペコード

（https://eips.ethereum.org/EIPS/eip-3074）

（2）ERC-4337：Alt Mempoolを使用したアカウント抽象

（https://eips.ethereum.org/EIPS/eip-4337）

（3）EIP-5806：代理取引

（https://eips.ethereum.org/EIPS/eip-5806）

（4）EIP-5920：PAYオペコード

（https://eips.ethereum.org/EIPS/eip-5920）

（5）EIP-6913：SETCODE命令

（https://eips.ethereum.org/EIPS/eip-6913）

（6）EIP-7377：移行取引

（https://eips.ethereum.org/EIPS/eip-7377）

（7）RIP-7560：ネイティブアカウント抽象 - コアEIP - イーサリアム魔術師連盟

(https://ethereum-magicians.org/t/rip-7560-native-account-abstraction/16664）

私たちが指摘したいのは、上記の内容において「アカウント抽象」は「抽象検証機能を指し、主な目標はキーのローテーションを実現し、マルチシグネチャをブロックチェーンのコア特性にし、私たちに自動的な量子耐性の道筋を提供すること」を意味します（h/t VB）。これは上記の4337および7560にのみ適用され、他の提案はGasスポンサーシップとバッチ操作の2つのカテゴリに分かれます。