EIP-7976: Further increase calldata cost

EIPs
1

Discussion topic for EIP-7976

Update Log

External Reviews

None as of 1025-06-19

Outstanding Issues

None as of 1025-06-19

2

The text introducing the code block in EIP-7976 is:

The formula for determining the gas used per transaction changes from EIP-7623’s implementation to:

But as far as I can tell, the formula is exactly the same as EIP-7623:

EIP-7623EIP-7976
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
    )
)

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
    )
)

If the formula remains the same, and it’s just the constants that change, perhaps consider removing the code block entirely, since it’s unchanged.

3

Yeah, you’re right. I will simplify it in the EIP, in case this PR won’t be merged:

It changes the calldata pricing at the floor from 15/60 to 64/64 and introduces a new variable floor_tokens_in_calldata, and then, having the entire EIP-7623 formula mentioned might make sense.

My feeling atm is that this will be merged.

4

I took a look at protocols that would be affected by this change. I manually tagged every contract that would see more than a 1 million gas increase over 4,000 blocks - this categorized about 92% of legitimate usage. Excluding scams, here’s a chart of the affected contracts:

image
image1056×1288 167 KB

Opensea (leading NFT marketplace) and Chainlink (leading oracle provider) are the hardest hit.

46% of Opensea transactions increase in cost, with 35% of their transactions increasing over 10,000 gas. This works out to about 278 million more gas over the 4,000 block period.

26% of Chainlink oracle updates increase by 380,000 gas or more.

Both of these contracts share triple combination of:

  1. Action authorization signatures in calldata
  2. Zero heavy calldata (>75% zeros)
  3. Extremely optimized code using very little gas otherwise

It’s ironic that the legendary amount of work OpenSea put into writing and securing a giant codebase in assembly for the ultimate in gas efficiency gets punished in this way.

I lumped bridges and rollups together, though those could have been split. Bridges have similar profiles to opensea - authorization heavy work, with signatures in calldata, many zeros for parameters that are not used, and otherwise efficient code that probably just cheaply sends a token or ETH at the end of the work.

Many hybrid dexes also have a similar cost shape, where offers are made off chain with signatures (calldata), have many zeros, and then the funds move is just small gas on chain.

Protocols that rely on submitting proofs of consensus chain rewards can take a hit here, since that’s a lot of proof for a little bit of other work.

1 Like
5

EIP-7976 does two things:

  • Increases the floor price of non-zero calldata bytes by 60%
  • Increases the floor price of zero calldata bytes by 540%

Unsurprisingly therefore, it has a disproportionately strong effect on transactions that use ABI encoding, and reduced effect on “bad” transactions that are mostly uncompressable data.

Here’s a heatmap showing the cost effect percentage on affected transactions against the compressed size of the calldata for those transactions. The clear trend is that more compressible the calldata is, the larger the relative price increase with this EIP.

image
image1038×987 16.7 KB

(This vertical axis of this chart is showing the percentage increase in cost after EIP-7976.)

Calldata should be compressed, both across the network, and when in storage. This means that the actual network and storage costs to ethereum are based the compressed size, not the uncompressed size.

I understand not pricing calldata at the compressed sizes since that enshrines a compression algorithm into the gas pricing. However, that does not preclude continuing to keep 0 bytes priced less. Lots of zeros is a subset of compressing well, and would match both the already existing ABI behavior and the code that is built around the currently existing incentive. We gain little at the protocol level for punishing zeros.

1 Like
6

The base cost formula is adjusted based on 21,000—the old TX_BASE_COST value—whereas EIP-2780 specifies a value of 12,000, surely that figure should have been updated concurrently during client implementation?