Account abstraction, the new shiny object in crypto
But are the advantages worth the tradeoffs?
Search “account abstraction” on the bird app and you will find one of the hottest product discussions going on in crypto right now.
The hopes for account abstraction (AA) range from simply improving the usability of blockchains to unlocking a whole new world of functionality that will finally bring about true mass adoption.
It’s hard not to get excited by the possibilities, but then you start to look at some of the live examples of AA and the hype seems a bit overblown.
In their quest to obscure the seedphrase, product teams have made big compromises on privacy, they’ve asked users to place trust in opaque or unknowable third parties, and they’ve constructed key management schemas that are not compatible with existing wallet standards.
Of course, this is very early days.
It’s important to distinguish these efforts from the hopes for what may be possible after a critical upgrade to Ethereum, which can’t come soon enough.
What has been built
When setting up your typical non custodial wallet, you are given a pair of keys: a public key and a private key.
You may receive funds by sharing your public key with the sender. But you can only initiate a send by authenticating (or signing) the private key, which you alone posses.
This top level of wallet ownership is also known as an Externally Owned Account (EOA).
V1: iCloud
One common form of AA gives the user the option to save their private key in the cloud and authenticate it with a username and password.
Some may quibble over whether this even qualifies as AA. I would argue that it does in the sense that it removes the need to write down and secure a seedphrase and gives the user a familiar pattern with which to authenticate and recover their private key.
V2: SSS
A much more sophisticated approach I’m seeing more and more is to leverage a technology called Shamir Secret Sharing (SSS).
Using this method, the private key is broken up into multiple “key shares,” a certain threshold of which (usually two of three) must be authenticated to reconstitute the whole private key.
Some examples
These wallets represent a few different form factors and common wallet categories.
Argent is a mobile app wallet available on iOS and Android, primarily for saving and long term storage of crypto assets.
The Binance Smart Chain (BSC) Wallet is a browser extension that facilitates access to the Binance Smart Chain and the dapps in that ecosystem.
Sequence is a web wallet that supports multiple chains and is purpose built for gaming.
How Argent manages private keys
With Argent, you have two options for private key management:
Option 1— Save your private key to your iCloud key chain and authenticate with biometrics or PIN.
This is very convenient, but if you decide to go this route your private key is stored with Apple and is vulnerable to all the same security weaknesses as your iCloud account.
Because of this, iCloud has become a much bigger target for hackers. This guy lost $650,000 in a pretty crude fishing attack because he saved his private key to iCloud.
Your privacy is also compromised, in the sense that all the personally identifying information associated with your iCloud account is now associated with your private key. If you use biometrics, you might as well have a DNA sample attached to your private key.
Your iCloud and biometrics can also be compelled, just like your blood can be compelled if you are pulled over for a DUI.
Raw numbers on the other hand (which is what a private key is) and a combination of words (mnemonic seedphrase) cannot be compelled, and they contain no personal identifying information.
Option 2— Use SSS to break your private key into three or more key shares and save them amongst several guardians.
You can use any or all of these entities as guardians:
- A hardware wallet or another device, like a phone
- A friend or family member’s device (someone you really trust)
- The Argent guardian which stores a key share on Argent’s server
This is perhaps the least bad implementation I’ve seen of v2 account abstraction.
Setup takes significantly more effort than iCloud, but you can configure it in a way that is both private and trustless, so long as you use anonymous guardians (like hardware wallets) and you don’t use Argent’s guardian.
You can assign as many guardians as you like and define your own threshold, like two of three, three of five or six of ten.
I would say the main drawback of using Argent in this way is that unfortunately, the wallet you create isn’t compatible with any other non custodial wallets that use normal wallet standards.
Meaning that if you were to store your savings on Argent, go into a coma for 30 years, then come back and try to restore your wallet, you better hope that Argent didn’t run out of VC money and go under, and that the guardian configuration still works exactly the way it did when you created your account.
Otherwise you’re SOL. There is no other wallet that facilitates the authentication of key shares and reconstitutes the private key exactly like Argent.
Funny enough, Argent also lets you export your seedphrase from settings. If you do that, the seedphrase would be compatible with other BIP-39 standard wallets, but anyone who has the seedphrase can completely bypass the guardians you set up using SSS.
The Argent team has empowered users by giving them a ton of options to roll their own custody setup, which I can appreciate.
It’s up to individuals to identify the tradeoffs and decide what is the best solution for them.
BSC Wallet’s approach to private keys
Similar to Argent, Binance Smart Chain Wallet (BSC) gives users the option to save their private key to Google Cloud, or to secure it via SSS.
Guardians are called “authentication factors” and they work the same way as on Argent, except the user doesn’t get to chose where the key shares are stored:
- Share one is saved to the Torus Network, which is authenticated using Google oAuth
- Share two is saved to the BSC chrome extension client, same as how metamask stores the private key
- Share three is stored with Binance and authenticated with username and password
Like Argent, it uses the familiar pattern of username and password to save the private key to Google or a key share to Binance.
But the tradeoffs are huge:
Connecting with google gives the provider (in this case Binance) access to the personal identifying information associated to that google account.
This is a non-starter for me and probably many crypto users.
BSC’s implementation of SSS is unique to the BSC Wallet, so a wallet created in this fashion is not going to be compatible with any other.
Lastly, the third key share must be saved with BSC, so one more major dependency on Binance.
How Sequence manages private keys
Sequence’s approach to onboarding is to completely obscure the existence of the private key from the user.
At the outset, you have a number of web2 oAuth options for login, which first made me think they were saving the private key to the cloud.
It wasn’t until I read the Terms that I realized they were using SSS:
“There are three private keys associated with your Wallet, and two private keys are required to access your Wallet at any given time. One private key is stored locally on your device. Another private key is generated using the Login Credentials you provided to open your Account (“Account”). The third private key is maintained by Horizon. When you log in to your Account/Wallet with your Login Credentials, you access the account using the private key stored on your device and the private key generated in connection with your Login Credentials.”
This is strait-up shady.
For the tiny fraction of users who read the terms, they still won’t know where their second key share is being stored. It says it is generated using login credentials, but doesn’t say where it is stored. So there is no way to know who that third party is.
Unsuspecting users might think that if they lose their device, they can simply sign in using their Facebook or Google credentials, not knowing that one of the key shares was on the lost device.
Burying these details in the terms and offering zero education during onboarding might seem like a UX win, but the price is that the user essentially knows nothing about their recovery options.
Account Abstraction v3
Of course when crypto folks talk about AA, almost no one is referring to v1 or v2. They are talking about the mostly theoretical future promise of v3.
To understand v3, we need to go one level down the hierarchy of the EOA and there you find the contract account (CA), or the smart contract layer.
Think of the CA as an application that lives on the Ethereum network. The CA is programmable and can do all kinds of interesting things, but the one thing it can’t do is initiate transactions.
At least not yet.
The future vision of account abstraction, described by Vitalik in a blog post is to merge the EOA and the CA, allowing for transactions to be initiated by the contract account.
“Instead of [smart contract code] just being used to implement the logic of applications, it would also be used to implement the verification logic (nonces, signatures…) of individual users’ wallets.” — Vitalik Buterin
This capability theoretically unlocks a whole new world of features, including but by not limited to:
- Better social recovery systems — which don’t rely on third parties and would be backwards compatible with other wallets
- Multisig contract accounts — that require multiple parties to sign off on a transaction for an extra layer of CA security
- Gas fee abstraction — where the smart contract performs the necessary operations for the tx fees to be paid in kind, and even lets the user decide if the fees will be paid by the sender or the receiver
- Delegable accounts — which would allow for automated/ recurring payments through the use of smart contracts
wen v3
Layer 2s are currently leading the charge on this, with zkSync recently deploying a set of tools that facilitate a limited set of AA functionality.
Ethereum mainnet doesn’t seem to be too far behind, with an Ethereum Improvement Proposal that integrates AA (EIP-4337) getting a lot of attention from developers and the greater Ethereum community.
That being said, the current capabilities of zkSync come with a lot of complexity and overhead, as well as the inherent risks of using any Ethereum Layer 2 chain, which were recently logged by CoinDesk.
Layer 2s remain cumbersome from the UX perspective, as most crypto assets are not on a layer 2 by default.
Whether you’ve purchased crypto from an exchange or from one of the popular fiat onramps, like Moonpay or Wyre those assets originate on Ethereum mainnet and must first be bridged in order to enjoy any of the benefits of layer 2.
Neither EIP-4337 or the much lauded EIP-4844 do anything to address this issue.
Conclusion
The first two versions of account abstraction were valiant attempts to address the seedphrase pain point, but when it comes to long term storage of assets these custody models are too fragile for me.
Yes, a better solution for the masses will probably emerge at some point, but v1 and v2 basically amount to quasi centralized custody with no backup at all.
The reliance on one or more third parties invalidates a key value prop of crypto: No intermediaries.
As a practical matter, you have no way of knowing whether a given third party will still be around in a decade or two to help you or your heirs recover your private key.
The convenience of having a username and password simply isn’t worth these tradeoffs, imo.
As for v3, the progress that has been made is indeed impressive. This next evolution of AA technology is definitely worth keeping a close eye on.
However, I think it would be premature to put too much stock in it and I personally will remain skeptical of any project that cites AA as a major differentiator or strategic advantage in the near term.
—
Thanks for reading until the end. I work in crypto and think about it non-stop. You can find me on Twitter @danajwright_
