Native fee tools

[Agusx1211]

@shazow proposed a few days ago that we could add some "native fee refund" capabilities. This may be a good idea since it is fairly hard to observe, from within a call, how much gas a Sequence operation used in total.

I do agree with the general idea, as this was a bit of a pain point when @ScreamingHawk did the 5189 integration on Sequence v2, but I am not entirely sure what is the best approach.

1. Do we do a simple gasUsed * gasPrice and support basic ERC20 token payments and ether?
2. Do we add support for 1559-like gas pricing + maybe rate to an ERC20?
3. Do we go with some other option (maybe a generic one)?

I started working on (1), but I wasn't happy with the idea, mostly because (a) we already have a lot of payload encoding and decoding code, and unfreezing that part of the spec would delay the work on the rest of Sequence v3. I am not sure if it is worth it. Additionally, finding a good "balance" on what features may be useful is a bit hard. It feels wrong to do native fee refunds WITHOUT 1559 support, but it also feels wrong to bloat the payload struct with too many things.

So I figure we can implement this using something like (3). The way I found is by leveraging delegateCall. In practice, delegateCall: true should only be used for "extending" the functionality of the wallet. This means that we don't need to be able to send "any" arbitrary calldata; we can always make the implementation on the delegateCall parse that arbitrary data. This means that we can add additional variables when delegateCall: true, variables that couldn't be realistically passed to the extension by other means. So we can pass something like startingGas, which makes it trivial to build a little extension that dynamically computes the used gas and refunds tx.origin (or any other address). I find this to be a better approach because it does not interfere with existing work, and it does not force us to decide which features we implement on the native fee refunds.

[Agusx1211]

Example of (1), how the payload struct may look like:
#19

[Agusx1211]

Example of (2), passing the required vars to delegateCall:
#20

[ScreamingHawk]

we can add additional variables when delegateCall: true, variables that couldn't be realistically passed to the extension by other means. So we can pass something like startingGas

This feels wrong. That means all uses of delegateCall will have these extra variables that weren't requested in the payload. The need to pass extra variables to support an "extension" is a smell that this needs native support. Otherwise, there would surely be other applications that need additional variables.

I would support this as a new call flag, rather than using the delegateCall flag. (Or we do this so the extra values are "hidden": #20 (comment))

[Agusx1211]

But the design space is quite large here, to make it native (even as an extra flag) we need to decide exactly what we need (and hope we don't miss). I think this is really tricky, and more so if you start to account with different L2s having different gas mechanics or quirks.

[luislls940-a11y]

👍🏻