Layer 2s mean we can enjoy cheap and fast transactions on a global scale. The question now is how can we improve user experience (UX) and security to achieve the mass adoption of crypto.
We at Argent believe Account Abstraction (AA) is the answer.
This post - the second in a series called ‘WTF is AA?’ (see here for Part 1) - covers the past attempts to introduce AA to Ethereum Layer 1. I explain why they've struggled to be implemented and what their weaknesses are. Then I end this blog by arguing that Layer 2 gives us the perfect opportunity to create the user experience we’ve all dreamed about from the start.
WTF is Account Abstraction and why does it matter?
As I wrote in my last post, Ethereum has two types of account - Externally Owned Accounts (EOAs) and contract accounts. There are severe limitations to this model.
Many issues with self-custody today stem from the hard coded authorisation logic at the core of the Ethereum Virtual Machine (EVM). There is a tight coupling between the account holding a user’s tokens and the signer authorized to move these tokens. For example, on Ethereum, the signature scheme is ECDSA, and the elliptic curve is secp256k1. And there is no way around that.
So how does AA solve these problems?
AA breaks the account coupling and makes the authorization of a transaction programmable by turning every account into a smart contract. With AA, every user can deploy and use an account with custom authorization logic tailored to their need.
Why does this matter? Just a few reasons include:
- Multiple signers so you can support fraud monitoring. Inspect every transaction to make sure it complies to defined security rules, and prevent users from sending assets to a scam address or incorrect contract.
- A different signature scheme with a different elliptic curve. Change the signature scheme to simpler, more gas efficient ones, or quantum-resistant ones. Or even use the secure enclave of iOS and Android devices to turn every phone into a hardware wallet.
- Social recovery. In case a user's private key is lost or compromised, AA allows wallets to add mechanisms to securely replace the key controlling the account. Never worry about seed phrases again!
Of course, this only covers the surface of what AA enables, but the possibilities are endless.
But if AA really will bring crypto to the masses, we first need to dive into why Ethereum doesn’t support it yet.
Why doesn’t Ethereum already support Account Abstraction?
Implementing full Account Abstraction on Ethereum is no easy task as it requires multiple changes to the very heart of the protocol. Changes that are increasingly harder to coordinate and implement as the value secured by Ethereum increases.
This is why, despite being discussed in 2016 and an Ethereum Improvement Proposal (EIP) initially proposed in 2017, AA is still not yet implemented on Ethereum today. This has had all the dramatic consequences that we’ve been forced to accept: a terrible user experience on Ethereum, where seed phrases continue to plague everyone.
Since 2016 several approaches have been proposed to bring some of the features of AA while requiring acceptable changes to the protocol. Acceptable in the sense that the changes are small enough that they could be accepted in the next fork of the protocol.
Each of these weaker forms of AA have their own limitations, and, notably, none of them have received wide adoption yet. This is one of the reasons why we are pushing for the widespread adoption of AA on L2s.
Before going into more detail on the various EIPs related to AA, it’s worth covering smart contract wallets. They’re not formal propositions for AA, but they are a great way to emulate AA's benefits without requiring any protocol changes.
Smart contract wallets and Account Abstraction
Most wallets on Ethereum are Externally Owned Accounts. MetaMask is one example. They rely on seed phrases, and you can’t program any UX or security improvements into them.
Smart contract wallets, on the other hand, can be programmed with custom code to authorize transactions and unlock user experiences that are impossible with native EOAs: For example, at Argent, we’ve pioneered features often cited together with Account Abstraction, such as social recovery, multicall, or on-chain fraud monitoring. These provide significant usability and security upgrades to users, whether beginner or advanced.
The problem is that smart contract wallets still live on a chain where the native account is the EOA. This has 2 main consequences:
- Smart contract wallets on L1 must use various tricks and build custom infrastructure to emulate AA properly. For example, you need to use off-chain servers, called relayers, to subsidize the transaction fees required to execute transactions on a smart contract wallet.
- The entire Ethereum ecosystem is built around EOAs, making smart contract wallets second-class citizens. Little is needed to support smart contract wallets out of the box, but because it is generally an afterthought, many Dapps are incompatible with smart contract wallets.
There have been attempts to address some of these compatibility issues, but they each have trade-offs.
EIP2938
EIP2938 was proposed in 2020 as a restricted form of Account Abstraction with the aim to enable smart contracts to act as top-level accounts (accounts that can initiate transactions and pay for gas fees).
It does so by introducing a new AA transaction type and 2 new opcodes (plus some other minor changes). It was designed to be fairly simple to implement while allowing new and more powerful features to be developed in the future.
The new AA transaction type only contains 3 fields { nonce, target, data } where target is the AA smart contract containing the logic to validate the transaction, and data encapsulates all the parameters of the transaction that must be validated and executed by the AA contract such as the contract to call, the payload to pass, the max transaction fees and the signature(s).
Due to its relative simplicity, EIP2938 does not support some of the expected features of AA, such as nonce abstraction, the ability to use proxy contracts, or the support of so-called meta transactions.
More importantly, EIP2938 does not replace or remove EOAs.
EIP3074
EIP3074 was introduced soon after EIP2938 and took essentially the opposite approach. Instead of enabling smart contracts to act as top-level accounts, it tries to make existing EOA accounts behave more like smart contracts by allowing users to delegate control of their EOA to a contract.
This delegation is achieved by asking users to sign a message with their EOA. Then, using that signed message and 2 new opcodes (AUTH and AUTHCAL), the target smart contract called an invoker can send transactions as if it was the EOA itself.
The leading motivation for EIP3074 is to enable existing users of EOA wallets to benefit from some of the features of AA without having to create new (smart contract) accounts or transfer their assets. In particular, its main focus is the ability to sponsor transactions for users or execute multicalls.
While this approach offers flexibility, it also comes with security tradeoffs which is why several members of the ecosystem have voiced their concerns. For example, under EIP3074, users are still expected to back up their seed phrase, which we know is a security nightmare and isn't how we bring the masses to crypto.
Smart contract wallets are a significant upgrade from EOAs.
Improving EOAs is like trying to modernise with faster horses. Where what the world actually needs is cars.
EIP4337
EIP4337 is the most recent proposition on our collective journey towards Account Abstraction, and it can be seen as an evolution of smart contract wallets. At a high level, it makes writing and operating smart contract wallets on Ethereum much simpler by mutualizing some of the on-chain and off-chain infrastructure required.
With EIP4337, users no longer make transactions. Instead, they send UserOperations to a higher level mempool. Miners or bundlers can package up a set of UserOperation into a bundle transaction that is sent to the EntryPoint contract for execution. The EntryPoint contract orchestrates the correct execution of the operations and makes sure the miner/bundler is properly compensated for the transaction fee.
Using EIP4337, any developer can write custom smart contract wallets with few lines of code and not have to care about how to subsidize transaction fees.
Like smart contract wallets, EIP4337 was designed to emulate AA without requiring any change to the protocol. But like smart contract wallets, EIP4337 does not get rid of EOAs, and wallets built on top of EIP4337 remain second-class citizens on Ethereum.
Will Account Abstraction ever get implemented on Ethereum?
So while Ethereum’s early developers always meant to implement full Account Abstraction to enhance UX and security, we can see that it’s been repeatedly pushed back in favour of more urgent changes.
So will AA get implemented now that the Merge has succeeded?
No one knows, but I certainly hope so because I’m convinced it is the only way to scale the much-needed user experience around self-custody.
What I also know is that this history of different designs for AA is a solid foundation as the ecosystem is gradually moving to L2s. For example, both StarkNet and zkSync are launching with native account abstraction, and their design is heavily inspired by EIP4337, which I consider the best proposal.
The endgame is eliminating one of the biggest threats to mainstream adoption of self-custody - EOAs. Ordinary users should never handle key management, and if Ethereum doesn’t transition away from EOAs we’ll live in a world where only the few self-custody and the rest use centralized exchanges. This is not the future I’m hoping for and it’s why I co-founded Argent. But it needs to be simple, and EIP4337 brings us closer to achieving that.
Hopefully, we’ll see more L2s support a variation of this so that even more users get to experience the significant improvements that come from AA. Only then will it be easier to convince the broader Ethereum community to support change at the protocol level, and for the dream of AA on Ethereum to finally become a reality.
In the final part of this series on WTF is AA, I will discuss some concrete examples of unique AA features that we’re excited about and building on StarkNet and zkSync.
