EIP-3074: AUTH and AUTHCALL opcodes

[adietrichs]

@SamWilsn

I’d like to interject to get a temperature check on only signing over invoker and nextra instead of what’s currently in the EIP. I’m leaning towards that direction, and I don’t want to waste everyone’s time reviewing something that might change.

My thoughts on this:

• I very much think this is the right thing to do. The whole point of signing over the invoker address is that the sponsee has to trust the logic of the particular invoker contract. Given that this is already a requirement, we might as well make the most out of it and get as much flexibility out of it as possible.

• One good example for this increased flexibility is the currently hard-coded mingas argument. I think it is not obvious whether it would be preferable to enforce a minimum (as mingas does) or an exact gas amount. For relayer use cases, the user might want a trusted upper limit of what he could have to pay for. If they would have to rely on the relayer logic for that upper limit anyway, why not also rely on it for the lower limit?

• To me it becomes more and more clear that the nextra argument is much more than a simple replay protection facilitator. I think nextra stands for “nonce extra”, so I would propose a name change either simply to extra or to something more expressive like commit_hash. In addition to the existing chainid, value, mingas, to, data it could also be used for enforcing interesting other restrictions, e.g. for expiring sponsored calls or for a maximum gas price. To me this is one of the main things that make this EIP so exciting…

• I assume this change would come together with moving most of the arguments from memory to the stack? I initially thought about this opcode from a “sub-transaction” perspective, where I preferred the memory / stack separation. Given that it seems clear that people prefer the “sponsored call” framing, I think this no longer applies and arguments should move to the stack. data obviously has to remain in memory.

• The one memory / stack decision I am on the fence about is the signature - I think there is a case to be made for v, r, s to remain in memory (somewhat analogous to signatures before they are sent (via calldata) to the ecrecover precompile), instead of them becoming 3 stack elements. They could either be located together with the data, or could have their own memory pointer (no length argument required).