EIP-3074 was proposed nearly two years ago. There’s been a lot of talk about it, and interest has surfaced again in potentially including it Shanghai.
In addition to potential adoption on Ethereum’s mainnet, there is also consideration from other EVM chains. I’m with Polygon, and there is potential interest in implementing 3074.
3074 should affect Solidity, giving it the opportunity to let contracts leverage the AUTH and AUTHCALL opcodes. Quilt has done the most work on 3074 to date afaik, and even implemented their own patch of Solidity, inserting an experimental pragma to enable 3074. (I’m pretty sure that patch adds auth and authcall terms to Yul.)
What would it take to get something like this enabled in Solidity proper? A big part of Account Abstraction will be prototyping contracts implementing the workflows enabled by it, which will be very difficult without Solidity support. fwiw, I think Quilt’s path of implementing the features as an experimental compiler feature is correct - most use cases rn do not need access to 3074 opcodes. Limiting the terms to Yul may be an additional consideration just to show that we are, in the parlance of the space, still very early.
Can this be considered for inclusion in Solidity? If so, how can we help, and what kind of timelines can we expect?
We’d definitely want to support it if it ends up as a part of the EVM. Both in Yul and with some high-level syntax.
Adding experimental support in the compiler is a different matter though. It depends on how likely it actually is to be added eventually. Adding new opcodes themselves is simple enough but there’s also quite a bit of added complexity in the optimizer. As long as the fate of the feature is very uncertain, we’d rather not put that complexity in the compiler.
In case of features that add new EVM opcodes, a better route would be pushing through Allow verbatim in Solidity assembly blocks #12067. That would let people easily implement helpers using new opcodes.
As for the timeline, hard to say because it largely depends on external interest in this since currently it’s not part of our roadmap. That would definitely change if the new opcodes were scheduled for Shanghai though.
That would definitely change if the new opcodes were scheduled for Shanghai though.
What about non-Ethereum EVM chains? If you’re interested in specifics, I’m with Polygon, and we’re exploring 3074 as an option. (We’re still very early in the process, but current feedback is very positive.) I’d be happy to provide any details that might be significant.
Would it help to say that while it’s experimental it wouldn’t be optimized? That wouldn’t bother me. This is for prototyping and ephemeral networks, optimizing it down for production use is not currently a consideration.
We don’t explicitly target non-Ethereum chains. It’s great if they are compatible enough with mainnet EVM features for the compiler to be usable there and we will not do anything intentionally to make it harder for them but we also don’t think it’s sustainable to maintain support in the compiler for their instruction sets if they diverge from the mainnet. We’re already considering dropping support even for some older mainnet EVM versions that are probably obsolete by now (though the blocker here is that it’s hard for us to be sure that they’re truly obsolete, without any practical use case).
What we’re fine with is adding generic features that make using the compiler with EVM on other chains possible. verbatim is an example of such a feature (it was added due to a request from Optimism by the way).
In the future we’d like to add some mechanism for defining custom opcodes with enough meta-information to make the rest of the compiler play nice with them (verbatim is a step in that direction but it’s just a black-box to the compiler). That’s what we can offer here but it’ll take some time before we get there.
Would it help to say that while it’s experimental it wouldn’t be optimized?
It would make implementation easier but still, the real issue is that we don’t want to handle these things on a per-EIP basis because with more cases like this it will accumulate too much maintenance burden and will not scale well.