テクノロジーインサイト一覧へ戻る
2026.08.17

Glamsterdam のガス再価格付けで「21,000ガス固定」が崩れる——EIP-8037 の状態ガス次元と、ウォレット・インデクサ・見積りツールが壊れる箇所

Glamsterdam のガス再価格付けで「21,000ガス固定」が崩れる——EIP-8037 の状態ガス次元と、ウォレット・インデクサ・見積りツールが壊れる箇所

何が起きたか

2026年8月17日、Ethereum Foundation の Protocol DevOps チームがブログで Platåberget テストネットを告知した。位置づけは、Glamsterdam(コンセンサス層の Gloas と実行層の Amsterdam の合成)の早期テスト場であり、これまでの短命な devnet と異なり数か月にわたって稼働させる想定である。テストネット上での Glamsterdam フォークは8月20日に予定された。告知の冒頭に置かれた要約は明確で、上限ガスをハードキャップとして扱うツール(ウォレット、インデクサ、ガス見積りツール)は「壊れるので更新が必要」と書かれている。

Glamsterdam に含まれる主な変更として告知が挙げているのは次のとおりである。EIP-7732 によるプロトコル内蔵のプロポーザ・ビルダー分離(ePBS)は、ブロックの構築・提案・検証の流れを変え、新しいビルダーAPIフローと PTC(ペイロード適時性)チェックを持ち込む。EIP-7928 のブロックレベル・アクセスリスト(BAL)は、参照された状態位置とトランザクション後の変化を記録する強制アクセスリストで、ブロック本体とは別に保存され、実行層のピア間では eth/71(EIP-8159)でやり取りされる。EIP-8007 は約2億ガスを下限として狙うガス再価格付けの束である。コントラクトと initcode のサイズ上限は、デプロイ済みコードが24 KiB から64 KiB へ、initcode が48 KiB から128 KiB へ引き上げられる。加えて EIP-7688 による前方互換なコンセンサスデータ構造が含まれる。EIP の全リストはメタ EIP-7773 で管理されている。

なお Platåberget 向けのクライアントリリースは「任意」とされており、当面は ethPandaOps のコンテナイメージを使う運用が案内されている。これはテストネットの参加条件であって、メインネット適用時の必須要件とは別物である。

何が壊れるのか——状態ガス次元の設計理由

再価格付けの本丸は EIP-8037 である。新しい状態を作る操作に対して、既存のガスとは別の「状態ガス次元」を導入する。アカウントの作成、コードのデプロイ、未使用のストレージスロットへの書き込みは、状態バイトあたりの固定費(CPSB)として計量され、しかも事前ではなく実行時に課金される。

設計理由は状態成長の抑制にある。EVM のガスは本来「計算量」と「状態の永続的な増加」という性質の異なる2つのコストを1本の数値に押し込めてきた。ブロックのガス上限を2億へ引き上げれば、計算資源の余裕は増えるが、同じ比率で状態も膨らむ。状態は一度書けばノードが永続的に保持するコストであり、計算とは費用の性格が違う。次元を分けることで、スループットを上げつつ状態成長だけを別枠で抑えられる。今回の変更は「値上げ」ではなく「価格の次元を増やす」ことに本質があると考えられる。

実務への影響は具体的である。EF の説明によれば、既に存在するアカウントへの ETH 送金は依然として21,000ガスだが、その内訳は TX_BASE_COST・COLD_ACCOUNT_ACCESS・TX_VALUE_COST へ分解される(EIP-2780)。一方、まだ存在しないアカウントへの送金は、これに加えて STATE_BYTES_PER_NEW_ACCOUNT × CPSB の状態ガスが実行時に発生する。つまり同じ「ETHを送る」という操作でも、宛先が新規かどうかで消費ガスが変わる。21,000で足りると仮定しているコード、単一のガス次元で見積りを行っているコードは、すべて見直しの対象になる。状態アクセスの値上げは EIP-8038 が担う。

ガス以外の2つの変更も、影響を受ける層が異なるだけで破壊的である。ePBS はブロックの構築・提案・検証のパイプラインを組み替えるため、MEV-Boost のリレーを前提にした構成、独自のブロック構築ソフトウェア、DVT(分散バリデータ技術)の実装、大規模運用者の監視系がいずれも影響を受ける。EF は Platåberget のバリデータセットを小規模ながら誰でも参加できる形にし、バリデータ預金だけでなくビルダー預金のワークフローも試せるようにしている。これは、ソロステーカーから大規模事業者までが自分の構成で ePBS を試す機会を意図的に用意したということである。BAL は、参照された状態位置と変更を記録した強制アクセスリストをブロック本体とは別に保持し、実行層のピア間で eth/71 によってやり取りする。ブロックの取得と再構築を自前で実装しているインデクサやアーカイブノードは、ネットワークプロトコルの層で対応が要る。

2026年5月時点で報告されていたパラメータでは、新規アカウント作成のコストが約8.5倍、コントラクトデプロイのコストが約10倍になるとされていた。ただしこれは当時の暫定値であり、確定値ではない。記事執筆時点で参照すべきはメタ EIP-7773 と devnet-8 の仕様である。

想定される落とし穴

第一に、告知本文が示す数値と、リンク先の EIP の記述が一致しない箇所がある。コントラクトサイズの項目で EF は EIP-7954 をリンクしつつ 24 KiB→64 KiB、48 KiB→128 KiB と記載しているが、EIP-7954 の本文は 32 KiB/64 KiB、EIP-7907 の本文は 64 KiB/128 KiB とそれぞれ異なる値を持つ。実装値を確定させるには、告知や解説記事ではなくメタ EIP-7773 と devnet-8 仕様を参照する必要がある。

第二に、「既存コントラクトは動く」が「既存ツールは動く」を意味しない。バイトコードの意味論はほぼ変わらないが、ガス見積り・シミュレーション・リプレイの層は壊れる。テスト計画をコントラクトのユニットテストで組んでいると、影響が本番のフロントエンドで初めて出る。

第三に、実行時課金であることが見積りの前提を変える。事前に固定費として引かれるのではないため、静的な計算式で上限を出しているコードは、状態を作る分岐が走ったときだけ不足する。失敗の出方が「常に失敗」ではなく「宛先や条件によって時々失敗」になるため、テストで再現しにくい。

第四に、Platåberget のクライアントリリースが任意である点を、メインネットの必須性と混同してはならない。テストネットは今テストするための場所であり、メインネット適用日は記事時点で未確定である。適用日が決まってからの着手では、ガス関連の修正には時間が足りない可能性が高い。

【技術インサイトとアクション】

  1. ガスを1本の数値と見なす前提が崩れる。状態ガス次元の導入は、「トランザクションのコストはガス量×ガス価格で一意に決まる」という設計を前提にしたコードすべてに波及する。同じ前提はブリッジの手数料計算、L2のフィー見積り、バッチ処理のサイズ決定にも埋め込まれていることが多い。 [コントラクト開発者・プロダクト側] 今月中に、コードベースを 21000 と gasLimit のハードコードで全文検索し、該当箇所を Platåberget で実行して差分を測定する。
  2. 変更が有効になるのはクライアント更新時ではなくフォーク時である。テストネットのリリースが任意であることは、準備の緊急度が低いことを意味しない。むしろ数か月稼働する Platåberget は、メインネット日程が決まる前に壊れ方を観測できる唯一の期間である。 [インテグレーター・ツール保守者] Sepolia フォークの日程が確定する前に、Platåberget に対して統合テスト一式を通し、ガス見積りとインデクサの再構築を実機で検証する。
  3. 仕様の数値は、告知・解説・EIP本文の3層で食い違うことがある。技術者向けの記事や社内資料に数値を転記する際、出典を「告知」レベルで止めると、後で仕様が違ったときに原因の特定ができない。 [全員] 社内共有の際は、参照元をメタ EIP-7773 と devnet-8 仕様に固定し、記事や告知から転記した数値には出典と参照日を併記する運用に切り替える。

【引用:出典】

本記事は公開情報に基づく技術解説であり、投資助言を目的としたものではありません。