I agree with the sentiment here that this is a platform problem and should not be solved by smart contracts. However, I am concerned with how this proposal would affect transaction validation logic.
There is currently an invariant in mempools that essentially says “if a transaction from an account is determined to be valid, it will continue to be valid until a new block is received that invalidates it.” This EIP would violate this invariant because any new transaction could invalidate any pending transaction. Furthermore, it would be impossible to know if that is the case before fully executing each transaction. We should better understand how important it is to maintain this behavior and explore if this exposes new attack vectors.
Right now I prefer extending the transaction object to support an additional sponsor signature. Although CallWithSigner seems to offer more flexibility in the near-term (payments to a relayer can be processed within the same transaction) there is an increased desire to remove the observability of gas during execution. This would likely make untrusted *CALLs unreliable, because reverts would cascade up and therefore would not be catchable in the parent frame.
there may be superior ways to do it (e.g. full-fledged account abstraction)
I believe AA could potentially provide a one-time breakpoint for performing the accounting that currently takes advantage of gas observability. This is an area that has been underexplored. A fairly analogous idea to CallWithSigner in AA might be a PAYGASFROM opcode which takes the normal parameters of PAYGAS plus an sponsor signature. I believe this approach is preferable to CallWithSigner because it i) puts a bound on how much computation per transaction must be done to know if other transactions will become invalid and ii) this bound is configurable by clients.
This is important problem, I’m glad it’s being discussed.