Original Authors: CloudY, Jam

Summary

However, in reality, the Ethereum EOA account used for comparison is a relatively primitive product, specifically:

• The account control is single, only signature authorization and non-signature authorization, whether it is a transaction worth $1 or $100 million, requires approval first and then sign to confirm the transaction. So the only difference between being deceived and normal transactions is a signature, which makes every new user nervous when interacting. Although now Metamask allows users to choose the approved amount when approving token permissions, for frequent interaction behavior, users prefer to directly authorize the maximum quantity rather than consuming Gas Fee multiple times for approval. Compared to the Web2 account model, which uses similar Two Factor Authentication (2FA) or hardware tokens to control the risk of large transactions, and face scanning or password-free payment to facilitate small transactions, EOA accounts appear very rigid and difficult to use.

• The Gas Fee threshold is too high, blocking a large number of new users. Ethereum mainnet and Layer2 solutions such as Optimism/Arbitrum use ETH tokens as Gas tokens, which requires users to convert fiat currency into USD stablecoins, then further convert them into ETH, and then transfer ETH into the wallet. Many users only discover the need for ETH as Gas after transferring USD stablecoins into the wallet, and then have to purchase ETH again. Moreover, public chains such as BSC/Polygon/Solana use their own Gas tokens, which is another pitfall for newcomers. In addition, many users do not really want to purchase Gas tokens in advance, but because of the need for on-chain interaction, they have to leave a large amount of redundant Gas tokens in the wallet.

EOA accounts are so difficult to use, Vitalik actually knew this a long time ago, and the Ethereum team has been trying to solve this problem, and account abstraction is one of the solutions. But because it is impossible to modify the underlying consensus of Ethereum for account abstraction, it was not until the proposal of ERC-4337, a solution based on application-layer smart contract wallets, that account abstraction truly received attention and became a hot topic.

This article will briefly introduce account abstraction and ERC-4337, and based on the application of account abstraction and the development of the Web2 account system, speculate on the evolution of the Web3 account system and the attribution of traffic entry.

From an ecological perspective, in the past, users needed to use EOA to perform complex on-chain operations, and because the development of on-chain ecology is limited, only limited protocols can be provided, and the actual needs of users cannot be effectively met. Account abstraction simplifies the above operations, only requiring user input to obtain output, without frequent clicks and cumbersome signatures. It can be said that the implementation of AA shifts the on-chain ecology from seller-dominated to buyer-dominated.

Account Abstraction (AA) and ERC-4337

What does Account Abstraction (AA) specifically refer to? It abstracts the underlying technology and data structure to simplify the operation steps for users and developers. Simply put, it is the functional implementation of "implementing CA based on EOA."

ERC-4337 has become the basic standard for AA. ERC-4337 introduces UserOperation, which is a special transaction that represents user intent and allows contract accounts to actively execute operations. These UserOperations are managed by a role called Bundler, which simulates the execution of UserOperations and adds valid operations to a special transaction pool. Then, the EntryPoint contract verifies and executes these UserOperations to achieve user intent.

Account Types

There are two main types of accounts in Ethereum: Externally Owned Account (EOA) accounts and Contract Accounts (CA).

The address length of EOA accounts is 20 bytes, generated from the private key created by the user and the public key calculated by the elliptic curve encryption algorithm. The state of EOA accounts includes the transaction count (Nonce) and asset amount (Balance). The address of contract accounts is also 20 bytes, but they are calculated from the sender address and Nonce of the transaction created by the contract. The state of contract accounts includes the contract count (Nonce), asset amount (Balance), code hash (CodeHash), and storage root hash (StorageRoot), the latter of which is used to store the root hash value of the Merkle Patricia Trie tree of contract data.

Account types and state information are crucial for transactions and smart contract execution on Ethereum, and are the differences between EOA and CA.

Source: "Account Abstraction, Analysed ｜Qin Wang∗, Shiping Chen∗ ∗CSIRO Data61, Australia"

Transactions

Ethereum transactions include sender and receiver information, digital signatures, transaction count, fund transfer amount, optional data, gas limit, and transaction fees. The two different account types mentioned above result in two completely different communication transaction types.

During the signing process, transaction data is hashed and then digitally signed. Validators verify the validity of the signature by calculating points on the elliptic curve, without needing to obtain the sender's private key, only requiring the transaction information and public key. The recovery of the public key is achieved through the v value in the signature, ensuring the security of the signature and the efficiency of verification.

Account Abstraction

The transaction structure and signature verification process of Ethereum reveal an important fact, that the account initiating the transaction must be an EOA account with a public-private key pair.

Contract accounts, due to the lack of public-private key pairs, cannot actively initiate transactions, but automatically execute the smart contract code in the account based on the information in the transaction, or send transaction information to other accounts, or even create new smart contracts. Therefore, the wallets created by mainstream wallet applications such as Metamask are all EOA accounts. However, EOA accounts have some flaws in use: private key risk, limited signature algorithms, excessive signature permissions, and transaction fee limitations.

Contract accounts can store code and data, and execute predefined smart contract logic to solve the above problems of EOA accounts. However, contract accounts cannot actively initiate transactions.

Account abstraction is an improvement on the above two account types, attempting to blur the boundaries between the two and become a universal account with complex logic, allowing the account to have the functionality of both CA (contract account) and EOA account.

ERC-4337

ERC-4337 achieves account abstraction without modifying the underlying Ethereum consensus layer, and has become the solution ultimately adopted by Ethereum. It ultimately realizes off-chain matching and on-chain transactions.

Source: "Account Abstraction, Analysed ｜Qin Wang∗, Shiping Chen∗ ∗CSIRO Data61, Australia"

UserOperation

ERC-4337 introduces a new concept called UserOperation to solve the problem of contract accounts being unable to actively initiate transactions, while avoiding changes to the underlying transaction types of the Ethereum protocol.

UserOperation is similar to a standard transaction, but it only represents the user's intent, rather than direct transaction behavior. Standard transactions are sent to Ethereum's mempool and then combined into a complete block by searchers and builders, which is ultimately sent to the blockchain by a proposer, usually choosing the block with the highest reward. In contrast, UserOperation is not a real transaction, so ERC-4337 introduces a new mempool and a role called Bundler to execute UserOperation in a decentralized manner. This innovation allows user intent to be processed and executed without directly participating in the standard transaction process.

Source: ERC 4337: account abstraction without Ethereum protocol changes

Bundler

When processing UserOperation, Bundler first performs basic validity checks, then simulates the execution of operations to confirm the validity of the signature. If the simulation is successful, the UserOperation is added to the UserOperation mempool, awaiting actual on-chain execution. To ensure consistency between simulation and actual execution, UserOperation restricts access to variables that may change during execution and only allows access to data related to the sender's address. Bundler can package UserOperation according to its preferences, prioritizing operations with higher fees. Finally, Bundler sends the batch of valid operations to the EntryPoint contract for on-chain execution.

EntryPoint

EntryPoint is a singleton contract in Ethereum, and its main task is to handle the execution of UserOperation. It has two key functions: handleOps and handleAggregatedOps, both of which first verify UserOperation and then execute the operations. Verification includes checking the account, signature validity, and fee payment. During the execution phase, the smart contract code in the target contract account is called using the data from UserOperation. Different smart contract wallet protocols may have different parsing and execution methods.

Source: ERC-4337: Account Abstraction Using Alt Mempool

Data

According to the ERC-4337 Semi-Annual Data Report by SixdegreeLab:

• After the deployment of the ERC-4337 contract, over 687,000 AA wallets were created on-chain, and UserOps were called over 2 million times. However, 88.24% of AA wallets were used less than 5 times, mostly for direct transfers or NFT minting.

• Among the 15,000 Bundlers, Pimlico accounted for 43.48% of them, holding the largest market share, while Alchemy generated the highest revenue ever, approximately $20,000.

• However, 97.18% of Bundled transactions only contained 1 UserOp, meaning that 90% of Bundlers could not profit from packaging transactions.

• 117 Paymasters collectively paid $465,000 in gas fees for 19 million UserOps, with Pimlico paying 43.45%.

• ZeroDev dominated the Wallet Factory, deploying 62.63% of the accounts.

• The most common method of constructing AA wallets is LEGO, using different third-party Paymasters, Wallet Factories, and Bundlers.

It is evident that there is still significant room for growth in the adoption of ERC-4337, and infrastructure development has only just begun, making the future of AA full of possibilities. With the rise of Layer2 and social applications, the use of AA wallets will experience rapid growth.

Development Direction of Account Abstraction

After understanding the basic principles of account abstraction and the architecture of ERC-4337, we will further explore the expansion methods of AA. We will not elaborate on the basic functions of smart contract wallets without private keys and gas, but instead look for more possibilities within the components of AA:

Architecture

• Native Account Abstraction

ERC-4337 is only an application-layer solution to address the inability to modify the underlying consensus of Ethereum. Although it popularizes the concept of account abstraction, it ultimately relies on contract accounts for interaction. Additional gas consumption during the verification process, the adoption of other competing ERCs, and dapp restrictions on contract account interaction are all factors hindering the growth of ERC-4337.

Therefore, native account abstraction, especially native account abstraction in Layer2, is particularly important. Currently, only Starknet and ZKSync support native account abstraction in Layer2. In the native account abstraction scheme, there are no Bundlers and Paymasters. Starknet uses the Sequencer to determine transaction order, pay gas, and execute, while ZKSync uses the Operator to determine transaction order, pay gas, and then call the bootloader to operate together.

The DeBank Chain, which claims to be built on the OP Stack, also aims to integrate a similar account abstraction system at the chain level, but the specific architecture will only be known when its mainnet is launched.

Source: "Introduction to Native Account Abstraction in zkSync"

• NFT Contract Wallets

NFT contract wallets are an application-layer account abstraction solution similar to ERC-4337. They enable EOA accounts to have the functionality of CA accounts through NFT, without relying on Bundler calling the EntryPoint contract. There are currently two mainstream implementations of NFT contract wallets: ERC-6551 and A3S Protocol.

ERC-6551 allows users to use their own EOA wallet's ERC-721 standard NFT as a controller to control one or multiple newly created smart contract wallets, enabling the matching of existing NFT with one or multiple smart contract accounts through an "external contract" without modifying the ERC-721 code. This approach combines existing NFT with account abstraction, opening up NFT use cases and popularizing the concept of account abstraction.

Source: "EIP-6551"

The A3S Protocol uses the smart contract of the NFT itself as the smart contract wallet, meaning that the wallet assets are on the smart contract account of the NFT, completely following the transfer of NFT ownership, without the need to attach a separate contract account as a wallet for the NFT, achieving NFT contract wallets through a shorter path, but also meaning incompatibility with existing NFTs.

Source: "A3S Protocol Gitbook"

In the unification of multi-chain wallet addresses, both solutions use obfuscation values (Salt) to achieve the same address on different EVM-compatible public chains, solving the problem of confusion of contract account multi-chain addresses. This was also the issue that led to Wintermute losing 20 million OP tokens when transferring to multi-signature addresses on different chains.

• Modularity and Multi-Chain Abstraction

The significance of modular account abstraction is to minimize the cost of development and maintenance, similar to OP Stack, allowing wallet developers to focus more on the product itself rather than the construction and maintenance of underlying infrastructure. The modular ecosystem established in this way is also the foundation of modular platforms. Therefore, modular account abstraction must achieve:

1. Interchangeability of various modules (EIP-6900 is attempting to establish standard implementation)

2. Diversity of module functions (signature schemes/privacy/MEV resistance/deposits and withdrawals/intent, etc.)

3. Security (uniform standards for each module to avoid storage conflicts)

4. Multi-chain abstraction (Vitalik proposed using a unified single-chain key library contract to achieve collaborative multi-chain smart contract accounts)

As mentioned earlier, we used Salt to make the addresses of multi-chain smart contract accounts consistent. However, having consistent addresses is only the first step. More importantly, it is to make users unaware of cross-chain operations during transactions, i.e., multi-chain abstraction, which is an important step in modularity and account abstraction.

Source: "Future of Smart Accounts: Modular, Specialised & Multichain"

Signature Verification

We previously mentioned that any transaction on Ethereum can only be initiated and paid for in ETH by EOA. In addition, EOA can only use the ECDSA signature scheme, making EOA usage very cumbersome and functionally limited, with the risk of private key leakage. The day when quantum computers emerge will also be the day when Ethereum EOAs become vulnerable.

Signature Algorithms

At the signature level, there are already solutions that implement multi-signature and social recovery through smart contracts (Gnosis Safe and Argent), as well as solutions that use so-called signature abstraction to authorize once and freely interact with contracts within a given range (Lens Protocol). However, according to the principle of "Not your keys, not your coins," we can pay more attention to the signature algorithm itself:

• Signature Aggregation

Implementing more efficient and simpler signatures through Schnorr or BLS, which not only enables multi-signatures at the base level but also reduces gas consumption through aggregated signatures. Of course, they each have their own issues, such as requiring additional communication rounds, not being suitable for multi-signature schemes with large values of m and n, and a large amount of time for matching verification.

• Post-Quantum Secure Signatures

Using one-time signatures such as Lamport or W-OTS to prevent others from using quantum computers to crack publicly disclosed partial private keys to forge messages and signatures.

UserOperation

• ERC7521 Intent Centric

When comparing account abstraction, especially ERC-4337, with the Intent Centric architecture, it can be seen that Bundler and Solver can actually be the same person. In other words, the user's interaction content "UserOperation" can be provided by the Bundler, and the Bundler interprets the user's intent to propose a matching solution path, then confirms the legality of the path to the user through the EntryPoint contract to avoid malicious behavior by the Bundler, and finally executes the verified intent path.

The combination of account abstraction and intent will be able to achieve synchronous abstraction of accounts and interactions, surpassing the user experience of Web2.

Source: "ERC-7521"

The entire transaction process can be achieved through processes such as witnesses/challenges and responses, using ZK proof technology to achieve privacy payments. This not only allows users to prove the validity of transactions without revealing the sender's real address but also batch multiple transactions into a single proof, reducing computational costs and significantly improving scalability, achieving cost reduction and efficiency improvement. Some enterprise users who need to comply with regulations can also transparently disclose transactions to regulators, meeting compliance requirements without sacrificing confidentiality.

Source: "ZKPayments: Achieving Privacy and Scalability"

Bundler

• Bundler MEV and Bundler Competition

Bundler MEV and Bundler Competition are both the result of inadequate infrastructure. Bundler MEV comes from the Bundler's transaction packaging responsibility similar to that of a Searcher, where the Bundler can change the submission order of UserOperation for profit, while Bundler Competition arises when different Bundlers package the same UserOperation. This is similar to the Gas War of the Searcher, where the Bundled UserOperation that did not go on-chain, although it spent gas, failed.

They can both learn from existing infrastructure, such as MEV-Boost, to establish communication channels between Bundlers and between Bundlers and Block Builders. Etherspot is developing a p2p network for AA to transmit UserOperations waiting to be packaged. Once they are packaged and processed on-chain, they will be marked and removed from the list, avoiding being packaged by multiple Bundlers.

Source: "Why ERC-4337 Bundlers Need to Collaborate with Block Builders"

Paymaster

• Paymaster Deposits and Withdrawals

Paymasters can pay gas fees for users and negotiate with users to use any token or fiat currency as a substitute. Therefore, Paymaster working with payment service providers to provide deposit and withdrawal services for users is a good solution.

Visa's team has deployed two experimental Visa Paymaster contracts on the Ethereum Goerli testnet, one to explore whether users can pay fees with tokens including USD stablecoins, and the other to directly sponsor transaction fees. Of course, integrating Paymaster with existing ERC-20 tokens requires the use of an external source or on-chain oracle to determine token prices and check if the Paymaster contract is approved to collect specified tokens from users. In this mature solution, direct access to Visa cards for fiat currency gas payments, and even real-time conversion with ERC-20 tokens, will significantly lower the entry barriers for Web2 users through the abstraction of deposits and withdrawals.

Evolution of Web3 Account System and Future Web3 Entry Points

The evolution of the account system in the Web3 era retains some shadows of Web2 while presenting a unique development path. In Web3, various types of accounts have emerged, including plugin wallets like Metamask, software wallets like Math and Trust, "operating platforms" like dAppOS and Gnosis Safe, as well as UniPass embedded in dApps and OKX Web3 Wallet integrated into exchanges.

Traffic Entry Points

As we mentioned in the article "Web3 Traffic Entry Points," all these entry points can become part of the AA wallet. However, they also divide the adoption path of the AA wallet into two categories: accounts and applications. Users can either obtain accounts first and then interact with applications, or interact with applications first and then use accounts.

Source: OP Research

Account System

The evolution of the account system in the Web3 era continues some characteristics of Web2 while presenting a unique development path. In Web3, various types of accounts have emerged, including plugin wallets like Metamask, software wallets like Math and Trust, "operating platforms" like dAppOS and Gnosis Safe, as well as UniPass embedded in dApps and OKX Web3 Wallet integrated into exchanges.

• Traffic Entry Points

We still believe that all these entry points can become part of the AA wallet. However, they also divide the adoption path of the AA wallet into two categories: accounts and applications. Users can either obtain accounts first and then interact with applications, or interact with applications first and then use accounts.

Wallet Mini Programs and Wallet as a Service

When we look at the adoption process of AA, we can see that it initially started with Instadapp's independent AA wallet product Avocado, followed by Metamask's release of Snaps mini-program components supporting some AA functions. Payment giant Visa also joined in with Paymaster experimentation and integration with Visa Card payments. Shortly after, social app Lens Protocol attempted to establish an AA wallet through ERC-6551, while Safe also supported ERC-4337 to consolidate its "mini-program" market. Following suit, OKX Wallet supported the use of AA wallets, and Circle chose to release its own AA wallet.

Two Adoption Models

The adoption of AA can be categorized into two models:

1. Self-owned wallet release or compatibility with AA to attract and retain users through wallet users and internal application mini-programs.

2. Applications/exchanges/payment service providers leveraging their traffic advantage to convert users into AA wallet users.

This leads to the discussion of which model users will prefer, as the on-chain ecosystem will shift from a seller's market to a buyer's market due to the emergence of AA.

Source: "Binance Research: Account Abstraction Report"

Mini Programs

From a short-term adoption perspective, the AA model based on the development of mini-program ecology with its own wallet will be more easily accepted by users, essentially being a B2C solution. Because most of the current users trying AA wallets are Web3 users, the wallet itself is not unfamiliar to them and does not require additional understanding to use directly. The rich functionality and smooth user experience can attract and retain them. Taking MetaMask's Snaps as an example, through API interfaces, it allows third-party developers to develop corresponding wallet mini-programs for interaction on non-EVM chains. This seems to be diverting traffic to other wallets, but in reality, it is educating users for its own ecosystem. Undoubtedly, the day MetaMask fully supports ERC-4337 will be the day it becomes the leader in AA wallets.

Using dappOS as an example:

dappOS = dappOS Account (multi-chain unified EOA) + dappOS Network.

dappOS Account: Allows users to use a "unified account" based on account abstraction, rather than a regular externally owned account (EOA). This approach makes it possible for users to recover accounts, process transactions in batches, and automate execution, while the aggregation of multi-chain wallets also facilitates unified asset management on different chains.

dappOS Network: A decentralized network that helps users automatically execute wallet and cross-chain operations, completing the complex interaction process behind transactions.

dappOS attempts to abstract the concepts of accounts, public chains, and Gas Tokens, providing users with a similar experience to Web2 accounts. However, due to its relatively early stage, the platform's collaboration with dapps is limited. Nevertheless, this does not hinder the growth of user data. Users are motivated to migrate from EOA, especially those who need multi-account and multi-chain interactions. The interaction experience after migration outweighs the migration cost. Once users enter, they are unlikely to leave the account system because they are being educated while using it. Users who initially use AA wallets cannot use EOA wallets, and wallets like dappOS can meet most of the users' interaction needs. Users do not need to migrate. Even if users want to migrate, the invisible multi-chain abstraction will make the entire migration process cumbersome.

It is evident that mature wallet products can quickly acquire and retain Web3 AA users, such as Safe, Avocado, OKX Wallet, and others.

Waas

WaaS is the application route of AA wallets, which is the opposite of the mini-program route. Having applications before wallets is clearly a B2B solution. Applications use WaaS to customize their wallets to complement product features. Standardized WaaS modules are available for different applications to choose from, leveraging the application's traffic to expand their own ecosystem, build the AA wallet platform, and then issue customized wallets for users. Users can freely choose the wallet functions they need.

Taking Stepn as an example, as a popular application, Stepn has millions of users globally, and each user has created a wallet through Stepn. If Stepn embeds an AA wallet and continues to develop its ecosystem, such as the subsequent MOOAR NFT marketplace, mahjong games, and Gashero, then this single AA wallet alone can bring millions of incremental users to the entire crypto market. These users are highly sticky to the AA wallet because the migration cost for them is extremely high.

Recently, the popular Friend Tech also follows a similar approach. Every Twitter user can be a potential user of its AA wallet. Fiat deposits and withdrawals and Gas token payments enable users to overcome the interaction barriers of Web3 and quickly integrate into Web3.

In practical products, we can focus on WaaS Pay and UniPass, which represent the characteristics of wallet direction in the WaaS route:

• WaaS Pay is a smart contract account deployment platform designed for organizations seeking instant blockchain payments while prioritizing privacy, using the Safe{Core} protocol suite and Safe{Core} account abstraction SDK. It provides a user-friendly no-code interface to customize smart contract account functions, such as social login, fiat currency on/off ramps, and gasless transactions for recipients. By using ZKBob to facilitate anonymous transactions through zero-knowledge proofs (ZKP), WaaS Pay ensures that sensitive financial data remains secure and confidential. The platform is supported by Polygon ZKEVM to ensure scalability and efficiency, while self-hosted IPFS nodes with Helia protect sensitive metadata.

• UniPass is essentially an SDK provided for third-party dapps, allowing dapps to bypass traditional account private keys and a series of signatures and gas limitations, or to manage private key generation and address binding in a centralized manner. It directly uses UniPass's DKIM verification to implement unmanaged accounts controlled by email, while simplifying on-chain interactions through Relayer, achieving gasless/signature abstraction, social replies, and other features that greatly enhance user interaction experience. As a scenario-driven application, UniPass chooses to provide customized services for different applications in a federated social network manner, while establishing interconnected account systems. Based on the interoperability of this federated social network, while providing data ownership and privacy protection, it links social relationships on-chain, establishing DID proof of ownership of data and assets, to attract more applications to use UniPass's SDK to enter Web3. The users of these applications naturally become UniPass users and continue to interact in Web3 using it, with extremely high stickiness.

From this, we can also see that the WaaS route of AA wallets has advantages in growth space and acquiring Web2 users, but this greatly tests the team's product quality and business development capabilities. However, once network effects are formed, it will have growth inertia, belonging to the type that exerts effort in the later stages.

Reference

[1] "Sixdegree ERC4337 Half-Year Data Report" https://sixdegree.xyz/research/Half-Year-Data-Report-of-ERC4337-by-Sixdegree.pdf

[2] "In-depth Analysis of 'Account Abstraction': 7-Year Evolution and Track Map" https://www.chaincatcher.com/article/2085142

[3] "Interpreting the Binance Research Account Abstraction Report" https://www.techflowpost.com/article/detail_12784.html

[4] "EIP-6551" https://eips.ethereum.org/EIPS/eip-6551

[5] "A3S Protocol Gitbook" https://a3sprotocolcontact.gitbook.io/a3s-protocol/a3s-v1.0/how-a3s-v1.0-works

[6] "Future of Smart Accounts: Modular, Specialised & Multichain" https://longhashvc.medium.com/future-of-smart-accounts-modular-specialised-multichain-d04f083375a6

[7] "Why Does the Bundler of ERC-4337 Need to Cooperate with Block Builders" https://learnblockchain.cn/article/6205

[8] "Complete Guide to Account Abstraction" https://news.marsbit.co/20230302172702633640.html

[9] "How Infrastructure Supports Billions of Users Through Account Abstraction" https://www.panewslab.com/zh/articledetails/24hz8399g6my.html

[10] "You Could Have Invented Account Abstraction: Part 1" https://www.alchemy.com/blog/account-abstraction

[11] "Ethereum Account Abstraction Research Report: Breaking Down 10 Related EIP Proposals and Addressing Bottlenecks Impacting Tens of Millions of Daily Active Users" https://www.odaily.news/post/5183201

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。