イーサリアムのGlamsterdamアップグレード、20万件のスマートコントラクトが機能停止のリスクで反発が拡大
重要ポイント
- •セキュリティ研究者らは、Glamsterdamの新しいガス価格ルールが約20万件の展開済みスマートコントラクトに影響を与える可能性があると推定しており、分析方法の弱点から実際の数はさらに多い可能性があるとしている。
- •EIP-8037はコントラクト作成の基本ガス料金を32,000から183,600に引き上げるもので、セキュリティ企業ChainSecurityはアプリケーションにおいて破綻し得る固定ガスの前提を8件特定した。
- •11月8日に提出された2つの互換性提案——命令セットを旧版とV2版に分割するLeo GlisicのEIP-8488と、Giulio Rebuffoのデュアルガスメーターのドラフト——は、Glamsterdam向けに承認されておらず、目標日付も明示していない。
- •Curve Finance創設者のMichael Egorovとイーサリアム投資家のRyan Berckmansは一時停止を公に求め、Egorovは緊急ハードフォークの可能性を警告し、Berckmansは迅速なアクティベーションを求めた以前の発言を撤回した。
- •開発者はHoodiテストネットワークでの10月26日のGlamsterdamアクティベーションを延期しており、イーサリアム財団はセキュリティ企業ChainSecurityとDedaubとともに影響を受けるアプリケーションを確認し、開発者からのフィードバックを収集している。
イーサリアムの開発者や投資家は、新しいガス価格ルールが既存のスマートコントラクトを壊す可能性が指摘される中、次期大型アップグレード「Glamsterdam」への慎重な対応を求めている。セキュリティ研究者らは、ユーザー資金を保管し更新できないコントラクトを含め、約20万件のコントラクトが影響を受ける可能性があると推定している。展開済みのイーサリアムコードはデフォルトで不変であるため、現在のコスト構造の下で書かれたコントラクトは、新しい価格設定に対応させるための書き換えができない。
11月8日、2人の開発者が、Glamsterdamが既に使用中のコントラクトを壊すのを防ぐことを目的とする対立する提案を提出した。Curve Finance創設者のMichael Egorovは、現状の形でのアップグレードが緊急ハードフォークを引き起こす可能性があると警告した。緊急ハードフォークとは、ネットワーク全体のノード運営者が調整してアップグレードする必要がある、対応的なルール変更を意味する。イーサリアム投資家のRyan Berckmansも、Glamsterdamを迅速にアクティベーションするという以前の支持を撤回した。
10月29日の会議で、開発者は最短で11月16日から20日に非公開のGlamsterdamテストを実施することを暫定的に協議した。この日程は、2つの新しい提案が提出される前に話し合われたものである。
一時停止を求める声
Curve Finance創設者のMichael EgorovはX上で「Please don't break the chain（チェーンを壊さないでほしい）」と直接訴えた。現状の形でのGlamsterdamは「another emergency hard fork back, with a lot of drama（多くの混乱を伴う、もう一つの緊急ハードフォークの巻き戻し）」につながる可能性が高いと警告した。
Dear @ethereum – please don't break the chain. It does look like Glamsterdam in the current form would lead to another emergency hard fork back, with a lot of drama. I am sure, it can be made without breaking immutable contracts which hold funds — Michael Egorov (@newmichwill) November 7, 2026
イーサリアム投資家のRyan Berckmansは、リスクを確認した後に立場を変えた。当初は迅速な前進を支持し、イーサリアムはすべてのアプリケーションに対してガス価格を変更しないことを保証できないと主張していた。その後、X上で次のように書いた。
「We should (clearly, now) not continue towards Glam activation asap. I was wrong to say so（現時点で明らかに、Glamのアクティベーションを早期に進めるべきではない。そう言ったのは私の誤りだった）」とBerckmansはXに書いた。
We should (clearly, now) not continue towards Glam activation asap. I was wrong to say so. I since learned that the problem is essentially worse than is generally understood (incl by me). We have an urgent need for more people to write more things with data in public on this. — Ryan Berckmans ⟠ (@ryanberckmans) November 7, 2026
セキュリティ研究者のpcaversaccioは、アップグレードは現状の形で進めるべきではないと述べた。「imho Glamsterdam should not be shipped in its current form, period（私見では、Glamsterdamは現状の形でリリースされるべきではない。以上）」と同研究者は書き、ガス料金の引き上げが約2週間前にコア開発者に指摘されていたことを付け加えた。
匿名開発者のbantegは、公開分析で既に約20万件の影響を受ける可能性があるコントラクトが特定されていたと述べた。同開発者によると、分析方法の弱点により、さらに多くのコントラクトが見落とされている可能性があり、いくつかの著名なプロトコルも露出していたという。
ガス変更と2つの修正案
懸念の対象は、Glamsterdamに含まれる2つの提案、EIP-8037とEIP-8038である。イーサリアム改善提案（EIP）は、ネットワークがルール変更を定義し採用するための正式な仕様である。これらの提案は、コントラクトの作成とブロックチェーン上の保存データへのアクセスにイーサリアムが課すガス料金を引き上げるものである。
ガスとは、スマートコントラクトが実行する各ステップの価格を決める手数料である。EIP-8037の下では、コード保存および実行コストを除くコントラクト作成の基本料金が、32,000ガスから183,600ガスに引き上げられる。
多くのアプリケーションは、これらのコストが固定され続けるという前提で構築されていた。一部は別のアプリケーションを呼び出す際に固定額のガスを確保しており、価格の上昇はそれらの呼び出しの失敗につながる可能性がある。実際のコストがコントラクトが確保したガスを超えた場合、呼び出しは取り消される可能性がある。セキュリティ企業のChainSecurityは、破綻し得るこうした前提を8件特定した。
Leo Glisicの提案であるEIP-8488は、イーサリアムの命令セットを2つのバージョンに分割するものである。既存のコントラクトは旧ガススケジュールを維持し、新しいコントラクトは新しい価格設定を伴う「V2」オペコードを使用する必要がある。
Giulio Rebuffoの別のドラフトは、各トランザクションで2つのガスメーターを使用することを提案している。一方は旧ルールの下での実行を追跡してコントラクトが期待するコストを見せ、もう一方が新しい価格を使用して実際の手数料を決定する。
Rebuffoのドラフトは、この設計について実行クライアントの実装もコンセンサステストも実施されていないと述べている。EIP-8488とRebuffoの提案はいずれもGlamsterdam向けに承認されておらず、いずれも目標日付を明示していない。
テストの延期
開発者は、セキュリティ警告を受けて、Hoodiテストネットワークでの10月26日のGlamsterdamアクティベーションを延期した。Hoodiはイーサリアムの公開テストネットワークの一つで、今後のプロトコル変更はメインネットワークに到達する前にここでリハーサルされる。延期の対象には、Amsterdam実行レイヤーの変更、Gloasコンセンサスの変更、およびHoodiのガスリミットを2億に引き上げる計画が含まれていた。
11月6日、イーサリアム財団の開発者Marius van der Wijdenは、財団がChainSecurityおよびDedaubと協力して影響を受けるアプリケーションを確認していると述べた。チームは開発者からのフィードバックも収集している。
11月16日から20日に協議された非公開テストは、したがって暫定的なものであり、対立する2つの提案が提出される前に日程が組まれていた。今後の課題は、いずれかの互換性ドラフトがGlamsterdamのスコープに組み込まれるかどうか、また開発者フィードバックの収集が続く中、ChainSecurityとDedaubとの継続的なレビューで何が判明するかである。
