You must have been seeing a lot of account abstraction posts on the TL lately. The account abstraction concept is not entirely new as the founder of Ethereum Vitalik, wanted to include it but did not have the time. Account abstraction through ERC-4337 is simply a blockchain technology that allows users to use smart contracts as their accounts. We must consider the two kinds of accounts we have on Ethereum first, and they are:
Externally Owned Accounts (EOAs)
Smart Contracts Accounts
Externally Owned Accounts:
They are the typical kind of accounts most of us have or are introduced to in web3. These accounts are controlled by private keys and managed by wallets. They are used to sign transactions and messages on the blockchain. One disadvantage of the EOA is that, if their private keys are compromised the entire account is not safe, can be drained, and the owner might not be able to do anything about it, you can only transfer your assets out of the wallet to a new one.
Smart Contracts Accounts:
On the other hand, smart contract accounts are not linked to private keys instead, are deployed to the network and run autonomously. Smart contract accounts are controlled by codes.
A lot of users have been interacting on the blockchain using externally owned accounts, and this has resulted in several challenges:
Hard To Manage Keys:
Managing Private keys and seed phrases is more difficult than you think it is. I have seen people forget their phone passwords and passwords to their socials as well. To think that these passwords are less complex than private keys and seed phrases, hence memorizing private keys is not a solution for a lot of persons, myself inclusive.
This is the reason why a lot of people opt for custodian wallets where someone else owns the private key of the address where you store your money, in this case, the assets on that address are not truly yours we saw that with the case of FTX.
Not So Great UX:
One of the challenges of EOAs is that they result in a bad user experience. In smart contracts today, we can write a function that makes a call to another function in external smart contracts.
A typical example of what this means is the approve and transfer function, this results in a user having to do two transactions just to make a simple swap on Uniswap. This destroys the experience of trading, imagine trying to get into a degen trade before a lot of persons do, you first have to approve before you can eventually swap.
Limit To Control:
EOAs have no limited access or control. What do I mean? anyone who has the private key of your wallet can control anything and everything about the wallet, there are no restrictions.
Account Abstraction is what we have today to solve those challenges and somewhat redefine what we know as an "account" in web3.
Account Abstraction
Account abstraction considers each account to be a smart contract instead of an EOA. The smart contract contains logic that can be customized depending on how it's set up.
One of the best innovations in account abstraction is the ability to separate signer from the account itself. This means you can now sign messages without necessarily having access to the account itself. This now brings about a lot of possibilities like, we can have multiple signers for an account now.
To access these smart contract accounts, we would utilize some sort of smart contract wallet. For example, Soul Wallet, and Argent are smart contract wallets that come with certain smart contract account implementations built in.
Use Cases For ERC4337:
One of the first use cases I am excited about is Transaction Batching, since our account is now a smart contract we can execute multiple function calls in a single transaction. Like I mentioned earlier regarding approving two transactions just to swap both approve and transfer functions. We now get to approve and transfer in a single function call from our smart contract account. I only need to make one transaction and this would significantly improve the user experience.
Our accounts can now define certain custom rules on what counts as a "valid" transaction and a "valid" signature by the signer. Your account can simply define a list of public keys related to all the signers, for example, and then not consider a signature valid until you have received signatures from all of them (or a majority subset, perhaps) before which it will not agree to execute the transaction. We can create whitelists that only allow transactions to certain addresses that you know to be safe. This means that even if your private key was stolen, the attacker could not send funds to non-whitelisted destination accounts. These whitelists would require multiple signatures to change them so that an attacker couldn't add their own address to the list unless they had access to several of your backups.
Pay gas fees without necessarily using the native token. Gas management is also much improved with account abstraction, gas fees can be paid in tokens other than ETH, freeing users from having to maintain an ETH balance for funding transactions. This would work by swapping the user's tokens for ETH inside the contract and then using the ETH to pay for gas. Applications can also offer to pay their users gas fees for example Opensea can decide to pay the gas fees for their top 100 users every month.
Resources
Connect with me on Twitter | Linkedin | GitHub
Thank you for reading