Account Abstraction. Auditor's View

Introduction

EIP-4337 offers a unique approach to Account Abstraction, effectively bypassing the need for alterations to the consensus layer. The architecture of EIP-4337 mirrors the transactions mempool functionality within a high-level system, giving the way for a more flexible and dynamic processing model. The central actors in this system are the users and the Bundlers that operate through a specialized p2p network of clients with implemented UserOperationPool.
In this setup, users send UserOperation objects to UserOperationPool. Acting as transaction builders, Bundlers listen in this mempool and combine UserOperation objects into a single bundle transaction, which is then sent to the EntryPoint smart contract. This EntryPoint smart contract serves as a processing hub, executing the UserOperation objects and deploying custom Account smart contracts implementing a specified interface.
The deployed Account smart contracts have a role that extends beyond merely the storage of assets. They handle nonces and signature validation, presenting opportunities for using custom logic in the operations process and the utilization of assets. Further enhancing the versatility of EIP-4337, the protocol enables the use of specific Paymaster actors to handle gas payments in inner transaction execution. This addition allows for customizing gas payment methods based on various conditions, such as payment in ERC-20 tokens to the Paymaster.
The overall architecture and logic of EIP-4337 have been detailed in the proposal by Vitalik Buterin et al.

Possible Ways of Integration

Integration of paymasters

The first and main part of ERC-4337 that can be used in some DeFi projects is the integrated paymaster taking care of a gas cost. It can use another way to cover gas costs (like ERC-20 tokens) or just sponsor gas prices to make the protocol more attractive.
All protocols trying to integrate a paymaster should consider DOS. If someone finds a way to sponsor their transaction without fair compensation, they can drain the paymaster’s stake. Let's assume some new ERC-20 token compensates the gas cost for any transfer. This can be exploited by an attacker transferring tokens back and forth: the paymaster will be quickly left without funds.
The paymaster can be used by DEXes (like Uniswap) to exchange ERC-20 tokens without having native tokens. If token A is exchanged for token B, the amount of A for the exchange can be decreased to the gas cost equivalent. Furthermore, ERC-20 tokens can be exchanged for wrapped native tokens immediately unwrapped and sent to the user’s account.
The important moment of such a use case is slippage. The minimum amount of B should be calculated considering gas price compensation. Incorrectly modified slippage will lead to a constant revert or can be used by MEV-bots to steal some of a user's funds.
NTF markets (like OpenSea) can give the ability to artists to mint NFTs without having native tokens. An artist or institution can pay with a bank card officially to a marketplace. After that, the protocol whitelists users in paymaster, allowing them to deploy a collection without diving into crypto, just through UI. Markets can even sponsor gas payments to help some cultural institutions or to attract more well-known artists.

Regular operations

Recurrent operations and subscriptions are other features of ERC-4337 that can add new functionalities to a DeFi project. Of course, such ability should be supported by an abstract account realization: wallet contracts should be able to validate such kind of UserOperations.
Regular investments can be used in Aave, Compound, and other lending platforms. Users may set some monthly transfer of funds to the protocol. Tokens will be constantly lent, giving profit and improving the health factor of users' debt. It’s also possible to auto-approve some money if the health factor becomes lower than some value.
It’s also possible to add a setting of orders in DEXes or other trading platforms without a preliminary funds transfer from the user's balance. Users can set some conditions when approval for some ERC-20 token is given. So, the order will be executed by trading protocol only if these conditions are met, and the user has enough balance.
It’s important to pay maximum attention to details of such regular or triggered approvals (approved amount, who can transfer tokens, and periodicity of auto-approval). It’s both the responsibility of a protocol owner and a user.

Limitations

Despite its revolutionary approach to Ethereum account management, EIP-4337 still encounters several inherent limitations. These constraints stem from various factors such as potential griefing and DoS attacks, the necessity for an isolated validation process of UserOperations, and the decentralized nature of the overall system:

• Gas Constraints in Validation Process: The design of EIP-4337 imposes limitations on the validation process. To safeguard against excessive gas consumption and potential griefing, high-cost validation algorithms cannot be implemented into Account smart contracts. Bundlers are allowed to exclude UserOperation objects from a bundle if the gas limit parameter for the validation process is set too high.
• Independence of the Validation Process: The validation process for Accounts and Paymasters grouped into a single bundle must remain independent, implying that they cannot call Accounts associated with other UserOperations or access the same storage slots. This restriction ensures that the consistency of validation does not depend on the order of UserOperation objects within the bundle transaction. Consequently, the usage of BeaconProxy is limited, and Accounts linked to the same Beacon cannot be included in one bundle.
• Restrictions on Storage Access: Accounts and Paymasters can only read the storage slots associated with their address. To reduce the possibility of DoS and griefing attacks, a staking mechanism has been introduced. If the Paymaster validation process accesses storage associated with other addresses, it must stake a specified amount of assets. This stake can be unstaked anytime after a fixed delay.
• Whitelisting of the Paymasters: The client implements a Throttle and Ban mechanism to determine Paymasters whose validation processes fail after being included into the bundle. In simpler terms, this targets Paymasters with inconsistent validation functions. If a Paymaster repeatedly fails after being included in the bundle (more frequently than a predefined parameter of client or Bundler), the Bundler may decrease the priority of operation or even ban operations that employ this Paymaster for a period of time.
• Delay between UserOperationPool and Chain Mempool: The UserOperation object is included in UserOperationPool before it's added within the bundle transaction to the chain mempool. It means that between sending the operation to the mempool and including the related bundle transaction in the block, a significant amount of time can pass. To mitigate late operation processing, the Account validation function returns a validUntil parameter, enabling Bundlers to avoid using outdated UserOperation objects.
• Opcode Restrictions: EIP-4337 requires the validation processes to be independent of block and transaction states to maintain consistency between validation simulation and execution of the bundle transaction. This restriction mandates Bundlers to ensure that validateUserOp method of Accounts and validatePaymasterUserOp of Paymasters don't use specific opcodes (GASPRICE, GASLIMIT, DIFFICULTY, TIMESTAMP, BASEFEE, BLOCKHASH, NUMBER, SELFBALANCE, BALANCE, ORIGIN, GAS, CREATE, CREATE2, COINBASE, SELFDESTRUCT). Exceptions are made for GAS if followed by one of the call opcodes.
• Deployment Costs: Every Account smart contract must be deployed before utilization. If extrapolated to millions of Accounts, the deployment costs could be significant. However, these costs can be mitigated through EIP-1167 (minimal proxy contract), which facilitates cheaper contract creation costs.
• Replication Attack Defense: To defend from replication attacks, EIP-4337 requires that UserOperation validation depend on chainId, nonce, and msg.sender (which is the EntryPoint smart contract).

Security Risks

The implementation of EIP-4337 brings several risks to the forefront. These risks relate to the potential vulnerabilities in custom signature verification methods in Account smart contracts, the potential of griefing, constraints on integration with certain projects, and the crucial need for comprehensive auditing:

• Custom Signature Verification Risks: The ability for Account smart contracts under EIP-4337 to employ custom signature verification can potentially introduce security vulnerabilities. These custom verification methods may be less secure than the standard ECDSA algorithm on the secp256k1 curve used for transaction signatures in Ethereum, leading to increased vulnerability risks.
• Griefing: Despite precautions, the potential griefing persists in EIP-4337. For instance, a malicious actor could frontrun the bundle transaction, changing the state of multiple Accounts and causing the validation process to fail after consuming a significant amount of gas.
• Project Integration Constraints: The structure of EIP-4337, where each Account is a smart contract, imposes integration constraints with projects using the isContract() modifier. This restriction essentially prohibits anything other than EOA message senders from using these projects.
• Necessity for Auditing: Given potential security vulnerabilities in the Account and the Paymaster, it's imperative that they are rigorously audited to ensure the overall system's security.
• Bundler's Extracted Value: Bundlers can replay the operations of users included in the UserOperationPool, potentially frontrunning arbitrage opportunities. This risk can be mitigated by implementing the client as a trusted third party, much like the FlashBots project does, thereby guaranteeing the security of operations for both users and Bundlers or direct block producers.

Conclusion

EIP-4337 offers a groundbreaking approach to Ethereum transaction management, offering flexibility in handling assets and gas payments. Some applications of ERC-4337 can make existing DeFi protocols more convenient and flexible. However, its implementation must be considered with a clear understanding of the inherent limitations and risks. A thoughtful balance between taking advantage of this innovative protocol and ensuring comprehensive security measures can make EIP-4337 a significant milestone in the Ethereum ecosystem.