Proposal to include EIP-3074 in London
SamWilsn opened this issue · 12 comments
EIP here: Sponsored Transaction Precompile
Simple Summary
Creates two new EVM instructions that authorize (via an ECDSA signature) a contract to act on behalf of an externally owned account.
Thanks for proposing @SamWilsn! I've added it to the agenda for this Friday's call, but it's already quite packed, so there is a risk we don't have time to get to it. If you'd rather not attend the entire call with the risk of your EIP not being discussed, let me know. I can add it to the call after and make sure we prioritize it then.
I don't mind attending this week regardless. The calls are always a mix of entertaining and enlightening!
It remains "optimistically scheduled", then :-)
I created a (relatively) simple example for what an invoker contract for EIP-3074 could look like:
https://gist.github.com/adietrichs/ab69fa2e505341e3744114eda98a05ab
@SamWilsn added to next call's agenda given we couldn't cover it today https://github.com/ethereum/pm/blob/master/README.md#acd-108-march-19-2021
From the ETH R&D discord:
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.
3074 Should not be included. It's still iterated on, and the semantics are very hard to overview. The possible quirks with new call types are many both on infra layer and app layer, and I think it needs more time to be fully understood.
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.
FYI, we have an issue with terms in this EIP. It does not propose any new procompile. It adds a new call instruction + one more new instruction related to this new call kind.
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.
In the interest in centralizing discussion, I've replied on the ethereum-magicians thread.
FYI, we have an issue with terms in this EIP. It does not propose any new procompile. It adds a new call instruction + one more new instruction related to this new call kind.
I updated the description of this issue to match the latest EIP. I hope that's what you're referring to?
The threat analysis document that was mentioned on today's AllCoreDevs: https://hackmd.io/@matt/BknnAnyNu
We agreed on ACD111 to not include this in London, so closing this.