How infrastructure supports billions of users through account abstraction

Infrastructure's support for billions of users with account abstraction.

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

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

EOA and Contract Wallets

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

First of all is the issue of gas fees. Each transaction will cost the user a considerable amount of ETH as gas fees (for example, the gas fee for a simple ETH transfer is about $0.5 at a gas price of 25 Gwei, which can be even more expensive for contract interaction or when the gas price is higher). This makes the handling fees of small transactions 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, which is a high entry barrier for many users.

• Page 181: A Comprehensive Review of Coinbase Legal Documents: Strong Response to SEC Lawsuit and Seeking to Dismiss the Case
• The growth engine of the DeFi field: a detailed explanation of the four innovative mechanisms of Uniswap V4
• MPC+AA is the path that Crypto wallets with a billion users must go through for Mass Adoption.

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 periodic timed transfers, the user needs to transfer ETH to a smart contract that has this function to achieve this operation.

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

In addition to the above three problems, 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. If the private key is lost, it cannot be retrieved. This also means that all assets associated with the EOA cannot be retrieved.

However, EOA also has limitations when it comes to performing certain linear tasks. For example, if a user wants to approve, swap, and unapprove tokens in one operation, they would need to perform three separate transactions, which is inefficient and time-consuming.

The good news is that a contract wallet can solve all of these issues. A 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 a more flexible and personalized way of managing their funds. As long as it can be implemented with Ethereum smart contract logic, a contract wallet can provide corresponding functions.

Specifically, multiple contract wallet operations can be bundled into one on-chain transaction, which can spread the Gas cost of this transaction among these operations. If a third party is willing to pay the Gas fee, users who use contract wallets do not need to pay Gas. Contract wallets can also complete multiple linear tasks at once. In addition, contract wallets support customized signature encryption algorithms and wallet recovery settings, among other things.

As the discussion about the advantages of contract wallets continues, the Ethereum community has actually been conducting long-term research on contract wallets. Although many EIPs have explored account abstraction-related issues, there is still no unified standard as of 2021. Here are several representative EIPs.

EIP-86

Originally proposed by Vitalik Buterin in 2017. The proposal implements a series of changes, the common purpose of which is to “abstract” signature verification and nonce checking, allowing users to create “account contracts” that can perform arbitrary signature/nonce checks.

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, the AA transaction, which 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 to 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 the authorized account. This allows smart contracts to send transactions on behalf of EOA. However, this is still not a perfect solution for AA. There are some limitations in native value transfer during the authorization transaction. And if a user loses access to their EOA, they will still be unable to recover their assets. If the private key is compromised, the user will need to transfer all their assets to a new account.

Due to the need for changes at the consensus layer or insufficiently comprehensive 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 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 Blockingtel, Dror Tirosh, Shahaf Nacson, and Tjaden Hess.

EIP-4337 is a groundbreaking proposal that can introduce AA without changing the Ethereum core protocol. EIP-4337 eventually became the ERC-4337 standard, which builders can use to implement their own smart contract wallets. At the same time, the standard also introduces some additional infrastructure, including “Bundlers” and “UserOperation mempool.” In this way, it actually replicates an Ethereum mempool with similar functions on the upper layer of the blockchain system. Users no longer submit single transactions, but UserOperations. Multiple UserOperations can be packaged into a single transaction and sent to Ethereum.

The following is a detailed technical explanation of ERC-4337 in the Ethereum [official documentation](https://eips.ethereum.org/EIPS/eip-4337), as well as some comments that are helpful for understanding.

Key roles and their definitions in ERC-4337

– UserOperation – Describes the structure that represents the transaction sent by the user. To avoid confusion, it is not named “transaction”. It will be sent to the Bundler and packaged with other UserOperations into a Bundle. Then the Bundle will be sent as a separate transaction to the chain.

– Sender – The contract account that sends 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 EntryPoints they support. The contract is audited and approved for deployment by the Infinitism team, responsible for handling all UserOperations and connecting contracts of other roles, including Wallet Factory, Aggregator, and Blockingymaster. This contract is the same address on EVM-compatible chains.

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

– Aggregator – An auxiliary contract trusted by the account for verifying aggregated signatures. Bundlers/Clients will whitelist the supported signature aggregators. The Aggregator must comply with the ERC-4337 standard configuration IAggregator interface.

– Blockingymaster – An intelligent contract that can pay for Gas on behalf of users. If it deposits enough ETH in the EntryPoint contract, it can pay for the Gas fee of the UserOperation sent by the sender, effectively abstracting the Gas. The Blockingymaster must comply with the ERC-4337 standard configuration Blockingymaster interface. The Blockingymaster can reach an agreement with the Sender. For example, the Sender pays USDC to the Blockingymaster, and the Blockingymaster uses ETH to pay for the Gas of the UserOperations it sends. In fact, the Blockingymaster 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 a license. 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 be audited by professionals.

The figure below 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 the chain, check whether it is signed by the specified smart contract wallet address, and confirm whether the wallet has enough Gas to compensate the Bundler.

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

On the other hand, when the Bundler triggers the handleOps function using EOA, Gas fees will be generated. The smart contract wallet can pay Gas fees to Bundlers from its account balance, or request the Blockingymaster contract to pay on its behalf. UserOperations cannot pass the off-chain verification step without sufficient Gas, and fail before the transaction is executed on the chain. Even if there is enough Gas, UserOperations may still fail during execution due to runtime errors and other reasons. For a UserOperation, regardless of whether the execution of the contract is successful or not, the EntryPoint contract will pay the Gas fee to the Bundler who triggered the handleOps function.

(Taken from official documentation: https://eips.ethereum.org/EIPS/eip-4337 )

After ERC-4337 takes effect, users can now initiate blockchain transactions in two ways. One is the traditional way, where EOAs directly initiate transactions. The other is to use the ERC-4337 standard and initiate UserOperations via Bundlers, which will then be packaged with other UserOperations and sent to the chain. The following flowchart illustrates the difference between sending transactions from a regular EOA and sending UserOperations from an ERC-4337 contract wallet.

The road is paved, but there are not many pedestrians

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

The adoption of AAs is still in its early stages. According to the Dune ERC-4337 analysis panel (*[ERC-4337 Account Abstraction](https://dune.com/niftytable/account-abstraction)* from @niftytable), 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 fraction coming from real users. We note that products that have integrated AA are still in the early stages. Currently, we can see that Bundlers are still overall in a loss-making state, with a current loss of more than 700 MATIC. This is mainly due to some Bundler miscalculations of the required gas on Polygon, resulting in EntryPoint returning less gas than the bundle consumes. This issue needs to be addressed at the Bundler client level.

In addition, there are other 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 transaction to detect whether contract execution failures will occur and calculate whether the gas fees returned by Sender or Blockingymaster are greater than the gas fees paid.

If it is profitable, the Bundler will submit this batch of UserOperations as a transaction to the block producer node. However, the transaction may still fail, causing the Bundler to pay gas fees but not receive gas returned by EntryPoint. For example, a user may send operations to different Bundlers. If there is room for profit and the simulation is successful, the Bundlers will submit it to the chain. In this case, if a UserOperation is submitted to the block producer node by different Bundlers at the same time, only one transaction will be successful, which means that only one Bundler will receive the gas fee returned by EntryPoint, and all other Bundlers will lose gas due to the failure to go on-chain. Although some may consider this behavior to be a malicious attack and advocate that the Bundler can ban the Sender address and refuse any future requests from that address, this is not a reasonable solution as users may unintentionally adopt this behavior. This issue needs to be properly addressed in the code, perhaps through the public mempool being developed. In addition, even if the transaction has been successfully submitted and the simulation result shows that there is room for profit, Bundlers may also 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 applicable to AA. This is because in AA, Bundlers can freely order UserOps, which provides them with the possibility of obtaining MEV. However, whether Bundlers can extract MEV depends on whether there are enough UserOperations to be bundled together. Currently, the entire AA market is still in its infancy, so Bundler MEV can also be considered as being in its early stages. It is possible that the MEV of AA may develop in two directions: one is similar to the Ethereum mainnet, with participants like Flashbots, Ultra Sound, and BloXroute involved; 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 largest 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 public mempool’s p2p network will be launched in August of this year.

Bundle Algorithm

In this process, several excellent AA development teams have been funded by the Ethereum Foundation. So far, several Bundler clients that can be used 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), etc.

Here, the issue of bundle strategy comes into play. Currently, due to the small number of UserOperations, Bundlers can adopt simple packaging 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 packaging UserOperations becomes more complex. The reason is simple: in the AA ecosystem, there is a lack of a mechanism similar to the blockchain consensus protocol, and the Bundler community has become a dark forest, with each Bundler prioritizing tasks according to their own interests and competing with each other. In contrast to the public mempool, private mempool may appear earlier. This is because when bundling UserOperations from the public mempool is not profitable, there is still a possibility of profit in bundling UserOperations from the private mempool. In this case, the Bundler is more competitive in bundling compared to other Bundlers.

Furthermore, as the public mempool becomes more widespread, UserOperations within it have various features, such as different Gas profit expectations and on-chain execution complexity. Bundlers will perform off-chain simulations to evaluate the profitability of various combinations of UserOperations, thus establishing their own bundling strategies. Bundling more UserOperations may generate higher profits, but it also increases the risk of verification failure. Even if verification is successful, there is still a risk of on-chain execution failure. Conversely, bundling fewer UserOperations is the opposite. Bundlers need to set their own transaction Gas parameters, which will affect the priority of execution of this transaction by the block-producing node. Under different estimated Gas prices and Gas volatility conditions, Bundlers may have different bundling strategies. Also, the cost of these verifications and strategy calculations in terms of local hardware computational resources and blockchain node resources needs to be taken into account. Additionally, Bundlers need to strive to provide a good user experience, ensuring that users do not face long delays after submitting UserOperations.

Although solutions to these challenges are still unclear, we can confidently say that the development of the AA industry and the joint 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, either 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 Blockingyers, contract wallets, and Signers, giving users greater freedom when using blockchain. At the same time, infrastructure providers can independently deploy these services based on their own judgment of the market.

To adapt to the widespread adoption of AA, infrastructure providers first need to offer at least two basic services: Bundler service and Blockingymaster service.

In the Bundler service, infrastructure providers may need to develop a private mempool 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 several standard JSON RPC methods to users, which are provided by the ERC-4337 core development team. It can be foreseen that more RPC methods will be available to users in the future. Infrastructure service providers need to update their support for these methods in a timely manner.

Additionally, it is also 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 the node to provide data indexing for AA. For example, the current client needs to scan the EntryPoint contract logs in all blocks 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.

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

In summary, 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, cooperating with different Blockingymaster 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.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!