8

The big problem we all know in ethereum is, losing private key for your EOA is dangerous. If somebody steals it, you're done, all your assets are gone.

It's said EIP-4337 solves it by separation of concern, but I don't get how. For sure, if you use EIP-4337 to have a multisig account, then yes, losing your private key won't mean you're gonna lose your stuff.

But let's say we use EIP-4337, and as an account contract, we don't use multisig, but normal one, where only owner can do(withdraw/deposit) stuff. In this case, EIP-4337 really didn't solve the problem as If somebody steals private key(authentication), he can do UserOperation and take all the money that account contract has. I guess, you could say, you will develop the account contract in a way that you can't really withdraw more than 1eth per week. but if sombody has your priv key, it means you really can't do any escape plan from your account contract. Whatever you do, the stealer can do the same(since he has priv key).So, we didn't solve the problem here.

So, EIP-4337 solves the problem with mutlisig kind of account contract, where multiple private keys exist. If that's true, then you could say that without account abstraction, the current on-chain Multisig contracts(e.x gnosis) behave and solve it the same way. So what really changed for this type of situation ? I don't think anything changed. It's the same thing.

So statements that account abstraction solves the problems of losing private key means losing your assets, it's the same thing currently and will be the same way in EIP4337 since if somebody has my authentication, he can just call entry point's handleOps and it's the same thing. If you state that then account contract should contain multisig code, then I argue, it's the same thing as current multisig(gnosis).

I'm not sure why the articles say that EIP-4337 solve the above problem and I'm confused. The only thing I can see it brings is totally different thing. Which is,

  • 1.1 EOAs don't need to start paying tx fees as account contract can do it for them.
  • 1.2 We don't depend anymore on ECDSA and account contract can contain any other logic.

Now, I might argue about 1.1 . It was already achievable by meta tx. Sure relayers are replaced by bundlers, but I don't know. It seems to me the different way of solving the same problem of gasless txs.

In terms of 1.2, I completely agree.

What's your thoughts ? where do I have the gaps in my head ?

4
  • With 4337 you don't send transactions directly to the blockchain, but to the Relayer, which collects and executes the transactions on-chain. But I'm not sure how you can Auth yourself(UserOperations) by the Relayer. Can this be some oauth, webauthn, etc, or again only with the private key?
    – tenbits
    Mar 4, 2023 at 13:19
  • Well, I know you dont send it directly since I mention that it is the same idea as meta tx but different implementation. In terms of auth, it happens through signatures but the point of question is completely something else Mar 4, 2023 at 13:59
  • Right, that's why I'm also curious how is the Relayer implemented, and If it could be implemented with some other sort of useroperation signatures, or if could accept any other Auth types.
    – tenbits
    Mar 4, 2023 at 14:23
  • Account abstraction also allows for admin functions aside from multi-sig like allowing separate accounts to perform owner operations. In the event of lost keys, you could have one or more backup accounts that can sign txs on behalf of the main account so you don't lose your assets to a lost account. Compromised keys though are realistically only solvable by multi-sig though. Dec 18, 2023 at 3:53

4 Answers 4

5

You are correct, the problem is only solved by using a multisig wallet (which, on Ethereum, needs to be a smart contract wallet). So anyone claiming that ERC-4337 solves this probably means that it does so by standardizing smart contract wallets.

As you pointed out smart contract wallets like Gnosis Safe and Argent already exist, and meta-transactions already exist.

So ERC-4337 doesn't actually enable anything new. It just standardizes all of this (without changing anything at the protocol level):

  1. It standardizes the wallet contracts and makes it easier to create new ones (because most of the complexity is pushed into the global entry point contract)
  2. It standardizes how meta-transactions work by defining UserOperations, a new mempool, and paymasters.

So it didn't technically enable anything that wasn't already being done before, but by standardizing those things it might drive adoption.

And by standardizing how relayers work it allows them to be more easily decentralized.

Note that even though nothing was changed at the protocol level for Ethereum itself, L2s can experiment with making protocol-level changes that work in a similar way, e.g. zkSync Era has already built this in to the protocol.

1

Case 1 : Against Loosing keys = you don't have access to it (forget it)

EIP 4337 disassociates the signing key from the account. Which means in case of private key loss (not theft) you can use one of the recovery mechanisms defined in the account contract ( E.g you can use social recovery).

Case 1 : Against keys theft = Someone has access to your singing keys

In regard to theft case, users can add guardians to their wallets as a protection mechanism. A guardian could be a friend, or even a smart contract. This later can have the ability to adjust the withdraw limit to prevent the attacker from stealing large amount.

Also, you can add a key to your account and this key must co-sign every transaction and this second key can be managed by a service provider. This service provider based on some business rules like (daily limit or trusted Daap,etc.) would determine if a transaction is secure or not. For instance if the service provider determines that the called contract is not secure it will drop the transaction and protect you Or it may request you to authenticate using some authentication mechanisms to check if no one is abusing your account.

but if sombody has your priv key, it means you really can't do any escape plan from your account contract. Whatever you do, the stealer can do the same(since he has priv key).

The pre-mentioned mechanisms make use of non-blockchain mechanisms to carry out the transaction like 2FA or something similar, so owning only the key isn't enough.

5
  • Hi. Thanks for the answer. The key goal of this EIP(I am copying this from EIP) is “ allow users to use smart contract wallets containing arbitrary verification logic instead of EOAs as their primary account”. Now I ask if I use meta tx(opengsn) combined with multisig wallet(gnosis), dont i get the same thing as account abstraction goal that I copied Mar 4, 2023 at 18:05
  • Abstract wallet is not a new thing. Gnosis safe is a predecessor. What you have given as example is a sinlge case among many allowed by EIP-4437. EIP would allow to define a modular accounts where you have a basic contract then you can pick plugins that can add new features to your account.
    – Badr Bellaj
    Mar 4, 2023 at 18:34
  • Well, you could just add new features to multisig. Not sure how this EIP does anything differently. You still got a smart contract instead of multisig. Mar 4, 2023 at 19:26
  • opengsn+gnosis+eoa is not the same as you have the msg.sender issues in that bundle, which must be solved on the end-contract level, now the relayer may create smth similar to gnosis+eoa1 for you, own it, send tx in that context, but only with your confirmation. Your eoa2 account may work just for the partial signing. Or you may register your WebAuthn pubkey and later sign the challenges from the relayer using some hardware or software Authenticator. Not sure about the latest, but it would be great to have this possible to build on top of account abstractions.
    – tenbits
    Mar 5, 2023 at 11:38
  • well, what I meant was you can extend from gnosis multisig, in there, change msg.sender to _msgSender() that comes from OpenGSN. Then, EOA signs the message, sends it to relayer and relayer pays for it(multisig will check signature field that was signed by EOA). The same thing happens with account abstraction. You sign UserOperation, send it to miner which calls it for you. Don't see any difference. Mar 5, 2023 at 18:33
0

So statements that account abstraction solves the problems of losing private key means losing your assets

Account abstraction does not solve the problem of losing private keys, only shifts it.

If it is not your private key, it is someone else's private key.

4
  • Thanks for the answer. 1. Are my assumptions correct ? 2. What do you mean by shifting it ? Mar 4, 2023 at 16:56
  • 1. The question is too verbose and not well-written, so I do not know what particular assumption you mean 2) Someone will always control the private keys. If it is not you, then it is someone else. Social recovery or account abstraction cannot go around this fact. Mar 4, 2023 at 17:30
  • 1
    The key goal of this EIP(I am copying this from EIP) is “ allow users to use smart contract wallets containing arbitrary verification logic instead of EOAs as their primary account”. Now I ask if I use meta tx(opengsn) combined with multisig wallet(gnosis), dont i get the same thing as account abstraction goal that I copied ? Mar 4, 2023 at 17:36
  • This is correct. Account abstraction is just multisigs with less gas cost, and some other features. Mar 5, 2023 at 13:44
0

There is a fundamental misunderstanding here.

The whole idea behind a 4337 Account Abstraction is that you wont ever have a private key in the first place. Another service provider will be executing the transactions on your behalf. You will have an account with some service provider where you login with a email and password and maybe have some two factor authentication.

When they say you can recover access to your account it means you can reset your password and still keep access. Your service provider is the one who has the necessary keys to execute transactions.

2
  • 2
    It is now completely possible to do that even without 4337, just by giving a 3rd party your Private Key. Could you please describe, where the PK will be stored in this scenario and how it will work?
    – YodaDefi
    May 26, 2023 at 15:44
  • Seems like you've just gone from needing to steal private keys of lots of users to just needing to steal one master key.
    – NickJ
    Sep 23, 2023 at 4:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.