How infrastructure supports billions of users through account abstraction

Author: BlockPI Network

Whether in a bull market or a bear market, the Ethereum ecosystem has been continuously building and self-optimizing. Among these developments, Account Abstraction (AA) has made significant progress in recent years and has permeated various parts of the Ethereum ecosystem, including applications, infrastructure, users, and developers. We can foresee that the large-scale adoption of AA will overall lower the barriers to blockchain usage and bring the user experience of web2 into the web3 industry.

To seize the opportunity of the AA market with potential value in the billions of dollars, BlockPI plans to integrate AA into its infrastructure services. By innovating in the field of AA, BlockPI is committed to providing AA users with a more convenient and efficient way to interact with blockchain contract wallet accounts and hopes to become a leader in the industry.

In this article, the BlockPI team will delve into their understanding of AA and share their thoughts from the perspective of an infrastructure service provider.

EOA and Contract Wallets

Whether in a bull market or a bear market, the Ethereum ecosystem has been continuously building and self-optimizing. Among these developments, Account Abstraction (AA) has made significant progress in recent years and has permeated various parts of the Ethereum ecosystem, including applications, infrastructure, users, and developers. We can foresee that the large-scale adoption of AA will overall lower the barriers to blockchain usage and bring the user experience of web2 into the web3 industry.

To seize the opportunity of the AA market with potential value in the billions of dollars, BlockPI plans to integrate AA into its infrastructure services. By innovating in the field of AA, BlockPI is committed to providing AA users with a more convenient and efficient way to interact with blockchain contract wallet accounts and hopes to become a leader in the industry.

In this article, the BlockPI team will delve into their understanding of AA and share their thoughts from the perspective of an infrastructure service provider.

1. EIP-86

Originally proposed by Vitalik Buterin in 2017. This proposal implements a series of changes aimed at "abstracting" signature verification and nonce checks, allowing users to create "account contracts" that can execute arbitrary signature/nonce checks.

2. EIP-2938

Proposed in 2020. The title of this EIP is Account Abstraction. The concept of AA is well described in this EIP. It introduces a new transaction type, the AA transaction. The transaction is initiated by an EntryPoint address and calls the AA contract wallet. EIP-2938 provides a unified specification and formally introduces AA account abstraction into Ethereum consensus. Specifically, it introduces two new opcodes, three global variables, and a different payload structure into Ethereum consensus.

3. EIP-3074

Proposed in 2020. This EIP introduces two EVM instructions, AUTH and AUTHCALL. AUTH authorizes setting environment variables based on ECDSA signatures. AUTHCALL sends calls as an authorized account. This allows smart contracts to send transactions on behalf of EOAs. However, this is still not a perfect solution for AA. During the authorization transaction process, EIP-3074 has certain limitations in native value transfer. Additionally, if a user loses access to their EOA, they will still be unable to recover their assets. If a private key is compromised, the user will need to transfer all assets to a new account.

Due to the need for changes at the consensus layer or the proposals being insufficiently comprehensive, the above proposals have not been formally incorporated into the Ethereum protocol. Therefore, the Ethereum community continues to explore how to introduce AA into the Ethereum protocol without changing the consensus, ultimately proposing EIP-4337.

4. ERC - 4337

EIP-4337 was initially proposed in September 2021 and was authorized as ERC-4337 in March 2023. Its authors include Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, Dror Tirosh, Shahaf Nacson, and Tjaden Hess.

EIP-4337 is a disruptive proposal that introduces AA without changing the core Ethereum protocol. EIP-4337 ultimately became the ERC-4337 standard, which builders can use to implement their own smart contract wallets. At the same time, this standard introduces additional infrastructure, including "Bundlers" and "UserOperation mempool." In this way, it effectively replicates a similar-functioning Ethereum mempool on top of the blockchain system. Users no longer submit single transactions but rather UserOperation. Multiple UserOperations can be bundled into a single transaction and sent to Ethereum.

Key Roles and Definitions of ERC-4337

UserOperation: Describes the structure of transactions sent on behalf of users. To avoid confusion, it is not named "transaction" and will be sent to the Bundler, bundled with other UserOperations into a Bundle. The Bundle is then sent to the chain as a single transaction.

Sender: The contract account that sends the UserOperation. This wallet contract must comply with the ERC-4337 standard and implement the IAccount interface.

EntryPoint: A global singleton contract that executes the UserOperations bundle. Bundlers/Clients will whitelist supported EntryPoints. This contract is audited and approved for deployment by the Infinitism team and is responsible for handling all UserOperations and connecting to contracts of other roles, including Wallet Factory, Aggregator, and Paymaster. This contract has the same address on EVM-compatible chains.

Bundler: A node that packages multiple UserOperations from the mempool and creates EntryPoint.handleOps() transactions (currently the block-producing node). Bundler services can run independently of blockchain nodes and send packaged UserOperations via RPC.

Aggregator: An auxiliary contract trusted by the account to verify aggregated signatures. Bundlers/Clients will whitelist supported signature aggregators. The Aggregator must comply with the ERC-4337 standard and implement the IAggregator interface.

Paymaster: A smart contract that can pay for gas. If it deposits enough ETH in the EntryPoint contract, it can pay the gas fees for the UserOperation sent by the sender, effectively achieving gas abstraction. The Paymaster must comply with the ERC-4337 standard and implement the Paymaster interface. The Paymaster can negotiate with the Sender. For example, the Sender pays the Paymaster in USDC, and the Paymaster uses ETH to pay for the gas of the UserOperations it sends. In fact, the Paymaster can choose to support any token, including ERC-20 tokens or even tokens from other chains.

Wallet Factory: A smart contract that can create contract wallets for ERC-4337 users. Deploying a Wallet Factory does not require permission. As an on-chain smart contract, its code is open to the public, and anyone can review it. A widely used Wallet Factory should undergo comprehensive audits by professionals.

The following diagram explains how the EntryPoint contract interacts with other roles.

Bundlers call the handleOps function of the EntryPoint contract, which accepts UserOperation as input.

handleOps will verify the UserOperation on-chain, checking if it is signed by the specified smart contract wallet address and confirming that the wallet has enough gas to compensate the Bundler.

If the verification passes, handleOps will execute the smart contract wallet function according to the function and input parameters defined in the calldata of the UserOperation.

On the other hand, when a Bundler triggers the handleOps function using an EOA, gas fees will be incurred. The smart contract wallet can pay gas fees to Bundlers from its own account balance or request the Paymaster contract to cover the costs. UserOperations cannot pass the off-chain verification step without sufficient gas, meaning they will fail before executing the transaction on-chain. Even with sufficient gas, UserOperations may still fail during execution due to runtime errors or other reasons. For a UserOperation, regardless of whether the contract execution is successful, the EntryPoint contract will pay gas fees to the Bundler that triggered the handleOps function.

After the implementation of ERC-4337, users can now initiate blockchain transactions in two ways. One is the traditional method, where the EOA directly initiates the transaction. The other is using the ERC-4337 standard to initiate a UserOperation through a Bundler, which will then package it with other UserOperations and send it to the chain. The following flowchart illustrates the difference between a regular EOA sending a transaction and an ERC-4337 contract wallet sending a UserOperation.

The Road is Paved, but Few Travelers

ERC-4337 provides a powerful framework for users and developers to use and build AA on Ethereum. Although this framework is an important advancement, there are still some challenges and uncertainties that need to be addressed and resolved.

The adoption of AA is still in its early stages. According to the Dune ERC-4337 analysis panel, over 65k UserOperations have been executed on-chain, with 90% coming from Polygon. Therefore, the current number of executed UserOperations is still very low, with most being developer tests and only a small portion coming from real users. We note that products that have integrated AA are still in their infancy. Currently, we observe that Bundlers as a whole are still operating at a loss, with losses amounting to over 700 MATIC. This is mainly due to some Bundlers on Polygon misestimating the required gas, resulting in the gas returned by EntryPoint being less than the gas consumed by the submitted bundle. This issue needs to be resolved at the Bundler client level.

In addition, there are several issues that need to be addressed. One of the issues is how Bundlers handle transaction failures.

After bundling multiple UserOperations together, Bundlers first simulate the transactions to detect if there will be contract execution failures and calculate whether the gas fees returned by the Sender or Paymaster exceed the paid gas fees.

If it is profitable, the Bundler submits this batch of UserOperations as a transaction to the block-producing node. However, the transaction may still fail, causing the Bundler to pay gas fees without receiving gas back from EntryPoint. For example, users may send operations to different Bundlers. If there is a profit margin and the simulation is successful, Bundlers will submit it to the chain. In this case, if a UserOperation is submitted to the block-producing node by different Bundlers simultaneously, only one transaction will succeed, meaning only one Bundler will receive gas fees returned by EntryPoint, while all other Bundlers will incur gas losses due to on-chain failure. While some may argue that such behavior should be viewed as a malicious attack and advocate for Bundlers to blacklist that Sender address, refusing any future requests from that address, this is not a reasonable solution, as users may inadvertently engage in such behavior. This issue needs to be properly addressed in the code, perhaps through a public mempool currently under development. Furthermore, even if a transaction has been successfully submitted and the simulation results show a profit margin, Bundlers may still suffer losses due to sudden gas fluctuations.

Another issue is the maximum extractable value (MEV) that can be obtained from AA. In the context of Ethereum, MEV typically refers to the value extracted by miners or other transaction processors by manipulating the order of transactions in a block or inserting their own transactions into the block. One might note that the logic of MEV can also apply to AA. This is because, in AA, Bundlers can freely order UserOps, providing them with the potential to extract MEV. However, whether a Bundler can extract MEV depends on whether there are enough UserOperations to bundle together. Currently, the entire AA market is still in its early stages, so Bundler MEV can also be considered in its infancy. It is foreseeable that the MEV of AA may develop in two directions: one similar to the Ethereum mainnet, with participants like Flashbots, Ultra Sound, and BloXroute involved; the other direction is forming Bundler consensus to implement fair ordering. The latter would completely eliminate the possibility of extracting MEV in AA.

Future Development

Public Mempool

Although the AA ecosystem is already operational, there is still much development work to be done. From the perspective of the entire AA ecosystem, the biggest missing part is the public mempool. The Etherspot team, developers of the Skandha Bundler client, is currently developing a p2p network for the public mempool. The public mempool p2p network is expected to launch in August this year.

Bundle Algorithm

In this process, the Ethereum Foundation has funded several excellent AA development teams. So far, multiple Bundler clients have been developed and are currently usable. Some of these are already quite mature, including Candide (a Voltaire Bundler written in Python), Pimlico (an Alto Bundler written in TypeScript), Etherspot (a Skandha Bundler written in TypeScript), Stackup (a Stackup-Bundler written in Go), and others.

This brings up the issue of bundling strategies. Currently, due to the small number of UserOperations, Bundlers can adopt simple bundling logic, such as fixed time intervals or a certain number of UserOperations per Bundle. However, as the number of UserOperations increases, especially after the introduction of the public mempool, the strategy for selecting and bundling UserOperations becomes more complex. The reason is simple: in the AA ecosystem, there is a lack of mechanisms similar to blockchain consensus protocols, and the Bundler community becomes a dark forest where each Bundler prioritizes tasks based on their own interests and competes with one another. In contrast to the public mempool, private mempools may emerge earlier. This is because when bundling UserOperations from the public mempool is unprofitable, there may still be profit potential in bundling UserOperations from a private mempool. In this case, the Bundler is more competitive when bundling compared to other Bundlers.

Moreover, as the public mempool gradually becomes more widespread, the UserOperations within it will have various characteristics, such as different gas profit expectations and on-chain execution complexities. Bundlers will conduct off-chain simulations to evaluate the profitability of various combinations of UserOperations, thereby establishing their own bundling strategies. Bundling more UserOperations may yield higher profits, but it also increases the risk of verification failures. Even if verification passes, there is still a risk of on-chain execution failures. Conversely, bundling fewer UserOperations presents the opposite scenario. Bundlers need to set their own transaction gas parameters, which will affect the priority of the block-producing node in executing the transaction. Under different estimated gas prices and gas volatility conditions, Bundlers may have different bundling strategies. They also need to consider the costs of local hardware computing resources and blockchain node resources required for these verifications and strategy calculations. Additionally, Bundlers need to strive to provide users with a good user experience, ensuring that users do not face excessive delays after submitting UserOperations.

Although the solutions to these challenges remain unclear, we can confidently say that the development of the AA industry and the collaborative efforts of developers will ultimately resolve these issues.

Infrastructure Must Adapt to AA

AA abstracts various roles involved in on-chain transaction behavior, including Sender, Bundlers, Gas payers, contract wallets, and Signers, allowing users greater freedom when using the blockchain. At the same time, infrastructure providers can independently deploy these services based on their market judgments.

To accommodate the large-scale adoption of AA, infrastructure providers first need to offer at least two basic services: Bundler services and Paymaster services.

In Bundler services, infrastructure providers may need to collaborate with Bundlers to develop a private mempool to provide a good user experience. Specifically, infrastructure providers need to integrate multiple Bundler clients to ensure the stability of Bundler services. These Bundler clients currently provide users with several standard JSON RPC methods, which are provided by the ERC-4337 core development team. It is foreseeable that more RPC methods will be available for users in the future. Infrastructure service providers need to keep their support for these methods updated in a timely manner.

Additionally, optimizing the Bundler API and the original node client RPC is also very important. Current node clients have not been optimized for AA. Some Bundler API methods require the node to provide data indexing for AA. For example, the current client needs to scan all blocks for EntryPoint contract logs when looking up UserOperations by hash. Without data indexing, the hardware resource consumption of this single request will be quite large, and the return time of the request will also become very long.

Furthermore, to provide users with a gas-free experience and diverse services, infrastructure providers need to collaborate with different Paymaster service providers to integrate various Paymaster services. Based on market demand, infrastructure providers can also design more convenient integration solutions based on existing Paymaster services. Other services, such as signature aggregation and wallet factories, are also potential directions for the future development and integration of infrastructure.