I don’t understand, why rely on some future (weird?) state where wallets can perform 2 signatures at once, instead of designing the EIP to work well with one signature?
No wallet currently supports performing EIP-7702 signatures so it’s not like there’s some existing thing we can rely on.
If you think the idea of signing two messages in one user interaction is a bad idea please share the reasons for that. I’m not sure it’s a good idea, I’m just pointing out that it’s a possibility, and that support for delegations will have to built out pretty much from scratch so this kind of thing can be added at this stage.
I think signing 2 messages at once is very hard to explain to the user in a way that is also safe. If you make it too easy to sign multiple things at once, that will be abused to trick users into signing things they have no idea about. And to make it safe you need a way to convince the wallet its okay while explaining to the user what they are doing and why. It is far superior in my opinion to map signatures to meaningful interactions for users, there’s no reason to require 2 signatures when 1 would do (and be safer).
Why is it safer? See my message above, but the first signature is generally required to over-provision trust in the current model to the code being delegated to. Followed by a second signature which might be more limited in scope. But because it is independent, who knows if it will even be used. How does the user express that a permission should only be granted transiently? They pretty much can’t with this 2 signature model.
The only way this can be abused is if a wallet decides to take advantage of their users. But no protocol can people from that type of threat.
EIP-7702 delegations are unlike other signatures. They deal with the permissions of your account. We’re not proposing to make it easier to sign many arbitrary things at once. Just a particular special case where peculiarities of the protocol necessitate two signatures in conjunction to achieve a single goal.
A pretty explicit goal of EIP-7702 is to not support transient operations. This has been discussed a lot over the past year, but essentially: wallets are not transient devices and EIP-7702 is designed to support their proliferation.
Also: we had a version that worked nicely for one signature, it was EIP-3074 
what we’ve ended up with in EIP-7702 is the result of a lot back and forth with core devs, the community, wallet devs, and more.
It has it’s trade offs, but I don’t think anything fatal.
I think this is probably the key point of contention. Why is it an explicit goal of EIP-7702 not to support transient operations? Wallets may not be transient devices, and the design may support the proliferation of wallets, but I don’t see why this has to be the exclusive goal of the EIP. In my opinion, it is at least as valid to also support and open up the features of batching and gasless transactions to applications. I don’t see what’s the point of excluding these use cases which IMHO are lower hanging and safer fruit (for reasons previously stated, but which I am happy to elaborate on, if needed)?
I don’t understand, this is already enabled by this EIP, in combination with others like EIP-5792 and ERC-4337.
Perhaps you could explain to me how a user with an EOA could accomplish a batched/gasless transaction (of restricted scope) coming from an app with one signature using the combination of these EIPs? I don’t really think it is possible (not to mention the fact that ERC-4337 is highly suboptimal in other dimensions)
The dapp would just use the wallet RPC method like EIP-5792 has defined wallet_sendCalls and the wallet would create a signature committing to both calls. It’s wallet defined how that looks / how it gets on chain. ERC-4337’s userOps is one way, but you can implement however you desire.
So this still results in multiple signatures on-chain, right?
I guess I’ve asked this elsewhere, but to make sure I understand your vision, it seems that for apps to be able to use this, the idea is to wait for thick wallet implementation of EIP-7702 which includes a contract backend, and then for potential convergence on an app layer protocol, and also adoption by users by whichever few wallets manage to do all this? As opposed to the alternative of making EIP-7702 app friendly/safer (allowing competition/iteration on usage of the standard), and only requiring relatively simple thin wallet implementations to support?
Converting your EOA to a smart contract wallet is a one-time operation which requires a signature. That signature cannot also commit to an operation you wish to perform so you need to also make a signature over that operation. Other than the one-time setup, all operations can be bundled with a single signature.
Because this is give full access of you EOA to the smart contract code, it’s not something that should be exposed to dapps. There should be a module protocol built on top that can reason about permissions.
I think this is exactly the problem with the EIP as is. It could be such that you wouldn’t be required to give full access over your EOA to the smart contract, that a single signature in total could be used to perform an operation without compromise, and that would be more secure for users and better for applications being built on Ethereum.
I understand you have an issue with this aspect of the EIP. There were other proposals like what you mentioned and they were discarded in favor of this. At this point, this is what client teams and the community have decided to pursue.
1 Like
I’m trying to understand the reasons for that. The only dimension I can see that this might be better is for wallet implementors to make other parties more beholden to them. I would like to know what I am missing, or why the better/more secure experience for users and applications is being foregone? AFAICT I am not the only one concerned about this so I think its a bit presumptive that you speak for the community, and I think it is reasonable for me to ask at this point at least for the justifications before the community makes a potentially costly mistake. This EIP will have an impact for many years to come.
As far as things that were moved away from, perhaps you mean EIP-3074? If so, I think these properties could still be achieved with something closer to EIP-7702, and its not clear to me where those options have been discussed or what the conclusions were.
If you have a proposal for how to modify 7702, I will be interested to hear it. But please understand, you are only just now engaging in the design discussion of an EIP which has been intensely discussed throughout the entire year. What is in the EIP now is the culmination of many different perspectives and preferences. Everyone has sacrificed something they care about to get this EIP over the line and Prague.
In particular, I have stopped pursing the ability you seem to be describing above: a single signature (for EOAs) to perform an operation without compromise. EIP-3074 did provide this. However, many had concerns about it and felt it would create two tracks of account abstraction. What is demanded is that EOAs and smart contract wallets have as similar an experience as we can provide. This is how we got to 7702.
Even the first version of 7702 was closer to 3074 and probably provided what you desire. However there was fierce arguments about revocation which is why we ultimately decided to enshrine code via the delegation designator.
So - please review this thread and the future of EOA breakout recordings to understand why we have ended up on this design. If you have a proposal for improving 7702, feel free to share it with us.
2 Likes
Thanks for the pointer, I will work on catching up on all those sessions. I would just point out that although I’ve been trying to follow the discussion for a while now, its actually quite difficult to participate in the process. I wasn’t aware of these breakout sessions until you just mentioned them, I think its the first time they came up on this thread.
I have been excited about 3074 and 7702 since first hearing about them, and I appreciate the hard work you and others have put in this far (even moreso now as I listen to these calls). I know this has been a long road, but from my perspective if the current proposal is finalized, it will result in a much longer time until apps are able to benefit (if ever), and so even taking a little longer now to fix is still a much better outcome.
I also experienced a bit of a Mandela effect as I did recall when first reading the spec that it seemed to have this property (single signatures, usable by apps), but in recent readings it seemed to have morphed into something else. Now I see that this changed in July. It’s still not clear to me why the EIP was changed not to revert the delegation back at the end of the transaction, but I still have a few more breakout sessions to go, so perhaps it will become clearer when I’m through.
As for how to modify 7702, my naive proposal would be to simply add a boolean transient flag to the authorization tuple that is signed over and determines whether the delegation remains or is cleared after processing each one. I understand now from the breakout sessions that this is also how @vbuterin was thinking about it early on, which reassures me that it may not be a crazy idea.
I would also possibly suggest considering an opaque bytes payload to each tuple, though I understand that may be even more controversial. This would allow the same signature to be included in the calldata itself and encode a potential operation. However, in the context of a transient operation this isn’t really necessary, as the contract being executed can have the assurance that if it is being run, it must be getting actively delegated to by its EOA owner. Having it would certainly increase the design space though, and I don’t recall who said it but I agree that increased design space would be preferable now to allow for potential UX improvements.
I agree that we as core devs don’t do the best job surfacing why every decision has been made. It’s been on my todo list for a while to beef up 7702’s rationale, but haven’t had a chance to do it yet.
We basically were at an impasse where one side felt that the ephemeral / temporary delegations had to be constrained with a revocation mechanism and I + others felt this significantly nerfed the EIP’s power because you wouldn’t be able to set and forget social recovery schemes.
Also, setting code temporary increases the likelihood of users doing simple batch scripting instead of using smart contract wallet like primitives.
We figured out the at writing the address the user wants to delegate to actually solves revocation pretty nicely because the EOA can just update the code they delegate to at anytime and it let’s users have a delegation permanently if they choose.
We could extend the design to add back some ephemerality or additional logic for atomically handling EOA calls, but we also need to balance the complexity of the change to the protocol. EIP-7702 is relatively simple to implement at this moment, but once you start adding new ways to instantiate EVM calls the complexity grows quickly. Plus we’re trying to reduce the number of call sites that can instantiate EVM execution because testing each of them every time there is an EVM change to ensure they are initialized correctly is very burdensome.
So as I mentioned - this adds the ability for EOAs to do scripting-like tx execution and we’ve actively decided that this detracts from main goal of getting users to use smart contract wallets.
This one has been proposed by @dror before. My response has consistently been that this only solves the “dual signature problem”, but in a hacky way. You still need to provide the signature to the system twice - which feels only like a half solution. What you really want is to add an opcode which can read the opaque data / hash from the authorization so it is already authenticated in some way.
–
At the end of the day, some people think the two signatures is a problem and others don’t. Since we didn’t come up with a great solution that allows just one signature, I think what we have is the best thing right now. Maybe we’ll come up with something in the future that can amend the current functionality.
If the current design hinders adoption by dapps, I think they will only be doing work that they probably need to do anyways to properly support smart contract wallets. This is the goal anyways - not minimal integration work by dapps.
Thanks for the explanations.
Allowing for either ephemeral or permanent via flag would allow for both. I actually think the current revocation mechanism is not very robust, which is one reason I think having the transient flag is important. Imagine trying to achieve ephemerality with the current system, providing one tuple to set the delegation and another to clear it. A malicious front-runner could drop the second tuple, thus leaving it delegated until another transaction with a single auth tuple is created and used to fix it. Thus this just becomes an anti-pattern people trying to achieve ephemerality will be mistakenly led into because there is no real way to do it. I don’t really see why adding the transient option would necessarily lead to additional call sites for EVM execution.
This is the real root issue in my opinion. This is problematic, because the stated motivation of the EIP says:
There is a lot of interest in adding short-term functionality improvements to EOAs, increasing the usability of applications and in some cases allowing improved security.
It goes on to mention the 3 specific applications of batching, sponsorship, and privilege de-escalation.
But none of these are the actual motivation! If they were, I think we would be trying to find the best way to support them. The actual motivation is apparently to get people to permanently migrate to smart contract wallets, and so I think at best the EIP is being presented in a very misleading way.
I agree there is something hacky about recovering the same signature twice, but to me its just as hacky (if not worse) to instead require a second different signature to be recovered by the application. I will make a different post about this topic though, since I think its actually the secondary issue here.
I feel like its being under-estimated how little the current solution provides to dapps that want to achieve the stated goals of this EIP of batching, permissionless, and privilege de-escalation in the short-term. The EIP seems to actually go out of its way to come across as not taking a stance on endgame account abstraction, but that does appear disingenuous at this point.
I expect its going to take many more years, at least, to be able to write an app that portably and reliably gets the benefits the EIP says it is trying to provide. In the current proposal, the bar for implementing a wallet is going to be much higher, and implementations will necessarily have to be much thicker. There will be more temptation to build a (bad) wallet, since that is the only way to control the transactions in the way that applications will want to. Further, there will almost certainly be an explosion in diversity of how this limited set of wallets expose these features to applications, and applications will have to try and build towards all of them to support users (likely therefore supporting each in a worse way). My fear is we are leading to a long-term “wallet wars” situation akin to the browser wars, that is likely to provide net negative value to users.
Again, I appreciate all the hard and thoughtful work you and others have already put into this. But I would be remiss not raise my concerns at this point since I think there’s still an opportunity to avoid that path, even if others have already raised similar concerns/proposals in the past.
Like I said, it is a design goal to not allow users to do tx scripts. So the flag approach doesn’t make much sense to me.
Maybe the text of the EIP can be improved, but I do think it is fairly clear about the end state of AA - smart contract wallets. It tries to abstract enough to allow many different visions there to flourish. I think you’re conflating app level standards needed in this end state with what primitives the protocol provides.
I disagree. There are many teams who already have projects showcasing the functionality of 7702. You can just see the Ithica experiments. But there are many others.
Appreciate your feedback. If you feel strongly about this, the only way to change is find support among wallet teams who will be implementing this. As far as I can tell, there is buy-in for the current version of 7702.