Before account abstraction, there were two types of accounts in Ethereum: externally owned accounts (EOA) and smart contracts. An EOA is a typical user account that has a private key. This is also the only type of account that can initiate a transaction. For instance, a user has to have ETH to send a transaction. Creating batched transactions is difficult, and there are no recovery options if a user loses their private key. Account abstraction (AA) was created to solve these issues. But is it a risk-free solution? This guide covers the basics of AA before detailing its risks and how to mitigate them.
What are the key features of account abstraction?
Account abstraction is a technology that enables smart contracts to initialize transactions by themselves. It allows users to create accounts that are represented by smart contracts. This technology also enables several features that improve users’ interaction with the chain.
- A user can pay for gas fees with tokens
- Applications can sponsor gas for users’ transactions
- There are flexible mechanisms to secure account
- Bridges and cross-chain dexes can work without native currency.
Use cases of account abstraction
Free transactions: Projects can pay users’ transaction fees.
Non-native cross-chain transactions: A possibility to bridge an ERC20 token to another chain and pay with it for transaсtions, which means there’ll be no need to additionally fund the account with native currency.
Additional wallet security features: In case of security risk, all operations on the account can be paused, and access can then be restored with the backup keys.
Account recovery: For example, a set of keys can be used to recover the key.
Transaction limits: An account that will be able to spend a specific sum of ETH per month can be created.
Subscriptions: Enabling subscriptions the same way they function with traditional credit cards.
Implementations of account abstraction
There have been different proposals on how to implement AA into the Ethereum network. Some of them involve significant changes to Ethereum’s protocol which complicates the implementation. The most prominent implementation is ERC-4337 which does not involve any consensus layer changes. The standard replicates the transaction mempool on a higher-level scale. The smart contracts of ERC-4337 were deployed to the Ethereum network in March 2023.
ERC-4337 uses smart contracts named wallets instead of EOA. This smart contract wallet can be controlled not only by a private key but by an arbitrary complex mechanism that is encoded in the contract.
Instead of transactions, users send UserOperations. A UserOperation contains instructions to execute, signatures verification, and other data. Like with transactions, a user specifies a premium for the Bundler to prioritize his operation.
Miners or bundlers package operations into bundle transactions which are then included in the Ethereum network.
Amongst other data, the UserOperation contains the code to create a smart contract wallet. If a user doesn’t have a wallet, it is created for them.
If a user wants to pay for the transaction with an ERC20 token or even doesn’t want to pay for a transaction at all, they specify a paymaster contract address in the UserOperation. A paymaster is a third-party service that will pay for the transaction in exchange for ERC20 tokens.
What are the risks, and how to mitigate them?
Although account abstraction is created to improve user security, there are some risks, especially in the early phases of adoption. The Ethereum ecosystem is notorious for bugs in smart contracts that have led to billions of dollars stolen by malicious users. Here are some risks of AA and how they can be avoided/mitigated.
Risk of bugs in the implementation of the standard
Like any new technology, account abstraction runs the risk of its first implementation containing bugs. The smart contracts of ERC-4337 were audited by a leading blockchain security company OpenZeppelin.
Mitigation: The solution is to use formal verification — a process that involves using mathematical methods to prove the correctness of smart contracts. The process of formal verification for the ERC4337 contracts is ongoing but not yet finished.
Bugs due to incompatibilities with some smart contracts
Not every smart contract is compatible with account abstraction wallets. For instance, smart contracts that use the tx.origin field to check the wallet that sent the transaction will get an unexpected value. Another incompatibility occurs with smart contracts which use EOA signatures: they are not supported by AA wallets.
In such contracts, certain crucial functionalities may not perform correctly. In the worst case, users’ funds can be blocked.
Mitigation: In order to lessen the risks, a user using an account abstraction wallet must check if the protocol he interacts with supports the technology.
Third-party code for wallets
The standard is designed so that a smart contract wallet can be created within the first UserOperation via a smart contract factory. However, there is a risk that the wallet implementation smart contract will contain bugs. It’s crucially important to use only wallet factories that have been thoroughly audited and tested by the leading blockchain security companies.
Mitigation: Use only trusted services to create wallets and ensure that the wallet’s code is audited at least by one trustworthy blockchain security company.
Third-party code for paymasters
If a user or a project uses paymasters, it relies on a third party to pay for the transactions. There may be errors in paymaster implementation, and a malicious paymaster can steal users’ funds.
It must be noted that the chosen paymaster service can also suffer from malicious users who can find ways of tricking the paymaster into paying for their transactions.
Mitigation: Wallets only use paymasters from trustworthy providers and ensure that the paymasters’ code was audited before using them.
Best practices
Account abstraction on the Ethereum blockchain is a relatively new concept. As such, the best practices and developer’s frameworks for its utilization are still in the process of being established. There are very few examples of using account abstraction for developers to learn from.
Mitigation: The best practice will eventually develop following the spreading of the standard. For developers, it’s crucial to share experiences using the new technology, especially in the early stages of adoption.
Draft mode of the standard
ERC-4337 is still in draft mode, although the contracts have already been deployed on Mainnet. There is a possibility that the standard will change. It should be noted that said changes are supposed to affect smaller details and not affect already deployed smart contracts.
Mitigation: Developers should keep an eye on how the standard develops and update the code of their projects accordingly to the standard changes if they occur.
Centralization
Although ERC-4337 is designed so that everyone can start a bundler, at least in the initial stage, the account abstraction ecosystem is fairly centralized as there are few production-ready implementations of Bundlers.
Mitigation: To avoid risks of an error in a Bundler implementation affecting the account abstraction network, at least a couple of Bundler implementations should be used. A lot of Bundler implementations are currently in development, and soon many of them will be production ready.
Account abstraction risk vs. reward?
Account abstraction is a potentially great technology that can bring more adoption to Ethereum. At the same time, it’s one of the developments that can make the blockchain more secure. Still, like with any new addition to blockchain technology in its early stages, users should be extra vigilant. Reviewing and researching AA is the best choice for everyone willing to adopt this technology.
Frequently asked questions
What is account abstraction?
Is account abstraction more secure than traditional wallets?
Is account abstraction ready to use?
About the author
Gleb Zykov is the CTO at HashEx. Gleb started his career as a software developer in a research institute, where he honed his technical and programming skills in the development of various robots for the Russian Ministry of Emergency Situations. He then brought his expertise to the IT services company GTC-Soft, where he designed Android applications and became the lead developer and CTO.
At GTC, Gleb led the development of several vehicle monitoring services and a premium taxi service similar to Uber. In 2017, Gleb co-founded HashEx, an international blockchain auditing and consulting company. As the CTO, he heads the development of blockchain solutions and smart-contract audits for the company’s clients.
Disclaimer
In line with the Trust Project guidelines, the educational content on this website is offered in good faith and for general information purposes only. BeInCrypto prioritizes providing high-quality information, taking the time to research and create informative content for readers. While partners may reward the company with commissions for placements in articles, these commissions do not influence the unbiased, honest, and helpful content creation process. Any action taken by the reader based on this information is strictly at their own risk. Please note that our Terms and Conditions, Privacy Policy, and Disclaimers have been updated.
