Account Abstraction. Auditor's View
====================

###### tags: `Research`

# Introduction
EIP-4337 proposes an innovative approach to Account Abstraction in Ethereum that doesn't require changes to the consensus layer. The architecture of EIP-4337 replicates the functionality of a transaction mempool in a high-level system, allowing for a more flexible and dynamic processing model. The main participants in this system are users and `Bundlers`, who operate through a specialized peer-to-peer network of `clients` with an implemented `UserOperationPool`.
In this setup, users submit `UserOperation` objects to the `UserOperationPool`. `Bundlers`, acting as transaction builders, monitor the mempool and combine `UserOperation` objects into a single `bundle` transaction, which is then sent to the `EntryPoint` smart contract. This `EntryPoint` contract acts as a central processing hub, executing the `UserOperation` objects and deploying custom Account smart contracts implementing a specified interface.
The deployed `Account` smart contracts go beyond asset storage; they handle nonces and signature validation, offering opportunities for custom logic in the operations process and asset utilization. To enhance the versatility of EIP-4337 further, the protocol introduces Paymaster actors, which handle gas payments during the execution of inner transactions. This addition allows for customizable gas payment methods based on various conditions, such as accepting ERC-20 tokens as payment to the `Paymaster`.
The detailed architecture and logic of EIP-4337 can be found in the proposal authored by [Vitalik Buterin et al](https://eips.ethereum.org/EIPS/eip-4337).

# Understanding the Mechanics of Account Abstraction

* User should create a `UserOperation` pseudo-transaction object and sign it. `UserOperation` is described as follows:

struct UserOperation {
    address sender,
    uint256 nonce,
    bytes initCode,
    bytes callData,
    uint256 callGasLimit,
    uint256 verificationGasLimit,
    uint256 preVerificationGas,
    uint256 maxFeePerGas,
    uint256 maxPriorityFeePerGas,
    bytes paymasterAndData,
    bytes signature
    }

The `UserOperation` structure consists of several fields that define the parameters and instructions for executing a transaction. Let's explore each field and its significance:

`sender`
This field indicates the address of the smart contract wallet initiating the transaction;
`nonce`
The `nonce` acts as a security measure against replay attacks. It serves as a salt during the creation of a user account to ensure uniqueness;
`initCode`
In case of a first-time transaction, the `initCode` is used to deploy the smart contract wallet. A Factory contract, introduced by smart contract developers, utilizes this code;
`callData`
The `callData` field contains the data to be executed by the smart contract wallet;
`callGasLimit`
This field sets the gas limit for the execution process within the smart contract wallet;
`verificationGasLimit`
The `verificationGasLimit` specifies the gas limit for the `UserOperation` verification process, performed by an `EntryPoint` contract;
`preVerificationGas`
This fee compensates the bundler for their services;
maxFeePerGas and `maxPriorityFeePerGas`
These values follow the `EIP-1559` standard and define the maximum gas price for the transaction;
`paymasterAndData`
This field contains the `Paymaster` contract address and specific data required for verification and validation on the `Paymaster` side;
`signature`
Together with the `nonce`, the `signature` ensures the legitimacy of the `UserOperation`. It verifies that it was created by an authorized user.

`UserOpeartion` is sent to a specific mempool which is used only for the such type of objects (using a `eth_sendUserOp` call). `Bundlers` watch that mempool, verify `UserOperations` objects using public functions of `EntryPoint` contract, then pack `UserOperations` into a transaction (it is a call to the `EntryPoint` contract with a `UserOperation[]` array) to be included in a block (which can be proposed by a bundler if they act as a block builder).

If `initCode` is set in a `UserOperation` object, then `EntryPoint` contract calls a `Factory` contract with that initCode and the created `Account` contract wallet address is returned. `Factory` uses `CREATE2` opcode to create a user wallet. `nonce` is used as a salt (which is equal to 0 in most cases as it is a first tx with a `UserOperation`). `CREATE2` is used to produce the same address for wallets on different networks as the `EntryPoint` is persistent across other networks.

Then, `UserOperation` is checked within an Account contract, which confirms that the call originates from `EntryPoint`, checks nonce provided in `UserOperation`, validates the provided signature and calls a `Paymaster` to prefund a tx (if requested). `eth-infinitism `implementation uses `OpenZeppelin` ECDSA `recover` function to get signer address out of `UserOperation` structure hash

bytes32 hash = userOpHash.toEthSignedMessageHash();
if (owner != hash.recover(userOp.signature))
    return SIG_VALIDATION_FAILED;

where `owner` is the users’ address.

In cases where `BLS` account signatures are implemented, the user's smart contract wallet must include a `getBlsPublicKey()` function. `UserOperation` structure is converted into a verifiable message. Then retrieved public key, message and signature are passed to the signature verification function.
* `Paymaster` allows users to “outsource” gas payment by providing an ERC-20 token allowance instead of paying with the native network currency. The `Paymaster` calculates the transaction price in the provided tokens, determines if a refund is necessary, and checks if the given allowance is sufficient. Notably, `eth-infinitism` updates the token price towards the end of `UserOperation` execution. If token price decreased since the previous fetch, a negative refund is applied.The OracleHelper contract in the `eth-infinitism` implementation includes a priceUpdateThreshold to determine when a price update is needed.
* After passing all checks, including logic checks and gas expenditure verification, the `callData` provided is executed through a call from the `EntryPoint` to the user's `Account` contract wallet. The Account contract then performs another call to the desired destination with the specified calldata.

# Possible Ways of Integration
## Integration of paymasters
In ERC-4337, the integrated paymaster is a crucial component for DeFi projects as it handles the gas costs involved. It offers different methods to cover these costs, such as using ERC-20 tokens or sponsoring the gas prices directly, which enhances the attractiveness of the protocol.

When integrating a paymaster, it is important for all protocols to consider the risk of Denial-of-Service (DOS) attacks. If someone discovers a way to sponsor their transactions without providing fair compensation, they can deplete the paymaster's stake. To illustrate, let's consider a scenario where a new ERC-20 token compensates for the gas cost of any transfer. An attacker could exploit this by repeatedly transferring tokens back and forth, quickly draining the paymaster's funds.

Paymasters have utility in decentralized exchanges (DEXes) like Uniswap, enabling the exchange of ERC-20 tokens without requiring native tokens. For example, when exchanging token A for token B, the amount of token A allocated for the trade can be reduced to account for the equivalent gas cost. Additionally, ERC-20 tokens can be exchanged for wrapped native tokens, which are then immediately unwrapped and sent to the user's account.
In this use case, it is crucial to consider slippage. The calculation of the minimum amount of token B should take into account gas price compensation. Incorrect adjustments to the slippage mechanism can result in constant transaction failures or potential exploitation by MEV-bots seeking to steal a user's funds.
Furthermore, NFT markets like OpenSea can leverage paymasters to enable artists to mint NFTs without requiring native tokens. Artists or institutions can make payments through traditional means, such as bank cards on the marketplace. Subsequently, the protocol whitelists these users in the paymaster, allowing them to deploy their collections without needing in-depth knowledge of cryptocurrency, simply by utilizing a user-friendly interface. Moreover, markets can even sponsor gas payments to support cultural institutions or attract renowned artists, further enhancing the ecosystem.

## Regular operations
ERC-4337 introduces additional functionalities like recurrent operations and subscriptions, which can bring new features to DeFi projects. However, implementing these capabilities requires support from an abstract account realization where wallet contracts can validate such `UserOperations`.
One application of recurrent operations is in lending platforms like Aave and Compound. Users can set up regular transfers of funds to the protocol, allowing their tokens to be continuously lent out. This generates profits and improves the health factor of users' debt. Additionally, users can auto-approve a specific amount of funds if the health factor falls below a certain threshold.
Another use case is the ability to set orders on decentralized exchanges (DEXes) or other trading platforms without initially transferring funds from the user's balance. Users can establish conditions for approval of an ERC-20 token. The trading protocol will execute the order only if these conditions are met and the user has sufficient balance.
When implementing recurrent or triggered approvals, it is crucial to pay close attention to various details such as the approved amount, authorized transferrs, and the periodicity of auto-approvals. Both the protocol owner and the user share the responsibility of ensuring these settings are carefully defined and managed.

# 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 the 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 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 into `UserOperationPool` before it's added within `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 the significant amount of time can pass. To mitigate late operation processing, `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 the 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
ERC-4337 presents an innovative solution for managing transactions on the Ethereum network, allowing for more flexibility in handling assets and gas payments. This protocol has the potential to enhance existing DeFi protocols, making them more convenient and adaptable. However, it is crucial to approach its implementation with careful consideration of the associated limitations and risks. Striking a thoughtful balance between leveraging the advantages of ERC-4337 and implementing robust security measures will be key in establishing it as a significant milestone within the Ethereum ecosystem.