Before talking about my implementation details, there is one last somewhat substantial change that I have been thinking about, namely the separation of the signature verification and the call. My motivation:
The opcode doing both seems overloaded, with 13 arguments right now
It is non-trivial to implement gas pricing that only charges for the (outer part of the) call portion if the signature is correct
In its combined form there is no native support for multiple calls from the same sponsee - they each require an additional signature verification overhead
Passing in the sponsee address, while a sensible gas saving, feels like a bit of a hack
The opcode returning two stack elements is unusual
This would effectively be saying, āthis caller can do whatever it wants from my accountā right? Iām assuming the authorization would only be valid for the call frame where AUTHORIZE was called? Presumably, any user doing this would essentially fully trust the contract it is giving permission to?
From a cleanliness and future capabilities perspective, I really like the idea. However, it means that signing tools will have significantly less information available to present the user with as to what exactly they are signing. From the signing toolās perspective, the user is just giving blanket power to a particular address.
Note: The signature would need to be over invoker.
I think that is a correct summary. Regarding the implications, I think it is important to distinguish between the two main use cases I see for this EIP:
In a trusted context (for example for significantly reducing gas usage of centralized exchanges, or for users controlling multiple addresses from a smart contract wallet and/or without the need for ETH in every account), this invoker trust assumption is not an issue, as the sponsor and the sponsee are the same person. I would expect a multitude of implementations, that all only have to pass the usual smart contract security scrutiny.
In a trustless context (mainly transaction relaying), trust into the specific invoker implementation is important. However, I think this has already been true for all of the latest revisions of the EIP, once the signed fields became minimal. I would not expect wallets to expose functionality to sign over arbitrary invokers (or if they do, word it in a ādelegate full account control to contractā way). Instead / in addtion, there can be a handful of community vetted ERCs for different flavors of relayer systems, with wallets implementing more precise native support for the specific extra hash used by the ERC. So for those ERC invokers, the wallet would not ask for full account control delegation, but instead would display the specific transaction (bundle) to be authorized, with specific information like expiry and other functionality.
Correct. Discussing this with @SamWilsn and @matt we felt like this authorizedSponsee should also not be passed along for delegate calls, to enforce all authorization-related execution to be in one place.
Correct, the signed data would remain identical to the current EIP. No need for the invoker address to be an opcode argument to AUTHORIZE though, because it would be the address of the currently executing contract.
I think that require(tx.origin != signerAddress) should be removed. Without this limitation, this EIP provides significantly more value because it would allow people to do the āapprove and callā flow with ERC20 tokens in a single transaction. In such cases, they are paying for their own gas and they shouldnāt have to go out and find a relayer and pay them extra or fund/use a second account just to get around this limitation.
Also, I donāt see any meaningful value in enshrining the require(tx.origin == signerAddress) behavior because it was already a broken protection that can be bypassed today.
I think the value for the call should be deducted from the signerās account, rather than the invokerās account. This would allow users to use this functionality to do transaction batching (i.e., execute the following series of operations in sequence) where one or more of the transactions they want to batch attaches ETH.
If there is fear that such a change would delay the launch of this EIP, then I propose we launch with require(value == 0) and then after a more careful evaluation we can remove that constraint and deduct from the signer.
I would want to see how this interacts with account abstraction before I would be comfortable moving forward with it. I concur with alexey and martin in that it is too early in the design to freeze it for implementation, which moves it out of London.
Pretty much the whole reason I started investigating this EIP was because EIP-2711 is not compatible with account abstraction. Thereās an (admittedly small) section on compatibility in EIP-3074.
In a bit more detail:
With mempool rules, we ban using AUTHCALL before PAYGAS. AUTH should be fine, as far as I can tell. After PAYGAS, an account abstraction contract behaves the same as a regular contract, and would be able to AUTHCALL to its heartās content.
There are certainly some concerns with creating an ungriefable abstract account sponsor. The AA sponsor wouldnāt be able to rely on external contracts for swapping, or token balances, or pretty much anything, but thatās no different than AA without EIP-3074.
That said, I donāt see anything that would preclude an AA contract that receives ETH or WETH deposits, and then lets you use that to pay for transactions from your EOA.
Sponsored Transaction Precompile - not to include to London - is there a way to do it without precompile (these are ugly things and should not be regarded as normal artefacts of EVM development), also consider who exactly will need it and what are the alternatives.
Weāve switched off the precompile (now two opcodes.)
As for interested parties, we have several! @stonecoldpat (who has been active on this thread) is from Infura Transactions/any.sender. Iāve had a bit of contact with OpenZeppelin about this EIP as well, though no strong endorsement (yet!)
Iāve written a document to discuss some different threat models EIP-3074 should be considered under and how they compare to EOAs and smart contract wallets today: https://hackmd.io/@matt/BknnAnyNu
EIP-191 specifies a safe format for signed messages, which already contains a subformat for messages of the type (ID || validator || payload). Could you use that rather than reinventing the wheel?
Probably my most important comments from the thread are:
Okay, so top question this is going to provoke, especially for āshould we commit to shipping this tomorrow?ā: IS IT SECURE? I believe the answer is YES, and for a simple reason:
EIP-3074 signatures always have a 0x3 prefix, which currently no Ethereum wallet will sign (at least without a warning that you may be signing everything away). For this simple reason, we can already safely say āno user can become vulnerable to this without accepting the risk.ā
Also:
Fun challenge: What other features could you implement for any account with this pattern? While these invokers all derive their power from a signature, they can have state, and are replay-strategy agnostic! You could have a cold wallet that delegates to an m-of-n multisig!
191 is just a draft while 2918 is in review and will almost certainly be included in Berlin (brining it to final). Also (probably a better discussion for 191 discussion), it is unclear to me why 191 is so prescriptive about the layout of the bytes after the version, and why the first byte is wasted on always being 0x19 instead of just having the first byte be a version (constrained to not compatible with legacy transactions).
To be fair EIP-191 has been in production for about 5 years now. I think EIP-191 is a more proper standard to use for non-tx signing and commonly supported by most wallets. We can introduce a version explicitly for this EIP so there is no change of signature collision and wallets must opt-in support. I donāt really see a downside to switching to EIP-191.
Assuming multiple protocol allow a similar invoker, it can open a gate for users to sign as many functions thereby spamming until one trx get successfully mined. Similar to opensea spam bots which keep bidding even if they dont have the equivalent assets in wallets
Someoneās gotta pay for that gas, and if the gas price is too low, the transactions wonāt propagate, so I donāt think this EIP introduces any more risk of spam than normal transactions.
