Account Abstraction. Auditor's View
Tags: solidity, audit, account, abstraction
Published: 2023-09-23 12:42:46

## 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.](https://eips.ethereum.org/EIPS/eip-4337)

## 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](https://eips.ethereum.org/EIPS/eip-4337#storage-associated-with-an-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)](https://eips.ethereum.org/EIPS/eip-1167), 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.