Abstract
This proposal introduces block-scoped transient storage opcodes, which manipulate state that behaves identically to storage, except that block-scoped transient storage is discarded after every block. Unlike transaction-scoped transient storage introduced in EIP-1153, values written via BSTORE persist across transactions within the same block and are readable by subsequent transactions executing against the same contract. All values are discarded when the block is finalized. Because block-scoped transient storage is never serialized to disk, it is significantly cheaper than persistent storage (SSTORE/SLOAD). Block-scoped transient storage is accessible to smart contracts via 2 new opcodes, BLOAD and BSTORE, where "B" stands for "block:"
BLOAD (0x5e)
BSTORE (0x5f)Motivation
EIP-1153 introduced transaction-scoped transient storage, enabling cheap inter-frame communication within a single transaction. However, there is no equivalent mechanism for cheap state that persists across transactions within the same block. Currently, contracts that need to maintain block-level state — such as cumulative values, per-block rate limits, or block-local registries — must use persistent storage (SSTORE/SLOAD), paying the full cost of disk serialization for data that is only meaningful for the duration of a single block.
This is wasteful. Persistent storage incurs high gas costs because it must be written to and read from disk, replicated across all nodes, and maintained indefinitely in the state trie. For state that is inherently ephemeral to a single block, these costs are disproportionate to the value of the data.
Block-scoped transient storage solves this by providing a dedicated storage region that:
- Never touches disk. Values exist only in memory for the lifetime of the block, so reads and writes are dramatically cheaper than persistent storage.
- Persists across transactions within a block. Unlike
TSTORE/TLOADwhich are cleared after each transaction,BSTORE/BLOADvalues accumulate across all transactions in a block, enabling new patterns of cross-transaction coordination. - Is automatically cleared at block finalization. No explicit cleanup is needed, and no state bloat is introduced.
Potential use cases enabled or improved by this EIP include:
- Per-block rate limiting: Contracts can enforce block-scoped throughput limits (e.g. maximum volume per block) without paying for persistent storage writes that are irrelevant after the block.
- Block-local accumulators: Aggregate values across transactions within a block — for example, a DEX tracking total block volume for dynamic fee computation.
- Block-scoped registries: Temporary registries or caches that are meaningful only within the current block context.
- Cheaper state transitions for block-basis operations: Any contract logic that resets or rotates state on a per-block basis can use block-scoped storage instead of persistent storage, significantly reducing gas costs.
- MEV-aware contract logic: Contracts can observe and react to cumulative activity within a block, enabling more sophisticated on-chain strategies.
- Cross-transaction reentrancy guards: Locks that span an entire block rather than a single transaction.
These opcodes are more efficient to execute than SSTORE and SLOAD because values are never serialized to or deserialized from disk. They are also more efficient than writing to persistent storage and later overwriting, because no storage refund accounting is needed.
Specification
Two new opcodes are added to the EVM, BLOAD (0x5e) and BSTORE (0x5f).
They use the same arguments on stack as SLOAD (0x54) and SSTORE (0x55).
BLOAD pops one 32-byte word from the top of the stack, treats this value as the address, fetches a 32-byte word from the block-scoped transient storage at that address for the executing contract, and pushes the value on top of the stack. If no value has been written to that slot in the current block, the value returned is 0.
BSTORE pops two 32-byte words from the top of the stack. The word on the top is the address, and the next is the value. BSTORE saves the value at the given address in the block-scoped transient storage for the executing contract.
Addressing is the same as SLOAD and SSTORE. i.e. each 32-byte address points to a unique 32-byte word.
Gas cost for BSTORE is the same as a warm SSTORE of a dirty slot (i.e. original value is not new value and is not current value, currently 100 gas), and gas cost of BLOAD is the same as a hot SLOAD (value has been read before, currently 100 gas). Gas cost cannot be on par with memory access due to block-scoped transient storage's interactions with reverts.
All values in block-scoped transient storage are discarded when the block is finalized.
Values written via BSTORE in one transaction are visible to subsequent transactions in the same block when they execute against the same contract. This is the key difference from EIP-1153 transient storage, which is cleared at the end of each transaction.
Block-scoped transient storage is private to the contract that owns it, in the same way as persistent storage. Only owning contract frames may access their block-scoped transient storage. And when they do, all the frames access the same block-scoped transient store, in the same way as persistent storage, but unlike memory.
When block-scoped transient storage is used in the context of DELEGATECALL or CALLCODE, then the owning contract of the block-scoped transient storage is the contract that issued DELEGATECALL or CALLCODE instruction (the caller) as with persistent storage. When block-scoped transient storage is used in the context of CALL or STATICCALL, then the owning contract of the block-scoped transient storage is the contract that is the target of the CALL or STATICCALL instruction (the callee).
If a frame reverts, all writes to block-scoped transient storage that took place between entry to the frame and the return are reverted, including those that took place in inner calls. This mimics the behavior of persistent storage and transaction-scoped transient storage as defined in EIP-1153.
If the BSTORE opcode is called within the context of a STATICCALL, it will result in an exception instead of performing the modification. BLOAD is allowed within the context of a STATICCALL.
Rationale
Why not use persistent storage?
Contracts already use persistent storage (SSTORE/SLOAD as specified for gas accounting in EIP-2200) for block-scoped patterns by writing values and later overwriting or ignoring them. This is expensive because persistent storage operations require disk I/O — values must be serialized to the state trie and replicated across all nodes. For data that is only relevant for a single block, this cost is entirely unnecessary. Block-scoped transient storage avoids disk access entirely, keeping values in memory only, which justifies a significantly lower gas cost.
Why not use transaction-scoped transient storage (EIP-1153)?
EIP-1153 introduced TSTORE/TLOAD for state that is discarded after every transaction. While this is useful for intra-transaction communication, it cannot be used for cross-transaction coordination within a block. A contract using TSTORE to track cumulative block activity would lose all state between transactions. BSTORE/BLOAD fills this gap by providing storage that persists for the lifetime of the block.
Storage-like interface
The word-addressed storage-like interface is chosen for the same reasons outlined in EIP-1153: the usefulness of mappings for arbitrary key-value lookups, consistency with existing SSTORE/SLOAD and TSTORE/TLOAD interfaces, and simpler compiler support.
Gas cost
The gas cost of 100 for both BSTORE and BLOAD is set to match TSTORE and TLOAD from EIP-1153. This is appropriate because, like transaction-scoped transient storage, block-scoped transient storage never requires disk access. The cost cannot be lower than this due to the need to support revert semantics and the memory allocation implications.
Revert behavior
Revert behavior is consistent with SSTORE, SLOAD, TSTORE, and TLOAD — if a call frame reverts, all BSTORE writes within that frame are undone. This maintains the principle of least surprise and ensures that existing patterns for error handling apply uniformly across all storage types.
Block-level lifecycle
The choice of block-level lifetime (rather than, say, epoch or slot) is deliberate. A block is the most natural unit of execution finality in the EVM, and block-scoped storage aligns with the block producer's view of state. This provides a clean lifecycle: values accumulate as transactions are executed, and are discarded atomically when the block is complete.
Backwards Compatibility
This EIP requires a hard fork to implement.
Since this EIP does not change the behavior of any existing opcodes, it is backwards compatible with all existing smart contracts.
Test Cases
TBD
Reference Implementation
TBD
Security Considerations
TBD
Copyright
Copyright and related rights waived via CC0.
