Self-custody management of crypto can be a daunting task for both new and experienced users alike. Private key management often poses a significant challenge, and incidents like FTX mishandling customer funds have made many retail users reluctant to store large sums on shady and unregulated exchanges.
In the realm of web3, the terms "wallets" and "accounts" play crucial roles, but their interchangeable usage often leads to confusion. This issue is further exacerbated by the fact that many leading wallet applications lack user-friendly interfaces that clearly distinguish between the functions of wallets and accounts. Crypto wallets are responsible for storing ERC-20s / ERC-721s / ERC-1155s and to leverage their utility for buying, selling, and interacting with dApps for authentication or identity verification purposes. Each wallet contains a private key essential for its operation - while this key enables wallet access from multiple locations, it does not synchronise the interactions across those access points. Relying exclusively on a private key also introduces a central point of failure, making it a significant security risk.
The absence of user-friendly tools, along with the inherent difficulty in comprehending their safe and secure usage, makes it hard for people to onboard and use blockchain-based dApps. This lack of trust perpetuates a cycle in which users struggle to fully embrace the potential of crypto due to its inherent complexity.
<aside> ⚡ This is where Account Abstraction (AA) comes in, promising to solve the dilemma between key management UX and security for self-custodial funds by enabling arbitrary logic to determine if an account can move funds or interact with any Smart Contract (SC).
</aside>
To understand account abstraction we first need to understand how accounts work on Ethereum today.
There are two types of accounts on Ethereum:
👛 EOAs have three properties:
The state of the blockchain can only be modified through transactions. This trigger must come from something external to the blockchain, hence, every transaction must be initiated by an EOA meaning that when a transaction is executed by the Ethereum Virtual Machine (EVM) the first account being touched must be an EOA and the corresponding account must pay a fee to the miner for the execution of the entire transaction. To assert its validity and to prove account ownership, every EOA has an associated with a cryptographic object called a signer, also called keypair, is made of two keys: a private key and a public key. The private key or the secret, can be used to sign digital message whereas the public key can enable anyone to verify that a given signature was signed by its corresponding private key.
Figure 1 - EOA wallet’s transaction lifecycle, by Frontier Research.
As the usage of Ethereum grew, developers grew frustrated at the limitations of EOA wallets and started creating wallets with more advanced access control. Contract Accounts, also commonly known as Smart Contracts (SC), are a tad different from EOAs since code written on the EVM controls their activities. The sometimes immutable code will define the nature of transactions the contract account can complete which means that CAs do not initiate transactions, unlike their EOA counterparts - instead, they can only send transactions in response to a transaction received.
Figure 2 - SC wallet’s transaction lifecycle, by Frontier Research.
Since User Operations cannot be directly submitted to the blockchain, a relayer or an external wallet is required to initiate the transaction. The constraints, imposed by the consensus layer and legacy dApps, are maintained in the above flow, however, it increases the transaction cost.****
But is there a better solution? Thankfully, yes. The new advancements rolled out in ERC-4337, an out-of-protocol meta-transaction standard that enables a form of Account Abstraction, allows any EOA wallet to interact with the network by initiating a transaction containing any User Operation, i.e. it guarantees that the initiator EOA wallet - called Blunder - will be paid back for the transaction fees by the User Operation.
Figure 3 - Improved transaction flow with AA.
This is achieved by splitting a User Operation into 2 sandboxed steps. A validation step, to check if the User Operation can move funds, and an execution step that performs the dApp interaction.
Bundlers only need to verify if the validation step will succeed, to gain confidence that they will be paid for including this User Operation in their transaction. One challenge with stateful AA is that a UserOp might be valid at one block and invalid at the following block.****