イーサリアム、SepoliaでのGlamsterdamを10月6日に目標

ACDC #186の会議メモと、その後のイーサリアムプロトコル研究者クリスティーン・D・キム氏の報告によると、この日付は依然として条件付きだ。開発者らは、Sepoliaのスケジュールを選択した時点で、プライベート開発ネットワーク上でのGlamsterdamの安定したアクティベーションを完了していなかった。

テスト計画はその後、さらに1イテレーション進んでいる。キム氏は9月11日、注目はGlamsterdam-Devnet-11に移っており、9月14日月曜日にローンチ予定だと述べた。以前の計画では、次の主要テストとしてDevnet-10が特定されていた。

Hoodiテストネットやイーサリアムメインネットのアクティベーション日はまだ確定していない。開発者らは12月のメインネットリリースの可能性を議論しているが、テスト結果によってそのスケジュールが現実的かどうかが決まる。

9月3日のAll Core Developers Consensus会議で、参加者は提案されたアクティベーションについてSepoliaエポック351232に合意した。キム氏は、対応する時刻は10月6日13:53 UTCになると報告した。この会議は、開発者らがGlamsterdamに使用されるプライベートテストネットワーク全体で安定したパフォーマンスを実証する前に開催された。

エポックを選択することで、クライアントチーム、インフラ運営者、アプリケーション開発者に共通の計画目標が提供される。しかし、これでアクティベーションが最終決定されるわけではない。次のテスト段階で重大な障害が発見された場合や、クライアントチームが信頼性の高いリリースを準備できない場合、開発者らはフォークを延期できる。

この注意事項は、Devnet-9でファイナリティ問題が発生した後も依然として重要だ。会議資料によると、このネットワークには約1,000のバリデータノードが含まれており、その段階ではバリデータ数で最大のGlamsterdam devnetだった。

ファイナリティには、チェーンの状態について十分な数のバリデータが合意する必要がある。テストネットワークがファイナライズできない場合、開発者らは原因がクライアントソフトウェア、バリデータの参加、ネットワーク構成、または別々のプロトコル変更間の相互作用にあるのかを特定しなければならない。

Devnet-11がSepolia前に修正をテスト

当初の計画では、以前の試験で障害が発生した後、Devnet-10が予定されていた。キム氏の最新のアップデートでは、開発者らが注目している次のテストとしてDevnet-11が特定されており、プライベートテストのシーケンスが以前の計画を超えて進んだことを示している。

安定したDevnet-11は、イーサリアムクライアントチームに、統合されたGlamsterdam仕様をテストするためのもう一つの環境を提供する。レイヤー2チーム、ステーキングプロバイダー、その他のインフラ運営者は、提案されたフォークに対して自社システムを安全にテストする前に、動作するクライアント実装を必要とする。

クライアントの多様性はプロセスをより複雑にする。イーサリアムは、独立して開発された複数の実行クライアントとコンセンサスクライアントを通じて動作しており、アップグレードは異なるクライアントの組み合わせ全体で機能しなければならない。1つの実装に限定された障害でも、影響を受けるバリデータが十分な重みを持つ場合、テストネットワークを中断させる可能性がある。

ACDC #186の議題には、LidoとOptimismからの、フォーク前に少なくとも1日安定した状態を求める要請が記録されている。議題では、Sepolia前に確認が必要な事項として、クライアントの修正と相互運用性の成功が挙げられていた。

Devnet-11が失敗または不安定になったとしても、10月6日のアクティベーションが自動的にキャンセルされるわけではない。開発者らは原因と修復に必要な時間を評価する必要がある。深刻な問題が発生した場合、All Core Developers会議で日付を再検討する可能性がある。

コンセンサスとEIP-8037のバグでテストが延長

以前のGlamsterdam試験では、イーサリアムのアーキテクチャの両側で障害が明らかになった。イーサリアム財団の開発者オペレーションエンジニア、ステファン・スターフリンガー氏は、Devnet-8で親ハッシュを繰り返すブロックに関するコンセンサスレイヤーの問題が明らかになったと報告した。

「ネットワーク全体を停止させることができた」とスターフリンガー氏はテストシナリオを説明しながら述べた。

この問題はブロック合意を担当するシステムに影響を与えた。その後、Devnet-9は非ファイナリティに陥り、エンジニアらはより大規模なバリデータセットでさらに多くのエッジケースを調査することになった。

実行側では、イーサリアム財団の研究者マリア・シルバ氏が、EIP-8037に関する実装上の問題を報告した。この提案は、新しいアカウント、コントラクト、ストレージエントリを含む新しい状態の作成に対してイーサリアムがガスを請求する方法を変更するものだ。

EIP-8037は、多次元ガスモデルを通じて状態作成コストを通常の実行コストから分離する。公開された仕様によると、この設計はイーサリアムがブロックガスリミットを引き上げる際に状態の増加を制御することを目指している。この提案は現在もピアレビュー中だ。

発見された問題により、実行クライアントは実装を修正する必要があり、仕様の作業につながった。EIP-8037は、アップグレードの他のプロトコル変更とともにテストされてきた。

テストは、各提案を個別に承認することとは異なる目的を持つ。開発者らは、選択されたすべての変更が、複数のクライアント、バリデータ構成、トランザクションパターンにわたって一緒に動作することを確認しなければならない。

Hoodiとメインネットの日付はテスト結果次第

開発者らは、Sepoliaが条件付きのままである間、HoodiでのGlamsterdamのスケジュールを設定することを見送っている。Hoodiは2番目のパブリックテストネット段階として機能し、ステーキング運営者やプロトコルチームに、メインネットの状況をより忠実に表すもう一つの環境を提供することが期待されている。

Tekuの開発者エンリコ・デル・ファンテ氏は、Hoodiの日付を確定する前に待つことを支持した。ACDC #186で、同氏は最近のDevnet-9の問題を挙げ、Sepoliaの決定後により多くのテスト時間を確保することを支持した。

12月のメインネットアクティベーションは、確定したローンチウィンドウではなく、可能性のある目標のままだ。Sepoliaを10月初旬にスケジュールすることで、テストが長引くことなく進めば、もう一つのパブリックテストネット段階とクライアントリリースの準備に十分なカレンダー上の時間が確保される。

開発者らは、メインネットのエポック、アクティベーションタイムスタンプ、最終的なクライアントリリーススケジュールを公開していない。10月6日がSepoliaに適しているかどうかを決定するための正式な期限も発表されていない。

直近の手続き上のイベントは、9月14日に予定されているDevnet-11のローンチだ。クライアントチームは、現在のスケジュールでSepoliaを進められるかどうかを判断する前に、ファイナリティ、クロスクライアントの動作、以前のテスト後に導入された修正を検証する。