4D Detailed Explanation of Ethereum Account Abstraction and ERC-4337: How to Open the Next Billion-Level User Entrance?

Original text: "All Things Research Institute: Web3's next billion-level user market? Comprehensive interpretation of account abstraction and the technology and application of EIP4337"

Author: Steve Wang , researcher at the All Things Institute, student at Wharton Business School, front-end & contract engineer

Introduction

The account abstraction defined by Ethereum Improvement Proposal 4337 (EIP 4337) is a set of protocol layer interfaces. It not only integrates the interaction forms familiar to web2 users, such as multi-factor authentication, but also proposes solutions to web3-specific user pain points, such as gasless transactions. As a protocol interface for introducing the next billion users, user experience is the most important focus of account abstraction.

Although many existing articles explain account abstraction very well, most of them are more scientific, and a few go deep into technical details. This article aims to integrate the two: it not only provides a comprehensive technical interpretation of the abstract concept of accounts, but also classifies and analyzes existing applications and infrastructure cases. Therefore, this article is divided into three parts: In the first part, we will discuss the origin of EIP 4337 and gain an in-depth understanding of its technical details, including UserOperation, Bundler, Entry Point Contract, payment Contract (Paymaster), Wallet Factory (Wallet Factory) and Signature Aggregator (Signature Aggregator). In the second part, we will analyze existing market players, including smart contract wallets and third-party infrastructure providers. In Section 3, we discuss where account abstraction is headed, including an outlook and predictions for innovation in the field.

This article is quite long. The first part is mainly about the technical interpretation of account abstraction. Readers who are only interested in the application scenarios of account abstraction can skip directly to the second part.

Part 1: Comprehensive Technical Analysis of EIP 4337

First, to briefly review the basics, there are two types of accounts in Ethereum: externally owned accounts (EOA) and contract accounts.

• EOAs are user-controlled accounts that can send transactions. EOA controls the ownership of the account through its private key, and can execute transactions through signatures, thereby changing the internal state of EOA or the state of external contract accounts. Since the private key (or seed phrase) is the only representative of EOA ownership, EOA is not suitable for defining complex ownership or transaction logic, such as using social media account login (social login) and multi-party signature (multisig) transactions. The limitations of EOA lead to poor user experience: some cumbersome steps, such as private key and seed phrase management, directly hinder Web2 users from entering Web3. Most of the most popular wallets, such as MetaMask, are based on the EOA account model.
• The contract account can host any Solidity code, so it can take advantage of all the Turing-complete features of the EVM. Unfortunately, contract accounts cannot send transactions, so their functionality must be triggered by EOA. A smart contract wallet is a contract account that is indirectly triggered by its users through the wallet provider's EOA network, either through a relayer or a bundler.

 Figure: EOA and Contract Account (Source: Bitcoin Insider)

Smart contract wallets existed long before EIP 4337. EIP 4337 was proposed to standardize the common functionality of designing smart contract wallets and their associated infrastructure. EIP 4337 follows the following design principles:

• In general, all technical implementations are on the top layer (smart contract layer) , so as to avoid touching the underlying infrastructure such as the consensus layer and the execution layer. If the basic design of the account model is changed at the bottom, it will become an important upgrade like the merger of the Ethereum PoS Mainnet. Because developers have limited energy, they can only adopt the lightweight technical route implemented by the contract layer.
• The design of the protocol interface should be modular , so that users can customize options, including transaction packaging processing (Bundler), gas payment (Paymaster) and signature aggregation (Aggregator).
• Ideally, each of these services would become a competitive open market . Users can choose the best service based on the provider's price and reputation.

EIP 4337 defines six contract interfaces for standardized smart contract wallets:

First of all, the smart contract wallet itself will be triggered indirectly by triggering the entry contract through the packager, verifying the transaction off the chain, and then executing it on the chain.

Secondly, the packager (Bundler) is used for batch verification and execution of user operations (UserOperation, which is the transaction type of the smart contract wallet defined by EIP 4337).

Third, the Entry Point Contract is a global contract with only one copy in Ethereum, which is used to standardize transaction execution and prevent packagers from DoS attacks from malicious transactions.

Fourth, the payment contract (Paymaster) is used to process gas payments on behalf of wallet users.

Fifth, the contract factory (Wallet Factory) is used to standardize the parameters and processes of wallet creation.

Sixth, the Signature Aggregator is used to aggregate the signatures of multiple transactions into bytes for faster verification and execution of transactions.

Below I will introduce UserOperation and the above six contract interfaces in detail, which is an interpretation of the official EIP 4337 document and the David Philipson@Alchemy account abstraction series.

1. Account Operation (UserOperation)

UserOperation is essentially the same as ordinary transactions, except that additional parameters are defined based on the contract interface of EIP 4337. To review here, an ordinary Ethereum transaction triggered by EOA has parameters such as the transaction target address, the amount of transferred Ethereum, the amount of gas, and the gas price.

In addition, considering the modular design of the EIP 4337 contract interface, UserOperation includes the following main parameters to define the triggering of the interface:

• calldata: define the function signature (function signature) and input parameters to be called on the smart contract wallet, calldata is also available in ordinary transactions
• signature: Verifies that the transaction does come from a smart contract wallet address, and the signature also exists in ordinary transactions
• nonce: prevent replay attacks, also in ordinary transactions
• sender: specifies the wallet address of the smart contract that executes the UserOperation
• paymasterAndData: used for transaction fee abstraction (gas abstraction) , including specific parameters of payment contract (Paymaster) address and gas payment
• initCode: used for wallet creation , including wallet factory (Wallet Factory) contract address and parameters for creating a smart contract wallet, such as the contract code of the wallet

In addition to requiring additional parameters, the workflow of UserOperation is similar to that of ordinary transactions: they are all broadcast to the mempool for verification, execution, and finally block generation. Validation and execution of UserOperation is triggered by Bundlers , which I explain below.

 Figure: Definition of the UserOperation parameter in the official EIP 4337 document

2. Bundler

Bundler is an external account (EOA) that verifies and executes UserOperation transactions on the smart contract wallet on behalf of the user, because on Ethereum, all transactions must be triggered by EOA. Bundler enables users to trigger smart contract wallet transactions without creating and memorizing the private key of EOA, which is also the original intention of smart contract wallets.

Although Bundlers have strong public goods properties, they can also benefit economically because:

• Bundler can collect the difference between the maximum priority Gas fee(maximum priority fee) and the actual gas cost after executing the UserOperation
• Similar to the relayer (Relayer) of ordinary transactions, Bundler can obtain MEV by sorting the UserOperation in the bundle transaction (bundle)

Although the user has paid the cost, Bundlers are good for saving gas , because each execution of a transaction requires a fixed cost of 21,000 gas, and executing a bundled transaction can allocate the fixed cost of a transaction to multiple UserOperations in the bundled transaction, thus Save gas cost. In addition, modifying storage multiple times in the same transaction will have marginally diminishing Gas fee for each additional operation.

It should be noted that although transactions on Ethereum are executed linearly (not in parallel) to avoid state conflicts (state conflict), multiple UserOperations can be executed in a bundled transaction, because Bundlers can set the same smart contract wallet address to contain at most A UserOperation so that bundled transactions do not conflict with each other when modifying state.

Other than these differences, Bundlers are similar to Block Builders in that they both broadcast validated UserOperations into a public or private mempool. Next, we'll introduce the Entry Point Contract, which Bundler needs to interact with to execute the UserOperation.

3. Entry Point Contract

The entry point contract is a global singleton contract that all Bundlers need to call to execute the UserOperation. It acts as a middleman between Bundler and the smart contract wallet:

• On the one hand, Bundlers call the handleOp function of the entry point contract, which accepts a UserOperation as an input parameter. handleOp is responsible for verifying and executing the function of the smart contract wallet according to the calldata of UserOperation

• handleOp first verifies the UserOperation on the chain, checks whether it is signed by the specified smart contract wallet address, and whether the wallet has enough gas to compensate Bundler
• If the verification is successful, handleOp will execute the smart contract wallet function according to the function signature and input parameters defined in the calldata of UserOperation

• On the other hand, the smart contract wallet needs to deposit tokens to the entry point contract to pay the gas fee to the Bundlers. When Bundler uses EOA to trigger the handleOp function, a gas fee will be generated.

• In addition, the smart contract wallet can also use its own account balance to pay the gas fee to Bundler, or request the payment contract (Paymaster) to pay for it. We will explain in detail later
• A UserOperation without enough gas fails the verification step in the target smart contract wallet, so it fails before execution
• Even if there is enough gas, UserOperation may still fail in the execution step, such as runtime error
• Regardless of whether the execution is successful or not, the entry point contract will pay the gas fee to the Bundler to trigger the handleOp function
• The entry point contract provides functions for smart contract wallets to add or withdraw token collateral

 Figure: The entry point contract workflow in the official EIP 4337 document

4. Smart contract wallet main contract

The smart contract wallet main contract separates the verification and execution steps of UserOperation:

• The validation steps are defined in the validateOp function. This function will be called twice: the first time is that Bundler simulates and verifies off-chain, verifies the signature in UserOperation, and ensures that the smart contract wallet has sufficient gas balance; the second time is that the entry point contract executes the chain verify on
• The execution step is defined in the calldata of UserOperation, which is used to specify the signature and input parameters of the smart contract wallet function

By separating the verification and execution of UserOperation, Bundler can verify UserOperation off-chain, so that malicious transactions can be filtered out without paying gas. Therefore, the validateOp function also functions as an off-chain debug API.

5. Payment contract (Paymaster)

The payment contract (Paymaster) defines the logic of the gas abstraction of the smart contract wallet. The form of Gas abstraction includes using ERC20 homogeneous tokens to pay Ethereum gas and transactions without gas, both of which can be realized by Paymaster. The modular design of ERC-4337 allows UserOperation to specify any Paymaster address and input parameters through the paymasterAndData parameter. Paymaster has the following features and requirements:

• In essence, Paymaster is a smart contract deployed by Dapp, which can trigger Paymaster's validatePaymasterOp function through Bundler to selectively pay gas for the UserOperation specified by the contract with arbitrary logic
• Paymaster needs to deposit Ethereum on the entry point contract to pay for UserOperation's gas
• In addition to depositing gas, Paymaster also needs to additionally pledge Ethereum on the entry point contract. This pledge will not be slashed, but it can prevent robots from maliciously creating Paymasters in batches

Paymaster is (at least in the official vision) a competitive open market. Although there is no official on-chain reputation system for Paymaster, Bundlers can record Paymaster's service quality off-chain and stop using Paymasters with lower quality, thereby incentivizing Paymasters to provide reliable services for UserOperation.

The Paymaster interface defines two functions:

• validatePaymasterOp: defines the abstract logic of gas. For example, in a scenario where a smart contract wallet pays for gas in ERC20 tokens, this function will ensure that the wallet has sufficient balance. validatePaymasterOp is called before executing UserOperation, which conforms to the design logic of separating the verification step from the execution step
• postOp: It is called at the last step of executing a certain function in the smart contract wallet. If the wallet does not have enough ERC20 balance to pay the Gas fee to Paymaster, postOp will cancel the function execution. Even if the function execution fails due to a runtime error in this step, the gas will still be deducted.

 Figure: Paymaster workflow in the official EIP 4337 document 

 Figure: Paymaster interface in the official EIP 4337 document

6. Wallet Factory

Wallet Factory is a contract to create smart contract wallets. To recap, UserOperation has an optional initCode field. When initCode is empty, UserOperation is just a function to trigger the smart contract wallet. When the initCode is populated with the Wallet Factory address and the parameters of the new smart contract wallet, Bundler will trigger the corresponding Wallet Factory to create a smart contract with the specified parameters.

Wallet Factory facilitates account abstraction in the following ways:

• Users can request Bundler to create a smart contract wallet by submitting a UserOperation filled with initCode, without owning an EOA to create it themselves
• Users can customize smart contract wallets by selecting a Wallet Factory with specific customization options and passing in their own parameters. In addition, because the Wallet Factory contract is public and the popular Wallet Factory undergoes a comprehensive code audit, it is safer for users to create new wallets using Wallet Factory
• Users can choose to let Paymaster pay for the gas of creating a wallet or use any ERC20 token to pay for gas without owning Ethereum. In addition, Paymaster can choose to only pay gas for smart contract wallets deployed by its trusted Wallet Factory
• Users can get their smart contract wallet address by calling the CREATE2 function before creating a wallet. This function deterministically generates a smart contract address using the EOA address that triggered the creation of the smart contract wallet, a salt, and an initCode. The user does not need to pay gas when creating a wallet, but only needs to pay the gas for creating the wallet and the transaction at the same time when using the wallet for the first transaction, thereby improving the user experience.

Wallet Factory has other duties as well. Similar to Paymaster, they need to stake ETH on the entry point contract and continue to provide good services for UserOperations in order to get more traffic from Bundler.

7. Signature Aggregator

Because different smart contract wallets use different signature algorithms, UserOperations that use the same signature algorithm need to be aggregated first, and then verified separately. In addition, since on-chain cryptography calculations consume a lot of gas, a signature scheme that supports aggregation (such as BLS) can save gas during the on-chain verification process . So we need an EIP 4337 smart contract interface called Signature Aggregator. It can support specific signature algorithms by implementing the following two functions:

• aggregateSignatures: The input parameter is an array of UserOperations, and an aggregate signature is output using a specific signature algorithm
• validateSignatures: The input parameter is an array of UserOperations and an aggregate signature, which is used to verify the signatures of all UserOperations in the array

Instead of validating one UserOperation at a time, Bundler first generates multiple aggregated signatures (one for each signature algorithm) using multiple signature aggregator contracts (one for each signature algorithm). Afterwards, Bundler passes the UserOperation array, aggregated signature, and aggregator address to the entry point contract, and each UserOperation array will call the validateSignature function of its corresponding signature aggregator. After the verification is passed, Bundler will execute this set of UserOperations on the smart contract wallet.

Similar to Paymaster and Wallet Factory, aggregators are also required to stake Ethereum on entry point contracts and maintain a track record of providing good service to UserOperations.

 Figure: The signature aggregator interface in the official EIP 4337 document

8. Summary of the overall workflow

The modular design of EIP 4337 divides the account abstraction function of the smart contract wallet into multiple interfaces. The functions of these interfaces can be summarized as the following workflow:

• User sends UserOperation to Bundler
• If UserOperation fills in the initCode parameter, Bundler will trigger Wallet Factory to create a new wallet with a certain address
• If UserOperation fills in the paymasterAndData parameter, Bundler will collect the Ethereum pledged by Paymaster on the entry point contract to pay for the gas. If paymasterAndData is not filled in, Bundler will charge the Ethereum pledged by the smart contract wallet on the entry point contract to pay the gas
• Bundlers can optionally use signature aggregators
• Bundler will use the validateOp, validatePaymasterOp and validateSignatures functions to simulate and verify the UserOperation off-chain to ensure that the signature is correct and the UserOperation has enough gas
• If the off-chain simulation verification passes, Bundler will use the above function to verify UserOperation on the chain
• If the verification on the chain is passed, Bundler will execute the UserOperation on the chain, regardless of whether the execution is successful or not, the gas will be deducted

 Figure: Account abstraction workflow without signature aggregator (courtesy of Alchemy) 

 Figure: Account abstraction workflow with signature aggregator (courtesy of Alchemy)

9. Other Notes

UserOperation will trigger functions such as validateOp to perform transaction verification both off-chain and on-chain. In order to prevent the state change (state change) outside the smart wallet contract from causing inconsistent verification results between off-chain and on-chain, EIP 4337 prohibits the verification function from using OpCodes that read the external storage of the contract and read the global state (such as timestamp). This prohibition applies to the validation functions validateOp, validatePaymasterOp, and validateSignatures.

Part II: Account Abstraction Market Participants

1. Smart contract wallet and supporting SDK

Smart contract wallets are the largest players in the account abstraction market. In order to be compatible with EIP 4337, they usually implement their own packager (Bundler), payment contract (Paymaster), wallet factory (Wallet Factory) and signature aggregator (Signature Aggregator). These wallets also come with an SDK that facilitates wallet integration for Dapp. The smart contract wallet market is relatively crowded. There are old players such as the multi-signature wallet Gnosis Safe that realize the account abstraction function based on the original product, and newcomers such as Candide focus on building a smart contract wallet that is fully compatible with EIP 4337. This section describes the common features of these wallets and the differences in each feature.

a. Social login and social recovery

Social login provides smart contract wallets with an interactive experience familiar to Web2 users, such as creating and logging into a wallet with an existing Google account. The same logic can also be extended to social recovery, such as using an email to reset the password of a smart contract wallet. The logic of social login and social recovery is generally defined in the main contract of the wallet.

Here we introduce the concept of Guardian. A guardian is an entity that can authorize a user to access an account or help a user restore an account. The guardian can be a Web2 account or an email address. This concept has been widely used in Web2, and now it can also be implemented in smart contract wallets through the concept of account abstraction.

A smart contract wallet can have multiple guardians. Users need to set up guardians during or after wallet creation and reach a certain guardian verification threshold, such as 2 out of 3 guardians, to log in or restore the wallet. This process is often referred to as multi-factor authentication . The following are common types of smart contract wallet guardians:

• Web2 service providers: such as social media accounts of wallet users, usually implemented by implementing the OAuth (Open Authorization, that is, open authorization) standard. This standard allows wallets to obtain user authorization to access user account information hosted by another Web2 application
• User equipment: such as browser storage and mobile storage
• Email: e.g. authorize by clicking a link that can send a signed email
• Multi-signature: users can set up multiple personally owned EOA or smart contract wallets as guardians
• MPC: Users can divide the private key into multiple shares, each share is controlled by a node in the MPC network, and the complete key will not be revealed
• SWIE (sign in with Ethereum, that is, log in with Ethereum)

Let's take a look at some players' implementation of this feature in the market:

• Web3Auth is a social login and MPC service used by many high-traffic smart contract wallets, including Biconomy, Etherspot, and 0xPass. Web3Auth divides the user key into multiple shares for guardians such as social login, user equipment and its MPC node network. The product logic implementation is completely off-chain, and no guardian will store the complete private key. (See image below.)
• BLS Wallet and Argent use multi-signature technology (multisig) to recover keys through multiple EOA addresses specified by users.
• UniPass implements an innovative approach to social recovery via email. The user submits the guardian's mailbox on the chain, and the DKIM signature of the mailbox is verified on the chain through the smart contract. DKIM (Domain Keys Identified Mail) is an email authentication protocol used to create digital signatures. Mailbox providers can use this digital signature to verify the identity of the sender of the email. UniPass also uses Zero-knowledge Proof to desensitize user information on the chain. UniPass also supports social recovery methods other than email.
• Soul Wallet verifies Guardian email addresses on-chain for social recovery.

 Figure: Web3Auth social login and social recovery, in this case there are three guardians

b. Gas Abstraction (gas abstraction, gas is the transaction fee)

Gas abstraction includes gas-free transactions and gas payments using any ERC20 token. These logics can be implemented in the payment contract (Paymaster), or through a relay (Relayer).

Many smart contract wallets themselves implement the Paymaster contract compatible with EIP 4337, and pledge tokens on the entry point contract to help users pay for gas.

Relayer is another gas abstraction solution that existed before EIP 4337. Relayers are user-trusted transaction forwarders that perform a special type of gas-free transaction called a "meta-transaction." A meta transaction is an Ethereum transaction that inserts another transaction within the original transaction. The user signs the meta transaction with their private key and sends it to the Relayer, which verifies it, submits it to the blockchain, and pays the gas. The relayer just executes the transaction without changing the transaction itself. Relayers benefit economically because they charge gas fees plus a small profit to the contract that executes the transaction. For example, Relayers can charge decentralized applications (Dapp) that support gas-free transactions. Relayer can be a centralized trusted third party or a decentralized network. The difference between Relayer and Paymasters lies in the following points:

• In addition to paying gas, Relayer also signs transactions, similar to what Bundler in EIP 4337 does
• Relayer not only handles transactions of type UserOperations
• Relayer does not pledge gas on the entry point contract

Let's take a look at some players' implementation of this feature in the market:

• Biconomy not only implements Paymaster compatible with EIP 4337, but also has a Relayer network that supports any ERC20 token to pay for gas.
• Argent uses a third-party relayer to pay gas in the form of meta transactions.
• Candide implemented Paymaster by itself.
• UniPass uses its own Relayer node to pay for gas, and plans to add a "free gas transaction for watching ads" model in the future and support the use of Cross-chain bridges (bridge) to pay for gas.

So far, most ERC20 gas payment solutions (such as Candide and Soul Wallet) only support a very limited number of token types, mainly Stablecoin, although I foresee this changing in the future.

 Figure: Biconomy uses Paymaster to support gas-free transactions (based on EIP 4337 technology implementation) 

 Figure: Biconomy uses any ERC20 to pay gas through Relayer (not based on EIP 4337 technology)

c. Legal currency deposit and withdrawal channels (ramps) and Cross-chain bridges (bridges)

Many existing wallets, such as MetaMask, have integrated legal currency deposit and withdrawal channels and Cross-chain bridges in the wallet through cooperation with third-party suppliers. These deposit and withdrawal channels and Cross-chain bridges can be further integrated with the payment contract (Paymaster) in gas abstraction.

Let's take a look at some players' implementation of this feature in the market:

• Biconomy and 0xPass partner with Transak to provide fiat on-ramp. Biconomy also provides Cross-chain bridge and Cross-chain communication services.
• Argent Vault has partnered with Moonpay, Transak, and Wyre to provide fiat on-ramps and has a built-in DeFi protocol aggregator.
• Etherspot, UniPass, and Braavos support fiat currency channels, swap, and Cross-chain bridges.

d. Transaction batching

Transaction batching is a feature unique to smart contract wallets that allows wallet users to execute multiple transactions in one on-chain transaction. One way to do this is to call a multiCall function that takes two arguments: an array of calldata (each calldata defines a function call) and an array of contract addresses (the address of the contract for each function call). The multiCall function has a loop (loop) and executes a function call in each loop. Transaction batching allows multiple transactions to share the fixed Gas fee of an Ethereum transaction, thereby reducing costs.

Note that transaction batching differs from signature aggregation, which accepts an array of UserOperations as an input parameter and outputs an aggregated signature byte to speed up multiple signature verification. And each UserOperation in this array can call a multiCall to execute the transaction batch.

The way to implement transaction batch processing in EIP 4337 is as follows: the entry point contract calls the handleOp function, and then the function calls the multiCall function defined in the smart contract wallet main contract.

Let's take a look at some players' implementation of this feature in the market:

• Biconomy sets up a MultiCall contract, which smart contract wallets can call to perform transactions in batches.
• Argent executes transactions in batches through a smart contract module called Transaction Manager, which supports multiCall and user session keys.
• Etherspot, Candide, Openfort, and 0xpass all support transaction batching.

 Figure: Example MultiCall contract (provided by Solidity by Example)

e. Modular design of smart contract wallet

A major advantage of smart contract wallets over EOA is their modular design. The function of the wallet can be extended through the contract module developed by the wallet provider. These modules provide functions not defined in the EIP 4337 interface and can be customized by the user. Under the modular design, the smart contract wallet is upgradeable. This practice was an industry standard well before the release of EIP 4337, pioneered by products such as Gnosis Safe. Gnosis Safe is a multi-signature wallet aimed primarily at business users, offering a set of features not defined by EIP 4337:

• Spending Limit: Limits the amount that accounts with signature permissions can withdraw from the wallet.
• Regular payment: automatic payment according to the custom time.
• Roles and authorizations: Define the required roles and authorizations for different transactions and behaviors of the wallet.
• Organization permissions: Permission settings based on different roles within the organization.
• Whitelists and Blacklist

The same modular design has been inherited by EIP 4337 compliant wallets including Argent, Candide, Soul Wallet and zeroDev.

Another way to extend the functionality of smart contract wallets is to natively integrate decentralized applications (dApps) within the wallet. For example, Gnosis Safe provides an SDK for dApps. Dapp using this SDK can appear directly in the wallet interface, which is equivalent to providing a built-in application store for the wallet. Other similar solutions include WalletConnect. However, these front-end solutions are not designed at the protocol layer and are therefore beyond the scope of this article.

 Figure: The modular design of Candide wallet is similar to Safe (Gnosis Safe) (provided by Candide wallet official website)

2. Infrastructure providers

Various Layer 2 support for account abstraction and third-party infrastructure providers for Bundlers and Paymasters will be discussed below.

a. Account abstraction on Layer 2

Given the recent explosion of L2, many smart contract wallets have shifted their development focus to L2. Many L2s natively support an account abstraction contract standard very similar to EIP 4337, which is explored in this section.

Optimism

The first version of Optimism implements account abstraction by introducing three OVM OpCodes that the EVM does not support. In Optimism's technical implementation, smart contracts are the only account type (no EOAs), so all user wallets are smart contract wallets. The smart contract wallet can also upgrade the contract code by calling the upgrade function.

Unfortunately, the second version of Optimism removed these three OVM Opcodes and support for account abstraction in order to be fully consistent with the EVM and for security reasons.

While a handful of smart contract wallets are currently being built on Optimism, there has been no official announcement on support for account abstraction.

Arbitrum

While there are currently a handful of smart contract wallets being built on Arbitrum, there has been no official announcement on support for account abstraction.

Starknet

Unlike Ethereum, Starknet does not distinguish between EOA and contract accounts. Therefore, all Starknet accounts are smart contract accounts. Starknet's account model is greatly influenced by EIP 4337, specifically in the following ways:

• All Starknet smart contract accounts must contain validate and execute functions. validate is a required function, which ensures that only the account owner can initiate a transaction by verifying the signature, and at the same time ensures that the transaction executor can obtain enough Gas fee. Users can implement arbitrary logic in the validate and execute functions, so as to flexibly expand various functions of the account. For example, users can implement different signature verification algorithms in the validate function.
• In order to prevent the transaction from being verified but unable to be executed, Starknet prohibits the validate function from calling the state of the external contract.

There are still significant differences between Starknet's implementation of account abstraction and Ethereum:

• Starknet does not distinguish between regular transactions and UserOperations, as all transactions are triggered by contract accounts. In Ethereum, Bundlers execute UserOperation transactions, while in Starknet, Sequencers execute all transactions.
• Starknet has not yet implemented a transaction fee abstraction protocol similar to Paymaster.
• Starknet requires accounts with token balances to create new contract accounts by calling a dedicated deploy_account function. In EIP 4337, Bundler deploys the contract account by executing the UserOperation transaction whose initCode parameter is not empty. The deployment process does not require an account with a token balance, because the Gas fee can be paid by Paymaster.
• If a verified transaction fails at the execution step, Starknet's sequencer will not be able to extract any Gas fee, while Ethereum does not have this problem.

 Picture: Starknet does not have EOA account type, only contract account (provided by Starknet official website)

zkSync

zkSync also does not distinguish between EOA and contract accounts , so it natively supports account abstraction. The account model of zkSync is very similar to EIP 4337, as shown in the following aspects:

• The account (smart contract wallet) interface also separates the validateTransaction and executeTransaction functions.
• The Paymaster interface also includes the validateAndPayForPaymasterTransaction and postOp functions. The former defines the logic of the Paymaster payment transaction. The latter ensures that Paymaster is able to extract Gas fee compensation after the transaction is executed, although this part of the function has not yet been implemented.
• Users also call Paymaster by filling in the two parameters of paymaster address and paymasterInput in the transaction, similar to UserOperation in EIP 4337.

However, there are also significant differences between the account abstraction implemented by zkSync and Ethereum:

• zkSync allows the validateTransaction function to call deployed external contracts, because deployed contracts are immutable in zkSync. Ethereum prohibits the verification function from calling external contracts to prevent state changes from causing transaction verification to pass but transaction execution to fail.
• zkSync allows the validateTransaction call to send out the external storage of the transaction contract account, such as the token balance of the contract account on the external contract, for the same reason as above.
• During transaction verification, Paymaster can call external storage for the same reason as above.

b. Third-party infrastructure provider (non-smart contract wallet)

As mentioned above, the account abstraction infrastructure includes client SDKs that can send UserOperations, packagers (Bundlers), payment contracts (Paymasters) and signature aggregators (Signature Aggregator). These infrastructures are usually implemented by the smart contract wallet itself to better integrate the upstream and downstream industries, but most of them are not designed for third-party use. Therefore, third-party infrastructure providers are needed in the market to provide modular and customizable Bundler and Paymaster services. Some well-known infrastructure players such as Alchemy have also entered this market. This section explores these third-party infrastructure providers in depth.

Stackup

Stackup is a Bundler and Paymaster provider. Its Bundler is implemented in Go language, has passed all EIP 4377 test suite requirements, is completely open source and free to use. Stackup Bundler supports different modes:

• Private mode: UserOperations enter a private memory pool (mempool), in exchange for slower transaction execution speed for better privacy. UserOperation does not show up in the public memory pool, thus avoiding MEV attacks.
• Search mode (searcher mode): used by robot operators of the Ethereum ecosystem (ie bot operator, also known as searcher, such as DeFi arbitrage robots), and integrated with block builders such as Flashbot, through MEV-Boost sends UserOperations, allowing the searcher to bid for a specific transaction order, so that the block builder can select the largest MEV transaction order to build a block.

Stackup also supports two types of Paymasters:

• Verification Paymaster: Provides a gas abstraction that requires off-chain transactions (such as legal currency deposits and withdrawals). For example, users can choose to subscribe to the Paymaster service with a credit card to pay for Gas fee. Users can also customize the logic of gas payment. Stackup will charge users through a "pay as you go" model.
• Deposit Paymaster: Allows users to pay Gas fee with ERC20 tokens.

 Figure: Stackup's infrastructure product suite

Blocknative

Blocknative is primarily a mempool browser and visualizer provider. Thanks to its strong understanding of memory pools, Blocknative provides Bundler services with unique features, such as:

• Use the EIP 4337 transaction browser (EIP 4337 UserOps Explorer) to visualize the status of UserOperations in the memory pool, which is convenient for wallets and Dapp to monitor the transaction status in real time
• Blocknative's core product, the memory pool browser, can also listen to pending and confirmed Bundler transactions in the entry point contract

Alchemy

Alchemy is currently developing its Bundler and Paymaster services, and potential users can join a waitlist.

 Figure: Alchemy's EIP 4337 infrastructure service is still under development

ETH-infinitism

ETH-infinitism is the official team of the Ethereum Foundation, which has implemented the Bundler and Paymaster defined by the EIP 4337 standard. There is little documentation on the team, but according to a Stackup post, as of February 2023, ETH-infinitism is one of only two bundlers (the other being Stackup) to pass the official test suite for EIP 4337.

Part III: The Future of Account Abstraction

1. In the final analysis, the survival of the account abstraction market depends on the adoption of EIP 4337 by the ecology, and this market is still very early

According to a recent research report by Web3Caff Research, the total number of origination addresses (from parameters) of all transactions in Ethereum is about 150 million after deduplication. However, the total number of smart contract wallets, estimated as the sum of Gnosis Safe and Argent accounts (the two products with the most users), is only 150,000.

Assuming that in the endgame, the number of EOA and smart contract wallets is equal, we can predict that the market size of smart contract wallets has a potential of 1000 times. Still, the adoption of smart contract wallets by the ecosystem will not be smooth sailing. EOA wallet giants like MetaMask have still not announced plans to adopt EIP 4337. Although we don't know their intentions, it's not hard to infer that the huge profits of mainstream EOA wallets are not enough to support the adoption of a new standard with insufficient infrastructure within their team. UserOperation is still not a mainstream transaction type widely used by dApps. Even so, I am still optimistic about the smart contract wallet market, and I can also foresee that the substantial improvement of the user experience of the smart contract wallet will bring exponential growth to the account abstraction market, although this outbreak may take a year or two just happened.

2. EIP 4337 has not been completed yet, comrades still need to work hard

Although EIP 4337 defines contract interfaces for infrastructure such as Bundler, Paymaster, and Signature Aggregator, Ethereum officials have not given solutions to many important technical problems, and these The problem requires the project party to repeatedly try different technical implementations, such as:

• At present, Bundler mainly broadcasts transactions in the private mempool , and UserOperation is sent directly to the designated block builder. Is it possible for the Bundler network to use the public mempool?
• Can Bundler extract MEV by sorting UserOperations? Can block builders extract MEV by ordering bundles? How will MEV be split between Bundler and block builders? Should we separate Bundler and block builders?
• Considering that Bundler needs to complete a large number of off-chain simulations and on-chain verifications, can they also be reliable block builders?
• How should the mempool of UserOperation and the mempool of regular transactions be coordinated to avoid state conflicts?

3. L2 uses EIP 4337 at different speeds

Although zkSync and Starknet already natively support account abstraction , they still have not implemented all EIP 4337 interfaces, and there are differences in technical implementation from Ethereum. Although many project teams are building smart contract wallets, bundlers (Bundlers) and payment contracts (Paymasters) for Optimism and Arbitrum, these L2 have not yet announced plans to officially support EIP 4337, and account abstraction is not their development focus.

From a purely technical point of view, the implementation of L2 account abstraction infrastructure is more complicated than that of L1 . For example, in the verification step, an L2 smart contract wallet needs to estimate the Gas fee of L1 and L2 at the same time, and allocate them to each UserOperation in the bundle transaction (bundle).

4. Regardless of the technical details, what are the characteristics of an excellent smart contract wallet?

Although there are many innovative features in the wallet market (such as gas abstraction, social recovery, MPC, etc.), most smart contract wallets support all the above functions, because the technical implementation of these functions is not difficult. Therefore, the business aspect of smart contract wallets is as important as the user experience aspect. Important commercial factors include:

• Cooperate with dApps: Cooperate with dApps at the traffic entry level of each L1 or L2 chain, especially infrastructure dApps (such as Stablecoin or DeFi protocols), which is the main way to attract users
• Practical functions: such as the integrated NFT market inside the wallet, Launchpad or quickly collect new trading pairs
• External support: such as official support from VC or Ethereum Foundation, these supports can help the wallet find the first batch of users

5. What are the characteristics of an excellent packager (Bundler)?

A permissionless and modular Bundler service is a public good. The open source nature of most bundlers means that they are non-exclusive and non-competitive. Any RPC endpoint can run a Bundler by copying the open source code. Even if the RPC endpoint running Bundler charges service usage fees through API keys, Bundler services are more difficult to monetize than other infrastructures (such as Paymaster), because the latter can be provided through third-party deposits and withdrawals or DeFi protocol aggregators Cooperate with suppliers to easily earn the price difference. Although it is more difficult to commercialize, Bundler is an important public good, because the verification and execution of UserOperation requires as many Bundler participation as possible to better decentralize. Since Stackup and ETH-infinitism are currently the only third-party Bundler providers available, we definitely need more of them.

Bundler service providers need to overcome many technical difficulties:

• Dive into multiple verification steps both off-chain and on-chain to ensure that the UserOperation can be executed successfully. Technical difficulties include understanding possible state conflicts between multiple UserOperations.
• Understanding the disabling of some OpCode by the validation function:

• Since reading a mutable external state may result in successful transaction verification but failed execution, EIP 4337 prohibits verification functions from calling OpCodes that read external states.
• Different L2s have slightly different prohibitions on the OpCode that reads the external state, which will pose challenges to Multichain development.
• The project party that is building Bundler needs to obtain the OpCodes of each function call through the traceCall function. However, most third-party RPC nodes do not support traceCall, so the Bundler project party may need to run its own node, which also has technical barriers.

• At present, the development focus of most Bundler project parties is on L2, and the Gas fee of L1 and L2 need to be calculated separately.
• A P2P network that implements private and public memory pools. Private memory pools need to provide customized services for searchers and dApps, such as whitelists. An industry standard for the common UserOperation mempool is not yet complete.

The differentiation of Bundler service providers lies in:

• Is the Bundler service built specifically for wallets, or is it built by a third-party infrastructure provider?

• Bundler is only one of many things that wallet project parties need to build, so they are more likely to focus on building a most basic usable Bundler for wallets.
• Third-party infrastructure providers need to build license-free and modular Bundlers and provide high-quality services for different scenarios.

• Similar to Ethereum nodes, Bundler services are implemented in different languages. This language diversity prevents single points of failure and is beneficial to the Ethereum ecosystem.
• Support for private and public memory pools and options for customizing private memory pools.
• Support for L1 and different L2 chains, each with slightly different interface implementations.

6. Let's talk about innovation

This section will enumerate the most requested innovations in smart contract wallet and account abstraction infrastructure.

License-free and modular EIP 4337 infrastructure

Let's first envision the endgame for the EIP 4337 infrastructure:

• Many Bundler, Paymaster and Signature Aggregator providers will compete in an open market. Users can obtain high-quality services at the lowest cost
• There are permissionless public endpoints for Bundler, Paymaster, and Signature Aggregator, as well as endpoints deployed specifically for a smart contract wallet or Dapp
• Smart contract wallets, Dapp, and individual users can deploy the aforementioned infrastructure in a permissionless, modular, and user-friendly manner. In other words, third-party infrastructure providers allow fast and customizable deployment of Bundler, Paymaster and Signature Aggregator from any address

In the current market state, many smart contract wallets have built their own infrastructure, but these infrastructures do not target different usage scenarios of third parties. Third-party infrastructure providers such as Stackup are developing modular Bundler and Paymaster, but their deployment processes are still far from being permission-free. Because EIP 4337 is not yet complete, the modular capabilities of these infrastructures have not yet been fully defined. In addition, due to the low volume of UserOperation transactions, wallets with signature aggregation enabled (such as BLS Wallet) are still not mainstream.

EIP 4337 Downstream Infrastructure

These include downstream infrastructure not defined by EIP 4337 but required to implement EIP 4337 infrastructure, such as fiat currency deposit and withdrawal aggregators and DeFi aggregators that can be integrated into Paymaster. Because these solutions already exist, innovation is most likely to occur within existing providers , who only need to reconfigure the interfaces they expose.

Dapp SDK and scaffolding

Although existing smart contract wallets have built their own client SDKs to facilitate Dapp integration, the market still lacks:

• A Dapp development standard library similar to ether.js that supports account abstraction functions, such as the encapsulation of the following functions:

• Create wallet and restore wallet address using Web2 social media accounts and email
• Creation, signing, sending and event monitoring of UserOperations
• Rapid deployment of Paymaster and Signature Aggregator

• Aggregate SDK and UI tools for all major smart contract wallets
• Scaffolding tools for fast front-end deployment so that Dapp developers can focus on the business logic of their products
• Templates for new Dapp powered by account abstraction, such as games that support gas abstraction

A more radical approach: separate accounts from smart contract wallets

The smart contract wallet interface of EIP 4337 only needs a validateOp function, leaving all core business logic, such as user registration, authority control and social recovery, to the wallet developer's free decision. While this provides more flexibility, different smart contract wallets will further fragment the Ethereum ecosystem , as data in one wallet cannot be easily transferred to another. Dapp may also exacerbate this fragmentation by supporting some smart contract wallets and not others.

In addition, although users can log in to smart contract wallets through email or other common processes in Web2, they still need to log in to Dapp through "connect wallet" operations that are unfamiliar to Web2 users.

A radical solution to these problems is to separate accounts from smart contract wallets by creating new account standards, such as EIP 6662 advocated by Hexlink. EIP 6662 defines an account interface of IAccountMetadata, which enables users to customize the authentication method of their own account (such as Web2 social media account), thereby transferring the authentication logic from the wallet main contract to a separate account interface. Smart contract wallets that support this interface can allow users to transfer their account data to another wallet. A Dapp that supports this interface can allow users to log into their Web3 accounts using the Web2 authentication methods defined in the account interface. Dapp can verify signatures from Web2 authentication methods to query Web3 account addresses, push notifications to Web2 accounts, and connect to Web3 accounts. Users do not need to create different wallets for different Dapp that it supports. Instead, the Dapp will automatically connect to the Web3 account associated with the user's Web2 authentication method. User accounts and wallets are no longer integrated and are no longer subject to wallets. Wallets essentially become Dapp that users can log in to their accounts for asset management.

in conclusion

• EIP 4337 standardizes the smart contract wallet and its related infrastructure into six contract interfaces: smart contract wallet main contract, packager (Bundler), entry point contract (Entry Point Contract), payment contract (Paymaster), wallet factory (Wallet Factory) and Signature Aggregator. UserOperation is a new transaction type supported by EIP 4337.
• There are two types of participants in the account abstraction market:

• A smart contract wallet with functions such as social login, social recovery, gas abstraction, transaction batch processing, and integration and aggregation of third-party services (such as fiat currency deposits and withdrawals and DeFi protocols).
• Third-party providers of infrastructure such as Bundler or Paymaster that focus on modular designs.

• I have the following predictions for the account abstraction market:

• The smart contract wallet market is highly competitive because competing products have similar functions and lower technical barriers.
• Bundler is a public good that is difficult to make a profit but is very necessary for ecology.
• Account abstraction is still a very early market, as adoption is still low, EIP 4337 is not yet complete, and many L2s have not yet implemented support for account abstraction.
• A market for account abstraction requires many innovations such as: permissionless modular infrastructure, integration with existing fiat and DeFi services, Dapp SDKs, and potentially a separate account layer.

Acknowledgment and Disclaimer

When writing this article, I consulted several industry experts and friends, especially thanks to Chen Jian Jason, Wang Yixiang Aaron of PlanckerDAO, independent researcher Spinach Spinach, Hexlink team, Circle Fang of AntAlpha Ventures, Skyhigh and others for their exchanges and discussions !

Due to my limited knowledge and limited research time, errors and omissions may occur. If you have different opinions, welcome to exchange and correct, thank you very much! The research is for personal interest, and there is no economic interest relationship with all the projects mentioned in the article, but it is not intended as investment advice.

references

https://ethereum.org/en/roadmap/account-abstraction/

https://eips.ethereum.org/EIPS/eip-4337

https://antalphaventures.notion.site/2edc5e36f69a44fe9a27dad0ef6ac3fb?v=a0fad60e889a4b2f831a2349d92ca11b

https://www.stackup.sh/blog/a-guide-to-the-top-erc-4337-bundlers-features-performance-and-more

https://github.com/PaymagicXYZ/awesome-account-abstraction

https://camiinthisthang.substack.com/p/account-abstraction-for-everyone

https://research.web3caff.com/zh/archives/4660

https://research.web3caff.com/zh/archives/3212

https://www.alchemy.com/blog/account-abstraction

https://www.alchemy.com/blog/account-abstraction-paymasters

https://www.alchemy.com/blog/account-abstraction-wallet-creation

https://www.alchemy.com/blog/account-abstraction-aggregate-signatures

https://docs.starknet.io/documentation/architecture_and_concepts/Account_Abstraction/approach/

https://era.zksync.io/docs/dev/developer-guides/aa.html#example-of-using-the-library

https://www.alchemy.com/account-abstraction

https://docs.zerodev.app/

https://eips.ethereum.org/EIPS/eip-4361

https://beta-docs.0xpass.io/

https://braavos.notion.site/Public-Docs-d98f625edb2e4399acab2e30d060ef8e

https://github.com/proofofsoulprotocol/soul-wallet-contract

https://docs.wallet.unipass.id/introduction/intro

https://docs.blocknative.com/4337-tools/blocknative-bundler

https://docs.candidewallet.com/develop/getting-started

https://docs.stackup.sh/docs/packages/bundler/introduction

https://github.com/web3well/bls-wallet

https://docs.etherspot.dev/

https://biconomy.gitbook.io/sdk/introduction/overview