Ethereum ACDEコール205：2月24日、3月5日、4月8日に主要なEthereumアップグレード

Ethereumの開発者は、今後のネットワークアップグレードのスケジュールを確定しました。主要な変更は2月24日、3月5日、4月8日に実施される予定です。重要な決定は、2025年2月13日に開催された最近のAll Core Developers Execution（ACDE）コール205で確定されました。

隔週のZoom会議 議論 はEthereum Foundation（EF）プロトコルサポートリードのTim Beikoによって主導されました。開発者は、Pectraアップグレードが2月24日にHoleskyテストネットでアクティベートされることを確認しました。その後、Sepoliaテストネットは3月5日にアップグレードされます。

両方の展開が順調に進めば、Ethereumのメインネットは4月8日頃にアップグレードを受けます。 

Beiko氏は、両方のテストネットでのPectraシステムコントラクトのデプロイメントのためにボランティアを見つけるためにチームと調整すると述べました。

将来のEthereumフォークとアップグレード速度をめぐる議論

さらに、開発者チームはPectraとFusakaの後の次の計画されたアップグレードについて議論しました。Beiko 提案された Pectraがメインネットで起動するまでにFusakaの範囲を凍結すること。

このタイムラインにより、開発者はFusakaでの作業を開始しながら、その後のハードフォークGlamsterdamの計画を立てることができます。 

Geth開発チームはこのタイムラインで作業したがりません。彼らは、Fusakaの範囲を確定するには時期尚早だと主張しています。Ethereum Improvement Proposal（EIP）EOFのFusakaへの組み込みは大きな議論を巻き起こしました。開発者の一派は、今後のアップグレードからの除外を主張しています。

EOF（Ethereum Object Format）は、 アップグレード Ethereumブロックチェーン上でスマートコントラクトが構造化され、実行される方法を改善することを目的としています。

Geth開発者のLightclientは、Fusakaの範囲凍結を加速することに反対しました。この開発者は、Ethereumの優先順位が今後2年で変化する可能性があると主張しています。彼は、開発者が6ヶ月のアップグレードサイクルを目指している一方で、現実世界の遅延によりそれが8ヶ月以上になる可能性があることを指摘しました。 これは、重要な改善が数年にわたって実装されない可能性があることを意味します。 

Lightclientは、EOFの組み込みに関する懸念を提起し、Ethereumのゼロ知識ロールアップ技術（zkEVMs）の急速な進歩を強調しました。開発者は、これらの変更が仮想マシンとどのように相互作用するかについて不明瞭な状態にあります。

議論の間、Geth開発者のMarius van der Wijdenは、PeerDAS、FOCIL、EOF、およびmodexpの上限を含むFusakaの好ましい範囲をリストしました。EF開発者運用エンジニアのParithosh Jayanthiは、FOCILはPeerDASやEOFほど実装の準備ができていないと反論しました。

Pectraソフトウェアテストネットのアップグレードとコミュニティのフィードバック

開発者はFusakaをめぐる意見の相違を乗り越え、進行中の Pectra展開. に対する自信を表明しました。EF開発および運用エンジニアのParithosh Jayanthiは、Pectra Devnet 6が良好に機能しており、バリデーターの参加率がほぼ完璧であると報告しました。 

さらに、EthereumのEphemeryテストネットはACDEコールの数時間後にPectraアップグレードをアクティベートし、開発者がさらにテストを実施できるようにしました。

Beiko氏は、Pectra EIPの著者に、提案を GitHub. 「最終コール」フェーズに移行するよう依頼しました。 

これはメインネット実装への最終ステップを示しています。彼はまた、Ethereumコミュニティからのフィードバックを検討しました。そのために、彼は最も一般的なリクエストがアップグレードサイクルの加速であることを指摘しました。

Beikoの提案されたFusaka範囲の最終化に関するタイムラインによると、3月13日までに開発者はアップグレードに含めるためのEIPを提案しなければなりません。2週間後、3月27日には、クライアントチームがFusakaで検討すべきEIPに関する好意を共有します。最後に、4月10日までに、アップグレードの範囲が最終化されます。

これに対応し、彼はEthereumの開発者が、前のアップグレードがメインネットで稼働し次第、各アップグレードの範囲をできるだけ早く確定するべきだと提案しました。

しかし、EFリサーチャーのAnsgar Dietrichsは、タイミングに関する例外を追加しました。彼は、Pectraアップグレードの重要なコンポーネントであるPeerDASコードの改善は、完了次第すぐにEthereumメインネットにアップロードされるべきだと指摘しました。この要件に反対する人はいませんでした。

EELSおよびEIPテスト基準に関する懸念 

ACDEコール中の別の懸念点は、EFテストエンジニアMario Vegaからの提案でした。これはEthereum実行レイヤーテストフレームワークに関するものでした。Vegaは、ハードフォークに含まれる任意のEIPに対してEELS（Ethereum Execution Layer Specifications）とEEST（Ethereum Execution Specification Test cases）を必須とすることを提案しました。

彼は、これがテストワークフローを改善し、採用前にEIPが評価される方法を標準化すると提案しました。 

しかし、複数の開発者がこの提案に反対しました。理由は？この要件がアップグレードプロセスを遅らせる可能性があるからです。Van der Wijdenは、EELSメンテナーがEIP採用の事実上のゲートキーパーになる可能性があると主張しました。なぜなら？すべての開発者が提案のPythonベースの実装を書くことができるわけではないからです。 Wijdenは代替アプローチを提案しました。ETHは EELS実装

を持つべきであり、これらはマージされていないプルリクエストとして提出できます。これにより、EELSチームがアップグレードに対する最終承認権を持つことを防ぎます。 Ethereum クライアントBesuを持つJustin Florentineは、コミュニティが追加のスクリプト言語の作成を検討するようアドバイスしました。これにより、EELSやEESTテストケースなしでEIPを含めることができるかどうかを明確にできます。