Setting a transaction-wide maximum may introduce a DoS risk in protocols where a single transaction includes calls from multiple users. A call to a contract that allocates MAX_TRANSIENT_SLOTS TSTOREs can cause other unrelated calls to fail.
Examples:
- ERC-4337 bundles: One UserOp calls such a contract, causing the UserOps of other users to revert and also pay for these reverts.
- Intent protocols or CoW swaps - a user may include a transfer of a malicious token which allocates
MAX_TRANSIENT_SLOTSslots, causing other tokens to revert. - 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.
- Any EIP-7702 use case where a 3rd party performs calls on the user’s behalf (most of the 7702 use cases).
We should mitigate protocol DoS via correct gas price, not by placing hard limits on how many times an opcode may be called. If 12 is a safe price for TSTORE, it shouldn’t require a hard limit. If it isn’t, let’s increase it to a safe value.
Gas limits cause a similar risk but it’s mitigated by passing a gas limit to CALL. If we add another hard limit to transactions, we’ll need to add it as a parameter to CALL as well.