Shanghai-candidate: EIP-1153 Transient Storage

The current state of the EIP is as follows:

  1. The EIP has been implemented in Geth, Nethermind, Besu and EthereumJS.

  2. Both Nethermind and EthereumJS have been reviewed and merge by the core dev teams.

  3. Besu had been reviewed and devs have signalled it can be merged once the EIP is marked for inclusion.

  4. Geth is pending review from the core team.

  5. Comprehensive integration tests have been implemented in ethereum/tests. The tests are passing on Geth, Nethermind, Besu, and EthereumJS.

  6. A draft PR for assembly opcodes in Solidity has been implemented

  7. Application developers from Uniswap, OpenSea, Optimism, Arbitrum, Paradigm, Celo, OpenZeppelin, Nomad, and others have all expressed support/interest in the EIP. Per @holiman “It’s a nice feature, of course we’d want it[…]”. It also simplifies future EVM improvement proposals, in particular regarding storage refunds for verkle tries, and EVM parallelization.

Related links:

Here is a talk I gave at EthCC[5] regarding the primary use case for which I think it will be most beneficial to dapp developers, but there are many use cases including for rollup L2->L1 transactions. The most obvious use case of reentrancy locks already would have freed up estimated O(10-100billions) of gas in block space (considering Uniswap V2 only, assuming supply of ~100B gas per day and Uniswap representing 10% of block space with a 2% per-pool-action gas saving).

The primary reasons for eventual inclusion are:

  • Enables better smart contract design patterns which are more developer friendly
  • Saves a lot of gas
  • In the long term, simplifies the EVM design (storage refunds are complicated)

And for inclusion in Shanghai:

  • Already implemented
  • Contracts need to be updated to use the opcodes before transient uses of SSTORE/SLOAD can be deprecated, which will take time for users and developers to migrate
9 Likes