How to empower infrastructure and serve billions of users through account abstraction?

How to serve billions of users by empowering infrastructure with account abstraction?

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

Original Author: Albert He, BlockPI Cheif Scientist

Original Source: medium

Translation: MarsBit, MK

• Reflections One Month After Montenegro EDCON 2023: Forward-looking Trends in Infrastructure and Applications
• Can you earn money by running a node? How to choose a public chain? We talked to a node operator about it.
• Interpreting the Narrative of HOPE’s Resurrection

Regardless of bull or bear market, the Ethereum ecosystem has been continuously building and optimizing itself. Among them, account abstraction (AA) has become 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 that widely adopting AA can reduce the threshold of blockchain use cases, bringing web2 user experience into the web3 industry.

To meet 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 also positioning BlockPI as a leader in the industry.

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

EOA and Smart Contract Wallet

The concept of AA originated 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. It is a major component of the Ethereum ecosystem, allowing users to interact with smart contracts and execute transactions on the network. However, using EOA may be challenging for people, and some inconveniences may affect the user experience.

The first inconvenience of EOA is related to the use of Gas. Each transaction costs the user a lot of ETH as Gas fees (the simple ETH transfer fee with a Gas price of 25 Gwei is 0.5 USD, and the cost of contract interaction or higher Gas price is higher). This makes the transaction fees for small transactions very expensive, especially during network congestion peaks. In addition, only ETH can be used to pay for Gas, which means that users must have ETH in their wallets, which is an important entry barrier for many users.

The second inconvenience of EOA is the inability to make conditional transactions unless other smart contracts are used to implement certain logic. For example, if a user wants to set up a timed periodic transfer, they must transfer ETH to a third-party smart contract that has this feature to implement this function.

The third inconvenience of an Externally Owned Account (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. This is hardcoded into the system and users cannot choose to use other algorithms.

As a result, efforts have been made to find solutions to these issues. Smart contract wallets (such as MetaMask and Argent) are the result of these efforts, enhancing user account functionality by using Ethereum smart contracts to address many of the limitations of EOAs. However, such solutions have their own drawbacks, mainly the need for users to pay gas fees for transactions and the issue of widespread adoption of smart contract wallets.

Based on these challenges, Ethereum began to explore a new concept, namely account abstraction. The goal of account abstraction is to address these issues at the protocol level, rather than relying on smart contracts or other middleware. This is what we now call account abstraction (AA).

In the remaining parts of this article, I will delve into the concept of account abstraction and how we are leveraging this concept to optimize BlockPI’s infrastructure.

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

In addition, EOAs face constraints when performing linear tasks in a single transaction. For example, if a user wants to approve, exchange, and cancel approval of tokens in one action, they need to perform three separate transactions, which is neither efficient nor time-saving.

The good news is that all of the above problems can be solved with a smart contract wallet. A smart contract wallet is a special type of smart contract that implements AA. It is designed to serve as a user’s wallet on the Ethereum network, providing a more adaptive and personalized way to manage their funds. As long as the Ethereum smart contract can implement the logic, the smart contract wallet can provide the required functionality.

Specifically, transactions of a smart contract wallet can be packaged into one on-chain transaction sharing gas costs, which can even have no gas cost if a third party is willing to pay. One operation can facilitate sequential tasks to be executed within its smart contract wallet. The smart contract wallet can support any signature encryption algorithm and set recovery codes, etc.

As discussions about the benefits of smart contract wallets continue, the Ethereum community has actually been researching wallet abstraction from the very beginning. While many EIPs have been proposed to explore account abstraction, a unified standard has not been established until 2021. Here are a few of the most representative proposals.

EIP-86

Initially created by Vitalik Buterin in 2017. Implements a set of changes that provides “abstraction” of signature verification and nonce checks as a service, allowing users to create “account contracts” that execute any desired signature/nonce check.

EIP-2938

Created in 2020. This EIP’s title is Account Abstraction. This EIP describes in detail the concept of AA. It introduces a new type of transaction, namely the AA transaction. This transaction is initialized by an EntryPoint address and calls an AA wallet contract. By doing so, it provides a unified specification and introduces AA into the Ethereum consensus. More specifically, it adds two new opcodes, three global variables, and a different payload structure to the Ethereum consensus.

EIP-3074

Created in 2020. This EIP introduces two EVM instructions, AUTH and AUTHCALL. AUTH sets a context variable named authorized based on an ECDSA signature. AUTHCALL sends a call as the authorized account. This allows a smart contract to send transactions on behalf of an EOA. However, this is not yet a perfect solution for AA. EIP-3074 has certain limitations in terms of native value transfer during sponsorship transactions. If you lose access to the EOA, you will not be able to recover your assets, and if they are stolen, all assets will need to be transferred to a new account.

Due to major reasons such as the need for changes in the consensus layer or incompleteness, all of the above ideas have not been formally adopted into the Ethereum protocol. Therefore, the Ethereum community continued to explore how to introduce AA into the Ethereum protocol without changing the consensus, ultimately creating 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 game-changing proposal that introduces AA without the need for any changes to the core Ethereum protocol. EIP-4337 leads to the ERC-4337 standard, which builders can use to implement their own smart contract wallets and includes some additional infrastructure, including “Bundlers” and UserOperation memory pools. By doing so, it effectively replicates the functionality of the transaction memory pool in a more advanced system. Users no longer send transactions, but submit UserOperation objects, which can then be packaged into a single transaction and included in the Ethereum chain.

Here is a more specific technical explanation of ERC-4337 and some more easily understood comments from the official documentation.

Definition and Key Roles of ERC-4337

UserOperation – Describes the structure of the transaction sent on behalf of the user. To avoid confusion, it is not named “transaction.” It is sent to the Bundler to be packaged with other UserOperations. The package is then sent as a single transaction to the block creator.

Sender – The contract account that sends the new UserOperation. The smart contract wallet must implement the IAccount interface of ERC-4337.

EntryPoint – The singleton contract that executes the UserOperations package. Bundlers/Clients whitelist supported EntryPoints. 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 Blockingymaster. It will have the same address on most EVM-compatible chains.

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

Aggregator – A contract that helps verify the aggregate signature trusted by the account. Bundlers/Clients whitelist supported Aggregators. The Aggregator must implement the IAggregator interface of ERC-4337.

Blockingymaster – A contract that can pay the Gas fee for the UserOperation on behalf of the Sender if enough ETH is deposited in the EntryPoint contract. Blockingymaster implements an effective Gas abstraction. Blockingymaster must implement the Blockingymaster interface of ERC-4337. Blockingymaster can have its own logic to make a deal with the Sender. For example, the Sender pays USDC to Blockingymaster, and then Blockingymaster sponsors its UserOperations with ETH. In fact, any ERC20 token or even tokens on other chains can be supported as long as Blockingymaster agrees and it is technically feasible.

Wallet Factory – A contract that can be called to create a smart contract wallet for ERC-4337 users. Deploying the wallet factory is permissionless. As a chain component, it is open to public auditing and transparent review. A widely used Wallet Factory should be fully audited by professionals.

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

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

handleOps verifies UserOperation on-chain, checks if 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 UserOperation.

On the other hand, when the Bundler triggers the handleOps function using an EOA, it incurs Gas fees. The smart contract wallet can pay Gas fees to Bundlers from its own account balance, or request the Blockingymaster contract to pay on its behalf. UserOperations without sufficient Gas cannot pass the verification process in the target smart contract wallet and fail before execution. Even if there is sufficient Gas, UserOperations may fail during execution, for example, due to runtime errors. Regardless of whether the execution is successful or not, EntryPoint contract will pay the Gas fees to the Bundler who triggered 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, in which an EOA initiates the transaction. The other is to use the ERC-4337 standard to initiate UserOperation through Bundler, which is then packaged with other UserOperations by Bundler and launched on the chain. The following flowchart illustrates the difference between a regular EOA sending a transaction and an ERC-4337 contract wallet sending 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 AA 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.

The adoption of AA is still in its infancy. According to the Dune ERC-4337 analysis panel (ERC-4337 Account Abstraction from @niftytable), only 65k+ UserOperations are executed on the chain, 90% of which come from Polygon. Therefore, the number of UserOperations executed at this time is still very small, most of which are attributed to developers’ testing, and only a few are attributed to users. We have noticed that products that have integrated AA are still in the early stages. At the same time, it can be seen that the profit of Bundler is negative (calculated as -700 in MATIC) because some Bundlers on Polygon have not calculated the pre-verification gas correctly. This verification algorithm still needs to be optimized.

In addition to this, there are still some issues that need to be addressed. One of the problems is how Bundlers handle transaction failures. After Bundler packages several UserOperations together, Bundler first simulates the transaction to check if it will be rolled back, and then calculates whether the Gas fee returned by Sender or Blockingymaster is greater than the Gas fee paid for the transaction. If it is profitable, Bundler submits this batch of UserOperations together as a transaction to the block builder. However, the transaction may still fail, resulting in Bundler paying Gas fees but not receiving the returned Gas from EntryPoint. For example, a user may send operations to different Bundlers. If any operation is profitable and their simulation is successful, Bundlers are willing to submit them on the 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 Gas fee from EntryPoint, and all other Bundlers will lose Gas due to on-chain failures. Although some people may argue that users should not do this, such behavior will be considered a malicious attack, and Bundler can ban the Sender address and reject any future requests from this address, but this is not a reasonable method because users may accidentally submit this operation. Such problems need to be properly addressed in the code, possibly by developing an incomplete public mempool network. In addition, 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 usually refers to the value that miners or other transaction processors can extract by manipulating the order of transactions in a block or by including their own transactions in the block. Someone noticed that the logic of MEV can also be applied to AA, because Bundlers can freely sort UserOperations, right? However, this is conditional and there needs to be enough UserOperations packaged together for Bundlers to extract MEV. Now the entire AA market is still in its early stages, so Bundler MEV can also be considered early stage. Overall, the AA industry may develop in two directions: one is similar to Ethereum’s mainnet, with participants such as Flashbots, Ultra Sound, and BloXroute participating, and the other is to form a Bundler consensus to execute fair sorting. The latter approach will completely eliminate the possibility of MEV in AA.

The Future

The 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 currently is the public mempool. The Etherspot team, the developer of the Skandha Bundler client, is currently developing a p2p network for the public mempool. The p2p network for the public mempool is expected to be available in August of this year.

The Bundling Algorithm

In this process, the Ethereum Foundation has already sponsored several AA development teams consisting of focused and diligent developers. So far, multiple versions of Bundler clients have been developed and are now available. Some of them are in a highly developed stage 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), etc.

Now, let’s go into more detail about the bundling algorithm. Currently, because the number of UserOperations is small, Bundlers can use simple and direct bundling logic, such as fixed time intervals or the number of UserOperations in each package. However, as the number of UserOperations increases, especially after the introduction of the public mempool, the selection and bundling strategy for UserOperations becomes more complex. The reason is simple: there is no consensus protocol like blockchain, and Bundler forms a dark forest, with each Bundler processing work based on their own interests and competing with each other. Private mempool, corresponding to public mempool, is more likely to appear first. This is because when it is not advantageous to pack UserOperations from the public mempool, it may be profitable to pack UserOperations from the private mempool together. In this way, Bundler has a competitive advantage when packing.

Moreover, as the public mempool becomes more adopted, the UserOperations within it will have different characteristics, such as different gas profit expectations and on-chain execution complexities. Bundlers will conduct off-chain simulations to evaluate the profitability of various UserOperations combinations and establish their unique bundling strategies. Bundling more UserOperations may produce greater profits, but also increases the risk of verification failure. Even if verification passes, the risk of on-chain execution failure still exists. Bundling fewer UserOperations is the opposite. Bundlers need to set their own transaction gas parameters, which affects the priority of transaction execution by block builders. Under different market gas price and gas volatility conditions, Bundlers may have different bundling strategies. At the same time, these verification and strategy calculations require local hardware computing resources and blockchain node resources. Bundlers also need to ensure a good user experience, ensuring that users do not face long delays after submitting UserOperations.

While the solutions to these challenges are still uncertain, we can be certain that the development of the AA industry and the collective efforts of developers will eventually find solutions. As an infrastructure builder, BlockPI hopes to solve problems in the development of the AA industry, whether as a developer or offering friendly AA infrastructure to 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 greater freedom when using blockchain. Moreover, services within AA can be separately deployed.

To adapt to the mass adoption of AA, infrastructure providers need to provide at least two basic services, the Bundler service and the Blockingymaster 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 in 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 will be added in the future. Infrastructure service providers should provide ongoing and complete support for these APIs.

Moreover, optimizing and adapting the relationship between Bundler API and the original node client RPC is also very important. We know that the current node clients do not have good response and adaptability optimizations for AA. Some Bundler API methods require data indexing of AA to be used. For example, looking up UserOperation by hash requires indexing of all UserOperations. Otherwise, the hardware consumption of this single request will be very high, and the request return will also take a long time.

In addition, infrastructure providers also need to integrate different Blockingymaster 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 Blockingymaster service providers, and convenient integration solutions based on existing Blockingymaster services can also be designed according to market demand. Other services, such as aggregate signatures and wallet factories, are also possible directions for future development and integration.

Currently, BlockPI is actually working to achieve all of the above goals. Not only that, we are communicating with almost all Bundler clients and Blockingymaster service providers in the community, and have made integrating AA services into the BlockPI Network our top priority. We are also in deep discussions with AA wallet developers to understand user needs. Therefore, on our path forward, we sincerely welcome cooperation and communication with all Bundlers, Blockingymasters, and wallets. Our overall goal is to work with others to build and develop the AA ecosystem and make our best efforts to promote its growth and development. Through joint efforts, we hope to make meaningful contributions to the entire AA industry and support its continued development process. After all, our ultimate mission is to be a pioneer in the industry, promote the development of the AA ecosystem, and make web2 users enjoy their blockchain experience without barriers.

Summary

From the perspective of AA, we are at a new historical moment. Although we have paved the way on the road, there are not many passengers yet. Currently, AA applications are still in the initial stage, and ERC-4337 provides a powerful framework for users and developers to use and build AA on the Ethereum platform, but there are still many challenges and uncertainties that need to be addressed.

AA infrastructure providers need to provide Bundler services and Blockingymaster services to their users, and need to integrate various Bundler clients and Blockingymaster service providers to ensure the robustness of the service. In order to optimize the responsiveness between the API and the node client, it may be necessary to index the AA data to reduce the hardware consumption of a single request. In order to provide a better user experience, infrastructure providers also need to provide users with more service options.

In the future, as the AA ecosystem continues to develop and the public mempool appears, the strategies for selecting and packaging UserOperations will become more complex. Each Bundler will prioritize their work based on their own interests and compete with other Bundlers. Bundlers need to set their transaction gas parameters, which will affect the priority of block builders to execute transactions. 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 joint efforts of developers will eventually find a solution. As the builder of infrastructure, BlockPI hopes to be the problem solver in the development of the AA industry, either as a developer or by providing friendly AA infrastructure for other developers. Our mission is to promote the development of the AA ecosystem, so that Web2 users can enjoy their blockchain experience without barriers.

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