When venturing into decentralized finance, non-fungible tokens (NFTs), or any type of on-chain activity, the initial hurdle is frequently the acquisition of a wallet. The experience of using an on-chain wallet differs significantly from the norm, and it’s a commonly cited factor that deters potential crypto users.
While these wallets offer users full custody of their assets, they lack security measures inherent in traditional online accounts. Wallet users must also safeguard private keys or seed phrases, which are very different from more well-established features such as two-factor authentication, offered by banks and centralized crypto exchange platforms. Security features like 2FA are currently incompatible with on-chain applications, which could further deter retail users from exploring them.
However, recent cases concerning the likes of FTX, BlockFi, and Celsius suggest that centralized platforms utilizing such features are not necessarily a safe option, strengthening the case for self-custody of assets. To bridge this gap, evolving wallets into account abstraction wallets could introduce a new paradigm that can address current user experience challenges.
The current system
Self-custody wallets can be implemented on-chain in two ways, either through an externally owned account (EOA), or a contract account (CA). Both can send and receive digital assets, and interact with smart contracts. They also exhibit key differences:
Contract accounts are typically used for self-custody in multi-signature wallets, or multisig wallets for short. A typical wallet requires one private key to authorize a transaction, while a multisig wallet requires two or more keys.
Therefore, multisig wallets are more secure but less practical for retail users as they are more complicated to set up than a standard EOA wallet. Needing multiple private keys to verify each transaction, even simple transactions or fund transfers, can be a laborious process. This is also the reason why multisig wallets tend to be used only by companies holding a large volume of crypto assets.
EOA wallets require a signature for every on-chain transaction, while CA wallets do not share the same requirement as transactions are not initiated using keys. For that reason, CAs are not viewed as a viable alternative. Nonetheless, three conditions dictate whether something constitutes an account:
- The wallet must have a balance, which relates to the number of digital assets held.
- The wallet must be able to use nonces, tagging them to transactions to ensure each transaction is unique.
- The wallet must have an address, which is a unique identifier similar to an email address.
Problems with the EOA model
For each EOA wallet, it derives its address from its public key, while authenticating transactions with its private key. This pair of keys is sometimes referred to as the signer. On the other hand, CA wallets do not initiate transactions using keys. This highlights a problem with EOA wallets, since they function both as an account and a signer. Should a user lose the record of the signer, the account is lost altogether. If someone gets a hold of the signer, he or she can authenticate any transactions from the associated wallet, gaining full control over its funds. In other words, the security of EOA wallets hinges entirely on how well users manage their keys. But human error is inevitable, which explains the prevalence of cryptocurrency and NFT hacks taking place.
Is account abstraction the solution?
Account abstraction (AA) refers to the decoupling of the signer from the account. An AA wallet is a smart contract wallet that defines what a valid transaction is, based on predefined and customizable rules. Instead of separating accounts either as EOA or CA, AA amalgamates them. Theoretically, smart contract wallets are usable as standalone wallets, though this is not yet possible as transactions, for now, must originate from an EOA address.
A network-wide change may be necessary to facilitate the implementation of AA. Since 2016, Ethereum co-founder Vitalik Buterin and core developers of Ethereum have been drafting plans for this transformation. These are known as Ethereum Improvement Proposals (EIPs), with the release of their earliest iterations stretching far back to the mid-2010s, suggesting that AA may have been on the minds of Ethereum developers since the dawn of Ethereum.
Following the completion of the merge in September 2022, more resources can be deployed toward AA development. The latest EIP also hints at the imminent introduction of next-generation wallets. EIP-4337, proposed in September 2021, calls for AA to be implemented in Ethereum without making changes to its core protocol. While EIP-4337 is still in draft stage, it can leverage platforms like OpenZeppelin and Stackup to implement the changes without impacting the consensus layer.
The current problem that most wallet users face is the inability to transact if they do not hold the native gas token. For example, if a user has USDT in an Ethereum wallet, but does not own any ETH, transactions cannot be made from that wallet.
EIP-4337 would remove this limitation by adding a new way to handle transactions. If implemented, users can provide some extra information that will be packaged together by a “bundler”. This bundler decides what to include based on fees before sending them for verification. Bundled transactions, upon verification, will be included in the network’s next block, achieving AA without changing how Ethereum works at its core.
This update would benefit application developers who don’t want their users to pay network fees. Users would be able to pay in different tokens directly to a “paymaster” who would subsequently convert it into ETH for compatibility with the network system.
Use cases for account abstraction
Transforming wallets into programmable smart contracts opens the door to implementing new features, analogous to upgrading from a Nokia 3990 to the latest smartphone.
Social recovery
One of the most important benefits of AA wallets is social recovery. In other words, users are protected if they lose their signing key. Instead of using a seed phrase to recover a wallet, which is the typical process for EOA wallets, social recovery adopts a different method. Buterin defines it as using a single signing key to approve transactions, while assigning a set of “guardians” with the authority to change the signing key of the account based on the majority rule. Guardians can be other devices owned by the wallet holder, friends and family members, or specialized institutions that can sign a recovery message upon confirmation of identity using phone numbers, emails, or direct verification (using video calls).
Social recovery enables users to contact the guardians and ask them to authorize a transaction to change the registered signing key to a new one. While some differences exist, this is conceptually similar to the process of regaining access to a Google account if the password is lost.
Gradual improvements in the user experience of wallet applications have made managing account guardians a relatively straightforward process. For example, UniPass, a smart contract wallet that incorporates the social recovery feature, allows users to seamlessly add and remove guardians with the click of a few buttons.
Role-based access control
The 2FA security feature commonly utilized in traditional Web2 applications has, at times, been claimed as a revolutionary feature available in and exclusive to AA wallets. However, implementing this form of 2FA will require multi-party computation (MPC) and an off-chain server. These requirements mean that a fully on-chain implementation of 2FA is not yet possible. On the contrary, since EOA wallets can operate using MPC technology, it is disingenuous to claim that 2FA is unique to AA wallets.
Rather, smart contract wallets can implement a similar type of on-chain functionality by requiring hot wallets to be used as a secondary form of confirmation. This would further safeguard against hacks as phishing attacks will need reconfirmation before assets can be transferred. AA wallets would theoretically enable specific security parameters to be defined based on user preferences. Some examples include:
- Setting a daily transaction limit that can only be overrode using the account’s hardware wallet. This sets a threshold on the financial amount that can be transferred daily.
- Connecting to a database of malicious addresses, enabling automatic prompts for a transaction to be reconfirmed via the account’s hardware wallet when interacting with an address listed on the database.
- Checking OpenSea’s collections and automatically notifying prior to purchasing a non-verified NFT collection. Similarly, a transaction would require reconfirmation via the account’s hardware wallet, to minimize the risk of purchasing a fake or maliciously obtained NFT.
Session keys
Proponents of blockchain gaming say it will be the next big narrative in the Web3 space. However, significant improvements in user experience will be needed for this to come true.
It’s hard to reason why users need to approve multiple functions whenever they want to interact with elements within blockchain games. That is not how traditional games work, and will likely deter adoption due to the unfamiliarity and complexity of the interface.
Session keys can potentially solve this problem. They allow users to pre-approve transactions in applications, including games, based on a set of parameters. These may include a given duration, a maximum amount of gas or transaction volume (of a certain token), or a particular function on a specific contract. Theoretically, users can pre-approve a session with some specified terms, hit go, and play the game without constantly being prompted by their wallet to authorize transactions.
For example, the Ethos Sui Wallet enables pre-approvals for a set number of transactions. In the Sui 8192 game, an on-chain version of the puzzle video game 2048, transactions do not need to be signed for every move made.
Batch transactions
Despite recent advances in blockchain technology, using decentralized applications can at times still be a clunky experience. This stems from the need to create a new transaction for every on-chain interaction. There’s also a cost for every transaction. With an AA account, wallets would theoretically be able to bundle multiple interactions together and execute them at one go as a single transaction.
Potential issues with account abstraction
AA wallets are currently not implemented at the protocol level and instead exist primarily as smart contracts. Some issues arise from this arrangement.
First, there is a cost to deploying the smart contract wallet as it uses blockchain storage. This can be circumvented to a certain extent by using cheaper blockchains or having a transaction relayer to cover this cost. However, the higher gas costs associated with transactions cannot be circumvented. The gas cost for a single transaction is higher when sent through a smart contract wallet as compared to an EOA wallet.
Second, each smart contract wallet needs to be audited before being used to replace EOA wallets. If a widely used smart contract wallet is exploitable, it could create loopholes for mass hacks and exploitation. In 2016, the Parity smart contract wallet suffered a hack costing 150,000 ETH, which is roughly equivalent to USD 180 million in today’s context. That same contract was hacked for another 500,000 ETH (USD 600 million) around three months later.
Security standards have improved markedly in recent years, and most AA wallets have become less complex over time. Incorporating security features like social recovery and role-based access control by default would provide protection against most issues common to smart contracts.
However, there are some security problems tied to the current implementation of AA proposal ERC-4337. The main issue is associated with the high privilege level granted to EntryPoint, which is a contract serving as an entry point for transactions to be bundled. If there’s a security loophole, hackers can easily exploit the wallet. For this reason, some well-established smart contract wallets like Argent have deviated from ERC-4337, and Layer-2 networks are working to implement protocol-wide changes to circumvent security issues associated with ERC-4337.
Layer-2 networks
L2 networks are being built from the ground up to simplify the implementation of changes. StarkWare and zkSync are both L2 networks that have AA natively built in at the protocol level. Unlike Ethereum, both networks do not differentiate between smart contract wallets and EOA wallets, instead classifying both wallet types as one.
Accounts implemented by these L2s can initiate transactions like typical EOA wallets, but can also implement arbitrary logic like a smart contract. They are similar to the design laid out in ERC-4337. With cheaper fees and a simpler wallet creation and management process, L2s could be the perfect medium to onboard the next billion Web3 users.
While it remains unfeasible to use an ERC-4337 wallet on Ethereum, at least for now, some alternatives exist. One example is UniPass, which is building a range of features to bridge this transition. These features largely align with the use cases mentioned above.
Case study: UniPass
For example, when UniPass users initiate transactions, a third party is required to act as a relayer to fulfill it. Relayers can allow users to pay for the gas fee using supported tokens, or pay on behalf of the users. A relayer node will be provided by UniPass to users, enabling acceptance of gas payments both using native tokens and mainstream stablecoins. Applications can also build their own relayers to serve the needs of their user base.
Likewise, UniPass wallets employ an MPC-based design that allows them to be reliant on EOA wallets for security and availability without needing private keys. It also has a unique on-chain verification technique using emails for social recovery. More importantly, UniPass wallets can verify digital signatures issued by DKIM, a standard email authentication method. This is achieved using on-chain smart contracts and enables users to carry out social recovery using only emails, negating a key limitation of other smart contract wallets such as Argent, which allow guardian status to be assigned only to Argent users or Ethereum wallet holders.
Conclusion
As more users gradually switch from centralized custodial-based wallets to self-custody alternatives, EOA wallets must adapt accordingly by transitioning into AA wallets. This would simplify the onboarding process, strengthen wallet security, and improve usability.
While there will still be a need to rely on legacy solutions to relay gas on Layer-1 networks, the likes of Starknet and zkSync are on track to implement AA in its original design. This development could help foster growth on these networks, and the Ethereum community should monitor how this plays out to safely implement EIPs that will make changes to Ethereum’s base protocol.
This article was adapted based on a feature originally written by Robert McTague and published on Amber Labs’ Substack. Amber Labs is the incubation and research arm of digital asset company Amber Group. KrASIA is authorized to adapt and publish its contents.