Ethereum Glamsterdam Q4延期とL1再設計――state gas・ePBS・BALが示す次世代Ethereum

現在日時：2026-08-19 JST

要約

Ethereumの次期大型アップグレード「Glamsterdam」は、当初想定されていた2026年上半期から、2026年第4四半期（Q4）へ延期された。

ただし、この延期は単なる開発遅延というより、Glamsterdamのスコープが非常に大きく、Ethereum L1の

• ブロック生成
• 実行
• state管理
• gas accounting
• MEV基盤
• validator挙動
• wallet・indexer・RPC・gas推定

までを同時に変更する、極めて大規模な統合アップグレードであることを反映したものと考えるのが適切である。

Glamsterdamの中核は、概ね次の3本柱に整理できる。

この3つを組み合わせることで、Ethereumは将来的に200M gas級のL1処理能力を目指す基盤を整えようとしている。

1. Glamsterdamは何をするアップグレードなのか

一言で言えば、

L1をもっと大きくしても壊れないように、ブロック生成・実行・状態保存の仕組みを一度に作り替えるアップグレード

である。

従来のEthereumは、L2中心のスケーリング戦略を強く推進してきた。

しかし現在は、

• L2 scaling
• L1 scaling

を同時に進める方向へシフトしている。

Glamsterdamは、そのL1側の基礎工事に相当する。

2. 最重要の変更：EIP-8037とstate gas

今回もっとも重要な変更の一つが、EIP-8037によるstate gas dimensionである。

Ethereumでは、gas limitを上げれば理論上は1ブロックあたりの処理量を増やせる。

しかし単純にgas limitだけを上げると、

1. transaction処理量が増える
2. stateへの書き込みも増える
3. nodeのdatabaseが肥大化する
4. SSD容量・I/O・同期負荷が増える
5. 個人node運用が難しくなる

という問題が起きる。

つまり、スループットを上げるだけでは decentralization が損なわれる可能性がある。

EIP-8037では、この問題に対し、

• execution gas
• state gas

を分離して扱う。

概念的には次のようになる。

従来

Gas
├─ CPU
├─ memory
├─ storage
└─ state creation

↓

Glamsterdam

Execution Gas
├─ CPU
├─ opcode execution
└─ calldata

State Gas
├─ new account
├─ new storage slot
└─ new contract state

つまり、単純な計算負荷と、永続的にEthereum stateを増やす処理を別資源として評価する方向である。

これはEthereumのgas設計における大きな転換である。

3. なぜstate gasが必要なのか

Ethereum FoundationやEIP文書では、state databaseの肥大化が明確な問題として扱われている。

gas limitを60Mからさらに大きく上げる場合、state creationまで比例的に増えてしまうと、nodeのstorage requirementsが急速に増える。

そこで、

計算量は増やしてもよいが、永久stateを増やす処理には別の価格を付ける

という考え方が必要になる。

これは単なる手数料調整ではない。

Ethereumが将来的に、

• compute
• state
• calldata
• proof
• bandwidth

などを別々の有限資源として扱う方向へ進む可能性を示している。

推測ですが、Glamsterdamのstate gasは、本格的なmulti-dimensional resource pricingへの第一歩と見ることができる。

4. 200M gasを安全に目指すための設計

Ethereum開発者は、Glamsterdam後のgas limitについて、200M級を視野に入れている。

現在の約60Mから見れば約3倍であり、これは非常に大きな拡張である。

しかし、単純なgas limit引き上げではnode負荷が過大になる。

そのためGlamsterdamでは、

ePBS
↓
executionに使える時間を増やす

BAL
↓
並列処理・並列I/Oを可能にする

State Gas
↓
state肥大を抑える

3つを組み合わせる
↓
高いgas limitを安全に扱う

という構造を取る。

Glamsterdamは単一EIPによる性能向上ではなく、複数の基盤改修を組み合わせることでL1をscaleさせる設計である。

5. EIP-7928 Block-Level Access Lists（BAL）

BALはGlamsterdamの中でも特に重要な技術である。

Ethereumでは通常、transactionを実際にexecutionしてみなければ、そのtransactionが

• どのaccountを読むか
• どのstorage slotを読むか
• どのstateを書き換えるか

が完全には分からない。

これは並列実行を難しくする。

BALでは、block単位で、そのblockが接触するaccountやstorageを明示する。

例えば、

Tx A → Account A
Tx B → Account B
Tx C → Account C

のように依存関係がなければ、複数transactionを並列に処理できる可能性が生まれる。

これによって期待されるのは、

• parallel execution
• batched I/O
• parallel state-root computation

である。

つまりBALは、Ethereumが長年抱えてきた「EVMは基本的に逐次処理」という制約を緩和するための基礎技術である。

6. EIP-7732 ePBS

もう一つの中核が、EIP-7732による

Enshrined Proposer-Builder Separation（ePBS）

である。

現在のEthereumでは、MEV-Boostなどを介し、

Validator
↓
MEV-Boost
↓
Relay
↓
Builder

という構造でblock buildingが行われている。

このうち重要な部分がプロトコル外部に存在する。

ePBSでは、

Ethereum Protocol
├─ proposer
└─ builder

という役割分担をEthereum protocolそのものへ組み込む。

これによって、

• builder入札
• payload delivery
• proposer / builder責任分離
• block timing
• censorship resistance
• MEV market

などをprotocol levelで扱いやすくなる。

ePBSは単なるMEV改善ではなく、Ethereumのblock production architectureそのものを変える。

7. ePBSはL1 scalingにも効く

ePBSの重要な点は、block constructionとexecution payloadの受け渡しを明確化し、slot内の時間配分を最適化できることである。

これによってexecutionに使える時間を増やし、より大きなblockを安全に処理する余地が生まれる。

したがってePBSは、

• MEV architecture
• censorship resistance
• validator operation
• L1 throughput

のすべてに関係する。

8. Contract size limitの拡大

Glamsterdamでは、contract code size limitの拡大も予定されている。

これは、

• smart wallet
• ZK verifier
• 大規模DeFi protocol
• 複雑なaccount abstraction
• cryptographic verification

などの実装自由度を高める。

ただしcontract codeが大きくなればstateも増える。

したがって、

contractを大きくできるようにする しかしstate creationには別の価格を付ける

というstate gasとの組み合わせが重要になる。

9. Platåberget公開testnet

Glamsterdam専用の公開testnetとしてPlatåbergetが立ち上げられている。

従来のprivate devnetと異なり、外部のoperatorやclient developerが参加できるpublic testnetである。

目的は、

• client implementation
• fork transition
• interoperability
• validator behavior
• gas accounting
• tooling compatibility

などをmainnetに近い条件で検証することにある。

概念的には、

Private Devnet
↓
Platåberget Public Testnet
↓
Sepolia / Hoodi
↓
Ethereum Mainnet

という段階を踏む。

これは非常に合理的な工程である。

Glamsterdamほど大きなprotocol changeを、いきなり主要testnetに入れるより、専用public testnetで破壊的なテストを行った方が安全性は高い。

10. 「21,000 gasのまま」という記事記述への補正

元記事では、

既存accountへのETH送金は従来どおり21,000 gas

と説明されている。

しかし、現在のGlamsterdam仕様にはEIP-2780も含まれており、既存accountへの単純ETH transferではexecution側のgas costを引き下げる方向が示されている。

したがって正確には、

既存accountへの単純送金
↓
execution gasは軽くなる方向

新規accountへの送金
↓
state creation gasが追加される

と理解する方がよい。

元記事はEIP-2780とEIP-8037の関係を簡略化しすぎている可能性がある。

11. Ethereumは「multi-dimensional gas」へ進むのか

ここは注意が必要である。

以前議論されていたEIP-8011のような全面的なmulti-dimensional gas設計はGlamsterdamから外れている。

しかしEIP-8037では、

• execution gas
• state gas

という2種類のmeteringが導入される。

したがって、

全面的なmulti-resource gas architectureではないが、state creationについては実質的な2次元化

と評価できる。

これは将来のEthereumにとって大きな意味を持つ。

12. なぜQ4へ延期されたのか

Glamsterdamの延期は、単なる「開発が遅れた」というより、integration riskが非常に高いことが最大の理由と考えられる。

影響範囲は、

Consensus
Execution
Gas accounting
State DB
Builder market
Validator behavior
Wallet gas estimation
Indexer
RPC
Developer tooling

まで広い。

しかもEthereumはmulti-client ecosystemである。

Execution clients

• Geth
• Nethermind
• Besu
• Erigon

Consensus clients

• Lighthouse
• Prysm
• Teku
• Nimbus
• Lodestar

これらすべてが同じprotocol rulesを実装し、同じedge caseで同じ結果を返さなければならない。

Ethereumのhard forkでは、EIPを書くことそのものよりも、

多数のclient implementationを完全に収束させること

の方が難しい場合がある。

したがってQ4延期は、scopeを考えると合理的なengineering判断と評価できる。

13. Ethereum開発複雑性の増大

一方で、明確な課題もある。

Ethereumは現在、

• L1 scaling
• ePBS
• BAL
• state gas
• FOCIL
• account abstraction
• privacy
• PQC
• shorter slots
• statelessness

などを並行して研究・実装している。

そのため、protocol developerだけでなく、

• client teams
• wallet developers
• RPC providers
• indexers
• exchanges
• dApps
• node operators

まで対応負荷が増大する。

これは今後のEthereumにとってかなり重要なリスクである。

Ethereumの最大の課題は、単一技術の性能ではなく、

巨大ecosystem全体を同時にupgradeするcoordination complexity

へ移りつつある。

14. Hegotáへの影響

Ethereum公式roadmapでは、

となっている。

Hegotáについては多数のEIPが検討されており、

• censorship resistance
• privacy
• L1 throughput
• block production
• protocol simplification

などが候補に含まれている。

ただし、Glamsterdamが延期したからといって、Hegotáが必ず同じ期間だけ延期するとは現時点では断定できない。

一方でclient developerやresearcherは重複しているため、Glamsterdamのintegration作業が長期化すれば、Hegotáに連鎖する可能性はある。

15. Ethereumの戦略変化

Ethereumのスケーリング戦略は、以前の

L2中心

から、

L2 scaling + L1 scaling

へ明確に広がっている。

これは非常に重要な変化である。

L2 rollupを維持しつつ、Ethereum L1自体もより大きなtransaction execution capabilityを持つ方向へ進んでいる。

Glamsterdamはその基盤である。

16. Cardanoとの設計思想比較

EthereumとCardanoは、スケーリングに対する哲学がかなり異なる。

Ethereumは、

既存の巨大ecosystemを維持したまま内部構造を交換する

という非常に難しい道を選んでいる。

Cardanoは、

初期設計の制約を活用し、将来変更の複雑性を抑える

方向である。

どちらもtrade-offがあり、単純な優劣ではない。

17. PQC時代との関係

GlamsterdamはPQCそのものを導入するupgradeではない。

しかし将来のPost-Quantum Cryptography時代を考えると、今回の基盤変更は重要である。

PQCでは一般に、

• public key
• signature
• proof
• verification cost

が現在のECDSA系より大きくなる可能性がある。

その結果、

• computation
• bandwidth
• storage
• state
• block propagation

への負荷が増える。

この点は、金融分野のPQC移行報告書でも、PQCは従来暗号より通信量・計算量・署名データ量など少なくとも一つ以上のリソース消費が増える可能性があると整理されている。 fileciteturn0file0

したがって、

• resource-aware gas accounting
• parallel execution
• state control
• scalable block production

を先に整備することは、将来のPQC・ZK・privacy時代にとって意味がある。

18. 5段階シナリオ分析

Glamsterdamを中心に今後約2年を想定する。

中心シナリオはS4と考える。

19. 総合評価

今回のニュースを、

「Ethereumの開発が遅れている」

だけで評価するのは不十分である。

より正確には、

Ethereumがsimple blockchainから、大規模な分散実行OSへ移行する過程で、architecture complexityが表面化した

と見るべきである。

Glamsterdamでは、

stateを有限資源として明示的に価格付け
↓
executionを並列化
↓
builderをprotocolに取り込む
↓
block processing capacityを拡張
↓
L1 gas limitを大幅に上げる

という構造が形成される。

したがってGlamsterdamは、2026年の単なる高速化upgradeではない。

Hegotá、privacy、ZK、PQC、さらに高いL1 throughputへ進むためのEthereum基盤工事

と位置付けるのが最も適切である。

Fact Check

出典・情報源

1. Ethereum.org, Ethereum Roadmap

- https://ethereum.org/roadmap/

1. Ethereum.org, Glamsterdam

- https://ethereum.org/roadmap/glamsterdam/

1. Ethereum Improvement Proposals, EIP-7773: Glamsterdam Meta

- https://eips.ethereum.org/EIPS/eip-7773

1. Ethereum Improvement Proposals, EIP-8037: State Creation Gas Cost Increase

- https://eips.ethereum.org/EIPS/eip-8037

1. Ethereum Foundation Blog, Soldøgn Interop Recap

- https://blog.ethereum.org/2026/05/02/soldogn-interop-recap

1. Platåberget Public Testnet Repository

- https://github.com/pk910/plataberget-dev

1. 金融庁「預金取扱金融機関の耐量子計算機暗号への対応に関する検討会 報告書」

- PQCは既存公開鍵暗号よりも通信量・計算量・署名データ量等のリソース要求が増える可能性を指摘。 fileciteturn0file0

CGTA注記

• 確認済み：Ethereum公式Roadmap、Meta EIP、個別EIP、Ethereum Foundation資料を中心にfact check。
• 推測部分：「state gasが本格的multi-dimensional gasへの第一歩」「PQC・ZK・privacy時代への基盤」という評価は、現在の設計方向からのCGTAによる将来推定。
• 未確認：Hegotáの最終scopeおよびmainnet実施時期は確定していない。

作成年月日：2026-08-19 JST