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 excludeUserOperation
objects from abundle
if the gas limit parameter for the validation process is set too high. -
Independence of the Validation Process: The validation process for
Accounts
andPaymasters
grouped into a singlebundle
must remain independent, implying that they cannot callAccounts
associated with otherUserOperations
or access the same storage slots. This restriction ensures that the consistency of validation does not depend on the order ofUserOperation
objects within thebundle
transaction. Consequently, the usage ofBeaconProxy
is limited, andAccounts
linked to the sameBeacon
cannot be included in onebundle
. -
Restrictions on Storage Access:
Accounts
andPaymasters
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 thePaymaster
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 aThrottle
andBan
mechanism to determinePaymasters
whose validation processes fail after being included into thebundle
. In simpler terms, this targetsPaymasters
with inconsistent validation functions. If aPaymaster
repeatedly fails after being included in thebundle
(more frequently than a predefined parameter ofclient
orBundler
), theBundler
may decrease the priority of operation or even ban operations that employ thisPaymaster
for a period of time. -
Delay between UserOperationPool and Chain Mempool: The
UserOperation
object is included inUserOperationPool
before it's added within thebundle
transaction to the chain mempool. It means that between sending the operation to the mempool and including the relatedbundle
transaction in the block, a significant amount of time can pass. To mitigate late operation processing, theAccount
validation function returns avalidUntil
parameter, enablingBundlers
to avoid using outdatedUserOperation
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 mandatesBundlers
to ensure thatvalidateUserOp
method ofAccounts
andvalidatePaymasterUserOp
ofPaymasters
don't use specific opcodes (GASPRICE
,GASLIMIT
,DIFFICULTY
,TIMESTAMP
,BASEFEE
,BLOCKHASH
,NUMBER
,SELFBALANCE
,BALANCE
,ORIGIN
,GAS
,CREATE
,CREATE2
,COINBASE
,SELFDESTRUCT
). Exceptions are made forGAS
if followed by one of the call opcodes. -
Deployment Costs: Every
Account
smart contract must be deployed before utilization. If extrapolated to millions ofAccounts
, 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 onchainId
,nonce
, andmsg.sender
(which is theEntryPoint
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 multipleAccounts
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 theisContract()
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 thePaymaster
, 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 theUserOperationPool
, potentially frontrunning arbitrage opportunities. This risk can be mitigated by implementing theclient
as a trusted third party, much like the FlashBots project does, thereby guaranteeing the security of operations for both users andBundlers
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.
Top comments (0)