# [EIP7623] calldataのガスコスト増加の仕組みを理解しよう！

> 現在のEthereumでは、トランザクションに含まれるcalldata（コールデータ）のコストが比較的低く設定されており、その結果として最大7.15MBものEL（Execution Layer）ペイロードがブロックに含まれる可能性があります

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

## はじめに

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

https://amzn.asia/d/gxvJ0Pw

今回は、Ethereumトランザクションにおける`calldata`のコスト構造を見直し、ガスコストの引き上げの仕組みを提案している**EIP7623**についてまとめていきます！

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

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

他にも様々なEIPについてまとめています。

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

## 概要

現在のEthereumでは、トランザクションに含まれる`calldata`（コールデータ）のコストが比較的低く設定されており、その結果として最大7.15MBものEL（Execution Layer）ペイロードがブロックに含まれる可能性があります。
一方で、実際の平均的なブロックサイズはおよそ100KBと、かなり小さくなっています。

:::message
EL（Execution Layer）ペイロードとは、Ethereumにおける実行レイヤーが処理するトランザクションや関連するデータの集合のことを指します。

#### ELペイロードとは何か

Ethereumのクライアントは、2つの主要なレイヤーに分かれています。

* **EL（Execution Layer）**
    * 実際にトランザクションを実行し、ステート（ストレージやバランスなど）を更新する役割
* **CL（Consensus Layer）**
    * ブロック提案や検証など、ブロックチェーンの合意形成を担当する役割

#### ELペイロードの構成内容

CLから提案されるブロックには、ELペイロードと呼ばれる以下の情報が含まれています：

* トランザクションのリスト（calldataを含む）
* ガス使用量やガス価格情報
* 状態ルート（state root）
* ログ（event log）
* baseFee、timestamp、blockNumber などのブロックヘッダ情報

#### なぜ「ELペイロードのサイズ」が重要なのか

現在のEthereumでは、トランザクションに含まれる`calldata`が非常に安価です。
そのため、ロールアップなどが大量のデータを`calldata`として投稿することがあります。
これにより、ELペイロードのサイズ（ブロックに含まれるデータ量）が非常に大きくなり、最大7.15MBに達するケースもあります。
平均は100KB程度なので、最大と平均の差が非常に大きく、リソースの浪費やバリデータの負担増につながることが問題視されています。
:::

**EIP7623**では、主にデータの投稿を目的としたトランザクションに対して`calldata`のコストを引き上げることで、最大ブロックサイズとそのばらつきを抑えることを提案しています。
これにより、一般的なユーザーの利用には影響を与えずに、より健全なブロックサイズの維持を目指します。

## 動機

**EIP1559**以降、Ethereumのブロックガスリミット（1ブロックあたりの計算リソースの上限）は変更されていません。
しかし、ロールアップがEthereumに大量のデータを投稿するようになり、ブロックサイズの平均は年々増加しています。

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

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

一方で、`calldata`の価格は**EIP2028**以来変更されておらず、データを大量に投稿する用途に対して安価な状態が続いています。
今後、データ可用性（DA）の手段として`blobs`（**EIP4844**で導入された新たなデータ形式）を活用する方針にあるEthereumにとって、このままでは非効率な状態が続いてしまいます。

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

[\[EIP2028\] Calldataのガスコストを削減する提案について理解しよう！](/articles/8fb1dea76c23122fb7c7)

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

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

そのため**EIP7623**では、トランザクションの中でEVM処理に使われるガス量と`calldata`の比率に基づいて、ある程度の`calldata`最低コスト（floor cost）を設ける方針を取ります。これにより、極端に大きなブロックが生成されるのを防ぎ、将来的な`blobs`の拡充やブロックガスリミットの引き上げに備えた基盤を整えることが目的です。

## 仕様

**EIP7623**では、トランザクションのガス使用量（`tx.gasUsed`）の計算方法を変更することで、`calldata`のコスト構造を見直します。

### パラメータ

* `STANDARD_TOKEN_COST = 4`
  現在の1バイトあたりの`calldata`コスト（**EIP2028**準拠）。

* `TOTAL_COST_FLOOR_PER_TOKEN = 10`
  提案される新しい`calldata`コストの最低基準値。

### トークン数の定義

`tokens_in_calldata` は以下のように定義されます。

```js
tokens_in_calldata = zero_bytes_in_calldata + nonzero_bytes_in_calldata * 4
```

ゼロバイトと非ゼロバイトに異なる重みをつけることで、データ量の大きさを正確に反映します。

### 現在の`tx.gasUsed`の計算式

従来のガス使用量の計算は次のようになります。

```js
tx.gasUsed =
    21000
    + STANDARD_TOKEN_COST * tokens_in_calldata
    + execution_gas_used
    + isContractCreation * (32000 + INITCODE_WORD_COST * words(calldata))
```

* `21000` はトランザクションの基本コスト
* `execution_gas_used` はEVM処理で実際に使用されたガス（ガスリファンド除外）
* コントラクト作成の場合には追加コストが加算されます

### 新しい計算式

**EIP7623**によって`tx.gasUsed`の計算は以下のように変更されます。

```js
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 * tokens_in_calldata
    )
```

つまり、トランザクションの実際のガス使用量と`calldata`量に応じた最小コストのどちらか大きい方が採用されます。

### トランザクションのガスリミットの制限

トランザクションの`gasLimit`は、以下の2つのうち大きい方を下回らないようにする必要があります。

* `21000 + TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata`
* トランザクションの内在的なガスコスト（intrinsic gas cost）

これは、実行内容に関係なく`calldata`に必要な最低限のガスが必ず確保されていなければならないことを意味します。
一部のトランザクションでは実際の`gasUsed`がこの最小値を下回ることもありますが、あくまでリザーブとして必要です。

このような仕組みによって、大量の`calldata`を安価に投稿する手法を制限し、より公平で持続可能なブロック利用を促進します。
特に、ロールアップがブロックサイズに与える影響を抑えることが目的です。

## 補足

現行のEthereumにおいて、最大ELペイロードサイズは約1.79MB（30,000,000ガス ÷ 16ガス/バイト）とされています。
しかし、`calldata`がゼロバイトで埋め尽くされたトランザクションを作ることで、非圧縮状態では最大7.15MBのペイロードを生成することが可能です。

ただし、EthereumノードはP2PレイヤーでSnappy圧縮を用いてブロックをやり取りしており、ゼロバイトが多いデータは圧縮効率が非常に高いため、結果として実際の伝送データサイズは1.79MB未満に収まることが多いです。

:::message
Snappy圧縮とは、Googleが開発した高速かつ軽量なデータ圧縮アルゴリズムです。

Ethereumでは、ノード同士がブロックなどのデータをやり取りする際に、このSnappy圧縮がP2P通信レイヤーで利用されています。

#### Snappy圧縮の特徴

* **非常に高速**
    * 圧縮・解凍の速度が非常に速く、リアルタイム通信や大規模なデータ送信に向いています。
* **中程度の圧縮率**
    * gzipやzlibよりも圧縮率はやや低いですが、そのぶん処理が速いです。
* **非対称圧縮**
    * 圧縮よりも解凍がさらに高速であることが多いです。
* **辞書ベース**
    * 同じようなパターンが繰り返されるデータ（例：ゼロバイトが連続するようなデータ）に対して高い効果を発揮します。

#### Ethereumにおける用途

Ethereumノードは、P2Pネットワークを通じてブロックやトランザクションのデータを交換します。
これらのデータは、サイズが大きいとネットワークの帯域を圧迫するため、効率的な転送が求められます。

そこで、Ethereumでは「DevP2P」プロトコルにおいてSnappy圧縮が採用されています。

* ゼロバイトが多い`calldata`やログ情報などは、Snappyによって大幅に圧縮されます。
* これにより、非圧縮では数MBあるELペイロードも、実際の通信では1〜2MB程度に収まることが多くなります。
:::

しかし、**EIP4844**の導入により、ブロック全体として許容される圧縮後のサイズが約2.54MBに増加しました。
これは、ブロブ（blob）データを含む将来的なユースケースに対応するためです。

**EIP7623**では、EVMでの計算にあまりガスを使わず、主にデータ投稿（DA）を行うトランザクションに対して、`calldata`のガスコストを現行の4/16ガス/バイトから10/40ガス/バイトに引き上げることを提案しています。

この変更により、以下の効果が見込まれます。

* 単一ブロックに含められる最大`calldata`量が約0.72MB（= 30,000,000 ÷ 40）に制限される
* 高圧縮が効かない（非圧縮性が高い）ブロックでも、最大1.26MiB程度に抑制される
* 通常のユーザー（ETH送信やDeFi、NFT取引、ブリッジ等を行う人）は影響を受けない

EVM計算に十分なガスを使っている場合、従来通り`calldata`は4/16ガス/バイトになるため、多くのユースケースでは変更の影響を受けません。

## 互換性

**EIP7623**は、ガスコスト体系を変更する非互換なアップグレードであり、ハードフォーク（ネットワークアップグレード）が必要です。

#### ウォレットへの影響

* ウォレットは `eth_estimateGas` を使用してトランザクションのガス見積もりを行っていますが、**EIP7623**では `TOTAL_COST_FLOOR_PER_TOKEN` に基づいたガス計算が必要となります。
* アップデートされていないウォレットはガスを過小に見積もる可能性があり、トランザクション失敗の原因になります。

#### ノードソフトウェアへの影響

* RPCメソッド（特に `eth_estimateGas`）の実装に、新しいガス計算ロジックを反映させる必要があります。
* `calldata`コストに関する変更に正確に対応していないと、誤ったガス見積もりや実行失敗が発生する可能性があります。

#### ユーザーへの影響

* ウォレットやノードが適切にアップデートされていれば、ユーザーは特別な対応をせずに従来通りの操作を継続できます。
* 開発者やノード運用者は、この変更に確実に対応することで、ユーザー体験を維持できます。

## セキュリティ

**EIP7623**によって最大ブロックサイズが制限されることになりますが、それによるセキュリティ上の懸念は特に報告されていません。

一部では、「`calldata`に依存するトランザクションとEVM処理に依存するトランザクションを1つにまとめれば、ガスコストを抑えられるのではないか」といった意見があるかもしれません。
実際に、こうした異なる特性のトランザクションを1つに束ねる手法（バンドル）には以下のような側面があります。

* このようなバンドルは現行のEthereumでもすでに可能であり、トランザクション1件ごとに必要な21,000ガスを節約する手段として認知されています（**ERC4337**では公式にサポートされています）。
* こうしたバンドルによっても、このEIPが目的とする「ブロックサイズ削減効果」が損なわれることはありません。
* 実際の運用では、バンドルには信頼関係の構築やタイミング調整が必要であるため、それほど一般的ではありません。

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

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

https://zenn.dev/heku/books/88e65212339061

## 引用

Toni Wahrstätter (@nerolation), Vitalik Buterin (@vbuterin), "EIP-7623: Increase calldata cost," Ethereum Improvement Proposals, no. 7623, February 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7623.

## 最後に

今回は「Ethereumトランザクションにおける`calldata`のコスト構造を見直し、ガスコストの引き上げの仕組みを提案している**EIP7623**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下の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