EIP-1153: Transient storage opcodes

EIPs EIPs core
,
45

Here is a concrete example of my use case that requires these opcodes (A is a third party developer, B is the protocol):

  • A calls B#openCheckbook()
    • B calls ICheckbookOpener(msg.sender).opened()
      • A calls B#spend() which accumulates a debt to the checkbook (transient storage)
      • A calls B#deposit() which pays off a debt to the checkbook (transient storage)
    • B checks the checkbook is balanced and reverts if not

We want user contract A to be able to call methods in protocol contract B in any order and while interacting with any external contracts in between calls to B, and check the accounting only when user contract A is done. Giving up control to the caller of B is the easiest way to do this. The minimum amount of transient storage slots used by this pattern for accounting in our use case is 6, but transactions can easily use more than 6 slots for accounting. The cost to make all these transient SSTOREs makes up more than half the gas cost.

As of EIP-3529, the refund is limited to 20% of the gas used, so the transaction must spend at least 600k gas to get a full refund for 6 transient storage slots. In addition, the SLOADs for 6 slots that are guaranteed to be 0 make up another ~15k gas. This model isn’t really feasible with the high cost of storage-used-transiently.

The only alternative model available in the EVM today is creating a separate ‘VM’ (a la weiroll VM) that is executed by contract B. However, to do so without introducing security issues in contract B is very difficult, and also the design is hard to use (difficult to construct the calldata onchain).

1 Like