EIP-7971: Hard limit and cost reduction for transient storage allocation

[charles-cooper]

I’ve been considering the attack you describe and I don’t think it works that well in practice.

• Because of the lack of introspection of transient_slots_used variable, a would-be attacker can’t be sure of the “just so” number of slots to allocate to deprive downstream calls of transient storage slots, but so that it itself does not hit MAX_TRANSIENT_SLOTS and exceptional halt.
• A would-be attacker can’t be sure that downstream calls use transient storage, therefore it can’t even be sure if it will force downstream calls to revert.

I’m also simply not convinced this class of attacks is that dangerous:

@yoavw

• ERC-4337 bundles: One UserOp calls such a contract, causing the UserOps of other users to revert and also pay for these reverts.

What would be the point of this?

@yoavw

• Intent protocols or CoW swaps - a user may include a transfer of a malicious token which allocates MAX_TRANSIENT_SLOTS slots, causing other tokens to revert.

• Other tokens could revert for any reason; the success of the token transfers should be checked by any such protocol anyways.

@yoavw

• Any interop protocol where a relayer performs a call on behalf of the user. The relayer can relay the user’s call but cause it to revert, effectively censoring crosschain calls.

The relayer can cause the call to revert in a number of other ways, including:

• Restricting the amount of gas passed to the call
• Simply not performing the call, if censorship is the desired outcome

@yoavw

• Any EIP-7702 use case where a 3rd party performs calls on the user’s behalf (most of the 7702 use cases).

• Again, this seems pointless on the part of the 3rd party. They can employ one of the methods mentioned previously (restricting gas or simply not making the call)
• This would also likely be detected by users during transaction simulation, who have the freedom to choose other service providers; I’m guessing a transaction relayer which censors user actions would not remain popular for very long.

In all of the above cases, these would likely be mitigated during transaction simulation, or the outermost contract may choose to allocate a random number of transient storage slots to deprive the would-be attacker contract of certainty of whether they would succeed.

This brings me to my next point, which is that the mitigation that that you suggested (here EIP-7923: Linear, Page-Based Memory Costing - #30 by yoavw), allowing introspection access via a new opcode TRANSIENT_SLOTS_USED, is possible, but I think it’s overkill. I think that in general, too much ability to introspect VM limits can cause other issues. For example, in the class of attacks you describe, it would actually give the would-be attacker more certainty about whether their attack will succeed, not less.