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

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

隔週のズーム会議議論 Ethereum Foundation（EF）プロトコルのリードTim Beikoが率いていました。開発者は、2月24日にペクトラのアップグレードがHolesky TestNetでアクティブ化されることを確認しました。その後、Sepolia TestNetは3月5日に上昇します。

両方のロールアウトがスムーズに進むと、Ethereumのメインネットは4月8日頃にアップグレードを受け取ります。

Beikoは、チームと調整して、両方のテストネットにPectraシステム契約を展開するためのボランティアを見つけると述べました。

将来のイーサリアムフォークとアップグレード速度に関する議論

さらに、開発者チームは、ペクトラとフサカの後に次の計画的なアップグレードについて議論しました。ベイコ提案ペクトラがメインネットで発売されるまでにフサカの範囲を凍結します。

タイムラインにより、開発者はフサカでの作業を開始すると同時に、その後のハードフォークグラムスターダムを計画することができます。

Geth Developmentチームは、このタイムラインで作業したくありません。彼らは、フサカの範囲を固めるのは時期尚早だと主張しています。フサカにイーサリアム改善提案（EIP）EOFを含めることは、かなりの議論を引き起こしました。開発者の派factは、今後のアップグレードから除外されることを主張しています。

EOF（Ethereum Object Format）は次のとおりですアップグレード Smart ContractsがEthereumブロックチェーンで構造化および実行される方法を改善することを目的としています。

Gethの開発者LightClientは、Fusaka Scope Freezeのスピードアップに反対しました。開発者は、イーサリアムの優先事項が今後2年間にわたって変化する可能性があると主張しています。彼は、開発者が6か月のアップグレードサイクルを目指しているが、実際の遅延は8か月以上にわたって伸びる可能性があると指摘した。これは、重要な改善が何年も実装されない可能性があることを意味します。

LightClientは、EOFの組み込みに関する懸念を提起し、Ethereumのゼロ知識ロールアップテクノロジー（ZKEVMS）の迅速な進歩を強調しました。開発者は、仮想マシンとのこれらの変更の相互作用に関して暗闇のままです。

議論の中で、Gethの開発者Marius van der Wijdenは、ModexpのPeerdas、Focil、EOF、上限を含むフサカの好みの範囲をリストしました。 EF開発者オペレーションエンジニアのParithosh Jayanthiは、PeerdasやEOFほど実装の準備ができていないと焦点を当てていると述べました。

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

開発者は、継続することに自信を表明するために、フサカに対する意見の不一致を乗り越えましたペクトラの展開。 EF開発およびオペレーションエンジニアのParithosh Jayanthiは、Pectra Devnet 6が順調に機能しており、ほぼ完璧なバリデーターの参加率があると報告しました。

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

BeikoはPectra EIPの著者に提案を「最後の呼び出し」フェーズに移動するように頼みました github。これは、メインネットの実装の前の最終ステップを示します。彼はまた、イーサリアムコミュニティからのフィードバックを調べました。そのために、彼は最も一般的な要求はアップグレードサイクルを加速することであることに注目しました。

これに応じて、彼は、イーサリアム開発者が、前のアップグレードがメインネットでライブになるとすぐに、各アップグレードの範囲を完成させることを目指すべきだと提案しました。

フサカの範囲を確定するためのBeikoが提案したタイムラインは、3月13日までに、開発者がアップグレードに含めるためにEIPを提案しなければならないと述べています。 2週間後の3月27日、クライアントチームは、Fusakaに対してEIPを検討すべきEIPSを好みます。最後に、4月10日までに、アップグレードの範囲が確定されます。

ただし、EFの研究者Ansgar Dietrichsは、タイミングの例外を追加しました。彼は、Pectraアップグレードの重要なコンポーネントであるPeerdasコードの改善は、完了したらすぐにEthereum Mainnetにアップロードする必要があることに注目しました。誰もこの要件に反対しませんでした。

ウナギおよびEIPテスト基準に関する懸念

ACDEコール中のもう1つの懸念事項は、EFテストエンジニアのMario Vegaからの提案でした。これは、Ethereum実行レイヤーテストフレームワークに関してもたらされました。 Vegaは、Hard Forkに含まれるEIPについて、ウナギ（Ethereum実行層の仕様）とEEST（Ethereum実行仕様テストのケース）を作成することを提案しました。

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

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

Wijdenは別のアプローチを提案しました。 ETHがあるはずですウナギの実装これは、マージドプルリクエストとして提出することができます。これにより、EELSチームはアップグレードに対する最終承認能力を持つことができなくなります。

EthereumクライアントのBesuとJustin Florentineは、コミュニティに追加のスクリプト言語の作成を検討するようにアドバイスしました。これにより、EIPがウナギまたはEESTテストケースなしで含めることができるかどうかを明確にします。