Account abstraction is mainly to solve two problems, one is to send transactions without ETH, and the other is to implement custom verification logic and algorithms.
Original title: “The Motivation, History and Analysis of Account Abstraction”
Written by: Yao Xiang, Head of MYKEY Research Department
Account Abstraction Account Abstraction is a technical solution to be implemented on Ethereum. It is designed according to the current stage. After the account abstraction is realized, a smart contract account can also actively initiate transactions without relying on the “meta transaction” mechanism.
background
There are two types of Ethereum accounts, one is an external account, and the other is a contract account. The external address is the last 20 bytes of the user’s public key after hashing, and the form is 0x76D836358E7A2 BB0F26c32Ce61Dc8DD540b02F7D. At present, there is only one type of transaction in Ethereum, which must be initiated by an external address, and the contract address cannot actively initiate transactions. Therefore, any change in the state of the contract itself must depend on a transaction initiated by an external address. Whether it is a multi-signature account, a coin mixer, or any smart contract configuration change, it must be triggered by at least one external account. This design makes the following two things impossible.
Active transactions without ether
Since the transaction must be sent and paid by an external account, and the fee is settled in ETH, the external address must hold Ether. Of course, this statement is not rigorous. When the gasprice is 0, the transaction does not need to pay a fee. But this situation is very extreme (see [1]), for ordinary users, such transactions may never be able to block.
Non-secp256k1 native authentication method
Since the transaction must be initiated by an external account, the legality check of each transaction is to verify whether the transaction provides the legal secp256k1 signature corresponding to the account. And if you want to introduce complex logic (such as multi-signature or social recovery) or use different verification algorithms (such as Eddsa, BLS, secp256r1 signature algorithm, these signature algorithms are used because they have special characteristics, or they are zero Knowledge proof-friendly, or convenient signature aggregation to reduce bandwidth overhead, or compatibility with existing hardware verifiers), must be implemented at the smart contract level. This also means that this verification must still be initiated by at least one external account and verified by Ethereum’s secp256k1 signature.
The above two constraints make it difficult for ordinary users to use Ethereum. First of all, no matter what application on Ethereum is used, users must hold ether (and bear the risk of ether price fluctuations). Secondly, users need to deal with complex cost logic, gas price, gas limit, transaction blocking, these concepts are too complicated for users. Many blockchain wallets or applications try to improve the user experience through product optimization, but the effect is minimal.
How to solve the above two problems?
The core idea is to decentralize the ” verification of ownership ” operation from the consensus layer to the contract layer, that is, not to check whether the sender of the transaction is consistent with the owner of the asset, but to check whether it provides legal credentials. The specific method is as follows: the user signs the transaction content and hands the signature to a third party to operate the chain. This third party will be referred to as “operator” in the following articles. This type of transaction is called a “meta transaction.” According to different design concepts, meta-transaction schemes can be roughly divided into two categories:
Account-centric-smart wallet
The goal of the account-centric solution is to create an account based on smart contract management for users, and users can use this account to interact with any contract on the blockchain. The concept of smart wallet has been around for a long time, but it has made great progress in the past year. According to the statistics of “Smart Wallet Trend” (note: the author is myself, hereby declare), there are currently more than 10 operators of “Smart Wallet”, with a total number of users exceeding 140,000. Most of these smart wallets adopt an operating strategy of paying on-chain fees for users, and then charge users through other methods.
The account-centric solution is essentially a blockchain account system, which is highly versatile and can provide additional features including account recovery, large-amount approval, and transfer whitelisting. The operator of the smart wallet assists users in creating and managing programmable identities on the blockchain, and provides transaction on-chain services. Generally speaking, smart wallets will pay users gas fees on the chain, while charging users through a centralized billing system. This model is very similar to account services in the traditional world. For example, operators pay for base stations, fiber optics, etc., and users can use communication services as long as they recharge their phone bills without worrying about the underlying complex logic.
Smart wallets also have their constraints. One is the security issue, and the other is the cost issue.
- Security: If there are loopholes in the account contract, all users’ assets will be at risk. Professional code writing, security auditing, and formal verification can only reduce the possibility of risk, but cannot guarantee that it will not happen-Argent has already happened.
- Cost: Smart wallet account creation requires fees, and transfers and any calls to any contract will cost more than external addresses. This results in higher transaction fees for smart wallet users, which affects their experience
Asset-centric-no gas token
The airless token also has its problems. From the current usage, very few people use this feature (data support is required). In the article “Smart Wallet, More Than Meta-transactions”, I analyzed the possible reasons, one of which is that there is no way to establish an effective billing system.
The asset-centric approach increases the availability of assets. Unlike smart wallets that need to create smart contract accounts, airless tokens can support external accounts to transfer money without using ether. Instead, smart contract accounts need to be compatible with more specifications (such as EIP-2126, so that contracts can identify different types Signature format), otherwise the ownership of the gasless token contract cannot be verified.
The goal of the asset-centric solution is to create assets that allow third parties to pay fees and realize “gas-free tokens.” For example, DAI and USDC can both allow any external address to send assets using meta transactions. These token protocols all use the EIP-712 protocol to verify the legitimacy of the owner.
The history of account abstraction
According to the development history of account abstraction compiled by Matt Garnett [2], since the launch of Ethereum in 2015, the discussion of account abstraction has not stopped. This article will briefly introduce EIP related to account abstraction in chronological order. It should be noted that EIP-208 is omitted from this history, and I have added it accordingly.
EIP-101: Currency and Cryptography Abstraction
November 15 th, 2015
In this EIP[3], Vitalik discussed the design of the account system in Serenity. The main idea of this scheme is that each account has its own “code”, which is the logical part. Due to the excessive changes of the scheme and the poor compatibility with the current transaction, it will cause many security risks. The scheme is shelved after sharding.
EIP-86: Transaction source and signature abstraction
February 10 th, 2017
After a long discussion, Vitalik proposed EIP-86. EIP-86 is a technical preparation for account abstraction. It defines a new type of account that allows users to create an account based on a smart contract. The account is a forwarding contract that stores Ether and checks transactions at the entry point. Sign and forward the verified legal transaction to the designated address, and pay the corresponding fee. This mechanism is more helpful to the realization of scenarios such as multi-signature wallets, ring signature mixed currency, and custom cryptographic algorithms (such as ed25519).
The discussion on EIP-86 has been going on for a long time. It is worth mentioning that Vitalik has enriched the details of the protocol and proposed EIP-208. EIP-86/208 is planned to be upgraded in Metropolis, but at the 19th Core Developers Conference [4], the developers raised many questions and decided to postpone the introduction in Metropolis. The main reasons are as follows.
Account abstraction brings new types of transactions. Compared with traditional transactions that must have an EOA as the sender, these transactions have no sender. This kind of transaction destroys the uniqueness of the transaction hash. Although this will not affect the execution of the EVM, all external operations based on the assumption of “uniqueness” will be affected. For example, all RPC interfaces that locate transactions through transaction hashes.
In addition, the “gasless payment” of account abstraction is an optimization, but it is not necessary. Because its function can be realized through “agent contract”, the only problem is that its cost will be larger than the original implementation.
Miners’ mining strategies will be greatly affected, and these new types of transactions may not be broadcast soon before they are widely accepted.
This new type of transaction still retains the nonce, gasprice, and value fields, and they are set to 0. This is very inelegant, and I hope to solve it with new types of transactions in the future instead of introducing technical debt.
EIP-859: Account abstraction on the main network
January 30 th, 2018
Unlike the previous two EIPs, EIP-859 did not form a definitive draft, but was always in the process of discussion without a final draft. The proposal hopes that the account contract has a relatively standardized implementation, that is, (1) check the signature (2) pay the handling fee (3) call the destination account.
If EIP-859 is implemented, (1) signature algorithm (2) more complex logic can be abstracted, and the “transaction hash uniqueness” feature will not be destroyed, but ERC-20 is still not allowed to pay fees.
This proposal was mentioned in the notes of the 34th and 40th core developer meetings. According to the meeting notes, the 33rd core developer meeting decided to shelve the proposal and focus instead on Casper. In the 34th meeting [5], Vitalik admitted that the proposal is still immature, but “it will be implemented in sharding anyway.” Hudson pointed out that the Constantinople upgrade contains too much content, so the proposal is no longer considered. At the 40th core developer meeting, everyone decided to shelve the proposal permanently, and no one opposed it.
EIP-2938: Account Abstraction
September 4 th, 2020
Two years later, Phase 0 of ETH 2.0 has been launched, and account abstraction has been put on the agenda again. Unexpectedly, the proposal suggested to be implemented first on ETH 1.x.
Simply put, the goal of account abstraction is to make smart contracts a top-level account type, rather than restricted accounts that must be called by external accounts, so that smart contract accounts can actively initiate transactions and pay handling fees. This goal is very different from EIP-86. The proposal at that time hoped to completely eliminate external accounts, or turn all external accounts into contract accounts, and this proposal still retains the existence of external accounts.
Ethereum’s current transaction legitimacy is only judged by three parameters: ECDSA signature, self-increasing nonce and account balance, so it is very easy for nodes to judge the legitimacy of a transaction. However, this is bound to cause many restrictions. After EIP-2938 is implemented, the following scenarios can be actively implemented:
- Smart wallets use algorithms other than ECDSA to verify signatures;
- Other features of smart wallets, including multi-signature and social recovery;
- Privacy protection systems, such as Tornado.cash;
- Improve the gas efficiency of DeFi protocol;
- The user uses other tokens instead of ETH to pay the fees.
Currently, the above user scenarios can also be implemented in an indirect way. The proposal believes that this method is not technically and economically efficient.
EIP-2938 is divided into two stages: single-tenant and multi-tenant. As the name suggests, the difference lies in whether the account owner is a single user or multiple (unspecific) users. In the single-tenant stage, the requirements of the scenarios (1), (2) and (5) can be met, but only in the multi-tenant stage (3) and (4) can it be realized. The technical solution for the multi-tenant stage has not yet taken shape. For more information about EIP-2938, you can refer to the article published by Status and translated by Ethereum fans [6].
What is the price? -Two sides of the coin
Undoubtedly, assuming that the account is successfully deployed in abstraction, it can bring new features, but there must be trade-offs. It is impossible to get good things, but at no cost. The discussions over the past five years have given us enough experience, and its negative effects are even difficult to analyze due to its complexity. Nevertheless, this article will attempt to systematically discuss its potential gains and costs so that the reader can make a fair judgment. “Account abstraction gains” refer to the core developer Peep an EIP document [7].
The gains of account abstraction
- Smart contract account that actively sends transactions.
- Smart contract accounts can actively send transactions without EOA triggering, which reduces the dependence on operators and consumes less gas.
- Improve the privacy of the coin mixer.
- At this stage, users withdrawing money from a currency mixer like Tornado.cash still need to rely on an EOA account to send transactions, which is a vulnerable link that exposes privacy. After the realization of multi-tenant account abstraction, when anyone withdraws tokens, there is no need to pay additional fees, but directly deducted from the withdrawal amount.
- Use other tokens to pay handling fees.
- At this stage, users must use ETH to pay for network fees. After the account abstraction is implemented, users can use other tokens to pay for fees. But this does not mean that the mining union at the protocol level accepts non-ETH as a fee, but exchanges with DEX for ETH to pay the fee.
- Reduce invalid arbitrage transactions on the chain and improve scalability.
- At this stage, when arbitrage opportunities are found on the chain, there may be multiple arbitrage transactions initiated at the same time, and the first successful arbitrage transaction will invalidate the arbitrage behavior of the remaining transactions, but these transactions will still be packaged in Ethereum ( If the gasprice is sufficient and the transaction is not replaced with the same nonce), this leads to a large number of “garbage” transactions on Ethereum. After the account abstraction is realized, since price judgments can be made during the account authority verification stage, arbitrageurs do not need to pay for failed arbitrage behavior, and the chain will not include failed arbitrage transactions, which can effectively improve the scalability of the chain.
The cost of account abstraction
- Increase the overhead of the memory pool to verify the validity of the transaction
- At this stage, when a node receives a transaction, it is easy to judge its validity and load it into the memory pool. The node only needs to judge three things: the validity of the signature, the rationality of the nonce (the current nonce of the account plus 1 or a reasonable value), and the balance of the account. If any one of them is not satisfied, the node can choose to discard the transaction. Illegal transactions do not pay commissions. Nodes are “verified” for free. Since the verification of ECDSA signatures is very simple and the cost is extremely low, the security of the current network will not be challenged.
- When account abstraction is introduced, it is much more difficult to judge the validity of a transaction. Nodes need to spend more computing resources for the verification of invalid transactions, but cannot charge any fees. For DOS attacks, see [8]
- Increase the memory pool to ensure the effectiveness of the transaction overhead
- At this stage, once the node verifies the validity of a transaction, unless the account uses the same nonce to send a new transaction and is packaged, the transaction loaded into the memory pool will always be valid until it is packaged into a block (also It may not be packaged because the gasprice is too low). After the account is abstracted, it is more difficult to judge the validity of the transaction. Multiple transactions in the memory pool can be valid at the same time before being packaged, but because their validity may depend on the global state, there are remaining transactions after one of the transactions is executed. The possibility of total failure. Therefore, a new memory pool rule needs to be established to avoid this situation.
- Introduce new transaction types, billing methods, mining and broadcasting strategies
- First, a new transaction type has been introduced. During the discussion of EIP-86/208, there was a tendency to “eliminate” EOA accounts, or to wrap EOA accounts in a smart contract account, so that there is only one basic account type and transaction type on the chain. In this proposal, the EOA account is retained, that is, there are two types of accounts-EOA and AA, and there are also two types of transactions. At the same time, the AA transaction must add a prefix when calling other contracts to prevent the EOA account from initiating the modification of the AA account status, which affects the judgment of the validity of the transaction, which may cause compatibility problems.
- Second, the billing method has changed. At this stage, miners do not need to care about the content of the transaction, only need to confirm that the ETH balance of the initiator of the transaction is greater than gaslimit*gasprice to guarantee receipt of the commission. After the account is abstracted, how to ensure that the miners can receive the commission? This proposal splits a transaction into two parts-the verification phase and the execution phase, using a new operator PAYGAS interval. In the verification phase, the verification of account permissions is completed, and it is not allowed to call external data or manipulate account balances at this stage. Consistent with the current method, if the verification is passed, the transaction fee will be paid and the transaction will be executed. Even if the transaction is rolled back during the execution phase, it will still be included in the block and paid, but the illegal transaction will be discarded if the verification fails.
- Furthermore, mining and broadcasting strategies have become more complicated. In order to protect the safety of the memory pool and miners, the recommended mining strategy is more conservative. Only one pending transaction for each account is reserved, and transactions with higher nonce are no longer reserved; the upper limit of gas capacity is set for the verification phase; after the transaction initiated by the AA account is packaged into the block, the memory pool needs to be discarded. The transaction for which the account is operated.
- In order to avoid the potential impact caused by the first two costs, the Ethereum protocol layer needs to make corresponding technical changes.
Re-evaluate the “harvest”?
To assess the necessity of account abstraction, we may first review its “harvest.” “Harvest” is nothing more than two types-what could not be done before can be done now; it is better than before.
Smart contract account that actively sends transactions.
Smart wallets can do this, and this gain is an improvement. Since the validity of the transaction relies on a qualified signature (or other credentials), not the EOA account that sent the transaction, any EOA account can submit the transaction, and there is no risk of trust or reliability. Since there is no need to forward transactions, less gas consumption is a reasonable “harvest”, but can it achieve the overall best? In other words, after introducing such complex technical changes, for the same transaction content, can the computer process more AA transactions or EOA transactions in the same time?
Conclusion: An improvement that requires technical verification.
Improve the privacy of the coin mixer.
At present, Tornado.cash uses the operator’s model instead of submitting receipts for withdrawals. Unlike smart wallet operators, privacy operators may not be stable enough and anyone can submit transactions instead, but the reliability of operators in privacy scenarios will be lower than general scenarios, which may result in unavailability of services. However, this needs to be achieved in the multi-tenant stage, and the feasibility and security of the current multi-tenant model still need to be verified.
Conclusion: An improvement to increase service availability. But I don’t know if it can go online or when it can go online.
Use other tokens to pay handling fees.
Smart wallets are now doing similar things. For example, Argent and MYKEY both allow users to use DAI to pay fees, but this operation is not atomic. Using stable currency and other assets to exchange DEX for ETH to pay the handling fee. At first glance, it solves the problem that could not be solved. But what I want to express is that the real demand is not technical completeness, but the use of stable currency to combat unstable procedures Fees (ETH price fluctuations, gasprice price fluctuations, gas consumption uncertain). Using the transaction on the chain to directly replace the handling fee, there is a feeling of buying a rechargeable card to recharge the phone before using the mobile phone to connect to the Internet. It seems to be back to the era of coin-operated phones. What’s more, this transaction still has a huge risk of failure, because changes in the state of the chain may affect the price. Of course, this is not to say that coin phones are useless.
Conclusion: An improvement that can realize the atomic use of non-ETH assets to pay commissions. But it does not solve the problem of price fluctuations, the real demand is doubtful, and the billing method is inefficient.
Reduce invalid arbitrage transactions on the chain and improve scalability.
In the research process, the statement about “reducing invalid transactions on the chain can improve chain scalability” even made me doubt the motivation of the entire account abstraction. Under the current model, arbitrageurs pursue arbitrage opportunities, but due to open strategies, different arbitrageurs may compete, increase network rates and introduce a large number of failed arbitrage transactions. However, arbitrageurs understand this truth better, and therefore will also evaluate the consequences of arbitrage failure, otherwise they will have to pay the price of handling fees, which is precisely the cost that keeps the system in a dynamic game. If the behavior of competitive arbitrage does not require cost, then although there will be no invalid on-chain transactions, the entire system will accommodate more arbitrage behaviors, allowing nodes to bear more computing tasks that cannot be charged, so how about increasing the system Scalability?
Conclusion: It is not an improvement, but a kind of stubbornness for the sake of “clean” on the chain.
In summary, most of these claimed improvements are just “optimizations” of existing implementations, and lack sufficient verification, and some of the “optimizations” cannot even withstand scrutiny.
to sum up
This article summarizes the background of Ethereum’s “account abstraction”. “Account abstraction” is mainly to solve two problems, one is to send transactions without Ether, and the other is to implement custom verification logic and algorithms. In order to solve these problems, Ethereum has put forward a number of proposals in history. This article analyzes the attempts of these proposals and the reasons why they were not adopted. The focus of this article is on EIP-2938, the latest analysis of account abstraction, and discuss its “harvest” and “cost”. “Account abstraction” can make some functions that require the introduction of “trust” to be realized at this stage more reliable, such as providing better privacy for coin mixers, or using assets such as stable coins to pay fees, but it also It will inevitably bring about major changes in the technical architecture, and its security also requires more complete verification. To quote A Jian’s passage, “And if certain technologies neither increase what people can choose, but also sacrifice what people actually choose, then there is no reason to have confidence in these technologies.”
Reference article
[1] https://etherscan.io/tx/0x4f719da4e138bd8ab929f4110e84d773b57376b37d1c635d26cd263d65da99cb
[2] https://hackmd.io/@matt/r1neQ_B38
[3] https://github.com/ethereum/EIPs/issues/28
[4] https://github.com/ethereum/EIPs/pull/208#issuecomment-313872489
[5] https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2034.md
[6] https://ethfans.org/posts/account-abstraction-eip-2938-why-and-what
