EIP-4488: Transaction calldata gas cost reduction with total calldata limit

Decrease transaction calldata gas cost, and add a limit of how much total transaction calldata can be in a block.

See: Transaction calldata gas cost reduction with total calldata limit by vbuterin · Pull Request #4488 · ethereum/EIPs · GitHub

8 Likes

This is indeed the optimal strategy for miners - to drop rollup transactions in favor of more execution-oriented transactions. Isn’t there a risk that it’ll actually hurt rollups?

At high congestion times (e.g. big NFT sales) rollup transactions will be constantly dropped, and they’ll have to compensate for the lack of execution gas by paying a higher total fee. Theoretically it should drive rollup gas fees to the current cost, except that it also limits the calldata size. The additional constraint might require them to pay an even higher fee to outbid other rollups competing on the same calldata space.

1 Like

While ostensibly simple, it could be argued that the calldata limit is an architectural decision with greater implications than just modifying a gas constant. An arbitrary limit on calldata per block seems like complexity that could be avoided by just giving calldata the proper gas cost such that it doesn’t present a significant risk.

If there is an arbitrary limit imposed, why not make it a soft limit, or impose it on the entire block size rather than on calldata specifically?

2 Likes

I wonder if something like EIP-2242: Transaction Postdata would be useful in combination of the above, where non-executable/non-accessible data is counted differently.

Summoning @adlerjohn :wave:

Add a rule that a block is only valid if sum(len(tx.calldata) for tx in block.txs) <= BASE_MAX_CALLDATA_PER_BLOCK + len(block.txs) * CALLDATA_PER_TX_STIPEND.

Would it not be easier (and slightly less variable max calldata per block) if only transactions with more than CALLDATA_PER_TX_STIPEND are counted against BASE_MAX_CALLDATA_PER_BLOCK?
Assuming 300 is the stipend per block, transactions with <= 300 calldata won’t provide extra room for transactions that use > 300 calldata.

1 Like

I was told to ask these questions here:

  1. I am trying to understand why the so-called “multi-dimensional complexity” problem associated with this proposal only applies to block producers. Don’t users and wallets also have a potential issue here, as they need to analyse the two dimensions when setting the tip/fee?

  2. Does this proposal somewhat undermine EIP-1559, because the base fee can vary based on the total gas usage, but not total calldata usage. Therefore, might this cause fees to be volatile like pre EIP-1559?

Could we achieve the same goals without the total calldata limit by reducing the cost of calldata and simultaneously increasing the cost of calldata access in EVM, beyond a certain size?

  1. Remove the calldata limit.
  2. Make the cost of calldata read quadratic (with a minimum that keeps the pre-fork cost intact), based on the highest offset accessed. The quadratic function only starts increasing the cost above the minimum, if the highest offset is 2x the current average (excluding rollup transactions).

Pro: it removes the hardcoded limit.
Con: Adds some complexity to the EVM implementation - calculating the calldata read cost based on the highest offset accessed, rather than using a fixed cost.

Would this achieve the same goals?

I was wondering something similar. Instead of blanket reduction in calldata gas cost as per EIP-4488, extend EIP-2242 to allow EVM access to postdata. Then, impose restriction such as total gas used by the execution on the data.

To simplify this restrictive exec environment, create a precompile that allows DELEGATECALL to supplied contract (such as SNARK verifications by ZK Rollups). Precompile only extends a hardcoded MAXGAS to the callee. An EIP-2242-type tx only has access to said precompile.

Note that backward compatibility of non-EIP-2242-type transactions is a breeze thanks to EIP-2718, i.e. a new envelope.

1 Like

I think at this point pretty much anything other than a two-line change in the style of EIP-4488 or 4490 is just too complex and not going to make it for that reason alone. The whole point is to make a quick-and-dirty solution because rollups need it fast fast.

The longer-term solution (or I guess medium-term solution) is to implement the beacon chain sharding spec (which is not that complicated) and only turn on 1-4 shards so we get some dedicated 2 MB space per block with its own efficient fee market and because there’s only a few shards nodes can still fully validate availability and we don’t have to worry about p2p networking.

Assuming 300 is the stipend per block, transactions with <= 300 calldata won’t provide extra room for transactions that use > 300 calldata.

I would say the main issue with this approach is that it would reduce the average-case maximum without reducing the worst-case maximum, so it risks decreasing total scalability.

I am trying to understand why the so-called “multi-dimensional complexity” problem associated with this proposal only applies to block producers. Don’t users and wallets also have a potential issue here, as they need to analyse the two dimensions when setting the tip/fee?

Technically only if the tx has more than 300 bytes, and even then if they keep setting a low priority fee their tx would just float around for a few extra blocks until a block that’s <25% full comes along (which happens quite frequently). Use cases that involve txs with a really huge amount of data (primarily rollups, but also contract creations) may require some special logic eventually, but only if block sizes start actually regularly getting to the calldata limit.

3 Likes