EthereumのGlamsterdamアップグレードでState操作のGas価格が見直される：開発者とユーザーが知っておくべきこと

最終更新 2026年8月26日

EthereumのGlamsterdamアップグレードでState操作のGas価格が見直される：開発者とユーザーが知っておくべきこと

Ethereumで予定されているGlamsterdamアップグレードでは、一般ユーザーにはすぐには見えにくいものの、スマートコントラクト開発者やインフラ担当チームにとっては非常に重要な変更が導入される見込みです。それは、state関連の操作に対する新しいGas価格モデルです。

Ethereum Foundationのチームは、提案されている2つの変更、EIP-8037とEIP-8038について影響評価を公開しました。どちらも、拡大し続けるネットワークのstateに対して、EthereumのGasコストが実際の計算負荷やストレージ負荷をより正確に反映するようにすることを目的としています。実務的には、新規アカウントの作成、新しいストレージスロットへの書き込み、bytecodeのデプロイ、コントラクトストレージの読み取り、cold accountへのアクセスといった操作に対して、より適切に課金することを目指しています。

ほとんどのユーザーは、特に何か対応する必要はありません。ウォレット、RPCプロバイダー、ブロックビルダー、アプリケーションのフロントエンドは、自動的に手数料見積もりやトランザクション処理を更新することが見込まれています。ただし、Gasの前提をハードコードしている一部のコントラクトについては、Glamsterdamの本格導入前に見直しと修正が必要になる可能性があります。

なぜ今、Ethereumはstate操作の価格を見直すのか

Ethereumにおける「state」とは、フルノードが保持しなければならない生きたデータベースを指します。ここには、アカウント残高、コントラクトコード、ストレージ値、nonce、そしてチェーンの検証に必要なその他のデータが含まれます。DeFi、ステーブルコイン、NFT、L2の決済、リステーキング、オンチェーン基盤の拡大に伴い、このstateは大きく膨らんできました。

問題は、単なるストレージ容量だけではありません。stateへのアクセスは性能にも影響します。ノードがトランザクションを処理する際には、stateデータを効率的に読み書きする必要があります。もしGas価格がこれらの操作にかかる実際のコストを過小評価していると、特にGas上限が引き上がる局面で、ネットワークはスループットのボトルネックにさらされやすくなります。

Ethereumがstateアクセスの価格を大きく調整したのは、2021年のBerlinアップグレードが最後です。このとき、EIP-2929やEIP-2930を含む提案によって、access listやcold/warm accessの区別などが導入されました。それ以降、Ethereumの利用形態は大きく変化しています。直近のGas上限引き上げも、state拡大を持続可能にする必要性を一段と高めています。

そのため、GlamsterdamにおけるGasの再価格設定は、単なる手数料調整ではありません。ノード運用を現実的に維持しながら、より高いスループットを支えるためのEthereum全体のロードマップの一部なのです。

EIP-8037とEIP-8038で何が変わるのか

Glamsterdamの評価では、次の2つの提案に焦点が当てられています。

EIP-8037: 新しいアカウント、新しいストレージスロット、デプロイされたbytecodeを含む、新規stateの作成コストを見直す。
EIP-8038: SSTORE、SLOAD、cold accountアクセスなどのstateアクセス操作のコストを引き上げる。

基本的な考え方はシンプルです。Ethereumノードにより大きな負担をかける操作には、実際のリソース使用量に近いGasコストを課すべきだということです。

これは、数多くのストレージスロットを作成するコントラクト、たくさんのコントラクトをデプロイする仕組み、大量のcold read/writeを行う処理に特に関係します。こうしたパターンは、特定のDeFiプロトコル、スマートコントラクトのファクトリー、NFTミント基盤、アカウント抽象化インフラ、複雑なオンチェーンゲームなどでよく見られます。

目的は、Ethereumをより高いスループットに備えさせること

評価レポートの重要なポイントのひとつは、新しい価格設定が、おおむねベースラインの約3倍のスループットを支えられる性能目標に合わせて調整されていることです。これは、GlamsterdamだけでEthereumの処理能力が一夜にして3倍になる、という意味ではありません。むしろ、この再価格設定は将来的にGas上限を安全に引き上げるための前提条件なのです。

2025年のEthereumスケーリングは、ますます多層化しています。ロールアップは引き続きユーザー活動の大部分を担い、Ethereumメインネットは決済層、流動性層、セキュリティ層として機能しています。EIP-4844以降、blobベースのスケーリングが進化していく中でも、メインネットの実行効率は依然として重要です。L1のstate操作が引き続き過小評価されたままだと、スループット向上のしわ寄せがノード運営者に及び、分散性が損なわれるおそれがあります。

つまり、Glamsterdamの再価格設定は、スケーリングのためのアップグレードであると同時に、防御的なアップグレードでもあります。ネットワークを高価すぎたり、検証しにくすぎたりすることなく成長させ続けるための措置なのです。

影響はどのように評価されたのか

実際の影響を見積もるために、Ethereumの研究者たちは、提案されたGasスケジュールのもとで過去のメインネットトランザクションを再実行しました。この方法により、新しい価格ルールを適用した場合に、どのトランザクションの挙動が変わるのかを把握できます。

結果は、次の4つの大まかなカテゴリに分類されました。

影響を受けないトランザクション
過去のトランザクションの大半はこのグループに入ります。再価格設定される操作にあまり依存していないか、すでに十分なGas余裕があるためです。
成功はするが、消費Gas量が変わるトランザクション
一部のトランザクションは引き続き有効ですが、Gas使用量や実行の詳細が変わります。価格ルールが更新されれば、これは自然な変化です。
元の上限ではGas切れになるが、上限を上げれば成功するトランザクション
これらは本質的に壊れているわけではありません。新しい価格モデルのもとでは、単により多くのGasが必要になるだけです。
かなり高いGas上限でも失敗し得るトランザクション
これが最も数は少ないものの、最も重要なカテゴリです。こうした失敗は、コントラクト内部のロジックで特定のGasコストを前提にしていることを示している場合が多いです。

開発者が注目すべきなのは最後のカテゴリです。コントラクトが低レベル呼び出し、fallbackの挙動、プロキシパターン、実行分岐などで固定のGas前提を使っている場合、Gasスケジュールの変更によって予期しない動作をする可能性があります。

なぜハードコードされたGas前提は危険なのか

スマートコントラクトは、本来、特定のopcodeに対する正確なGas価格に依存しないよう設計するのが理想です。EthereumはこれまでもGasコストを変更してきましたし、今後プロトコルが進化する中で再び変更される可能性があります。ある操作が常に同じコストだと想定するコントラクトは、脆くなりがちです。

代表的なリスク領域は次のとおりです。

固定Gasを指定した低レベル呼び出し
余裕のないGasマージンに依存するfallbackまたはreceive関数
Gasを手動で割り当てるプロキシやファクトリーコントラクト
gasleft() によって制御フローを分けるコントラクト
内部実行コストの見積もりが攻めすぎているバッチ実行システム
Berlin型のcold/warm access価格設定以前に書かれたレガシーコントラクト

だからといって、これらすべてのコントラクトが失敗するわけではありません。多くはこれまでどおり正常に動くでしょう。ただ、Glamsterdamは、Gasを永続的な定数ではなく、プロトコルの変数として扱うべきだということを改めて示しています。

開発者は、最新の仕様詳細についてEthereum Improvement Proposalのリポジトリを確認し、クライアント実装に関する議論はEthereum EIPsのGitHubリポジトリで追うことができます。

開発者がGlamsterdam前にやるべきこと

スマートコントラクトチームにとって最善の対応は、メインネット稼働を待つのではなく、先回りしてテストすることです。実践的なチェックリストは次のとおりです。

1. Gasに敏感なロジックを監査する

次のようなコードがあれば見直してください。

gasleft();
低レベルの.call{gas: ...}();
固定の実行バッファ;
カスタムのリレイヤーやバンドラーによるGas計算;
最小実行コストを前提にしたfallback関数;
非常に厳しいGas上限でデプロイされるファクトリー。

コントラクトの正しさが正確なGas挙動に依存しているなら、より慎重な確認が必要です。

2. デプロイやバッチ処理を再テストする

他のコントラクトをデプロイするコントラクトや、新しいストレージスロットを大量に書き込む処理は、EIP-8037のもとでコストが上がりやすくなります。バッチミント、vault作成、アカウントデプロイ、ブリッジ処理、レジストリ更新などは、新しいルールでテストすべきです。

3. Platåbergetテストネットで検証する

Ethereum Foundationチームは、開発者がPlatåbergetテストネットを使って、Glamsterdam風の価格設定で修正が機能するか確認できると案内しています。複雑な実行フローを持ち、ローカルでは再現しづらいプロトコルにとっては、専用ネットワークでのテストが特に有効です。

4. Gas見積もりの前提を更新する

フロントエンド、SDK、リレイヤー、バンドラー、アカウント抽象化サービスは、トランザクションのシミュレーションとGasバッファが更新されていることを確認してください。コントラクト自体に問題がなくても、見積もりが甘いとトランザクション失敗やユーザー体験の悪化につながります。

5. 統合先との連携を図る

ウォレット、アグリゲーター、カストディ型プラットフォーム、分析プロバイダー、自動マーケットシステムなどに組み込まれているプロトコルなら、既知の変更点は早めに共有してください。Gas再価格設定は、コントラクト本体だけでなく、トランザクションをシミュレーションしたりルーティングしたりするオフチェーンシステムにも影響します。

一般のEthereumユーザーがやるべきこと

普通のユーザーにとって答えはシンプルです。手動での対応は不要です。

資金を移動したり、資産を再デプロイしたり、何かを承認したり、ウォレットの保護方法を変えたりする必要はありません。インフラ提供者がソフトウェアを更新すれば、ほとんどの変更は裏側で処理され、Gas見積もりやトランザクションシミュレーションが改善されるはずです。

とはいえ、特に多くのストレージ書き込みやコントラクトデプロイを伴う複雑な取引では、アップグレード後に少し高くなる場合があります。シンプルな送金や一般的な操作への影響は、かなり小さいと見られています。

いつものことですが、大きなネットワークアップグレードの時期にはフィッシング詐欺に注意してください。プロトコルアップグレードのために、シードフレーズの入力や秘密鍵のエクスポート、あるいは見知らぬサイトでの「ウォレット移行」は必要ありません。

これはEthereumの長期設計にとって何を意味するのか

Glamsterdamによるstate操作の再価格設定は、ブロックチェーン基盤における繰り返しのテーマを浮き彫りにしています。それは、スケーラビリティは単にブロックスペースを増やすことだけではなく、希少なリソースを正しく価格付けすることでもある、という点です。

state負荷の高い操作に対してGasが安すぎると、ネットワークはノードが無理なく処理できる速度を超えて成長してしまう可能性があります。逆に高すぎれば、有用なアプリケーションが不必要に高コストになります。Ethereumの課題は、イノベーションを支えつつ、分散性を守れるバランスを見つけることです。

これは、Ethereumのロードマップが複数の方向で進化している現在、特に重要です。

より大規模で効率的なL2エコシステム
ロールアップ向けのより良いデータ可用性
実行レイヤーの性能向上
アカウント抽象化の普及
長期的なstate管理研究
将来のGas上限引き上げに向けたより安全な条件

Glamsterdamは、その大きなロードマップの一部にすぎません。直接的な影響は限定的かもしれませんが、その設計目標は基盤的です。つまり、Ethereumをより高い処理能力へ進める前に、まずリソース価格を現実に近づけることなのです。

セキュリティ上の注意：プロトコルアップグレードで秘密鍵の扱いは変わらない

Gas再価格設定が影響するのはトランザクション実行コストであり、ユーザーが資産を管理する方法ではありません。ネットワークがハードフォーク中であれ、テストネットの予行演習中であれ、クライアントのアップグレード期間中であれ、ユーザー側で最も重要なセキュリティ原則は変わりません。秘密鍵はオフラインで保管し、トランザクションは慎重に確認することです。

EthereumのDeFi、NFT、ステーキングサービス、L2ブリッジを利用するユーザーにとって、ハードウェアウォレットは重要なセキュリティ層になります。OneKeyは、秘密鍵をオフラインで守りながら、署名前にトランザクション詳細を確認できるよう支援する設計です。ネットワークアップグレードによってEthereumがより高機能になる一方で、安全な自己管理はエコシステムに安心して参加するために不可欠です。

Glamsterdamは、多くのユーザーに大きな混乱をもたらすことはないでしょう。しかし、Ethereum開発者にとっては重要な技術的ステップです。Gasに敏感なコントラクトを扱うチームは、早めにテストを行い、前提を更新し、メインネットへの導入前に統合作業を整えておくべきです。