Introduction

Self – custody required wallet address is the user’s “account” in the on-chain world, a major obstacle for users to onboard Web3. In fact, the attempt of improving the “account” system has been ongoing for more than seven years. Until October 2022, Vitalik Buterin introduced EIP-4337 and account abstraction in his Twitter thread. Later in November, Account Abstraction become frequently mentioned in various sharing sessions at Devcon 6 in Bogota, sparking lively discussion about Account Abstraction, smart contract wallets, and 4337.

Account abstraction is a significant improvement for supporting users to enter an on-chain world. Not your keys, not your coins. Self-custody has been repeatedly emphasized by crypto OGs, but very few people listened. The high degree of maneuverability brought by Account Abstraction can truly give the masses a more secure and more user-friendly experience in the decentralized world, and self-custody will no longer be a thing for geeks. While FTX’s collapse has cast a shadow over the future of crypto, it undoubtedly verifies the necessity of decentralized applications and self-custody. With the implementation of Account Abstraction, the whole industry will be more empowered to break free from the centralized “Villains” and “Emperors”, moving towards a higher dimension of decentralization and freedom.

While EIP-4337 is regarded by many as the direction for Account Abstraction, the proposal is only an overly ideal draft. For example, gas fee can be apportioned by ‘bundle transactions’, yet in practice, additional gas costs may be generated during validation. Another example would be that the smart-contract wallets will ideally all apply a unified architecture and form a strong consensus, but in practice its effectiveness is weak as it is only a compromised voluntary ERC standard. Sure, EIP-4337 accounts can offer a better user experience, but in practice it faces the awkward fact that many Dapps do not support interacting with and EIP-4337 supported wallet address.

EIP-4337 is a shift in the evolution of Account Abstraction, but it is a compromise to the facts of tight resources and excessive impact of direct code changes on Ethereum. This compromise helps to spread the idea of Account Abstraction and laying a foundation for consensus in the future But it is not the final form of Account Abstraction. In the end, Ethereum will still need to implement Account Abstraction at the consensus layer in order to reach the utopia we were all aspired to by EIP-4337.

What Is Account Abstraction —— From Abacus to Smart Calculator

Before discussing the specific meaning of Account Abstraction, let’s first break it down to what “Account” and “Abstraction” are respectively.

To put it simply, Ethereum is built on two types of accounts, one carrying the user’s wallet and the other carrying the logic of smart contracts. Their functions are mostly incompatible: the user’s wallet cannot process logical judgments, while the account hosting the smart contract cannot do anything other than processing logics. As you can imagine, such an account system is not optimized. The goal of Account Abstraction is to eliminate this incompatibility and “generalize” their differences – to remove the specificity and find the commonality.

Accounts

Ethereum has two types of accounts: Externally Owned Account (EOA) and Contract Account (CA).

EOA is the type of account that’s mostly encountered by users, an example would the address shown on MetaMask, which is controlled by a user with a private key. CA, on the other hand, is a smart contract deployed to the Ethereum network, controlled by the code instead of a private key. The similarities and differences between the two types of accounts can be seen below.

Abstraction

Abstraction is the process of generalizing specific problems, and then use general solutions to deal with them. In other words, abstraction is a process of “generalization”.

Let‘s take a concrete example in real life to understand what abstraction means for Ethereum: The structure of a toy car is special and concrete, consisting of a special set of parts such as four wheels and the body. If you want to have a truck toy or an airplane toy, you will need to buy a new one. The structure of LEGO, on the other hand, is abstract and general. LEGO breaks toys into general block modules such as cubes and spheres, and you can use these blocks to build things in any shape.

The development of blockchain is an abstract process as well. The initial purpose of Bitcoin was special and clear, which was to realize a peer-to-peer cash system; while Ethereum turned blockchain into a more general system, removing the special features designed for peer-to-peer payment and extracting the commonality of blockchain technology to build a new network. With Ethereum virtual machine (EVM), a variety of different protocols and applications can be freely constructed on the blockchain, expanding the blockchain ecosystem. 

Account Abstraction

Account Abstraction aims to generalize Ethereum’s account system in order to remove the specificity of different types of accounts. As mentioned above, Ethereum has two types of accounts, EOA and CA, each with its own characteristics. EOAs have always been more privileged than CAs (the more “top level” account) because only EOAs can start transaction execution by paying gas. And EOA can only use ECDSA signature scheme, implemented by the elliptic curve cryptography Secp256k1. CAs supporting code logic need to be deployed and can only send transactions initiated by EOAs.

All this comes from the special enforced design of Ethereum architecture. Where the purpose of Account Abstraction to generalize Ethereum accounts is important. Specifically, generalizing for the special characteristics of accounts will extract the following keys to Account Abstraction.

1. Cryptographic Abstraction: signature verification of accounts is no longer limited to a specific encryption algorithm; users can customize the choice of different encryption algorithms as a security mechanism.
2. Account Function Abstraction: support code logic to achieve custom functions
3. Transaction Abstraction: accounts can all initiate transactions; gas payments can be customized

In short, for developers, Account Abstraction will bring more freedom and possibilities; for users, Account Abstraction brings better user experience in several dimensions, such as security, ease of use, and functionality. Before Account Abstraction, a user’s wallet was just an abacus that could only conduct addition or subtraction. After the implementation of Account Abstraction, the abacus will have the function of logical judgment，like a smart calculator with a chip added into it.

The evolution of Account Abstraction – transitioning from radical to moderate towards the end-state

The discussion on Account Abstraction started as early as a few months after the official launch of Ethereum in 2015, and new proposals continued to emerge. We have sorted through EIPs related to Account Abstraction in chronological order to get a glimpse of the different solutions and developments below:

Since the launch of Ethereum in 2015, Account Abstraction was initially proposed in EIP-86 and experienced a five-year-long radical reform composed full of idealism. None of these proposals for Account Abstraction that requires underlying code changes have advanced to the review stage, several subsidiary proposals were approved, laying the groundwork for Account Abstraction. For example, EIP-1014 enables to calculate contract addresses in advance before deploying a contract, and EIP-1271 implements a scheme for signing through contract accounts.

After the setback from reforming the account system radically, Account Abstraction began to look for more moderate compromise solutions. This phase no longer attempted to directly change the underlying code of Ethereum, but mainly introduced the ERC standards for voluntary adoption by developers. EIP-4337 opened the era of moderate advancement of Account Abstraction. Recently, EIP-5189 has proposed further optimizations based on EIP-4337.

ERC standards aimed at Account Abstraction are a compromise for the slow change, high impact and poor compatibility to the underlying code. Such a moderate approach helps the concept of Account Abstraction to spread, allowing Account Abstraction to be implemented from the ideal discussion to the practicable reality first, and to improve and refine the shortcomings of the existing scheme in practice step by step.

In the future, after a mild evolution and a reaching a certain consensus, it may be possible to apply EIP-3074, EIP-5003 and other proposals to upgrade EOAs to CAs. Ethereum will ultimately realize its original vision of making thorough changes to the underlying protocol and unifying accounts into a single programmable and customizable account.

The Past – Radical Reform

In the beginning, the attempt to achievingAccount Abstraction has been a violent reform with direct modifications to the consensus layer since the initial proposal and has been refined repeatedly in this phase.

EIP-101

Introduction:

The concept of abstraction was first proposed by Vitalik, the founder of Ethereum, in EIP-101 at the end of 2015. In this proposal, Vitalik discussed the abstract design of Serenity’s account system, simplifying the account from 4 fields to only 2 fields: code and storage, with ETH all stored in a token contract, while keeping the address lists that map users’ balances. It also simplifies a transaction from 8 fields to 4 fields, which greatly abstracts the account and transaction.

Advantages

• Users areable to customize their own security model and use other encryption algorithm to secure them accounts
• ETH and other ERC-20 tokens are treated equally
• Reduce the indirectness of custom account features such as multi-signature

Problems and Status

The proposal made radical changes to the account system, with compatibility issues as well as security concerns, and thus, was temporarily shelved at the time and is now in stagnant status.

EIP-86

Introduction

In 2017, Vitalik proposed EIP-86 to abstract the source of transactions as well as signatures, again making radical changes to the underlying code. This proposal allows users to create account contracts that perform any desired signature/nonce checks. There is an “entry point” address, an address from which anyone could send transactions. The account contract receives data from “entry point” and verifies the signature, and if the signature is correct it sets up a gas payment to the miner. This proposal is a preparation of Account Abstraction that allows users to define the signature algorithm instead of using ECDSA and the default nonce scheme that are hard coded in Ethereum. Meanwhile, gas is paid by account contracts only after correct signature verification. 

Advantages

• Multisig: Each participant does not have to spend ETH, transactions containing all signatures can be sent to the contract directly, where the contract can pay the fees itself. 
• Ring signature mixers: Ring signature can be simply understood as a mechanism where the first and last signatures are joined to form a “ring”, thus nobody knows where it starts and ends .  Individuals send the same number of tokens into a contract, and then use a linkable ring signature to withdraw the same number of tokens later. However, there is a privacy risk due to the need to prepare gas for withdraw. With this EIP, gas could be straightly paid from the withdrawn coins, which guarantees the privacy in this scenario.
• Custom cryptography: users can upgrade to Lamport hash ladder signatures or any other scheme they want on their own terms
• Non-cryptographic modifications: users can require transactions to have expiry times 

Problems and Status

• The new type of transaction has no sender (all are entry points), which destroys the uniqueness of the transaction hash and all protocols that rely on hash uniqueness is therefore incompatible
• The “gasless payments” of account is not necessary, because it can be realized now through “agent contract” with higher cost
• Miners’ mining strategies will be greatly affected
• The new type of transaction retains the fields nonce, gasprice, value, etc. and they are set to 0, which lacks code elegance

As a result, based on these issues, the proposal was eventually put on hold for introduction and is currently in stagnant status.

EIP-859

Introduction

The proposal introduces a new type of transaction and a new PAYGAS opcode. It maintains transaction hash uniqueness by still enforcing the nonce field in the transaction. The new PAYGAS opcode is introduced for paying gas, serving as a logical demarcation of the “verification parts of a transaction” and the “execution parts of a transaction.

Advantages

• Customized signature scheme
• Maintains the uniqueness of hash
• Supports verification conditions to be more complex, saving gas in a variety of scenarios. One particular use case is ICOs. For example, if there are 10000 transactions going into an ICO but the cap can only accept 5000, then currently all 10000 would get included with the last 5000 being excluded, thus saving gas costs and reducing invalid spam transactions.

Problems and Status

• Cannot use ERC20s to pay for gas

In fact, EIP-859 did not form a definitive draft, but only in the discussion stage. The proposal was also discussed at several Ethereum developer meetings, but it was permanently shelved due to the lack of maturity and the fact that the upgrade already contained a lot of content at that time.

EIP-1014

Introduction

EIP-1014 does not directly mention Account Abstraction but is relevant to its development. The proposal introduces a way in which a contract can be preprocessed before the actual deployment of the contract address, which allows users to receive funds to this address even before deploying their smart contract wallet to it. Users can actually deploy it when the first transaction is made using this contract address.

Advantages

• Cost savings: users can pre-process the contract before paying gas for contract deployment 
• The consistency of multi-chain contract address: the contract address only exists after deployment, so unlike EOA can directly achieve multi-chain consistency; through the salt parameter in the opcode, the contract address can also realize multi-chain consistency

Status

EIP-1013 was finally approved, laying an important foundation for the development of smart contract wallets.

EIP-1271

Introduction

EIP-1271 proposes a standard way for any contracts to verify whether a signature on a behalf of a given contract is valid. This allows CAs to validate the signature just like EOAs.

Advantages

The proposal has become an approved ERC standard where developers can adopt voluntarily. This lays a good foundation for the promotion and popularity of contract accounts in the future, as long as dapps are willing to support contract address signature by simply adding the code of EIP-1271 to the protocol.

Status

EIP-1271 was finally approved and already has practical applications, such as OpenSea supports for Authereum smart contract wallets for signed logins.

EIP-2938

Introduction

In 2020, Vitalik has proposed a more complete solution to Account Abstraction in conjunction with multiple contributors. Compared to the previous solutions of unifying account types into one contract account, the EIP-2938 proposal still maintains the existing two types of accounts (EOA and CA) but accepts a contract to be the top-level account that pays fees and starts transaction execution.

The proposal defines a new Account Abstraction transaction type that requires two new opcodes: NONCE and PAYGAS, which still requires modifications to the underlying code of Ethereum.

EIP-2938 also maps out the solution implementation and describes specific application scenarios. The applications of Account Abstraction are considered across two stages: The first stage supports single-tenant Account Abstraction, the later stages move toward supporting multi-tenant Account Abstraction.

Advantages and Scenarios

Single-tenant

• Customize signature verification schemes other than ECDSA (e.g., BLS, post-quantum)
• Add smart contract wallet features such as multisig verification or social recovery
• Pay for gas using ERC-20 tokens

Multi-tenant

• Privacy: In privacy-preserving systems like tornado.cash, accounts no longer  face risk to expose privacy from preparing gas fees.
• Save gas fees: For example, when arbitrage opportunities arise, a large number of arbitrageurs initiate arbitrage transactions at the same time, and after the first successful one, other arbitrage transactions fail but are still packed in the block. After Account Abstraction, it allows the arbitrageurs to not pay gas for the failed transactions, reducing the number of junk transactions on chain.

Problems and Status

Although this proposal is more detailed, the technical solution for multi-tenant phase is still unformed. It was also not considered to be technically and economically efficient enough to move to the final stage.

At this point, the first phase of Account Abstraction, radical and violent changes to the core protocols of Ethereum, has almost all been shelved. The priority, necessity, economic efficiency, and compatibility of Account Abstraction all remain to be further optimized.

The Present – Moderate Change

As Ethereum’s developers are focused on Ethereum’ merge and sharding, proposals making direct core protocol modifications are difficult to advance. Developers, represented by Vitalik, have had to compromise by proposing relatively more modest, indirect alternatives.

EIP4337

Introduction

This EIP is the first proposal that introduces Account Abstraction without any modifications to the core protocol. It achieves so by introducing UserOperation object. Users send UserOperation objects to a separate mempool, which is packaged into a single “bundle transaction” via Bundler. Then this calls an entryPoint contract for verification. If all is successful, it is then included in a block.

Advantages

• Customized signature algorithms: support various signature algorithms other than ECDSA
• Customized functions: Realizing gas sponsoring, social recovery and other functions through the contract code

Problems and Status

• Non-upgradable: to support the standard, users need to transfer assets and activities to a new address 
• Gas overhead: more gas overhead than regular transactions because of importing UserOperation
• Incompatible: some existing dapps or protocols may prohibit interaction with contract accounts

Despite the many practical issues, Vitalik plans to first support EIP-4337 in the short term while continuously refining and improving it in practice. After forming a consensus at scale through widely discussion and promotion, it will be beneficial to motivate existing applications to make changes to support the interactions of contract account and ERC-1271’s contract signature standard. Currently, EIP-4337 is still in draft status, waiting to advance to the next stage.

EIP-5189

Introduction

This EIP is an ERC proposal that changes the transaction packaging process, again avoiding protocol changes. this proposal introduces the role of endorser contracts, which are defined by smart contract wallet developers. These smart contract instances are tasked with determining the quality of the submitted meta-transactions, thus, safely helping bundlers determine if a meta-transaction should be kept in the mempool or not. This proposal moves the risk brought by Account Abstraction from bundler to the wallet developer, who is expected to be responsible for coding and deploying endorser contracts.

Advantages

• Lower the threshold and risk of filtrating meta-transactions for bundler

Problems and Status

The proposal is just in draft form and is still in the early stages.

In this phase, the schemes of Account Abstraction have transformed from the early violent revolution to a moderate evolution. Although the strength of reform has been weaker, it is easier to implement and can advance the development of smart contract wallets to attract and build up a certain user base.

The Future – Mandatory Implementation

Vitalik has proposed that in the process of implementing ERC-4337, new proposals would be introduced to improve the shortcomings of ERC-4337, such the upgrade of EOAs to contract addresses and the optimization of gas fees. The possible path will be from voluntary adoption to widespread popularity, and then to the eventual implementation of mandatory conversion, ultimately achieve the  goal of unifying Ethereum account types into one.

EIP-3074

Introduction

EIP-3074, which was proposed earlier than EIP-4337, did not introduce a new transaction type, but introduced two opcodes, AUTH and AUTHCALL. The new opcodes allow EOA to delegate control to a contract, which enables all EOAs to perform the functions of a smart contract wallet.

Advantages

• Gas sponsoring: gas fees can be paid from another account, and tokens can be sent from addresses without ETH. 
• Batch transactions: Sending multiple transactions with a single call reduces transaction fees

Problems and Status

This proposal stills requires protocol changes, which is planned to be implemented in the Shanghai upgrade and is still under review phase due to various security uncertainties.

EIP-5003

Introduction

This proposal is an expansion proposal of EIP-3074. It introduces a new operation code, AUTHUSURP, which deploys code at the authorized address, realizing the upgrade of EOA to contract account.

Advantages

• Convert an EOA to a contract account

Status

The proposal is based on EIP-3074, which is still in draft stage and the progress would be affected by the progress of EIP-3074.

Layer2？

From the above EIPs development, we can see that Account Abstraction aims to solve the legacy problem of Ethereum’s dual account system. However, the shcemes of directly making modifications to the protocol, although more direct, requires more developers. As the urgency of Account Abstraction is not yet high, it has encountered many obstacles. In contrast, the direct code change solution may be more suitable for new layer2 public blockchains with start-up ecology. Starknet, for example, is a chain that natively supports Account Abstraction, with only one unified account type that can be programmed to send transactions, send and receive assets, etc. The zkSync 2.0 mainnet, which went live in October, also introduced the new feature of Account Abstraction, which allows accounts to initiate transactions and execute the code logic that is deployed on them.

Therefore, Layer 2 may be at the forefront of Account Abstraction and contract wallet development before Account Abstraction is finally implemented on Ethereum mainnet.

Account Abstraction Segment Map

Account Abstraction will allow all accounts to have similar functionality as to contract accounts. Before the full implementation of consensus and underlying code, there are already several smart contract wallet products (Smart Contract Wallet-SCW) that realize the advantages of contract accounts and are offering users an alternative to EOA.

Here, by sorting out the smart contract wallets and related smart contract platform products, we can understand the current development of SCW, imagining the possible application scenarios of wallets after the complete realization of ERC-4337 or Account Abstraction.

The leading smart contract wallet, Safe, focuses on multi-signature to increase the security of the account. Argent, Unipass, Soulwallet and Candide mainly focus on keyless experience and social recovery function, with Unipass and Soulwallet additionally support for paying gas with ERC-20 tokens. Meanwhile, ZKSafe uses zero-knowledge proof technology to enable the possibility of user-defined passwords. A3S Protocol, on the other hand, abstracts the control of an account to an NFT, and by holding, transferring, or trading this NFT key, users can securely transfer, escrow, or trade the whole account, including multi assets, rights, and privilege within the account. Sentiment and Defisaver are in fact asset management products, but the automated operations and modular function have value of reference for the development of smart contract wallets.

The development history of Smart Contract Wallets can be roughly divided into several stages: 

at the beginning, To B products represented by Safe were used to solve the security problems of accounts and assets with multisig scheme. 

Subsequently, the prosperous development of DeFi promoted an increase in demand from ordinary users. Products like Argent, Pillar, Authereum then emerged, which focus on ease of use, lowering the barrier of users and optimizing the user experience. 

Now, the reduced likelihood of the direct reform of Account Abstraction on Ethereum and the high Ethereum gas fee, have created new opportunities for Layer 2. Layer2-based contract wallets such as Loopering, and Argent’s development focus has gradually shifted to zkSync and Straknet. Recent ERC-4337-based Soulwallet, Unipass, etc., have chosen to develop on Layer 2 first. 

In the future, with the popularization and compatibility of Account Abstraction and contract accounts, SCW will have more vitality and potential in more specific scenarios. For example, through controlling the account address by NFT, A3S protocol enables the financialization and temporary escrow of your wallet. The modular features of DeFi Saver made it possible for ordinary users to customize wallet functions and set up account logic.

Is Account Abstraction necessary?

Traditional EOA wallets like MetaMask have been criticized for terrible user experience, as users need to properly manage their own private keys or seed phrase and bear the risk of private key leakage. This also makes the first step into the Web3 world a rather high barrier.

Recently, many Web2 giants  are trying to expand to Web3. For example, Reddit launched Reddit NFT, which easily brought in millions of new users that are far beyond the existing user volume on OpenSea. In its guide to minting NFTs, Reddit did its best to lower the barrier of understanding for users, blurring complex concepts about addresses, private keys, NFTs, etc.

If a keyless contract wallet is used, the threshold can be fundamentally removed, which could provide a better option for large volume Web2 users to enter Web3. (

However, does a secure, private key-free experience must be achieved through an Account Abstraction or contract address?

Not really. 

The first option is the custodial wallet currently used by most exchanges. This means users entrust their private keys to the exchange, allowing the exchange to hold and manage the assets on behalf of them. Such custodial wallets can greatly reduce the user’s access threshold, but there are corresponding trust risks. Recently, FTX’s collapse has made users aware that assets held in custody can be misappropriated and seemingly trustworthy and powerful institutions can collapse. The safest option is to keep control of your assets completely in your own hands. Not your key, not your coins.

Another type of wallet uses a technology called Multi-Party Compution (MPC), which can also enable a secure, no-key user experience that some contract wallets aim to realize.

Generally, MPC mostly applys TSS (TSS- Threshold Signature Scheme), which divides the private key into many “fragments” and hand over the fragments to a decentralized network for computation and encryption. When a signature is needed, the fragments are stitched together to form a complete private key, avoiding the security problem of single point of failure by separating the control rights. This approach is somewhere between self-custodial and custodial, which can be referred to as a semi-custodial wallet.

TSS and Multisig may seem very similar. The difference is that each signer in the multisig wallet needs provide a complete private key signature to control contract account, while the verification of TSS only involves one private key, which is off-chain and not directly related to the smart contract.

Excellent MPC wallet products already exist today, such as Safeheron for To B and Bitizen for To C.

MPC can also implement keyless functions , and MPC seems to be cheaper and more compatible in use because it can be based on EOA. The technology of MPC is not only applicable to EVM chains, but also to other non-EVM accounts. So, a question must be asked, is it necessary to have a contract wallet based on keyless and other purposes, or Account Abstraction?

Such arguments do exist. In May of this year, Coinbase questioned the expensive gas of contract wallets and the possibility of users not finding enough trusted guardians in a promotional tweet for its own MPC wallet.

Vitalik also expressed his attitude in this Twitter thread:

Vitalik hopes to implement Account Abstraction at the protocol level, to achieve the goal of customizing account signature algorithm. ECDSA signature algorithm currently enforced by Ethereum is not the optimal choice, and MPC is only a partial security scheme based on ECDSA. The implementation of Account Abstraction, on the other hand, allows for the direct use of more advanced and secure signature algorithms (such as Quantum-resistant ones) according to the development of cryptograph.

Therefore, there is still a considerable necessity of Account Abstraction in the dimensions of more secure signature algorithms, better user experience, and more complete control of assets.

The ultimate form of account abstract wallet

After Account Abstraction is popularized and consensus is reached, the compatibility and affordability of contract accounts will be enhanced. Here, we also make optimistic predictions or expectations about the final state of such products, the functions they can provide and the application scenarios, which we believe may include the following functions and application scenarios.

……

1. No private key: users no longer need to manage the seed phrase or private key. Instead, they can choose a variety of user-friendly authentication schemes such as biometric verification and device verification
2. Account recovery: account recovery can be done through biometric and social verification
3. Gasless interaction: users can use ERC-20 tokens involved in the transaction for gas payment, directly designate a fixed account for payment without preparing ETH in advance, or pay no gas fee in case of transaction failure
4. Custom security schemes: users can choose better security schemes as cryptography evolves
5. Privacy: more effective on-chain privacy based on ring signatures and other approaches
6. Temporary account escrow: Users can set the requirements of administrator, duration, interaction, etc., to escrow the account to others, and automatically retrieve it after reaching the requirements or expiration
7. Account staking/trading: The account contains assets and accumulated on-chain credit history, which allows the account itself to be directly staked and traded in the on-chain marketplace
8. Restriction and division of account permissions: it is possible to grant partial account rights to others, such as the permission to only use NFT but not the tokens in the account
9. Customize workflow: Set automatic trigger points and processes. For example, if the balance of account A exceeds 1Eth by 0.5ETH, account B will automatically transfer the extra 0.5ETH to account B. When a token reaches a certain price, account B will automatically swap ETH for a token……
10. Transaction restrictions: The time and amount of the transaction can be set, and the transaction will be automatically invalid if the time or amount is exceeded
11. Whitelist/Blacklist: restrict interaction with blacklisted addresses, for example, assets sent from blacklisted addresses will be automatically returned. This is to circumvent the previous case where Tornado Cash “poisoned” other addresses by sending them small amount tokens after being sanctioned, making those addresses to be erroneously blocked by other protocol fronts.
12. Account classification management system: Users can use dedicated accounts in different scenarios to have a more reasonable account management system. For example, if a certain account as a gas account only stores ETH, all other account interactions would be paid by the gas account; a certain account only holds blue-chip NFT would not be easily accessed; a certain account as a dedicated account for games…
13. Modular code function: Users would be provided with different functional modules, which allows them to combine functional modules according to their needs without code knowledge, customizing the account to meet their habits and needs.

Conclusion

The implementation of Account Abstraction is worthy of everyone’s expectation. It will not only significantly increase the number of on-chain users, but also gives developers the high degree of freedom to solve the pain points of the current account system, giving birth to new applications and strategies.

However, implementing Account Abstraction at the code level is full of obstacles and uncertainties. Although a compromise proposal like EIP-4337 still has practical problems such as high gas fee and poor compatibility, it is not a bad choice to promote the concept and enhance consensus by vigorously promoting such proposal. With the popularization of the concept, Account Abstraction as well as contract wallets will be able to move from the niche to the mainstream, driving protocol compatibility from user demand to form a new account paradigm. Eventually, with a broad consensus, Ethereum will meet the conditions to directly change the underlying code to realize Account Abstraction.

With the final implementation of Account Abstraction, the high threshold and complex user experience of the current account system will no longer be taken for granted. This new account system will be more conducive to attracting new users and traffic for Web3 and stimulate the flourishing of the ecology, thus forming a positive cycle.