A case for a simpler alternative to EIP 3074

EIPs
,
41

If it’s a philosophical disagreement then it’s a pretty fundamental one. Should we make it easy for users to take risks where even if they follow all the current best practices at any given time, they may be vulnerable due to not being able to fix their past mistakes? In most other cases, users can remain safe by following best practices. With EIP 3074 they can’t, because the best practices aren’t necessarily known at the time they expose themselves to the risk.

You’re right, I don’t need to use 3074 and I might not. And despite not being a professional auditor, I’m probably a bit more qualified than the average user to assess the risk of using an invoker. But we’re not here to defend ourselves. We’re here for the users.

With Gnosis Safe, users only take a specific risk, associated with the contract itself. With EIP 3074 invokers, users take a risk that the best practices are incomplete and will change in the future. If we miss anything in the first iteration, then by the time we realize it, all past users are already at risk.

Some users may not even realize it, because they may no longer be users of that invoker and they don’t realize they’re essentially holding their assets in it. If a Gnosis Safe bug is discovered, some users will get hit, but many others will learn about it and move their funds asap. But if the best practices of selecting invokers is changed, how will users know that they need to move all their assets immediately due to some past AUTH they signed a couple of years ago?

There’s an important difference. Vitalik’s proposal is to replace all EOAs with a simple contract that emulates the behavior of the current EOA, and with an upgrade option. Users may explicitly upgrade their EOA to use a contract wallet, and since it’ll be done via a transaction rather than a signed AUTH message, it won’t be replayable on other chains so it will only affect the user’s account on the intended chain. If a user wants to start using Gnosis Safe, for example, it’ll be possible to upgrade an existing EOA to Gnosis Safe at the user’s choice. And if the user later decides to switch to Argent, then the user is no longer exposed to Gnosis Safe. There is no lasting effect and the user is free to choose at any given moment.

Will users perceive the act of signing an AUTH to an invoker as migrating their account to that invoker on all chains, now and in the future? And will they understand that they can only add contracts to their wallets but never remove or replace them?

There’s a reason why users use smart contracts rather than delegating all their power to someone else. It is also cheaper to give all your ETH to a centralized exchange and just trade there, but we like staying in control. When I send an asset to a contract, I implicitly assume that the potential damage is limited to the asset I’m currently sending to that contract. EIP 3074 makes it impossible to assume that. So you’re right, this is extremely powerful. Also too powerful, and we can get the same results with just the cost of deploying a contract when we need one.

42

If a Gnosis Safe is used as a primary account, the risk profile is equivalent to an EOA signing to an invoker. A bug in either could be exploited to take over the user’s entire account.

Users may explicitly sign a message to allow additional functionality of their wallet. It is opt-in though, just like deploying a smart contract wallet.

I recommend reading my post Validation Focused Smart Contract Wallets, as I’ve addressed how EIP-3074 is future-compatible with a world where users can revoke invokers, change wallets, etc.

43

Except that if the user then decides to switch from Gnosis Safe to Metamask, then the bug exposure disappears. With EIP 3074 the user may sign any number of invokers (whitelisted by the wallet if that’s how the wallet works), and has no way to “remove” them.

But with support for multiple invokers (roughly equivalent to adding modules to a Gnosis Safe wallet), and with no way to opt-out after opting in.

I read it, and I really like the idea of using EOF and adding a validate section. Once users have an ability to blacklist an invoker, it becomes much safer to use. And this section keeps things clean and easier to verify.

I like the validation focused wallets but EIP 3074 doesn’t mandate that, and there may be other contract wallets that don’t work the same way. It would be safer if the protocol ensures that the user has a way to opt-out of any invoker, not just with contracts that implement an opt-out method.

If we did it in the opposite order, implementing EOF and validate section first, then forking to convert all EOAs, and only then introduce EIP 3074, then it would at least allow any user to change the validate section to blacklist unwanted invokers. That would solve a lot of the risks associated with EIP 3074.

A couple of things that stood out to me when I read it:

  • When converting all EOAs, you suggested that the default validate will just check the signature. Don’t we lose replay protection then, without a nonce check? What stops someone from replaying all the user’s past transactions after this fork? Unless I misunderstood the way it works, I think the fork will have to also expose the account nonce to EVM. Even if the replay protection mechanism changes in the future, the contract will be able to prevent replays of pre-fork transactions.
  • Without including chainid in the AUTH signature, the validate section won’t save the user from cross-chain attacks. User may authorize a honest-looking invoker on one chain, not realizing the need to blacklist that invoker on all other chains.

Regardless of EIP 3074, it’s a good idea to add this infrastructure (EOF+validate). And then we may be able to add EIP 3074 safely after the EOAs are converted.

Have fun at ethcc. Too bad I can’t be there myself, I was hoping to meet in person.

44

Not sure how that is an equivalent comparison – you can switch from an EOA that signed an EIP-3074 message to an EOA that hasn’t, then you also remove the bug exposure. This is equally as costly as switching from a Gnosis Safe to an EOA.

You’re correct, there must be nonce check.

Yes, agreed. I think chainid will probably be added to the EIP in the near future, as there have been no reasonable use cases without it presented.

Ah too bad :frowning: another conference then!

45

I’m less concerned about the cost than about awareness. Users know what wallet they use, so if a vulnerability is discovered they are likely to switch. And if they switched regardless, before a vulnerability has been discovered, they don’t need to care about the security of a wallet they no longer use.

With invokers it’s different. Users must keep track of any invoker they ever used, even just once. And if one of them is deemed unsafe at some point, move everything to a new EOA. Keeping track of the wallet you use seems much easier than keeping track of all past invokers.

Users won’t do it, so it becomes the responsibility of the wallet maintainer to keep track and warn the user to switch EOA immediately if a previously-used invoker is found to be buggy or malicious. If I were a wallet maintainer, I wouldn’t want to be responsible for tracking the security of any 3rd party invoker I whitelisted, and tracking which user has signed such AUTH. I don’t know how I’d be able to reach all these users because they may be inactive for months and are still immediately vulnerable due to this past AUTH.

It might lead to wallets refusing to whitelist any 3rd party invoker, and only using their own. That would diminish the value of EIP 3074 much more than restricting the invoker to signed transactions, and actually prevent may use cases.

Another concern with needing to switch EOA due to a bug in any of the invokers previously used, is that sometimes you just can’t switch because you hold a non-transferrable asset. For example, suppose I hold tokens I received from various projects with a vesting contract. I can’t change the recipient in the vesting contract so I need to wait a few years for full vesting.

I have the same concern with Gnosis Safe but at least my exposure is limited to one contract, and it’s a proxy so I can upgrade the implementation to fix the bug in-place. If instead I used multiple invokers in the past, and then a bug is discovered in just one of them, I lose all my unvested tokens.

Hopefully devcon.