Ethereum「Glamsterdam」、Hoodiでの更新を延期　ガス計算変更と既存契約への影響を調査

Ethereumのコア開発者は2026年10月22日、次期大型更新「Glamsterdam（グラムステルダム）」のHoodiテストネットへの適用を延期した。Ethereum Foundationによると、ガス計算を変更する提案EIP-8037と、メインネット上のスマートコントラクトとの相互作用を追加調査するためだ。

セキュリティ企業ChainSecurityは、提案されている変更によって、ガス不足で失敗した処理の再試行を守る仕組みが崩れる可能性を指摘している。同社は10月22日、13件の実例を発見し、影響を受けるプロジェクトへの責任ある開示を進めていると公表した。

10月23日時点で、Hoodiの新たな実施日は未定だ。メインネットでは12月1日、8日、9日が候補に挙がっていたが、日程決定は追加の影響調査とテストの進展を待つことになる。

■再試行を守る失敗処理に何が起きるのか

スマートコントラクトは、別のコントラクトを呼び出した際の失敗を受け止め、失敗記録の保存、バッチ処理の続行、代替処理などを実行することがある。このとき、単に供給されたガスが足りなかった場合にも失敗を確定すると、本来は実行できる操作の再試行が妨げられる。

ChainSecurityが10月13日に公開した分析は、攻撃者が意図的に少ないガスを供給する「insufficient gas griefing」に注目したものだ。出金や入金などのサブ処理だけをガス不足で失敗させ、その後の処理で失敗を確定させる攻撃を想定している。

こうした攻撃を防ぐため、コントラクトは呼び出し前に供給可能なガスを確認したり、呼び出し後の残量からガス不足を判定したりする。また、失敗記録を書き込むだけのガスが残らず、操作全体が巻き戻されることを暗黙の保護としている設計もある。

同社によると、Glamsterdamでは、状態の作成に使うガスの別勘定化や処理ごとのガスコスト変更によって、これらの前提が変わる。従来は途中で巻き戻されていた失敗処理が最後まで進み、再試行を無効にする記録や、誤った結果を保存する可能性がある。

問題の影響は、呼び出し先だけでなく、その間に入るコントラクトや、失敗を確定するまでの処理にも左右される。ChainSecurityは、外部呼び出しの失敗後も実行を続ける経路を追跡し、出金、バッチ処理、自動復旧などの結果を検証するよう開発者に促している。

■実行用と状態作成用に分かれるガス

分析の対象は、状態作成の課金を変更するEIP-8037と、状態へのアクセスコストを改定するEIP-8038だ。EIPはEthereumの仕様変更を提案する文書で、ガスはネットワーク上の処理に必要な資源を計量する単位である。

EIP-8037は、通常の実行ガスとは別に、状態作成用の予算「state-gas reservoir」を設ける。状態作成の料金はまずこの予算から支払い、不足分を実行ガスから支払う。トランザクション全体の料金には、両方の消費が反映される。

ChainSecurityが10月13日時点の仕様を分析した例では、未アクセスの新規ストレージスロットにゼロ以外の値を書き込む費用は、従来の22,100ガスから、実行ガス12,100と状態作成用97,920ガスに変わる。別予算が状態作成分を負担すれば、書き込みに必要な実行ガスは小さくなる。別予算が空なら、両方を合わせた110,020ガスを実行ガスから支払う。

既存のEIP-150は、呼び出し先へ渡せるガスを、所定の呼び出しコストを差し引いた残量の最大約63/64に制限する。2016年に導入されたこのルールは、呼び出しの深さを悪用するサービス拒否攻撃への対策にもなっている。提案されている別予算は全額が呼び出し先へ引き継がれ、この63/64制限は実行ガスに適用される。

そのため、実行ガスの残量を返すgasleft()だけでは、状態作成に使える予算を把握しきれない。呼び出し元に残る実行ガスが少なくても、別予算と組み合わせれば、以前は完了できなかった失敗記録の書き込みを実行できる場合がある。

■ガスの補充と返却で変わる四つのパターン

ChainSecurityは、失敗処理に影響する仕組みを四つに分けて説明している。一つ目は、状態作成用の別予算によって、少量の実行ガスでできる処理が変わることだ。失敗記録の書き込みがガス不足になることを前提にしている設計では、その記録が保存される可能性が生じる。

二つ目は、同じトランザクション内で新たに使用したストレージスロットをゼロへ戻す際の即時補充だ。分析対象の仕様では、状態作成費用を実行ガスから支払っていた場合、その未返却額を上限として、1スロット当たり最大97,920ガスが実行ガスへ戻る。残量を確認する位置によっては、ガス不足の検知や、その後の失敗処理の挙動が変わる。

三つ目は、中間のコントラクトがREVERTによって処理を巻き戻す場合だ。中間処理が状態作成に費やした実行ガスの一部が返却され、呼び出し元の失敗処理を続行できることがある。この経路では、中間処理にREVERTを実行するだけのガスが残っていることが条件となる。

四つ目は、固定のガス予算が不足することだ。状態作成費用やアクセス費用の引き上げによって、以前は十分だった供給量でも呼び出し先がガス不足になり得る。指定量を確実に渡せるかという確認と、その量で許可された全処理を完了できるかという確認の両方が必要になる。

同社は、呼び出し後の残量だけから失敗原因を判定する設計や、失敗処理自体のガス不足に依存する設計の見直しを勧めている。可能な場合は失敗を操作全体へ伝えて巻き戻し、失敗処理を必要とする場合は復旧経路を確保する。固定予算、プロキシを含む呼び出し経路、状態作成用予算が不足する条件も検証対象になる。

■Hoodi運用者は延期対応版を確認

延期は10月22日のAll Core Developers Execution会議、ACDE #248で決まった。Hoodiではエポック132,352、10月26日17時42分48秒UTC、日本時間10月27日午前2時42分48秒に更新する予定だった。Ethereum Foundationは、実行レイヤーのAmsterdam、合意形成レイヤーのGloas、および同時に予定していたガス上限2億への引き上げを設定から取り除いた。

FoundationのBarnabas Busaは同日、共有ネットワーク設定から有効化予定を除く変更を取り込んだ。暗号資産調査会社Protocol Watchの創業者Christine D. Kimも延期を伝え、Hoodi運用者にクライアントの対応を確認するよう呼びかけた。

Besu開発チームは10月22日、「Unschedule Amsterdam on Hoodi」の変更を取り込み、延期に対応する26.10.1を公開した。合意形成クライアントLodestarも、HoodiでのGloasとガス上限変更の予定を取り除くv1.50.1を公開している。

FoundationはHoodiのノード・バリデータ運用者に対し、実行レイヤーと合意形成レイヤーの両方で、延期対応を明記したリリースや設定を確認するよう求めている。旧日程を保持したソフトウェアは予定時刻に更新を実行しようとするため、各クライアントの手順に従った対応が必要だ。

Sepoliaでは10月6日13時53分36秒UTC、日本時間同日午後10時53分36秒にGlamsterdamが有効化され、ガス上限2億での検証が進んでいる。Hoodiはメインネット移行前の次の重要な検証段階となる。ACDE #248の議題では、Hoodiが順調に進めば翌週の合意形成側の会議でメインネット日程を決める構想が示されていた。

■容量拡大を支える変更と、これまでの検証

Glamsterdamは、実行レイヤーのAmsterdamと合意形成レイヤーのGloasを組み合わせる更新だ。Gloas側ではEIP-7732のプロトコル組み込み型の提案者・ビルダー分離、ePBSを導入する。Amsterdam側には、ガス計算変更に加え、EIP-7928のブロックレベルアクセスリストが含まれる。

ブロックレベルアクセスリストは、ブロック内でアクセスするアカウントやストレージなどを記録し、データ読み出しや処理の並列化を支える。ガス価格改定は、処理量が増える際の状態データの肥大化を抑え、容量拡大とノードの運用負担を両立させる狙いがある。

公開開発ネットワークPlatåbergetでは8月20日にGlamsterdamを適用した。開発者会議では、移行時にクライアントの問題でブロックの確定処理が一時停止したことが報告されている。9月のdevnet-9では大規模な状態での移行に加え、確定処理が止まる状況と復旧を検証するテストも行われた。

Digital Todayによると、メインネット適用への期待は当初の2026年前半から第4四半期へ移っていた。10月22日の会議で示された12月の3候補日も、Hoodiでの検証が順調に進むことを条件としていた。今後は影響範囲と対応方法の見極めが、日程判断の重要な材料となる。

Ethereum Foundationは8月から、ガス上限を固定値として扱うウォレット、インデクサー、ガス推定ツールなどに更新を求めていた。今回の調査では、こうした周辺ツールの対応に加え、既存コントラクトの失敗処理を新しいガス計算で検証する作業が焦点になる。

■Lidoが指摘した移行時の入金処理

合意形成側では、Lidoのエンジニアリング責任者Dima Gusakovが、ePBS導入時のビルダー登録に関する懸念を示している。10月15日のACDC #189では、移行時に保留中の入金を処理する際、同じ公開鍵を持つビルダー向け入金とバリデータ向け入金がどう扱われるかが議論された。

開発リポジトリの報告では、悪意ある運用者が0xB0で始まる出金認証情報を使ったビルダー入金を先に登録し、同じ公開鍵へのバリデータ用入金がその後ろに並ぶ例が示されている。移行時の登録処理によって後続の資金もビルダーへ加算されると、ステーキングサービスが想定するバリデータの生成や入金確認が妨げられる。

Gusakovは、バリデータ向けの入金をビルダー向けと区別する仕様変更を提案した。EtherWorldによると、開発者はSepoliaへの適用済みという開発段階や追加検証の負担を重視し、その時点では変更を採用せず、アプリケーション側の対応を求めた。この論点は、移行時の入金処理に備えるステーキング事業者の課題となっている。

■次の日程を左右する影響調査

コア開発者は、既存コントラクトへの影響を調べ、アプリケーション側の修正で対応できるか、追加の準備期間やGlamsterdamの仕様変更が必要かを判断する。対応内容によって、Hoodiで再検証する範囲とメインネットまでの工程が変わる。

次の更新Hegotáについても、候補EIPの評価と開発ネットワークの準備が並行して進んでいる。Glamsterdamの調査・検証と、後続更新の仕様検討をどのように進めるかが、開発チームの調整事項となる。

今回の発見は、メインネットへの適用前に既存アプリケーションの前提を検証する重要性を示している。容量拡大を支えるガス計算の変更を安全に導入するには、正常時の取引に加え、意図的なガス不足や復旧処理まで含めて確認する必要がある。

元記事: Ethereum Glamsterdam Delay: ChainSecurity Flags 13 Contracts Where Failures Turn Permanent