How does infrastructure support billions of users through account abstraction?

Whether it is a bull market or a bear market, the Ethereum ecosystem is constantly building and self-optimizing. Among them, Account Abstraction (AA) has made important progress in recent years and has penetrated into all parts of the Ethereum ecosystem, including applications, infrastructure, users, and developers. We can foresee that the large-scale adoption of AA will lower the threshold of blockchain usage as a whole and introduce the user experience of web2 into the web3 industry.

To capture the opportunity of the potentially multi-billion dollar AA market, BlockPI plans to integrate AA into its infrastructure services. Through integration and innovation in the AA field, BlockPI is committed to providing AA users with a more convenient and efficient way to interact with blockchain contract wallet accounts, and hopes to become a leader in this industry.

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

EOA and contract wallet

The concept of AA stems from the limitations of EOA accounts. An EOA account (external owned account) is a user account in Ethereum, represented by a public key (blockchain address) and accessed through a private key. It is a major component of the Ethereum ecosystem, allowing users to transfer money on the blockchain or interact with smart contracts. However, for many people, using an EOA can be a challenging task in itself. Moreover, the current EOA account still has some inconveniences in use, which affects the user experience.

The first is the issue of gas fees. Each transaction will cost the user a considerable amount of ETH as a Gas fee (take the Gas price of 25 Gwei as an example, the Gas fee for a simple ETH transfer is about 0.5 US dollars, and it will be more expensive for contract interaction or when the Gas price is higher) . This makes 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 constitutes a high barrier to entry for many users.

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 a timed periodic transfer, the user needs to transfer ETH to a smart contract with 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. This 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 EOA's public key and private key is also a problem. The private key is the only way for users to access EOA, if the private key is lost, it will not be retrieved. This also means that all assets within the EOA associated with it will be irretrievable.

At the same time, EOA also has limitations when performing certain linear tasks. For example, if a user wishes to approve (approve), exchange (swap) and unapprove tokens (unapprove token) in one operation, three separate transactions need to be performed, which is inefficient and time-consuming.

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

Specifically, multiple contract wallet operations can be packaged into an on-chain transaction, and these operations can share the Gas cost of this transaction. If the third party is willing to pay the Gas fee, there is no need to pay Gas for users using the contract wallet. Contract wallets can also complete multiple linear tasks at one time. In addition, the contract wallet also supports the encryption algorithm of custom signatures, and sets the function of wallet recovery and so on.

As the discussion of the advantages of contract wallets continues, the Ethereum community has actually conducted long-term research on contract wallets. Although many EIPs have explored issues related to account abstraction, as of 2021, no unified standard has been established. Below are several representative EIPs.

EIP-86

Originally proposed in 2017 by Vitalik Buterin. This scheme implements a series of changes with the common purpose of "abstracting" signature verification and nonce checking, thus enabling users to create "account contracts" that can perform arbitrary signature/nonce checking.

EIP-2938

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

EIP-3074

Presented in 2020. This EIP introduces two EVM instructions, AUTH and AUTHCALL. AUTH sets environment variables according to the ECDSA signing authority. AUTHCALL sends the call as an authorized account. This allows smart contracts to send transactions on behalf of EOA. But this is still not a perfect solution for AA. In the authorization transaction process, EIP-3074 has certain restrictions on the transmission of original value. And if the user loses access to the EOA, there is still no way to get his assets back. If the private key is leaked, the user needs to transfer all assets to the new account.

None of the above proposals were formally incorporated into the Ethereum protocol due to the need for changes at the consensus layer or because the proposals were not comprehensive enough. Therefore, the Ethereum community continued to explore how to introduce AA into the Ethereum protocol without changing the consensus, and finally proposed EIP4337.

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 disruptive proposal that would introduce AA without changing the core Ethereum 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. What the user submits is no longer a single transaction, but a UserOperation. These UserOperations can be packaged into a single transaction and sent to Ethereum.

The following is a detailed technical explanation of ERC-4337 in Ethereum [official documentation], with some helpful comments.

Key roles of ERC-4337 and their definitions

• UserOperation—describes the structure of a transaction sent on behalf of a user. To avoid confusion, it is not named "transaction" and it will be sent to the Bundler to be packaged together with other UserOperations as a Bundle. The Bundle is then sent on-chain as a single transaction.

• Sender—the contract account that sends UserOperation. The wallet contract must follow the ERC-4337 standard to configure the IAccount interface.

• EntryPoint - the global singleton contract that executes the UserOperations bundle. Bundlers/Clients whitelist supported EntryPoints. The contract is audited and approved for deployment by the Infinitism team, and is responsible for handling all UserOperations and connecting contracts with other roles, including Wallet Factory, Aggregator, and Paymaster. The contract is all at the same address on the EVM compatible chain.

• Bundler—The node that packs multiple UserOperations from the mempool and creates the EntryPoint.handleOps() transaction (the current block producer node). The Bundler service can run independently of blockchain nodes 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 configure the IAggregator interface following the ERC-4337 standard.

• Paymaster—a smart contract that can pay Gas on your behalf. If it deposits enough ETH in the EntryPoint contract, it can pay the sender the smart contract for UserOperation's Gas fee, effectively implementing the Gas abstraction. Paymaster must follow the ERC-4337 standard to configure the Paymaster interface. Paymaster can make an agreement with Sender. For example, Sender pays USDC to Paymaster, and Paymaster uses ETH to pay the Gas of the UserOperations it sends. In fact, Paymaster can choose to support any

Token

, including ERC-20

Token

even other chains

Token

。

• Wallet Factory—a smart contract that can create contract wallets for ERC-4337 users. Deploying Wallet Factory is license-free. As an on-chain smart contract, its code is open to the public and anyone can review it. A 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 accepts a UserOperation as input.

• handleOps will verify 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 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 Bundler uses EOA to trigger the handleOps function, a Gas fee will be incurred. The smart contract wallet can pay Bundlers Gas fees from its own account balance, or request the Paymaster contract to pay for it. UserOperations cannot pass the off-chain verification step without enough Gas, that is, it fails before executing the transaction on the chain. Even if there is enough Gas, UserOperations may still fail due to runtime errors and other reasons during execution. 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 that triggers the handleOps function.

After ERC-4337 takes effect, users can now initiate blockchain transactions in two ways. One is the traditional way, that is, the EOA directly initiates the transaction. 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 chain. The flow chart below illustrates the difference between a normal EOA send transaction and an ERC-4337 contract wallet send UserOperation.

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

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

The adoption of AA is still in its infancy. According to the Dune ERC-4337 analysis panel [ERC-4337 Account Abstraction], only 65k+ UserOperations were executed on the chain, 90% of which came from Polygon. Therefore, the number of UserOperations currently performed is still very small, most of which are developer tests, and only a small part comes from real users. We note that products that have integrated AA are still in their early stages. At present, we can observe that Bundlers as a whole is still in a state of loss, and the current loss is about more than 700 MATIC. This is mainly caused by some Bundlers on Polygon misestimating the gas required, resulting in the Gas returned by EntryPoint being less than the gas consumed by the submitted Bundle. This problem needs to be solved at the Bundler client level.

Beyond that, there are a few issues that need to be addressed. One such issue is how Bundlers handle transaction failures.

After packaging multiple UserOperations together, Bundlers will first simulate the transaction, detect whether there will be contract execution failure, and calculate whether the Gas fee returned by Sender or Paymaster is greater than the paid Gas fee.

If it is profitable, Bundler submits this batch of UserOperations to the block node as a transaction. However, it is still possible for the transaction to fail, resulting in the Bundler paying the Gas fee but not receiving the Gas refund from the EntryPoint. For example, a user might send actions to different Bundlers. If there is room for profit and the simulation is successful, Bundlers commit 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 that only one Bundler will receive the Gas fee returned by the EntryPoint, and all other Bundlers will fail due to chaining And lose Gas. Although one might argue that this behavior should be considered a malicious attack, and argue that Bundler can ban the Sender address and reject any future requests from that address, this is not a reasonable solution because users may take this action unintentionally. Behavior. This issue needs to be properly addressed in code, perhaps through a public mempool network that is under development. Furthermore, Bundlers may suffer losses due to sudden gas fluctuations even if the transaction is successfully submitted and the simulation results show that there is room for profit.

Another issue is the maximum extractable value (MEV) that can be obtained from AA. In the context of Ethereum, MEV generally refers to the value that miners or other transaction processors extract by manipulating the order of transactions in a block or inserting their own transactions in a block. One might notice that the logic of MEV can also be applied to AA. This is because in AA, Bundlers can freely order UserOps, which provides them with the possibility to acquire MEV. However, whether Bundler can extract MEV depends on whether enough UserOperations can be bundled together. Now the entire AA market is still in its infancy, so Bundler MEV can also be considered in its infancy. It can be seen that AA's MEV may develop in two directions: one is similar to the Ethereum mainnet, with the participation of participants such as Flashbots, Ultra Sound and BloXroute; the other direction is to form a Bundler consensus to implement fair sorting. The latter would completely eliminate the possibility of extracting MEVs in AA.

future development

public mempool

While 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 missing piece right now is the public mempool. The Etherspot team, developers of the Skandha Bundler client, are currently developing a p2p network with a public mempool. A p2p network of public mempools is expected to launch in August of this year.

Bundle algorithm

Along the way, the Ethereum Foundation has funded several outstanding AA development teams. So far, several Bundler clients have been developed and are currently available. Among them, some are very mature. 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), etc.

Here comes the issue of packaging strategy. 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 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: in the AA ecosystem, there is no mechanism similar to the blockchain consensus protocol, and the Bundler group has become a dark forest. Each Bundler prioritizes tasks according to their own interests and competes with each other. As opposed to public mempools, private mempools may appear earlier. Because when it is not profitable to package UserOperations from the public mempool, it is still possible to package UserOperations in the private mempool. In this case, the Bundler is more competitive with other Bundlers when packaging.

In addition, with the gradual popularization of the public mempool, the UserOperations in it have various 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 respective bundling strategies. Packing more UserOperations has the potential to generate higher profits, but it also increases the risk of validation failures. Even if the verification is passed, the risk of execution failure on the chain still exists. In contrast, UserOperations with less packaging is the opposite.

Bundlers need to set their own transaction gas parameters, which will affect the priority of block producers to execute this transaction. Under different estimated Gas price and Gas volatility conditions, Bundlers may have different packaging strategies. At the same time, it is also necessary to consider the cost of local hardware computing resources and blockchain node resources for these verification and policy calculations. In addition, Bundlers also need to ensure a good user experience for users and ensure that users do not face excessive delays after submitting UserOperations.

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

*Infrastructure must adapt to AA

AA abstracts the various roles involved in on-chain transactions, including Sender, Bundlers, Gas payers, contract wallets, and Signers, so that users have a higher degree of freedom when using the blockchain. At the same time, infrastructure providers can independently deploy these services according to their own judgment on the market.

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 Bundler service, infrastructure provider may need to develop private mempool together with Bundlers to provide good user experience. Specifically, infrastructure providers need to integrate various Bundler clients to ensure the stability of Bundler services. These Bundler clients currently provide users with several standard JSON RPC methods provided by the ERC-4337 core development group. It is foreseeable that more RPC methods will be available to users in the future. Infrastructure service providers need to update support for these methods in a timely manner during this process.

Also, it's important to optimize between the Bundler API and the origin node client RPC. The current node client is not optimized for AA. Some Bundler API methods require an index against the data provided for the AA. For example, when the current client looks up UserOperation by hash, it needs to scan the EntryPoint contract logs in all blocks. If there is no data index, the hardware resource consumption of this single request will be quite huge, 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, according to market demand, infrastructure providers can also design more convenient integrated solutions based on existing Paymaster services. Other services, such as aggregated signatures, wallet factories, etc., are also potential directions for 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, cooperating 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 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 will integrate AA into the BlockPI network as our top development task. At the same time, we also conducted in-depth communication with AA wallet developers to understand user needs. We sincerely welcome all Bundlers, Paymasters and wallets to communicate and cooperate with us.

The goal of BlockPI is to build and develop the AA ecosystem together with the community, and do everything possible to promote the progress and prosperity of the AA ecosystem. We hope that through cooperation with the community, we will contribute to the entire AA industry as an industry leader and support its subsequent development process, so that Web2 users can experience blockchain technology without barriers.