diff --git a/EIPS/eip-8311.md b/EIPS/eip-8311.md new file mode 100644 index 00000000000000..66111b95d1f1da --- /dev/null +++ b/EIPS/eip-8311.md @@ -0,0 +1,130 @@ +--- +eip: 8311 +title: Increase Calldata Floor Cost to 96 +description: Increase the calldata floor cost to 96/96 gas per byte to align it with the ETH-transfer byte-density anchor +author: Maria Silva (@misilva73), Toni Wahrstätter (@nerolation) +discussions-to: https://ethereum-magicians.org/t/eip-8311-increase-calldata-floor-cost-to-96/28860 +status: Draft +type: Standards Track +category: Core +created: 2026-06-20 +requires: 7623, 7976 +--- + +## Abstract + +This EIP proposes an adjustment to calldata pricing by raising the floor cost from 64/64 to 96/96 gas per calldata byte. This brings the worst-case byte density of a pure-calldata block down to the byte density of an ETH-transfer-full block, so that no priced calldata composition is denser, per gas, than this anchor. + +## Motivation + +The 21,000-gas ETH transfer anchors both dimensions of a block. On the execution side, [EIP-8007](./eip-8007.md) has pushed worst-case execution as far as the current ETH transfer cost permits. On the bandwidth side, a block full of transfers is itself a data payload — envelopes, signatures, and the access-list records kept for each transfer — that no pricing instrument can touch without charging more than 21,000 gas. + +A transfer-full block therefore sets an irreducible byte density that we can use to set the price for call data. Accounting for a worst-case transfer envelope (~130 bytes) plus its worst-case marginal block-access-list contribution (~91 bytes), a single transfer adds ~221 bytes for 21,000 gas, or a byte density of approximately `0.0105` bytes/gas. Because this block cannot be repriced, the goal for any data-pricing change is to make it the worst case *by construction*: every composition the protocol prices should carry at most this many bytes per gas. + +[EIP-7976](./eip-7976.md) set the calldata floor at 64 gas per byte. A pure-calldata block at that floor has a byte density of `1/64 ≈ 0.0156` bytes/gas — roughly `1.49×` the transfer block density. The smallest possible lever to close this gap is to raise the floor to: + +``` +F* = ceil(1 / 0.01052) = ceil(95.06) = 96 gas/byte +``` + +At 96 gas per byte, a pure-calldata block has a byte density of `1/96 ≈ 0.0104` bytes/gas, which sits at or just below the transfer-anchor density. Pure calldata is no longer the densest priced block, removing it as the binding bandwidth constraint and allowing the gas limit to scale up to the transfer anchor rather than being held down by data-heavy payloads. + +By increasing the floor cost to 96/96 gas per byte, this proposal aims to: + +- Align the worst-case pure-calldata byte density with the irreducible ETH-transfer anchor density +- Remove pure calldata as the binding bandwidth constraint on the gas limit +- Create additional headroom for block gas limit increases +- Maintain the same exemption for transactions with significant EVM computation +- Have minimal impact on regular users + +## Specification + +| Parameter | Value | +| ---------------------------- | ----- | +| `STANDARD_TOKEN_COST` | `4` | +| `TOTAL_COST_FLOOR_PER_TOKEN` | `24` | + +Let `tokens_in_calldata = zero_bytes_in_calldata + nonzero_bytes_in_calldata * 4`. + +Let `floor_tokens_in_calldata = (zero_bytes_in_calldata + nonzero_bytes_in_calldata) * 4`. + +Equivalently, the floor cost is `96` gas per calldata byte (both zero and non-zero), since `TOTAL_COST_FLOOR_PER_TOKEN * 4 = 96`. The token abstraction is retained only for consistency with [EIP-7623](./eip-7623.md) and [EIP-7976](./eip-7976.md). + +Let `isContractCreation` be a boolean indicating the respective event. + +Let `execution_gas_used` be the gas used for EVM execution with the gas refund subtracted. + +Let `INITCODE_WORD_COST` be 2 as defined in [EIP-3860](./eip-3860.md). + +The formula for determining the gas used per transaction changes from [EIP-7976](./eip-7976.md)'s implementation to: + +```python +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 + ) +) +``` + +Any transaction with a gas limit below `21000 + TOTAL_COST_FLOOR_PER_TOKEN * floor_tokens_in_calldata` or below its intrinsic gas cost (take the maximum of these two calculations) is considered invalid. This limitation exists because transactions must cover the floor price of their calldata without relying on the execution of the transaction. There are valid cases where `gasUsed` will be below this floor price, but the floor price needs to be reserved in the transaction gas limit. + +## Rationale + +With [EIP-7976](./eip-7976.md)'s implementation, data-heavy transactions cost 64/64 gas per zero/non-zero byte, giving a pure-calldata byte density of `1/64 ≈ 0.0156` bytes/gas. This EIP raises the floor to 96/96, giving `1/96 ≈ 0.0104` bytes/gas. + +The target of `96` is not arbitrary. It is the smallest integer floor `F` for which `1/F` does not exceed the ETH-transfer block density of `~0.0105` bytes/gas. Choosing the floor this way ensures the floor does exactly the job it needs to do — bringing pure calldata down to the anchor line — without overcharging beyond what the anchor requires. + +By increasing calldata costs from 64/64 to 96/96 gas per byte for data-heavy transactions, this EIP provides: + +- **Anchor alignment**: A pure-calldata block is brought to (and just under) the irreducible ETH-transfer byte density, so it no longer binds the bandwidth side of the slot before the un-repriceable transfer block does. +- **Maintained user experience**: Regular users engaging in DeFi, token transfers, and other EVM-heavy operations remain unaffected, as the floor only binds data-heavy transactions. +- **Better blob incentivization**: Higher calldata costs further encourage migration to blob usage for data availability. + +The floor cost mechanism ensures that transactions involving significant EVM computation continue to pay the standard 4/16 gas per byte for calldata, preserving the user experience for regular Ethereum operations. + +For an illustration of the absolute effect, a 10 MiB uncompressed execution payload would require ~1.01B gas under 96/96 pricing, compared to ~671M gas under [EIP-7976](./eip-7976.md)'s 64/64 pricing and ~105M gas under [EIP-7623](./eip-7623.md)'s 10/40 pricing. + +## Backwards Compatibility + +This is a backwards incompatible gas repricing that requires a scheduled network upgrade. + +Wallet developers and node operators MUST update gas estimation handling to accommodate the new calldata cost rules. Specifically: + +1. **Wallets**: Wallets using `eth_estimateGas` MUST be updated to ensure that they correctly account for the updated `TOTAL_COST_FLOOR_PER_TOKEN` parameter of 24. Failure to do so could result in underestimating gas, leading to failed transactions. + +2. **Node Software**: RPC methods such as `eth_estimateGas` MUST incorporate the updated formula for gas calculation with the new floor cost values. + +Users can maintain their usual workflows without modification, as wallet and RPC updates will handle these changes. + +## Test Cases + +Testing for this EIP should verify the correct application of the new calldata cost floor of 96/96 gas per byte: + +1. **Data-heavy transactions**: Verify transactions with minimal EVM execution pay the floor cost of 96 gas per calldata byte +2. **EVM-heavy transactions**: Confirm transactions with significant computation continue using standard 4/16 gas per byte +3. **Edge cases**: Test transactions at the boundary where execution gas equals or exceeds the floor cost +4. **Gas estimation**: Validate that `eth_estimateGas` correctly accounts for the new `TOTAL_COST_FLOOR_PER_TOKEN` value +5. **Invalid transactions**: Ensure transactions with insufficient gas limits are properly rejected + +## Security Considerations + +As the maximum possible block size is further reduced compared to [EIP-7976](./eip-7976.md), no additional security concerns are introduced beyond those already addressed in the original proposals. + +The same transaction bundling considerations from [EIP-7623](./eip-7623.md) apply: + +1. Transaction bundling was already possible and remains so +2. Bundling does not compromise the block size reduction objectives +3. Practical limitations (trust, coordination) continue to limit widespread bundling + +The increased floor cost strengthens the incentive structure for appropriate data availability method selection without introducing new attack vectors. + +This EIP addresses only the pure-calldata composition. Mixed compositions that combine cheap standard-rate calldata with byte-dense state access are out of scope and are not brought to the anchor line by a higher calldata floor alone; they are left to a separate proposal. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md).