A deep dive into the main components of ERC-4337: Account Abstraction Using Alt Mempool — Part 1
Account abstraction has been a highly desired feature within the Ethereum developer community for years, and it is seen by many as a prerequisite to the mass adoption of crypto. A new framework would pave the way for advanced wallet designs, supporting features such as multisigs, post-quantum secure signature methods, and wallet upgradeability, finally bringing the user experience of web2 applications to web3 without compromising on security.
To address these challenges, ERC-4337: Account Abstraction Using Alt Mempool was proposed by Vitalik Buterin and others. This ERC introduces a new workflow that mimics the transaction mempool’s functionality at a higher system level, through “UserOperation” objects that encapsulate intentions and verification data. Miners or “bundlers” then consolidate these operations into “bundle transactions” for Ethereum block inclusion by covering transaction costs and getting reimbursed from individual UserOperation fees.
The purpose of this article is to present a deep dive into the main components of ERC-4337: Account Abstraction Using Alt Mempool, addressing common questions, misconceptions, and security considerations. The first part of this series will cover the Bundler, and how it interacts with other components during common workflows
Pre-requisites
It is highly advised that readers have familiarity with general concepts of Account Abstraction or with the ERC-4337 draft.
Core workflows
The core workflows of the ERC-4337 can be best summarized by the picture below, taken from the proposal draft. As we can see, there are main components that interact through different functions and processes: the Bundler, the EntryPoint, the Wallet contract, and, optionally, the Paymaster.
The Bundler
The bundler is the component responsible for listening to UserOperations, packaging, and sending them as regular transactions to Ethereum nodes. This means that validators that want to accept and profit from UserOperations also have to run a new bundler software or extended version of an Ethereum client. In order to simplify this process, some infrastructure companies, such as Alchemy and Stackup, provide “bundlers as a service” solutions so that dapp developers don't have to worry about this.
As we can see above, when a user wants to use this “new way” of interacting with the blockchain, they send a UserOperation object to a Bundler, which holds it in a different mempool than the one from Ethereum nodes (hence the title “Alt Mempool”), before it is included in a block as a “Bundle transaction” (which is just another name for a regular Ethereum transaction).
In this flow, the bundler is responsible for sending and paying for the Ethereum transaction and is reimbursed through the EntryPoint contract's flow. The EntryPoint is responsible for guaranteeing that the Wallet contract has enough ether to pay for the UserOperation, or that a Paymaster has sufficient deposits.
Now let's take a look at the ERC’s reference implementation to understand how this all fits together.
Config
The bundler.config.json is a configuration file where operators can set all properties relevant to the Bundler execution. In addition to some bundler-specific configurations, it specifies the entryPoint and the beneficiary addresses. The first one is needed since the EntryPoint is expected to have new versions with updates through time (as it has already had, from the first mainnet version v0.4 to the current one v0.6). The second address is the account that will receive fees for providing their service of bundling UserOperations. This is usually (but not necessarily) the transaction signer that calls the EntryPoint to process an array of UserOps.
RPC server
Inside the BundlerServer module, the handleMethod method is responsible for dealing with RCP calls, including debug_ methods. We can see, for example, that the eth_sendUserOperation method receives two parameters, a UserOperation, and the EntryPoint address, which are then processed internally.
Alt Mempool
The addUserOp method from the MempoolManager module is responsible for adding a user operation to the Alt Mempool, which is an array of pending UserOperations inside the Bundler. We can see that it is possible to replace a previously sent UserOp with a different gas, for example. Additional logic is also in place to block a high number of actions from the same user to prevent Denial of Service attacks.
Bundling UserOperations
The createBundle method from the BundleManager module is responsible for creating a list of UserOperations that will be sent to the EntryPoint contract.
This is where storage restrictions established by the ERC are applied by the validateUserOp method from the ValidationManager module, and where paymasters’ stakes are verified as described in the “reputation system” part of the ERC.
A big challenge with an account abstraction system based solely on smart contracts is ensuring protection against DoS attacks. Making the block builder execute the whole operation can expose the system to DoS attacks, as malicious actors could send operations that appear to pay a fee but then revert after a lengthy execution. To prevent such attacks from congesting the mempool, nodes must verify an operation’s ability to pay its fee before forwarding it. In addition, UserOperations are simulated to make sure they are valid and capable of paying for their own execution, and that the same will hold true when executed on-chain. The validation is not allowed to access any information that might change between simulation and execution, such as current block time, number, hash, etc., and is only allowed to access data related to this sender address so that multiple UserOperations accessing the same storage are not all invalidated with a single state change.
After the UserOperations bundle is validated and created, the sendBundle function of the BundleManager signs the Ethereum transaction and sends it to the ethers Provider. If the transaction reverts, after having been successfully validated during the previous step, the reputation penalties are applied to prevent abuse. The hourlyCron method from the ReputationManager module then makes sure the exponential moving average is applied to throttle or ban global entities.
After the transaction is signed and included in the block, it is parsed and returned to the SDK, which can display a human-readable message to the user's wallet.
Final Thoughts
The Ethereum ecosystem continues to evolve, with ERC-4337: Account Abstraction Using Alt Mempool introducing a paradigm shift in how transactions are processed.
As we’ve delved into the intricacies of the Bundler and its interaction with other components, we hope it is now clear what is the role of this system in the account abstraction landscape.
Stay tuned for Part 2 of this series where we’ll dive deeper into the remaining components of ERC-4337 and their workflows.
