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.

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; Account Abstraction frequently appeared in various sharing sessions at devcon 6 held in Bogotá in November, 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 crypto 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 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; for example, the ideal contract wallet applies a unified structure, but it is actually a voluntary ERC proposal, and its effect is very weak; for example, the ideal Accounts using EIP-4337 can bring a better user experience, but it is actually an embarrassing situation where many dapps prohibit contract address interaction...

first level title

text

Before discussing the specific meaning of account abstraction, we can disassemble it first to understand what is "account" and "abstract".

secondary title

Account Accounts

Ethereum has two basic account types: Externally Owned Accounts (EOA) and contract accounts (Contract Account - CA).

secondary title

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.

secondary title

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, of 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:

1. 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

2. Account function abstraction: support code logic and realize custom functions

3. Transaction abstraction: accounts can initiate transactions; gas payment customization

first level title

The development process of account abstraction - from radical to moderate to transition to final state

Discussions on abstraction started 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 5-year radical reform full of idealism. 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. EIP-4337 was born, which opened the era of gentle advancement 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.

secondary title

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, abstracting transaction sources and signatures, and making 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 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 set the last 5,000 transactions not to be included in the block chain, thereby saving gas consumption and reducing invalid spam transactions.

Problems and status quo:

• Does not support gas payment with ERC-20 tokens

• Cannot use ERC 20 s 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 teamed up with many people to propose a more complete account abstraction solution. Compared with the previous account abstraction goal, which unified the account type into one contract account, the EIP-2938 proposal still maintains the existing EOA and contract accounts, 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 for this solution implementation and describes 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

• Pay for gas with 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.

secondary title

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 is 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. Currently, EIP 4337 is still in the Draft state, 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.

secondary title

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 is actually earlier than EIP 4337. It did not introduce a new transaction type, but introduced two operation codes, AUTH and AUTHCALL, which allow EOA control to be delegated to smart contracts, which allows all EOAs to have smart contract wallets function.

Advantage:

• Gas payment: gas fees can be paid by another account, and addresses that do 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 then 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:

secondary title

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, etc. 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.

first level title

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.

image description

Account abstract concept project comparison

secondary title

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 the contract wallet 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 accounts 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.

secondary title

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:

1. 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

2. Account recovery: Account recovery can be performed through biometrics, social verification, etc.

3. Gas-free interaction: users can use ERC-20 tokens involved in the transaction for gas payment, or directly specify a fixed account for payment without preparing ETH as gas in advance; or without paying gas fees when the transaction fails

4. Custom security mechanism: With the development of cryptography, you can choose a better security mechanism

5. Privacy: More effective on-chain privacy based on ring signatures and other methods

6. 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.

7. 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

8. Account permission restriction and division: You can license some account permissions to others, such as only using NFT in the account but not tokens

9. 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...

10. 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

11. Whitelist/Blacklist: Limit interaction with blacklisted addresses. For example, assets sent by blacklisted addresses will be automatically returned to avoid "poisoning" other addresses after tornado cash was sanctioned before, resulting in addresses being blocked by other protocol front-ends. Circumstances of false bans.

12. 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

13. first level title

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.

The implementation of 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.