Account Abstraction Demystified
Since you clicked on this article, you have likely been on a quest to understand Account Abstraction (EIP-4337). By now, you’re familiar with its advantages and the five roles, and you’ve probably read Vitalik's posts. While it all sounds great in theory, you might be feeling confused about how it solves the big UX problems of Web3.
The main thing to understand is that Account Abstraction(AA) was not created to solve a particular problem but as an exercise to separate transaction verification from execution. In other words, the requirement was to generalise signature verification, hoping the extra flexibility would unlock the creation of better wallets.
On the other hand, outside the protocol developer circles, everyone expects AA to be the miracle solution that will help onboard the next billion users to Web3. In this article, I will try to bridge this gap.
The Web3 Challenge — User Experience
The elephant in the room for Web3 adoption is most likely UX: the seed phrases, the unforgiving security, the clicks and the transparency.
It is not surprising, then, that AA is expected to help developers solve many of these problems.
The reality is that EIP-4337 is a standard that can be applied top-of-stack (like ERC-20). It encourages reusable tooling and, possibly, easier solution composition. It does not enable anything that wasn’t possible before.
Any breakthroughs resulting from its widespread adoption will most likely be from various unexpected combinations of solutions and not from a new feature.
This article will discuss UX improvements that seem like a natural fit for AA.
The on-chain game
All games need a smooth user experience, and having to click a few times in a different window for every move is pretty far from that. The issue is that Ethereum and compatible chains require that every transaction is signed by an "externally owned account" (EOA), and the wallets that control the keys are external to the game.
Our task is to design a secure, decentralised solution for executing the game moves on-chain in real-time without the user having to click to sign each one.
The simple solution — Session Keys managed by the game
The straightforward solution is for the game engine running in the browser or the phone (GE) to generate a volatile key pair behind the scenes and ask the user to transfer some ETH from their main account to this volatile account. We can think about this key pair as a session key (SK) with an on-chain balance.
While playing, the game engine generates a transaction for every move, signs it with the SK behind the scenes, and submits it to the network.
When the game ends, the GE will transfer the remaining balance and the winnings to the main account.
This is a reasonable solution, especially if the game runs on a cheap L2 and the amounts involved are fractions of a dollar. The main disadvantage is that the SK can disappear if the browser crashes, and the ETH it controls can be lost.
To summarise the User Experience: Alice visits an on-chain game website and registers to play by connecting her wallet and signing a transaction that transfers a small amount of ETH from her account to prepay for moves. Then, she can play the game and make moves as in any Web2 game.
Applying EIP-4337
In this section, we'll achieve the same functionality but fix the minor issue of potentially lost funds. You'll notice how the complexity increases.
In a nutshell, we keep the Session Key approach but no longer transfer funds to it. The funds and the public key will be submitted to a smart contract. The game moves will not be standalone transactions. Instead, they will be payloads signed with the SK. In EIP-4337 terminology, they will be "User Operations" (UO).
Since we no longer have transactions but still need to execute the moves on-chain in real-time, we need a "Bundler" to create, submit, and pay for the transactions containing the UOs.
On-chain, we'll have three smart contracts: the "Entry point," the "Smart Wallet," and the actual "Game Smart Contract."
The "Entry Point" is the contract called by the bundler, which unpacks the UOs and authenticates them with the "Smart Wallet." The "Smart Wallet" can do that because it has the SK's public key. Afterwards, it submits them to the game for execution. The last step is for the Bundler to reclaim the money it has spent on this UO from the Smart Wallet.
Assuming all this infrastructure, like the Bundler, Javascript SDKs for UOs, code for the "Entry Point," and the "Smart Wallet," already exists, it makes sense for a game developer to use the EIP-4377 standard, as their effort will be similar to the "Simple solution".
An extra benefit of the EIP-4377 infrastructure is that the game can now employ a "Paymaster," another intermediary who can offer to pay for the moves on behalf of the user. This could improve the UX and onboarding of new users and unlock freemium models.
The User experience is identical to that described in the "Simple solution," with the difference that even if the browser crashes, the prepaid amount is not lost. Note that using the standard allows for much faster integrations with compatible paymasters.
Social Recovery
It's well known that Web3 projects constantly struggle to strike a good balance between usability and security. All solutions, from seed phrases to hardware wallets, trade one for the other. This has been a constant challenge since the early days of Bitcoin.
Centralised providers, like Apple, give users an excellent user experience with high security because they position themselves at the root of trust and combine many technologies.
Achieving a similar outcome in a decentralised setup is still a dream, but we can start with the basics.
The idea behind "Social Recovery Wallets" is to give users a "Forgot Password" recourse. This feature adds a third dimension to the security-balance tradeoff. The user can employ a high-security solution, like a hardware wallet, for everyday operations and still have a way to recover the account in the exceptional situation where she loses the device.
In the spirit of decentralisation, the role of recoverers is entrusted to "guardians", who are selected by the user. They can be friends, family, commercial services, or other devices they own. It is critical that no guardian has any power over the assets.
The implementation is straightforward. The funds are controlled by a "Smart Contract Wallet" (SCW), which will encode all the necessary rules.
For example:
- KeyA can spend money freely. Where KeyA is the user's main EOA.
- Any two of KeyB, KeyC and KeyD (the appointed guardians) can replace KeyA for KeyE. Where KeyE is the new key generated by our user.
With this setup, the user can use KeyA for day-to-day operations but still access a “recovery” mode. This model is superior to a plain “Multi-key” because the guardians are almost never involved.
Note that KeyA must have some native balance to pay for transactions, but the SCW controls the bulk of the assets.
Also, note that we haven't used Account Abstraction for this solution yet, but we have achieved our goal.
After updating our SCW to be EIP-4377 compatible, all interactions with it will be "User Operations" paid from the balance of the contract. This is a clear improvement, as the user does not need to hold any balance on the EOA, but it does not change the fundamental behaviour.
Multi Calls
For years, services like Furucombo have allowed users to perform complex arbitrages involving Flash Loans.
You can start with a flash loan on Aave in CoinA, then buy CoinB on Uniswap, sell it for CoinC on DyDx, then repurchase CoinA on Uniswap, and finally pay back the loan and pocket a small profit.
All these operations must happen atomically for many reasons, but mainly because the FlashLoan must be paid back in the same invocation.
There are multiple ways to implement this pattern.
One option is to write a smart contract that does all this by calling the "lend" and "swap" functions of Aave, Uniswap and DyDx. Services such as Furucombo can generate the code based on the user instructions.
The code is then deployed to the chain and will execute the arbitrage logic in the constructor. There are some gas inefficiencies, but this is a very flexible solution.
Another approach is to deploy a general-purpose smart contract that interprets and executes a list of instructions. For example, "Lend 100,000 CoinA from Aaave" — would be the first instruction.
This is a pretty straightforward "Multi-Call," and as you can see, it works quite well. This pattern has been used for many years without any standard.
EIP-4377 fits quite naturally for this problem. The Smart contract is the "Entry Point," and the instructions are the User Operations.
Objectively speaking, other than being compatible with a standard, the functional benefits are unclear.
Conclusion
Account Abstraction (EIP-4377) is hailed as groundbreaking, and the expectations for its impact are sky-high. It is believed that it will solve the UX problems which plague Web3 and hold it back from mainstream adoption.
However, the reality is more nuanced. Like any standard, the best it can hope to achieve is helping combine existing solutions in unforeseen ways or speeding up new ideas with compatible tooling.
Find out more
If you're interested in learning more about what we're building, check out our other blog posts here or dive into our whitepaper. Join the community on Discord and follow us on Twitter.
