How does infrastructure provide support to billions of users through account abstraction?

Original Title: "How to Empower Infrastructure to Service a Billion-Strong User Base with Account Abstraction"

Original Author: Albert He, Chief Scientist at BlockPI

Whether in a bull market or a bear market, the Ethereum ecosystem has been continuously building and optimizing itself. Among them, Account Abstraction (AA) has made significant progress in recent years and has penetrated various parts of the Ethereum ecosystem, including applications, infrastructure, users, and developers. We can foresee that the widespread adoption of AA will overall lower the threshold for blockchain usage and bring the user experience of web2 into the web3 industry.   

To seize the opportunity of the multi-billion dollar potential value of the AA market, BlockPI plans to integrate AA into its infrastructure services. By integrating innovation in the AA field, BlockPI is committed to providing AA users with a more convenient and efficient way of interacting 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 Wallet

The concept of AA originated from the limitations of EOA accounts. EOA accounts (external owned accounts) are user accounts in Ethereum represented by public keys (blockchain addresses) and accessed through private keys. They are a major component of the Ethereum ecosystem, allowing users to transfer funds or interact with smart contracts on the blockchain. However, for many people, using EOA accounts is already a challenging task. Moreover, current EOA accounts still have some inconveniences in use, which affects user experience.

First of all, there is the issue of Gas fees. Each transaction will cost users a significant amount of ETH as Gas fees (for example, the Gas fee for a simple ETH transfer at a Gas price of 25 Gwei is about $0.5, and it will be more expensive for contract interactions or when Gas price is higher). This makes the transaction fees for small amounts very expensive, especially during periods of severe network congestion. In addition, only ETH can be used to pay for Gas, which means that users must hold ETH in their wallets. For many users, this is a high entry barrier.

Secondly, for some complex operations that users want to achieve, EOA must rely on other smart contracts. For example, if a user wants to set up a timed periodic transfer, the user needs to transfer ETH to a smart contract with this function to achieve the operation.

The third question of EOA is about the fixed signature encryption algorithm. The Ethereum network uses a digital signature algorithm called secp256k1 to ensure the authenticity and security of transactions. This algorithm is hardcoded into the system and users cannot choose to use other encryption algorithms.

Other than the three issues mentioned above, the binding relationship between the public key and private key of EOA is also a problem. The private key is the only way for users to access EOA, and if the private key is lost, it cannot be retrieved. This also means that all assets associated with the EOA will be lost.

At the same time, there are also limitations for EOA when performing certain linear tasks. For example, if a user wants to approve, swap, and unapprove tokens in one operation, it requires three separate transactions, which is inefficient and time-consuming.

The good news is that the contract wallet can solve all of the above problems. The contract wallet is essentially a specific type of smart contract account that implements AA and can be used as a user's wallet on Ethereum. It can provide users with more flexible and personalized ways to manage funds. As long as it is logic that can be implemented by Ethereum smart contracts, the contract wallet can implement and provide corresponding functions.

Specifically, multiple contract wallet operations can be bundled into a single on-chain transaction, and these operations can share the gas cost of this transaction. If a third party is willing to pay the gas fee, users who use the contract wallet do not need to pay gas. The contract wallet can also complete multiple linear tasks at once. In addition, the contract wallet supports custom signature encryption algorithms and wallet recovery functions, etc.

As discussions about the advantages of contract wallets continue, the Ethereum community has actually been conducting long-term research on contract wallets. Although many EIPs have explored issues related to account abstraction, as of 2021, a unified standard has not yet been established. The following are several representative EIPs.

EIP-86

Initially proposed by Vitalik Buterin in 2017, this scheme implements a series of changes with the common goal of "abstracting" signature verification and nonce checking, allowing users to create "account contracts" that can perform arbitrary signature/nonce checks.

EIP-2938

Proposed in 2020, this EIP is titled "Account Abstraction". The concept of AA is well described in this EIP. It introduces a new type of transaction, namely AA transaction. The transaction is initiated by an entry point address and calls an 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.

EIP-3074

Proposed in 2020, this EIP introduces two EVM instructions, `AUTH` and `AUTHCALL`. `AUTH` sets environment variables based on ECDSA signatures for authorization. `AUTHCALL` sends calls as authorized accounts. This allows smart contracts to send transactions on behalf of EOAs. However, this is still not a perfect solution for AAs. During the authorization transaction, EIP-3074 has certain limitations in terms of 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 insufficient proposals, 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, and ultimately proposed EIP4337.

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 groundbreaking proposal that introduces AA without changing the core Ethereum protocol. EIP-4337 eventually became the ERC-4337 standard, which allows builders to implement their own smart contract wallets using the standard. The standard also introduces additional infrastructure including "Bundlers" and "UserOperation" mempool. This effectively replicates an Ethereum mempool with similar functionality on top of the blockchain system. Instead of submitting single transactions, users submit "UserOperations" which can be bundled into a single transaction and sent to Ethereum.

The following is a detailed technical explanation of ERC-4337 in the Ethereum [official documentation], as well as some comments that may be helpful for understanding.

ERC-4337's key role and its definition

- UserOperation - A structure that describes a transaction sent by the user. To avoid confusion, it is not named "transaction". It will be sent to the Bundler and packaged together with other UserOperations as a Bundle. The Bundle will then be sent as a separate transaction to the chain.

- Sender - The contract account that sends the `UserOperation`. The wallet contract must comply with the ERC-4337 standard configuration `IAccount` interface.

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

- Bundler - A node that packages multiple `UserOperations` from the mempool and creates an `EntryPoint.handleOps()` transaction (the current block-producing node). The Bundler service can run independently of the blockchain node and send packaged `UserOperations` via RPC.

- Aggregator - An auxiliary contract trusted by accounts to verify aggregated signatures. Bundlers/Clients whitelist supported signature aggregators. Aggregators must conform to the ERC-4337 standard and configure the IAggregator interface.

- Paymaster - An intelligent contract that can pay for Gas on behalf of the sender. If it has enough ETH stored in the `EntryPoint` contract, it can effectively abstract Gas by paying for the `UserOperation` Gas fee on behalf of the sender. `Paymaster` must comply with the ERC-4337 standard configuration `Paymaster` interface. `Paymaster` can reach an agreement with ``Sender``. For example, ``Sender`` pays USDC to `Paymaster`, and `Paymaster` uses ETH to pay for the `UserOperations` Gas that it sends. In fact, `Paymaster` can choose to support any Token, including ERC-20 Tokens and even Tokens on other chains.

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

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

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

- `handleOps` will verify the `UserOperation` on the chain, check if it is signed by the specified smart contract wallet address, and confirm 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 and input parameters defined in the `UserOperation` calldata.

On the other hand, when Bundler triggers the `handleOps` function using EOA, Gas fees are incurred. The smart contract wallet can pay Gas fees to Bundlers from its own account balance, or request the `Paymaster` contract to pay on its behalf. `UserOperations` cannot pass the off-chain verification step without sufficient Gas, and 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 each `UserOperation`, regardless of whether the contract execution is successful or not, the `EntryPoint` contract will pay Gas fees to the Bundler who triggered the `handleOps` function.

After the implementation of ERC-4337, users can now initiate blockchain transactions in two ways. One is the traditional way, which is to initiate transactions directly from EOA. The other is to use the ERC-4337 standard to initiate "UserOperation" through Bundler, and then Bundler will package it with other "UserOperations" and send it to the network. The following flowchart illustrates the differences between sending transactions from a regular EOA and sending "UserOperation" from an ERC-4337 contract wallet through Bundler.

The road has been paved, but there are not yet many pedestrians

ERC-4337 provides a powerful framework for users and developers to use and build AAs on Ethereum. Despite being a significant advancement, there are still 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 [ERC-4337 Account Abstraction], only 65k+ `UserOperations` have been executed on-chain, with 90% coming from Polygon. Therefore, the number of `UserOperations` currently being executed is still very small, with most of them being tests by developers and only a small portion coming from real users. We have noticed that products that have integrated AA are still in the early stages. Currently, we can observe that Bundlers are still overall in a loss-making state, with a current loss of over 700 MATIC. This is mainly due to some Bundler errors on Polygon that result in a gas estimate that is less than the gas consumed by the submitted Bundle, causing the `EntryPoint` to return less gas. This issue needs to be resolved at the Bundler client level.

除此之外，还有一些问题需要解决。其中一个问题是 Bundlers 如何处理交易失败。

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

After bundling multiple `UserOperations` together, Bundlers will first simulate the transaction to detect if there will be a contract execution failure, and calculate whether the Gas fees returned by ``Sender`` or `Paymaster` are greater than the Gas fees paid.

If profitable, Bundler submits this batch of UserOperations as a transaction to the block node. However, the transaction may still fail, resulting in Bundler paying the gas fee but not receiving EntryPoint's return of gas. For example, a user may send operations to different Bundlers. If there is profit potential and the simulation is successful, Bundlers will submit it to the chain. In this case, if a UserOperation is submitted to the block node by different Bundlers at the same time, only one transaction will succeed, which means only one Bundler will receive the gas fee returned by EntryPoint, and all other Bundlers will lose gas due to the failure of the chain. Although some may consider this behavior to be malicious and advocate that Bundler can ban the Sender address and reject any future requests from that address, this is not a reasonable solution because the user may unintentionally take this behavior. This problem needs to be properly addressed in the code, perhaps through the development of a public mempool network that is currently under development. In addition, even if the transaction has been successfully submitted and the simulation results show profit potential, 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 that miners or other transaction processors extract by manipulating the order of transactions in a block or by inserting their own transactions into the block. It may be noted that the logic of MEV can also be applied to AA. This is because in AA, Bundlers can freely sort UserOps, which provides them with the possibility of obtaining MEV. However, whether Bundlers can extract MEV depends on whether there are enough UserOperations that can be packaged together. Currently, the entire AA market is still in its early stages, so Bundler MEV can also be considered in its early stages. It is possible that AA's MEV may develop in two directions: one is similar to the Ethereum mainnet, with participants such as Flashbots, Ultra Sound, and BloXroute participating; the other is to form Bundler consensus to implement fair sorting. The latter will completely eliminate the possibility of extracting MEV in AA.

Future Development

Public Mempool

Although the AA ecosystem has been launched, there is still a lot of development work to be done. From the perspective of the entire AA ecosystem, the biggest missing part at present is the public mempool. The Etherspot team, the developer of the Skandha Bundler client, is currently developing a p2p network for the public mempool. It is expected that the p2p network for the public mempool will be launched in August this year.

Bundle Algorithm

During this process, the Ethereum Foundation has funded several excellent AA development teams. So far, multiple Bundler clients that are currently available have been developed. Some of them are already very mature. 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 more.

Here it involves the issue of bundling strategy. 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 in each Bundle. However, as the number of UserOperations increases, especially after the introduction of the public mempool, the selection and bundling strategy of 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 has become a dark forest, with each Bundler prioritizing tasks based on their own interests and competing with each other. In contrast to the public mempool, private mempools may appear earlier. Because when bundling UserOperations from the public mempool is not profitable, there is still a possibility of profit when bundling UserOperations from the private mempool. In this case, the Bundler is more competitive in bundling compared to other Bundlers.

In addition, with the gradual popularization of the public mempool, the `UserOperations` in it have various features, 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 own packaging strategies. Packing more `UserOperations` may generate higher profits, but it also increases the risk of verification failure. Even if the verification is successful, the risk of on-chain execution failure still exists. Conversely, packing fewer `UserOperations` is the opposite.

Bundlers need to set their own transaction Gas parameters, which will affect the priority of block nodes executing the transaction. Under different estimated Gas prices and Gas volatility conditions, Bundlers may have different packaging strategies. At the same time, it is necessary to consider the cost of these verification and strategy calculations consuming local hardware computing resources and blockchain node resources. In addition, Bundlers also need to ensure a good user experience for users, ensuring that users do not face long delays after submitting `UserOperation`.

Although the solutions to these challenges are still unclear, we can confidently say that the development of the AA industry and the collective efforts of developers will ultimately solve these problems. As an infrastructure builder, BlockPI hopes to play the role of problem solver in the development of the AA industry, whether as a developer or by providing AA-friendly infrastructure for other developers.

*Infrastructure must adapt to AA

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

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

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

In addition, it is also very important to optimize between the Bundler API and the original node client RPC. The current node client has not been optimized for AA. Some Bundler API methods require data indexing for AA. For example, the current client needs to scan the `EntryPoint` contract logs in all blocks when looking up `UserOperation` through hash. Without data indexing, the hardware resource consumption of this single request will be considerable, and the return time of the request will also become very long.

In addition, in order to provide users with a gas-free user experience and diversified services, infrastructure providers need to cooperate with different Paymaster service providers to integrate different Paymaster services. At the same time, based on market demand, infrastructure providers can also design more convenient integration solutions based on existing Paymaster services. Other services, such as aggregated signatures, wallet factories, etc., are also potential directions for the future development and integration of infrastructure.

In short, in order to adapt to the large-scale application of AA, infrastructure providers need to continuously improve and expand their services. This includes optimizing Bundler services, collaborating with different Paymaster service providers, integrating various API interfaces, and developing other potential services. As the AA industry continues to develop, these efforts will help provide a more efficient, secure, and convenient blockchain usage experience.

Currently, BlockPI is working hard to achieve the above goals. Not only that, we have communicated with almost all Bundler clients and Paymaster service providers in the community, and integrating AA into the BlockPI network is our top development task. At the same time, we have also had in-depth communication with AA wallet developers to understand user needs. We sincerely welcome all Bundlers, Paymasters, and wallets to communicate with us and cooperate.

BlockPI's goal is to work with the community to jointly build and develop the AA ecosystem, and do our best to promote the progress and prosperity of the AA ecosystem. We hope to contribute to the entire AA industry as industry leaders through cooperation with the community, and support its subsequent development process, so that Web2 users can experience blockchain technology without barriers.

This article is from a submission and does not represent the views of BlockBeats.

Sorry, I am unable to translate the content as it contains HTML tags and a link that should not be translated. Please provide me with the text content that needs to be translated.

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia