How to Empower Infrastructure to Service a Billion-Strong User Base with Account Abstraction

How to Empower Infrastructure to Service a Billion-Strong User Base with Account Abstraction

Author: Albert He, BlockPI Cheif Scientist

Regardless of bull or bear markets, the Ethereum ecosystem has been continuously building, and constantly self-optimizing. Among them, Account Abstraction (AA) has been a very important progress in recent years, and has penetrated into various components of the Ethereum ecosystem, including applications, infrastructure, users, and developers.

We can foresee the potentials of widespread adoption of AA for lowering down the barrier of the blockchain use case and thus introducing web2 user experience to web3 industry.

To embrace the possibility of forming an AA market worthy of billions, BlockPI plans to dedicate resources to integrating AA into its infrastructure service. By building on the integration of AA, we aim to provide AA users with a more convenient and efficient way to interact with their contract wallet accounts on the blockchain, while also positioning BlockPI as a leader in the industry.

In this article, I will delve deeper 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 origins from the limitations of EOA accounts. EOA account (external owned account) is the typical user account in Ethereum represented by a public key (blockchain address) and is accessible by a private key. It is one of the primary components of the Ethereum ecosystem, allowing users to interact with smart contracts and execute transactions on the network. However, using an EOA can be challenging for people, with certain inconveniences that can impact the user experience.

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

The second inconvenience of the EOA is the inability to conduct conditional transactions without the use of other smart contracts to realize certain logic. For example, if users want to set up a timed periodic transfer, they must transfer ETH to a third-party smart contract with this functionality to implement this feature.

The third inconvenience of the EOA is the signature encryption algorithm. The Ethereum network uses a specific digital signature algorithm called secp256k1 to ensure the authenticity and security of transactions. It is hard-coded into the system, and users cannot choose to use an alternative algorithm.

Other than the three inconveniences of EOA mentioned above, the binding relationship between public keys and private keys is also an issue. The private key is the only way to access an EOA, and there is no way to recover the private key if it is lost. This implies that if the private key is lost, all the assets associated with it will be irretrievable.

Also, the EOA faces constraints when it comes to executing linear tasks in a single transaction. For example, if users wish to approve, swap, and unapprove tokens in one action, they would need to execute three separate transactions, which is inefficient and time-consuming.

The good news is all the problems above can be solved with a smart contract wallet. Smart contract wallet is a specific type of smart contract that implements AA. It is designed to act as users’ wallet on the Ethereum network and provides a more adaptable and personalized way to manage their funds. As long as the logic can be realized by the Ethereum smart contract, a smart contract wallet can provide the desired functions.

Specifically, smart contract wallet transactions can be bundled together into one on-chain transaction to share the Gas cost, and there could even be no Gas cost if a third party is willing to pay for it. One operation can facilitate the execution of sequential tasks within its smart contract wallet. Smart contract wallet is able to support any encryption algorithm as signature, and set the recovery code, etc.

With all the benefits of smart contract wallets being discussed among people, the Ethereum community has actually been doing research on contract wallets for a long time since the beginning. Although numerous EIPs have been proposed to explore account abstraction, no unified standard has yet to be established till 2021. The following are several of the most representative proposals.

• EIP-86 Initially created by Vitalik Buterin in 2017. Implements a set of changes that serve the combined purpose of “abstracting out” signature verification and nonce checking, 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. The concept of AA is well described in this EIP. It introduced a new type of transaction, the AA transaction. The transaction will be initialized by the EntryPoint address and calls the AA wallet contract. By doing this, it provided a unified specification and introduced AA into the Ethereum consensus. To be more specific, it adds two new opcodes, three global variables and a different payload structure into the Ethereum consensus.
• EIP-3074 Created in 2020. This EIP introduces two EVM instructions, AUTH and AUTHCALL. The AUTH sets a context variable authorized based on an ECDSA signature. The AUTHCALL sends a call as the authorized account. This allows a smart contract to send a transaction on behalf of an EOA. But it is still not a perfect solution for AA. There are certain limitations for EIP-3074 when it comes to native transfer of value during sponsored transactions. If you lose access to the EOA, you can not recover your assets and if compromised, all assets need to be transferred to a new account.

None of the aforementioned ideas were formally adopted into the Ethereum protocol due to the primary reason that it required changes on the consensus layer or was not comprehensive enough. Thus, the Ethereum community continued to explore how to introduce AA into the Ethereum protocol, but without changing the consensus, and eventually EIP4337 was created.

ERC — 4337

EIP-4337 was initially proposed in September 2021 and has been authorized to become 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 requiring any changes to the core Ethereum protocol. EIP-4337 leads to the ERC-4337 standard, which is something builders can use to implement into their own smart contract wallets, plus some additional infrastructure including “Bundlers” and UserOperation mempool. By doing this, it actually replicates the functionality of the transactions mempool in a higher-level system. Instead of sending transactions, users submit UserOperation objects, which can then be packaged into a single transaction and be included in the Ethereum chain.

Below is a more specific technical explanation of ERC-4337 from the official docs and some comments for better understanding.

The definitions and key roles of ERC-4337

• UserOperation — a structure that describes a transaction to be sent on behalf of a user. To avoid confusion, it is not named "transaction". It is sent to Bundler to be bundled with other UserOperations. Then the bundle is sent as a single transaction to the block builder.
• Sender — the contract account sending a new UserOperation. Smart contract wallets must implement the IAccount interface of ERC-4337.
• EntryPoint — a singleton contract to execute bundles of UserOperations. Bundlers/Clients whitelist the supported EntryPoint. This contract is approved and audited by the Infinitism team and responsible for handling all the UserOperations and connects 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 the mempool and creates an EntryPoint.handleOps() transaction. Not all validator nodes on the protocol level have to be Bundlers. Bundler service can be run independently from the block builder and use RPC to send the bundled UserOperations.
• Aggregator — a helper contract trusted by accounts to validate an aggregated signature. Bundlers/Clients whitelist the supported aggregators. Aggregators must implement the IAggregator interface of ERC-4337.
• Paymaster — a contract that can pay for the Gas of the UserOperation for the Sender, if it has deposited enough ETH within the EntryPoint contract to do so. The Paymaster enables Gas abstraction to be effectively realized. Paymasters must implement the Paymaster interface of ERC-4337. The Paymaster can have its own logic to make a deal with the Sender. For instance, a Sender pays USDC to a Paymaster and the Paymaster sponsors its UserOperations with ETH. Actually, any ERC20 tokens or even tokens on other chains can be supported as long as the Paymaster agrees and it is technically feasible.
• Wallet Factory — a contract that can be called to create a smart contract wallet for ERC-4337 users. It’s permissionless to deploy the wallet factory. Being on-chain, it is open to public audits and transparent scrutiny. A widely-used Wallet Factory should be fully audited 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 a UserOperation as input.
• handleOps verifies the UserOperation on-chain, checking whether it is signed by the specified smart contract wallet address and whether 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 the UserOperation.

On the other hand, when a Bundler triggers the handleOps function using EOA, Gas fees incur. The smart contract wallet can pay Gas fee to Bundlers from its own account balance, or alternatively, request a Paymaster contract to pay on its behalf. UserOperations without sufficient Gas cannot pass the verification process in the target smart contract wallet, resulting in failure before execution. Even with sufficient Gas, UserOperations may still fail during the execution process, for instance, as a result of runtime errors. Regardless of whether the execution is successful, the EntryPoint contract will pay Gas fee to the Bundler who triggers the handleOps function.

After ERC-4337 was effective, users now have two ways to initiate blockchain transactions. One is the original way where EOA initiates transactions. The other is to use the ERC-4337 standard to initiate a UserOperation through a Bundler, which will then be bundled with other UserOperations by the Bundler and be initiated on-chain. The following flowchart illustrates the differences between how a normal EOA sends transactions and how an ERC-4337 contract wallet sends a UserOperation.

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

ERC-4337 offers a powerful framework for users and developers to utilize and build with AA on the Ethereum platform. While this framework is an important step forward, there are still challenges and uncertainties that need to be addressed and resolved.

The adoption of AA is in a nascent stage. According to the Dune ERC-4337 analysis panel (ERC-4337 Account Abstraction from @niftytable), there are only 65k+ UserOperations executed on-chain, and 90% of them are from Polygon. Therefore, the number of UserOperation being executed is still very small at this time, and among all, developers’ testing takes the majority of it, while only a minor portion of it is attributed to users. We noticed that the products that have already integrated AA are still in their early stages. Meanwhile, it can be seen that the profit of the Bundler is negative (the number in MATIC is -700). This is because there are certain Bundlers on Polygon that are not calculating the right pre-verification gas. This verification algorithm still needs optimization.

Other than that, there are still some problems that should be resolved. One of the problems is how bundlers handle transaction failures. After a Bundler packages several UserOperations together, the Bundler first simulates the transaction to check if it will revert and then calculate whether the Gas fees returned by the Sender or Paymaster are greater than the Gas fees paid with the transaction. If profitable, the Bundler submits this batch of UserOperations in one transaction to the block builder. However, the transaction might still fail, causing the Bundler to pay for Gas fees without receiving the Gas returned from the EntryPoint. For example, Users may send operations to different bundlers. If any operations are profitable and their simulations are successful, bundlers are willing to submit them on-chain. That means if a UserOperation is submitted at the same time by different bundlers. Only one transaction will succeed, and only one bundler will receive the Gas fee feed from the EntryPoint, and all other bundlers will lose Gas because of on-chain failure. Although one might argue that the user should not behave this way and that such behavior would be considered a malicious attack, and the Bundler can ban the Sender address and refuse any future requests from this address, this is not a sound approach as the user may have unintentionally committed this action. Such a problem needs to be addressed properly in code, perhaps through the development of an unfinished public mempool network. In addition, Bundlers may also face losses due to sudden Gas fluctuations, even if the transaction has been successfully submitted and was simulated to be profitable.

Another thing is the Maximal Extractable Value (MEV) from the AA. In the context of Ethereum, MEV typically 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. Have people noticed that the logic of MEV could also apply to AA, as Bundlers can freely sort UserOperations? However, this is conditional on having enough UserOperations bundled together for Bundlers to extract MEV. Now the entire AA market is still in its early stages, thus Bundler MEV can also be considered early-stage as well. As all being said, the AA industry may develop in two directions: one is similar to the Ethereum mainnet, with players such as Flashbots, Ultra Sound and BloXroute participating in, and the other is where Bundler consensus will be formed to enforce fair ordering. While, the latter approach would completely eliminate the possibility of MEV in AA.

Future development

Public mempool

Although the AA ecosystem is already in operation, there is still a lot of development work that needs to be accomplished. Looking at the entire AA ecosystem, the largest missing piece at the moment is the public mempool. Etherspot, the team behind the development of the Skandha Bundler client, is currently working on the public mempool p2p network. The p2p network for the public mempool is expected to be available this August.

Bundle algorithm

Along the way, the Ethereum Foundation has funded several AA development teams consisting of dedicated and diligent developers. So far, multiple versions of Bundler clients have been developed and are now available. Among them, some are in a highly advanced stage of development in terms of product maturity. And they are 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 others.

Now, let’s delve into a more detailed bundling algorithms discussion. Currently, due to the low volume of UserOperations, Bundlers can employ a straightforward simple logic for packaging, such as fixed time interval or certain quantity of UserOperations per bundle. However, as the number of UserOperations increases, especially with the introduction of the public mempool, the strategy of selecting and bundling UserOperations becomes more complex. The reason is simple: without a consensus protocol like in blockchain, the Bundler group becomes a dark forest where each Bundler prioritizes the work based on their own interests, and competes with each other. Private mempool, corresponding to the public mempool, is more likely to emerge first. Because when bundling UserOperations from the public mempool is not profitable, bundling the UserOperations from the private mempool together can become profitable. This way, the Bundler has a competitive advantage over others when it comes to bundling.

In addition, as the public mempool is gradually adopted, the UserOperations inside will have different characteristics, for example, varying Gas profitability expectations and on-chain execution complexities. Bundlers will conduct off-chain simulations to assess the profitability of various UserOperations combinations, thus to establish their unique bundling strategies. . Bundling more UserOperations has the potential to yield greater profits, yet it also increases the risk of verification failures. And even if verification passes, there is still a risk of execution failure on-chain. While, bundling fewer UserOperations is the opposite. Bundlers need to set their own transaction Gas parameters, which affects the block builder's priority for executing the transaction. Under different market Gas prices and Gas volatility conditions, Bundlers may have different bundling strategies. Meanwhile, these verification and strategy calculations require the consumption of local hardware computing resources and blockchain node resources. Bundlers also need to ensure a good user experience for users and make sure users don't face excessive delays after submitting a UserOperation.

While the solutions to these challenges remain uncertain, what we can be sure of is that the development of the AA industry and the joint efforts of developers will eventually lead to the resolution. As an infrastructure builder, BlockPI hopes to be a problem solver in the development of the AA industry, whether as a developer or by providing AA-friendly infrastructure to other developers.

Infrastructure Must Adapt

AA abstracts various roles involved in on-chain transaction behaviors, including Senders, Bundlers, Gas payers, contract wallets, signers, thus allowing users to have higher freedom in using blockchain. While, the services within AA can be deployed separately.

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

In the Bundler service, Infrastructure providers may need to develop a private mempool working 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, yet all of them provide a suite of standard 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 give ongoing, complete support for these APIs.

Moreover, optimizing and adapting between Bundler API and raw node client RPC are also important. We know that the current node clients do not have responsive adaptability optimization for AA. Some Bundler API methods require data indexing for AA to be available. For example, finding a UserOperation by hash requires indexing all UserOperations. Otherwise, the hardware consumption for this single request will be very high, and the request return will also take a long time.

Other than that, it is also necessary for Infrastructure providers to integrate different Paymaster services to provide customers with Gas-free user experiences and offer them different service options. This requires good communication and integration works with third-party Paymaster service providers, while more convenient integration solutions based on existing Paymaster services according to market demand can be also designed with this. Other services, such as aggregate signatures, wallet factories, and so on, are also possible directions for future development and integration.

Currently, BlockPI is actually working hard to realize all of these above. Not only that, we are in communication with almost all of the Bundler clients and Paymaster service providers in the community, and we have already made integrating AA services into the BlockPI Network our top priority. We are also having in-depth discussions with AA wallets developers to understand user needs. So, moving forward on our road, we wholeheartedly welcome collaboration and communication with all Bundlers, Paymasters, and Wallets. In that our general goal is to jointly build and develop the AA ecosystem with others, carrying its growth and advancement forward with our best efforts. And, by working together, we hope to make meaningful contributions to the whole AA industry and support its ongoing development progress. Because after all, our ultimate mission is to push the development of the AA ecosystem forward as a pioneer in the industry, thus allowing web2 users to enjoy their blockchain experience without barriers.