Glamsterdamで変わるアプリの費用構造：状態作成と実行予算を分けて考える

Ethereum Foundationは11月6日、互換性の問題でGlamsterdamのハードフォーク工程を延期し、Hoodiのフォークも解決を待つと発表した。メインネット有効化の発表ではない。Foundationの説明

プロダクト側のリスクは、費用と業務処理の正しさの両方に及ぶ。従来は成功した新規ユーザーの操作が、古い予算を超える可能性がある。全体が巻き戻されていた失敗処理が、取り消せない失敗記録を残す可能性もある。すべてのgas予算に一律の係数を掛けても、正確な見積もりにはならず、資金やメッセージの処理が安全であることも証明できない。本稿は11月7日時点で確認した提案とテスト資料に基づく。パラメータや仕様は今後変わり得る。

利用者が払う費用と、ブロックに入る仕事量

EIP-8037は、新たな状態の作成を別枠で計量することを提案している。利用者は実行gasと状態gasの合計を支払うが、ブロック容量と次のブロックのベースフィーは、二つの累積値のうち大きい方を基準に計算する。各枠に独立した入札市場ができるわけでも、状態の保存が無料になるわけでもない。長期的な状態の増加を抑えながら、状態作成と実行が単一のカウンターを奪い合う影響を減らすのが狙いである。EIP-8037

この違いは運用ダッシュボードの意味を変える。アプリが徴収・補助する取引手数料と、ネットワークに残る実行余力は、同じ累積値だけでは説明できなくなる。取引レシートの累積gasをそのままブロック混雑度とみなすと、容量を読み違えるおそれがある。提案は、レシート上の累積支払量とブロックのgas指標を明確に区別している。ここから導かれる運用上の判断は、手数料の肩代わりサービスが支出、操作成功率、資源使用量を別々に追うべきだということだ。ブロックごとのgas使用量だけで補助方針を決めるのは不十分になる。

経済的には、ノードが長期間保持するデータの負担を、その作成者へより多く配分する選択である。拡張の持続可能性を改善する一方、デプロイや初回利用に費用を集中させる可能性がある。実行できる仕事量が増えることと、一人ひとりの操作が安くなることは、別々に検証すべき結果だ。

新規ユーザーには別の費用モデルが必要

現行草案では、元の値がゼロのコールドなストレージスロットへ非ゼロ値を書き込む際、状態部分は64×1,530、つまり97,920 gasとなる。アクセスの2,100と書き込みの10,000を加えると、合計は110,020だ。これは特定の一回の書き込みに対するモデル上の費用であり、送金全体の価格でも、すべてのアプリに共通する値上がり倍率でもない。EIP-8037、EIP-8038

例えば、同じトークン送金の入口でも、既存保有者の残高を更新する場合と、初めて受け取る人の残高スロットを作る場合では、異なる状態経路を通り得る。本稿の分析では、成功した取引の平均費用から新規顧客向けの固定補助を決めると、この違いが隠れる。初回の受け取り、初回の承認、初回のウォレットデプロイ、繰り返し操作を分けて再実行し、最も高額な正当な経路を利益で支えられるか確かめるべきである。

新しいスロットを作らなければ十分というわけでもない。EIP-8038はアクセスと書き込みの費用も変更するため、既存状態の更新も高くなり得る。バッチ処理は一部の共通費用を分散できるが、外部アカウント、プロキシ、失敗後の再試行が増える場合、削減効果は呼び出し経路全体で証明する必要がある。取引数が減ったというだけでは結論は出せない。EIP-8038

gasleft()は完全な請求書ではない

EIP-8037のreservoirモデルは、予算の一部を状態作成用に確保する。Solidityのgasleft()として利用されるGASオペコードが返すのはgas_leftだけで、reservoirは含まない。状態作成を取り消すと即時の補充が起きる場合もある。そのため、前後のgasleft()の差を取っても、利用者が負担する総費用を安定して表せず、値が常に減ると仮定することもできない。EIP-8037

これはリレイヤー、手数料負担者、オンチェーン課金コントラクトに直接関わる。差分を支出の証拠として扱う課金処理は、状態費用を漏らしたり、値が増えたときに算術上の問題を起こしたりする可能性がある。より堅実な設計は、利用者が同意した課金ルール、検証可能な実行結果、オフチェーンの照合を分けることだ。上限設定は損失を抑えられるが、誤った計量を正しくすることはできない。公式の監査資料も、gasleft()の差分に基づく課金を確認対象に挙げている。不変条件の一覧

最も高くつく誤りは失敗後に起きるかもしれない

見えにくい問題は、呼び出し先が失敗した後、外側のコントラクトが何を実行できるかである。EIP-8037の補充規則から、検証が必要な仮説的な場面を考える。状態gasの補充やreservoirによって、一部の失敗処理が最後まで実行可能になるかもしれない。例えば、以前は失敗記録を書き込むgasが足りず全体が巻き戻っていた処理が、呼び出し先は実行されていないのにタスクを永久に完了扱いにする場合がある。必要なのは、関数がエラーなしで返ることではなく、再試行する権利が残ることの証明だ。セキュリティ分析

重要なリリース前テストは、業務上の結果から逆算すべきである。子呼び出しのgasを意図的に不足させ、受け取り権、メッセージ状態、nonce、再試行の入口を確認する。失敗を捕捉する必要があるバッチには、明確な復旧経路が必要だ。残りgasや空のrevertデータだけで失敗原因を推測してはいけない。本稿は、失敗を捕捉する全コントラクトに脆弱性があると主張するものではない。リスクは経路全体と状態に依存する。

一時的なロックも別途検討に値する。一つの取引内でしか使わないフラグには、EIP-1153のtransient storageが適するか評価できる。取引終了時に破棄されるため、一部の呼び出し間の一時状態に向く。ただし移行時には、プロキシのコンテキスト、巻き戻し動作、再入攻撃への防御を確認する必要がある。永続的な残高や取引をまたぐ権限を移すべきではない。EIP-1153

受け入れ基準に処理結果を加える

実務的な準備は、テスト対象の仕様バージョンを固定し、新旧アカウント、新旧スロット、十分な状態予算と不足する予算、成功経路と巻き戻し経路を網羅することである。コントラクトだけでなく、ボットやRPC周辺のコンポーネントも確認対象にする。公式資料はオフチェーン部分も影響を受け得ると明記しており、コントラクトの単体テストを再実行するだけでは足りない。公式監査リポジトリ

プロダクト側は、調整可能な予算、手数料肩代わりの上限、異常時の復旧責任を明確にする必要がある。予算の余裕は正当な利用者が行き詰まることを防ぎ、業務状態の復旧可能性は誤りの永久化を防ぐ。Glamsterdamの延期で生まれた時間は、過去のgas実績を、費用と失敗結果の両方を検証できる制約へ置き換える機会である。手数料低下や処理能力向上を約束する前に、これらのテストに合格すべきだ。