# [ACP176] AvalancheEVMの動的ガス調整の仕組みを理解しよう！

> ACP176では、AvalancheのC-ChainおよびSubnet-EVMチェーンにおいて、P-Chainのアップグレード提案であるACP103で導入された「動的手数料（dynamic fee）メカニズム」と類似した仕組みを採用すること

- URL: https://cardene.dev/articles/8e9ccb3b0316ca1ad7c8
- 公開日: 2025-09-18
- 更新日: 2025-09-18
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

https://amzn.asia/d/gxvJ0Pw

今回は、AvalancheのEVMチェーン（C-ChainおよびSubnet-EVM）の手数料計算を動的化し、バリデータが需要に応じて目標ガス消費量を調整できるようにすることで、手数料の急騰を防ぎつつ処理能力を柔軟に拡張する仕組みを提案している**ACP176**についてまとめていきます！

:::message
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
:::

https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/176-dynamic-evm-gas-limit-and-price-discovery-updates/README.md

他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

## 概要

**ACP176**では、AvalancheのC-ChainおよびSubnet-EVMチェーンにおいて、P-Chainのアップグレード提案である**ACP103**で導入された「**動的手数料（dynamic fee）メカニズム**」と類似した仕組みを採用することが提案されています。
ただし、そのままではなくブロック提案者（＝バリデータ）自身がガス消費量の目標値を時間単位で動的に調整できるようにする改良を加える点が特徴です。

:::message
**ACP103**については以下の記事を参考にしてください。
:::

[\[ACP103\] Avalanche P-Chainの動的手数料の仕組みを理解しよう！](/articles/347024f238de4641e7b3)

つまり、EVMチェーンが現在固定的に設定している「**ガス消費目標**」を、ネットワークの状態や需要に応じてバリデータが柔軟に変更できる仕組みを取り入れることで、より効率的でスケーラブルなガス手数料調整が可能になるという提案です。

:::message

この提案により、以下の改善が期待できます。

* **大規模ブロックの影響を抑える**
    個別の大きなブロックによってガス価格が不自然に跳ね上がる現象を軽減できます。
* **柔軟なキャパシティ調整**
    バリデータが動的にガス目標を設定できるため、ネットワークの実力に応じて処理能力を拡大でき、将来的なトランザクション負荷の増加にも適応可能です。

結果として、AvalancheのC-ChainおよびSubnet-EVMは、よりスムーズかつ持続的に成長し続けるための基盤を整えることができます。
:::

## 動機

現在のC-Chainには「**静的（固定的）なガス目標**」と「**修正されたEIP1559ベースの手数料調整メカニズム**」が導入されています。

:::message
**EIP1559**については以下の記事を参考にしてください。
:::

[\[EIP1559\] Ethereumの新たなガス価格設定メカニズムを理解しよう！](/articles/ce77124940010280717b)

具体的には以下のようになっています。

* ガス目標は**1,500万gas**に設定されています。
* これは10秒間のローリングウィンドウ（rolling window）ごとに適用され、過去10秒間のガス消費量に基づいて次のブロックのベース手数料が調整されます。

この仕組みには以下の2つの問題点があります。

#### 大きなブロックによる手数料スパイク

ウィンドウ方式により、もしあるブロックがガス上限いっぱいまで使われると、その後に続くブロックが小さいものであっても、同じウィンドウ内に含まれるためガス価格が上がり続けてしまうという問題があります。
その結果、ガス価格が一時的に過剰に上昇し、利用者にとって予期せぬ高コストが発生してしまいます。

#### 静的なガス目標の硬直性

現在のガス目標（例: 1,500万gas）はネットワークアップグレードによってしか変更できません。
つまり、ノードのハードウェア性能向上やソフトウェアの最適化が進んでも、それに合わせて柔軟にガス目標を調整することができず、ネットワーク全体のキャパシティ調整が遅れるという欠点があります。

## 仕様

:::message
### C-Chainにおける動的手数料メカニズムの仕組み

AvalancheのC-Chainでは、これまで固定されたガス目標（毎秒1,500,000gas）と、**EIP1559**を改良した手数料調整方式が使われてきました。
しかし、この方式は大きなブロックによって手数料が急上昇する問題や、ガス目標の変更にネットワークアップグレードが必要になる問題がありました。
そこで導入が提案されているのが、P-Chainの**ACP103**を基盤とした動的手数料メカニズムです。

**ACP176**では、1秒あたりの目標ガス消費量（$T$）を基準にガス価格が決まります。
ガスの利用量が目標を超えれば価格は上昇し、下回れば価格は下がるというシンプルな構造です。
ただし、C-Chain版では$T$をブロックごとにバリデータが調整可能とした点が大きな特徴です。

#### $q$と$T$の関係

目標ガス消費量$T$は、以下の式で定義されます。

$$
T = P \cdot e^{\frac{q}{D}}
$$

ここで、$P$は最低限の目標値、$q$はブロックごとに増減できる整数、$D$は変化を緩やかにするための定数です。
バリデータは自分の望む$T$を設定し、それに対応する$q$を計算します。
各ブロックでは、現在の$q$を少しずつ望む方向に近づけることができます。
これにより、バリデータ全体の多数決のような力学で、ネットワークの実効的な$T$が決まっていく仕組みになっています。

#### 他のパラメータの連動

$T$が決まると、以下のパラメータも連動して調整されます。

* $R = 2 \cdot T$（1秒あたりの回復量）
* $C = 10 \cdot T$（最大蓄積容量）
* $K = 87 \cdot T$（価格変化の感度係数）

この設計により、ガス価格の上昇と下降のスピードが釣り合い、また最大容量や価格の変化速度も$T$に応じて自動的にスケーリングされます。

#### ガス価格の安定性

ガス価格は内部変数$x$（過剰ガス消費量）を使って計算されます。
$K$が変わっても価格が急に跳ねないように、$x$も比例して補正されます。
さらに、$q$やそれに付随する各パラメータの更新はブロック実行後に反映されるため、そのブロックに含まれるトランザクションの価格計算には影響せず次のブロックから有効になります。

#### 全体の効果

この仕組みによって、C-Chainは以下のような特徴を得ます。

* **大きなブロックの影響を緩和**し、手数料が急激に跳ね上がらない
* **ネットワークの処理能力に応じて柔軟にスケーリング**できる
* **バリデータの多数意見で最適な水準に収束**する

Ethereumの**EIP4844**に導入されたblobガス市場や、P-Chainでの実運用を通じて、この方式が需要に応じて価格を安定的に調整し、DoS攻撃を防ぐ方向に働くことは既に検証されています。
:::

### ガス価格の決定

**ACP176**で用いるブロックのベース手数料（base fee）の決め方は、P-Chainで**ACP103**が採用したガス価格決定メカニズムと同じ考え方です。
ブロック$b$のガス価格は、以下のパラメータに基づいて計算します。

|       |                       |
| ----- | --------------------- |
| $T$ | 1秒あたりの目標ガス消費量（target） |
| $M$ | 最小ガス価格（下限）            |
| $K$ | ガス価格の更新係数（感度を決める定数）   |
| $C$ | 最大ガス容量（ためておける上限）      |
| $R$ | 1秒あたりに追加されるガス容量（回復速度） |

ここでのポイントは、ネットワークに「**容量**」、「**回復**」、「**上限**」をもたせ、その超過度合いに応じてガス価格を上下させるということです。
$T$は「**どのくらいのペースでガスを使うのが理想か**」を表す目標、$R$は1秒あたりの容量の回復量、$C$は貯めておける容量の上限、$K$はガス価格がどれくらいの速さで反応するかの係数、$M$は下限です。
また、過剰ガス消費量を表す内部状態$x$（excess）が使われ、ブロックで消費したガス$G$や各定数に応じて更新されます（$x$は後述の式で調整します）。

### $T$を動的にする

上記のガス価格決定は、1秒あたりの目標ガス消費量 $T$ を前提にしています。
ここでは、$T$をブロックごとに動的に調整できるようにします。

まず、非負整数$q$を用意し、この仕組みの有効化時に$q=0$で初期化します。
目標ガス消費量は以下の式で表します。

$$
T = P \cdot e^{\frac{q}{D}}
$$

ここで$P$はネットワーク全体で許される最小の目標ガス消費率、$D$は変化速度をなだらかにする定数です（$e$は自然対数の底、$e\approx2.71828$）。

ブロック$b$のトランザクション実行が終わった後、$q$は1ブロックあたり最大で$Q$だけ増減できます。
必ず$\lvert \Delta q \rvert \le Q$を満たさなければならず、これに違反するブロックは無効です。
どれだけ$q$を変えるかは、ブロックビルダー（=バリデータ）が指定します。

各ノード（バリデータ）は、自分の望む$T$ を設定ファイルに指定できます。
そのときの望ましい$q$は次式で求めます。

$$
q_{\text{desired}} = D \cdot \ln\!\left(\frac{T_{\text{desired}}}{P}\right)
$$

$\ln$は自然対数です。
$q_{\text{desired}}$はローカルでのみ使う値で、ノードごとに異なっても安全です。
実装では$\ln!\left(\frac{T_{\text{desired}}}{P}\right)$を近似して四捨五入（整数化）して問題ないです。

ブロックを組み立てる時、現在のネットワークの$q$（`q_current`）から、次に採用したい$q$を以下の関数で計算できます（1ブロックで変えられる幅は`max_change=Q`まで）。

```python
# 指定ブロックにおける次のqを計算
def calc_next_q(q_current: int, q_desired: int, max_change: int) -> int:
    if q_desired > q_current:
        return q_current + min(q_desired - q_current, max_change)
    else:
        return q_current - min(q_current - q_desired, max_change)
```

$q$はブロック内のトランザクション実行が終わった後に更新されます。
そのため$T$も常に以下の式で更新されます。
$$
T = P \cdot e^{\frac{q}{D}}
$$

$T$が変わると、1秒あたりの容量追加量$R$も以下のように更新します。

$$
R = 2 \cdot T
$$

これにより、ガス価格が上がる速さと下がる速さが同程度になるように保ちます。

さらに、最大容量$C$も$T$に比例させて以下のようにします。

$$
C = 10 \cdot T
$$

これは、ブロックがしばらく受け入れられない状態が5秒続くと、ストックできる容量が上限に達する（$R=2T$なので$C/R=10T/2T=5$秒）という意味です。

また、価格の反応係数$K$も$T$に比例させて以下のようにします。

$$
K = 87 \cdot T
$$

これにより、最大利用（=持続的に$2T$ガス/秒）のときに、約60.3秒で手数料が2倍になる性質を保ちます（比較として、**EIP1559**は約70秒、現行C-Chainはブロック間隔に依存しつつ約50秒程度で倍化）。

$K$を変えても、その瞬間にガス価格自体が不連続に跳ねないよう、内部ステートである過剰ガス消費$x$も比例調整します。
**ACP103**では$x$を$x+G$と更新しますが、本メカニズムでは次ブロック$n+1$の$K$に合わせて以下の式で更新します。

$$
x_{n+1} = (x + G) \cdot \frac{K_{n+1}}{K_{n}}
$$

重要な注意点として、$q$（それに伴って$T, R, C, K, x$）の更新はブロック$b$の実行後に行われ、影響は次のブロック$b+1$の価格決定から反映されます。
したがって、ブロック$b$に入っているトランザクションの価格計算には影響しません。

さらに、この「**ブロックビルダーが$T$を調整できる**」設計は、多数決で釣り合う点に収束しやすい性質があります。
バリデータはステーク重み（持分）に比例してブロックを多く提案するため、「**上げたい**」重みと「**下げたい**」重みが50%ずつになる水準に、実効的な$T$が時間とともに近づくことが期待されます。

最後に、**ACP103**の性質として、ある時間幅$\Delta t$で消費できる最大ガスは$r + R \cdot \Delta t$（$r$は直前ブロック終了時点の残容量）で、全$\Delta t$にわたる上限は$C + R \cdot \Delta t$です。
これを1ブロック$b$に着目して表すと、次のブロックガス上限になります。

$$
gasLimit_{b} = \min(r + R \cdot \Delta t,\; C)
$$

### 設定パラメータ

本メカニズムは、$T,M,K,C,R$に依存します。
$T$は初期値から$D$と$P$に基づいて動的に調整され、$R$と$C$は$T$から導出されます。C-Chainの有効化時のパラメータは次のとおりです。

| パラメータ | 説明 | C-Chainでの設定値 |
| ----- | ------------------- | -------------------------- |
| $P$ | 1秒あたりの最小目標ガス消費量     | $1{,}000{,}000$ |
| $D$ | 目標ガス消費率の更新を制御する定数   | $2^{25}$  |
| $Q$ | 目標ガス消費率の更新幅を制限する上限値 | $2^{15}$  |
| $M$ | 最小ガス価格              | $1 \times 10^{-18}$ AVAX |
| $K$ | 初期ガス価格更新係数          | $87{,}000{,}000$  |

$P$はC-Chainで安全に最低限といえる目標値として選定されています（現在のC-Chainの目標は**毎秒1,500,000gas**）。
ネットワークの過半のステーク重みが$P$を望む場合に限って、実効的な目標は$P$にとどまります。

$D$と$Q$は、1ブロックで$T$を現在値の約$1/1024$刻みで調整できるように設計されています。
これはEthereumが実行レイヤのガスリミット変更幅に用いている境界（bound divisor）に合わせたもので、さらに$2^{15}$倍のスケールをかけてより細かい粒度で調整できるようにしています。

$M$はネイティブ資産の最小単位にそろえてあり、常に価格発見が起きやすいようにしています。
この価格発見の仕組みは、すでにP-Chainで実運用されています。
また、Ethereumの**EIP4844**（“blob”という大容量データに専用の手数料市場を導入した改定）でも同種の手法が用いられています。
これらの実運用の結果から、需要が高まった際に手数料が適切に上昇し、過負荷（DoS）を抑制する方向に働くことが確認されています。

:::message
**EIP4844**については以下の記事を参考にしてください。
:::

[\[EIP4844\] Shard Blob Transactionsの仕組みについて理解しよう！](/articles/4966cf7f6691d7220367)

$K$は、最大利用（$2T$gas/秒が持続）の下で、約60.3秒で手数料が2倍になるように選んでいます（参考: **EIP1559**は約70秒、現行C-Chainは条件により約50秒）。

なお、瞬間的な価格倍率の上限は以下の式で表せます。

$$
e^{\frac{C}{K}} = e^{\frac{10 \cdot T}{87 \cdot T}} = e^{\frac{10}{87}} \approx 1.12
$$

$C/K$が一定（$T$に比例）になる設計なので、$T$を変えても瞬間的に跳ねる倍率は一定に保たれます。

### $T_{desired}$の選び方

本メカニズムでは、各バリデータが設定で$T_{desired}$（望む目標ガス消費率）を指定できます。
この指定は、時間とともにネットワーク全体の実効的な$T$に影響します。$T$が
高いほど、ネットワークが利用できるリソース（ストレージ/計算など）が増え、スループットも上がる一方で、その水準を安定運用できるノード資源が必要になります。

したがって、各バリデータは、①その$T$を支えるために必要な自ノードの資源要件、②TPS向上によるネットワークの便益、③その水準に達した場合のネットワーク安定性を総合的に考慮して$T_{desired}$を選ぶべきです。
クライアント実装はデフォルトを用意できますが、最終的な値は各バリデータが独自判断で設定できます。

## 互換性

**ACP176**の変更は必須のNetworkUpgrade（全ネットワーク一斉の有効化）を経て初めて効力を持ちます。
有効化までの間は、C-Chainにおける現行のガスリミットと価格発見メカニズムがそのまま使われます。
有効化後の開発者向けツールへの影響は小さく、特にトランザクション形式は変わらないため、ウォレットにも影響は及びません。

一方で、有効化後は$C$（最大ガス容量）が動的に調整されるため、単一ブロックで消費可能な最大ガス量、つまり単一トランザクションが消費可能な最大ガス量も動的に変化します。
結果として、ある時点では無効と判定されたトランザクションが別の時点では有効になり得る（逆に有効だったものが無効になる場合もある）という挙動が生じます。
これは直感に反するかもしれませんが、最小ガス消費率（ネットワークが最低限確保する処理ペース）が十分高く設定されていれば、実務上の影響は大きくなりにくいと考えられます。
この挙動は**Ethereum Mainnetでも現在確認されているものです。

:::message
有効化後、手数料が上昇局面にあるときの大型トランザクションの取り込み遅延について懸念が挙がりました。
これへの対策として、ブロックプロデューサは十分な容量があるときにのみブロックを生成すべきとされます。
有効化前の単一トランザクション最大サイズは1500万gasでした。
そこでの推奨ヒューリスティックは、容量が$\min(8\cdot T,;1500\text{万})$以上になるまでブロック生成を控えることです。
記載時点では、これにより最大1280万gasのトランザクションがブロックスペースに入札できる状態を確保できます。
:::

## 参考実装

本ACPは**Coreth**に実装され、**Fortunaアップグレードフラグ**の背後にマージ済みです。完全な実装は次のリリースにまとめられています。

* coreth@`v0.14.1-acp-176.1`（GitHubReleases参照）

この形態は、**コードとしては取り込まれているが、プロトコルの有効化フラグで制御する**という意味であり、**ネットワークの有効化時期に合わせて挙動が切り替わる**運用を想定しています。

## セキュリティ上の考慮

**ACP176**は、AvalancheEVMチェーンにおけるガス価格決定メカニズムを変更します。
ガス価格は需要変動に応じて動的に適応し、最終的に価格発見（需要と供給の釣り合う水準に調整される仕組み）を行います。
もし期待どおりに反応しなければ、価格が低すぎてDoS攻撃に晒される、あるいは低負荷時に利用者へ過大な料金を課すといったリスクが生じ得ます。
このメカニズムはP-Chainで既に実戦投入されていますが、C-ChainでのMainnet有効化に先立ち、改めて十分なテストを行うべきです。

さらに**ACP176**は、バリデータがC-Chainのガスリミットを変更できる仕組みも導入します。
もしガスリミットが過度に高く設定されると、バリデータノードがブロック処理に追随できない可能性があります。
これへの緩和策として、最大ガスリミットの上限を導入する選択肢はありますが、その場合はその上限を超えてスケールするには再度NetworkUpgradeが必要になります。
設計・運用では、過負荷での処理追随性と将来の拡張余地のバランスを十分に検討する必要があります。

## 最後に

今回は「AvalancheのEVMチェーン（C-ChainおよびSubnet-EVM）の手数料計算を動的化し、バリデータが需要に応じて目標ガス消費量を調整できるようにすることで、手数料の急騰を防ぎつつ処理能力を柔軟に拡張する仕組みを提案している**ACP176**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

[Twitter @cardene777](https://twitter.com/cardene777)

他の媒体でも情報発信しているのでぜひ他も見ていってください！

https://chaldene.net/

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4