Ethereumコア開発者がプロセスとFusakaのタイムラインをめぐって対立

Ethereumの最新のAll Core Devs会議では、コードだけでなくプロセスにも焦点が当てられました。Fusakaアップグレードが進行する中で、クライアントリリースと最初のテストネットフォークの間に以前から示されていた30日間の猶予期間を守るべきかどうかが議論されました。一部の参加者は、インフラストラクチャやアプリチームが適応する時間を確保するためにこの約束を再確認するよう求めましたが、他の参加者は、より広範なロードマップの遅延を避けるために柔軟性を持たせるべきだと主張しました。

この議論は、混在したdevnetの結果を背景に展開されました。Dev OpsチームのBarnabas Busaによると、Devnet-3では計画されていた非ファイナリティ演習が長引きました。「最初は約2日間を予定していましたが、今は5日目に突入しています」と彼は述べ、参加率が一時的に低下した後、再び50％を超えたことに言及しました。ファイナリティには、全有効ステークの3分の2以上の同意が必要です。

対照的に、別のテストネットは協調的な再起動後に迅速に回復しました。「チェーンは、おそらく2時間以内に回復しました」とBusaは述べました。この訓練は、ライブインシデントで変数がどのように相互作用するかをプレッシャーテストし、Ethereumが危機時に回復するのに役立ちます。

Read more: EthereumのFusakaアップグレードは遅延する可能性があります

今後数日で修正が行われる予定で、短期的な計画としてはDevnet-3を完全な状態に戻し、テストを再実行した後、Devnet-5を立ち上げることです。

しかし、より大きな争点はパブリックネットワークのスケジューリング規律でした。Lightclientは既存の約束を強調しました。「最初のテストネットの30日前と明記されています。」彼は、コア開発者が他のチーム（このコールに参加していない）の必要な時間を評価して便宜的に目標を動かすことに警鐘を鳴らしました。

実際的な懸念は、ハードフォークの進行ペースをどのように改善するかです。テスト間の間隔を短縮すればフォークを加速できますが、下流チームが急いでアップデートを出すリスクが高まります。一方で、パイプラインが長引けば、キューにある他のすべてが遅れるため、Ethereumコミュニティ全体が不満を抱く可能性があります。

「私は、コミュニティが必ずしも望むものに基づいてタイムラインを選ぶべきではないと思います」とLightclientは述べました。「ソフトウェアを出荷する人たちは、コミュニティが使う高品質なソフトウェアを提供するために30日間が必要だと言っています。」

それでも、やや緊張感のあるやり取りは、ステークホルダーが明確に変更を求めない限り、書面によるプロセスを維持する方向に流れました。

また、毎回同じ質問を繰り返すことへのフラストレーションもありました。「決定を変え続けるのは本当に悪い前例だと思います」とLightclientは述べ、アプリ開発者やL2は通常コアコールに参加しておらず、自分たちのリリースをスケジューリングするために予測可能な期間に依存していると指摘しました。

現時点では、30日間のバッファが有効であるかのように進めつつ、新たな意見を積極的に求めるというのがコンセンサスだと、コーディネーターのTim Beikoは述べました。「[プロセス]ドキュメントに記載されている内容でスケジュールを準備し、並行して影響を受けるステークホルダーに確認すべきです。」もし迅速な対応に広範な支持がある場合は、その旨を文書化することになります。