EIP8212: Block-scoped transient storage

EIPs
1

Discussion topic for EIP-8212

What this EIP Proposes

This EIP introduces two new opcodes, BSTORE and BLOAD, that provide block-scoped transient storage to the EVM. Values written via BSTORE persist across all transactions within a block but are automatically discarded when the block is finalized. This fills a gap between transaction-scoped transient storage (TSTORE/TLOAD from EIP-1153), which is cleared after every transaction, and persistent storage (SSTORE/SLOAD), which is written to disk and maintained indefinitely. Block-scoped storage is private to the owning contract and follows the same revert semantics as existing storage types.

Motivation

Contracts that need to track state within a block, such as per-block rate limits, volume accumulators, or block-local registries, currently must use persistent storage, paying full disk serialization costs for data that becomes irrelevant the moment the block is finalized. This is unncessarily expensive. Because block-scoped transient storage never touches disk, it can be offered at significantly lower gas costs while enabling new patterns of cross-transaction coordination that are impossible with EIP-1153’s transaction-scoped storage.

What requires feedback

  1. The appropriate gas cost for BSTORE and BLOAD is an open question. While this EIP currently proposes 100 gas (matching TSTORE/TLOAD), block-scoped storage crosses the transaction boundary meaning values must be held in memory for the entire block rather than a single transaction. This longer lifetime increases the memory burden on nodes and may warrant a higher gas cost to reflect the additional resource consumption.

  2. From an implementation perspective, feedback is required on how block-scoped transient storage would differ from transaction-scoped transient storage in client implementations. Transaction-scoped storage can be trivially cleared between transactions, but block-scoped storage must be maintained across the full block lifecycle while still supporting per-transaction revert semantics.

  3. There is a question of whether this EIP would be more valuable as a generalized form — storage that persists for n blocks rather than exactly one. An n-block lifetime would unlock other usecases. Feedback is appreciated whether the added complexity of an n-block lifetime is justified by the expanded use cases, or whether block-scoped storage is the right level of granularity

Update Log

External Reviews

None as of 2026-04-03.

Outstanding Issues

None as of 2026-04-03.

References

2

Here’s another use case: things like EEZ that require an execution table to be prepared in order to serve pre-proven rollup calls. (See Synchronous Composability Between Rollups via Realtime Proving on Ethresear.ch) After a few transactions at most, the table can be discarded, yet discarding it actually costs more gas than leaving it laying around, which is a bit backwards, like fining people for picking up their trash. That said they might be able to make do with transient storage, more research needed.

There’s an interaction between this EIP and EIP-7928: Block-Level Access Lists which I think should be pointed out: block-scoped storage needs to be added to the block-level access lists, otherwise we lose the ability to parallelize execution. EIP-7928 will be on Mainnet this year in Glamsterdam. As a result I would suggest raising gas costs of block-scoped storage closer to, but not exactly at the level of persistent storage.