第203回イーサリアムACDEミーティング：イーサリアムはPectraアップグレードで相場を押し上げられるか？
TechFlow厳選深潮セレクト
第203回イーサリアムACDEミーティング：イーサリアムはPectraアップグレードで相場を押し上げられるか？
第203回イーサリアムACDE会議では、Pectra Devnet 5の開始、仕様の更新、テストネットのアップグレード計画に注力し、メインネットのアップグレードとエコシステム協働を新たな段階へと推進しました。
Web3業界の深掘り報道に専念し潮流を洞察翻訳：白話ブロックチェーン
2025年1月16日、イーサリアムプロトコル開発者はZoomを通じて第203回All Core Developers Execution（ACDE）会議を開催した。今週の会議は、イーサリアム財団（EF）プロトコルサポート責任者のTim Beikoが進行を担当した。ACDE会議は隔週で行われる定例会議であり、開発者たちはそこでイーサリアム実行レイヤー（EL）に関する変更について議論および調整を行っている。
第203回ACDE会議では、Pectra Devnet 5の起動や未完了のPectra仕様の更新について話し合われた。また、Holeskyテストネットでのガスリミット引き上げテストの次のステップ、RPC標準化の進捗、ノードの最低ハードウェア要件および帯域幅要件の明確化についても議論された。
1. Pectra Devnet 5 の起動
開発者らは会議開始の30分前にPectra Devnet 5を起動した。イーサリアム財団の開発者オペレーションエンジニアであるParithosh Jayanthiは、開発ネットワーク内でガス推定の問題を発見し、関連ログを収集してイーサリアム開発Discordチャンネルに共有する予定だと述べた。
2. Pectra 仕様の更新
開発者たちは、Pectraコード仕様における5つの未完了な更新について議論した。
1）EIP 7623：Calldataコストの追加
最初の更新は、ガス払い戻しの処理方法を明確にするためのEIP 7623の修正である。この更新はすでにGitHubでマージされており、Pectra Devnet 5のテストに含まれている。
2）EIP 7840：実行クライアント設定ファイルへのBlobスケジューリングの追加
2つ目の更新は、EIP 7840におけるベースフィー分数に関する問題である。会議では反対意見はなく、開発者たちは1月20日（翌週の月曜日）のPectraテスト会議までに、関連変更をGitHubにマージすることで合意した。
3）Blobベースフィーの更新
3つ目の更新もまたBlobベースフィーに関連し、Pectraアクティベーション期間中の超過ガスの計算方法に関するものである。イーサリアム財団の研究責任者Alex Stokesは、この計算は前のブロックヘッダーの情報を前提としていると説明した。もしBlob容量の変更がフォーク境界（Pectraアクティベーションブロック）で有効になる場合、超過ガスの計算は旧フォークロールで構築された前ブロックの情報に基づくことになる。Stokesは、Blob容量の増加がフォーク境界で有効になるか、それともフォーク境界の次のブロックで有効になるかを明確にする必要があると指摘。「どちらを選んでも本質的な違いはないが、統一された方法が必要だ」と述べた。開発者たちは、EIP 7691を明確化し、Blob容量の増加をフォーク境界の1ブロック後に有効とすることで合意し、これにより新フォークロールのみを使用した計算が可能となる。イーサリアムテスト開発者Mario Vegaは、クライアント側でこのロジックが既にテスト中であると述べた。Geth開発者「Lightclient」は、翌週月曜日のテスト会議までにEIP 7691を更新すると約束した。
4）EIP 2537：BLS12-381曲線演算のプリコンパイルコスト計算
4つ目の更新は、EIP 2537における乗算コストの計算に関するものである。開発者たちは、計算を整数除法として明示することを仕様に記載することで合意した。Pectra Devnet 5のテストを通じて、クライアントチームはすでにコードレベルでこのロジックを実装しているため、仕様文書の修正のみが必要である。イーサリアム仮想マシン開発者のPaweł Bylicaは、GitHub上でEIPの変更を行い、翌週月曜日のテスト会議までに完了させると述べた。
これらの更新を通じて、開発者たちはPectra関連作業の洗練と調整を進め、将来のイーサリアムメインネットアップグレードの準備を着実に進めている。
5）最後の5つ目の更新はEIP 7702に関連しており、外部アカウント（EOA）が永続的にコードを設定できる新しいトランザクションタイプを追加する提案である。Otim LabsのCOOであるJulian Rachmanは、このEIPに対する動作変更の提案として、コード内省（code introspection）機能の導入を提示した。Otim Labsチームが作成したドキュメントによれば、コード内省とは、従来のコントラクトが自身または他のコントラクトのバイトコードをチェックし、その情報に基づいて動作を調整できる能力を指す。
イーサリアム仮想マシンオブジェクトフォーマット（EOF）開発チームは、将来的なイーサリアムアップグレードにおいてコード内省を無効にする計画を持っているが、ドキュメントおよび会議では、EOAの「delegate_address」を確認するためにコード内省を有効にしても、EOFの開発プロセスを妨げるものではないとされている。EIP 7702タイプのトランザクションの委任アドレスをコード内省で確認できるようにすることで、GasスポンサーシップなどのEIP 7702機能を活用しつつ、リレーヤーや他の外部アカウントを安全に使用することが可能になるという利点がある。
Geth開発者の「Lightclient」は、Pectra仕様にこの更新を含めることを支持し、「この更新は非常に簡単に実装できる。すでにEIP 7702の委任アカウントかどうかを判定しているため、返送アドレスを指定するのは簡単な追加処理にすぎない」と述べた。会議司会のBeikoは、参加者に対して変更内容をさらに数日間検討した上で最終仕様への採用を判断するよう呼びかけ、翌週月曜日のテスト会議で再議論することを提案した。
Beikoはまた、Rachmanのチームに対し、すべてのEIP 7702変更提案を含む正式なプルリクエストをGitHubに提出するよう求めた。この更新のために新しいPectra開発ネットワークを立ち上げる必要があるかどうかについて、Jayanthiは、変更はパブリックテストネットのシャドウフォークに含めることができ、新しい開発ネットワークの起動は不要であると述べた。Beikoは、今回の会議で議論された他のすべての仕様更新についても同様に新たなPectra開発ネットワークは不要であり、開発者たちはPectra Devnet 5のさらなるテスト終了後、パブリックテストネットの更新作業を進められると補足した。
3. Pectra システムコントラクトの監査更新
イーサリアム財団（EF）プロトコルセキュリティ研究員のFredrik Svantesは、Pectraシステムコントラクトに関する第三者による監査がすべて完了したと報告した。重大な問題は発見されておらず、監査レポートはGitHubにアップロードされ、クライアントチームが閲覧できるようになる。Svantesは、次回のACDE会議で専用の時間を設け、監査担当者が結果を発表し、クライアントチームの質問に答えることを提案した。
4. Pectra テストネットアップグレード計画
Tim Beikoは、テストネットのアップグレードに関する初期タイムラインを提示した。彼は、今後2回のACD会議で、SepoliaおよびHoleskyテストネットのアップグレードに使用するブロック高を決定し、2025年2月3日までにクライアントリリースの準備を完了することを提案した。Sepoliaのフォークは2月12日週に行い、その後Holeskyのフォークを2月19日週に行う予定である。重大なバグや問題がなければ、Pectraアップグレードは3月初旬から中旬にかけてメインネットへ導入される見込みであり、これはHoleskyフォークから3〜5週間後となる。この提案に対し、会議中に異論はなかった。Stokesは、クライアントリリースをSepoliaおよびHoleskyテストネットのアップグレードと連動して推進することを提案した。
5. Holesky のガス制限
EFの汎用エンジニアSophia Goldは、Holeskyアップグレードリリースにおけるクライアントのデフォルトガス上限を3600万（36m）に設定することを提案し、Holeskyのデフォルトガス上限を引き続き引き上げ、常にイーサリアムメインネットのガス上限を超えるように維持すべきだと述べた。これにより、メインネットのガス上限引き上げがHoleskyで事前にテスト可能になると説明した。この提案に対しても異論はなかった。Teku、Besu、Prysm、Nethermindの各チーム代表は、すでに自らのHoleskyクライアントリリースでデフォルトガス上限を3600万に設定済みであると述べた。
6. RPC 標準化の取り組み
Geth開発者のFelix Langeは、クライアントチームがイーサリアムJSON-RPC仕様の標準化努力に対して十分なフィードバックを提供していないことに失望を表明した。会議では、RPC標準化の範囲や関与すべきエコシステム関係者が明確に定義されていないことが課題として挙げられた。Langeは自身のブログ記事で、標準化の取り組みと今後の提案について詳しく説明している。Beikoは、この問題についてDiscord上でさらなる議論を行い、特別ディスカッション会議を設定することを提案した。Besu開発者のJustin Florentineは、この特別会議の日程調整を担当すると述べた。
7. ノードのハードウェアおよび帯域幅要件の仕様化
EFアプリケーション研究員のKevaundray Wedderburnは、イーサリアムノードの最低ハードウェアおよび帯域幅要件に関する自身のドキュメントに対するフィードバックを求めた。Beikoは、これらの要件を情報提供目的のEIP（Informational EIP）として策定すべきかどうかを尋ねた。これにより、開発者やより広範なイーサリアムコミュニティが参照できるようになる。Prysm開発者「Potuz」は、バリデーターノードとフルノードではハードウェア要件が異なるため、ドキュメントでは両者を明確に区別すべきだと指摘した。BeikoはPotuzの意見に同意し、ノードのハードウェアおよび帯域幅要件、ならびにWedderburnのドキュメントの正式化に向けた次のステップについて、Discord上でさらなる議論を行うことを提案した。
8. EIP 編集者ワークショップ
最後に、EIP編集プロセスに関する特別ワークショップの開催が言及されたが、具体的な内容や日時については未定であり、今後の会議で詳細が議論される可能性がある。
イーサリアムキャットハーダーズ（Ethereum Cat Herders）チームは、2025年1月17日16:00（UTC）にEIP編集者ワークショップを開催する予定である。この会議ではEIP編集プロセスの概要が紹介され、EIPのワークフローおよび編集プロセスに関心を持つすべてのイーサリアムコミュニティメンバーの参加が歓迎される。会議の録音は後日YouTubeに公開される予定である。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@galaxyhq
