Original author: Albert He, BlockPI Chief Scientist

Original translation: MarsBit, MK

Whether it's a bull market or a bear market, the Ethereum ecosystem has been continuously building and optimizing itself. Account Abstraction (AA) has become a very important advancement in recent years and has permeated various components of the Ethereum ecosystem, including applications, infrastructure, users, and developers.

We can foresee that widespread adoption of AA can lower the barrier for blockchain use cases, bringing web2 user experience into the web3 industry.

To embrace the possibility of forming a billion-dollar AA market, BlockPI plans to invest resources in integrating AA into its infrastructure services. By building the integration of AA, our goal is to provide AA users with a more convenient and efficient way to interact with their contract wallet accounts on the blockchain, while positioning BlockPI as a leader in the industry.

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

EOA and Smart Contract Wallets

The concept of AA originates from the limitations of EOA accounts. EOA accounts (externally owned accounts) are typical user accounts in Ethereum, represented by public keys (blockchain addresses) and accessible through private keys. They are 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 certain inconveniences may affect the user experience.

The first inconvenience of EOA is related to the use of gas. Every transaction incurs significant ETH costs for users as gas fees (for example, a simple ETH transfer fee at a gas price of 25 Gwei is $0.5, and fees for contract interactions or higher gas prices are even higher). This makes transaction fees for small amounts very expensive, especially during network congestion. Additionally, only ETH can be used to pay for gas, which means users must have ETH in their wallets, posing a significant barrier for many users to get started.

The second inconvenience of EOA is the inability to perform conditional transactions unless using other smart contracts to implement certain logic. For example, if a user wants to set up scheduled recurring transfers, they must transfer their ETH to a third-party smart contract with this functionality.

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

Therefore, starting from these issues, people have begun to try to find solutions. Smart contract wallets (such as MetaMask and Argent) are the products of these efforts, enhancing user account functionality by using Ethereum smart contracts and solving many limitations of EOA. However, such solutions have some drawbacks, mainly the need for users to pay gas fees for transactions and the issue of popularizing smart contract wallets.

Based on these challenges, Ethereum started to explore a new concept, which is account abstraction. The goal of account abstraction is to solve these issues at the protocol level, rather than relying on smart contracts or other middleware. This is what we now refer to as Account Abstraction (AA).

In the remaining part of this article, I will delve into the concept of account abstraction and how we leverage this concept to optimize BlockPI's infrastructure.

In addition to the three inconveniences of EOA mentioned above, the binding relationship between public and private keys is also an issue. The private key is the only way to access EOA, and if it is lost, there is no way to recover it. This means that if the private key is lost, all associated assets cannot be retrieved.

Furthermore, EOA faces constraints when performing linear tasks in a single transaction. For example, if a user wants to approve, exchange, and revoke token approvals in a single action, they would need to execute three separate transactions, which is neither efficient nor time-effective.

The good news is that all of the above issues can be addressed by smart contract wallets. Smart contract wallets are a special type of smart contract that implements AA. It is designed to serve as a user's wallet on the Ethereum network and provides a more adaptive and personalized way to manage their funds. As long as the logic can be implemented by Ethereum smart contracts, smart contract wallets can provide the required functionality.

Specifically, transactions of smart contract wallets can be bundled into one on-chain transaction, sharing gas costs. If there are third parties willing to pay, there may even be no gas costs. One operation can facilitate the execution of sequential tasks within the smart contract wallet. Smart contract wallets can support any signature scheme, set recovery codes, and so on.

With the discussion of all the benefits of smart contract wallets, the Ethereum community has actually been researching contract wallets from the beginning. Although many EIPs have been proposed to explore account abstraction, a unified standard has not been established until 2021. Here are several representative proposals.

EIP-86 

Originally created by Vitalik Buterin in 2017. It implements a set of changes that provide "abstraction" for signature verification and nonce checks, allowing users to create "account contracts" that perform any required signature/nonce checks.

EIP-2938 

Created in 2020. The title of this EIP is Account Abstraction. This EIP provides a detailed description of the concept of Account Abstraction. It introduces a new type of transaction called AA transaction. This transaction is initialized by the EntryPoint address and calls the AA Wallet contract. By doing so, it provides a unified specification and introduces AAs into Ethereum consensus. 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 an ECDSA signature. AUTHCALL sends a call as an authorized account. This allows a smart contract to send a transaction on behalf of an externally owned account (EOA). However, this is not a perfect solution for AAs yet. EIP-3074 has limitations in terms of native value transfer during sponsorship transactions. If you lose access to the EOA, you won't be able to recover your assets, and if they are stolen, all assets need to be transferred to a new account.

Due to major reasons such as the need for changes at the consensus layer or lack of comprehensiveness, all of the above ideas have not been formally adopted into the Ethereum protocol. As a result, the Ethereum community continued to explore how to introduce AAs into the Ethereum protocol without changing the consensus, eventually creating EIP-4337.

ERC-4337

EIP-4337 was first 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 AAs without the need for any changes to the core Ethereum protocol. EIP-4337 paves the way for the ERC-4337 standard, which builders can use to implement their own smart contract wallets, along with additional infrastructure including "Bundlers" and the UserOperation memory pool. By doing so, it effectively replicates the functionality of the transaction memory pool in a higher-level system. Instead of sending transactions, users submit UserOperation objects, which can then be bundled into a single transaction and included on the Ethereum chain.

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

Definition and Key Roles of ERC-4337

UserOperation — A structure that represents transactions sent by users. To avoid confusion, it is not named "transaction". It is sent to Bundler to be bundled with other UserOperations. The bundle is then sent as a single transaction to the block creator.

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

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

Bundler — A node (block builder) that bundles multiple UserOperations from the mempool and creates the EntryPoint.handleOps() transaction. Not all validation nodes at the protocol layer need to be Bundlers. Bundler services can run independently of the block builders and send bundled UserOperations via RPC.

Aggregator — A trusted contract that helps with signature validation of the aggregate. Bundlers/Clients add supported aggregators to their whitelist. Aggregators must implement the IAggregator interface of ERC-4337.

Paymaster — A contract that can pay the gas fees for UserOperations on behalf of the Sender if enough ETH is deposited in the EntryPoint contract. The Paymaster implements an effective gas abstraction. The Paymaster must implement the Paymaster interface of ERC-4337. The Paymaster can have its own logic to interact with the Sender. For example, the Sender can pay USDC to the Paymaster, and then the Paymaster sponsors its UserOperations with ETH. In fact, as long as the Paymaster agrees and it is technically feasible, any ERC-20 token and even tokens on other chains can be supported.

Wallet Factory — A contract that can be called to create smart contract wallets for ERC-4337 users. Deploying the wallet factory does not require permission. As a component on the chain, it is open to public audits and transparent reviews. Widely used Wallet Factories should be thoroughly audited by professionals.

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

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

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

If the verification is successful, handleOps will execute the smart contract wallet function based on the function signature and input parameters defined in the calldata of UserOperation.

On the other hand, when the Bundler triggers the handleOps function using EOA, it incurs Gas fees. The smart contract wallet can pay Gas fees to the Bundlers from its own account balance, or request the Paymaster contract to pay on its behalf. UserOperations without enough Gas cannot pass the verification process in the target smart contract wallet, resulting in a failure before execution. Even with enough Gas, UserOperations may still fail during execution, for example, due to runtime errors. Regardless of the success of the execution, the EntryPoint contract will pay the Gas fees to the Bundler that triggers the handleOps function.

(Source: Official Documentation: https://eips.ethereum.org/EIPS/eip-4337)

After ERC-4337 takes effect, users now have two ways to initiate blockchain transactions. One is the original way where EOA initiates the transaction. The other is by using the ERC-4337 standard to initiate a UserOperation through the Bundler, which is then bundled with other UserOperations and launched on the chain by the Bundler. 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 the passengers are still few

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

AA adoption is still in its early stages. According to the Dune ERC-4337 analysis panel (ERC-4337 Account Abstraction from @niftytable), only 65 k+ UserOperations are being executed on-chain, with 90% of them coming from Polygon. Therefore, the number of UserOperations being executed at this time is still very small, with the majority being tests performed by developers and only a few attributed to users. We have noticed that products integrated with AA are still in the early stages. Additionally, it can be seen that the profit of Bundlers is negative (calculated as -700 with MATIC). This is because some Bundlers on Polygon have not correctly calculated pre-validation gas. This validation algorithm still needs optimization.

In addition to this, there are some issues that need to be addressed. One of them is how Bundlers handle failed transactions. After bundling several UserOperations together, Bundlers first simulate the transaction to check if it will roll back, and then calculate whether the gas fee returned by the Sender or Paymaster is greater than the gas fee paid for the transaction. If it is profitable, Bundlers submit this batch of UserOperations as one transaction to the block builder. However, the transaction may still fail, resulting in Bundlers paying the gas fee but not receiving the gas refunded from the EntryPoint. For example, a user may send operations to different Bundlers. If any of the operations are profitable and their simulations succeed, Bundlers are willing to submit them on-chain. 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 the gas fee from the EntryPoint, and all other Bundlers will lose gas due to on-chain failure. Although some may argue that users should not do this and such behavior would be considered a malicious attack, Bundlers can blacklist the Sender address and reject any future requests from this address, but it is not a reasonable approach as users may accidentally submit this operation. Such issues need to be addressed properly in the code, potentially by developing an unfinished public mempool network. Additionally, due to sudden gas fluctuations, Bundlers may still face losses even if the transaction has been successfully submitted and simulated as profitable.

Another thing is the Maximum Extractable Value (MEV) extracted from 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 the block. It has been noticed that the logic of MEV can also be applied to AA because Bundlers can freely order UserOperations. However, this is conditional and requires enough UserOperations to be bundled together for Bundlers to extract MEV. Currently, the entire AA market is still in its early stages, so Bundler MEV can also be considered in its early stages. Overall, the AA industry may develop in two directions: one similar to the Ethereum mainnet, with participants such as Flashbots, Ultra Sound, and BloXroute involved, and the other forming Bundler consensus to enforce fair ordering. The latter approach will completely eliminate the possibility of MEV in AA.

Future Development

Public Mempool

Although the AA ecosystem is already operational, there is still a lot of development work to be done. Looking at the entire AA ecosystem, the biggest gap at the moment is the public mempool. The Etherspot team, the developers of the Skandha Bundler client, is currently working on the development of a p2p network for the public mempool. The public mempool's p2p network is expected to be available in August this year.

Packaging Algorithm

In this process, the Ethereum Foundation has funded several AA development teams composed of focused and diligent developers. So far, several versions of Bundler clients have been developed and are now available. Some of them are highly developed in terms of product maturity. They include Candide (Voltaire Bundler written in Python), Pimlico (Alto Bundler written in Typescript), Etherspot (Skandha Bundler written in Typescript), Stackup (Stackup-Bundler written in Go), and so on.

Now, let's delve into a more detailed discussion of bundling algorithms. Currently, due to the small number of UserOperations, Bundlers can adopt a simple and straightforward bundling logic, such as fixed intervals or the number of UserOperations in each bundle. However, as the number of UserOperations increases, especially with the introduction of a public mempool, the strategy for selecting and bundling UserOperations becomes more complex. The reason is simple: without a consensus protocol like blockchain, Bundlers form a dark forest where each Bundler prioritizes its own interests and competes with each other. Private mempools are more likely to appear correspondingly to the public mempool. This is because it may be more profitable to bundle UserOperations from the private mempool when bundling UserOperations from the public mempool is not advantageous. This way, Bundlers have a competitive advantage when bundling.

In addition, as the public mempool is gradually adopted, the UserOperations within 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, thereby establishing their unique bundling strategies. Bundling more UserOperations may result in greater profits, but also increases the risk of verification failures. Even if the verification succeeds, there is still a risk of on-chain execution failures. On the other hand, bundling fewer UserOperations is the opposite. Bundlers need to set their own transaction gas parameters, which will affect the priority of execution for block builders. Under different market gas prices and gas fluctuation conditions, bundlers may have different bundling strategies. At the same time, these verification and strategy computations require local hardware computing resources and blockchain node resources. Bundlers also need to ensure a good user experience by avoiding long delays after users submit UserOperations.

Although the solutions to these challenges are still uncertain, we can be sure that the development of the AA industry and the collective efforts of developers will eventually find solutions. As infrastructure builders, BlockPI hopes to solve these problems in the development of the AA industry, whether as developers themselves or by providing user-friendly AA infrastructure for other developers.

Infrastructure Must Adapt

AA abstracts various roles in on-chain transaction behavior, including senders, Bundlers, gas payers, contract wallets, and signers, allowing users to have greater flexibility when using the blockchain. Moreover, services within AA can be deployed separately.

To accommodate the widespread adoption of AA, infrastructure providers need to first offer at least two fundamental services: Bundler service and Paymaster service.

In the Bundler service, infrastructure providers 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 the Bundler service. These Bundler clients are developed using different programming languages, but they all provide a set of standard JSON RPC methods specified by the ERC-4337 core team. Currently, there are not many available methods, but more methods will be added in the future. Infrastructure service providers should provide continuous and comprehensive support for these APIs.

In addition, it is also important to optimize and adapt the relationship between Bundler APIs and the original node client RPC. We know that the current node clients do not have good responsiveness and adaptability to AAs. Some Bundler API methods require data indexes for AAs to be used. For example, looking up UserOperations by hash requires indexing all UserOperations. Otherwise, the hardware consumption of this single request will be very high, and the request will also 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 offer them different service options. This requires good communication and integration with third-party Paymaster service providers. Additionally, based on market demand, more convenient integration solutions can be designed based on existing Paymaster services. Other services such as aggregate signatures and wallet factories are also possible directions for future development and integration.

Currently, BlockPI is actively working towards achieving all of the above goals. Not only that, we are communicating with almost all Bundler clients and Paymaster service providers in the community, and integrating AA services into the BlockPI Network as our top priority. We are also having in-depth discussions with AA wallet developers to understand user needs. Therefore, on our path forward, we sincerely welcome cooperation and communication with all Bundlers, Paymasters, and wallets. Our overall goal is to collaborate with others to build and develop the AA ecosystem, and make our greatest efforts to drive its growth and development. Through collaborative efforts, we hope to make meaningful contributions to the entire AA industry and support its continuous development process. After all, our ultimate mission is to be a pioneer in the industry, promoting the development of the AA ecosystem and enabling web2 users to enjoy their blockchain experiences seamlessly.

Summary

From the perspective of AAs, we are in a new era of history. Although we have paved the way, there are not many passengers yet. Currently, AA applications are still in the early stages, and ERC-4337 provides a powerful framework for users and developers to use and build AAs on the Ethereum platform. However, there are still many challenges and uncertainties that need to be addressed.

AA's infrastructure provider needs to provide Bundler services and Paymaster services to its users, and integrate various Bundler clients and Paymaster service providers to ensure the robustness of the services. In order to optimize the responsiveness between the API and node clients, indexing of AA data may be required to reduce hardware consumption for individual requests. In order to provide a better user experience, the infrastructure provider also needs to offer users more service options.

In the future, with the continuous development of the AA ecosystem and the emergence of public mempools, the selection and packaging strategies for UserOperations will become more complex. Each Bundler will prioritize its own work based on its own interests and compete with other Bundlers. Bundlers need to set their own transaction Gas parameters, which will affect the priority of transaction execution by the block builder. Under different market Gas price and Gas volatility conditions, Bundlers may have different packaging strategies.

Although the solutions to these challenges are still uncertain, we can be sure that the development of the AA industry and the collective efforts of developers will eventually find solutions. As builders of infrastructure, BlockPI hopes to be problem solvers in the AA industry, whether as developers or by providing friendly AA infrastructure for other developers. Our mission is to drive the development of the AA ecosystem, enabling Web2 users to seamlessly enjoy their blockchain experiences.