{shanghai,cancun}-candidate: EIP-1153 Transient Storage

The current state of the EIP is as follows:

  1. The EIP has been implemented in Geth, Nethermind, Besu, EthereumJS, Erigon.
  2. Comprehensive EVM tests have been implemented in ethereum/tests. The tests are passing on Geth, Nethermind, Besu, and EthereumJS implementations.
  3. A draft PR for assembly opcodes in Solidity has been implemented and tested with Uniswap prototypes
  4. Application developers from Uniswap, OpenSea, Optimism, Arbitrum, Paradigm, Celo, OpenZeppelin, Nomad, Primitive have expressed support for the EIP. @holiman’s perspective here.

Related links:

Here is a talk I gave at EthCC[5] regarding the primary use case: the “till” pattern. This pattern can be used to reduce token transfers and external calls in future protocols, but requires transient storage in order to be gas-competitive with current patterns due to expensive storage access costs and capped gas refunds. There are many other use cases including (of course) reentrancy locks and rollup L2->L1 transactions. Using transient storage just for reentrancy locks in Uniswap V2 would have freed up estimated O(10-100billions) of gas in block space.

The primary reasons for inclusion are:

  • Enables better smart contract design patterns which are more developer friendly (the “till” pattern)
  • Saves a lot of gas for existing storage-used-transiently use cases (e.g. reentrancy locks)
  • Simplifies the EVM design (storage refunds are complicated)
  • Unblocks parallel transaction execution (along with removing self destruct)

And for inclusion in Shanghai/Cancun:

  • Already implemented and well tested
  • Developers want this yesterday
  • “Transient” usage of SSTORE/SLOAD needs to be deprecated for a long time before verkle trees can potentially deprecate storage refunds

Couple updates:

Really cool to see the developer momentum behind this one