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

はじめに

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

https://amzn.asia/d/gxvJ0Pw

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

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

概要

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

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

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

重要なのは、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%の削減です。

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

仕様

パラメータ定義

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

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

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

ガス計算式

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

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

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

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

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= 最終ガス消費量"]

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

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ガスのガスリミットを前提とした各方式での最大ペイロードサイズの比較です。

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メソッドが新しいフロアコスト計算式を反映する必要があります。

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

テストケース

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

セキュリティ

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

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

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

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

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

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

引用

最後に

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

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

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

Twitter @cardene777

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

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58