Account Abstraction - the Future of Wallets?

With the long-awaited Merge complete, Vitalik Buterin is now turning to another passion project: account abstraction (AA). Account Abstraction creates an unique opportunity in ethereum to re-think how wallets work, what accounts can do, and how accounts interact with dapps.

‍

This post will cover the motivation behind account abstraction, what it is, what use cases it enables, and when we expect to see it live on Ethereum.

‍

‍Ethereum History

As we covered in our Wallet Wars Part 2 blog post, Ethereum has two types of accounts: Externally-owned accounts (EOAs) and Smart Contracts. 

1. EOAs are the traditional accounts that you create with a wallet like MetaMask. They have a hidden private key and a derived public address and are what most users use to interact with the blockchain.
2. Smart contracts are programmable applications that can perform transactions but do not have an associated private key. EOAs or other smart contracts can transact with these entities, performing a predetermined set of actions based on their program logic. Many DeFi and wallet applications on Ethereum are built on smart contract accounts. 

In this EOA-centric paradigm, the concept of the signer and the concept of the account are merged. The entity authorized to spend your tokens (the signer), is the same as the entity that holds your tokens (the account). This creates problems because it means that if an EOA account holder loses their signer (private key), they lose their account. EOA accounts are hard to secure and hard to recover.

‍

EOAs also have several other limitations, since much of their functionality is hardcoded into the core Ethereum protocol. For example, EOAs only allow for the use of ECDSA (elliptic curve digital signature algorithm) for signature verification without the option to switch to a more efficient or quantum-safe algorithm. To make this more concrete, Gmail allows you to enable 2FA on your account. Similar customizability can't be done on Ethereum today.

‍

At the same time, the current design of Ethereum requires that all transactions be initiated from an EOA, and that only that EOA can pay the gas fee (which must be paid in ETH). There is also no way to batch operations (for example approve + transferFrom), making Ethereum less efficient.

As the Ethereum ecosystem has grown and developers want to build increasingly complex products, these constraints have encumbered the product experience. For example, some DApps like Dark Forest require the user to take a number of actions on-chain in quick succession. To accommodate this, users either have to manually approve every transaction from their wallet, which is extremely burdensome, or the app will create a burner account for you, generating a private key and storing it in your browser or other “secure location”. Anytime you want to transact with the Dapp, they automatically sign your transaction with the private key without you noticing. 

‍

The problem with this second workaround is that your burner account is completely detached from your main account. This means that any balances you have on it are secured only by whatever security mechanism the Dapp uses, as opposed to leveraging the OpSec you maintain with your original wallet.

‍

In looking at this setup, the utility of having a more generalized, “abstracted”, notion of account is obvious – it would be great to be able to decouple the relationship between the account and the signer. This is the essence of account abstraction – that all accounts would be smart contracts with their own custom logic defining what a valid transaction is. These “smart contract wallets” have their own custom methods with their own methods for signature, replay protection, and gas payments, while still maintaining a connection to a private key.

Since 2016, the Ethereum foundation has been exploring different approaches to account abstraction, for example, EIP-86, which introduced a “forwarding contract” to abstract signature verification and nonce, and allow for signature certifications schemes other than ECDSA, and EIP-2938 in 2020, which would have introduced Ethereum protocol changes that would allow transactions to start from a smart contract instead of an EOA. However, both these proposals ultimately failed because they would require significant changes to core Ethereum, and thus significant development time.

‍

EIP-4337

Most recently in 2021, Vitalik and others submitted EIP-4337, which introduces AA without any changes to the core Ethereum (and thus does not require a fork). Instead, it proposes the creation of a higher-level system, a separate mempool¹. Users send

‍

UserOperations to the new mempool, which are then bundled and submitted to Ethereum as a single transaction. 

‍

It decouples parts of EOAs' actions (like transactions), which are currently implemented as part of the core Ethereum, and moves them to the Ethereum Virtual Machine (EVM) for greater flexibility, upgradability, and interoperability. Since the EVM is a runtime environment separate from the Core Ethereum, modifications can be made more quickly. 

‍

The EVM abstraction from the core also allows AA to be used on other L2 blockchains, making it easier for them to communicate and interact.

‍

Use cases

‍

AA opens up a plethora of use cases, including:

‍

1. Sponsored transactions

DApp developers could choose to subsidize the transaction fees as part of their onboarding process, removing one of the biggest friction points for new crypto users. Currently, potential users have to go to a centralized exchange, wait for KYC, purchase Ethereum, transfer it to their wallet, in order to try out most DApps.

‍

2. Recurring payments on a self-custodial wallet

Currently, all transactions on a self-custodial wallet have to be approved synchronously. With AA, transactions could be scheduled with a time delay, or according to event-driven flows. This would allow you to set up something like recurring payments on a self-custodial wallet.

‍

3. Social-recovery

In traditional wallet recovery methods, a user has to provide a recovery phrase or seed phrase to recover their wallet. However, this can be problematic if the user loses access to their recovery phrase or if it is stolen.

With account abstraction, it is possible to implement a social recovery process where a user can designate multiple trusted individuals as recovery agents.

‍‍

4. Multisig wallets by default because every account is a smart contract

In a multi-sig wallet, multiple individuals or parties must provide their signatures before a transaction can be executed. Currently, multi-sig wallets require EOAs to initiate the transaction, pay the gas fee, and then call the multi-sig smart contract. The contract will then refund the gas amount the EOA initially paid. 

With account abstraction, accounts can be programmed to require multiple signatures before a transaction can be executed, effectively making every account a multisig wallet by default. This allows users to easily implement multisig functionality without having to use a separate multisig wallet contract.

‍

5. Session keys for games

Currently, players of blockchain games either have to approve every action or give the game full control over their wallet. With AA, the smart contract wallet can be programmed to create a private burner key that permits automatic transactions only with the specific DApp for a specific amount of time. This provides the minimum privilege to the DApp and increases security. All the assets belonging to the main account remain protected.

‍

When will account abstraction get here?

EIP-4337 is a work in progress and will change before it is finalized. Meanwhile, some L2 chains have begun implementing their own versions of account abstraction: StarkNet, an L2 ZK-rollup, has only a single account type - a contract. Its AA model permits users to customize the signature validation algorithm and have other parties pay gas on behalf of the transacting account. zkSync, another ZK rollup, also implemented account abstraction in its 2.0 release inspired by EIP-4337. Their implementation requires all accounts to implement the IAccount interface, which contains methods to verify and execute transactions and optionally elect a transaction sponsor. 

‍

Account Abstraction Risks

Despite the increased flexibility AA provides, the extensibility of transactions also increases the surface area for attack vectors — every component needs to be secure individually and holistically. As the changes in EIP-4337 may not be backward compatible with older smart contract wallets, migrating to the new standard can introduce unforeseen bugs or security risks. If this process causes the new smart contract wallet to become vulnerable, attackers can transfer funds out of the abstracted account, circumventing EOAs or private keys. 

‍

Additionally, the new architecture requires all wallets to send transactions to a global entry point contract. As a result, this entry point needs to be robust and well-protected as it needs to ensure that all the transactions received are appropriately signed and validated. 

‍

Some other potential issues with account abstraction include higher gas fees - smart contract wallets might require a lot of processing power to execute – and lack of true cross-chain compatibility. Smart contract wallets would have to be deployed separately for each chain, and most current attempts to implement multi-chain support are complex. 

‍

Does AA compete with MPC?

Given that account abstraction is still very much in development, one of the alternatives that have been frequently discussed is MPC wallets. MPC wallets leverage multi-party computation, a set of cryptographic techniques that allows multiple parties – each holding their own private data – to evaluate a computation without ever revealing any of the private data held by each party (we have previously published a blog post on the technology). 

‍

Unlike multi-sig wallets, which multiply the number of locks and keys, MPC wallets break a single key into individual shards. This way, rather than a single owner having to be responsible for a private key, multiple parties can hold partitions of the private key. With threshold signatures, a subset of them can come together to sign a transaction.

MPC wallets can work alongside AA to provide users with a secure key management system. Imagine you create a wallet to hold your company’s funds. With MPC, you can decompose the wallet’s keypairs, distribute them to trusted company personnel, and configure it to have a majority signature scheme. With AA, you can permit a vetted external service — like a web hosting tool or a vendor — automatically withdraw funds from the account without needing a majority of the key holders to sign every time. You can set limits on daily transaction amount and frequency per service. The synergy of MPC and AA provides users with a cryptographically secure key management system and powerful customization tool.

‍

Conclusion

Even though AA has been in discussion since Ethereum's early days, we are finally seeing some realistic proposals for its implementation. As we think about what the next generation of wallets should look like, AA will surely guide what is possible.

‍

‍

¹Mempool is a buffer that holds data on unconfirmed transactions that have yet to be added to the blockchain.