ERC-4337: Account Abstraction via Entry Point Contract specification

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

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:

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

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

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

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

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.

Yes,exactly right. :grinning:

1 Like

@yoavw , @dror
I have a question about this ERC: In a decentralized bundler network, what would be the incentive for bundlers to propagate UserOps to the rest of the bundlers in the UserOp mempool? If a bundler can collect fees for being the first to bundle UserOps and send them to the Ethereum network then I would presume it would become advantageous for a bundler to listen for incoming UserOps but not propagate them further since they can be the first to bundle the UserOps they receive.

In the normal Ethereum mempool this is not an issue because full nodes gossip amongst themselves and with block producers/validators. The full nodes are not in any competition with each other so they have no incentive to censor transactions.

But without a concept of a full-node for the proposed UserOp mempool, with bundlers in competition with each other to be the first to bundle UserOps, and with no consensus mechanism to regulate which bundler gets to create the next bundle, I would imagine that there wouldn’t be any reason or incentive for bundlers to communicate with each other.

Why do you say it is highly recommended? Is this recommendation related to 4337? If yes, I am a bit confused. I thought that 4337 actually eliminates a need for 2771 for AA because gas sponsoring takes place in another layer. 2771 is still needed for EOAs, of course.
I wonder if this statement is valid: with EIP2771 a target smart contract decides on gasless tx service provider (it defines trusted forwarder), with EIP4337 a wallet provider decides on gasless tx service (if enabled, it binds tightly or loosely to a paymaster).

The EIP 4337 spec describes UserOperation as: Like a transaction, it contains “sender”, “to”, “calldata”, “maxFeePerGas”... . However, I don’t see where the to field gets set in any of the examples. ERC-4337: Account Abstraction Using Alt Mempool.

Does this need to be encoded as an attribute within the calldata?

Hello,

I have a question about the Account Abstraction model. In the context of fully on-chain gaming, players are expected to initiate transactions. However, I’m interested in implementing a system where multiple players sign messages, which are then aggregated by a backend and uploaded to the blockchain. Ideally, users wouldn’t need to see a pop-up window each time they sign, and could set a configuration allowing them to sign messages of a specific format without permission (e.g., {from: 0x0, data: *, value: 0}). Is this possible? Thank you!

The incentive is the same as normal nodes and block-builders.
A “bundler” (a node that collects UserOperations into a transaction to be placed in the next block) has to be a block-builder (or use a direct API such as MEV-boost) to the next block.
Any attempt to put a bundle into the normal mempool would result a frontrun by another bundler.
It is true that a bundler can handle ITS OWN UserOperations, where they pay no extra fee to the bundler. This way there is no risk for someone to front-run (since there is no incentive to) - and even if someone does, it will get the UserOp on chain on the expense of this other bundler, so it doesn’t even serve as a “DoS” vector.

Since a bundler is merely a functionality of a block-builder, it carries almost the same incentive model.
The “almost” is because validation of a UserOperation is slightly more complex than a transaction: it is more expensive (in cpu and gas) and thus requires a different logic to protect the bundler from spam - but you do get paid for it when it gets submitted.

We recommend 2771 because it is good for Smart-Contracts ecosystem, not directly related to erc-4337 (or AA in general)
This is the de-facto standard for off-chain signing of data.

2771 doesn’t need an EOA, of course…
It DOES need the contract to validate the signature in the isValidSignature() method, but there is no requirement for the signature to be ECDSA, or for the signer to be an account: it can be a BLS, shnorr, zkproof, multisig or whatever signature scheme your account supports.

Yes.
In ERC-4337, the format of the inner transaction is defined by the wallet itself. We expect wallets to have the equivalent of execute(dest,value,data), but they can use different formats.
Notably, accounts are expected to have an executeBatch() method, which may carry multiple destinations and calldata

That’s not a framework issue, but a wallet issue: you want to be able to “pre-approve” the wallet to send specific transactions without a user interaction.
This in general pose a security breach, but there is a concept of “session key”: your account supports a restricted key, which is limited to specific target contracts, specific contract methods and time-span. The user creates such a key once, and let the game “manage” this key (e.g. store it in the browser’s localStorage)
The damage such a key may cause is limited - probably to the same site or game, which is probably accepted.
So even though ERC-4337 doesn’t define such session keys by itself (or any type of key, for that matter), it is possible to create such accounts which support multiple key types. I do believe some wallet implementations already support it, or intend to, as this is a key feature for blockchain gaming.

Hello guys,

Could anyone give me a hint, how the signature in user operation been generated, and how it been validated in the smart contract in details, I am quite confused on this part.

Best regards

Account abstraction in general (and ERC-4337 in particular) delegate the validation of the UserOperation (transaction) to the account contract itself.
That is, ERC-4337 does not verify the signature at all. it calls a method on the account (named validateUserOp), which should validate the struct - including the signature field.
The meaning of this signature is entirely up to the account.
It can be a single or multiple signatures, a zk proof blob, or anything else.

@mudgen add some additional thoughts (not limited to specific plugin eip,hope it’s a useful thought for all): link

How to minimize security issues caused by plugins in a contract wallet

Context:

  1. The wallet use delegatecall to implement flexible plugins.
  2. It is not allowed for hacker(stole your private key) to add malicious plugins to destroyed the storage slot before social recovery (social recovery will never be able to run if some storage slot destroyed).

Implementation suggestions:

  1. The wallet owner must have a 48-hour delay confirmation period for adding any new plugins (or can be immediately effective through joint signature by owner and guardian).
    (This prevents the wallet from being stolen by hackers and destroying the storage, causing social recovery to not run as expected.)

  2. The wallet contract needs to add a simulate(calldata) function, where calldata is all the operations that the user will execute (if key storage such as owner, guardian, etc. are modified after executing the user’s operation, the specific information that is modified should be reverted). The wallet UI side should call this function in advance before the user executes any operation, if key storage is not modified as expected, the user should be prompted to avoid the wallet storage being destroyed by contract wallet plugin’s bug.

Was there an answer to this?

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.

I was having trouble understanding this as well, since there are only 2 bullets but it talks about restrictions (2) and (3). I think when referencing restrictions and conditions, it would be nice to reference them by label, which in most cases could be done by changing unordered lists to ordered lists in the ERC.