EIP-8037 - State Creation Gas Cost Increase

Created 2025-10-01
Status Draft
Category Core
Type Standards Track
Authors
Requires

Harmonization and increase of state creation gas costs to mitigate state growth and unblock scaling

Abstract

This proposal increases the cost of state creation operations, thus avoiding excessive state growth under increased block gas limits. It sets a unit cost per new state byte that targets an average state growth of 60 GiB per year at a block gas limit of 300M gas units and an average gas utilization for state growth of 30%. Contract deployments get a 10x cost increase while new accounts get a 8.5x increase. Deployments of duplicated do not pay deposit costs. To avoid limiting the maximum contract size that can be deployed, it also introduces an independent metering for code deposit costs.

Motivation

State creation does not have a harmonized cost, with different methods incurring varied costs for creating the same size of new state. For instance, while contract deployment only costs 202 gas units per new byte created, new storage slots cost 625 gas units per new byte created. Also, deploying duplicated bytecode costs the same as deploying new bytecode, even though clients don't store duplicated code in the database. This proposal establishes a standard to harmonize all state creation operations.

Additionally, state growth will become a bottleneck for scaling under higher block limits. As of May 2025, the current database size in a Geth node dedicated to state is ~340 GiB. After the increase in gas limit from 30M to 36M gas units, the median size of new state created each day doubled, from ~102 MiB to ~205 MiB.

new_state_added

The relationship we are seeing in this example is not linear as expected. This is likely due to other factors impacting user behavior. However, all else being equal, we expect a proportional increase in the number of new states created as gas limits increase. At a 60M gas limit (and a proportional increase in new state per day of 1.7x), we would see a daily state growth of ~349 MiB and a yearly state growth of ~124 GiB. Similarly, at a 100M gas limit, the state would grow at a rate of ~553 MiB per day and 197 GiB per year. This level of state growth would give us less than 2.5 years until the size of the state database exceeds the threshold of 650 GiB, at which point nodes will begin experiencing a degradation in performance.

Specification

Parameter changes

Upon activation of this EIP, the following parameters of the gas model are updated:

Parameter Current value New value Increase Operations affected
GAS_CREATE 32,000 212,800 6.7x CREATE, CREATE2, contract creation txs
GAS_CODE_DEPOSIT 200 1,900 9.5x CREATE, CREATE2, contract creation txs
GAS_NEW_ACCOUNT 25,000 212,800 8.5x New EOA funding
GAS_SELF_DESTRUCT_NEW_ACCOUNT 25,000 212,800 8.5x SELF_DESTRUCT
GAS_STORAGE_SET 20,000 60,800 3x SSTORE
PER_EMPTY_ACCOUNT_COST 25,000 212,800 8.5x EOA delegation
PER_AUTH_BASE_COST 12,500 43,700 3.5x EOA delegation

Multidimensional metering for code deposit gas

Besides the parameter changes, this proposal introduces an independent metering for the code deposit costs. The specification is derived from EIP-8011. However, it only requires two dimensions, namely, gas and code_deposit_gas.

Contract deployment cost calculation

This proposal further changes how contract deployment cost are computed. When a contract creation returns a runtime bytecode R (length L), first check whether the code already exists in the state trie. Then:

In addition, contract creation is also charged a storage_access_cost = GAS_WARM_ACCESS (if warm) | GAS_COLD_SLOAD (if cold) and a hash_cost = GAS_KECCAK256_WORD * code_data_words, where code_data_words = ceil(L / 32). This accounts for the added execution cost of accessing and verifying for duplicated code.

CREATE vs CREATE2

CREATE2 already charges for hashing the init code when deriving the address. That cost remains. Runtime-code deduplication hash (keccak256(R)) is separate: even with CREATE2, the runtime hash must be computed to determine whether the code is new or already stored.

Rationale

Harmonization across state creation

With the current pricing, the gas cost of creating 1 byte of state varies depending on the method used. The following table shows the various methods and their gas cost per byte. The calculation ignores the transaction intrinsic cost (21k gas units) and the costs of additional opcodes and scaffolding needed to execute such a transaction.

Method What is written Intrinsic gas Bytes → state Gas / byte
Deploy 24kB contract (EIP-170 limit) Runtime code + account trie node 32,000 CREATE + 25,000 new account + 200 × 24,576 code deposit = 4,972,200 gas 24,576 B ~202 gas
Fund fresh EOA with 1 wei Updated account leaf 25,000 new account ~112 B ~223 gas
Add delegate flag to funded EOA (EIP-7702) 23 B (0xef0100‖address) + updated account leaf 25,000 PER_EMPTY_ACCOUNT + 12,500 PER_AUTH_BASE + 1,616 calldata - 7,823 refund = ~31,300 gas ~135 B ~232 gas
EIP-7702 authorization to empty address 23 B (0xef0100‖address) + updated account leaf 25,000 PER_EMPTY_ACCOUNT + 12,500 PER_AUTH_BASE + 1,616 calldata = 39,116 gas ~135 B ~289 gas
Fill new storage slots (SSTORE 0→x) Slot in storage trie 20,000 gas/slot 32 B 625 gas

To harmonize costs, we first set the gas cost of a single state byte, cost_per_state_byte. This cost targets an average growth of 60 GiB per year at a block gas limit of 300M gas units and an average gas utilization for state growth of 30%. A recent empirical analysis has shown that, at current gas prices, state creation accounts for approximately 30% of all gas consumed. ** Additionally, on average, blocks use half of the entire available gas in the block. Thus, we are setting the unit gas cost of state creation based on the average case. Finally, we are targeting a 300M block limit to account for scaling optimizations expected in the short to medium term.

This capacity corresponds to an average of $\frac{60 \times 1024^3}{365} = 176,505,505$ bytes per day. With a 300M gas limit, Ethereum will process $150M \times 7,200 = 1,080,000M$ gas units per day, at block target. With a 30% consumption dedicated to state creation, the total gas units per day for state creation are $1,080,000M \times 0.3 = 324,000M$. Thus, the cost per byte is $\frac{324,000M}{176,505,505}=~1,835$. To provide a further buffer and simplify calculations, we round this number and set cost_per_state_byte to 1900.

Now that we have a standardized cost per byte, we can derive the various costs parameters by multiplying the unit cost by the increase in bytes any given operation creates in the database (i.e., 32 bytes per slot, 112 bytes per account and 23 bytes per authorization):

Note that the fixed cost GAS_CREATE for contract deployments assumes the same cost as a new account creation.

Multidimensional metering

EIP-7825 introduces a limit of 16.7M gas units for a single transaction. With the proposed contract creation costs, this cap would limit the maximum contract size that can be deployed to roughly 6kb ($\frac{16,777,216 - 21,000 - 5,000,000 - 212,800}{1,900} = 6,075$). The limit by transaction was set in place to mitigate DoS attacks that result in uneven load distribution. This is not a concern for contract deployments, specially after the proposed 10x increase in costs.

An independent metering of the code deposit costs allows to lift this limit for contract creation transactions, while ensuring that users still pay the fair costs of contract deployment.

This proposal is consistent with the multidimensional gas metering introduced in EIP-8011. However, it only requires two dimensions, namely, gas and code_deposit_gas. If EIP-8011 is not implemented, a two-dimensional version of EIP-8011 is still required.

Duplicated bytecode discount

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:

Users can maintain their usual workflows without modification, as wallet and RPC updates will handle these changes.

Estimated price impacts

Users and dApp developers will experience an increase in transaction costs associated with creating a new state. Assuming an ETH price of 4000 USD, here is a comparison for some operations:

New account:

New slot:

24kB contract deployment:

24kB contract deployment with duplicated bytecode:

Note that we are ignoring transaction intrinsic costs (21k gas units), call data costs, and the costs of additional opcodes and scaffolding needed to execute such transactions.

Security Considerations

Increasing the cost of state creation operations could impact the usability of certain applications. More analysis is needed to understand the potential effects on various dApps and user behaviors.

Mispricing with respect to ETH transfers

One potential concern is the cost of creating a new account (212,800 gas units), compared to transferring ETH to a fresh account (21,000 gas units). With this mismatch, users wishing to create new account are incentivized to first send a normal transaction (costing 21k) to this account to create it, thus avoiding the PER_EMPTY_ACCOUNT_COST of 212,800 gas units.

EIP-2780 solves this mispricing by adding a new component to the intrinsic gas cost of transactions. For transactions the sending ETH that send ETH to a fresh account. If a non-create transaction has value > 0 and targets a non-existent account, the GAS_NEW_ACCOUNT is added to intrinsic cost.

Independent metering for code deposit costs

Contract creation now introduces a cost that is not accounted for in the traditional gas metering and thus doesn't contribute to the block gas limit or the individual transaction limit. This could potentially be exploited by an attacker to create very large contracts that would stress the network. More benchmarking and analysis is needed to understand the potential risks and to determine if additional mitigations are necessary.

Copyright

Copyright and related rights waived via CC0.