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

Glamsterdam が公開テストネット Platåberget で初フォーク ― EIP-8037 が「送金は21,000ガス」という前提を壊す

Glamsterdam が公開テストネット Platåberget で初フォーク ― EIP-8037 が「送金は21,000ガス」という前提を壊す

何が起きたか

Platåberget は2026年8月13日にジェネシスを迎え、8月17日に Ethereum Foundation の Protocol DevOps チームが公式ブログで告知、8月20日に Glamsterdam フォークを適用した。Chain ID は 7091047534。バリデータセットはパーミッションレスで、誰でもデポジットコントラクト経由でテストバリデータを立てられる。

このテストネットが従来の devnet と決定的に違うのは、新規チェーンとして始まっていない点である。Sepolia や Hoodi のように独自のジェネシス状態から立ち上げるのではなく、メインネットと同一の状態から出発し、8月20日のフォークで Glamsterdam のルールへ移行した。つまり、いま本番に載っているコントラクトが、フォーク前後でどう振る舞いを変えるかを、そのまま観測できる。

Glamsterdam のメタEIPである EIP-7773 は執筆時点で Draft のままで、Scheduled for Inclusion として10本が並ぶ。コンセンサス層のヘッドライナーが EIP-7732（Enshrined Proposer-Builder Separation、ePBS）、実行層が EIP-7928（Block-Level Access Lists、BAL）。そこに EIP-8037（State Creation Gas Cost Increase）、EIP-7778（払い戻しなしのブロックガス会計）、EIP-7708（ETH送金がログを出す）、EIP-7954（最大コントラクトサイズを約24KiBから32KiBへ）などが乗る。メインネットの目標は第4四半期で、当初の2026年上期から二度後ろ倒しされている。

なぜ状態生成ガスを分離しなければならなかったのか

読みどころは EIP-8037 である。この提案は、ストレージ確保・コードデプロイ・アカウント生成といった「状態を増やす操作」のコストを、通常の実行ガスから切り離し、状態バイト数に cost_per_state_byte（CPSB）を掛けた別枠で課金する。Glamsterdam における CPSB は 1530 に固定されている。

なぜ分けるのか。ガスリミットを引き上げれば処理できる量は増えるが、同時に状態データベースの成長速度も上がる。両者が同じガス単位で混ざっていると、スループットを上げる判断が、そのままノード運用者のディスク負担を増やす判断になってしまう。EIP-8037 は状態成長に専用の予算枠を設けることで、この二つを切り離した。Glamsterdam が 200M ガスリミットという水準を視野に入れられるのは、この枠が先に決まったからだと考えられる。設計としては「速くする」提案ではなく、「速くしても壊れない上限を先に引く」提案である。

さらに devnet-7 系のテストリリースでは、EIP-2780 と EIP-8037 の改定により、状態依存のトランザクションコストがイントリンシックガスから外され、トップフレームでの実行時課金へ移された。アカウント生成の状態ガスはアクセス時に条件付きで課金される。事前に多めに取って後で返す方式から、実際に触ったときに取る方式への変更である。

互換性の切れ目はどこか

EF の DevOps チームは、ガスリミットを固定値として扱っているツールについて「動作しなくなる」と明言し、即時の更新を求めている。ここが最も広く刺さる。

具体的には、送金に 21,000 を決め打ちしているコード、ガス見積もりをキャッシュして再利用しているバッチ処理、gasLimit を定数テーブルで持つインデクサやウォレットである。新規アカウントへの送金は、既存アカウントへの送金より高くなる。同じ transfer でも、宛先が既存か新規かでコストが変わるということは、送信前に見積もりを取り直さない実装は失敗するということだ。ePBS や BAL は主にバリデータとビルダーの領域だが、ガス再価格設定はウォレット・インデクサ・ガス見積もり器のすべてに触れる。影響範囲はこちらのほうがはるかに広い。

EIP-7954 によるコントラクトサイズ上限の引き上げは逆方向の変更で、これまで分割を強いられていた大きなコントラクトが1本で収まるようになる。ただし、24KiB を前提にサイズ検証しているデプロイパイプラインやベリファイアは、上限が変わったことを知らないままだと誤った判定を出す。

EIP-7708 は、ETH の送金と焼却がログを発行するようにする。これは監視側にとっては歓迎すべき変更で、これまで内部送金を追跡するために独自のトランザクショントレースを走らせていたウォレットや取引所は、通常のログ購読で同じ情報を得られるようになる。ただし逆向きの影響もある。同じ資金移動が、トレース経由とログ経由の二つの表現で観測できるようになるため、両方を素朴に集計している会計処理は二重計上する。移行期にはどちらを正とするかを先に決めておく必要がある。

EIP-7778 は払い戻し（リファンド）を伴わないブロックガス会計へ移行する。ガスの払い戻しは、ストレージ解放時に消費済みガスを返す仕組みで、ブロック単位の消費量を予測しにくくしていた。これを廃すればビルダーの予測可能性は上がるが、払い戻しを織り込んでガス上限を切り詰めていたコントラクト、とりわけ大量のストレージ解放を行うバッチ処理は、実効コストが上がる。ガス最適化のためにストレージのクリアをまとめて行っていた実装は、その最適化の前提を失う。

想定される落とし穴

第一に、Platåberget は「メインネットと同じ状態から分岐した」テストネットであって、Sepolia や Hoodi の代替ではない。ここで通ったからといって、公開テストネットでの検証を省略してよいことにはならない。逆に、既存デプロイ済みコントラクトの回帰テストという意味では、Sepolia より条件が近い。役割が違うので、両方走らせる前提で計画を立てるべきである。

第二に、EIP-8282 のビルダー用コントラクト（デポジット、Exit）はジェネシスに含まれておらず、Gloas フォークが有効になる前にオンチェーンへデプロイされる。ビルダー登録まわりをテストするなら、この二つのアドレスがいつ有効になるかを確認してから手順を組む必要がある。

第三に、変更が効くのはクライアントを更新した瞬間ではなく、フォーク高に到達した瞬間である。クライアントを先に上げても挙動は変わらないため、「更新したが何も起きない」ことを正常動作と誤認しやすい。逆に言えば、フォーク時刻に一斉に切り替わるので、段階的な移行はできない。

第四に、ACDC #185（8月20日）まわりの報告では、Platåberget（内部的には Glamsterdam devnet-8 として扱われている）で新しいビルダー機能を有効化した直後に、複数のクライアントが停止または遅延した。フォーク前は安定していたとされる。これは公開テストネットの日程が後ろに動きうることを意味しており、社内の対応期限を「Sepolia フォーク日」に紐づけて固定すると、日程が動いたときに緩む。期限は自分たちの側で切っておくのが安全である。

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

  1. ガスコストは「実行の対価」から「実行の対価＋状態成長の対価」という二次元に変わる。単一のガス値で世界を記述してきた前提が崩れるので、ガス値を単一のスカラーとして扱っているすべての層――見積もり、会計、上限チェック、料金転嫁ロジック――が影響を受ける。これは Ethereum に限らず、EVM 互換チェーンが同種の再価格設定を採用したときに繰り返される変更である。 ［コントラクト開発者・インテグレーター］ Sepolia での Glamsterdam フォークの2週間前までに、コードベース内の 21000・固定 gasLimit・キャッシュ済みガス見積もりを全件洗い出し、実行時見積もりへ置き換える。
  2. Platåberget はメインネットと同一状態から分岐した公開網であり、「いま本番に載っているコントラクトが、フォーク後にどう振る舞うか」を実測できる環境は通常存在しない。新規ジェネシスのテストネットでは、既存の状態依存バグは再現しない。 ［プロダクト側・QA］ 非ファイナリティ devnet の開始までに、本番デプロイ済みの主要コントラクトに対する回帰テストを Platåberget 上で一巡させ、フォーク前後の差分を記録する。
  3. ePBS はリレーを「必須」から「任意」に変えるが、移行直後は旧経路と新経路が併存する。単一経路を前提にした監視・アラート設計は、どちらの経路で落ちたのか切り分けられなくなる。 ［ノード運用者・ステーキング事業者］ メインネット適用日が確定する前に、ePBS 構成でのブロック提案・ビルダー登録・Exit の一連をテストネットで通し、監視項目を新旧両経路に対応させる。

【引用：出典】

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