I have an idea to enhance its functionality by introducing multi-entrypoint support. This enhancement would allow an account to accept multiple entrypoints, enabling seamless integration with various wallet platforms.
The current EIP-4337 proposal focuses on providing a standardized approach for composing Ethereum accounts and abstracting their underlying signatures and key management. However, it assumes a single entrypoint for interacting with the account. By expanding the proposal to support multiple entrypoints, we can significantly enhance its flexibility and usability across different wallet implementations.
My proposal suggests introducing a mechanism within EIP-4337 that allows an account to register and manage multiple entrypoints. This way, users can interact with the account using different wallet platforms, each utilizing its own entrypoint, while still benefiting from the underlying features provided by account abstraction.
The benefits of this enhancement include:
Improved interoperability: Supporting multiple entrypoints would foster interoperability between different wallet platforms, empowering users to choose their preferred method of interacting with the account while maintaining a consistent user experience.
Enhanced user choice: Users could access and manage the account using a wide range of wallet implementations, including hardware wallets, mobile wallets, browser extensions, and more, without needing to modify or switch their account setup.
Developer-friendly integration: Wallet developers would have the flexibility to integrate their platforms with accounts utilizing EIP-4337 more easily, expanding the adoption and support for account abstraction in the Ethereum ecosystem
I don’t understand what you achieve with multiple EntryPoint contracts.
An account trusts the EntryPoint that its execute method is only called if validateUserOp is called first (and doesn’t fail).
While it is possible for an account to support multiple EntryPoint (e.g. using require(validEntryPoints[msg.sender])), I don’t see the merit of it: There should be a single EntryPoint on the network, and the only reason to replace is the unlikely case we find a security breach , in which case wallets would like to replace it.
When an application submits a UserOperation (by calling the eth_sendUserOperation rpc call), the bundler first validate this UserOp is valid.
It does so by calling the simulateValidation() helper function, to make sure that creation, account validation and paymaster validation all succeed.
In order to protect itself (the bundler, not account), from denial of service attacks, it has to make sure this UserOp can’t interfere (invalidate) any other UserOp already in the mempool.
To do so, it performs a set of checks by tracing the above validation simulation - e.g. to make sure that opcodes that can be used for such denial of service (block number, timestamp,etc) are not used, and also that it only uses its own storage.
It will only accept UserOps that pass these validations.
If a UserOp is validated, the bundler knows it will pay, so there is no longer a possible of denial of service attack.
The executed code of the UserOp can do whatever it pleases - the UserOp is already guaranteed to pay. Just like normal transaction, the user pays even if the UserOp (or transaction) reverts.
I don’t understand what you’re trying to do: during execution, you can do whatever you like. Moving storage to another randomly-allocated location is possible - but you still need to keep (in storage) this randomly allocated storage address.
Should we include logic to validate ERC20 gas payments in the bundler, such as checking prices to optimize gas usage?
The paymaster contract will solely validate gasPrice and return the ERC20 token to tx.origin. Users have the option to set maxPriorityFeePerGas and maxFeePerGas in the userOperation to zero.
When implementing ERC20 gas payments in the bundler, it is worth considering the inclusion of additional logic to validate these payments and optimize gas usage. One approach could involve performing price checks to ensure efficient gas consumption.
Furthermore, users are provided with the flexibility to set maxPriorityFeePerGas and maxFeePerGas to zero within the userOperation section.
I’m interested in learning whether Account Abstraction will be implemented in the consensus layer in the future. I observed that EIP-4337 was favored over EIP-2938 because it avoids AA on the consensus layer. The reason for my inquiry is that I am an early solo staker who lost my mnemonic and now can’t create a withdrawal address. I’m curious if there are any upcoming EIPs that might introduce social recovery options for ETH2 addresses.
Does this mean session key will have access to all functions of AA wallet by default. Or there would be some control needs to be in place which cross checks data from userOperation while validating transaction coming to smart contract via session key
erc-4337 doesn’t define session key - a specific account implementation can define it, and it also has to define what it can do.
erc4337 only let the validation methods (of account and paymaster) declare the time-range they are valid, which is required in order to have session keys.
Note that this mechanism can be used for other purposes too. e.g. someone can create a paymaster that accepts a “coupon”, which is only valid on a specific time-range.