This proposal introduces a gas discount for contract deployments when the bytecode being deployed already exists in the state. By leveraging EIP-2930 access lists, any contract address included in the access list automatically contributes its code hash to a deduplication check. When the deployed bytecode matches an existing code hash from the access list, the deployment avoids paying GAS_CODE_DEPOSIT * L costs since clients already store the bytecode and only need to link the new account to the existing code hash.
This EIP becomes particularly relevant with the adoption of EIP-8037, which increases GAS_CODE_DEPOSIT from 200 to 1,900 gas per byte. Under EIP-8037, deploying a 24kB contract would cost approximately 46.6M gas for code deposit alone, making the deduplication discount economically significant for applications that deploy identical bytecode multiple times.
Sequential transaction execution ensures that a deployment storing new code makes it visible to later transactions in the same block
Is this EIP built on the assumption that transaction execution will forever be sequential? Will it be problematic to have this EIP in a world where we want to parallelize all tx executions of a given block?
This only affects the odd case where 2 txs are submitted within a block and one references in the AL the contract that another deploys within the same block.
But that’s right that this should probably be correctly specified. Otherwise it could lead to consensus issues.
So, can this discount be extended to EOAs that share the same authorization indicator. Besides, can we use the access list from EIP-7928 instead of the relatively outdated EIP-2930 to build CodeHash?
Since we somewhat deprecate access lists in Glamsterdam I propose a different algorithm here to check for contract bytecode deduplication:
All EXTCODEHASH account queries prior to the code deposit operation (so initcode returning) are pushed to the journal. Note that in BAL these will enter as Account. Once the contract is deployed, loop over the EXTCODEHASH list to verify if the hash exist. This removes the access list pattern and just makes this EVM based. The downside is that we need an extra EXTCODEHASH journal, because this is a subset of the Account entries in BAL. This should not be too complex though. We can also somewhat assume that if the account is in the BAL, by retrieving this account, we already have the code hash, since these are currently grouped by the account RLP in the state trie.
I would also require EIP-4758: Deactivate SELFDESTRUCT, this gets rid of nasty implementations where we create a contract, then EXTCODEHASH it from inititcode from a yet-to-be-created contract in the same transaction (getting this discount), and then in same tx SELFDESTRUCT the just created account. It is not a big problem and since EIP-8037 does not give you the state creation cost back for SELFDESTRUCTed accounts (per “Gas refills for SELFDESTRUCT” section)
I nevertheless think the EIP should be updated to reflect the state gas changes of Glamsterdam
