Paradigm：イーサリアムのキャンクンアップグレード後、次に何が来るのか？
TechFlow厳選深潮セレクト
Paradigm：イーサリアムのキャンクンアップグレード後、次に何が来るのか？
誘発需要のため、L1のガス制限を引き上げても実際にはほとんど効果がない。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Georgios Konstantopoulos
翻訳：TechFlow
导读
本稿の目的は、Paradigm Rethチームが、カンクンアップグレード後の次のELハードフォーク「プラハ会議」に含めるべきEIP（イーサリアム改善提案）および2024年の「ELコア開発」計画についての見解を概説することにある。本文中の意見はRethチームの現時点での見解を反映しており、Paradigm全体の立場を代表するものではない。
概要
我々は、プラハハードフォーク（Prague hard fork）が2024年第3四半期にイーサリアムテストネットで実施され、年末までにメインネットに導入される可能性があると考えている。これには以下の内容を含めるべきである：
-
EIP-7002など、ステーキングに関連するすべてのEIP。これらはリステーキングや信頼不要なステーキングプールを可能にする。
-
独立したEVMの変更。
-
我々は、プラハまたは将来のELハードフォークに関する課題について、他のチームと協力して調査することを歓迎し、指導やRethコードベースの調整支援も提供できる。
推進すべきこと：
-
我々は以下のEIPを優先すべきと考える：7002、6110、2537。
-
EOF（EVMオブジェクトフォーマット）の仕様記述を支持するが、その範囲を早急に確定し、範囲に特化したメタEIP（meta-EIP）を作成することを望む。
-
EIP-4844の最大Blob Gasの増加に前向きである。具体的な数値については明確な見解を持たないが、データ担当者との共同調査を呼びかける。
-
EIP-7547のバージョン（含みリスト）の導入を支持する。これは草の根レベルでの検閲抵抗性を高める。
行うべきでないこと：
-
プラハにおけるVerkle Triesの導入には支持しないが、クライアントチームが2024年第2四半期から実装作業を開始し、2025年中盤～後半の大阪ハードフォークでのリリースを約束することを支持する。
-
L1の実行Gas上限やコントラクトサイズの拡大には反対であるが、ネットワークへの影響を調べるためのデータ分析担当者との協力を歓迎する。過去のテスト結果（Rethノードが負荷増加に耐えられることを示す）に基づき、立場を再考する用意がある。
-
ウォレット／アカウント抽象化EIPは、より多くの実践的テストが必要であり、相互のトレードオフを理解する必要がある。互いに排他的でなければ、今後複数のAA関連EIPを展開する用意がある。
-
コミュニティが噂されているNSAバックドア（NAS backdoor）を受け入れるなら、EIP-7212（secp256r1）について判断するかもしれない。
-
その他ロードマップ上のテーマ：CL EIPやCL/ELフォークの結合については直接的な見解を持たないが、EIP 7549および7251は有望に見える。PeerDASの作業に対しても可能な限りEL側から貢献したい。現在のところ、SSZルート（EIP 6404、6465、6466）の導入は回避したいと考えている。最後に、EIP-4844およびEIP-4444では規定されていない、期限切れのblob、履歴、状態に対する長期データアーカイブソリューションの機会に注目している。イーサリアムがこのようなソリューションを提供する意思があるかは未だ不明である。
以下に全文の詳細を紹介する。
推進すべきこと：
簡潔に言えば、我々は以下を支持する：
-
CLとELのギャップをさらに縮小すること
-
単独で実行可能で、独立かつ並列的にテスト可能なEVM変更
EIP-7002
このEIPにより、EL側のスマートコントラクトがCL側の1つ以上のバリデーターを制御でき、信頼不要なリステーキングおよびステーキングプールが可能になる。我々の視点では、これはまさに「取りやすい成果（low-hanging fruit）」である。なぜなら、既存のステーキングプールが引き出し機能を実装するスマートコントラクトから一層の中央集権性を排除できるからだ。
EVMにステートフルなプリコンパイルを導入することは、EVM実装において新たに捉える必要のある抽象概念だが、それ以外は直ちに実行可能なEIPと考えている。
EIP-6110
このEIPはEL状態に預け入れ（deposit）を導入し、CL上での状態管理を簡素化する。実際上、これはCLの引き出し追跡と類似しているため、全体としてこれは容易かつ独立に実装可能なEIPであると考える。
EIP-2537
BLS12-381にはすでに複数の実装があり、多くのSNARKs、BLS署名アルゴリズム、およびEIP-4844で頻繁に使用される曲線である。プリコンパイルインターフェースを通じて曲線の検証アルゴリズムを公開するだけであるため、実装の複雑さは非常に低いと考える。また、BLS12-381曲線プリコンパイルに対するハッシュインターフェースも必要となるかもしれない。
EOF
要するに：明確に定義されたバージョンを支持する。SolidityおよびVyperが採用するだろう。コードフォーマットおよび検証の調整により解析が容易になることは間違いないが、それ以外については慎重に検討すべきである。我々は以下のEIPの採用を提案するが、さらなる削減にもオープンである。
良い点：
-
EVMの変更のみに関わるものであり、ethereum/testsでテスト可能で、個人が実装できる
-
VyperおよびSolidityが求めているEVMの変更
-
パフォーマンス向上およびコントラクトサイズ上限の拡大に寄与
-
EVMがランタイム時にバイトコード解析を行う必要をなくす。キャッシュなしの場合、解析時間は最大50%に達し、コントラクトサイズが大きくなるほど増加する。
-
部分コード読み込みをサポートし、大規模スマートコントラクトの実行を助ける
-
開発体験：dupN/swapNおよびその他のツール改良により、「スタックが深すぎる」という問題を修正可能
-
将来志向：L2で新機能を安全に導入でき、ツールが互換性のあるものを認識できる
悪い点：
-
範囲および移動目標の不透明さ
-
採用を推進する強力な推進者の不在
-
従来のコードのサポートが依然として必要
-
採用前に、イーサリアムメインネットと他のEVMチェーン間に一時的な分岐が生じる
我々は2024年に以下のEOF機能を展開すべきと考える。範囲を早急に確定し、コミットメントを行うべきである。それ以外の内容は後続の展開を検討すべきである。我々の提案は以下の通り：
-
EIP-3540：EOF - EVMオブジェクトフォーマットv1：コードおよびデータコンテナを導入し、イーサリアムバイトコードに構造およびバージョン管理を追加。
-
EIP-3670：EOF - コード検証：EOF形式に従わないコントラクトのデプロイを拒否。より構造化されたコードを実施し、無効および未定義の命令を無効化。
-
EIP-663：無制限のSWAPおよびDUP命令：Solidityの「スタックが深すぎる」問題を解決。即時価値を持つJUMPDEST解析は副作用を生じる可能性がある。EVM言語にとって非常に魅力的。
-
EIP-4200：EOF - 静的相対ジャンプ：より良い静的解析を実現し、不確定なジャンプを排除。相対ジャンプはコード再利用性を高める。
-
EIP-4750：EOF - 関数：動的ジャンプではなく静的ジャンプを使用する場合に生じるサブルーチンの問題を解決。さらに、部分コード読み込みを可能にし、Verkleとの連携を助け、コントラクトサイズ制限を拡大。
-
EIP-5450：EOF - スタック検証：コードおよびスタック要件の検証。CALLF (EIP-4750) 命令を除き、すべての命令のランタイム時のスタックアンダーフローおよびオーバーフローチェックを削除。
-
EIP-7480：EOF - データセクションアクセス命令：バイトコードのデータセクションにアクセス可能にする。
-
EIP-7069：改良されたCALL命令：CALLからのgas可観測性を削除可能にし、将来のgas再価格付けを容易にする。EOFとは独立しているが、これを導入する好機と考える。
EIP-6206：EOF - JUMPFおよび非返還関数については、確定度が低い。EOF関数内での末尾呼び出し最適化を可能にするが、言語側での有用性分析が必要である。これらがない場合、範囲から除外し、後続のEOF更新に含めることも可能と考える。
上記の作業量は、1人あたりフルタイムで1〜2ヶ月程度と見積もる。勢いを維持するために、さらに範囲を狭めることも可能である。
従来のバイトコードに関する注意：
-
新しい従来／非EOFバイトコードの禁止は可能だが、既存の従来バイトコードの非推奨化は不可能であり、これは事実上EOFの「v0」とみなされる。EOF後も従来バイトコードにはJUMPDEST解析が必要であり、Verkle Triesに分割するための特別なコード処理も必要である。
-
私たちの知る限り、ソースコードなしで非EOFバイトコードをEOFに変換する検証可能な方法は存在しないが、そのような変換を促進するメカニズムの探索には前向きである。
-
また、EOFへの状態の強制移行の有効期限方式の検討にも前向きである。
EIP-4844 Blob数量の増加
我々はこの変更に対して前向きである。EIP-4844の文脈では、これはMAX_BLOB_GAS_PER_BLOCKおよびTARGET_BLOB_GAS_PER_BLOCKの増加に相当する：
-
TARGET_BLOB_GAS_PER_BLOCKおよびMAX_BLOB_GAS_PER_BLOCKの目標値は、それぞれブロックあたり3個のBlob（0.375 MB）および最大6個のBlob（0.75 MB）。これらの小さな初期制限は、本EIPがネットワークに与える負担を最小限に抑えることを目的としており、ネットワークがより大きなブロックでも信頼性を示せば、将来のアップグレードで制限を増やすことが予想される。
-
実際には小さなコード変更に過ぎないが、txpoolへの実際の影響を調査する必要がある。EIP-4844のストレステストインフラを再利用できると考える。ただし、CL側でより多くのBlobを伝播するのは難しい可能性があり、CLチームの意見を尊重する。
行うべきでないこと
Verkle Tries
要するに、Verkle triesが2024年末／2025年初頭に展開される道筋は見えない。チームが2024年第2四半期にリソースを割り当て、2025年第2〜第3四半期の大阪ハードフォークでの展開を約束することを提案する。
良い点：
-
より小さなストレージ証明により、軽量クライアントが安価に実現可能。
-
ブロックヘッダーに事前状態の読み取りを含めることでステートレス実行が可能になり、静的状態アクセスによりパフォーマンス向上も可能。
-
バイトコードのチャンク化および部分コード読み込みの有効化により、コントラクトサイズ制限を向上。
-
状態の復元コストが低いため、状態の有効期限切れがより受け入れやすくなる。
悪い点：
-
変更の影響および実装・テストの統合作業の大きさ。
-
Gas計算の変化：Verkle Triesにより、証明のサイズがGas計算関数に組み込まれる。ストレージの価格設定の変化がまだ十分に探求されていない（例：Verkle後、トップレベルのGas消費者がどれだけコストを負担するか？）。
-
アプリケーション統合：オーバーレイ変換実行中に、Merkle Patricia Trie検証器を持つアプリケーションはどのように対応すべきか？eth_getProofの挙動はどうあるべきか？
Verkle Triesの利点は理解しているが、サードパーティツール／コントラクトがどのように調整する必要があるか、および第2層ソリューションなどへの移行の影響についてはさらに検討が必要と考える。当初は移行戦略に懐疑的だったが、既存のMPT（Merkle Patricia Trie）から状態を読み取る際にVerkleツリーを更新するという要求があったためである。しかし、現在は状況が変わったようである。そのため、オーバーレイツリー方式を実現可能な移行パスとして支持する。
Verkleツリーの移行戦略に関するドキュメントは一般的に古く、多くのリソースは依然としてMPTから状態を読み取る際にVerkleツリーを更新すると主張しているが、実際にはそうではない。主要な移行ドキュメントが最新の方法に更新されることを望んでおり、例えばこの優れたドキュメントのようにあるべきだと考える。また、移行戦略に関する草案EIP（Ethereum Improvement Proposal）の策定も期待している。
したがって、2025年の展開は支持するが、プラハでのシステム展開は不可能と考える。
L1 Gas制限
誘発需要のため、L1 gas制限を引き上げても実際にはほとんど効果がないと考える。また、ほとんどのクライアントは平均負荷の増加に対処できると考えるが、最悪のケースに対して警戒を怠らないため、現時点ではL1 gas制限の増加を提案できない。短期的にはblob gas制限の拡大の方が有望な解決策と考える。
この分野の研究に協力してくれる人材を募集する。通常はEVM内のリソース計量の破綻に関するものである。「Broken Metre」論文は、この研究方向の良い出発点である。
アカウント抽象化
1つまたは複数のこれらのEIP（またはERC）を含めることに前向きであるが、各提案のユーザーエクスペリエンスおよび開発者エクスペリエンスの比較をもっと見たい。これにより、ツール統合のトレードオフ空間および作業量をよりよく理解できる。以下のEIP／ERCに注目しているが、他にも推薦があれば歓迎する：
なお、上記のうち「アカウント抽象化」とは、「検証関数の抽象化」を指し、主な目標は鍵のローテーション、マルチシグをファーストクラスの技術にすること、そして量子耐性への自動的パスを提供することであり、これらは4337および7560に限定される。他の提案は「Gasスポンサーシップ」と「一括操作」の二つに分類される。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
Paradigm
