In-depth interpretation of "Account Abstraction": 7 years of route evolution and track map

Author: Block Irene

The self-custodial wallet address is the "account" of users in the on-chain world, but it is also a significant barrier preventing users from entering Web3. The improvement of accounts has been an ongoing experiment for over seven years. Until October 2022, Vitalik posted a thread on Twitter introducing EIP-4337 regarding account abstraction; in November, at various sharing sessions during Devcon 6 in Bogotá, the topic of Account Abstraction frequently appeared, sparking widespread and enthusiastic discussions about account abstraction, contract wallets, and 4337.

Account abstraction is of great significance in supporting users on-chain. "Not your keys, not your coins." Self-custody has been emphasized countless times by crypto veterans, yet only a small minority can achieve it. The high degree of freedom brought by account abstraction truly empowers ordinary users with a safer and more user-friendly decentralized experience, making self-custody accessible beyond just a few geeks. Although the collapse of FTX has cast a deep shadow over the future of the crypto world, it undoubtedly validates the necessity of decentralized applications and self-custody. With the implementation of account abstraction, the crypto industry will gain strength to liberate itself from the centralized bad actors and emperors, moving towards a higher dimension of decentralization and freedom.

Currently, EIP-4337 is seen by many as a guiding beacon for account abstraction, but the proposal remains an overly idealistic draft. For example, while it is ideal that transaction bundling can share gas costs, the verification process actually adds extra gas consumption; while it is ideal that contract wallets can adopt a unified architecture, in reality, it is a voluntarily adopted ERC proposal with weak effects; and while it is ideal that accounts using EIP-4337 can provide a better user experience, the awkward reality is that many dapps prohibit interactions with contract addresses…

The gentle approach of EIP-4337 represents a shift in the evolution of account abstraction, a compromise to various realities such as tight development resources and the significant impact of direct code changes. This compromise helps to disseminate the concept of account abstraction in advance, laying a consensus foundation for future abstraction, but it is not the endpoint of account abstraction. Ultimately, Ethereum still needs to truly implement account abstraction at the code level to reach the utopia we aspire to.

What is Account Abstraction ------ From Abacus to Smart Calculator

Before discussing the specific significance of account abstraction, we can first break it down to understand what "account" and "abstraction" mean separately.

In simple terms, Ethereum's foundation is built on two types of accounts: one that carries the user's wallet and another that carries the logic of smart contracts. Their functions are mostly incompatible: user wallets cannot perform logical judgments, while accounts that carry smart contracts cannot do anything outside of their logic. It is easy to see that such an account system is not optimized. The goal of account abstraction is to eliminate this incompatibility, to "generalize" their differences—removing specificity and seeking commonality.

Accounts

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

EOA is the type of account that ordinary users most frequently interact with, such as addresses in MetaMask wallets, which are controlled by users through private keys; while CA is a smart contract deployed on the Ethereum network, controlled by its code, without a private key. The similarities and differences between the two types of accounts are as follows:

Abstraction

Abstraction refers to extracting common patterns from specific problems and then using general solutions to address them. In other words, abstraction is a process of "generalization" that requires removing specificity and seeking commonality.

To understand abstraction with a more concrete example: toy cars and LEGO blocks. The structure of a toy car is specific and concrete, composed of a series of special components such as four wheels and a car body. If you want a toy truck or even a toy airplane, you need to buy new toys. In contrast, LEGO blocks are more abstract and generalized; they abstract toys into general building modules like cubes and spheres, allowing players to construct any toy shape using these blocks.

In the development of blockchain, the transition from Bitcoin to Ethereum is also a process of abstraction. The original purpose of the Bitcoin network was to achieve a peer-to-peer payment system with a specific and clear goal; Ethereum transformed the blockchain into a more generalized system, removing the specificity designed for peer-to-peer payments, extracting the commonality of blockchain technology to build a new network, and introducing the Ethereum Virtual Machine, which allows for the free construction of various protocols and applications on the blockchain, expanding the blockchain ecosystem.

Account Abstraction

Account abstraction refers to the generalization of Ethereum accounts, removing specificity. As mentioned earlier, Ethereum has two types of accounts, EOA and CA, each with its own characteristics. EOA is the more "top-level" account, where any transaction can only be initiated by EOA and requires ETH to pay for gas, and EOA can only use the ECDSA signature scheme implemented by a specific Secp256k1 elliptic curve algorithm. However, EOA does not directly support code logic. CA, which supports code logic, needs to be deployed and initiated by EOA.

All of this is a special forced design at the underlying level of Ethereum. The purpose of account abstraction is to hope to generalize Ethereum accounts, giving them greater freedom and expanding the possibilities of accounts. Generalizing the specificity of accounts can extract the following key aspects of account abstraction:

1. Cryptographic Abstraction: The signature verification of accounts is no longer limited to specific cryptographic algorithms; users can customize and choose different cryptographic algorithms as security mechanisms.
2. Account Functionality Abstraction: Supporting code logic to achieve custom functionalities.
3. Transaction Abstraction: Accounts can initiate transactions; gas payments are customizable.

In summary, for developers, account abstraction means greater freedom and more possibilities; for users, account abstraction can bring a better user experience from multiple dimensions, such as security, usability, and functionality. It can be said that before account abstraction, a user's wallet address was merely an abacus for performing calculations. After account abstraction is implemented, this abacus gains logical judgment capabilities, becoming a smart calculator with a chip.

The Development History of Account Abstraction ------ From Radical to Gentle to Transitional State

The discussion of abstraction began just months after the official launch of the Ethereum network in 2015, and new proposals continue to emerge as of October this year. We will chronologically outline the EIPs related to account abstraction to glimpse the different solutions and developments in account abstraction.

Here, the development of account abstraction proposals is divided into three stages:

Starting from the launch of Ethereum in 2015, EIP-86 first proposed account abstraction, initiating a five-year-long radical reform filled with idealism. Although these proposals for account abstraction that directly changed Ethereum's underlying code did not advance to the review stage, some ancillary proposals passed, laying a certain foundation for account abstraction. For example, EIP-1014 realized the ability to calculate contract addresses in advance without deploying contracts, and EIP-1271 implemented a signing scheme through contract accounts.

After the setbacks of radical reform, account abstraction began to seek a more gentle compromise. This stage no longer attempted to directly change Ethereum's underlying code but focused on introducing ERC standards for voluntary adoption by developers. EIP-4337 emerged, marking the beginning of the gentle advancement era of account abstraction. Recently, EIP-5189 proposed further optimization based on the ideas of 4337.

The ERC standard account abstraction proposal is a compromise to the slow changes, significant impacts, and poor compatibility of underlying code changes. This gentle approach helps to spread the concept of account abstraction, allowing it to transition from ideal discussions to practical realities, and to gradually improve and refine existing proposals through practice.

In the future, after gentle evolution and reaching a certain consensus, proposals like EIP-3074 and 5003 may be applicable to upgrade EOA to contract accounts. Ethereum will ultimately realize its initial ideals by making thorough changes to the underlying protocol, unifying accounts into a programmable and customizable type.

Past - Radical Reform

Since the first proposals were introduced, the solutions for account abstraction have consistently been violent reform proposals that directly change the consensus layer, continuously improving through various proposals in this stage.

EIP-101

Proposal Overview:

At the end of 2015, Ethereum founder Vitalik first proposed abstraction in EIP-101. In this proposal, Vitalik discussed the abstraction design of the account system in Serenity, simplifying accounts from four fields to just two fields: code and storage, with ETH stored in a token contract, retaining a list of addresses mapping user balances; transactions were simplified from eight fields to four fields, greatly abstracting accounts and transactions.

Advantages:

• Users can customize security modes and use other cryptographic algorithms to protect account security.
• ETH and other ERC20 tokens can be treated equally.
• Reduced indirectness in customizing account functionalities (such as multi-signature).

Problems and Current Status:

This proposal made drastic changes to the account system, leading to compatibility issues and security risks, and was temporarily shelved until after sharding, currently in a stagnant state.

EIP-86

Proposal Overview:

In 2017, Vitalik proposed EIP-86, abstracting transaction sources and signatures, again making radical changes to the underlying code. This proposal allowed users to create account contracts that could use any signature and nonce checking mechanism. In this scheme, there is an entry point contract through which anyone can send transactions, and the account contract receives data from the entry point and checks the signature, paying gas to miners if correct.

This proposal prepared for account abstraction, allowing users to customize signature algorithms without being forced to use Ethereum's hardcoded ECDSA and default nonce mechanism; gas is only paid by the contract account after verifying the signature's correctness.

Advantages:

• Multi-signature: Each signer does not need to hold ETH; transactions containing multi-signature information can be sent directly to the multi-signature account, which pays directly.
• Ring signature mixing: Ring signatures form a loop, making it impossible to determine the starting point. n users send an equal amount of tokens to the contract and then use ring signatures to withdraw the same amount of tokens. However, since gas needs to be prepared for token withdrawal, there is a risk of exposure at this stage. Therefore, through this proposal, gas can be paid directly from the withdrawn tokens, ensuring privacy in this scenario.
• Custom cryptography: Users can use quantum-safe signature methods like Lamport to secure their accounts.
• Custom non-cryptographic functionalities: For example, setting transaction expiration times.

Problems and Current Status:

• The new transaction type lacks a sender (all are entry points), breaking hash uniqueness. This is incompatible with protocols based on hash uniqueness.
• Insufficient necessity for gas payment; currently, proxy contracts can also achieve this, albeit at a slightly higher cost.
• Miners' mining strategies would be greatly affected.
• The new transaction type retains fields like nonce, gas price, and value, setting them to 0, lacking code elegance.
• Therefore, based on these issues, this proposal was ultimately postponed and is currently in a stagnant state.

EIP-859

Proposal Overview:

This proposal introduced a new transaction type and new opcodes, still mandatorily retaining the nonce field in transactions to maintain transaction hash uniqueness. It introduced the paygas opcode for gas payment, serving as a logical boundary for verifying and executing certain transactions.

Advantages:

• Custom signature mechanism.
• Maintains transaction hash uniqueness.
• Supports more complex verification scenarios and saves gas. For example, during a token ICO, if 10,000 transactions participate simultaneously, but only the first 5,000 transactions are supported when the token goes live, under existing logic, all 10,000 transactions would be packed on-chain. However, under this proposal, the contract can set the latter 5,000 transactions to not be included in the block, thus saving gas consumption and reducing invalid garbage transactions.

Problems and Current Status:

• Cannot use ERC-20 tokens to pay for gas.

In fact, this proposal has never formed a definitive draft and has remained in the discussion stage. It has been discussed multiple times in Ethereum developer meetings, but due to its immaturity and the already extensive content included in the upgrade at that time, this proposal has also been permanently shelved.

EIP-1014

Proposal Overview:

This proposal does not directly mention account abstraction, but it is closely related to the development of account abstraction. It introduces a method to pre-calculate contract addresses before actually deploying them, allowing assets to be sent to that address before the first transaction using the contract address, at which point the contract can be deployed.

Advantages:

• Cost savings: Users can calculate contract addresses in advance before paying gas to deploy contracts.
• Consistent multi-chain contract addresses: Contract addresses only exist after deployment, so they cannot achieve multi-chain consistency like EOAs; however, through the salt parameter in this opcode, contract addresses can also achieve multi-chain consistency.

Current Status:

This proposal was ultimately passed, laying an important foundation for the development of smart contract wallets.

EIP-1271

Proposal Overview:

This proposal provides a standard for verifying whether signatures representing contract accounts are valid. This allows contract accounts to perform signature verification like EOAs.

Advantages:

As an established ERC standard, developers can voluntarily adopt it. This lays a good foundation for the future promotion and popularization of contract accounts; as long as dapps are willing to support contract address signatures, they can simply add EIP-1271 code to their protocols.

Current Status:

This proposal has been finalized and is already in practical use, such as OpenSea supporting Authereum contract wallets for signature logins.

EIP-2938

Proposal Overview:

In 2020, Vitalik and several others proposed a more complete solution for account abstraction. Compared to previous proposals aiming to unify account types into one contract account, EIP-2938 retains the existing EOA and contract account types but accepts contracts as top-level accounts, allowing them to pay transaction gas and initiate transaction execution.

This proposal defines a new type of transaction: Account Abstraction transactions, and introduces two opcodes: Nonce and PAYGAS. This improvement still requires changes to Ethereum's underlying code.

EIP-2938 also outlines the implementation of this solution and describes specific application scenarios. Account abstraction is divided into two levels: first, achieving single-tenant account abstraction, and then expanding to multi-tenant account abstraction.

Advantages and Scenarios:

Single-tenant

• Customizable signature verification methods beyond ECDSA (e.g., BLS, post-quantum).
• Increased multi-signature verification, social recovery, and other contract wallet functionalities.
• Use ERC-20 tokens to pay for gas.

Multi-tenant

• Privacy: In scenarios like Tornado Cash that preserve privacy, accounts no longer need to prepare gas fees, thus avoiding privacy exposure.
• Gas savings: For example, when arbitrage opportunities arise, many arbitrageurs simultaneously initiate arbitrage transactions. If the first transaction succeeds, the others may fail but still get packed into the block. After account abstraction, arbitrageurs would not need to pay gas for failed arbitrage actions, reducing the number of garbage transactions on-chain.

Problems and Current Status:

Although this proposal is more detailed, the technical solutions for the multi-tenant phase have not yet matured. Moreover, this proposal is considered inefficient both technically and economically, so it has not entered the final stage.

Thus, in the first phase of account abstraction, proposals that radically and violently changed Ethereum's underlying protocol have almost all been shelved. The priority, necessity, economy, and compatibility of account abstraction still need further optimization.

Current - Gentle Changes

Ethereum developers are focused on Ethereum's merge and sharding, making it difficult to advance proposals that directly change the underlying protocol. Developers, represented by Vitalik, have had to compromise and propose relatively gentler, indirect alternatives.

EIP-4337

Proposal Overview:

This proposal is the first account abstraction proposal that does not require changes to Ethereum's underlying code. In ERC-4337, a UserOperation object is introduced. Users send the UserOperation object to a separate memory pool. Bundlers package these objects into a transaction, calling an Entry Point contract, and then the transaction is included in a block.

Advantages:

• Customizable signature algorithms: Supports signature algorithms beyond ECDSA.
• Functional customization: Through contract code, functionalities such as gas payment and social recovery can be implemented.

Problems and Current Status:

• Non-upgradable: Users need to transfer assets and activities to a new address to support this standard.
• Higher gas costs: The introduced user operation incurs higher gas consumption.
• Compatibility issues: Some existing dapps or protocols may prohibit interactions with contract accounts.

Despite numerous practical issues, Vitalik hopes to strongly support ERC-4337 in the short term, researching better solutions during the practical process and continuously improving it. After achieving large-scale promotion, forming consensus and scale effects will facilitate existing applications to make changes, supporting interactions with contract accounts and the ERC-1271 contract signature standard. Currently, EIP-4337 is still in Draft status, awaiting further advancement to the next stage.

EIP-5189

Proposal Overview:

This proposal is an ERC proposal that transforms the transaction packaging process, also not requiring changes to the underlying code. It introduces an endorser role, where contract wallet developers define the endorser contract to help confirm the quality of submitted meta-transactions, assisting bundlers in determining whether the transaction should remain in the mempool. This proposal shifts the risks brought by account abstraction to wallet developers, who are expected to code and deploy endorser contracts.

Advantages:

• Lowers the threshold and risk for bundlers to filter meta-transactions.

Problems and Current Status:

This proposal has just formed a draft and is still in the early stages.

At this stage, the account abstraction proposals have transitioned from early violent revolutions to peaceful evolution. Although the impact is weaker, it is easier to implement, promoting the development of smart contract wallets and attracting and accumulating a certain user base.

Future - Mandatory Implementation

Vitalik mentioned that he hopes to continuously introduce new proposals to address the shortcomings of ERC-4337 during its promotion, such as upgrading EOA to contract addresses and optimizing gas fees. The possible path will transition from voluntary adoption to widespread popularity, ultimately achieving the goal of unifying Ethereum account types into one.

EIP-3074

Proposal Overview:

EIP-3074 was proposed even before EIP-4337. It does not introduce new transaction types but introduces two opcodes, AUTH and AUTHCALL, allowing the delegation of EOA control to smart contracts, enabling all EOAs to have the functionalities of smart contract wallets.

Advantages:

• Gas payment by another account: Gas fees can be paid by another account, allowing addresses without ETH to send tokens.
• Batch transactions: Sending multiple transactions through a single call reduces transaction costs.

Problems and Current Status:

This proposal requires changes to Ethereum's code, planned for implementation during the Shanghai upgrade phase. Currently, due to various uncertainties regarding security, it is still under review.

EIP-5003

Proposal Overview:

This proposal is an extension of EIP-3074, introducing a new opcode, AUTHUSURP, which allows authorized addresses to set the code of the authorized address, enabling the upgrade of EOA to contract accounts.

Advantages:

• Achieves the upgrade of EOA to contract accounts.

Current Status:

This proposal is based on EIP-3074 and is still in draft status, with progress likely influenced by the status of EIP-3074.

Layer 2?

From the above EIP development history, it is evident that account abstraction aims to solve the legacy issues of Ethereum's dual account system. However, proposals that directly change the protocol, while more straightforward, require more developers, and the urgency of account abstraction is not high, leading to many obstacles.

In contrast, proposals that directly change the code may be more suitable for newly emerging layer 2 public chains. For example, Starknet is a chain that natively supports account abstraction, with only one unified account type that is programmable and can send transactions, receive assets, etc. The recent launch of the zkSync 2.0 mainnet in October also introduced new account abstraction functionalities, allowing accounts to initiate transactions and execute code logic deployed on them.

Moreover, Layer 2 often has lower gas fees compared to the Ethereum mainnet, providing a better user experience and lower costs for deploying smart contract accounts that require gas payments.

Therefore, before account abstraction is ultimately realized on the Ethereum mainnet, Layer 2 may be at the forefront of the development of account abstraction and contract wallets.

Account Abstraction Landscape Map

Account abstraction means that future accounts will possess functionalities similar to contract accounts. Before account abstraction is fully realized in consensus and underlying code, several smart contract wallet products (Smart Contract Wallet - SCW) have already recognized the advantages of contract accounts and are providing users with options beyond the EOA account system.

Through the analysis of smart contract wallets and related smart contract platforms, we can understand the current development direction of SCWs and envision possible application scenarios for wallets after the complete realization of ERC-4337 or account abstraction.

Comparison of Account Abstraction Concept Projects

From the development history of SCWs, it can be roughly divided into several stages: initially represented by Safe as a B2B product, using a multi-signature model to solve account and asset security issues; subsequently, the prosperous development of DeFi increased the demand from ordinary users, leading to the emergence of products like Argent, Pillar, and Authereum, which focus on usability, lowering user entry barriers, and optimizing user experience.

Now, as the possibility of direct violent reform of account abstraction in Ethereum decreases and the high gas fees of the Ethereum mainnet create new opportunities for Layer 2, contract wallets based on Layer 2, such as Loopring, have emerged in response. The development focus of Argent is gradually shifting towards zkSync and Starknet, and recent projects based on ERC-4337, such as Soulwallet and Unipass, have also chosen to develop on Layer 2 first.

In the future, with the popularization and compatibility of account abstraction and contract accounts, there will be more vitality and potential for contract wallets in more specific scenarios. For example, the A3S protocol can tokenize accounts as NFTs, enabling the financialization of accounts and temporary custody of accounts; DeFi Saver's modular functionality can provide ordinary users with customizable contract wallet functionalities and the possibility of setting account logic.

Is Account Abstraction Necessary?

Traditional EOA wallets like MetaMask have long been criticized for poor user experience, requiring users to manage private keys or mnemonic phrases carefully, bearing the risk of private key leakage. This creates a high barrier for entering the Web3 world from the very first step.

Recently, many Web2 companies with large user bases and traffic have been trying to expand into Web3. For example, Reddit issued Reddit NFTs to users, effortlessly bringing in a new user base far exceeding that of OpenSea. In guiding the NFT minting process, Reddit has done its utmost to lower the understanding barrier for users, blurring complex concepts related to addresses, private keys, NFTs, etc.

If a keyless contract wallet is adopted, it can fundamentally eliminate the barrier, providing a better channel for a large number of Web2 users to enter Web3.

However, must security and keyless experiences be achieved through account abstraction or contract addresses?

Not necessarily.

The first option is the custodial wallets currently used by most exchanges, where private keys are not held by users themselves but are managed by exchanges on behalf of users, preventing users from having full control over their funds. Such custodial wallets can significantly lower user barriers but also carry corresponding trust risks. The recent sudden collapse of FTX has made users realize that custodial assets may be misappropriated, and seemingly powerful institutions can also collapse. The safest choice is to have complete control over one's assets. Not your key, not your coins.

Another type of wallet employs a technology called Multi-Party Computation (MPC), which can also achieve the security and keyless user experience that some contract wallets aim for.

Generally, MPC mostly uses a method called Threshold Signature Scheme (TSS), which essentially fragments the private key and distributes the fragments to a decentralized network for computation and encryption. When a private key signature is needed, the fragments are assembled to form the complete private key, avoiding single-point failure security issues through decentralized control. This method lies between self-custody and custodial wallets and can be referred to as semi-custodial wallets.

This logic bears some similarity to multi-signature wallets, but the difference is that each signer in a multi-signature wallet provides complete private key signature control over the contract account; in contrast, the TSS verification process only involves one private key and is off-chain, with no direct connection to smart contracts.

Currently, there are many excellent MPC wallet products, such as Safeheron for B2B and Bitizen for B2C.

MPC can also achieve keyless functionalities, and it seems to be cheaper and more compatible than contract wallets based on keyless objectives. MPC technology is not limited to EVM chains; other non-EVM accounts can also apply. So, is a contract wallet based on keyless objectives or account abstraction truly necessary?

Such debates do exist. In May of this year, Coinbase questioned the high gas costs of contract wallets and the potential difficulty users may have in finding trustworthy guardians in a promotional tweet for its MPC wallet.

Vitalik also expressed his stance in response to this tweet:

It can be seen that Vitalik hopes to achieve the goal of customizable account signature algorithms at the protocol level. The currently enforced ECDSA signature algorithm on Ethereum is not the optimal choice, and MPC is merely a localized security solution based on ECDSA. After achieving account abstraction, it would be possible to directly use more advanced and secure signature algorithms (such as quantum-resistant ones) based on technological advancements.

Therefore, account abstraction still holds considerable necessity in terms of more secure signature algorithms, superior user experiences, and complete asset control.

The Ultimate Form of Account Abstraction Wallets

Once account abstraction is popularized and consensus is reached, the compatibility and economy of contract accounts will be enhanced. Here, we optimistically predict or anticipate the ultimate state of such products, including the functionalities and applicable scenarios they may provide:

1. Keyless: Users no longer need to manage mnemonic phrases or private keys; they can use various verification methods such as biometric verification or device verification.
2. Account Recovery: Accounts can be recovered through biometric identification or social verification.
3. Gas-free Interaction: Users can use ERC-20 tokens involved in transactions to pay for gas or directly specify a fixed account for payment, without needing to prepare ETH in advance for gas; or they may not need to pay gas fees in case of transaction failures.
4. Customizable Security Mechanisms: Users can choose better security mechanisms as cryptography evolves.
5. Privacy: More effective on-chain privacy achieved through methods like ring signatures.
6. Temporary Custody of Accounts: Users can set management parties, durations, and interaction requirements, allowing accounts to be managed by others and automatically reclaimed after the time or requirements are met.
7. Account Collateral/Trading: Accounts containing assets and accumulated on-chain credit history can be directly collateralized or traded in on-chain markets.
8. Account Permission Restrictions and Segmentation: Users can grant others partial account permissions, such as allowing access to NFTs in the account but not tokens.
9. Customizable Workflows: Setting automatic triggers and processes. For example, when Account A's balance exceeds 5 ETH, it automatically transfers the excess 0.5 ETH to Account B, and when Account B's token reaches a certain price, it automatically swaps ETH for that token…
10. Transaction Restrictions: Users can set transaction times and limits, preventing transactions from succeeding if they exceed the time or limit.
11. Whitelists/Blacklists: Restrict interactions with blacklisted addresses, such as automatically returning assets sent from blacklisted addresses to avoid situations where addresses are erroneously banned by other protocols after being "poisoned" by Tornado Cash sanctions.
12. Account Classification Management System: Users can use dedicated accounts in different scenarios, creating a more rational account management system. For example, an account may serve solely as a gas account holding only ETH, with all other accounts' interactions paid for by the gas account; another account may hold blue-chip NFTs and not be easily accessed; yet another account may be designated for gaming.
13. Modular Code Functionality: Providing users with different functional modules, allowing users to customize accounts according to their habits and needs without needing to understand code.

……

Conclusion:

The realization of account abstraction is worth everyone's anticipation. This will not only help significantly increase the number of on-chain users but also provide developers with a high degree of freedom to address the pain points of the current account system, leading to the emergence of new applications, gameplay, and imaginative spaces.

Implementing account abstraction at the code level is fraught with obstacles and uncertainties. Although compromise solutions like EIP-4337 still face practical issues such as high gas costs and poor compatibility, vigorously promoting EIP-4337 is also a choice for concept dissemination and enhancing consensus. As the concept becomes widespread, account abstraction and contract wallets can transition from niche to mainstream, driven by user demand for protocol compatibility, forming a new account paradigm. Ultimately, under broad consensus, Ethereum will have the conditions to directly change its underlying code to achieve account abstraction.

Once account abstraction is fully realized, the current high barriers and complex user experiences of the account system will no longer be taken for granted. This new account system will be more conducive to attracting new users and traffic to Web3, stimulating the vigorous development of the ecosystem, thereby forming a positive cycle.