×
☰
In this post, we’ll explore the issues with UX in the current web3 landscape, and dive deeper into how a proposal known as account abstraction provides a potential solution to several of the biggest problems we have today.
The reality is, a poor UX is a significant drawback to building your application in a decentralized manner. While there are many solutions actively being worked on to address the issues, account abstraction is arguably the most promising.
It’s an exciting paradigm that will allow anybody to interact with dapps; not just web3 enthusiasts, and is coming to reality with the latest Ethereum Improvement Proposal EIP-4337.
Let’s dive into it!
Let’s get through the boring stuff first. To understand account abstraction, we first need to understand what an account actually is when talking about Ethereum.
Ethereum has two different types of “accounts”:
You can think of a contract account as code (smart contracts) living on the blockchain that defines how the account behaves, and think of EOAs as a person (although a person could have many EOAs).
You probably are already familiar with EOAs. Your MetaMask wallet is an EOA. EOAs are made up of a cryptographic pair of keys: public and private keys that control account activities.
Contract accounts, however, don’t have a private key. They’re smart contracts that are controlled by the logic of the code within them; they’re not controlled by a user.
The key takeaway here is that code defines what contract accounts do, and users control what EOAs do. This matters because smart contracts have the capability to do anything you can write in code, whereas EOAs can basically just sign transactions.
Alright, so that’s accounts. What about transactions?
Every time you want to write information to the blockchain, such as transfer tokens, or mint an NFT, a transaction needs to occur. Transactions need to be signed by an EOA, and an EOA also has to pay the associated gas fees.
A transaction is initiated by an EOA, and can be sent to either:
Performing actions on the blockchain today is typically slow and tedious. Every time you want to write new information to the blockchain, you sign a transaction from your EOA to do so.
Once you’re familiar with the process, this becomes the standard experience.
For new users, however, it’s a nightmare.
The process of starting from scratch and interacting with a web3 application for the very first time is enough to put anyone off from entering the space, and that’s just the beginning.
Here’s a step-by-step experience that a new user goes through to perform their first action on a decentralized application from a fresh EOA:
This experience is brutal for any new user, tech-savvy or not. But it doesn’t stop there, the initial setup is just the beginning of the user’s concerns when using EOAs.
You’re likely already familiar with somebody you know losing access to their EOA by either accidentally sharing or losing access to their private key. Some examples:
The level of responsibility you have with traditional EOAs is dangerously high.
There’s even a saying for it: “not your keys, not your crypto”; referring to the fact that if somebody else ever has your private key at any point (such as a centralized exchange), they have the power to control your funds; this point has been proven countless times in the past.
The harsh reality is that private keys are easy to lose and impossible to recover.
As we touched on earlier, EOAs are very limited in their capabilities.
From your EOA, you’re usually performing one of two typical actions:
Whoever has the private key can sign messages and initiate any transactions the EOA can handle. Knowing the private key of an EOA gives you the power to perform everything that an EOA is capable of. It’s all or nothing.
In the real world, losing your credit card doesn’t mean you are completely doomed.
There are rules in place that allow you to do things like set payment limits, stop transactions, detect fraud, change funds to a new account, only allow funds to be transferred under certain conditions, etc.
In web3, if you make one mistake, your entire account is compromised and unrecoverable. EOAs even compared to centralized stores of currency is… š©.
We’ve dunked on EOAs enough, let’s finally discuss the solution.
Account abstraction is the proposal to allow users to use smart contract wallets instead of EOAs. This completely removes any need for users to use EOAs in order to perform transactions.
But why? What do contract accounts do that EOAs can’t?
Smart contracts are infinitely more flexible in their capabilities than EOAs. Each smart contract can define different rules and configurations within its code.
Some examples of use cases can be seen below:
| Use Case | EOAs | Contract Accounts |
| Permission controls | Private key grants full access to everything. | Define a list of tiered permission levels. e.g. Require 3 out of 5 signers to approve a transaction. |
| Batch transactions | Each individual action requires a separate signature. | Capable of batching transactions together; e.g. approving a token transfer and transferring a token in the same operation. |
| Account Recovery | Loss or exposure of private key means full loss of control over the wallet. | There is no private key. You can write any arbitrary logic in code that allows you to recover the funds in the wallet. |
| Transaction limits | Any transaction your wallet signs is what occurs. You cannot restrict anything. | Write any logic to control how funds can be transferred. E.g. a function to halt transactions to other addresses while you recover your account. |
These are just a few of the capabilities that contract accounts offer over traditional EOAs. The key thing is; contract accounts are code.
This means anything you can write in code is therefore possible in a contract account.
Okay, this sounds great. Why aren’t we already doing this today? Before we answer that, let’s quickly give a brief overview of the history of account abstraction proposals dating back to 2016, and explore why EIP-4337 is different.
2016: EIP-86 – Proposal allowing users to create “account contracts” that perform any desired signature/nonce checks instead of using the mechanism that is currently hard-coded into transaction processing.
2020: EIP-2938 – Proposal to create a new transaction with type AA_TX_TYPE. Transactions of this type are referred to as āAA transactionsā.
2020: EIP-3074 – Proposal allowing users to delegate control of their EOA to a smart contract. Would allow any EOA to act like a smart contract wallet without deploying a contract.
None of these proposals have been merged into Ethereum. They are all currently in the “stagnant” category; meaning they have been inactive for a period of 6 months or greater.
Part of the reason for these proposals not being merged is that they require consensus-layer protocol changes to the Ethereum network.
Until 2021, when EIP-4337 was proposed; account abstraction on Ethereum without a consensus layer change required!
EIP-4337 introduces a “pseudo-transaction” object called a UserOperation; a structure that describes a transaction to be sent on behalf of a user.
User Operations go into an “alt mempool”; which is essentially a waiting room for storing information on unconfirmed transactions.
Nodes on the Ethereum network can choose to act as a “bundler”. Bundlers pick up user operations from the mempool, and package multiple user operations into a single transaction known as a “bundle transaction”.
Once they create a bundle transaction, they send it to a global “singleton” smart contract known as the “EntryPoint”. There is only one EntryPoint smart contract on the entire blockchain. The bundler calls a function on the EntryPoint smart contract called handleOps.
This function receives the bundle transaction, and calls a special function on each account: `validateUserOp` . Each smart contract wallet must implement this function.
`validateUserOp` should verify the operationās signature, and pay the fee if the account considers the operation valid, before continuing to execute the operation.
Each smart contract wallet also must implement a second function: expected to be called “execute” to actually perform the operation that is sent in by the EntryPoint contract.
A simplified flow of this can be seen below:
Contract accounts are the next evolution of wallets required to provide a much-needed improvement to the UX of web3.
The possibilities are really endless for what this change enables:
A grandma could be collecting NFTs and not even know what the blockchain is. Account abstraction enables everybody to use web3; not just tech enthusiasts.
In this post, we’ve outlined:
Account abstraction is a game changer for web3 and bringing decentralized applications to a mainstream audience.
The power to use smart contracts as your wallet brings endless possibilities and EIP-4337 is the latest proposal of account abstraction that doesn’t require a consensus-layer change.
Source: Jarrod Watts
Blogs
