The biggest upgrade since The Merge? How will Glamsterdam affect Ethereum?

イーサリアムの次なる大規模アップグレードが、最終段階に入っている。

現在のイーサリアム公式ロードマップによると、Glamsterdam アップグレードは2026年後半にメインネットで正式に開始される予定であり、6月末の時点では、マルチクライアント開発ネットを中心に、組み込みPBS、ブロックレベルのアクセスリスト、ガスの再価格設定などのコア機能を継続的にテストする開発者ネットワークの最終テスト段階に入っている。ただし、具体的なアクティベーション日時はまだ確定していない。

一方、ソーシャルメディア上で最も話題になっているのは、間違いなくアップグレード後の「メインネットが10,000 TPSに到達」という直感的なパフォーマンスストーリーである。しかし、それ以外にも、今回のアップグレードはイーサリアムのブロック生成パイプラインと実行エンジンを根本から再構築するものであり、その変更の深さと影響範囲の広さから、開発者コミュニティでは「The Merge（イーサリアムマージ）以来最大のアップグレード」と広く認識されている。

では、この少しクールな響きの名前を持つ「Glamsterdam」（コンセンサスレイヤーのアップグレード「Gloas」と実行レイヤーのアップグレード「Amsterdam」を組み合わせたもの）は、一体何を変えるのか？ それは、これまでの問題点にどのように決別し、私たちの日常的なオンチェーン体験にどのような破壊的な変化をもたらすのだろうか？

1. なぜ「マージ以来最大のアップグレード」なのか？

これまでのDencunやFusakaのアップグレードが主にL2のデータ可用性（Blob）の基盤を築くためのものであったとすれば、Glamsterdamは焦点をL1に戻し、L1のパフォーマンスとアーキテクチャの大規模な見直しを引き起こすものである。

これは実際、イーサリアムが現在「L1を再び偉大にする」ための最もリアルな基盤の描写でもあり、つまり、ノードを実行するコストとネットワークの中央集権化リスクを同時に上昇させることなく、どのようにL1がより多くのトランザクションを収容できるようにするかということである。

しかし、一般ユーザーにとっては、過去のイーサリアムアップグレードは、しばしば「ガスは安くなるのか？スループットは向上するのか？」という、最も直感的な問題に単純化されてきた。しかし、正直なところ、差し迫ったGlamsterdamを単純に「手数料削減」や「スケーリング」だけで要約するのは難しい。

全体として、今回のアップグレードは、誰がブロックを構築するか、トランザクションがどのように実行されるか、ノードがどのように状態を読み取り同期するか、そして異なるオンチェーン操作にいくらのガスを支払うべきかなど、イーサリアムの基盤となる複数の重要な要素に関わるものであり、イーサリアムがブロックを生成・処理するための基本的なパラダイムを再設計するようなものである。現在開示されている技術的詳細によると、最も注目すべき核心的な変更は主に3つの側面に集中している：

• 組み込みPBS（ePBS）：ブロック提案者と構築者の間のゲーム関係を再構築し、外部中継への依存を排除する。
• ブロックレベルアクセスリスト（BALs）：トランザクション実行のための地図を事前に描き、並列処理とより高速なノード同期への道を開く。
• ガスの再価格設定：より精密なリソース課金モデルを導入し、高スループット環境下での状態の膨張を制御する。

まず、組み込みPBSを理解するには、イーサリアム上のブロックが必ずしも提案者（Proposer）自身によって提出されるわけではないことを知る必要がある。特に現在のMEV-Boostアーキテクチャの下では、ほとんどの提案者は、トランザクションの収集、順序付け、MEV収益の探索といった作業を専門のブロック構築者（Builder）に外部委託し、提案者は主に複数の候補ブロックから最も高い入札を提示したものを選択してネットワークに提出する役割を担っている。

この「ビルダーが組み立て、プロポーザーが提出する」という分業が、PBS（Proposer-Builder Separation）である。

しかし問題は、現在のこのメカニズムがイーサリアムの基礎プロトコルに完全に組み込まれていないことである。プロポーザーとビルダーは、プロトコル外のサードパーティ製ソフトウェアとMEV-Boostリレーサービスを介して、ブロックの入札、コンテンツの配信、支払いを実行しなければならない。

つまり、リレーはビルダーが最終的に完全なブロックを公開することを保証すると同時に、プロポーザーがブロックの内容を先に見て「裏切って」支払いを拒否することを防ぐという、脆弱で中央集権化された「信頼できる仲介者」の役割を担っているのである。

そして、EIP-7732で提案されたePBS（Enshrined PBS）はまさにこの問題点を解決するために、このゲーム関係を直接イーサリアムのコンセンサスプロトコルに組み込むことを目指している。サードパーティの中継を排除し、ビルダーをプロトコルがネイティブに認識する参加者とし、まずブロックのコミットメントと入札を提出させ、プロトコルが自動的に対応する支払いをロックし、その後、専用の「ペイロード適時性委員会（Payload Timeliness Committee）」がビルダーが時間通りに実行ペイロードを公開したかを判断する。

これにより、コンセンサスブロックと実行ペイロードの一部の処理プロセスを分離し、実行ペイロードの伝搬と処理のウィンドウを約2秒から約9秒に延長することができる。この数秒はわずかに見えるが、イーサリアムのスケーリングにとっては極めて重要である。つまり、ノードがより多くの時間を確保し、より大きなブロックやより多くのBlobデータを受信・処理できるようになり、ガスリミットをさらに引き上げるための余地を生み出すからだ。

次に、Glamsterdamの実行レイヤーにおけるもう一つの核心的なブレークスルーは、EIP-7928で提案されたブロックレベルアクセスリスト（BALs）である。

周知の通り、現在のイーサリアムノードは、ブロックを受け取る前に、そのブロック内の各トランザクションがどのアカウントを読み取り、どのコントラクトストレージにアクセスし、どの状態を変更するのかをブロックから直接知ることはできない。通常、トランザクションを実行する過程で、これらのデータ依存関係を徐々に発見する必要がある。

これは、大型倉庫に荷物を取りに行くのに、完全な荷物の場所リストがないようなもので、作業員は探しながら処理しなければならない。そのため、複数の人が同時に同じ在庫を変更するのを避けるために、多くの作業は厳密な固定順序（シングルスレッドのシリアル実行）で行われなければならない。

ブロックレベルアクセスリスト（BALs）は、各ブロックに完全な「状態アクセスマップ」を添付するようなものである。ブロックヘッダーで、そのブロック内のトランザクションセットがどのアドレスとストレージスロットにアクセスするか、そしてトランザクション実行後の状態結果を事前に宣言する。このマップを通じて、ノードは実行前にどのトランザクションが同じデータにアクセスし、どのトランザクションが互いに競合しないかを一目で判断できる：

競合しない部分については、ノードは事前にハードディスクから関連する状態を読み取り、一部のトランザクション検証と状態ルート計算を並行して処理できるため、すべての作業を厳密なシリアルキューに詰め込む必要がない。さらに、BALsはトランザクション完了後の状態変化も記録するため、一部のノードはネットワーク状態を同期・追跡する際に、これらの結果を利用して状態を再構築でき、すべてのシナリオでブロック内のすべてのトランザクションを最初から実行する必要がない（筆者の個人的な理解では、シャーディングの概念に少し似ている）。これにより、イーサリアムは完全に並列実行可能なブロックチェーンとなる。

したがって、長期的に見れば、これはイーサリアムメインネットがパフォーマンスの天井を突破するための基盤となる鍵である。

最後に、ガスの再価格設定である。これは主に経済的レバレッジを通じて、複数のオンチェーン操作におけるガス価格を大幅かつ根本的に調整するものである。

その理由は、現在のイーサリアムのガスコストと、ノードが実際に負担するリソース消費が完全に一致していないからである。例えば、純粋な複雑な計算は実行後、通常ノードに長期的な負担を残さない。しかし、新しいアカウントの作成、スマートコントラクトのデプロイ、新しいストレージスロットへの書き込みは、世界中のすべてのフルノードが永続的に保存しなければならないデータを生み出す。

これまで、これらの状態作成行為のコストは、それらがもたらす永続的なストレージコスト（状態爆発）を完全には反映していなかった。もしイーサリアムがガスリミットを引き上げた後も既存の価格設定を維持すれば、より多くのブロックスペースが急速に制御不能な状態データに変換され、最終的にはノードのハードウェアを完全に圧迫する可能性がある。

そして、Glamsterdamの範囲に含まれることが確定しているEIP-8037は、このルールを完全に再構築しようとしている。これには、計算と状態の分離会計が含まれており、新しい状態データのサイズに基づいてコストを再計算し、通常の計算ガスと状態ガスを分離する。また、状態の急増を制御し、大量の新しいアカウントを作成したり、大規模な冗長コントラクトをデプロイしたり、新しい状態に頻繁に書き込んだりするアプリケーションの操作コストは上昇する可能性がある一方、主に即時計算リソースを消費し、状態を継続的に増加させないアプリケーションは、より魅力的な料金体系となる。

結局のところ、Glamsterdamのガス改革は、単純に「全面値下げ」と理解されるべきではない。むしろ、あるトランザクションがどれだけの即時計算リソースを消費し、ネットワークにどれだけの長期的なストレージ負担を残したかを明確にし、異なる操作が実際の物理コストにより近い方法で料金を支払うようにすることである。

全体として、これら3つの部分は一見互いに独立しているように見えるが、実際には同じ究極の目標を指している。それは、イーサリアムメインネットのガスリミットと処理能力をさらに大幅に引き上げるために、事前に基盤となるコアインフラストラクチャを改造することである。

2. なぜブロックを単純に大きくできないのか？

多くの人は疑問に思うかもしれない。遅くて高いのなら、なぜガスリミットを直接引き上げて、ブロック容量を倍増させないのか？

これはよくある質問である。理論的には、メインネットの容量を増やす最も直接的な方法は、各ブロックで許可されるガスの上限を引き上げることである。なぜなら、ガスリミットが高ければ高いほど、1つのブロックに収容できるトランザクションと計算が増えるからだ。

しかし、ガスリミットは無制限に引き上げられる数字ではない。ブロックが盲目的に大きくなると、ドミノ効果が発生する。ノードは同じ時間内により多くのデータを受信し、より多くのトランザクションを実行し、新しい状態を計算する必要がある。処理速度が追いつかなければ、性能の低いノードは脱落しやすくなり、ブロックの伝搬と検証に遅延が生じ、最終的にネットワークの分岐と中央集権化のリスクが高まる。

同時に、トランザクションの増加は、イーサリアムのデータベースに永続的に書き込まれるアカウント、コントラクト、ストレージデータの増加も意味する。これらのデータはトランザクションの終了とともに自動的に消えることはなく、イーサリアムの状態データベースに蓄積され続け、状態をより速く膨張させる。

したがって、イーサリアムのスケーリングが直面しているのは単純な数学の問題ではなく、3つの問題を同時に解決する必要がある：

• まず、ノードが大きなブロックを伝搬・処理するためのより多くの時間をどのように確保するか。
• 次に、トランザクションを順次実行することによるパフォーマンスのボトルネックをどのように減らすか。
• 最後に、より多くのブロックスペースが急速に制御不能な状態膨張に変わるのをどのように防ぐか。

これがGlamsterdamの核心的なロジックである。先に盲目的にスケーリングしてからノードに耐えさせるのではなく、まずブロック生成、トランザクション実行、リソース価格設定の方法を再構築し、基盤からパイプラインを整備してから、自然にメインネット容量の増加への道を開くのである。

このうち、ePBSはスロット内のブロック処理フローを再編成することで、ノードに大きなブロックを伝搬・検証するためのより多くの時間を与える。BALsは状態アクセス関係を明示的に提供することで、クライアントの読み取り、実行、同期の効率を向上させる。ガスの再価格設定は、持続不可能な状態成長を制限する役割を担う。

2026年4月のGlamsterdam協調テストでは、コア開発者たちがマルチクライアント実装に集中したストレステストを実施し、アップグレード後の信頼できる容量の下限として2億ガスを技術目標として明確に掲げた。この目標の背後には、まさにePBS、BALs、状態ガスの再価格設定が共同で提供する基盤的なサポートがある。

もちろん、2億ガスはアップグレード後のシステムが持つ収容能力と将来の段階的な進化の方向性を示すものに過ぎず、メインネットがGlamsterdamのアクティベート当日に即座にガスリミットをこのレベルに引き上げることを意味するわけではない。

本当に重要なのは、イーサリアムがこれまでの「慎重な試行的スケーリング」から、「基盤構造の再構築を通じて、より大規模なメインネットスケーリングに事前に備える」方向へと移行していることである。

3. 一般ユーザーとイーサリアムエコシステムはどのような影響を受けるのか？

一般ユーザーの観点から見ると、Glamsterdamアップグ