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

GlamsterdamのSepolia適用候補が10月6日へ——公表されたエポックと時刻が整合しないため、各自で検算が要る

GlamsterdamのSepolia適用候補が10月6日へ——公表されたエポックと時刻が整合しないため、各自で検算が要る

何が起きたか

Glamsterdamは、ePBS（EIP-7732）とブロックレベルアクセスリスト（EIP-7928）を中心とする、Ethereumのマージ以降で最大級のアップグレードである。その最初の公開テストネット適用先がSepoliaで、日程は2段階で議論されてきた。

8月20日のAll Core Developers Consensus（ACDC）#185の議事には、Sepoliaへの適用としてエポック351232、スロット11,239,424、2026年9月28日が提案され、異議は出ず、決定は次回のACDCへ持ち越されたと記載されている。続く9月3日のACDC #186で、参加者はSepoliaの適用エポックとして351232に合意したと報じられた。ところが、このとき示された対応時刻は10月6日13:53 UTCである。Ethereumのプロトコル研究者Christine D. Kim氏の要約を引用した報道が、この時刻を伝えている。

さらに9月10日時点で、Kim氏は日程に付された留保はなお有効であり、注目すべきはDevnet-10ではなく9月14日に立ち上がるGlam-Devnet-11だと述べている。報道によれば、Devnet-11は約84,000バリデータ規模で立ち上がり、その2日後にGloasフォークを実施する計画である。HoodiテストネットおよびメインネットのHoodi適用日は未確定で、12月のメインネット適用が議論されたにとどまる。

公表された数字を検算する

Sepoliaのビーコンチェーン創世時刻はUNIX時刻1655733600、すなわち2022年6月20日14:00:00 UTCである。スロットは12秒、1エポックは32スロットなので、エポックnの開始時刻は創世時刻に384n秒を加えた値になる。

エポック351232について計算すると、開始スロットは351232×32＝11,239,424で、ACDC #185の議事にあるスロット番号と一致する。開始時刻は2026年9月28日14:44:48 UTCとなり、こちらも当初提案の日付・時刻と正確に一致する。つまりACDC #185の記載は内部的に整合している。

問題は10月6日13:53 UTCである。同じ式で逆算すると、この時刻は創世から数えて353023.9エポック目に相当し、エポック境界に落ちない。エポック境界でない時刻にフォークが設定されることはないため、この組み合わせはそのままでは成立しない。同じ時刻帯でエポック境界になるのは353032（2026年10月6日14:44:48 UTC）で、これは351232のちょうど1800エポック後、日数にして8日後である。

したがって、報じられている「エポック351232＝10月6日13:53 UTC」は、エポック番号か時刻のいずれかが正しくない。最も素直な解釈は、ACDC #186でエポックが1800だけ後ろ倒し（おそらく353032）にされ、報道がエポック番号を#185時点のまま引き継いだ、というものである。断定はできないが、少なくとも「公表された2つの数字をそのまま自社のカレンダーに入れると、8日ずれる可能性がある」という点は確実に言える。実際に作業を組む担当者は、Ethereum PMリポジトリの議事とクライアントのリリースノートに記載されるフォークエポックを、報道ではなく原文で確認する必要がある。

この検算は特別な作業ではない。必要なのは、対象ネットワークのビーコン創世時刻、スロット時間、エポックあたりのスロット数の3つだけである。Sepoliaは1655733600／12秒／32スロット、Hoodiは創世時刻が異なるがスロット構成は同じ、メインネットも同様である。フォーク日程を扱うチームは、この3値を定数として持ち、エポック番号を入れれば時刻が出る小さなスクリプトを用意しておくだけで、報道の転記ミスに引きずられなくなる。逆に言えば、この検算をしていないチームは、外部の要約の正確さに運用を賭けていることになる。

devnetで何が詰まっているか

日程が動いている理由は明快で、Glamsterdamはまだどの私設devnetでも安定した適用に成功していない。報道によれば、直近のdevnetテストではコンセンサス層と実行層の双方でバグが表面化しており、そのうちの一つはEIP-8037の実装に関連する問題だとされる。EIP-8037はGlamsterdamのガスモデル変更に関わる提案で、intrinsic gasの上限に触れる。実行層の課金モデルに手を入れる変更がdevnetで詰まるのは、想定範囲の出来事ではあるが、公開テストネットへ進む前提が満たされていないことを示している。

Devnet-10からDevnet-11へ関心が移ったこと自体も情報である。devnetの番号が進むのは、前のdevnetで安定を確認できなかったか、あるいは修正の適用先を新しいネットワークに切り替えたことを意味する。「次のdevnetを見る」という状態が続く限り、Sepoliaの日付は候補以上のものにならない。

想定される落とし穴

第一に、エポックと時刻を両方引用している情報源でも、両者が整合しているとは限らない。エポック番号は議事から、時刻は要約から、別々に転記されて伝わることがある。フォーク日程を社内に展開する際は、エポック番号だけを一次情報として扱い、時刻は自分で計算して添えるのが安全である。計算式は創世時刻＋384×エポックで、Sepoliaの創世時刻は1655733600である。

第二に、Sepoliaの日付が決まってもメインネットの日付は決まらない。過去のフォークでは、公開テストネットからメインネットまで2〜4か月を要している。12月のメインネット適用が議論されたと報じられているが、これは決定ではない。テストネットの結果次第という留保が明示的に付いている。

第三に、Sepoliaは検証用の環境であって、メインネットと同一ではない。バリデータ数も構成も異なり、Devnet-11の約84,000バリデータという規模はメインネットの規模と比べれば小さい。Sepoliaで問題が出なかったことは、メインネットで問題が出ないことを意味しない。

第四に、適用日が動くこと自体を前提に運用を組む必要がある。「9月28日」で社内の作業枠を確保していたチームは、すでに1回の変更を経験している。フォーク対応を日付に紐づけるのではなく、エポック番号の確定とクライアントのリリースを起点に紐づけるほうが、変更に強い。

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

  1. フォーク日程は「エポック番号」と「時刻」という2つの表現を持ち、伝播の過程でどちらか一方だけが更新されうる。エポック番号は仕様上の確定値、時刻はその派生値であり、派生値を一次情報として扱うと8日単位のずれが混入する。 ［ノード運用者・インテグレーター］ フォーク日程を社内展開する際は、エポック番号のみを原文から転記し、時刻は創世時刻＋384×エポックで自分で計算した値を併記する運用に今週から切り替える。
  2. Glamsterdamは私設devnetで安定稼働していない段階にあり、公開テストネットの日付は「目標」であって確定ではない。EIP-8037のようなガス課金モデルの変更が詰まっている以上、適用範囲の再調整（EIPの除外）も選択肢に残る。 ［プロダクト側・技術計画］ Glamsterdam由来の機能に依存する社内計画は、Sepolia適用の成否が判明するまで日付を持たせず、Devnet-11の結果を次の確認ポイントとして明示する。
  3. テストネットでの成功は規模の異なる環境での成功であり、メインネットの保証ではない。バリデータ数も、クライアントの実装分布も、負荷特性も異なる。 ［バリデータ運用］ メインネット適用の2週間前までにクライアントの更新を完了させる方針を、日付ではなく「エポック確定から逆算する」形で運用手順に書き換える。

【引用：出典】

本記事は公開情報に基づく技術解説であり、投資助言を目的としたものではありません。エポックと時刻の整合性に関する指摘は、Sepoliaのビーコン創世時刻1655733600、スロット12秒、1エポック32スロットを前提に本稿で計算した結果です。