Account Abstraction Will Evolve Wallets
We must continue to evolve
When someone first decides to plunge into decentralized finance, NFTs, or any other type of on-chain activity, they are hit with the realization that they first need to acquire a wallet. Unfortunately, the experience of using an on-chain wallet is much different than the user experience most people are accustomed to. This is a significant friction point that deters millions of potential crypto users.
While wallets do give the user full custody of their assets, they lack the security safeguards of other online accounts. Users must safely store and protect their private keys/seed phrases or risk losing their digital assets. This is very different from, say, a bank account or even a centralized crypto exchange account. For example, Coinbase and basically every other centralized account lets users enable 2FA to ensure the safety of their assets. This type of functionality is not currently possible with any on-chain solution. The lack of basic security features deters retail users from even touching on-chain applications and causes them to stick to their centralized and custodial wallets. As we have recently observed, this is not necessarily a safer option. The failure of firms such as FTX, BlockFi, and Celsius and the resulting loss of user funds has strengthened the case for maintaining self-custody of your assets. However, retail users need an easy way to do so. How can this current paradigm change? By evolving our wallets into account abstraction wallets, we can solve many user experience issues plaguing us today.
The current system
There are two ways to implement self-custody wallets on-chain: you either need an externally owned account (EOA) or a contract account (CA). Both are capable of sending and receiving digital assets as well as interacting with deployed smart contracts. However, they have some key differences, which are summarized in the below table.
Right now, contract accounts are typically only used for self-custody in the form of a multi-signature wallet, or “multi-sig”. Multi-sigs offer an increase in security but are usually not a practical way for retail users to keep their assets on-chain because they are far more complicated to set up than a normal EOA wallet. Without account abstraction, contract accounts cannot easily be used as the primary method to store digital assets.
There are 3 important conditions that must be met for something to be classified as an “account”. Regardless of being an externally owned account or a contract account, these conditions must be met. An account must have a:
Balance - This represents the number of digital assets within the wallet
Nonce - This ensures that every transaction emitted from the wallet is different
Address - This is a unique identifier for each account on the network
While both types of accounts may look similar on the surface, the biggest difference is that an EOA must sign every on-chain transaction. Contract wallets cannot be used as a proper replacement yet because of this. The user owns an EOA wallet via a pair of keys, a public and private key. This pair of keys is known as the signer. An EOA wallet’s address is derived from the public key, while transactions from the account must be signed with the private key. Contract wallets do not have a pair of keys to initiate transactions. This points to a fatal flaw with externally owned accounts. EOA wallets are both an account and a signer. This leads to headaches and potentially serious problems for users.
Problems with the EOA model.
While it’s disingenuous to say that the current EOA design (which is the standard for wallets today) is fundamentally flawed, it is certainly not in a state that billions of people across the world can use. The main reason for this is that the signer has complete control of the account. If you lose your signer, you lose your account. If someone gets a hold of your signer, they have your account. While this may work to hold a user’s assets under perfect conditions, we do not live in a perfect world. The security of EOA wallets relies entirely on users managing a single private key. There is no safety net; there can be no mistakes. However, people are prone to mistakes, and wallets cannot be this complex if they plan to scale to the masses.
An easy way to see that the current form of self-custody is flawed is to hop on Twitter and search “BAYC Hacked”.
Holders of monkey jpegs are under constant attack due to how difficult self-custody is at the moment.
They get hacked a lot. 100s of Bored Ape Yacht Club NFTs have been stolen, and they continue to be stolen at a fairly frequent rate. This is a clear problem with the user experience of Ethereum. It should not be easy to lose a digital asset worth six figures. We should not expect the next financial system to rely on 12 words written on a piece of paper.
Account abstraction, the solution?
The goal of account abstraction is to decouple the relationship between the signer and the account. An account abstraction wallet is a smart contract wallet that defines what a valid transaction is, according to pre-specified and customizable rules. The goal is to prevent a signer from having absolute and final control over what happens to a wallet’s assets. Instead of having both EOA accounts and contract accounts, account abstraction merges them into one; smart contract wallets will be able to be used as standalone wallets. This is not possible today, as all transactions must originate from an EOA address. However, each new EIP brings us closer and closer to an account abstraction reality.
History of Account Abstraction
To properly implement account abstraction and reduce the need for EOA accounts, it has been long thought that a network-wide change needs to be made. Since 2016, Vitalik and other Ethereum core developers have been drafting solutions for how this change might look. These are summarized below:
EIP-86: Proposed by Vitalik Buterin in 2016, less than a year after Ethereum’s initial release, this EIP introduced the concept of smart contracts as “forwarding contracts” and would only accept transactions coming from an “entry point” address, an address from which anyone could send transactions if they followed a specific format. This required major changes to the Ethereum protocol and was scrapped.
EIP-1014: Proposed by Vitalik Buterin in 2018, this EIP took core ideas from EIP-86 and led to the creation of the CREATE2 opcode. This allows us to predict the address where a contract will be deployed without ever having to actually deploy it. This is important because for a smart contract wallet to function, we must make sure that the smart contract address is the same on all EVM chains, even if it hasn’t been deployed to all of them at the same time.
EIP-2938: Proposed in September 2020 by Vitalik Buterin, Ansgar Dietrichs, and Matt Garnett, this EIP attempted to make new “account abstraction” transactions, requiring the creation of new opcodes. This proved to be too big of a protocol change, with uncertainties about how it would play out. EIP-2938 was scrapped.
EIP-3074: Created in October 2020 by Ansgar Dietrichs and Matt Garnett, this EIP introduced two new opcodes: AUTH and AUTHCALL. When used together, they allow a smart contract to send a transaction on behalf of an EOA. As we have seen with other past EIPs, significant network changes have been unlikely to be approved. EIP-3074 was no exception and faced hesitancy about its security risks, so it was not implemented.
It’s important to note that the timeline of EIPs shows that account abstraction has been in the minds of the core Ethereum developers since the dawn of Ethereum. With the merge completed, more developer resources can finally go into account abstraction. The next EIP finally brings us close to next-gen wallets.
EIP-4337 - Account Abstraction in Ethereum without requiring consensus-layer protocol changes: In September 2021, Vitailk, OpenGSN, and Nethermind proposed EIP-4337 — Account Abstraction via Entry Point Contract Specifications. The EIP attempts to accomplish account abstraction without requiring core protocol changes. This is a huge accomplishment, as protocol changes are what halted most advances so far. EIP-4337 is still in the draft stage and has not been finalized yet, but because EIP-4337 will not change the consensus layer, there are already implementations of it available, including OpenZeppelin and Stackup. The mechanisms of this EIP function can be broken down into three steps:
UserOperations, (which are essentially normal transactions with extra data fields enabling account abstraction features), are sent through a custom mempool
Afterward, UserOperations are packaged into a single transaction via a Bundler. Bundlers would choose which UserOperation objects to include based on fee-prioritization logic, similar to how miners operate in the existing transaction mempool. The bundler (using a service like Flashbots) calls an EntryPoint contract for verification
If there are no errors, the transactions are included in the next block on the network
The EntryPoint contract is a critical piece of infrastructure that is called via the Bundler. This smart contract is called to first verify that the UserOperations follow the pre-specified rules of the account and then execute them. It is important to remember EIP-4337 has no protocol-level changes. This means that Bundler is an EOA address that is submitting all these transactions to the chain. The EntryPoint contract can be extended further by adding a Paymaster. The Paymaster offers a few benefits:
It allows application developers to pay fees on behalf of their users
It allows users to pay fees in ERC20 tokens, with a contract serving as an intermediary to collect the ERC20s and pay for the gas costs in ETH
This is a massive bonus for application developers who don’t want their users to pay network fees. Users will be able to pay in different tokens directly to a ‘paymaster’ – who would then convert it into ETH for system compatibility. This is just one example of a unique use case that account abstraction wallets have over EOA wallets, and there is much more we must talk about.
Use Cases for Account Abstraction
Transforming wallets into programmable smart contracts opens the doors to new functionality. The benefits and new use cases of having an account abstraction wallet are so great it is actually worth migrating to one for most users. It is analogous to upgrading from an old Nokia phone to the latest smartphone.
Smart contract wallets are a major upgrade in terms of features compared to EOA wallets - Source: Argent Wallet on Twitter.
Social Recovery
One of the most important benefits in terms of securing a user’s digital assets, social recovery aims to protect users if they lose their signing key. Imagine if a user’s laptop broke and they had misplaced their physical copy of their private key or seed phrase. In this scenario, with an EOA wallet, all your assets would be lost forever. Instead of using a seed phrase to recover a wallet, social recovery follows a different method. This is Vitalik’s favorite way to secure a wallet, and he defines how it works below:
There is a single "signing key" that can be used to approve transactions
There is a set of "guardians," of which a majority can cooperate to change the signing key of the account
If a user loses or forgets their signing key, the social recovery functionality can be activated. Typically, if I were to lose my signing key, and lose my seed phrase, I would be unable to get access to my account. With social recovery, the user can simply reach out to their guardians and ask them to sign a particular transaction to change the signing key registered in the wallet contract to a new one. Although there are some mechanical differences, this is conceptually similar to what happens when you forget your Google account password and need to regain access to your account.
There are many possible choices for whom to select as a guardian. The three most common options are:
Other devices owned by the wallet holder themselves
Friends and family members
Institutions, which would sign a recovery message if they get a confirmation of your phone number or email, or perhaps in high-value cases verify you personally by video call
Adding new guardians is a reasonably straightforward process.
Screenshot of Unipass wallet’s UI for adding a guardian
The UniPass Wallet is an upcoming smart contract wallet with social recovery as one of its main features. The UniPass Wallet includes an interface by which guardians can be added and removed seamlessly.
Role-based access control
For many traditional “web2” applications, users are required to enable 2-factor authentication (2FA) by the platform's developers. This automatically prevents a large number of hacks from happening.
It is worth noting that many other articles will claim that multi-factor or 2-factor authentication via SMS or email address is a new feature unlocked by having an account abstract wallet. Implementing this form of 2FA usually leverages Multi-Party Computation (MPC) and an off-chain server. There has yet to be a purely on-chain implementation. But since it is powered by MPC technology, it could also be implemented by just using an EOA wallet. It is disingenuous to say that it is unique to account abstraction wallets.
However, smart contract wallets can implement a similar type of functionality on-chain by requiring your hot wallet to be used as a form of secondary confirmation. This automatically prevents a large number of hacks from happening, as even if you are phished you may still need confirmation to move your assets. Account abstraction wallets let you define specific security parameters according to your preferences. Examples of this could include:
Setting a daily transaction limit which specifies a monetary threshold on what can be sent per day unless you confirm via your hardware wallet. This would prevent your wallet from being drained all at once.
Connecting to a database of well-known “scam” addresses, which would immediately prompt you to confirm a transaction via your hardware wallet if an address you are interacting with is stored in the database.
Checking Opensea collections and letting you know that you are purchasing a non-verified NFT collection and prompting you to confirm via your hardware wallet, preventing confusion about buying a fake/malicious NFT.
Most importantly, all these features provide a multi-layered safety net when performing on-chain interactions. Most users have no idea what they are signing or approving. Right now, we operate on a system where one misclick can deplete your wallet’s balance instantly, and this needs to change.
Session keys
Many think blockchain gaming will be the next big narrative in web3. For this to take place, there needs to be a better user experience than what currently exists. It makes no sense that a user should have to approve multiple functions whenever they want to interact with something in the game they are playing. This is not how traditional games work and will deter people due to the unfamiliarity and clumsiness of the interface. Session keys allow users to pre-approve an application's transactions according to a set of parameters: a given duration, a max amount of gas, a max transaction volume of a certain token, or a particular function on a particular contract. A user would be able to pre-approve their session with some basic terms, hit go, and play the game without constantly being bombarded by their wallet asking, “confirm this transaction”.
Batch transactions
Right now, if I wanted to use a decentralized application, I would need to make a new transaction for every on-chain interaction. This is annoying and can also be expensive, as each approved interaction costs money. With an account abstraction account, wallets can bundle multiple transactions together and execute them as one transaction.
This radically simplifies the user experience. Complex transactions and yield farming opportunities can be simplified to require only one click of a button.
Other use cases
The list of features an account abstraction wallet can support is limitless. Because account abstraction wallets are smart contracts, wallet developers can constantly update them with new features and utility. We can even expect third-party plug-ins for wallets. However, this brings me to my next point: the flaws of account abstraction wallets today.
Potential issues with account abstraction
Account abstraction wallets are currently not implemented at the protocol level and currently only exist as smart contracts, with gas being relayed in creative ways. Because these wallets are smart contracts, some issues arise. First, there is a cost to deploy the smart contract wallet, as it uses blockchain storage. This can be circumvented currently by using cheaper chains or by having a relayer cover this cost. However, this does not really circumvent the higher gas costs of submitting a transaction. The gas cost for a single transaction sent via a smart contract wallet is more expensive than sending via an EOA wallet. While this one day could be improved with proper batching of transactions, we are not at that point yet. A second, more important issue is that each wallet needs to be audited before it is used as a replacement for EOAs. If a widely-used smart contract wallet has an exploit, it could be one of the largest hacks of all time. This isn’t just hypothetical, as smart contracts wallets have been hacked before. In 2017, the Parity smart contract wallet saw a hack of 150,000 ETH (valued at 180 million USD today). Three months later, that same smart contract was hacked for another 500,000 ETH (valued at 600 million USD today). Luckily, we have improved our security standards since 2017, and most of what account abstraction wallets currently try to accomplish isn’t unreasonably complex. Security features like social recovery and role-based access control are also built-in by default, which provides a level of protection from any issues in the smart contract itself. However, even with these features, there are still security problems with the current implementation of ERC-4337. The biggest issue is the extremely high privilege that the EntryPoint contract has. If this smart contract has security issues, hackers would be able to exploit any ERC-4337 contract wallet through it.
In addition to security issues, the infrastructure to properly support ERC-4337 is not there completely. The current implementation of ERC-4337 heavily relies on Flashbots. Flashbots is vital to account abstraction, as it packages up a set of UserOperation objects into a single “bundle transaction”, which then gets included in an Ethereum block. Flashbots is specific to Ethereum itself, bringing into question how ERC-4337 wallets could be compatible with other EVM chains. While the contract wallet could be deployed onto another chain, without a comparable mechanism to Flashbots for bundling transactions, the wallet would not be functional. Lastly, smart contract wallets can only interact with decentralized applications that have implemented EIP-1271, which is called to verify signatures from contract wallets. Theoretically, if Opensea or any other decentralized application has not yet implemented EIP-1271, the smart contract wallet will not be able to interact with the application and will be rendered useless.
Established smart contract wallets like Argent didn’t just deviate from ERC-4337 for no reason. Layer 2 networks are working with clean slates to implement protocol-wide changes to circumvent issues raised by ERC-4337.
Layer 2s
Layer 2s are building their networks from the ground up and can more easily implement changes, as they are starting with a cleaner slate, in terms of technical debt. Zksync and Starkware are both Layer 2 networks that have natively built-in account abstraction at the protocol level. Unlike Ethereum, Zksync and Starkware make no distinction between smart contracts and EOAs, and the two types of wallets are merged as one. Layer 2s have achieved true account abstraction beyond what any EIP has successfully implemented thus far. These accounts can initiate transactions, like an EOA, but can also have arbitrary logic implemented in them, like a smart contract. These designs are very similar to the design laid out by EIP-4337. With cheaper fees and the simplification of creating and maintaining a wallet, layer 2s may be the perfect place to onboard the next billion web3 users. In the meantime, however, what if we wanted to use an EIP-4337 wallet on Ethereum? What is the best wallet to do so?
UniPass, an Account Abstraction wallet
While Argent wallet (an amazing account abstraction wallet) is focusing on layer 2s like Starknet, it is important that we see implementations on layer 1s such as Ethereum. UniPass is an account abstraction wallet building a range of features that set it apart from the competition, including both EOA wallets and other account abstraction wallets. When UniPass users initiate a transaction, a third party is required to act as a relayer to fulfill it. In this process, the relayer can allow users to spend arbitrary supported tokens to pay for the gas fee, or even pay the gas fee for the users, thus achieving a gasless user experience. UniPass will provide a default UniPass Relayer Node that you can use out of the box. In the beginning, UniPass Relayer will accept gas payments in the form of its native token and mainstream stablecoins. Additionally, applications can build their own customer relayer to meet the needs of their user base.
Other smart contract wallet solutions often rely on EOA wallets for private key management. UniPass Wallet uses an MPC-based Threshold Signature Scheme (TSS), which allows it to be reliant on EOA wallets for security and availability while also completely avoiding private keys, the largest single point of failure, throughout the entire user journey. This creates a seamless user experience that is both delightful and secure for the users.
Creating a wallet is as simple as logging in with your Google Account
UniPass also has a unique on-chain email-based verification technique for social recovery. Email protocols (POP3, SMTP, and IMAP), have existed for more than 50 years already, and are a foundational piece of the modern internet. In order to protect emails from malicious modification, DomainKeys Identified Mail (DKIM) was introduced in 2004. DKIM is a standardized identity verification technique for email. Senders are able to add a digital signature to outgoing emails. When an email server receives signed emails, it can verify whether the email is coming from the actual sender and whether the content is modified.
After endless research, UniPass Wallet can now verify DKIM’s digital signature using smart contracts on-chain. This allows users to manage their non-custodial contract accounts and carry out social recovery using only emails. Typical smart contract wallets’ social recovery solutions, like Argent’s, require guardians to be users of Argent or to have an Ethereum wallet already. This means that if your trusted family members and friends are not web3 users, they cannot act as your account’s guardians. With UniPass’s architecture, users can set multiple email addresses as guardians of the account, which can help users set up account recovery by simply submitting emails to a smart contract on-chain. This greatly lowers barriers for guardians and allows all your family members and friends with emails to become guardians of your account.
However, one question arises: how can UniPass keep all this information private? It would not be good if an email address tied to your account is visible to everyone on-chain. As such, UniPass Wallet uses zero-knowledge technology to completely anonymize users’ private information on-chain, achieving decentralized verification while protecting users’ privacy.
Closing Thoughts
With the collapse of major centralized custodial wallet solutions, many users are flocking toward self-custody wallet solutions. EOA wallets must evolve into account abstraction wallets to scale to the next billion users. They make the onboarding process more accessible, strengthen security, and dramatically improve usability. While we still need to rely on solutions to relay gas in creative ways on layer 1s, layer 2s such as Starknet and Zksync will implement account abstraction in its most pure form. This material UX improvement could easily help foster growth on these networks. The Ethereum community must watch how this plays out closely to safely implement EIPs that change Ethereum’s base protocol. Regardless, there are still wallets, such as UniPass, taking the lead and creating advanced wallets with EIP-4337. I look forward to the day when these solutions become widely used and we wonder how we used to store our digital assets in such an archaic way.
Author
Robert McTague is an Investment Associate for Amber Group's Eco Fund, the company's early-stage crypto venture fund. He hopes that as we integrate account abstraction, blockchain technology will scale to the next billion users. Special thanks to George Zhang (UniPass) for helping us understand all of the finer details of account abstraction.
Disclaimer
Amber has invested in UniPass. The information contained in this post (the “Information”) has been prepared solely for informational purposes, is in summary form, and does not purport to be complete. The Information is not, and is not intended to be, an offer to sell, or a solicitation of an offer to purchase, any securities. The Information does not provide and should not be treated as giving investment advice. The Information does not take into account specific investment objectives, financial situation or the particular needs of any prospective investor. No representation or warranty is made, expressed or implied, with respect to the fairness, correctness, accuracy, reasonableness or completeness of the Information. We do not undertake to update the Information. It should not be regarded by prospective investors as a substitute for the exercise of their own judgment or research. Prospective investors should consult with their own legal, regulatory, tax, business, investment, financial and accounting advisers to the extent that they deem it necessary, and make any investment decisions based upon their own judgment and advice from such advisers as they deem necessary and not upon any view expressed herein.