# [EIP7976] calldataのフロアコストを引き上げてブロックサイズを抑制する仕組みを理解しよう！

> EIP7976とは、calldataのフロアコスト（最低ガスコスト）を従来の10/40ガス/バイトから64/64ガス/バイトに引き上げる提案です。

- URL: https://cardene.dev/articles/c08fc5c10faae8c3a7f0
- 公開日: 2026-03-23
- 更新日: 2026-03-23
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

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

https://amzn.asia/d/gxvJ0Pw

今回は、calldataのフロアコスト（最低ガスコスト）を引き上げてデータ量の多いトランザクションのブロックサイズへの影響を抑え、ガスリミット引き上げの余地を広げる提案をしている**EIP7976**についてまとめていきます！

:::message
以下にまとめられているものを解説しながらまとめていきます。
:::

https://eips.ethereum.org/EIPS/eip-7976

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

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

## 概要

**EIP7976**とは、calldataのフロアコスト（最低ガスコスト）を従来の10/40ガス/バイトから64/64ガス/バイトに引き上げる提案です。
この変更により、データ量の多いトランザクションが占有できるブロックサイズの上限が約37%削減されます。

:::message
**calldata**

calldataとは、トランザクションに含まれるデータ領域のことです。
コントラクトの関数を呼び出す時に引数を渡したり、L2のロールアップがL1にデータを投稿したりする時に使われます。
:::

この提案は**EIP7623**を前提としており、**EIP7623**で導入された「フロアコスト」の仕組みをさらに強化するものです。

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

[\[ERC4337\] プロトコルの変更をせずにAAを実装する仕組みを理解しよう！](/articles/8c97ca7c93c4557ebfc2)

重要なのは、DeFi操作やトークンTransferなどEVM計算が中心のトランザクションには影響がないという点です。
影響を受けるのは、大量のデータをcalldataに詰め込むタイプのトランザクション（主にL2のデータ投稿）のみです。
2024年9月〜2025年9月の実績データでは、全トランザクションのわずか1.5%にしか影響しません。

## 動機

#### ブロックサイズの肥大化問題

Ethereumのブロックには「ガスリミット」という上限があり、現在は約4,500万ガス（45Mガス）です。
ブロックに含まれるトランザクションの合計ガス消費がこの上限を超えることはできません。

ここで問題になるのがcalldataのコストです。
calldataのガスコストが低いと、1つのトランザクションに大量のデータを詰め込むことができてしまい、結果としてブロック全体のデータサイズが膨れ上がります。
ブロックサイズが大きくなると、ネットワーク上のノードがブロックをダウンロード・検証するのに時間がかかり、チェーン全体のパフォーマンスに悪影響を及ぼします。

#### **EIP7623**の成果と残された課題

**EIP7623**は「フロアコスト」という仕組みを導入することで、この問題に取り組みました。
フロアコストとは、EVM計算をほとんど行わないデータ中心のトランザクションに対して適用される最低ガスコストのことです。

**EIP7623**ではフロアコストを10/40ガス/バイト（ゼロバイトに10ガス、非ゼロバイトに40ガス）に設定し、最大ブロックサイズを約1.07MB（`45,000,000 ÷ 40`）に抑えました。

しかし、Ethereumのガスリミットを将来さらに引き上げたいという要望があります。
ガスリミットを引き上げるとより多くのトランザクションを処理できますが、フロアコストが現状のままではブロックサイズも比例して大きくなってしまいます。
ガスリミット引き上げの余地を確保するためには、フロアコストをさらに引き上げてブロックサイズの上限を下げる必要があるのです。

#### この提案による解決策

**EIP7976**はフロアコストを64/64ガス/バイトに引き上げます。
これにより、データ中心のトランザクションが占有できる最大ペイロードサイズは約0.67MB（`45,000,000 ÷ 64`）まで下がります。
**EIP7623**の約1.07MBから約37%の削減です。

| 方式 | ゼロバイト | 非ゼロバイト | 最大ペイロード |
|------|----------|------------|-------------|
| 従来（**EIP7623**以前） | 4ガス | 16ガス | 約2.81MB |
| **EIP7623** | 10ガス | 40ガス | 約1.07MB |
| **EIP7976** | 64ガス | 64ガス | 約0.67MB |

さらに、calldataのコストが上がることでL2がデータ投稿先としてcalldataではなくblob（**EIP4844**で導入された専用のデータ領域）を選ぶインセンティブが強まり、適切なデータ可用性手段への移行が促進されます。

## 仕様

#### パラメータ定義

**EIP7976**では以下の2つのパラメータが定義されています。

| パラメータ | 値 | 説明 |
|----------|-----|------|
| `STANDARD_TOKEN_COST` | 4 | 標準的なcalldataトークンのコスト。EVM計算が多いトランザクションに適用される。 |
| `TOTAL_COST_FLOOR_PER_TOKEN` | 16 | 1トークンあたりのフロアガスコスト。データ中心のトランザクションに適用され、`floor_tokens_in_calldata`と掛け合わせて最低ガスを算出する。 |

calldataのバイト数は「トークン」という単位に変換されて計算されます。
変換ルールは以下の通りです。

| 変数 | 計算式 | 説明 |
|------|--------|------|
| `tokens_in_calldata` | `ゼロバイト数 + 非ゼロバイト数 × 4` | 標準コスト計算用のトークン数。非ゼロバイトは4倍の重みを持つ。 |
| `floor_tokens_in_calldata` | `(ゼロバイト数 + 非ゼロバイト数) × 4` | フロアコスト計算用のトークン数。すべてのバイトが均等に4倍。 |

標準コスト計算（`tokens_in_calldata`）ではゼロバイトの重みが軽く（1倍）、非ゼロバイトの重みが重い（4倍）のに対し、フロアコスト計算（`floor_tokens_in_calldata`）ではゼロバイトも非ゼロバイトも均等に4倍として扱います。
つまり、フロアコスト計算ではゼロバイトをたくさん含むトランザクションでもコストが高くなるように設計されています。

#### ガス計算式

トランザクションのガス消費量は以下の疑似コード（Python記法）で決定されます。

```javascript
tx.gasUsed = (
    21000
    +
    max(
        STANDARD_TOKEN_COST * tokens_in_calldata
        + execution_gas_used
        + isContractCreation * (32000 + INITCODE_WORD_COST * words(calldata)),
        TOTAL_COST_FLOOR_PER_TOKEN * floor_tokens_in_calldata
    )
)
```

式中の各変数の意味は以下の通りです。

- `execution_gas_used`
    EVM実行で消費されたガスからガスリファンドを差し引いた値です。
- `isContractCreation`
    トランザクションがコントラクト作成かどうかを示すフラグ（true=1, false=0）です。
- `INITCODE_WORD_COST`
    **EIP3860**で定義されたコントラクト初期化コードの1ワードあたりのコスト（2ガス）です。

この式のポイントは`max()`関数です。
2つの値を比較して大きい方が採用されます。
EVM計算が多いトランザクションは引き続き標準コスト（ゼロバイト4ガス、非ゼロバイト16ガス）が適用され、データ中心のトランザクションのみフロアコスト（全バイト64ガス）が適用されます。

```mermaid
flowchart TD
    A[トランザクション実行] --> B{ガスコスト計算}
    B --> C["標準コスト\n= STANDARD_TOKEN_COST × tokens\n+ EVM実行ガス\n+ コントラクト作成コスト"]
    B --> D["フロアコスト\n= TOTAL_COST_FLOOR_PER_TOKEN\n× floor_tokens"]
    C --> E{max で比較}
    D --> E
    E --> F["大きい方 + 21000\n= 最終ガス消費量"]
```

以下の図は、フロアコスト判定の仕組みをフロー図で示したものです。

![フロアコスト判定の仕組み](/images/c08fc5c10faae8c3a7f0-fig2-floor-cost-flow.webp)

EVM計算が多いトランザクション（DeFi・Transfer等）では標準コストの方が大きくなるため影響を受けません。
一方、データ中心のトランザクション（L2のデータ投稿等）ではフロアコストが適用され、コストが増加します。

##### ガス計算の動作パターン

具体例で考えてみます。
100バイトの非ゼロcalldataを含むトランザクションの場合を見てみます。

- `tokens_in_calldata` = 0 + 100 × 4 = 400
- `floor_tokens_in_calldata` = (0 + 100) × 4 = 400

##### EVM計算が多いトランザクション

EVM実行に50,000ガスを消費するDeFi操作の場合、標準コストは `4 × 400 + 50,000 = 51,600` です。
フロアコストは `16 × 400 = 6,400` です。
`max(51,600, 6,400) = 51,600` となり、標準コストが適用されます。
つまり通常のDeFiトランザクションでは、この変更の影響を受けません。

##### データ中心のトランザクション

EVM実行ガスがほぼ0（例えばL2がcalldataにデータを投稿するだけ）の場合、標準コストは `4 × 400 + 0 = 1,600` です。
フロアコストは `16 × 400 = 6,400` です。
`max(1,600, 6,400) = 6,400` となり、フロアコストが適用されます。
データ中心のトランザクションは従来の4倍のコストを支払うことになります。

#### トランザクション無効化ルール

トランザクションの`gasLimit`（ガスの上限）が `21000 + TOTAL_COST_FLOOR_PER_TOKEN × floor_tokens_in_calldata` を下回る場合、またはトランザクション固有のガスコスト（intrinsic gas cost）を下回る場合、そのトランザクションは無効として拒否されます。
2つの計算結果のうち大きい方が基準となります。
この制限は、トランザクションが実行前の段階でcalldataのフロアコストを確実にカバーできることを保証するためのものです。

EVM実行の結果として`gasUsed`がフロアコストを下回るケースは発生し得ますが、`gasLimit`の段階ではフロアコスト分のガスが確保されている必要があります。

## 補足

#### コスト変遷の比較

calldataのコスト設定は段階的に引き上げられてきました。
以下の図とテーブルは、45Mガスのガスリミットを前提とした各方式での最大ペイロードサイズの比較です。

![calldataコスト比較と最大ペイロード](/images/c08fc5c10faae8c3a7f0-fig1-cost-comparison.webp)

| 方式 | 非ゼロバイトコスト | 最大ペイロード | 10MiB送信に必要なガス |
|------|-----------------|--------------|---------------------|
| 従来 | 16ガス/バイト | 約2.81MB | 約168Mガス |
| **EIP7623** | 40ガス/バイト（フロア） | 約1.07MB | 約420Mガス |
| **EIP7976** | 64ガス/バイト（フロア） | 約0.67MB | 約671Mガス |

10MiBの非圧縮データ（約1,048万バイト）を送信するのに必要なガスが、**EIP7623**の10/40方式では約420Mガス（`10,485,760 × 40`）ですが、**EIP7976**の64/64方式では約671Mガス（`10,485,760 × 64`）になります。
これは45Mガスのガスリミットを大幅に超えるため、実質的にそのような大量データの送信はブロック単位では不可能になります。
この設計により、将来ガスリミットを引き上げてもブロックサイズの肥大化を抑えられる余地が生まれます。

#### なぜ64/64なのか

**EIP7976**がフロアコストを64/64に設定した背景には、ブロックサイズ削減効果とユーザーへの影響のバランスがあります。

ブロックサイズ削減の観点では、最大ペイロードが**EIP7623**の約1.07MBから約0.67MBに下がることで、ガスリミットを将来引き上げてもブロックサイズが適正範囲に収まります。

ユーザー影響の観点では、2024年9月〜2025年9月のブロック20644414〜23272414の実績データを分析した結果、影響を受けるトランザクションは全体のわずか1.5%です。
DeFi操作やトークンTransfer、NFT操作など、EVM計算が中心のトランザクションはフロアコストの影響を受けません。

#### blobへの移行促進

**EIP4844**（Proto-Danksharding）で導入されたblob（Binary Large Object）は、L2のデータ投稿に最適化された専用のデータ領域です。
calldataと比べてコストが安く、ブロックサイズにも影響を与えません。

calldataのフロアコストが引き上がることで、L2にとってはcalldataにデータを投稿するコストがさらに高くなります。
これはblobの利用を経済的に有利にし、データ可用性の手段としてblobへの移行を後押しします。

## 互換性

この提案はガスの再価格設定（リプライシング）を伴うため、ハードフォーク（計画的なネットワークアップグレード）が必要です。
既存の仕様と互換性がない変更であり、以下の対応が求められます。

#### ウォレットの更新

`eth_estimateGas`を使用しているウォレットは、新しい`TOTAL_COST_FLOOR_PER_TOKEN`パラメータ（16）に対応した更新が必要です。
更新しないとガスの見積もりが実際より低くなり、トランザクションが失敗する可能性があります。

#### ノードソフトウェアの更新

`eth_estimateGas`などのRPCメソッドが新しいフロアコスト計算式を反映する必要があります。

ウォレットとノードが適切に更新されれば、ユーザーは従来通りのワークフローを維持できます。

#### テストケース

この提案の実装が正しく動作するかを検証するための観点は以下の通りです。

| テスト観点 | 検証内容 |
|-----------|---------|
| データ中心のトランザクション | EVM実行が少ないトランザクションにフロアコスト（64ガス/バイト）が適用されるか。 |
| EVM計算中心のトランザクション | 計算量が多いトランザクションに標準コスト（4/16ガス/バイト）が引き続き適用されるか。 |
| 境界ケース | EVM実行ガスがフロアコストとちょうど等しい、または超えるトランザクションの扱い。 |
| ガス見積もり | `eth_estimateGas`が新しい`TOTAL_COST_FLOOR_PER_TOKEN`値を正しく反映するか。 |
| 無効トランザクション | `gasLimit`が不足するトランザクションが適切に拒否されるか。 |

## セキュリティ

#### ブロックサイズ削減によるセキュリティ強化

**EIP7623**と比較して最大ブロックサイズがさらに削減されるため、**EIP7623**で対処済みのセキュリティ上の懸念を超える新たなリスクは導入されません。
ブロックサイズの縮小は、ノードの処理負荷を軽減し、ネットワーク全体の安定性を向上させます。

#### トランザクションバンドリングの考慮

**EIP7623**と同様に、複数のトランザクションを1つにまとめる「バンドリング」は引き続き可能です。
しかし以下の理由から、バンドリングがブロックサイズ削減の効果を損なうことはありません。

- バンドリングは**EIP7623**以前から可能であり、新しいリスクではない
- 実際にバンドリングを行うには信頼関係やコーディネーションが必要で、大規模な悪用は困難

フロアコストの引き上げにより、適切なデータ可用性手段の選択を促すインセンティブ構造が強化されます。

## 引用

https://eips.ethereum.org/EIPS/eip-7976

https://ethereum-magicians.org/t/eip-7976-further-increase-calldata-cost/24597

https://eips.ethereum.org/EIPS/eip-7623

## 最後に

今回は「**EIP7976**によるcalldataフロアコストの引き上げとブロックサイズ抑制」についてまとめてきました。
いかがだったでしょうか？

Ethereumのスケーリングにおいて、ガスリミットの引き上げとブロックサイズの抑制は常にトレードオフの関係にあります。
**EIP7976**はフロアコストを64/64に引き上げることで、ユーザーへの影響を最小限に抑えつつ、将来のガスリミット引き上げに備える設計になっています。

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

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

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

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

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