Ethereum 開発者は、今後のネットワークアップグレードのスケジュールを最終決定しました。主要な変更は、2月24日、3月5日、4月8日に実施される予定です。主要な決定は、2025年2月13日に開催されたAll Core Developers Execution (ACDE) Call 205で最終決定されました。.
隔週で行われるZoom会議で の議論は が主導した Ethereum 。開発者らは、Pectraのアップグレードが2月24日にHoleskyテストネットで有効化されることを確認した。その後、3月5日にSepoliaテストネットが稼働する予定だ。
両方のロールアウトがスムーズに進めば、 Ethereumのメインネットは4月8日頃にアップグレードを受け取ることになる。.
ベイコ氏は、両方のテストネットにPectraシステム契約を展開するためのtracを見つけるためにチームと調整すると述べた。.
将来の Ethereum フォークとアップグレード速度に関する議論
さらに、開発チームはPectraとFusakaに続く次のアップグレード計画について議論した。Beikoは、 を提案した PectraがメインネットでローンチされるまでにFusakaのスコープを固定すること
このタイムラインにより、開発者は Fusaka の作業を開始しながら、後続のハードフォーク Glamsterdam の計画も立てることができます。.
Geth開発チームはこのタイムラインでの作業を望んでいません。彼らは、Fusakaのスコープを確定させるには時期尚早だと主張しています。Fusakaに Ethereum 改善提案（EIP）のEOFが含まれていることは、大きな議論を巻き起こしました。一部の開発者は、今後のアップグレードからEIPを除外すべきだと主張しています。.
EOF（Ethereum Object Format）は、 アップグレード スマートコントラクトtrac上でどのように構築され、実行されるか Ethereum 。
Gethの開発者であるLightclient氏は、Fusakaのスコープ凍結の加速化に反対した。同氏は、 Ethereumの優先順位は今後2年間で変化する可能性があると主張している。開発者は6ヶ月ごとのアップグレードサイクルを目指しているものの、実際の遅延によって8ヶ月以上かかる可能性もあると指摘した。 つまり、重要な改善が何年も実現されない可能性があるということだ。
Lightclientは、EOFの組み込みに関して懸念を表明し、 Ethereumのゼロ知識ロールアップ技術（zkEVM）の急速な進歩を強調しました。開発者は、これらの変更が仮想マシンとどのように相互作用するかについて、依然として不明な点を抱えています。.
議論の中で、Geth開発者のMarius van der Wijden氏は、Fusakaの推奨スコープとしてPeerDAS、FOCIL、EOF、そしてmodexpの上限を挙げました。EF開発オペレーションエンジニアのParithosh Jayanthi氏は、FOCILはPeerDASやEOFほど実装の準備が整っていないと反論しました。.
Pectraソフトウェアテストネットのアップグレードとコミュニティからのフィードバック
開発者たちはFusakaに関する意見の相違を乗り越え、進行中の Pectraの展開。EF 開発・運用エンジニアのParithosh Jayanthi氏は、Pectra Devnet 6は順調に稼働しており、バリデーターの参加率はほぼ完璧だと報告した。
さらに、 Ethereumの Ephemery テストネットは、ACDE コールの数時間後に Pectra アップグレードを有効化し、開発者がさらなるテストを実施できるようになりました。.
上で提案を「最終段階」に移行するよう要請した GitHub。 からのフィードバックも調査した Ethereum 。その結果、最も多かった要望はアップグレードサイクルの加速化だったと指摘した。
これに応えて彼は、 Ethereum 開発者は、前回のアップグレードがメインネット上で稼働したらすぐに、各アップグレードの範囲を最終決定することを目指すべきだと提案した。.
ベイコが 提示した Fusakaのスコープ確定スケジュールによると、3月13日までに開発者はアップグレードに含めるEIPを提案する必要があります。その 2週間後の3月27日には、クライアントチームがFusakaで検討すべきEIPに関する希望を共有します。そして最終的に、4月10日までにアップグレードのスコープが確定します。
しかし、EF研究員のアンスガー・ディートリヒス氏は、このタイミングに例外を設けました。彼は、Pectraアップグレードの重要なコンポーネントであるPeerDASコードの改善は、完了次第、 Ethereum メインネットにアップロードする必要があると指摘しました。この要件に異議を唱える者はいませんでした。.
EELSとEIPの試験基準に関する懸念
ACDEの会議中に懸念されたもう一つの点は、EFテストエンジニアのマリオ・ベガ氏からの提案でした。これは Ethereum 実行層のテストフレームワークに関するものでした。ベガ氏は、ハードフォークに含まれるすべてのEIPにEELS（Ethereum 実行層仕様）とEEST（Ethereum 実行仕様テストケース）を必須にすることを提案しました。.
これにより、テストのワークフローが改善され、EIP の採用前の評価方法が標準化されるだろうと彼は示唆しました。.
しかし、複数の開発者がこの提案に反対しました。その理由は、この要件によってアップグレードプロセスが遅延する可能性があるためです。Van der Wijden氏は、EELSメンテナーがEIPの組み込みにおける事実上のゲートキーパーになる可能性があると主張しました。なぜでしょうか？すべての開発者が、提案のPythonベースの実装を作成できるわけではないからです。.
Wijdenは別の方法を提案した。ETHは、 EELSの実装を 。こうすることで、EELSチームがアップグレードに対する最終承認権限を持つことを防ぐことができる。
のJustin Florentine氏は、 Ethereum コミュニティに対し、追加のスクリプト言語の作成を検討するよう助言しました。これにより、EELSやEESTのテストケースなしでEIPを組み込むことができるかどうかが明確になります。
