著者：@Web3Mario
はじめに：Vitalikは2024年5月13日にEIP-7706を提案し、既存のGasモデルを補完する案を示しました。この提案では、calldataのGas計算を独立させ、Blob Gasと同様のbase fee価格設定メカニズムを導入することで、L2の運用コストをさらに削減することを目指しています。関連するEIP-4844が2022年2月に提案されて以来、かなりの時間が経過しているため、関連資料を調査し、最新のEthereum Gasメカニズムについて総合的に解説します。
現在サポートされているEthereum Gasモデル――EIP-1559およびEIP-4844
初期の設計において、Ethereumはシンプルなオークション方式で取引手数料を定めていました。ユーザーが自らgas priceを設定し、通常、支払った取引手数料はマイナーに分配されるため、マイナーは経済的合理性に基づき、入札額が高い順に取引をブロックに詰め込んでいきます（MEVを無視した場合）。しかし、当時のコア開発者たちはこの仕組みに以下の4つの問題があると考えていました：
l 取引手数料水準の変動性とコンセンサスコストの不一致： ブロックチェーンが活発な状態にあるとき、取引のブロック収容需要が十分にあり、ブロックは簡単に満たされますが、これにより手数料の変動が極めて大きくなります。例えば、平均Gas Priceが10 Gweiのとき、ネットワークが1取引を追加で受け入れる際の限界コストは、平均Gas Priceが1 Gweiのときの10倍となり、これは受け入れがたい状況です。
l ユーザーにとって不要な遅延： 各ブロックにはgaslimitのハード制限があり、過去の取引量の自然な変動も相まって、取引はしばしば数ブロック待つ必要があります。これはネットワーク全体として非効率です。つまり、あるブロックは大きく、次のブロックは小さくするという「緩衝」機構がなく、各ブロックごとの需要差に対応できません。
l 価格設定の非効率性： シンプルなオークション方式では適正価格の発見が難しく、ユーザーにとっては妥当な価格設定が困難になります。結果として、多くの場合でユーザーが過剰な手数料を支払ってしまうことになります。
l ブロック報酬のないブロックチェーンは不安定になる： 採掘によるブロック報酬を廃止し、純粋に手数料モデルに移行すると、取引手数料を奪う「姉妹ブロック」の採掘インセンティブが生まれたり、より強力な利己的採掘攻撃が可能になるなど、安定性に問題が出る可能性があります。
こうした問題に対して、EIP-1559の提案と実施により、Gasモデルは初めて刷新されました。EIP-1559はVitalikらコア開発者によって2019年4月13日に提案され、2021年8月5日のLondonアップグレードで採用されました。この仕組みでは、オークション方式を廃棄し、「Base fee」と「Priority fee」の二重価格モデルを採用しています。Base feeは、親ブロックでのガス消費量と、変動かつ再帰的なガスターゲットとの関係に基づき、数学モデルによって定量的に計算されます。直感的には、前ブロックのガス使用量がターゲットを超えるとbase feeが上昇し、下回ると減少します。これにより需給関係を適切に反映しつつ、適正ガス価格の予測が容易になり、誤操作による天文学的なGas Priceの発生を防ぎます。なぜなら、base feeはシステムが自動決定するものであり、ユーザーが自由に指定するものではないからです。具体的なコードは以下の通りです：
parent_gas_used が parent_gas_target を超える場合、現在のブロックのbase feeは前ブロックのbase feeにオフセット値を加算したものになります。このオフセット値は、parent_base_fee × （前ブロックのガス総使用量とガスターゲットの乖離量）÷（ガスターゲット ÷ 定数）と1のうち大きい方を採用します。逆の場合も同様のロジックです。
また、base feeはマイナーへの報酬ではなく、そのまま焼却されるため、ETHの経済モデルは縮小方向となり、価値の安定に寄与します。一方、priority feeはユーザーがマイナーに支払う「チップ」として自由に価格設定でき、マイナーの並べ替えアルゴリズムの一部を再利用できるようになっています。
時が進んで2021年、Rollup技術の発展が本格化しました。OP RollupやZK Rollupでは、L2のデータを圧縮処理した上で、その証明データをcalldata経由でオンチェーンにアップロードし、データ可用性（Data Availability）を確保したり、直接オンチェーンで検証を行います。このため、これらのRollupソリューションはL2の最終性を維持する上で大きなGasコストに直面しており、そのコストは最終的にユーザーに転嫁されます。そのため、当時の多くのL2プロトコルの使用コストは、期待ほど低くなかったのです。
同時に、Ethereumはブロック空間の競合という課題にも直面していました。各ブロックにはGas Limitがあり、すべての取引のGas消費量の合計がこの値を超えてはいけません。現在のGas Limitが30,000,000であることを考えると、理論的には30,000,000 ÷ 16 = 1,875,000バイトの制限があります（16はEVMがcalldataの1バイトあたりに消費するGas量）。つまり、単一ブロックで扱えるデータ規模は約1.79 MBに制限されています。しかし、L2のオーダーマーが生成するRollup関連データは規模が大きいため、メインチェーンの他のユーザーの取引確認と競合し、1ブロックあたりの取引処理量が減少し、結果としてメインチェーンのTPSに影響を与えました。
この問題を解決するために、コア開発者たちは2022年2月5日にEIP-4844を提案し、2024年第2四半期初頭のDencunアップグレードで実装されました。この提案では、「Blob Transaction」という新しい取引タイプを導入し、従来の取引タイプに加えて「Blob data」という新たなデータ型を追加しました。calldataとは異なり、Blob dataはEVMから直接参照することはできず、そのハッシュ（VersionedHash）のみを参照できます。また、二つの付随設計があります。第一に、通常の取引と比較してBlob TransactionのGCサイクルを短くすることで、ブロックデータの肥大化を防ぎます。第二に、Blob dataには独自のGasメカニズムが備わっており、その挙動はEIP-1559と類似していますが、数学モデルには自然指数関数を採用しています。これにより、取引規模の変動に対する安定性が向上します。自然指数関数の傾きもまた自然指数関数であるため、ネットワークの取引規模がどの状態であっても、取引量が急増すればblob gasのbase feeが強く反応し、取引活性を抑制できます。また重要な特性として、横軸が0のとき関数値が1になる点があります。
base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS * e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION)
ここで、MIN_BASE_FEE_PER_BLOB_GASとBLOB_BASE_FEE_UPDATE_FRACTIONは定数であり、excess_blob_gasは親ブロックにおけるblob gasの総消費量とTARGET_BLOB_GAS_PER_BLOCKとの差で決まります。blob gasの総消費量が目標値を超える（差が正）場合、e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION) > 1となり、base_fee_per_blob_gasが増加します。逆に減少します。
この仕組みにより、Ethereumのコンセンサス機能を利用して、大規模なデータの存在証明や可用性保証を行うケースが低コストで実現でき、ブロックの取引詰め込み能力を圧迫しません。たとえば、Rollupオーダーマーはblob transactionを使ってL2の重要な情報をblob dataに封入し、EVM内でversionedHashを利用して巧妙な設計でオンチェーン検証を実現できます。
補足として、現在のTARGET_BLOB_GAS_PER_BLOCKとMAX_BLOB_GAS_PER_BLOCKの設定により、メインネットでは各ブロックあたり平均3つのblob（0.375 MB）を処理する目標、最大6つのblob（0.75 MB）までという制限があります。これらの初期制限は、ネットワークへの負荷を最小限に抑える目的で設けられており、将来のアップグレードで、ネットワークが大規模ブロックでも安定動作を示すにつれて、引き上げられる予定です。
実行環境のGas消費モデルのさらなる細分化――EIP-7706
現在のEthereum Gasモデルを理解した上で、EIP-7706の目的と実装詳細を見てみましょう。この提案は、Vitalikが2024年5月13日に提出したものです。Blob dataと同様に、特殊な性質を持つ別のデータフィールド——calldata——に対応するGasモデルを分離し、そのコード実装ロジックを最適化しています。
原理的には、calldataのbase feeの計算ロジックはEIP-4844のblob dataのbase feeと同じく、指数関数を用いて、親ブロックでの実際のガス消費量とターゲット値の偏差に基づいて、現在のbase feeの拡大率を計算します。
注目すべき新しいパラメータとして、LIMIT_TARGET_RATIOS=[2,2,4]があります。ここで、LIMIT_TARGET_RATIOS[0]は実行操作系Gasのターゲット比率、LIMIT_TARGET_RATIOS[1]はBlob data系Gasのターゲット比率、LIMIT_TARGET_RATIOS[2]はcalldata系Gasのターゲット比率を表します。このベクトルを使って、親ブロック内の三種類のGasそれぞれのgas target値を計算します。計算式は以下の通りで、gas limitをそれぞれの比率で除算します：
gas_limitsの設定ロジックは以下の通りです：
gas_limits[0]は既存の調整式に従う必要がある
gas_limits[1]はMAX_BLOB_GAS_PER_BLOCKに等しい必要がある
gas_limits[2]はgas_limits[0] // CALLDATA_GAS_LIMIT_RATIOに等しい必要がある
現在、gas_limits[0]は30,000,000、CALLDATA_GAS_LIMIT_RATIOは4に設定されているため、calldata gas targetは30,000,000 // 4 // 4 = 1,875,000となります。現在のcalldata Gas計算では、ゼロでないバイトは16 Gas、ゼロバイトは4 Gas消費するため、仮にcalldata内での非ゼロ・ゼロバイトの割合がそれぞれ50%だとすると、1バイトあたり平均10 Gasが必要です。したがって、現在のcalldata gas targetは約187,500バイトのデータに相当し、これは現在の平均使用量の約2倍です。
この設計の利点は、calldataがgas limitに達する確率を大幅に低下させ、経済モデルを通じてcalldataの使用量を一定範囲に保ちつつ、calldataの悪用を防止できる点にあります。このような設計は、L2の発展を妨げないよう整備されたものであり、blob dataと組み合わせることで、オーダーマーのコストをさらに削減することを目指しています。
@web3_mario
