An Introduction to Account Abstraction

An Introduction to Account Abstraction

In my last articles I went over problems we are facing on the internet and how blockchain technology and Web3 can be part of the solution to these problems. In the Web3 space there is always a lot of talk about onboarding the next couple of million or even billion users. The thing is, currently it is quite difficult for the average person to figure out how to participate. This article now goes over the first step in taking part in web3, which is having a wallet. This is the first step and currently also probably one of the biggest obstacles people face in onboarding. Here I want to shine some light over the current state, its issues, and limitations, before presenting what the next phase or versions of wallets might look like.

The Current State of Blockchain Interactions

Before we dive deeper, I want to touch on the current state of wallets, which in turn also strongly influence the user experience. Everyone who has already interacted with any protocol on Ethereum, or a Layer 2 has already used a wallet. And for those who have not, here are the steps needed once you create a new wallet.

The easiest way, and probably the only way, many people do this is with a browser wallet like MetaMask. Those are basically extensions to your browser, which make it possible for you to communicate with your wallet. So, after installation, a public key and private key are generated, as well as a secret recovery phrase. Currently, accounts rely on private keys generated from seed phrases for security. If someone gains access to the seed phrase, they can easily deduce the private key guarding the account, thereby obtaining control over all associated assets. Losing or exposing the private key and seed phrase renders them irretrievable, resulting in the permanent freezing of the assets they safeguard. Safeguarding these seed phrases poses challenges, even for experienced users, and phishing attacks targeting seed phrases are among the most prevalent scams users encounter. And this is where the first obstacle to user friendliness already presents itself. This secret recovery phrase is also the only thing that can get your wallet back. If you for example loose access to your current wallet, or the device you set it up on, you can use this phrase to restore the wallet and continue like before.

While this is great in terms of decentralization, it sounds like a nightmare to some people. I had an instance where I explained this to someone I know, and their first reaction was a worried question on who can help them recover the phrase in case they lose it. The answer is no one. Once this phrase is lost it is permanent. This is also why you can find several products and services handling this problem, for example by stamping the words into metal plates and storing them in a vault.

But let´s face it. For the vast majority of people, decentralization is not really that important that they want to risk losing access to their funds because of making a mistake. And while many people in Web3, like myself, are strongly in favour of decentralization and self-custody, it is simply not in the minds of most people. And while we can claim that this is a matter of information and education, it is hard to defend, that the status quo is accepted as a given by people enthusiastic about the core values of web3 and not the vast majority of future users. It is important that more people use Web3 because this can in turn also increase decentralization.

The Solution and a Driver for Adoption

So, what is the solution for the problem presented in the paragraph before? One of the possible solutions and the focus of this article is account abstraction. While still in its infancy, I will give you an introduction on what a future implementation of this concept can look like.

As of now, Users engage with Ethereum through externally owned accounts (EOAs), which represent the sole means of initiating transactions or executing smart contracts. This framework imposes constraints on user interactions with Ethereum, complicating tasks like batch transactions and necessitating the maintenance of an ETH balance to cover gas fees.

Account abstraction presents a solution to these challenges by empowering users to programmatically enhance security and user experiences within their accounts. This could involve upgrading EOAs to be controlled by smart contracts or enabling smart contracts to trigger transactions. Both options require modifications to the Ethereum protocol. Another approach involves integrating a secondary transaction system alongside the existing protocol. Regardless of the method chosen, the goal is to enable access to Ethereum through smart contract wallets, either integrated into the core protocol or via an additional transaction network.

Smart contract wallets offer various advantages to users, such as establishing customizable security rules, enabling account recovery in case of key loss, facilitating shared account security across trusted entities, facilitating gas payments on behalf of others, bundling transactions together for efficiency, and fostering innovation in dApp and wallet development.

Currently, these benefits are not inherently supported because only externally owned accounts can initiate transactions, operating based on public-private key pairs. However, smart contract wallets address key issues, offering solutions like customizable security features and account recovery mechanisms. Nevertheless, programming smart contract wallets can be complex, as their logic must ultimately be translated into EOA transactions for Ethereum processing. Account abstraction streamlines this process by enabling smart contracts to initiate transactions themselves, allowing users to implement desired logic directly into the smart contract wallet.

In essence, account abstraction enhances support for smart contract wallets, simplifying their development and bolstering their safety. Ultimately, with account abstraction, users can reap the benefits of Ethereum without needing to grasp the intricacies of its underlying technology.[1]

What Account Abstraction promises to improve

So now you can see why it is important and what it could change. In essence, it makes interacting with the blockchain more beginner friendly and could take away many barriers to mass adoption. But I want to give you even more examples of use cases before I will dive into more technical aspects of this topic. Here are some key use cases unlocked by account abstraction:

1. Wallet Recovery: Unlike EOAs, the security of a smart account isn't dependent on a seed phrase or private key. Owners of smart accounts can designate multiple devices, individuals, or third-party services as wallet guardians. If credentials are lost, these guardians can collectively authorize a transaction to establish new credentials for accessing the smart account, without compromising the user's asset control or ownership.

2. Batch Transactions: Traditional transactions on decentralized exchanges often necessitate separate actions for approval and execution, sometimes requiring multiple signer approvals. With smart accounts, multiple transactions can be grouped together and approved simultaneously. This simplifies DeFi transactions, mirroring the ease of traditional finance transactions.

3. Shared Accounts & Team Wallets: With EOAs, control over a crypto wallet is binary - either full access is shared or none. Account abstraction enables varying levels of access to be shared among multiple users. This could involve setting up multi-signature requirements where multiple users must approve transactions or granting limited payment abilities to specific wallets within defined parameters.

4. Automated Transactions: EOAs require manual initiation or signing for each transaction on a dApp, lacking automation options for trusted transactions. Smart accounts allow for the definition of parameters such as token access, spending limits, gas limits, and predefined triggers for specific actions. This flexibility enables automation to a degree limited only by imagination.

Additional benefits of account abstraction include the ability to define custom security features like daily spend limits, sponsoring gas fees for other users' transactions, and using any token for gas payments.[2] Account abstraction also enables dApp creators to exercise ingenuity in gas administration. For instance, you could potentially subscribe to your preferred DEX by paying a set monthly fee for limitless transactions. DApps may propose covering all your gas expenses as an incentive for utilizing their platform or as a welcoming gesture. The integration of smart contract wallets at the protocol level will significantly streamline developers' ability to pioneer new approaches to gas management.[1]

But now that I told you what Account Abstraction is, we need to discuss how this can be implemented. AS of now, the favoured form of implementation is ERC-4337. EIP-4337 introduces account abstraction through an alternative mempool, granting smart contracts functionalities similar to EOAs. ERC-4337, co-authored by Vitalik Buterin and others, introduces account abstraction to Ethereum without altering the core protocol. It achieves this by replicating the transactions mempool's functionality in a higher-level system. Instead of traditional transactions, users send UserOperation objects to Ethereum nodes, which are then bundled into a single transaction included in the Ethereum chain.[3] There are also other Proposals to introduce Account Abstraction, but they would require a fork of the Ethereum chain, something which comes with own problems of itself, and for now ERC-4337 looks to be the winner in becoming the standard for building smart contract wallets and could also already establish itself as the community favourite.

Other Account Abstraction Model Proposals

Other Proposals are these ones you can see listed below:

EIP-2771 introduces meta-transactions, enabling external entities to cover users' gas expenses, all without altering the Ethereum protocol. The process involves sending signed transactions to a Forwarder contract, which verifies and forwards them to a gas relay. The gas relay then directs the transaction to a Recipient contract, covering the gas fees to ensure its execution.

In contrast, EIP-2938 proposes a protocol update by introducing a new transaction type, AA_TX_TYPE, comprising three fields: nonce, target, and data. Nonce serves as a transaction counter, target designates the entry point address, and data consists of EVM bytecode. To support these transactions, two new instructions, NONCE and PAYGAS, are required in the EVM, facilitating native support for smart contract wallets.

EIP-3074 seeks to enhance Ethereum's externally owned accounts (EOAs) by enabling them to delegate control to smart contracts. This delegation empowers smart contracts to authorize transactions initiated from user accounts. To implement this functionality, two EVM "opcodes," AUTH and AUTHCALL, must be introduced. Under this framework, smart contract wallets can be deployed without the necessity of a contract. Instead, an immutable and trustless contract named "Invoker" manages transactions in a stateless manner, ensuring security and reliability.[4]

Why Account Abstraction matters

Account abstraction offers significant enhancements to user experience and security by integrating support for smart contract wallets at the protocol level. This integration grants developers of smart contracts, wallets, and applications greater freedom to innovate in ways that may surpass current expectations. Notable improvements stemming from account abstraction include the streamlining of transaction bundling for efficiency, enabling actions like swaps to become seamless one-click operations, thereby eliminating the need for users to sign multiple transactions individually.

Moreover, gas management sees substantial enhancements through account abstraction. Traditionally, gas fees are solely payable in ETH, posing a hurdle for users who lack an ETH balance but hold other assets like USDC. With smart contract wallets, users can now pay gas fees using tokens like USDC, freeing them from having to maintain an ETH balance across all their accounts. DApp developers can also leverage this flexibility to offer innovative gas management solutions, such as subscription-based fee models or covering users' gas fees as incentives.

Furthermore, trusted sessions facilitated by account abstraction hold transformative potential for user experiences, particularly in applications like gaming, where rapid approval of numerous small transactions is essential. Smart contract wallets can provide temporary approval for specified transactions within a defined timeframe or under certain conditions, enhancing user convenience while maintaining security.

The concept of purchases is also reimagined with account abstraction, potentially resembling the familiar online shopping experience where users can add items to a "basket" and execute all transactions with a single click, with the contract handling the required logic.

These examples illustrate just a fraction of the possibilities unlocked by account abstraction, with countless other innovations waiting to be explored. By freeing developers from the limitations of current externally owned accounts (EOAs), account abstraction enables the integration of desirable features from Web2 into Web3 while preserving self-custody and fostering creative exploration of novel user experiences.

Final Thoughts

As I have outlined in this article, Account Abstraction holds a lot of promises. It also will undoubtedly be one of the biggest drivers for Web3 adoption. It also opens the door to create different smart contract wallets for different usecases. Just think of how many different types of “wallets” or apps you have on your phone today which hold secure information. Some of these could benefit from the integration of Web3 and have a very similar User Experience compared to their current Web2 functionality. Together with other continuous and much needed improvements this could mean that Web3 could finally have the ability to be appealing to people outside of the tech bubble.

While we still might have to wait until this thing really kicks off and Account Abstraction becomes the standard, there is still a lot of opportunity to participate and grow. While smart contract wallets are already available, further enhancements are necessary to maximize their decentralization and permissionless nature. EIP-4337 stands as a mature proposal that doesn't demand alterations to Ethereum's protocol, suggesting potential for swift implementation. However, modifications affecting Ethereum's protocol are presently not actively pursued, implying that their realization might entail a prolonged timeline. There's also the prospect that EIP-4337 adequately accomplishes account abstraction without necessitating any protocol adjustments.

Also, with other improvements on Ethereum like the recent Dencun Upgrade which increases data blobs per block, vital for Ethereum's scalability to support more users and transactions affordably while maintaining decentralization. Without these changes, hardware demands would rise, pricing out smaller operators and centralizing network control, contradicting Ethereum's ethos.

So, as you can see, things are still evolving at a fast pace towards a more user friendly and optimized Experience of Web3. It remains to see how these promises play out and what further developments they might make possible.

Sources

[1] N.N., Account Abstraction, In: Ethereum.Org, Roadmap (January 25th, 2024), online: https://ethereum.org/en/roadmap/account-abstraction/

[2] Mrig P, M. Musharraf, What is Account Abstraction? ERC-4337 Explained, In: Thirdweb, Blog (May 2nd, 2023), online: https://blog.thirdweb.com/account-abstraction-erc4337/

[3] N.N., ERC-4337: Account Abstraction, In: ERC4337 Team, (n.a.), online: https://www.erc4337.io/

[4] N.N., What is Account Abstraction – Full Guide, In: Moralis, Blog (September 18th, 2023), online: https://moralis.io/what-is-account-abstraction-full-guide/