Ethereum の次期大型アップデート「Glamsterdam」とは？ePBS と BAL を中心に解説

本記事の概要

2026 年後半に Ethereum メインネットへのリリースが予定されている “Glamsterdam” アップデートについて、その技術的な狙いと、バリデータ・フルノードの運用者や L2・スマートコントラクト開発者にとっての実務的な影響を解説します。 （※“Glamsterdam”は、Consensus Layer(CL)側のアップデートが”Gloas”（恒星の名前に由来）、Execution Layer(EL)側のアップデートが”Amsterdam”（過去の Devconnect 開催地に由来）とされていることから作られた造語です。出典：Glamsterdam | ethereum.org）

本稿は、2025 年 12 月にリリースされた Fusaka アップデートの次に来る大型アップデートを扱います。Fusaka については 前回の記事 を参照してください。

注: 本アップデートは執筆時点（2026 年 6 月 24 日）で devnet（開発用テストネット）段階 にあり、スコープ（対象 EIP）・各 EIP のパラメータ・アクティベーション日時はいずれも 確定しておらず、今後変動し得ます。本稿は、メタ EIP である EIP-7773 で「Scheduled for Inclusion（採用確定）」とされている EIP を中心に記載しています。最新の状況は必ず一次情報をご確認ください。

Glamsterdam アップデートの概要とタイムライン

目的と打ち手

本アップデートは、2025 年 12 月の Fusaka に続く大型アップデートで、おおむね次を達成することを目標に開発されています。Fusaka が L2 のデータ可用性（Blob）のスケーリング に主眼を置いていたのに対し、Glamsterdam は L1 自体のTXの実行能力のスケーリングと、ブロック生成の仕組みの刷新 に踏み込みます。（Blob とは、L2 などのデータを一時的に載せる安価なデータ領域のことです。）

1. ブロック生成の仕組みの刷新
   • Enshrined Proposer-Builder Separation（ePBS, EIP-7732） をプロトコルに組み込み、現在 MEV-Boost等のMEV情報を収集するために依存している「リレー（信頼が必要な第三者）」をプロトコルレベルで不要にする
   • コンセンサスの処理過程からブロックに含まれるTXの検証を分離し、バリデータが時間がかかるTXの検証を署名前までに行う必要をなくす
2. L1 の実行性能の改善（並列実行）
   • Block-Level Access Lists（BALs, EIP-7928） を導入し、ブロック内のどの TX がどのState（Ethereumでは全アカウントの残高・コントラクトのデータをStateとして全ノードが保有している）にアクセスするかを事前に宣言させ、データの読み出し・TX 実行・State Root 計算の並列化を可能にする（State Root はStateのハッシュ値でブロックごとに再計算が必要）
   • ブロックのガス上限（TXをどれだけ多く入れられるようにするか）を安全に拡張できるようになる
3. ステート肥大化の抑制と持続可能性の担保
   • 全ノードが保有するStateは、チェーンが持続するごとに増え、ノード運用に影響が及ぶ。Stateに関連する操作（アカウント生成・ストレージ書き込み・コントラクトデプロイ等）のガスコストを実コストに合わせて引き上げることで（EIP-8037）、Stateの成長にディスインセンティブを付け抑制し、持続可能性を担保するため、年間 120 GiB 程度の増加になるように調整する
   • TXのcalldata（コントラクト等への入力データ）・access list のコスト見直し（EIP-7976 / EIP-7981）を用いてブロックサイズを抑制し、ガス上限引き上げの余地を作る
4. UX と開発者体験の向上
   • すべての ETH 送金でログを発行（EIP-7708）するようにし、インデクサーでの検知を容易化することで取引所の入金検知を容易化
   • コントラクトサイズ上限の緩和（EIP-7954）、スタック操作オペコードの追加（EIP-8024）、SLOTNUM オペコードの追加（EIP-7843）

Glamsterdam は、Ethereum のロードマップにおける「The Scourge（MEV 対策・ステーキングの中立化）」「The Surge（スケーリング）」「The Purge（ステート肥大化対策）」といったテーマに整合しており、特に ePBS は将来的な inclusion list / FOCIL や PeerDAS の発展 といった、検閲耐性・分散化に向けた布石にあたります。inclusion list は、ブロックを作る側に「この取引は必ず含める」ことを強制して検閲を防ぐ仕組み、FOCIL（Fork-Choice enforced Inclusion Lists）はその強制を一人の proposer ではなく多数のバリデータに分担させる設計案で、いずれも Glamsterdam 自体には未採用ながら、ePBS がその実装の土台になります。

タイムライン（執筆時点）

執筆時点（2026 年 6 月 24 日）では、全 EIP を載せた devnet を回している段階で、これが「パブリックテストネット前の最終フェーズ」と記載されています。メインネットでのアクティベーションは 2026 年後半 の見込みですが、日付はまだ確定していません。下は現状をまとめた表になります。

出典: Ethereum’s biggest protocol overhaul in years moves into its final development stage (CoinDesk, 2026-06-16) / EIP-7773

なお、Fusaka では EIP-7935 のようにブロックのガス上限の既定値自体を引き上げる EIP が含まれていましたが、Glamsterdam では ガス上限そのものを引き上げる EIP は採用確定リストに含まれていません。ガス上限はバリデータの投票で決まる値であり、アップデートではなく継続的な拡張となるためです。Glamsterdam の各 EIP（特に BAL による並列実行と、ステート/データのコスト見直し）は、ガス上限を安全に引き上げられる「土台」を作るものです。devnet では 200M ガスといった高いガス上限を目標としたテストが行われています。

出典: Ethereum’s Glamsterdam Upgrade Enters Final Devnet Phase With 200M Gas-Limit Target (The Defiant)

対象となるEIPの一覧

メタ EIP である EIP-7773 で「Scheduled for Inclusion（採用確定）」とされている 10 本の EIP を、下表に示します。先頭の 2 本（EIP-7732 / EIP-7928）が、本アップデートの 目玉機能（headliner） です。

出典: EIP-7773: Hardfork Meta - Glamsterdam（各 EIP の詳細は本文・参考文献の各リンク参照）

注意: 一部のメディアでは、ETH 送金を最大 71% 安くする EIP-2780（Reduce intrinsic transaction gas） が Glamsterdam に含まれると報じられていますが、EIP-7773 上では EIP-2780 は「Considered for Inclusion（検討中）」であり、採用は確定していません（執筆時点）。同様に、ePBS と並んで議論される検閲耐性機構 FOCIL（EIP-7805） は「Declined for Inclusion（不採用）」とされています。

それでは、目玉機能である ePBS（EIP-7732）と BAL（EIP-7928）が、それぞれどのような技術なのか、概要から説明します。

目玉機能① ePBS（EIP-7732: Enshrined Proposer-Builder Separation）

解決したい課題：リレー依存と現行処理の重さ

現在の Ethereum では、ブロックを提案するバリデータの大多数が、ブロックの中身（TX実行部であるペイロード）の構築を、MEV-Boost のリレー（relay） と呼ばれる第三者に外注しています。MEV（Maximal Extractable Value）とは、ブロック内の取引の取り込みや並べ替えから得られる追加収益のことで、これを専門業者（builder）が最適化し、その成果をバリデータに届ける仕組みが MEV-Boost です。リレーは「proposer に正しく報酬を払い、builder のペイロードを確実にブロックに取り込む」ための信頼された仲介者として機能しますが、これは Ethereumプロトコル外の存在に対する信頼が前提 であり、中央集権化・検閲のリスクになります。

加えて現在のスロット（Ethereum の時間の基本単位で、12 秒ごとに 1 つ、ブロック生成の機会が割り当てられる）の設計では、バリデータは投票の締切（スロット開始から 4 秒）までに、コンセンサスとTXの実行の両方の状態遷移を完了 させなければなりません。この現行処理が重く時間がかかることが、ブロックの伝播やペイロードの大型化のボトルネックになっています。

EIP-7732（ePBS） は、この proposer-builder 分離を プロトコルに組み込み 、リレーというプロトコル外の信頼で必要な存在を取り除きます。

仕組み：ブロックを「コンセンサス部」と「実行部」に分離する

ePBS の核心は、これまで BeaconBlockBody に丸ごと含まれていた ExecutionPayload（実行部）を、ブロック本体から切り離す点にあります。

1. proposer はまず「入札情報」だけを含むビーコンブロックを提案する ExecutionPayload 本体ではなく、SignedExecutionPayloadBid（署名付き入札情報）を含めます。入札には、含めたいペイロードの block hash、builder id、proposer への支払額、ガス上限等のメタデータが含まれます。
2. ビルダーは後からペイロードの中身を公開する 実際の ExecutionPayload は、SignedExecutionPayloadEnvelope という別メッセージとして、ビーコンブロックとは非同期に、スロットの後半で公開されます。
3. 実行検証は次のスロットへ後ろ倒しする（遅延検証） 投票締切までの短時間で、バリデータは コンセンサスの状態遷移だけ を行えばよくなります。ペイロードの検証は、次のブロック検証時まで遅延できます。

これにより、ペイロードの実行・伝播に使える時間は、約 2 秒から約 9 秒 へと大きく拡大します。

出典: Glamsterdam | ethereum.org / EIP-7732

ビルダーのプロトコルへの登録制

ePBS では、ビルダーが バリデータとは別の主体として BeaconState 上に登録 されます。ビルダーは最低 1 ETH のビーコンチェーン残高を持ち、次のように公開鍵・残高・出金可能時期などを持つ登録済みの主体として定義されます（以下のコードは読み飛ばしても本筋は追えます）。

class Builder(Container):
    pubkey: BLSPubkey
    version: uint8
    execution_address: ExecutionAddress
    balance: Gwei
    deposit_epoch: Epoch
    withdrawable_epoch: Epoch

proposer が入札を採用すると、ビルダーの約束した支払額がビルダーのビーコンチェーン残高から差し引かれ、BuilderPendingPayment としてキューに入ります。後に、proposer が指定した EL 上のアドレスへの引き出し（withdrawal）として支払いが実行されます。これにより、リレーを介さず 「proposer は確実に報酬を受け取り、適正なビルダーのペイロードは確実にブロックに含められる」 というトラストレスな処理がプロトコル内で実行されます。

Payload Timeliness Committee（PTC）による PBS の簡易検証

ePBS では、各スロットのビーコンコミッティに選ばれたバリデータのサブセット（512 名）が PTC（Payload Timeliness Committee） を構成します。PTC を担うのはビルダーではなくバリデータで、実行ペイロードの中身そのものは検証せず、PayloadAttestationMessage を通じて次の 2 点だけを検証します。

• payload_present: ビルダーが約束した block hash どおりのペイロードを公開したか
• blob_data_available: 対応する blob データが利用可能だったか

これが「遅延検証（delayed validation）」の要であり、PTC メンバーは重い実行検証は実施せず、ビルダーが適正に作業したか、ペイロードが時間内に公開されたかだけを検証します。

スロットの 3 つの状態と安全性

ePBS では、各スロットが次の 3 状態のいずれかになります。

• Full: ビーコンブロックとペイロードの両方が公開・採用された
• Skipped: ビーコンブロックが公開されなかった
• Empty: ビーコンブロックは採用されたが、実行ペイロードが公開されなかった

安全性の設計の要点は次の通りです（出典: EIP-7732）。

• proposer への無条件支払い: ビルダーの入札を含むビーコンブロックが採用されれば、ペイロードが後で公開されなくても支払いはビルダー残高から差し引かれる。
• PTC の equivocation リスク: ネットワーク分断を支配するビルダーと、単一の悪意ある PTC メンバーが結託すると、ネットワークの一部が「ペイロードあり」、別の一部が「なし」と食い違って認識する split view（チェーンの状態についてネットワークの見解が割れ、合意できない状態）を作り得る。ただし 2/3 の PTC 閾値の下では実質 33% のネットワーク支配が必要であり、実用上のリスクは緩和される。

なお、ePBS は CL のブロック検証ルールに後方非互換な変更を加えるため、ハードフォークを伴います。

注: スロットの長さ（12 秒）は Glamsterdam では変更されません。 スロット短縮（EIP-7782）は EIP-7773 上で「Declined for Inclusion（不採用）」とされています。ePBS は 12 秒スロットの「中の責務の配置」を組み替えるものです。

目玉機能② BAL（EIP-7928: Block-Level Access Lists）

解決したい課題：TX 実行が逐次的なこと

これまで、TX の実行は 逐次的 でした。EIP-2930 で TX 単位の access list（その取引が読み書きするアカウントとストレージを事前に並べたリスト）が導入されましたが、これは任意で強制力がありません。

EIP-7928（BAL） は、ブロック内で どのアカウント・どのストレージにアクセスし、実行後にどう変化したか を、ブロック単位で 必須かつ決定論的に記録 させます。BAL の存在により、次の並列化が可能になります（出典: EIP-7928）。

BALs によって並列でのディスク読み出し、並列での TX 検証、並列での State Root 計算・更新が可能になります。

BAL に記録される内容とデータ構造

BAL は、TXの実行中に関連した全てのアドレスについて、ストレージの読み書き・残高・nonce・コードの変化を、block access index（=どの TX に起因する変化かを示す番号）とともに記録します。

データ構造は、概念的には「アドレス → フィールド種別 → block access index → 変化後の値」という階層を、RLP（Recursive Length Prefix、Ethereum が標準で使うデータの直列化方式）でエンコードしたものです（以下の擬似定義は詳細なので、読み飛ばしても本筋は追えます）。

AccountChanges = [
    address,
    List[SlotChanges],   # ストレージ書き込み（slot → [index, 新値] の列）
    List[StorageKey],    # ストレージ読み出し（書き込みのないアクセス）
    List[BalanceChange], # 残高変化（index ごと）
    List[NonceChange],   # nonce 変化（index ごと）
    List[CodeChange]     # コード変化（index ごと）
]
BlockAccessList = List[AccountChanges]  # アドレスの辞書順でソート

block access index は次のように割り当てられます。

• 0: 実行前のシステムコントラクト呼び出し（例: EIP-2935 のブロックハッシュ保存）
• 1 〜 n: ブロック内の各 TX（順序どおり）
• n+1: 実行後のシステムコール（例: EIP-7002 の出金、EIP-7251 の統合）

BAL 全体のハッシュ（block_access_list_hash、RLP エンコードした BAL の Keccak-256）は、ブロックヘッダ（各ブロックの先頭に置かれ、全ノードが検証するメタデータ領域）に新しい項目として加わります。

なぜ並列化できるのか

BAL があると、EL は TX を実行する前に、必要な State を正確に知ることができます。これにより、

1. 並列ディスク読み出し: 必要なアカウント・ストレージを、実行を待たずに並列で取得できる。
2. 並列 TX 実行: 互いに関連のないアドレス・ストレージにアクセスする TX は並列で実行し、結果を TX 順にマージできる。仕様では 60〜80% の TX が関連のないストレージにアクセスする とされており、その分は並列に処理できる。
3. 並列 State Root 計算 / State 更新: 実行後の差分を直接適用し、State Root を再構成できる。ライトクライアントや state sync の高速化にも寄与します。

サイズとオーバーヘッド

BAL はブロックに追加されるデータなので、BALを追加する分の容量負荷が発生します。実測では、平均で 1 ブロックあたり約 72.4 KiBの容量増 とされ、これは「ワーストケースの ブロックでのcalldataより小さい」ため問題ないだろうとされています。BAL のアイテム数はブロックのガス上限に比例して制限されます（bal_items ≤ block_gas_limit / 2000、ITEM_COST = 2000）。

EL は受け取った BAL からハッシュを計算・ブロックを実行して 実際に生成された BAL と提供された BAL が一致しなければ、そのブロックは無効 として検証します。検証はI/Oの処理・EVM実行の処理と並行して行えるため、ブロック処理を遅らせません。

出典: EIP-7928: Block-Level Access Lists

その他の重要なEIPの詳細

ステート肥大化対策とガスコストの見直し（EIP-8037 / EIP-7976 / EIP-7981 / EIP-7778）

ブロックのガス上限を引き上げるには、「ワーストケースでの負荷」を下げておく必要があります。Glamsterdam では、そのためのガスの価格関連の修正が複数含まれます。

• EIP-8037（State生成にかかわるガスコストの増加）: アカウント生成・ストレージスロット・コントラクトデプロイ等の Stateを増やす操作 を、「State 1 バイトあたり 1,530 ガス（CPSB）」という統一指標で価格設定します。ステート肥大化を抑制 し、年間 120 GiB 程度の持続可能なState容量の増加を目標とします。ガス上限引き上げの前提条件として含まれています（これがなければ、ガス上限を増やし、TXの処理量を増やすとState容量が加速的に増加するため）。
• EIP-7976（Calldataの最低ガスコストの増加）: calldata の最低ガスコストを 10/40 → 64/64 ガス/バイトへ引き上げ、ガス上限に達するワーストケースのブロックサイズを約 37% 削減します。ガスコストが比較的安いBlobにデータを移動させ、calldataに大きなデータを入れさせないための誘導になっています。
• EIP-7981（Access Listのガスコストの追加）: access list のガスコストを 64 ガス/バイト追加し、ガス上限に達するワーストケースのブロックサイズを約 21% 削減します。
• EIP-7778（ブロックのガス上限計算からリファンド処理の除外）: ブロックの ガス上限計算からリファンドを除外 します。リファンドによってブロックのガス上限を超えて計算負荷を持ち得る問題を解消します。

開発者・UX 向けの改善（EIP-7708 / EIP-7843 / EIP-7954 / EIP-8024）

• EIP-7708（ETH送金にログ生成を追加）: TX・CALL・SELFDESTRUCT・CREATE/CREATE2 による すべての ETH 送金が、ERC-20 互換の Transfer ログを発行 するようになります。従来、コントラクト発の ETH 送金はインデクサーから見えず、取引所の入金検知やクロスチェーン追跡の課題でした。ERC-20互換でETHを含んだ資金移動を追跡できます。
• EIP-7843（SLOTNUMオペコードの追加）: 現在のブロックに対応する slot number を返す新オペコード SLOTNUM(0x4b) を追加します。timestamp から slot を逆算する方法や、beacon block root を使う（ガスが高い）方法に代わる、安価な手段を提供します。
• EIP-7954（コントラクトサイズ上限の増加）: コントラクトサイズ上限を 24,576 バイト(24KiB)→65,536 バイト(64KiB)、initcode 上限を 49,152 バイト(48KiB)→131,072 バイト(128KiB) へ引き上げ、より機能豊富なコントラクトを許容します。
• EIP-8024（SWAPN, DUPN, EXCHANGE）: 16 段を超えるスタック操作を可能にする DUPN/SWAPN/EXCHANGE を追加します。引数の多い関数や、コンパイラのスタックスケジューリングで必要となる「深いスタック要素の入れ替え」を、メモリ退避などの非効率な回避策なしに行えるようにします。

バリデータ・フルノード運用者、L2・コントラクト開発者への影響とまとめ

バリデータ・フルノード運用者への影響

最大の変化は ePBS（EIP-7732） です。プロトコルにビルダー分離が組み込まれることで、MEV-Boost のリレーへの依存がプロトコルレベルで不要になります。バリデータにとっては、attestation 締切までの短時間に重いTX等の実行・検証を行う必要がなくなり、ペイロードの伝播時間にも余裕（約 9 秒）が生まれます。一方で、PTC（Payload Timeliness Committee）への参加や、ビルダーがプロトコル上の主体（最低 1 ETH のステーク）になるなど、ブロック生成に関するステークホルダーが大きく変わります。利用しているクライアント・MEV 関連ソフトウェアの ePBS 対応方針は、リリース前に必ず確認してください。

また、BAL（EIP-7928） によりブロックに平均 約 72 KiB 程度のデータが追加され、その検証（提供 BAL と生成 BAL の一致確認）が EL の処理に加わります。BAL は並列 I/O・並列実行・高速な同期を可能にする一方で、ガス上限の引き上げ（devnet で 200M を目標）と組み合わせると、CPU・ディスク I/O・帯域の要件は変化する可能性 があります。また、EIP-8037 等によるStateの増加速度の抑制は長期的なディスク容量の要件に影響します。

L2 開発者への影響

スマートコントラクト開発者への影響

まとめ

Glamsterdam は、Fusaka が切り拓いた データ可用性のスケーリング に続き、今度は L1 の実行そのもののスケーリングと、ブロック生成の仕組みの刷新 に踏み込む大型アップデートです。目玉は、リレーという信頼前提をプロトコルレベルで取り除く ePBS（EIP-7732） と、L1 の並列実行への扉を開く BAL（EIP-7928） の 2 つです。これらに、ステート肥大化対策・ガスコストの見直し（EIP-8037 ほか）や、開発者体験の改善（EIP-7708 / 7843 / 7954 / 8024）が組み合わさります。

ePBS は将来の inclusion list / preconfirmation、BAL は将来のさらなるスループット拡大や stateless 化といった、「未来への下準備」 としての性格が強い点も Fusaka と共通しています。一方で、本アップデートは執筆時点で devnet 段階にあり、スコープ・パラメータ・日程は今後も変動し得ます。運用者・開発者は、メタ EIP（EIP-7773）と各クライアントのリリースノートを継続的に確認することをお勧めします。

Omakase は Ethereum ステーキングの運用代行事業者（SSP, Staking Service Provider）として、ePBS をはじめとする本アップデートのクライアント対応やブロック生成まわりの運用変更を継続的に追っています。

参考文献

本稿は、以下の参考資料を元に作成しています。詳しく理解したい方は、こちらをご確認ください（特記なき参照日：2026 年 6 月 24 日）。

1. Ethereum Foundation（ethereum.org）「Glamsterdam」ethereum.org/roadmap/glamsterdam
2. Ethereum Improvement Proposals「EIP-7773: Hardfork Meta - Glamsterdam」EIP-7773
3. Ethereum Improvement Proposals「EIP-7732: Enshrined Proposer-Builder Separation」EIP-7732
4. Ethereum Improvement Proposals「EIP-7928: Block-Level Access Lists」EIP-7928
5. Ethereum Improvement Proposals「EIP-8037: State Creation Gas Cost Increase」EIP-8037
6. Ethereum Improvement Proposals「EIP-7976: Increase Calldata Floor Cost」EIP-7976
7. Ethereum Improvement Proposals「EIP-7981: Increase Access List Cost」EIP-7981
8. Ethereum Improvement Proposals「EIP-7778: Block Gas Accounting without Refunds」EIP-7778
9. Ethereum Improvement Proposals「EIP-7708: ETH transfers emit a log」EIP-7708
10. Ethereum Improvement Proposals「EIP-7843: SLOTNUM opcode」EIP-7843
11. Ethereum Improvement Proposals「EIP-7954: Increase Maximum Contract Size」EIP-7954
12. Ethereum Improvement Proposals「EIP-8024: Backward compatible SWAPN, DUPN, EXCHANGE」EIP-8024
13. Fellowship of Ethereum Magicians「EIP-7773: Glamsterdam Network Upgrade Meta Thread」ethereum-magicians.org
14. CoinDesk「Ethereum’s biggest protocol overhaul in years moves into its final development stage」（2026-06-16）coindesk.com
15. The Defiant「Ethereum’s Glamsterdam Upgrade Enters Final Devnet Phase With 200M Gas-Limit Target」thedefiant.io