Cabinet
テクノロジーインサイト一覧へ戻る
2026.08.20

Glamsterdam の Sepolia フォーク日が epoch 351232 で提案 ― ただし議事は「決定は次回」と明記している

Glamsterdam の Sepolia フォーク日が epoch 351232 で提案 ― ただし議事は「決定は次回」と明記している

何が起きたか

ACDC（All Core Developers – Consensus）は、コンセンサスクライアントの各チームがタイミング・不具合・テストネットの扱いを詰める定例会議で、議事録とチャットログはプロジェクトのプランニングリポジトリに公開される。2026年8月20日に開かれた第185回の議事には、フォーク状況の項に Sepolia の Glamsterdam フォークとして epoch 351232、slot 11239424、2026年9月28日が記され、異論なしと書かれている。同じ文書の目標一覧にも同じ行が現れ、そこには次回 ACDC での確認待ちという注記が付く。

数字の整合は自分で検算できる。Ethereum のコンセンサス層は1エポック32スロット、1スロット12秒である。351232 × 32 = 11,239,424 でスロット番号と一致する。Sepolia のビーコンチェーン・ジェネシス（2022年6月20日 22:00:00 UTC）からスロット番号 × 12秒を足すと、2026年9月28日 14:44:48 UTC に一致する。日本時間では同日23時44分48秒。エポックとスロットと時刻が三者とも矛盾しないので、少なくとも算出そのものは正しい。

Hoodi については epoch 132352 / slot 4235264 で10月26日が示された。こちらも 132352 × 32 = 4,235,264 で整合する。同じ方法で Hoodi のジェネシスから逆算すると 2026年10月26日 17:42:48 UTC になるが、報じられているのは日付までであり、時刻は本記事による導出である。

メインネットの日付は依然として存在しない。目標は第4四半期で、当初の2026年上期から二度後ろ倒しされている。

なぜ公開テストネットが二つ必要なのかも、日程を読むうえで押さえておく価値がある。Sepolia は許可制のバリデータセットを持ち、比較的小さく制御しやすい環境として、アプリケーションとツールの適合性を確かめるために使われる。Hoodi はより大きく本番に近いバリデータ構成を意図した網で、ステーキング運用やクライアント多様性の検証がここで効く。Glamsterdam のヘッドライナーである ePBS は、提案者・ビルダー・バリデータの三者が絡む変更なので、Sepolia を通っただけでは検証されない部分が残る。二段構えは冗長ではなく、検証対象が違う。

Sepolia フォークの前段にも作業が残っている。Ethereum Foundation は Platåberget のフィードバック期間ののち、コンセンサスのエッジケースを検証するための非ファイナリティ専用 devnet を、およそ1か月後に立ち上げる予定だとしている。ファイナリティが停止した状態でネットワークがどう振る舞うかは、通常のテストネット運用では再現しにくく、ePBS のように提案経路を変える変更では確認が要る。この devnet の結果が、Sepolia 日程を確定させるかどうかの判断材料になる。

「提案」と「確定」の間に何があるのか

技術記事でいちばん事故が起きるのはこの区別である。ACD プロセスでは、日付は一度の会議で決まらない。提案 → 異論の有無を確認 → 次回で確定、という段取りを踏むのは、参加していないクライアントチームや、その場で判断材料を持たないチームに持ち帰る時間を与えるためである。「異論なし」は「全員が積極的に賛成した」ではなく「その場で反対がなかった」にすぎない。

今回、確定が持ち越された背景には具体的な材料がある。Platåberget（内部的には Glamsterdam devnet-8 としても使われている）で新しいビルダー機能を有効化した直後に、複数のクライアントが停止または遅延したと報じられている。ePBS はブロックを提案する主体と実際に組み立てる主体をプロトコル内で分離する変更で、フォーク前のネットワークは安定していたとされる。つまり不具合は ePBS の有効化そのものに紐づいている可能性が高い。追加の devnet を挟んでから公開テストネットへ進む、という判断はこの観測に基づいている。

ここから読み取るべきは、9月28日が「Ethereum が何としても守る締切」ではないということである。次のテストで深刻な問題が出なければ残る目標日、という位置づけが正確だ。実装者コミュニティの側から見れば、これは望ましい挙動である。日程を守るために不安定なコードを公開テストネットへ流すほうが、はるかに高くつく。

日付の種類を取り違えないために

社内共有で最も頻繁に起きる誤りは、テストネットの適用日をメインネットの適用日として流通させることである。実際、9月2日時点で出回っている一部のカレンダーは、9月28日を ETH のアップグレード日として掲載しており、Sepolia のテストネットフォークであるという但し書きを欠いている。

区別すべき日付は四つある。提案日（8月20日）、確定日（次回 ACDC、未定）、テストネット適用日（Sepolia 9月28日提案、Hoodi 10月26日提案）、メインネット適用日（未定）。このうち、自社の作業期限を紐づけるべきなのはテストネット適用日である。メインネット適用日を待って動き始めると、検証期間が取れない。

想定される落とし穴

第一に、9月28日が動いた場合、連動して動くのは Hoodi の日程だけではない。Sepolia と Hoodi の間隔は現在4週間弱に設計されているが、これは非ファイナリティ devnet の結果次第で伸びうる。「Sepolia の2週間後に社内対応を完了」といった相対期限の切り方は、間隔そのものが可変であることを見落としている。

第二に、epoch と slot が併記されているとき、実際にフォークを駆動しているのはエポック境界である。スロット番号は導出値にすぎない。監視スクリプトをスロット番号のハードコードで書くと、日程変更時に修正箇所が増える。エポック番号を設定値として持ち、スロットは計算で出すほうが壊れにくい。

第三に、Sepolia は許可制バリデータセットを持つテストネットであり、Hoodi はより本番に近い構成を意図した網である。Sepolia で通ったからといって、大規模バリデータセットでの ePBS 挙動が検証されたことにはならない。ステーキング事業者にとって意味のある検証は Hoodi 側にある。

第四に、議事録は「決まったこと」と「議論されただけのこと」を同じ文書に並べて書く。引用するときは、その行に確認待ちの注記が付いているかどうかまで見る必要がある。今回の Sepolia の行には、まさにその注記が付いている。

【技術インサイトとアクション】

  1. ACD プロセスにおける日付は、提案・確認待ち・確定という三つの状態を持ち、公開情報だけでは同じ「日付」として見える。一次ソース（議事録）に戻らずに二次記事から日付を引くと、この状態が落ちる。これは Ethereum に限らず、公開ガバナンスを持つプロトコル全般で同じ構造の誤りを生む。 ［テックリード・社内広報］ 社内にフォーク日程を共有するときは、必ず「提案／確定／適用済み」のいずれかを日付に付記し、一次ソース（ethereum/pm の議事）へのリンクを添える運用にする。次回 ACDC の結果を確認するまでは、9月28日を確定として扱わない。
  2. ePBS の不具合がテストネット段階で表面化したという事実は、ブロック提案経路の変更がクライアント間の合意形成において最も脆い部分であることを示している。同じ前提――提案者と構築者が同一である――に依存している自社の監視・MEV 関連ツールも、同じ箇所で壊れる可能性が高い。 ［ノード運用者・ステーキング事業者］ Sepolia フォークの確定を待たず、9月中に社内のブロック提案監視と MEV 経路のツールを棚卸しし、提案者と構築者が別主体になる前提で再設計に着手する。
  3. テストネット日程は可変であり、公開日程に自社の期限を紐づけるとスケジュールが外部要因で緩む。相対期限（「Sepolia の2週間後」）も、テストネット間の間隔が動けば意味を失う。 ［プロジェクト管理］ メインネット適用日が未定である現時点で、社内の対応完了期限を絶対日付（例：2026年10月末）として先に固定し、テストネット日程の変動から独立させる。

【引用：出典】

本記事は公開情報に基づく技術解説であり、投資助言を目的としたものではありません。