Account abstraction is not limited to EIP-4337, nor is it limited to no private keys and social recovery functions. This article sorts out the development history and future direction of account abstraction from the EIP proposal, and imagines the infinite possibilities of account abstraction from the track map...
It will take some time for the account abstraction to be implemented, but it will be the only way to lower the threshold for new users in the future and improve the user experience.
The wallet address that needs to be self-hosted is the user's " account " in the chain world, but it is also a major obstacle preventing users from entering Web3 . For the improvement of the account, it is an experiment that has lasted for more than 7 years. Until October 2022 , Vitalik tweeted a thread introducing EIP-4337 about account abstraction; in the various sharing sessions of devcon 6 held in Bogotá in November, Account Abstraction frequently appeared, triggering a discussion about account abstraction. Extensive lively discussion of abstractions, contract wallets, 4337 .
Account abstraction is of great significance to support users on-chain. "Not your keys, not your coins." I don't know how many times self-hosting has been emphasized by the encryption veterans, but there are still very few people who can do it. The extremely high degree of freedom brought by account abstraction can truly give ordinary users a more secure and easy-to-use decentralized experience. Self-hosting will no longer be a feat of a few geeks. Although the explosion of FTX has cast a deep shadow on the future of the encrypted world, it has undoubtedly verified the necessity of decentralized applications and self-hosting. With the implementation of account abstraction, the encryption industry will be more capable of freeing itself from centralized villains and emperors, and moving towards a higher dimension of decentralization and freedom.
At present, EIP-4337 is regarded by many people as the direction indicator of account abstraction, but the proposal is still only an ideal draft. For example, ideally , transaction packaging can share the gas , but in fact, the verification process increases the gas consumption; Accounts using EIP-4337 can bring a better user experience, but it is actually an embarrassing situation where many dapps prohibit contract address interaction ...
A moderate solution such as EIP-4337 is a change in the evolution of account abstraction, and it is a compromise for various realities such as the shortage of development resources and the excessive impact of direct code changes. This compromise solution helps to spread and promote the concept of account abstraction in advance, laying a consensus foundation for future abstraction, but it is not the end of account abstraction. In the end, Ethereum still needs to truly implement account abstraction at the code layer to reach the utopia we yearn for.
What is Account Abstraction - From Abacus to Smart Calculator
Before discussing the specific meaning of account abstraction, we can disassemble it first to understand what is "account" and "abstract".
To put it simply, the foundation of Ethereum is based on two types of accounts, one carries the user's wallet, and the other carries the logic of the smart contract. Most of their functions are incompatible: the user's wallet cannot make logical judgments, and the account carrying the smart contract cannot do anything other than logic. It is conceivable that such an account system is not optimized. The goal of account abstraction is to eliminate this incompatibility and " generalize " their differences— remove specificity and find commonality.
Account Accounts
Ethereum has two basic account types: Externally Owned Accounts ( EOA ) and contract accounts ( Contract Account - CA ).
EOA is the type of account most frequently contacted by ordinary users, such as the address in the MetaMask wallet, which is controlled by the user through the private key; while CA is a smart contract deployed in the Ethereum network, which is controlled by its code and has no private key. key. The similarities and differences between the two types of accounts are as follows:
abstract
Abstraction refers to extracting common patterns from specific problems, and then using general solutions to deal with them. In other words, abstraction is a process of "generalization", which requires removing specificity and finding commonality.
Let’s understand abstraction with a more realistic and concrete example: toy cars and Lego blocks. The structure of a small car toy is special and specific, consisting of a series of special parts such as four wheels and a body. If you want to have a small truck toy or even an airplane toy, you need to buy a new toy. Lego building blocks are more abstract and more general. He abstracts toys into general building block modules such as cubes and spheres. Players can use these building blocks to build any toy shape.
In the development of blockchain, from Bitcoin to Ethereum is actually an abstraction process. The original purpose of the Bitcoin network was to realize a peer-to-peer payment system with a specific purpose; while Ethereum turned the blockchain into a more general system, removing the specificity for peer-to-peer payment and extracting the area The commonality of block chain technology builds a new network. With the Ethereum virtual machine, various protocols and applications can be freely constructed on the block chain, expanding the block chain ecology.
account abstraction
Account abstraction refers to the generalization of Ethereum accounts and the removal of specificity. We also mentioned in the previous article that Ethereum has two types of accounts, EOA and CA each have their own characteristics, among which EOA is a more " top-level " account, any transaction can only rely on EOA to initiate and pay ETH as gas , and EOA can only use the ECDSA signature scheme, which is implemented by a specific Secp 256 k 1 elliptic encryption algorithm. But EOA does not directly support code logic. The CA that supports code logic needs to be deployed and initiated transactions by EOA .
All of this is a special mandatory design of the bottom layer of Ethereum. The purpose of account abstraction is to generalize Ethereum accounts so that they have a higher degree of freedom and expand the possibility of accounts. By generalizing the specificity of the account, the following abstract keys of the account can be extracted:
Cryptographic abstraction: that is, account signature verification is no longer limited to a specific encryption algorithm, and users can customize and select different encryption algorithms as a security mechanism
Account function abstraction: support code logic and realize custom functions
Transaction abstraction: accounts can initiate transactions; gas payment customization
All in all, for developers, account abstraction means higher degrees of freedom and more possibilities; for users, account abstraction can bring better experience from multiple dimensions, such as security, ease of use Usability, functionality. It can be said that before the account is abstracted, the user's wallet address is just an abacus that can calculate addition and subtraction. After the account abstraction is realized, the abacus has the function of logical judgment and becomes a smart calculator with a chip.
The development process of account abstraction - from radical to moderate to transition to the final state
Discussions on abstraction began a few months after the official release of the Ethereum network in 2015 , and new proposals were still put forward until October this year. We sort out the EIPs related to account abstraction in chronological order to get a glimpse of different solutions and developments of account abstraction.
Here, the development of the account abstraction scheme is divided into three stages:
Since the launch of Ethereum in 2015 , EIP-86 proposed account abstraction for the first time, and started a radical reform full of idealism for 5 years. Although these account abstraction proposals that directly changed the underlying code of Ethereum failed to advance to the review stage, some subsidiary proposals passed, laying a certain foundation for account abstraction. For example, EIP-1014 realizes that the contract address can be calculated in advance without deploying the contract, and EIP-1271 realizes the scheme of signing through the contract account.
Frustrated from radical reforms, account abstraction began to look for a more modest compromise. At this stage, it is no longer an attempt to directly change the underlying code of Ethereum, but mainly to launch the ERC standard, which is voluntarily adopted by developers. The birth of EIP-4337 opened the era of gentle promotion of account abstraction. Recently, EIP-5189 proposed a further optimization scheme based on the idea of 4337 .
The account abstraction scheme of the ERC standard is a compromise for the slow change of the underlying code, large impact, and poor compatibility. Such a gentle approach is conducive to the dissemination of the concept of account abstraction, so that account abstraction can first be implemented from ideal discussions to practical reality, and step by step in practice, and continuously improve and improve the shortcomings of existing solutions.
In the future, after a moderate evolution and reaching a certain consensus, proposals such as EIP-3074 and 5003 may be applied to upgrade EOA to a contract account. Ethereum will finally realize the original ideal, make radical changes in the underlying protocol, and unify accounts into a programmable and customizable account.
Past - Radical Reform
Since the relevant proposals were first proposed, the solution to account abstraction has always been a violent reform plan that directly changes the consensus layer, and has been continuously improved in proposals at this stage.
EIP-101
Program introduction:
At the end of 2015 , Ethereum founder Vitalik first proposed abstraction in EIP-101 . In this proposal, Vitalik discussed the abstract design of the account system in Serenity , simplifying the account from 4 fields to only two fields of code and storage . ETH is stored in a token contract, and the address mapping the user balance is reserved. List; transactions are simplified from 8 fields to 4 fields, which greatly abstracts accounts and transactions.
Advantage:
User-defined security mode, using other encryption algorithms to protect account security
ETH and other ERC 20 tokens can be treated equally
Reduced indirection of custom account features such as multi-sig.
Problems and status quo:
This proposal has made drastic changes to the account system, and there are compatibility issues and security risks. Therefore, it was temporarily put on hold at that time after sharding, and it is currently in a stagnant state.
EIP-86
Program introduction:
In 2017 , Vitalik proposed EIP-86 to abstract transaction sources and signatures, and make radical changes to the underlying code again. This proposal allows users to create account contracts that can use any signature and nonce checking mechanism. In this scheme, there is an entry point contract. Anyone can send transactions through this contract. The account contract receives the data from the entry point and checks the signature. If it is correct, it will pay the miners for gas . This solution is a preparation for account abstraction, allowing users to customize the signature algorithm, no longer mandatory to use Ethereum's hard-coded ECDSA and default nonce mechanism; at the same time, the gas is paid by the contract account after the signature is verified correctly.
Advantage:
Multi-signature: Every multi-signature person does not need to own ETH , the transaction containing multi-signature information can be sent directly to the multi-signature account, and the multi-signature account is directly paid by the multi-signature account
Ring signature mixed currency: Ring signature refers to the connection of signatures to form a ring, so the starting point cannot be judged. n users send the same number of tokens to the contract, and then use the ring signature method to withdraw the same number of tokens. However, due to the need to prepare gas for withdrawing tokens, there is an exposure risk at this stage. Therefore, through this proposal, gas can be paid directly from the extracted tokens, which ensures the privacy in this scenario.
Custom cryptography: users can use quantum-safe signature methods such as Lamport to ensure account security
Customize non-cryptographic functions: such as setting transaction expiration time, etc.
Problems and status quo:
The new transaction type has no transaction sender (all entry points ), which destroys the uniqueness of the hash. Incompatible with protocol operations based on hash uniqueness
The necessity of gas -free payment is insufficient, and it can also be realized through the agency contract at present, but the cost will be slightly higher
Miners' mining strategies will be greatly affected
The new transaction type retains nonce , gasprice , value and other fields and is set to 0 , which lacks code elegance
Therefore, based on these problems, the proposal was finally postponed and is currently stagnant .
EIP-859
Program introduction:
This proposal introduces a new transaction type and a new opcode, and the nonce field is still mandatory in the transaction to maintain the uniqueness of the transaction hash. Introduce the paygas operation code for gas payment, and serve as a logical boundary between verifying part of the transaction and executing part of the transaction.
Advantage:
Customized signature scheme
Maintains transaction hash uniqueness
It can support more complex verification scenarios and save gas . For example, during the token ICO , there are 10,000 transactions participating at the same time, but the token is only online to support the first 5,000 transactions. According to the existing logic, all 10,000 transactions will be packaged. Under this proposal, the contract can be set to not include the last 5,000 transactions in the blockchain, thereby saving gas consumption and reducing invalid spam transactions.
Problems and status quo:
ERC-20 tokens cannot be used to pay for gas
Cannot use ERC 20s to pay for gas
In fact, the proposal has not yet formed a definitive draft and is only in the discussion stage. This proposal was also discussed at several Ethereum developer meetings, but because it was not mature enough, and the upgrade contained a lot of content at that time, the proposal was also permanently shelved.
EIP-1014
Program introduction:
The proposal does not directly mention account abstraction, but it is closely related to the development of account abstraction. This proposal introduces a method to pre-calculate the contract address before actually deploying the contract address, and send assets to the address before deploying the contract address. When using the contract address for the first transaction, then proceed deploy.
Advantage:
Cost saving: users can calculate the contract address in advance before paying gas to deploy the contract
Multi-chain contract address consistency: the contract address needs to be deployed before it exists, so unlike EOA , it can directly achieve multi-chain consistency; through the salt parameter in the opcode, the contract address can also achieve multi-chain consistency
status quo:
The proposal was finally passed, laying an important foundation for the development of smart contract wallets.
EIP-1271
Program introduction:
The proposal provides a set of criteria for verifying that signatures representing contract accounts are valid. This enables contract accounts to perform signature verification like EOA .
Advantage:
This proposal is an established ERC standard that developers can adopt voluntarily. This has laid a good foundation for the promotion and popularization of future contract accounts. As long as the dapp is willing to support contract address signature, simply add the code of EIP-1271 to the agreement.
status quo:
The proposal has been finally passed, and there are already practical applications, such as opensea supporting authereum contract wallet for signature login.
EIP-2938
Program introduction:
In 2020 , Vitalik jointly proposed a more complete account abstraction solution. Compared with the previous account abstraction goal, which unified the account type into one type of contract account, the EIP-2938 proposal still maintains the existing two types of EOA and contract account, but accepts the contract as the top-level account so that it can pay transaction gas and initiate Transaction execution process.
This proposal defines a new type of transaction : Account Abstraction transactions , and introduces two opcodes : Nonce and PAYGAS . This improvement still required changes to Ethereum's underlying code.
EIP-2938 also plans the implementation of the solution and elaborates on specific application scenarios. Account abstraction is divided into two levels: the first is to implement single-tenant account abstraction, and then extend to multi-tenant account abstraction.
Advantages and scenarios:
Single-tenant Single-tenant
Customize the use of signature verification methods other than ECDSA (such as BLS , post-quantum )
Add contract wallet functions such as multi-signature verification and social recovery
Gas is paid using ERC-20 tokens.
Multi-tenant Multi-tenant
Privacy: In privacy-preserving scenarios such as tornado cash , accounts no longer need to prepare gas fees to expose privacy.
Save gas : For example, when arbitrage opportunities arise, a large number of arbitrageurs initiate arbitrage transactions at the same time, and after the first one succeeds, other arbitrage transactions fail but are still packaged in the block. After the account is abstracted, arbitrageurs no longer need to pay for the failed Paying gas for arbitrage reduces the number of spam transactions on the chain.
Problems and current situation:
Although the plan is more detailed, the technical plan for the multi-tenant stage is still unformed. And the solution was not considered to be technically and economically efficient enough, so it did not enter the final stage.
So far, in the first stage of account abstraction, plans to radically and violently change the underlying protocol of Ethereum have almost been shelved. The priority, necessity, economy, and compatibility of account abstraction still need to be further optimized.
Now - Gentle Change
Ethereum developers are focused on the merger and sharding of Ethereum, and it is difficult to advance the plan of directly changing the underlying protocol. The developers represented by Vitalik have to compromise and propose a relatively milder and indirect alternative.
EIP 4337
Program introduction:
This proposal is the first account abstraction proposal that does not require changes to the underlying code of Ethereum. In ERC-4337 , a UserOperation object was introduced. Users send UserOperation objects to a separate memory pool. Bundler packages these objects into a transaction, calls an Entry Point contract, and then the transaction is included in a block.
Advantage:
Custom signature algorithm: support signature algorithms other than ECDSA
Function customization: functions such as gas payment and social recovery can be realized through the contract code
Problems and current situation:
Not upgradeable: users need to transfer assets and activities to new addresses to support the standard
Gas overhead is higher: the introduced user operation will bring higher gas consumption
Compatibility issues: Some existing dapps or protocols may prohibit interaction with contract accounts
Although there are many practical problems, Vitalik hopes to strongly support ERC-4337 in the short term, research better solutions in the process of practice, and continue to improve and improve them. After achieving large-scale promotion, the formation of consensus and scale effect will help to promote changes in existing applications, support the interaction of contract accounts and support the contract signature standard of ERC-1271 . At present, EIP 4337 is still in Draft status, waiting to continue to advance to the next stage.
EIP-5189
Program introduction:
This proposal is an ERC proposal to transform the transaction packaging process, and also does not require changes to the underlying code. The proposal introduces the role of an endorser . The developer of the contract wallet defines the endorser contract to help confirm the quality of the submitted meta-transaction and help the bundler determine whether the transaction should stay in the mempool . This proposal transfers the risk of abstracting the account into a bundler to the wallet developer, and expects the developer to be responsible for coding and deploying the endorser contract.
Advantage:
Reduced the threshold and risk for bundler to screen meta-transactions
Problems and current situation:
The proposal is currently in draft form and is still in its early stages.
At this stage, the scheme of account abstraction has transformed from an early violent revolution to a peaceful evolution. Although the strength is weaker, it is easier to implement, which can promote the development of smart contract wallets and attract and accumulate certain user groups.
Future - Mandatory
Vitalik mentioned that he hopes that in the process of implementing ERC-4337 , he will continue to introduce new proposals to improve the shortcomings of ERC-4337 , such as upgrading EOA to contract addresses and optimizing gas costs. The possible path will be from voluntary adoption to widespread popularization, and then to the final implementation of mandatory conversion to achieve the ultimate goal of unifying the Ethereum account types into one.
EIP-3074
Program introduction:
The proposal of EIP 3074 was actually earlier than EIP 4337. It did not introduce a new transaction type, but introduced two operation codes, AUTH and AUTHCALL , allowing EOA control to be delegated to smart contracts, which allows all EOAs to have smart contract wallets function.
Advantage:
Paying gas on behalf of others: the gas fee can be paid by another account, and the address that does not hold ETH can also send tokens.
Batch transactions: send multiple transactions with a single call, reducing transaction fees
Problems and current situation:
The proposal requires changes to the Ethereum code, and the plan is to implement it in the Shanghai upgrade phase. Due to various security uncertainties, it is still under review in the review phase.
EIP-5003
Program introduction:
This proposal is an extension proposal to EIP 3074 , and introduces a new operation code AUTHUSURP , which allows the authorized address to set the code of the authorized address, so as to realize the upgrade of EOA to the contract account.
Advantage:
Realize the upgrade of EOA to contract account
status quo:
This proposal is based on EIP-3074 and is still in the draft stage, and the progress should be affected by the progress of EIP-3074 .
Layer 2 ?
From the above EIP development history, it can be seen that account abstraction is to solve the legacy problems of the Ethereum dual-account system. Sex is not yet high, so encountered a lot of obstacles. In comparison, the solution of directly changing the code may be more suitable for the new layer 2 public chain whose ecology has just started. For example, Starknet is a chain that natively supports account abstraction. It has only one unified account type, which can be programmed, and can send transactions, send and receive assets, and so on. In October , the zksync 2.0 mainnet was launched, and a new function of account abstraction was also introduced. Accounts can initiate transactions and execute code logic deployed on them.
In addition, compared with the Ethereum mainnet, Layer 2 often has lower gas fees. For smart contract accounts that need to pay gas for deployment, the user experience will be better and the cost will be lower.
Therefore, before account abstraction is finally implemented on the Ethereum mainnet, Layer 2 may be the forefront of account abstraction and contract wallet development.
Account abstract track map
Account abstraction means that future accounts will have similar functions of contract accounts. Before account abstraction is fully realized in the consensus and underlying code, there are already some smart contract wallet products ( Smart Contract Wallet-SCW ), seeing the advantages of contract accounts, and are providing users with options other than the EOA account system.
Here, by sorting out the products of smart contract wallets and related smart contract platforms, we can understand the current development direction of SCW , and use this to imagine the possible application scenarios of wallets after ERC-4337 or account abstraction is fully realized.
Account abstract concept project comparison
From the perspective of the development history of SCW , it can be roughly divided into several stages: at first, the to B product represented by Safe used the multi-signature model to solve the security problems of accounts and assets; subsequently, the prosperity and development of defi promoted the development of ordinary users With the increase of demand, products such as Argent , Pillar , and Authereum that focus on ease of use, lower the threshold for users to use, and optimize the user experience will appear ; now, the possibility of account abstraction in Ethereum is less likely to be directly violently reformed, and the high cost of the Ethereum mainnet The gas fee provides new opportunities for Layer 2. Contract wallets based on layer 2 such as Loopering have also emerged in response to the situation. The development focus of Argent has gradually shifted to Zksync and Straknet . Recently, soulwallet and unipass based on ERC-4337 have also emerged. They all choose to develop on layer 2 first; in the future, with the popularity and compatibility of account abstraction and contract accounts, in more specific scenarios, contract wallets will have more vitality and potential. For example, the A 3 S agreement will account NFT The financialization of the account and the temporary escrow of the account can be realized; the modular function of defisaver can give ordinary users the possibility of customizing the function of the contract wallet and setting the logic of the account.
Is account abstraction necessary?
Traditional EOA wallets like MetaMask have been criticized for poor user experience. Users need to properly manage their private keys or mnemonic words and bear the risk of private key leakage. This also makes the first step into the web3 world has a very high threshold.
Recently, many web2 companies with a large number of users and traffic are trying to expand to web3 . For example, Reddit issued reddit NFT to users, which easily brought in new users far exceeding the existing user volume of Opensea . In guiding the NFT casting process, reddit has tried its best to lower the threshold for users to understand, blurring complex concepts such as addresses, private keys, and NFTs .
If a contract wallet without a private key is used, the threshold can be eliminated fundamentally, and a better channel for a large number of web2 users to enter web3 will be provided.
However, must the security and private key-free experience be realized through account abstraction or contract address?
not.
The first type of option is the custodial wallet currently used by most exchanges, that is, the private key is not in the hands of the user, but the exchange holds and manages the assets on behalf of the user, and the user cannot fully control their own funds. Such a managed wallet can greatly reduce the threshold for users, but there are also corresponding trust risks. The recent sudden explosion of FTX has made users realize that the assets under custody may be misappropriated, and seemingly powerful institutions may also collapse. The safest option is to fully control the assets in your own hands. Not your key, not your coins .
Another type of wallet applies a technology called Multi-Party Computation (MPC ), which can also achieve the security and private key-free user experience that some contract wallets want to achieve.
Generally speaking, MPC mostly uses the threshold signature ( TSS-Threshold Signature Scheme ) method, which simply means fragmenting the private key and submitting the fragments to a decentralized network for calculation and encryption. When private key signature is required, the fragments are spliced together to form a complete private key, which avoids the security problem of a single point of failure by decentralizing control rights. This method is between self-custody and custody, and can be called a semi-custodial wallet.
This logic is similar to the multi-signature wallet, but the difference is that each multi-signer in the multi-signature wallet provides a complete private key signature to control the contract account; while the verification process of TSS only involves a private key, and is a chain The following are not directly related to smart contracts.
There are also many excellent MPC wallet products, such as To B 's Safeheron and To C 's Bitizen .
MPC can also implement functions such as no private key, and MPC can be based on EOA , which seems to be cheaper to use and has better compatibility. MPC technology is not only applicable to the EVM chain, but also to other non- EVM accounts. So, is a contract wallet based on the purpose of having no private key, or is account abstraction really necessary?
Such debates do exist. In May of this year, Coinbase questioned issues such as the expensive gas of contract wallets and the fact that users may not be able to find enough trustworthy guardians in their MPC wallet promotion Twitter.
And Vitalik also expressed his attitude on this twitter :
It can be seen that Vitalik hopes to abstract the account at the protocol level to achieve the goal that the account signature algorithm can be customized. The ECDSA signature algorithm currently enforced by Ethereum is not the optimal choice, and MPC is just a partial security scheme based on ECDSA . After the account abstraction is realized, more advanced and safer signature algorithms (such as quantum-resistant ones) can be directly used according to the development of technology.
Therefore, account abstraction still has considerable necessity in terms of safer signature algorithms, better user experience, and more complete asset control.
The ultimate form of account abstract wallet
After the account abstraction is popularized and a consensus is reached, the compatibility and economy of contract accounts will be improved. Here, we also optimistically predict or look forward to the final state of this type of product, the functions it can provide and the applicable scenarios. We believe that it may include the following functions and application scenarios:
No private key: users no longer need to keep mnemonic words or private keys; multiple verification methods such as biometric verification and device verification can be passed
Account recovery: Account recovery can be performed through biometrics, social verification, etc.
Gas -free interaction: users can use the ERC-20 tokens involved in the transaction to pay for gas , or directly specify a fixed account for payment, without preparing ETH as gas in advance; or without paying gas fees when the transaction fails
Custom security mechanism: With the development of cryptography, you can choose a better security mechanism
Privacy: More effective on-chain privacy based on ring signatures and other methods
Temporary account custody: Users can set management party, time, interaction and other requirements, entrust the account to others for management, and automatically withdraw it after reaching the time or requirements.
Account mortgage / transaction: The account contains assets and accumulated credit history on the chain, and the account itself can be directly mortgaged and traded in the chain market
Account permission restriction and division: You can license some account permissions to others, such as only using NFT in the account but not tokens
Custom Workflows: Set up automated triggers and processes. For example, when the balance of account A is 0.5 ETH more than 1 ETH , it will automatically transfer the excess 0.5 ETH to account B , and account B will automatically swap ETH into a certain token when a certain token reaches a certain price ...
Transaction limit: You can set the transaction time and quota, and the transaction that exceeds the time or exceeds the quota will not be successful
Whitelist / Blacklist: Restrict interaction with blacklisted addresses. For example, assets sent by blacklisted addresses will be automatically returned to avoid " poisoning " to other addresses after the previous tornado cash was sanctioned, resulting in addresses being blocked by other protocol front-ends. Circumstances of false bans.
Account classification management system: Users use dedicated accounts in different scenarios and have a more reasonable account management system. For example, a certain account only stores ETH as a gas account, and the interaction of all other accounts is paid by the gas account; a certain account only stores blue-chip NFT , which will not be easily used; a certain account is used as a game-specific account
Modular code function: Provide users with different functional modules. Users do not need to understand codes. They only need to combine functional modules according to their own needs to customize accounts that meet their own habits and needs.
Conclusion:
The landing of account abstraction is worth everyone's expectation. Because this will not only help the number of users on the chain to increase significantly, but also the high degree of freedom that account abstraction brings to developers will solve the pain points of the current account system and create new applications, gameplay, and imagination.
Realizing account abstraction at the code level is full of obstacles and uncertainties. Although compromise solutions such as EIP-4337 still have practical problems such as high gas and poor compatibility, vigorously promoting EIP-4337 is also a choice to promote concepts and enhance consensus. . With the popularization of concepts, account abstraction and contract wallets will move from niche to mainstream, promote protocol compatibility from user needs, and form a new account paradigm. In the end, under a broad consensus, Ethereum has the conditions to directly change the underlying code to achieve account abstraction.
After the final account abstraction is implemented, the high threshold and complicated 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 , stimulating the vigorous development of the ecology, thus forming a positive cycle.
