EIP-7623 Calldata Cost Increase (Increase calldata cost)
Final · Fees & gas · EIP status Final · created 2024-02-13
It sets a new floor on the calldata gas cost for transactions that mainly post data, which reduces the theoretical maximum block size. The cost of ordinary transactions with heavy EVM computation is unchanged.
Why it is needed
The total amount of gas an Ethereum block can hold (the block gas limit) has not grown since EIP-1559, but the average block size has kept growing as rollups post data to Ethereum. The price of calldata, the space in a transaction used to carry data, has also stayed the same since EIP-2028. As a result, the average block is about 100KB while the theoretical maximum block can grow to 7.15MB, a large gap. The network must always prepare for the worst-case block size, so a large gap makes it hard to add blobs or raise the block gas limit. Now that EIP-4844 has introduced blobs for data publishing, this proposal raises the calldata price for data-heavy transactions to reduce the maximum block size and its variance.
What changes
Today
- Calldata costs the same for every transaction. A zero byte costs 4 gas and a nonzero byte costs 16 gas.
- The theoretical maximum execution payload is about 1.79MB, and it can grow to 7.15MB if filled with zero bytes.
- The gap between the average block (about 100KB) and the maximum block is large, which makes expanding blobs or raising the gas limit burdensome.
After EIP-7623
- Data-heavy transactions face a floor of about 10 gas per byte (zero bytes) and 40 gas per byte (nonzero bytes).
- The maximum payload for data-heavy transactions drops to about 0.72MB.
- Transactions with a large share of EVM computation keep the existing 4/16 gas, so their cost does not change.
- The reduced maximum block size leaves room to add blobs or raise the block gas limit.
Who is affected
- Ordinary users: Ordinary transactions such as ETH, token and NFT transfers and DeFi do not use calldata to publish data, so most are unaffected.
- Wallet developers: eth_estimateGas must be updated to reflect the TOTAL_COST_FLOOR_PER_TOKEN floor. Otherwise it will estimate too little gas and transactions may fail.
- Client and node operators: The gas estimation RPC must be changed to use the new formula, and it takes effect together with the scheduled network upgrade.
- Rollups and L2s: Posting data through calldata becomes more expensive, so publishing data through blobs becomes more advantageous.
In depth
The token unit and the two constants
Calldata is converted into tokens rather than bytes. tokens_in_calldata = zero_bytes_in_calldata + nonzero_bytes_in_calldata * 4, so a zero byte is 1 token and a nonzero byte is 4 tokens. There are two constants. STANDARD_TOKEN_COST is 4 and corresponds to the existing price (4 gas per zero byte, 16 gas per nonzero byte), and TOTAL_COST_FLOOR_PER_TOKEN is 10 and corresponds to the floor price (10 gas per zero byte, 40 gas per nonzero byte).
New gas formula: max(existing cost, floor)
A transaction's total gas usage (tx.gasUsed) changes to 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). execution_gas_used is the gas spent on EVM execution minus the gas refund, and INITCODE_WORD_COST is 2 as defined in EIP-3860. When EVM execution gas is large enough, the left term wins and the result is the same as before, and the floor on the right applies only to transactions overwhelmingly dominated by calldata.
Gas limit validity rule
A transaction is invalid if its gas limit is less than 21000 + TOTAL_COST_FLOOR_PER_TOKEN * tokens_in_calldata or less than the intrinsic gas (whichever is larger). The floor price of calldata must be guaranteed regardless of the transaction's execution result. There are valid cases where the actual gasUsed comes out below this floor, but at least the floor amount must be reserved in the gas limit in advance.
How much the maximum block size shrinks
The current maximum execution payload is about 1.79MB (30_000_000/16), and it can reach 7.15MB if filled with zero bytes. However, blocks are compressed with Snappy at the P2P layer, so a payload dominated by zero bytes usually compresses to below 1.79MB, and with the introduction of EIP-4844 the maximum block by compressed size has grown to about 2.54MB. This EIP aims to raise the calldata cost of data-heavy transactions to 10/40 gas and reduce the maximum payload to about 0.72MB (30_000_000/40). Other adversarial block constructions can reach about 1.26MiB measured on uncompressed payloads.
What wallets and nodes need to do
This change is a backward-incompatible gas repricing, so it requires a scheduled network upgrade. Wallets that use eth_estimateGas must be updated to reflect TOTAL_COST_FLOOR_PER_TOKEN correctly, or they will underestimate gas and transactions may fail. RPC methods in node software such as eth_estimateGas must also reflect the new formula. Users do not need to change how they use their wallets once the wallets and RPCs are updated.
Transaction bundling concerns and the rebuttal
A strategy of merging a calldata-heavy transaction with an EVM-computation-heavy transaction to avoid the floor may look advantageous. The original document sees it as not a major problem for three reasons. First, such bundling is possible today, merging transactions saves 21,000 gas per additional transaction, and ERC-4337 explicitly supports it. Second, even with bundling, the EIP's goal of reducing block size is not undermined. Third, in practice bundling is not easy because of trust and coordination problems. Because the change reduces the maximum block size itself, there are no security concerns raised.