EIP-7971 Transient storage gas reduction and hard limit (Hard Limits for Transient Storage)

Declined for Inclusion · Fees & gas · EIP status Draft · created 2025-06-12

Lowers the gas cost of the transient storage opcodes TLOAD and TSTORE from 100 to 5 and 12 respectively, and limits the number of slots usable in one transaction to 131072 to prevent resource exhaustion attacks.

Why it is needed

The transient storage introduced by EIP-1153 is a temporary storage space that disappears when the transaction ends. It does not need to be written to disk or update the state root, yet it is priced at 100 gas, the same as a warm access to regular storage. This price still makes it costly for programming languages to include reentrancy locks by default, and it discourages legitimate uses such as temporary approvals, callback metadata, and communication between frames within a transaction. Simply lowering the price, however, would let an attacker mount a denial-of-service (DoS) attack by allocating large amounts of memory cheaply. So this EIP lowers the price and at the same time sets a hard limit on the number of slots a transaction can use, so that common use cases stay cheap and clients get a firm guarantee on the upper bound of resource consumption.

What changes

Today

After EIP-7971

Who is affected

In depth

Gas cost change: TLOAD 5, TSTORE 12

The gas cost of TLOAD (opcode 0x5c) is lowered from GAS_WARM_ACCESS (100) to GAS_TLOAD (5), and the base gas cost of TSTORE (opcode 0x5d) is lowered from 100 to GAS_TSTORE (12). The basis is actual resource usage. Reading transient storage needs only a memory access with no disk I/O, so it is set at 5 gas. Writing needs memory allocation and journaling to support reverts, so it is set at 12 gas. This corrects the inconsistency that transient storage is priced the same as warm storage operations even though it is fundamentally cheaper in resources than persistent storage (no disk I/O, no state root update).

Transaction-global slot counter and limit

At the start of a transaction, the transient_slots_used counter is initialized to 0. When TSTORE executes and the slot is being written for the first time in this transaction (from any contract), the counter increases by 1. If the counter exceeds MAX_TRANSIENT_SLOTS (131072), the transaction MUST be aborted with an exceptional halt. The counter is maintained across all message calls within the transaction and is reset to 0 when the transaction ends. Slot uniqueness is based on the (contract_address, storage_key) tuple. Writing to the same slot several times normally does not increase the counter after the first write, except when the slot is released by a revert.

Cost of allocating a new slot, GAS_TSTORE_ALLOCATE

Writing to a new slot for the first time requires memory allocation, so it is more expensive than rewriting an existing slot. For that reason, charging an additional GAS_TSTORE_ALLOCATE (24) on the first allocation is under consideration. However, this also requires a mechanism to distinguish a first allocation from a later write. The reference implementation includes this charging scheme. If the slot is not in the unique_slots set, it deducts an extra 24 gas and adds the slot to the set, and if the set size exceeds 131072 it raises ExceptionalHalt.

Figures to be finalized after benchmarks

The proposal states explicitly that the figures are not yet final. Benchmarks for transient memory operations are currently under development, and the final numbers will be set once that data is collected. That data will also be used to judge whether the performance difference is large enough to charge new slot allocation differently. It also notes that warm storage loads read from cache are expected to have performance characteristics similar to transient storage reads, so the final parameters must be kept consistent with EIP-8038. Test cases are also still TBD.

Choice of hard limit and rejected alternatives

MAX_TRANSIENT_SLOTS of 131072 gives ordinary applications enough slots while capping memory use per transaction at about 8MB (131072 slots × 64 bytes), which prevents out-of-memory (OOM) based DoS. The hard limit has three advantages. Total resource consumption is guaranteed without computing it as a function of the current gas limit, ordinary use cases that use only one or two slots, such as reentrancy locks, do not bear the worst-case cost, and clients can safely reserve all the memory they need at the start of a transaction. Among the alternatives considered, a per-contract limit makes reasoning about resources complicated because it depends on the shape of the call stack, superlinear pricing adds complexity while continuing to penalize ordinary use cases, and an unlimited approach could allow memory DoS if the transaction gas limit or pricing changes later, so all three were rejected.

Security effect: maximum allocation reduced by 79%

At the current 100 gas price, a 60 million (60M) gas transaction can allocate up to 600,000 transient storage slots, or 38.4MB. With this EIP, the cap is fixed at 131072 slots, about 8MB, which reduces the maximum allocation by 79%. Because it is a hard limit, the upper bound on resource consumption stays predictable even if the gas limit or other protocol parameters change in the future. There are no known backward compatibility issues other than the fact that existing operations become cheaper.

Status and core developer call decisions

This EIP is in Draft status, so its content may still change. According to the call records, at 08.13 ACDE #243, EIP 7971 was not accepted as a fork inclusion candidate (DFI), along with 8058, 7609, 7973, and 8360. The champion (the person responsible for driving the proposal) was not on the call, so nixo will contact the author and close the PR if they cannot be reached.

Original EIP · ← EIPs