How to make account abstraction empower infrastructure to serve billions of users?

Author: Albert He, BlockPI Cheif Scientist; Compiler: MarsBit, MK

Whether it is a bull market or a bear market, the Ethereum ecosystem has been continuously building and self-optimizing. Among them, account abstraction (AA) has become a very important advancement in recent years, and has penetrated into various components of the Ethereum ecosystem, including applications, infrastructure, users, and developers.

We can foresee that the widespread adoption of AA in the world can lower the barriers to entry for blockchain use cases, thereby bringing web2 user experience to the web3 industry. **

To embrace the possibility of forming a multi-billion AA market, BlockPI plans to dedicate resources to integrating AA into its infrastructure services. By building out the integration of AA, we aim to provide more convenient and efficient ways for AA users to interact with their contract wallet accounts on the blockchain, while also positioning BlockPI as an industry leader.

In this post, I will delve into our understanding of AA and share thoughts from the perspective of an infrastructure service provider.

EOA and smart contract wallet

**The concept of AA stems from the limitations of EOA accounts. **EOA accounts (externally owned accounts) are typical user accounts in Ethereum, represented by a public key (blockchain address), accessible through a private key. It is a major component of the Ethereum ecosystem, allowing users to interact with smart contracts and execute transactions on the network. However, using EOA can be challenging for people, and some inconveniences may affect the user experience.

**The first inconvenience of EOA is related to the use of Gas. **Each transaction will cost the user a large amount of ETH as Gas fee (a simple ETH transfer fee of 25 Gwei for Gas price is 0.5 USD, and more for contract interaction or higher Gas price). This makes transaction fees very expensive for small transactions, especially during peak periods of network congestion. Additionally, only ETH can be used to pay for Gas, which means users must have ETH in their wallets, which is a significant barrier to entry for many users.

**The second inconvenience of EOA is that conditional transactions cannot be made unless some logic is implemented using other smart contracts. **For example, if a user wants to set a timed cycle transfer, they must transfer ETH to a third-party smart contract with this function to achieve this function.

**The third inconvenience of EOA is the signature encryption algorithm. **The Ethereum network uses a specific digital signature algorithm called secp 256 k 1 to ensure the authenticity and security of transactions. This is hardcoded into the system and the user cannot choose to use another algorithm.

Therefore, starting from these problems, people began to try to find solutions. Smart contract wallets such as MetaMask and Argent are the result of these efforts, addressing many of EOA's limitations by using Ethereum smart contracts to enhance user account functionality. However, such a solution still has some disadvantages, mainly requiring users to pay Gas fees for transactions and the popularity of smart contract wallets.

**Based on these challenges, Ethereum began to try to introduce a new concept, namely account abstraction. The goal of account abstraction is to solve these problems at the protocol level, rather than relying on smart contracts or other middleware. This is what we now call account abstraction (AA). **

In the remainder of this post, I'll dig into the concept of account abstraction and how we can use it to optimize BlockPI's infrastructure.

**In addition to the three inconveniences of EOA mentioned above, the binding relationship between the public key and the private key is also a problem. **The private key is the only way to access the EOA, if lost, there is no way to recover the private key. This means that if the private key is lost, all assets associated with it will be irretrievable.

**In addition, EOA also faces constraints when performing linear tasks in a single transaction. **For example, if a user wishes to approve, exchange, and unapprove tokens in one action, they need to perform three separate transactions, which is inefficient and time-consuming.

The good news is that all of the above problems can be solved with smart contract wallets. A smart contract wallet is a special type of smart contract that implements AA. It is designed to act as a user's wallet on the Ethereum network and provide a more adaptive and personalized way to manage their funds. As long as the logic of the Ethereum smart contract can be realized, the smart contract wallet can provide the required functions.

Specifically, the transactions of the smart contract wallet can be packaged into an on-chain transaction to share the gas cost. If a third party is willing to pay, there may even be no gas cost. An operation can facilitate the execution of sequential tasks within its smart contract wallet. The smart contract wallet can support any signature encryption algorithm, and set recovery codes, etc.

With all the talk about the benefits of smart contract wallets, the Ethereum community has actually been working on contract wallets since the beginning. Although many EIPs have been proposed to explore account abstraction, no unified standard has been established until 2021. Below are some of the most representative proposals.

EIP-86

Originally created in 2017 by Vitalik Buterin. Implemented a set of changes to "abstract" signature verification and nonce checking services, allowing users to create "account contracts" that perform any desired signature/nonce checks.

EIP-2938

Created in 2020. The title of this EIP is Account Abstraction. This EIP details the concept of AA. It introduces a new type of transaction, the AA transaction. This transaction will be initialized by the EntryPoint address and call the AA wallet contract. By doing so, it provides a unified specification and introduces AA into the Ethereum consensus. More specifically, it adds two new opcodes, three global variables, and a different payload structure to Ethereum consensus.

EIP-3074

Created in 2020. This EIP introduces two EVM instructions, AUTH and AUTHCALL. AUTH sets a context variable called authorized based on the ECDSA signature. AUTHCALL sends a call on behalf of an authorized account. This allows a smart contract to send transactions on behalf of EOA. But this is not a perfect solution for AA. EIP-3074 places certain limitations on native value transfers during sponsorship transactions. If you lose access to the EOA, you will not be able to recover your assets, and if stolen, all assets will need to be transferred to a new account.

None of the above ideas were formally adopted into the Ethereum protocol due to major reasons such as requiring changes at the consensus layer or not being comprehensive. Therefore, the Ethereum community continued to explore how to introduce AA into the Ethereum protocol without changing the consensus, and finally created EIP 4337.

ERC — 4337

EIP-4337 was originally proposed in September 2021 and 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 game-changing proposal that introduces AA without making any changes to the core Ethereum protocol. EIP-4337 guides the ERC-4337 standard, which builders can use to implement their own smart contract wallets, and includes some additional infrastructure, including "Bundlers" and UserOperation memory pools. By doing this, it essentially replicates the functionality of the transaction mempool in a more advanced system. Instead of sending transactions, users submit UserOperation objects, which can then be packaged into a single transaction and included in the Ethereum chain.

The following is a more specific technical explanation of ERC-4337 from the official documentation, as well as some comments for better understanding.

Definition and key roles of ERC-4337

UserOperation — structure describing transactions sent on behalf of a user. To avoid confusion, it is not named "transaction". It is sent to the Bundler to be packaged with other UserOperations. The package is then sent to the block creator as a single transaction.

Sender — the contract account that sends the new UserOperation. The smart contract wallet must implement the IAccount interface of ERC-4337.

EntryPoint — a singleton contract that implements the UserOperations package. Bundlers/Clients whitelist supported EntryPoints. This contract is approved and reviewed by the Infinitism team and is responsible for handling all UserOperations and connecting other contracts including Wallet Factory, Aggregator, Paymaster. It will have the same address on most EVM-compatible chains.

Bundler — a node (block builder) that bundles multiple UserOperations from a mempool and creates EntryPoint.handleOps() transactions. All validators at the protocol layer do not have to be Bundlers. The Bundler service can run independently of the block builder and uses RPC to send bundled UserOperations.

Aggregator — A helper contract trusted by accounts to verify aggregated signatures. Bundlers/Clients whitelist supported aggregators. Aggregators must implement the ERC-4337 IAggregator interface.

Paymaster — A contract that can pay the UserOperation's gas fee for the Sender if enough ETH is deposited in the EntryPoint contract. Paymaster implements an efficient Gas abstraction. Paymaster must implement the Paymaster interface of ERC-4337. Paymaster can have its own logic to make a deal with Sender. For example, Sender pays USDC to Paymaster, and Paymaster sponsors its UserOperations with ETH. In fact, any ERC 20 token or even tokens on other chains can be supported as long as Paymaster agrees and it is technically feasible.

Wallet Factory — a contract that can be called to create smart contract wallets for ERC-4337 users. Deploying a wallet factory is permissionless. As an on-chain component, it is open to public audit and transparent scrutiny. Widely used Wallet Factory should be fully audited by professionals.

The diagram below explains how the EntryPoint contract interacts with other actors.

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

handleOps verifies the UserOperation on the chain, checks whether it is signed by the specified smart contract wallet address, and whether the wallet has enough Gas to compensate Bundler.

If the verification is successful, handleOps will execute the smart contract wallet function according to the function signature and input parameters defined in the UserOperation's calldata.

On the other hand, when Bundler uses EOA to trigger the handleOps function, a Gas fee will be incurred. The smart contract wallet can pay the Gas fee to Bundlers from its own account balance, or request the Paymaster contract to pay on its behalf. UserOperations that do not have enough Gas cannot pass the verification process in the target smart contract wallet and thus fail before execution. Even if there is enough gas, UserOperations may fail during execution, for example, due to runtime errors. Whether the execution is successful or not, the EntryPoint contract will pay the Gas fee to the Bundler that triggers the handleOps function.

(Source: Official Documentation:

After ERC-4337 goes into effect, users now have two ways to initiate blockchain transactions. One is the original way, where the EOA initiates the transaction. The other is to use the ERC-4337 standard to start UserOperation through Bundler, and then Bundler will package it with other UserOperations and initiate it on the chain. The following flow chart illustrates the difference between the normal EOA send transaction and the ERC-4337 contract wallet send UserOperation.

The road is paved, but there are not many passengers

ERC-4337 provides a powerful framework for users and developers to use and build AA on the Ethereum platform. Although this framework is an important step forward, several challenges and uncertainties still need to be addressed and resolved.

**Adoption of AA is in its infancy. **According to the Dune ERC-4337 analysis panel (ERC-4337 Account Abstraction from @niftytable), only 65 k+ UserOperations are executed on-chain, 90% of which are from Polygon. Therefore, the number of UserOperations performed at this time is still very small, most of which are developer tests and only a small part is attributed to users. We note that products that have integrated AA are still in their early stages. At the same time, you can see that Bundler's profit is negative (-700 in MATIC terms). This is because some bundlers on Polygon do not calculate the pre-validation gas correctly. This verification algorithm still needs optimization.

**Other than that, there are a few kinks that need to be worked out. One such issue is how Bundlers handle transaction failures. **After Bundler packages several UserOperations together, Bundler first simulates the transaction to check whether it will be rolled back, and then calculates whether the Gas fee returned by Sender or Paymaster is greater than the Gas fee paid by the transaction. If it is profitable, Bundler submits this batch of UserOperations together as a transaction to the block builder. However, the transaction may still fail, resulting in the Bundler paying the gas fee but not receiving the gas back from the EntryPoint. For example, a user might send actions to different Bundlers. Bundlers are willing to submit any operations on-chain if they are profitable and their simulation is successful. This means that if a UserOperation is submitted by different Bundlers at the same time. Only one transaction will succeed, only one Bundler will receive gas fee from EntryPoint, all other Bundlers will lose gas due to on-chain failure. While one could argue that users shouldn't do this, such behavior would be considered a malicious attack, and that Bundler could ban the Sender address and reject any future requests from this address, this is not a reasonable approach because users This operation may have been submitted inadvertently. Such issues need to be properly addressed in the code, possibly by developing an unfinished public mempool network. Additionally, due to sudden gas fluctuations, Bundlers may face losses even though transactions have been successfully submitted and simulated as profitable.

**Another thing is the Maximum Extractable Value (MEV) that can be extracted from the AA. **In the context of Ethereum, MEV generally refers to the value that miners or other transaction processors can extract by manipulating the order of transactions in a block or including their own transactions in a block. Has anyone noticed that the logic of MEV can also be applied to AA, since Bundlers are free to order UserOperations? However, this is conditional, enough UserOperations need to be bundled together for Bundlers to extract MEV. Now the entire AA market is still in its infancy, so Bundler MEV can also be considered in its infancy. In general, the **AA industry may develop in two directions: one is similar to the Ethereum mainnet, with participants like Flashbots, Ultra Sound, and BloXroute participating, and the other is to form a Bundler consensus to enforce fairness sorting. The latter approach would completely eliminate the possibility of MEV in AA. **

future development

public mempool

Although the AA ecosystem is already functioning, there is still a lot of development work to be done. Looking at the entire AA ecosystem, the biggest gap at present is the public mempool. The Etherspot team, developers of the Skandha Bundler client, are currently developing a p2p network with a public mempool. The p2p network of the public mempool is expected to be available in August of this year.

Packing Algorithm

Along the way, the Ethereum Foundation has funded several AA development teams of dedicated and hardworking developers. To date, several versions of the Bundler client have been developed and are now available. Some of them are highly developed in terms of product maturity. They are Candide (Voltaire Bundler written in Python), Pimlico (Alto Bundler written in Type), Etherspot (Skandha Bundler written in Type), Stackup (Stackup-Bundler written in Go), and many more.

Now, let's dive into the packing algorithm in more detail. Currently, due to the low number of UserOperations, Bundlers can employ simple and straightforward packaging logic, such as fixed time intervals or the number of UserOperations in each bundle. However, as the number of UserOperations increases, especially after the introduction of the public mempool, the strategy for selecting and packaging UserOperations becomes more complex. The reason is simple: without a consensus protocol like a blockchain, Bundlers form a dark forest, each prioritizing work according to their own interests, and competing with each other. Private mempools, correspondingly corresponding to public mempools, are more likely to come first. Because when it is not profitable to package UserOperations from the public mempool, it may become profitable to package UserOperations together in the private mempool. This way, Bundler has a competitive advantage when it comes to packaging.

In addition, as the public mempool is gradually accepted, the UserOperations in it will have different characteristics, such as different Gas profit expectations and on-chain execution complexity. Bundlers will conduct off-chain simulations to evaluate the profitability of various combinations of UserOperations to establish their unique bundling strategies. Packing more UserOperations has the potential to yield greater profits, but also increases the risk of validation failures. Even if the verification is passed, the risk of execution failure on the chain still exists. The less-packaged UserOperations do the opposite. Bundlers need to set their own transaction gas parameters, which will affect the priority of block builders to execute transactions. Under different market Gas prices and Gas volatility conditions, Bundlers may have different packaging strategies. At the same time, these verification and policy calculations need to consume local hardware computing resources and blockchain node resources. Bundlers also need to ensure that users have a good experience and that users do not face excessive delays after submitting a UserOperation.

While the solutions to these challenges remain uncertain, we can be confident that the evolution of the AA industry and the combined efforts of developers will eventually find solutions. As an infrastructure builder, BlockPI hopes to solve problems in the development of the AA industry, whether as a developer or to provide friendly AA infrastructure for other developers.

Infrastructure must adapt

AA abstracts various roles in the transaction behavior on the chain, including senders, bundlers, gas payers, contract wallets, and signers, allowing users to have a higher degree of freedom when using the blockchain. Also, services within an AA can be deployed separately.

**In order to accommodate the large-scale adoption of AA, infrastructure providers first need to provide at least two basic services, namely Bundler service and Paymaster service. **

In the Bundler service, the infrastructure provider may need to develop a private mempool with Bundlers to ensure a good user experience. Specifically, infrastructure providers need to integrate various Bundler clients to ensure the robustness of Bundler services. These Bundler clients are developed in different programming languages, but they all provide a standard set of JSON RPC methods specified by the ERC-4337 core team. Currently, there are not many methods available, but more methods will be added in the future. Infrastructure service providers should provide continuous and complete support for these APIs.

Also, it is important to optimize and adapt the relationship between the Bundler API and the origin node client RPC. We know that the current node client is not well optimized for the responsiveness and adaptability of AA. Certain Bundler API methods require AA's data index to work. For example, looking up a UserOperation by hash requires indexing all UserOperations. Otherwise, the hardware consumption of this single request will be very high, and the request will take a long time to return.

In addition, infrastructure providers also need to integrate different Paymaster services to provide customers with a gas-free user experience and provide them with different service options. This requires good communication and integration with third-party Paymaster service providers. At the same time, according to market demand, more convenient integration solutions based on existing Paymaster services can also be designed. Other services, such as aggregated signatures, wallet factories, etc., are also possible directions for future development and integration.

Currently, BlockPI is actually trying to achieve all of the above goals. Not only that, we are communicating with almost all Bundler clients and Paymaster service providers in the community, and have made integrating AA service into BlockPI Network our top priority. We are also having in-depth discussions with AA wallet developers to understand user needs. Therefore, we sincerely welcome cooperation and exchanges with all Bundlers, Paymasters, and wallets as we move forward. Our overall goal is to build and develop the AA ecosystem with others, driving its growth and development to the best of our ability. By working together, we hope to make a meaningful contribution to the AA industry as a whole and support its continued development. Because after all, our ultimate mission is to be a pioneer in the industry and promote the development of the AA ecosystem so that web2 users can enjoy their blockchain experience without barriers.

Summarize

From the perspective of AA, we are at a new historical moment. Although we have paved roads on the boulevard, there aren't many riders yet. At present, the application of AA is still in its infancy. ERC-4337 provides a powerful framework for users and developers to use and build AA on the Ethereum platform. However, there are still many challenges and uncertainties that need to be resolved.

**AA's infrastructure provider needs to provide Bundler service and Paymaster service for its users, and needs to integrate various Bundler clients and Paymaster service providers to ensure the robustness of the service. **In order to optimize responsiveness between API and node clients, AA data may need to be indexed to reduce hardware consumption for a single request. In order to provide better user experience, infrastructure providers also need to provide users with more service options.

**In the future, as the AA ecosystem continues to grow and public mempools emerge, the strategy for selecting and packaging UserOperations will become more complex. **Each Bundler prioritizes its own work based on its own interests and competes with other Bundlers. Bundlers need to set their own transaction gas parameters, which affect the priority of block builders to execute transactions. Under different market Gas prices and Gas volatility conditions, Bundlers may have different packaging strategies.

While the solutions to these challenges are uncertain, we can be confident that the evolution of the AA industry and the combined efforts of developers will eventually find solutions. As an infrastructure builder, BlockPI hopes to be a problem solver in the development of the AA industry, either as a developer or by providing friendly AA infrastructure for other developers. Our mission is to promote the development of the AA ecosystem so that Web2 users can enjoy their blockchain experience without barriers.