EIP-2929 tracks accessed addresses and storage keys in the transaction-scoped sets accessed_addresses and accessed_storage_keys, and rolls both sets back to their pre-call state when a call frame reverts or exceptionally halts. This EIP removes that rollback: once an address or storage key is added to an access set, it remains warm for the rest of the transaction, regardless of any subsequent revert.
Warm and cold pricing exists to reflect the client's real cost of loading state. That cost is paid when the data is first read from the database; a revert undoes state changes, but it does not unload the data — it stays in the client's caches, and a second access within the same transaction is cheap in reality. Rolling the access sets back on revert therefore charges cold prices for accesses that are warm in practice.
Removing the rollback aligns the gas schedule with actual execution cost and simplifies implementations: access sets become append-only for the duration of the transaction and no longer need to participate in the state journal or checkpoint/revert machinery.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
As of the fork block:
accessed_addresses and accessed_storage_keys MUST NOT be rolled back. All entries added during the frame's execution, including those added by its subcalls, MUST remain in the sets.For a cold account or storage access, the cold access charge MUST be paid before its address or storage key is added to the corresponding set. If there is insufficient gas to pay that charge, the entry MUST NOT be added. Once the charge is paid, the entry MUST remain in the set even if a subsequent charge or check in the same operation fails. The rules for entries initialized at transaction start and addresses added by CREATE or CREATE2 remain as specified in EIP-2929.
Access sets are a metering mechanism, not observable state, so reverting them protects nothing: reverting a frame cannot make the client forget the bytes it already read. Making the sets append-only prices the second access at what it actually costs and removes the only piece of the journal that models a cache rather than state.
An alternative would be keeping the rollback but discounting repeated cold accesses; that adds a third pricing tier for no benefit over simply keeping entries warm.
This EIP requires a hard fork. After the fork, some accesses that were previously charged cold are charged warm, so transactions become cheaper or stay the same — no transaction becomes more expensive. Contracts relying on exact gas costs of accesses after a revert may observe different gas consumption.
The following cases use the access charges defined by EIP-2929. EIP-8038 renames WARM_STORAGE_READ_COST, COLD_SLOAD_COST, and COLD_ACCOUNT_ACCESS_COST to WARM_ACCESS, COLD_STORAGE_ACCESS, and COLD_ACCOUNT_ACCESS, respectively, if it is active.
DELEGATECALLs frame B; B performs a cold SLOAD of slot s in A's storage and reverts. A then loads s and pays the warm storage access charge.BALANCE of address a, then runs out of gas. A then accesses a and pays the warm account access charge.a. A's subsequent access to a pays the cold account access charge.Persisting warmth across reverts lets a transaction warm addresses and storage keys inside a frame that is then reverted, and access them cheaply afterwards. This is not a new capability: an EIP-2930 transaction access list already changes the warm/cold status of arbitrary addresses and storage keys in exactly the same way, before execution even begins. In both cases the cold cost of every warmed entry is paid once within the transaction, so total charged work still covers the client's actual loading cost.
Copyright and related rights waived via CC0.