Ethereum「Glamsterdam」、Hoodiで10月26日17:42 UTC（日本時間27日2:42）始動

結論から言うと、Glamsterdamが始動するのはEthereumメインネットではなくHoodiです。起動は2026年10月26日17時42分48秒（UTC）、日本時間では27日2時42分48秒です。Hoodiのノード運用者とバリデータは対応クライアントへの更新が必要ですが、ETHを保有しているだけの人に今回の発表を理由とする作業はありません。Ethereumの前提を確認したい人はEthereumとBitcoinの違いも参照してください。

今回まとめて試されるのは、ブロック提案者とビルダーをプロトコル内で分けるePBS、並列処理を支えるBlock-Level Access Lists（BAL）、ガス会計の再設計などです。まず自分の役割を確認し、次の表から必要な章へ進んでください。

読者	今回必要な対応	読む章
ETH保有者	交換・移行は不要。不審な案内を避ける	保有者への結論
Hoodiノード・バリデータ	対応版への更新、外部構成と監視の試験	運用チェックリスト
アプリ開発者	ガス、ログ、API、再同期などを検証	SepoliaとHoodiでの検証

ここからは主に技術対象者向けです。本記事は価格予測や売買推奨ではありません。一次情報を2026年10月18日に照合して編集し、仕様・対応版が変わった場合は公式告知を基準に更新します。実作業時には公式告知、EIP、各クライアントの最新リリースノートを再確認してください。

Glamsterdamは10月26日17:42 UTCにHoodiで始動する

\n

Ethereum Foundationの告知によると、GlamsterdamはHoodiでepoch 132352、slot 4235264に有効化されます。日時は2026年10月26日17時42分48秒（UTC）で、日本時間では翌27日2時42分48秒です。ネットワークアップグレードでは全参加者が同じ境界で新しい規則へ切り替わる必要があるため、運用上はニュースに書かれた日付だけでなくepochとslotも重要です。

起動日時は2026年10月26日17時42分48秒（UTC）

epochは複数のslotをまとめた単位、slotはブロック提案の機会を割り当てる時間枠です。したがって「10月26日のどこかで手動のスイッチが押される」のではありません。対応クライアントは設定された境界を認識し、その時点からGlamsterdamの規則でブロックを検証します。Hoodiの設定リポジトリにもAmsterdam時刻とGloas epochが記録されており、運用者は自分の設定が公式値と一致するか確認できます。

日本で作業する場合は日付がUTC表記の翌日になる点にも注意が必要です。監視や当番表、変更凍結時間を組むときは、タイムゾーンを明記してください。起動直前だけでなく、事前同期、更新後の再起動、ピア接続、ヘッド追従、エラー監視まで含めて時間を確保すると、切り替え境界で慌てにくくなります。

対象はHoodi、メインネット実施日は未定

今回の告知対象はHoodiです。2026年10月16日時点で、EthereumメインネットにおけるGlamsterdamの起動日時は決まっていません。Hoodiで動いたことは、本番環境での採用日時や安全性を保証するものではありません。テストネットで実装間の差、負荷、外部サービスとの接続、アプリの互換性を調べ、その結果を次の判断へつなげます。

「Glamsterdamが10月26日に始動」という見出しだけを見ると、一般のETH利用者にも一斉対応が必要に見えるかもしれません。しかし、どのネットワークで起きるかを省くと意味が変わります。Hoodiの資産はメインネット上のETHではなく、試験用環境の資産です。Hoodiのフォーク日時を、送金停止や売買判断の根拠に置き換えないでください。

ETH保有者に今回の発表に伴う作業はない

ETHをウォレットや取引所で保有しているだけの人は、今回のHoodi発表に伴ってトークンの交換、移行、送金を行う必要はありません。「アップグレード対応のためETHを別トークンへ交換する」と誘う案内が届いても、この公式発表の内容とは一致しません。秘密鍵やシードフレーズを入力せず、利用中のウォレットや取引所の公式窓口で確認しましょう。

一方、自分でHoodiノードを運用している人、Hoodiでバリデータを動かす人、Hoodiへ接続するアプリを開発している人には対応があります。以降は仕組みを説明した後、役割別のチェックリストへ落とし込みます。

Glamsterdamで導入される主要な変更

\n

GlamsterdamのメタEIPであるEIP-7773には、採用予定のコアEIPがまとめられています。調査時点では18本が列挙されており、一つの機能だけを追加する更新ではありません。コンセンサス層ではブロック生成やバリデータの任務が変わり、実行層では状態アクセス、取引の基礎費用、ログ、opcode、コントラクト上限などが変わります。

柱	何が変わるか	特に確認する人
ePBS	提案者とビルダーの分離をプロトコル化	バリデータ、MEV・リレー・DVT運用者
BAL	ブロックが触れた状態位置と差分を記録	クライアント開発者、ノード運用者
ガス変更	取引、calldata、状態生成・アクセス等を再価格付け	ウォレット、コントラクト、推定器の開発者
200M上限	Hoodiのブロックガス上限を起動epochで引き上げ	ノード運用者、負荷試験担当者

ePBSの運用影響は次章、BALと200Mはその次、ガス再価格付けは固定値リスクの章で、確認方法とともに説明します。ガスの基本はEthereumのガス代の仕組み、アプリ側の前提はスマートコントラクトの基礎で補えます。

\n\n

ePBSがバリデータと外部ビルダー構成に与える影響

\n

ePBSは、ブロックを提案するバリデータと、取引を選び実行ペイロードを構築するビルダーの関係を合意規則へ取り込みます。目的は役割を分けつつ、ビルダーが作った内容をネットワークが検証できる時間を確保することです。そのため、バリデータが従来どおりブロック提案だけを意識すればよいとは限らず、新しいメッセージ、期限、支払い処理、委員会任務への対応が必要になります。

提案者とビルダーの分離がプロトコルに組み込まれる

提案者はコンセンサスを前へ進める役割を持ち、ビルダーは取引の並びと実行結果をまとめた「実行ペイロード」を構築します。EIP-7732では、ビルダーのコミットメントと実行ペイロードの公開を分け、ペイロード検証を次の段階で行えるようにします。これにより、ブロックの時間枠を実行ペイロードの伝播だけで使い切らない設計を目指します。

初心者は「分離されたなら、自分のバリデータはビルダーを使わなくてよい」と早合点しないようにしましょう。実際の構成はクライアントの対応、ローカルビルド、外部ビルダー、リレーやミドルウェアの選択によって異なります。重要なのは、構成要素ごとにGlamsterdam対応が明記され、組み合わせ試験が済んでいるかです。

PTCとビルダー登録・支払いの処理が加わる

PTCはPayload Timeliness Committeeの略で、実行ペイロードが期限内に公開されたかを確認する委員会です。選ばれたバリデータは、公開状況について投票する新しい任務を担います。見逃しや不一致を避けるには、Beacon NodeとValidator Clientが同じフォークに対応し、時刻同期や通信が正常である必要があります。

ビルダーの登録・退出についてはEIP-8282が実行層の事前配備コントラクトと要求バスを定めます。ビルダーがプロトコル内の参加主体になるため、預入、登録、退出、支払いの状態を正しく扱う必要があります。運用者は残高や報酬だけでなく、登録状態と関連ログも監視対象に加えるべきです。

MEV・リレー・DVT構成は互換性確認が必要になる

バリデータがMEV関連ソフト、外部リレー、分散型バリデータ技術（DVT）、署名者、監視サービスを組み合わせている場合、クライアント本体だけ更新しても十分とは限りません。ブロック生成の順序やメッセージ形式、締切が変われば、中間にある一つの部品が古いだけで提案失敗や取りこぼしにつながる可能性があります。

確認は「各製品がGlamsterdam対応と書いてあるか」だけでなく、自分が使うバージョン同士の組み合わせで行います。Hoodi上で鍵や設定を本番と分離し、提案、正しいチェーンへの投票であるアテステーション、PTC任務、ビルダー選択、フェイルオーバー、監視通知を一通り試してください。外部ビルダーが応答しない場合にローカル構築へ切り替わるか、その挙動が想定どおりかも重要です。

BALと200Mガス上限が実行環境をどう変えるか

BALと200Mガス上限はどちらも処理能力の拡大に関係しますが、役割は異なります。BALは状態処理を効率化しやすくするデータ構造であり、200MはHoodiのブロックが受け入れる実行量の上限設定です。一方だけを見て性能を判断せず、検証時間、ブロック伝播、ストレージ増加、再同期まで測定する必要があります。

BALは状態読込・取引検証・状態ルート計算を並列化しやすくする

\n

Ethereumの取引は、アカウント残高、コントラクトコード、ストレージ値などの状態を読み書きします。前の取引が何を変更するか分からなければ、後の取引を安全に並行処理するのは難しくなります。BALはブロック単位でアクセス先と差分を明らかにし、依存関係を把握するための材料を提供します。

これによってクライアントは、必要な状態をまとめて先読みしたり、互いに干渉しない処理を並列化したり、状態全体を要約するハッシュ値である状態ルートの計算を分担したりしやすくなります。ただし、すべての取引が独立しているわけではありません。同じストレージへ触れる取引は順序依存が残るため、並列化できる割合はブロックの内容でも変わります。

Hoodiでは起動epochにガス上限を200Mへ引き上げる

\n

公式告知では、HoodiのGlamsterdam起動epochにガス上限を200Mへ引き上げます。EIP-8261はGloas後のガス上限をepoch単位で段階設定できる任意スケジュールを示しており、Hoodiの計画を理解する仕様上の手掛かりになります。ここでのMはmillion、つまり200Mは2億ガスです。

この値はHoodiでの試験条件です。メインネットの上限が同じ日時に同じ値へ変わるという意味ではありません。また、ガス上限を上げても、個々の処理に課されるガスが再価格付けされれば、取引種類ごとの収容数は単純比例しません。テスト結果は取引構成とハードウェア条件を添えて評価する必要があります。

ノード負荷と状態増大は実測で見極める

ノード運用者はCPU使用率の平均だけでなく、ピーク、メモリ、ディスクI/O、データベース増加量、ブロック検証時間、ヘッドからの遅延、ピア数、正規チェーンが入れ替わる再編成（reorg）時の回復を観測してください。普段空いているHoodiで問題がなくても、負荷生成時や同期直後にボトルネックが現れることがあります。

アーカイブノード、フルノード、ステートを限定して保持する構成では、影響も異なります。RPCを外部へ提供するノードでは、eth_callやログ検索などの問い合わせがブロック処理と資源を奪い合うこともあります。検証環境を本番に近づけ、通常時と高負荷時の基準値を残すと、更新前後の差を説明しやすくなります。

固定ガス前提のアプリは再検証が必要

アプリ開発者にとって最大の注意点は、「以前の定数が今後も常に正しい」という前提です。Glamsterdamでは取引の基礎費用、calldata、アクセスリスト、状態生成、状態アクセス、払い戻し後のブロック会計が変更対象になります。ガス推定APIを使っていても、その結果を独自の上限や最小値で切り詰めていれば誤作動する可能性があります。

単純なETH送金でも21,000ガス固定とは限らない

EIP-2780は、一律の基礎取引ガスを署名、宛先、価値移転などの資源別費用へ分解します。宛先の状態などによって、見た目が単純なETH送金でも従来の21,000固定という想定が成立しない場合があります。フォームの初期値、ハードウェアウォレット連携、バッチ送金、手数料不足時の再試行を確認してください。

安全な実装は、取引内容と対象ブロックの規則に基づいてクライアントへ見積もりを求め、余裕幅の方針を明示します。ただし、推定値も将来の状態変化や混雑を完全には予測できません。失敗時には理由を利用者へ示し、むやみに巨大な上限へ差し替えるのではなく再見積もりできる導線を用意します。

calldata・アクセスリスト・状態生成・状態アクセスの費用が変わる

EIP-7976はcalldataの最低費用を1バイト当たり64ガスへ引き上げ、巨大なブロックデータを抑えることを狙います。EIP-7981はEIP-2930アクセスリストのデータ量に見合う費用へ調整します。大量データをcalldataへ入れるロールアップ関連処理や、アクセスリストを積極利用する取引は、以前の見積もりをそのまま使えません。

EIP-8037は新規アカウント、コード、ストレージなど状態を新しく作る処理の費用を増額・分離計測します。EIP-8038は、拡大したEthereum状態へアクセスする実コストを反映し、関連するガス価格を見直します。ストレージスロットを大量に作るコントラクトや、多数の状態を読み込む処理は影響を受けやすいため、代表的な成功経路だけでなく最大規模のケースも測定しましょう。

ガス払い戻しを前提にしたブロック上限計算を見直す

EIP-7778は、ブロックガスの集計で払い戻し後の値ではなく、実際に消費したガスを用います。従来は払い戻しによって、ブロックガス上限から直感する量より多くの計算が入り得ました。変更後はブロック上限の実質的な迂回を抑え、最悪時の計算量を予測しやすくします。

取引者が最終的に支払う金額の計算と、ブロック全体の上限へ算入する量を混同しないでください。ブロック構築、シミュレーション、バンドル作成、ガス使用量の分析ツールは、どちらの数値を表示しているか明確にする必要があります。古いロジックで「まだブロックに余裕がある」と判断すると、候補ブロックが新規則に適合しない恐れがあります。

ウォレット・推定器・コントラクトの固定値を洗い出す

コード検索では21000、固定のgasLimit、独自のcalldata係数、アクセスリスト単価、ストレージ書き込み費用、払い戻し率を探します。設定ファイルやデータベースに保存された値、フロントエンドの入力検証、SDKの既定値、監視アラートの閾値も対象です。テストが通っても、モックが古い定数を返していないか確認してください。

契約側では、残りガスを使って処理分岐する設計、外部呼び出しへ固定量だけ渡す設計、一定ガス以下なら必ず成功するとみなす設計が要注意です。ウォレット側では手数料表示、残高不足判定、置換取引、バッチ処理を確認します。インデクサや分析基盤では、従来の費用分類を新しいガス内訳へどう対応させるか決めておきます。

ノード運用者とバリデータが起動前に行うこと

Hoodiでは実行層（EL）とコンセンサス層（CL）の片側だけを更新すると、フォーク後の追従や任務に失敗する可能性があります。次を変更票へ転記し、担当と完了判定を明確にしてください。

対象	作業	確認方法・完了条件	実施時期
EL	Hoodi対応版へ更新	実行中の版、Engine API接続、同期を確認	事前試験後、起動前
CL / Beacon Node	対応版へ更新	ヘッド追従、ピア、エラーなし	起動前
Validator Client	対応版と接続先を確認	アテステーション、提案、PTC任務が成功	起動前に試験
リレー・DVT・署名者	組み合わせ試験	提案とフェイルオーバーが成功	起動前
監視	版、遅延、I/O、任務を追加	通知試験と当番への共有が完了	更新時
ロールバック	手順と適用条件を文書化	フォーク後データへの可否を文書で確認	変更承認前

実行層・コンセンサス層を対応版へそろえる

参照日2026年10月18日（公式表は10月16日告知）のコンセンサス層対応版はLodestar 1.50.0、Nimbus 26.10.1、Prysm 7.3.0、Teku 26.10.1です。実行層ではBesu 26.10.0、Ethrex 30.0.0-rc.2、Nethermind 2.2.0が掲載されていました。ただし、これは記事作成時点の表であり、空欄のクライアントを非対応と断定する一覧でも、将来の最新版を固定する一覧でもありません。

運用者は公式表から自分のクライアントを選び、リンク先のリリースノート、対象ネットワーク、既知の問題、必要な設定変更、データベース移行を確認してください。バイナリやコンテナのタグだけでなく、実行中プロセスが返すバージョンも確認します。ロールバック方法を用意する場合も、フォーク境界を越えたデータへ古い版を接続してよいかをクライアント文書で確かめます。

Beacon NodeとValidator Clientを両方更新する

バリデータ構成ではBeacon Nodeがネットワークとコンセンサスを扱い、Validator Clientが鍵を使って任務へ署名します。両者が別プロセスや別ホストなら、それぞれの実体と接続先を棚卸ししてください。片方だけ古い場合、新しい任務の受け渡しや型に対応できない可能性があります。

更新後は同期完了、Engine API接続、時刻同期、アテステーション、提案、PTC関連処理を確認します。冗長化している場合は待機系も対象です。フェイルオーバー先が古いままだと、障害時にだけ不具合が現れます。二重署名を防ぐスラッシング保護データの扱いは、通常の更新時と同じく慎重に行ってください。

公式表の対応版とリリースノートを直前まで確認する

アップグレード前には、不具合修正を含む新しいパッチ版が出ることがあります。早めに試験版で検証しつつ、起動直前に公式告知とクライアントチームのリリースを再確認する運用が必要です。監視担当者にも採用版と変更点を共有し、ログの新しい警告を既存ルールが誤検知しないか確認します。

ダウンロード元と署名・チェックサムを確認し、非公式なミラーやSNS上の直接リンクだけに頼らないでください。更新案内を装った攻撃は秘密鍵だけでなく、ノードホストの認証情報やAPIキーも狙います。バリデータ鍵をアプリ検証環境へコピーせず、Hoodi用とメインネット用の構成を明確に分離します。

RC版や未確認版を別ネットワークへ安易に横展開しない

Ethrexの掲載版にはrc、つまりリリース候補を示す表記があります。候補版がHoodi試験に必要でも、それをメインネットや他ネットワークへそのまま配備してよいとは限りません。対象ネットワーク、推奨用途、既知の制約を確認し、変更管理の範囲をHoodiへ限定してください。

同じ自動化テンプレートを複数ネットワークで共有している場合、イメージタグやフォーク設定の一括更新が意図せず全環境へ広がる恐れがあります。ネットワーク別の変数、承認工程、デプロイ対象一覧を確認し、Hoodiの作業がメインネット構成を書き換えないことを事前に検証しましょう。

アプリ開発者がSepoliaとHoodiで検証する項目

Sepoliaは短時間の機能確認、Hoodiは長期運用と負荷・互換性の確認に使い分けます。両方で同じ結果になると決めつけず、ネットワーク名、クライアント版、フォーク境界、ハードウェア条件を記録してください。

検証項目	推奨環境	理由・完了条件
ガス見積もり、ログ、新opcodeの短時間確認	Sepolia	既に起動済みの環境で主要経路と境界値を素早く反復
長時間のイベント購読、外部サービス連携	Hoodi	切断・再接続・重複排除まで継続確認
ノード再起動、再同期、フォーク境界	Hoodi	復旧後にヘッド追従し欠落がない
200M条件の負荷、RPC応答、I/O	Hoodi	本番相当構成で基準値を取り、許容値内と確認

ガス見積もりと固定上限を再計測する（まずSepolia、継続確認はHoodi）

代表的な取引ごとにeth_estimateGas、シミュレーション結果、実際のgasUsed、失敗理由を保存し、フォーク前後で比較します。ETH送金、ERC-20移転、承認、NFT発行、コントラクト配備、ストレージ作成、バッチ処理など、自社が実際に扱う経路を選んでください。成功例だけでなく、残高不足、revert、巨大calldata、アクセス先が初回か既存かといった境界条件も試します。

ユーザー操作の途中で見積もりから実行まで時間が空くアプリは、状態が変化した場合の再見積もりも確認します。バックエンド、SDK、フロントエンドで別々に上限を設定していると、最も小さい値がボトルネックになります。エラー表示が「ネットワーク障害」だけにならず、ガス不足や規則変更を調査できる情報を残しましょう。

ETH移転ログをSepoliaで確認し、Hoodiで長期購読する

EIP-7708はCALLなどによるETH移転に共通ログを発行し、内部ETH移転をログで索引化できるようにします。これまでトレースAPIへ依存していたインデクサは、新ログを取り込むか、既存トレースとどう重複排除するかを決める必要があります。入出金監視、会計、通知、ブロックエクスプローラーの表示が主な確認対象です。

ログが増えるからといって、過去ブロックにも自動的に同じログが生えるわけではありません。フォーク境界をまたぐ検索では、旧方式と新方式を区別する必要があります。また、ログだけでアプリ固有の「入金確定」を判断できるとは限りません。ブロックの正規性、必要な確認、再編成時の取り消し処理も従来どおり必要です。

新opcode・サイズ・CREATE2はSepoliaで機能確認する

EIP-7843はEVM内で現在のslot番号を得るSLOTNUM opcodeを追加します。EIP-8024はより深いスタックへアクセスするSWAPN、DUPN、EXCHANGEを後方互換的に追加します。新命令を使うコンパイラやツールは、対象フォークを明示し、未対応ネットワークへ生成コードを配備しないようにしてください。

EIP-7954は配備済みコード上限を24KiBから64KiB、initcodeを48KiBから128KiBへ拡大します。大きなコントラクトを配備できる余地は増えますが、RPC、エクスプローラー、検証ツール、デプロイフレームワークが新上限を受け入れるか確認が必要です。上限拡大は、設計上の複雑さや監査負担を自動的に解決しません。

EIP-7997は複数EVMチェーンで利用できる最小CREATE2ファクトリを所定アドレスへ置き、同じ入力から予測可能なアドレスを得る仕組みです。アドレス計算、既存ファクトリとの使い分け、対象チェーンの配備状態、衝突時の扱いをテストしてください。「同じアドレス」は「同じ状態や残高」を意味しない点にも注意が必要です。

SELFDESTRUCTとSSZはSepoliaで差分確認する

EIP-8246はSELFDESTRUCTの送金先が同一アカウントの場合にも残高を焼却しない動作へ変えます。SELFDESTRUCTを直接使う古いコントラクトだけでなく、ライブラリ、テスト用ヘルパー、残高回収ロジックに依存がないか調べてください。期待残高、イベント、トレース、会計結果をフォーク境界の前後で比較します。

コンセンサス層のEIP-7688は、データの直列化方式であるSSZの構造をProgressiveContainerへ移し、将来フィールドを追加しやすくします。コンセンサスデータを直接デコードするアプリ、独自インデクサ、監視基盤は、型の分岐や未知フィールドの扱いを検証してください。クライアントAPIが吸収する変更でも、独自バイナリ解析をしていれば影響が表面化します。

EIPの段階と公式クライアント表を継続確認する

EIP文書にはReviewやLast Callなど、Finalになる前の段階が含まれます。Hoodiで見つかった問題を受けて仕様や実装が修正される可能性があるため、テストを一度通して終わりにせず、EIPの更新、クライアントリリース、公式告知を追跡してください。仕様本文と実装結果が食い違った場合は、利用クライアントの既知問題も確認します。

次の一手は4つです。自分の役割を確定し、公式表で対応版を照合し、SepoliaまたはHoodiで担当範囲を試験し、起動直前に告知とリリースノートを再確認してください。結果と採用版を変更記録へ残せば、フォーク後の異常も更新前の基準と比較できます。