ERC-4337: Account Abstraction via Entry Point Contract specification

ERCs
62

As I understand it, the purpose of the approval model is to be able to submit a single transaction which does multiple actions at once, in an atomic transaction.
While it solves the on-chain problem (atomic transaction) it is still a nuisance for the user (which has to manually approve all operations)

This is a “best practice” when using an EOA, which has no other way to approve transactions.

When working with a wallet contract, the solution is different: A wallet contract can have an “executeBatch” , which trigger a sequence operations from the contract to external entities.
The contract owner approve once this batch, and the contract execute it all.

This way, we solve both the on-chain (single-transaction) and off-chain (single approval).

Yes, it comes with a cost (using contract account).
I don’t think that batching by itself is a reason for using wallet contract, but it comes with all other benefits of account-abstraction (authorization, security, gas abstraction etc)

63

It seems you and I use the term “approval model” to refer to two different things.

What I mean when using “approval model” I mean that

  • Account Alice wants to approve an action, e.g. transfer 1 units of her ERC20 to Account Charlie
  • Account Bob gets Alice’s approval and go ahead to execute the execution on Alice’s behalf.

The modeling of this process is what I refer to as “Approval Model”.

Currently, without ERC-4337 and ERC-5453, user would probably need to do something like

  • Alice: call ERC20.approve(bob, 1);
  • Bob: then call ERC20.transferFrom(alice, charlie, 1);

The alternative is to use ERC-2612

  • Alice: sign an approval with ERC-2612 and send digital signature off-chain to Bob
  • Bob: call ERC2612.permit(alice, bob, 1, tomorrow, v, r, s)
  • Bob: then call ERC20.transferFrom(alice, charlie, 1);

With ERC-5453

  • Alice: sign an approval with ERC-5453 and send digital signature off-chain to Bob
  • Bob: call ERC20.transferFrom(alice, charlie, 1, endorsement); (ERC20 needs to be extended but ERC721 supports this)

The account approving an action can be different from the account executing an action, is what I am trying to discuss this.

64

Perhaps related to delegatable from @danfinlay, and this thread with Yoav considering 4337 compatibility.

1 Like
65

Thank you, that seems quite solving the same problem with two different approach, let me take a look.

66

Yes. it’s in that space. Took slightly different approach. Will chat with Dan and work out a summary of different and see if we can collaborate to get some solution out.

2 Likes
67

Looking forward to chatting, it does look like you’ve started designing the same thing, I love that! There are surely lots of ways to improve it.

I recently think I made a breakthrough for how Delegatable-4337 could be simply achieved:

I think you could use this branch of Delegatable that adds support for EIP-1271 signatures from contract accounts, and just normalize that all 4337 accounts also implement EIP-1271.

At that point, you get half the benefit: Even 4337 accounts (and contract accounts) can use any Delegatable contract.

Additionally, if the account contract itself also inherits Delegatable, then it could also delegate its own ability to do anything (and so delegate capabilities from contracts that do not themselves inherit from Delegatable).

3 Likes
68

Surprised the draft does not yet present or discuss adjusted eth_sign and eth_signTypedData RPC endpoints that allow AA wallets to also return the necessary initCode so that “sign in with web3” applications can validate the ERC-1271 signatures of undeployed AA wallets, by simulating the creation first based on the initCode data.

Without this AA wallet users would not be able to interact with certain applications until their wallets have been deployed on-chain.

ERC-4337 already allows undeployed AA wallets to receive funds by requiring factories to use CREATE2 for their creation, would be great if the standard also allowed AA wallets to interact with signature-gated frontends before they’re deployed on-chain.

69

The Account is a contract, and thus can’t sign. it can VERIFY signatures, if it supports ERC1271, that is, exports the isValidSignature() method.
The eth_sign and eth_signTypedData are not implemented by the node, but by the wallet. This ERC defines the contracts and protocol, and the validation/authorization of the wallets, not anything that is done during execution.
Even ERC-2771 itself is not mandated by ERC-4337 (though of course, it is highly recommended)

An ERC-4337 wallet should support the above RPC calls. Note that it uses the signer to sign it, not the account itself (again, because the account is a contract, and can’t sign)
Note that ERC-4337 doesn’t even require the signer to be an ECDSA signature. In such cases, the meaning of “signing” might be completely different.

70

You completely missed my point. I wasn’t implying that smart contract wallets are able to somehow sign in the traditional notion. Furthermore ERC-1271 already allows wallets to implement any signature scheme, providing the necessary abstraction by allowing for a bytes signature parameter with no defined length limit.

What I was saying is that I believe the ERC-4337 standard should specify how wallets are to implement the eth_sign and eth_signTypedData RPC endpoints to return the necessary initCode so that applications can VERIFY “signatures” from ERC-4337 without them having to be deployed on-chain yet.

71

Petition to change the nomenclature from “Account Abstraction” to “Smart Account”

  • Fits in with “smart contract”: run code in your contract
  • better description for what it actually is at the end of the day: run code in your account
  • will lead to much less blind men touching an elephant effect
2 Likes
72

Hi authors of EIP-4337
This is Joey from Fairyproof. We are a Web3.0 security company.

Thank you for this well-written proposal - It is very well-documented and well-covered.

The technical team at Fairyproof has analyzed EIP-4337 and raised some security checkpoints that we would like to share with you.

You can check out on the details here: Security Checkpoints for EIP-4337 Based Account Abstraction Implementation | Fairyproof Tech | Medium

We hope you can take a look at these considerations and share your thoughts with us :blush:
Thank you

73

PEEPanEIP #100: ERC-4337: Account Abstraction Using Alt Mempool with @yoavw @dror Shahaf & Tom

1 Like
74

Greetings friends,
We have launched an initiative to promote the integration of EIP1271 into more dApps as it is vital for account abstraction.

1 Like
75

Hi all,
This is Peter from Hexlink, our team is working on an extension of EIP-4337 to the community:

EIP-6662: AA Account Metadata for Authentication which stores authentication data on-chain to support a more user-friendly authentication model. Would love to hear feedback from this community of EIP-4337 contributors :grinning:

Thank you all :blush:

76

Hi, this is Pablo from PlanckerDAO. We are recently organizing a joint reading of eip4337. When we got to the part on bundling, we were confused about the sentences “In practice, restrictions (2) and (3)” and “If any of the three conditions is violated” because we didn’t find the numbered restrictions and conditions above.

One of us sunnyishere (Github) discovered another early draft of eip4337 that provides clearer explains of “In practice, restrictions (2) and (3)” and "If any of the three conditions is violated. " We would like to ask if they are parts of the legacy documentation and should be updated. @yoavw @vbuterin

77

Yes, we added EIP-2535 at some stage in the implementation of the first pre-alpha version, but then removed EIP-2535 for the following reasons.

  1. If FacetCut is restricted to view/pure only, the resulting lift is limited
  2. if arbitrary FacetCut is allowed because of the use of delegatecall, then FacetCut can destroy the institution of storage (e.g. a wrong or malicious FacetCut can modify some storage that he should not be allowed)

We are also thinking about how to securely add dynamic plug-in capabilities to a self-custody wallet,

for example:

  1. a centralized auditing institution is required, making it necessary for users to wait more than 2 days to use plugins that are not audited by the institution
    (to prevent ownerkey theft while the internal storage slot has been modified by FacetCut and can no longer be used for social recovery.)
  2. or use segregated storage slot (split by different addresses, but this leads to higher costs)

wait for your advice

78

It is really great you are working on this.

  1. If FacetCut is restricted to view/pure only, the resulting lift is limited

FacetCut is a struct defined in the EIP-2535 standard. Saying it is view/pure only does not make sense because it is just a struct definition. Only functions can be view/pure so I don’t really understand what you are saying here. Please clarify.

  1. if arbitrary FacetCut is allowed because of the use of delegatecall, then FacetCut can destroy the institution of storage (e.g. a wrong or malicious FacetCut can modify some storage that he should not be allowed)

I think you are referring to arbitrarily making upgrades – adding/replacing/removing functions. Is that right? Of course don’t make it completely arbitrary. Only allow the owner of a diamond to upgrade their diamond. This is the same way contracts work now. People decide to trust or not the contracts that exist on ethereum. The facets of diamonds don’t have to be any different. Of course audited registries of facets can be created to help people decide what to use and trust.

You mentioned that the above reasons were why you removed EIP-2535 but it is doubtful to me that those reasons are related to the compliance with the standard. For example diamonds can be non-upgradeable or immutable and still be compliant diamonds. See this article about compliance: Compliance with EIP-2535 Diamonds Standard

1 Like
80

Thanks, I should have understood what you meant :grinning:

I would like to add background information here, our project has social recovery, meaning that even if the private key of the owner within the wallet is stolen, the user can reset the owner through a social recovery process, so we need to make sure that even if the owner is owned by someone else, no one else should destroy any storage structure within the contract for a certain period of time (e.g. 2 days) (This may cause a breakdown in social recovery).
If the owner is allowed to add FacetCut at will, it is possible that the user will never be able to use Social Recovery to retrieve his wallet.

“If FacetCut is restricted to view/pure only, the resulting lift is limited”, I originally meant to allow the user to add FacetCut that not call sstore opcode in any way is relatively safe.

Yes, for an audited FacetCut, I think users should be able to add it at any time.And maybe we should set a 2days delay in effect (so that in extreme cases the user can do social recovery) When users want to add unaudited FacetCut

and we still want to add support for the EIP2535, which was previously removed only because we wanted to find a balance between security and ease of use

81

Hey, okay. To clarify for other people seeing this, “add FacetCut” just means being able to add/remove/replace external functions in a diamond right?

Yes, for an audited FacetCut, I think users should be able to add it at any time.And maybe we should set a 2days delay in effect (so that in extreme cases the user can do social recovery) When users want to add unaudited FacetCut

Your plan there makes sense to me.

82

Yes,exactly right. :grinning:

1 Like