イーサリアム次の到達点 Glamsterdam：あなたが知っておくべき中核アップグレードポイント

なぜ Glamsterdam は、イーサリアム Merge 後で最も重要なアップグレードの 1 つになり得るのか？
執筆：KarenZ，Foresight News
イーサリアムの Glamsterdam アップグレードは、単なるスループット向上のための技術反復だと誤読されやすいです。より正確に言うと、出ブロック手順、検証手順、そしてリソースの価格付け方法などを再配置し、より高い Gas 上限、より大きな blob 容量、そして将来の並列実行に向けた“土台”を整えるものです。
2026 年 6 月 23 日時点で、ethereum.org は Glamsterdam を 2026 年後半に行われるアップグレード予定としてラベル付けしています。Glamsterdam という名前は、実行層のアップグレード Amsterdam と、コンセンサス層のアップグレード Gloas の組み合わせに由来します。公式ロードマップでは、2025 年 12 月の Fusaka の後、Hegotá の前に位置づけられ、主要機能として次の 2 点が明確に挙げられています。1 つ目は「プロトコル内の提案者 - 構築者分離」、すなわち ePBS。2 つ目は「ブロックレベルのアクセスリスト」、すなわち BAL です。
誰が提案し、誰が構築するのか：ePBS は出た分業をプロトコルに組み込む
今日のイーサリアムのブロック生成は、時間が非常にタイトな引き継ぎのようなものです。誰かがブロックを提案し、誰かが取引内容を構築する。その間には MEV-Boost やサードパーティ中継（relay）などのプロトコル外のインフラにも依存しています。
この仕組みは長年動いてきましたが、信頼の一部をプロトコルの外に置くことで、検証者がごく短い時間枠の中で、コンセンサス、実行、データ可用性などのタスクを同時にこなす必要がありました。
Glamsterdam の最大級の変更の 1 つが EIP-7732、つまり ePBS（Enshrined Proposer-Builder Separation）です。提案者と構築者の分業をプロトコルに書き込みます。
簡単に言うと、提案者はコンセンサスブロックを選び、構築者はその中身となる取引を用意します。構築者は口約束だけでは済みません。まずプロトコル内で「保証状」を提出します。どの実行ブロックを提出するのか、提案者にいくら支払う意思があるのかを明確に書くのです。その後、Payload Timeliness Committee（負荷の適時性委員会、PTC）が、期限どおりに提出されているかを確認します。
この変更の要点は、サードパーティの relay への依存を減らすことだけではありません。ブロックの伝播と検証のための時間を確保することにもあります。
今日、検証者は非常に短い重要なウィンドウ内で、コンセンサスと実行の両方を同時に処理する必要があります。ePBS はこの 2 つを分離し、実行負荷を後から開示・検証できるようにします。EIP-7732 の設計では、実行負荷の伝播ウィンドウ、つまりネットワークで伝播されノードが受信するまでの“利用可能時間”は、約 2 秒から約 9 秒へ拡張できます。ウィンドウが長くなれば、ブロック容量を増やすときも、ノードがダウンロード、検証、投票に間に合わず、取りこぼしや再編のリスクが増えることがより少なくなります。
この点は一般のユーザーには直接的な実感が薄いかもしれませんが、イーサリアムの拡容には非常に重要です。伝播と検証のウィンドウが長くなるということは、ネットワークがより安全に大きな負荷を処理できることを意味します。CoinDesk は 2026 年 6 月 16 日の記事で、イーサリアム基金会の DevOps エンジニア Parithosh Jayanthi の発言として、Glamsterdam は Merge 以来最大級のフォークの 1 つになり得て、イーサリアムについての多くの前提を変え、将来のより大規模な拡容に備えることになる、と伝えています。
BAL と再価格付け：拡容はアクセルを踏むだけでなく、データベースも管理する必要がある
Glamsterdam のもう一つのコアとなる変更は EIP-7928、Block-Level Access Lists（ブロックレベルのアクセスリスト）です。
これは、各ブロックに対する「アクセス記録」を用意するもの、と理解できます。ブロックを実行するときにどのアカウント、どのストレージ位置に触れたか、実行後に関連する状態がどうなったか——これらをすべて記録しておきます。そうすれば、ノードがブロックを処理するときに、もはや完全に“盲目の箱を開ける”ようにはなりません。どのデータを読めばよいのか、どの計算は並行に進められるのかを、より早い段階で把握できます。
過去の EIP-2930 は取引レベルのアクセスリストをすでに導入していましたが、それは任意で、実際の利用は限られていました。EIP-7928 の変更点は、アクセスリストをブロックレベルまで引き上げるところにあります。ブロックヘッダーに、このリストの「指紋」（ハッシュ記録）を残し、実行負荷は完全なリストを保存します。ノードはブロックを実行するときに照合し、リストに記載されたアクセス記録が、ブロック実行の過程と本当に一致しているかを確認します。一致しなければブロックは無効になります。
では、なぜ重要なのでしょうか？ いまのイーサリアムでは、取引を実行する際に多くのデータアクセスは、実際にその段階まで進めて初めて分かります。ノードは、ある一群の取引が同時に同じ口座やストレージスロットを読み書きするのかどうかを事前に知れないため、安心して並行処理するのが難しいのです。BAL は、ブロック実行の“アクセスの軌跡”を明示的に書き出し、クライアントが並行したディスク読み取り、並行した取引検証、並行した状態ルート計算を行えるようにします。また、特定の状況では、完全な再実行をしなくても取引を更新して状態を反映できます。ユーザーの手数料を直接下げるボタンではなく、クライアント側のエンジニアリングに並列化の余地を開くものです。
ただし、Glamsterdam の拡容ロジックは「道を広げる」だけではありません。イーサリアムのデータベースが長期的に膨らみ続けることも抑えます。EIP-8037 は状態作成コストを引き上げ、状態 1 バイトあたりのコストである CPSB を導入します。状態とは、イーサリアムが長期にわたって保存し続けるデータベースの内容だと捉えられます。たとえば新しいアカウント、新しいコントラクト、新しいストレージスロットなどです。取引の実行が終わっても状態は、すべてのノードが維持する帳簿の中に残ります。状態の増加が速すぎると、ノードの運用コストがどんどん上がり、分散性もゆっくり押し出される形で損なわれていきます。
EIP-8037 が示す背景の数字は直感的です。2026 年 1 月時点で、状態専用の Geth ノードデータベースは約 390 GiB です。メインネットの Gas 上限が 3000 万から 6000 万に引き上げられた後、1 日あたりの新規状態は約 105 MiB から約 326 MiB へ増えています。年換算の増加幅にすると約 116 GiB です。さらに Gas 上限 2 億で比例外挿すると、状態の年増加は約 387 GiB になり、1 年未満で 650 GiB という性能劣化の閾値を超える可能性があります。
つまり、EIP-8037 がやりたいのは「一時的な計算」と「永続的にデータベースを占有すること」を分けて価格付けすることです。新しい状態の作成はより高くなります。なぜなら、それがネットワークにもたらすのは“一度きりの計算コスト”ではなく、“長期のストレージ負担”だからです。
Vitalik Buterin も、Glamsterdam の拡容ルートについて説明する中で、Glamsterdam は状態作成コストを「実行コスト」と「calldata コスト」から切り出すと述べています。狙いは、実行容量をもっと拡大できるようにしつつ、状態規模は同じ速度では膨らまないようにすることです。
まとめて見ると、BAL はノードがブロックを並行処理しやすくし、“より速く動く”ことを可能にする一方で、状態作成の再価格付けは、データベースを長期的に占有する操作のコストをより高くすることで、“帳簿がどんどん太っていくのを防ぐ”ことに寄与します。Glamsterdam の拡容は単に Gas limit を引き上げる話ではありません。より現実的な問いを投げかけています——イーサリアムは、より多くの取引をさばけるのか。それと同時に、ブロック伝播、取引検証、状態ストレージの負荷が制御不能にならないようにできるのか。
Glamsterdam の EIP 一覧が固まってきた：どれが確定で、どれがまだ保留？
2026 年 6 月 23 日時点で、Forkcast 上のイーサリアム・アップグレードに関する追跡情報によれば、現在のイーサリアム開発者は Glamsterdam のアップグレードに向けて devnets 環境でテストを行っており、8 月 3 日に Sepolia で展開、9 月 16 日にメインネットで展開される予定です（具体的な時期は変更の可能性あり）。
現在 Glamsterdam のリストに含める予定となっているのは 10 個の EIP です：
EIP-7708（ETH 转账也会触发日志，便于索引和追踪原生 ETH 转账）
EIP-7732（ePBS，把提议者与构建者的分工写进协议，减少对协议外 relay 的依赖）
EIP-7778（取消与 Gas refund 相关的区块 Gas 记账，使区块 Gas 计算更简单）
EIP-7843（新增 SLOTNUM 操作码，让合约能够读取当前 slot 编号）
EIP-7928（区块级访问列表 BAL，记录区块执行时访问过的账户与存储位置，为并行验证铺路）
EIP-7954（提高最大合约大小上限，允许更大的合约字节码）
EIP-7976（提高 calldata floor cost，调整 calldata 的最低成本）
EIP-7981（提高访问列表成本，重新校准 access list 的 Gas 定价）
EIP-8024（向后兼容的 SWAPN、DUPN、EXCHANGE 操作码，增强 EVM 栈操作能力）
EIP-8037（提高状态创建 Gas 成本，抑制状态数据库の過度な膨張）
これらの EIP は大まかに 3 つのカテゴリに分けられます。第 1 はブロック提案および検証プロセスの再構築で、EIP-7732 と EIP-7928 が中核。第 2 はリソースの価格調整で、EIP-7778、EIP-7976、EIP-7981、そして EIP-8037 を含みます。第 3 は EVM と開発者体験の変更で、EIP-7708、EIP-7843、EIP-7954、EIP-8024 が該当します。
言い換えると、Glamsterdam は単一の機能をいじるだけではありません。ブロックの分業、並行検証、Gas の価格付け、そして EVM の使い勝手を同時にアップグレードするのです。
さらに、別の EIP 群は「導入を検討」リストのままです：
EIP-2780（リソースの区分ごとにトランザクション intrinsic Gas を分解）
EIP-7610（空でないストレージ口座の作成合約時にロールバック）
EIP-7688（将来に向けた互換性のあるコンセンサス層データ構造）
EIP-7904（Gas コスト分析の計算。Glamsterdam から外される可能性あり）
EIP-7975（eth/70、一部のブロックのレシートリスト）
EIP-7997（決定的ファクトリー合約）
EIP-8038（状態アクセス Gas コスト更新）
EIP-8045（罰金を課された検証者が引き続きブロックを提案することを排除）
EIP-8061（退出および合併 churn の引き上げ）
EIP-8070（eth/72、Sparse Blobpool）
EIP-8080（退出で consolidation queue を利用）
EIP-8136（データ列ブロードキャストの cell-level deltas）
EIP-8159（eth/71、ブロックアクセスリストの交換）
EIP-8246（SELFDESTRUCT の burn を削除）
EIP-8282（Builder Execution Requests。ePBS の構築者に対して専用の登録・退出リクエストを提供）
加えて、Forkcast は現在、EIP-8254（実行層ブロックに含める deposit requests の数を 8192 個に制限）を「導入を推奨」リストとして掲げています。
ステーキング（質入れ）側の観点から見ると、リストに含めることが検討されている EIP-8061 と EIP-8080 は特に注目に値します。ステーキングする人にとっては、退出の流動性が改善する可能性を意味します。Figment は 2026 年 5 月 5 日の記事で、機関投資家のステーキングでは特に ePBS、EIP-8061、EIP-8080 を最優先で見るべきだと述べ、2026 年 4 月時点で約 3,890 万枚の ETH がステークされている規模を前提に、EIP-8061 により退出 churn limit を 256 ETH/epoch から約 1187 ETH/epoch へ引き上げられる可能性があると試算しています。さらに EIP-8080 では、一般的な退出が合併キューの余力を活用できるようになります。Figment は同時に、メインネットのリリース前の数値はすべて推測として扱うべきだとも注意しています。
出典：Figment
プロトコルはアップグレードし、基金会のメンバーも入れ替わる
Glamsterdam の技術準備と、イーサリアム基金会のプロトコル・クラスター（Protocol cluster）に関する人事調整は、ほぼ同時期に進んでいます。イーサリアム基金会の 2026 年 5 月 11 日付ブログによれば、Glamsterdam はいくつかのマイルストーンを達成しました。2 億 Gas limit floor を、post-Glamsterdam の信頼できる目標として設定。ePBS は複数クライアントの Glamsterdam devnet で安定稼働。EIP-8037 も最終稿を完了。
同じ記事で Protocol cluster のリーダー交代も発表されました。Will Corcoran、Kev Wedderburn、Fredrik が新しいプロトコル・クラスターのコーディネーターになります。元のコーディネーターである Barnabé Monnot、Tim Beiko はイーサリアム基金会を離れ、Alex Stokes は休暇を取ります。
基金会が 3 人の新しいコーディネーターに割り当てた役割は次の通りです。Will Corcoran はチーム横断の調整経験を持つ。Kev Wedderburn は zkEVM チームを率いる。Fredrik は Protocol Security と Trillion Dollar Security プロジェクトを率いる。
今回の変化はプロトコルチームにとどまりません。2026 年 6 月 18 日、Hsiao-Wei Wang が投稿し、休暇後に以太坊基金会の共同エグゼクティブ・ディレクターおよび取締役会メンバーの職を辞することを決めたと明かしました。
イーサリアム基金会の元研究員 Dankrad Feist は 2026 年 6 月 19 日に、EF を離れた人々は CROPS（検閲に抗し、捕獲に抗い、オープンソースで、プライバシーとセキュリティを重視する）信奉者だと述べました。問題は戦略ではなく運営だということで、今回の人材流出はイーサリアムにとってはややネガティブだとしています。Miden の共同創業者 Azeem は逆方向から解釈し、EF は自らを変えにくく、人材が流れた後には、イーサリアムのロードマップをより確実に実行できる新組織が生まれる可能性があり、エコシステムにとっては長期的には純増（ネットでプラス）になると考えていると述べています。
以太坊基金会内部人士的说法更像是一次划定边界：以太坊基金会临时联席执行董事 Bastian Aue（Aerugo）回应称，以太坊基金会成员离职原因包括战略分歧、岗位适配、机构正常变动或个人选择。EF 表示不会在社交媒体上讨论个人的人事问题，但强调离职者应有体面的离场方式。
その後、イーサリアム基金会は公式ツイッターのスレッドで、より明確な組織ストーリーを提示しました。イーサリアムの潜在力を実現するには、複数の組織が連合を組む必要があり、過去 1 年でいくつかの組織がエコシステムのレジリエンスと能力を共同で強化してきた、という内容です。EF が挙げた例には、6 月 23 日に発表された ethlabs（イーサリアムと ETH の次の段階での採用に焦点を当てる非営利の研究・開発ラボ）、2026 年 4 月に開始された Eth Apps Guild（イーサリアム ネイティブアプリの実際の採用を目指し、とくに新興市場に注目）（2026 年開始予定の Ethereum Economic Zone（同期的な可コンポーザビリティとゼロ知識のリアルタイム証明により、生態系の分断を減らすことが目標））、そして 2025 年に設立された Argot（Solidity とオープンソースのコンパイラツールを保守するエンジニア／研究者による自治的な集団）があります。
この公式スレッドにより、イーサリアム基金会の直近の変化がより理解しやすくなります。基金会は単に人やプロジェクトを外へ押し出すだけでもなく、中心的な調整を放棄することでもありません。イーサリアムのロードマップをより多くの組織が共同で担えるように分解していく可能性があるのです。
まとめ
したがって、Glamsterdam は EIP の集合としてだけ見るべきではありません。イーサリアムがより高いスループットに至る前に行う、エンジニアリング上の“組み替え”です。誰がブロックを作り、誰が提案し、誰が検証し、どのデータを長期保存し、どのリソースをより高く扱うべきか——それらが再びテーブルに載せ直されています。
技術面のキーワードは ePBS、BAL、そして多次元 Gas のはじまりです。組織面のキーワードはより現実的で、イーサリアム基金会が協調力を保てるか、そして基金会の外の新組織がその協調力を継続的なデリバリーにつなげられるか、という点です。
 参照：
 https://forkcast.org/upgrade/glamsterdam/
 https://ethereum.org/roadmap/glamsterdam/
 https://blog.ethereum.org/2026/05/11/protocol-update-may-26
 https://x.com/VitalikButerin/status/2027403360484430122