Random thoughts on Account Abstraction
Sylve
0x499e
July 27th, 2022

Article was originally published on hackmd.io on July 25th 2022.

Random thoughts on Account Abstraction

We’re all hyped up at the prospect of higher programmability for our wallets, I thought I’d jump in and share some of what I’ve seen recently. The examples provided below revolve around StarkNet but could be applicable to other network supporting account abstraction.

Account Abstraction, a primer

On Ethereum L1 you have two entities: Externally Owned accounts (EOA) and smart contracts.

EOAs are addresses on the blockchain controlled by a private key. You generate them by creating a private key and deriving a blockchain address from it. You now control the key that can sign transactions from said address. But the key is the account: you can’t authorize another key to sign for a given address and you can’t code custom logic on top it. Governance and spending logic have to be implemented outside of the blockchain.

A smart contract is basically code held at a certain address on the blockchain. Some smart contracts are built to behave like wallets and are aptly called “smart wallets”. You can be very creative with smart wallets because you don’t have a unique signing key: for example, multisignature contracts like Gnosis safes allow you to define a spending quorum, (“you need signature from 2 out of 3 authorized keys to validate transactions”), and add other governance features on top of it (“this address can only spend 50 USDC per day”).

It’s important to understand that smart contracts can be programmed to behave exactly like EOAs (only one signing key, no upgradability, etc.) but the opposite is not true.

Account Abstraction (AA) is a long-discussed proposal to only have smart contracts and do away with EOAs. This mean your wallet is a smart contract, and you can program it any way you want. This also means you will need to deploy your contract wallet, you can’t simply derive your key and immediately start signing transactions. AA is not yet implemented on Ethereum L1 (and may never be) but will be implemented by default on validity/zk-rollups like StarkNet, zkSync and Polygon Miden. Given that these L2s will have cheap computation and AA implemented by default, builders will be able to significantly improve user experience and build crazy new stuff.

Now, onto some cool characteristics of AA.

EOAcel vs. key rotator

EOAs are stickier than, say, World of Warcraft game accounts because you can’t change the private key. Imagine I sell you my WoW account: you will change the password and the email address attached to it so I can’t access it or use “I forgot my password” to reset it. Now imagine I sell you my EOA (meaning I give you the private key): you have no way of knowing if I’ve kept a copy of the key, and you can’t modify this key. In 2 years I might decide to steal everything from you by signing a transaction with that same key to drain all your funds.

Account Abstraction makes it much easier to rotate keys. You can indeed implement a function which changes the main signing key of a given wallet, or even manage multiple signing keys. You could have your admin key in a hardware wallet and a myriad of other keys held on less secure devices and only authorized to perform certain actions.

For example: a key held on your browser could be authorized to transfer up to 50 USDC, while another key held in a server could be authorized to run exactly one claim() transaction on Aave every day to reap juicy DeFi profits.

Funnily, this key rotation makes Soulbound Tokens (SBTs) a tad trickier to implement with AA. With EOAs you have a quasi-guarantee that no one will sell their account. With AA you need to take extra measures to ensure ownership of the wallet cannot be transferred.

@GuthL suggested in this thread to implement a wallet interface standard to uphold non-transferrability. This would follow a pattern similar to EIP-165. Untransferrable wallets would need to follow a standard which would be guaranteed by interface detection. Another option would be to implement this at the NFT level, as suggested by @th0rgal, but that would become an entire NFT standard in itself.

I like to mobile mobile

Blockchain mobile interaction is 99% read. Your phone holds your addresses and you can browse your balances, your NFTs, directly from your phone. Actual blockchain interactions (write) are entirely Desktop-bound because interacting with the blockchain from a smartphone is a hassle. If you want to sign a transaction from your phone you will need the private key of your wallet to be held on your phone, which is a big no-no security wise. You could spin up a burner wallet from your phone but that would fragment your accounts on different devices. And what happens if you lose your device. etc. etc.

That’s the situation with EOAs. Luckily AA allows us to program whatever we want. So why not authorize a mobile_key to sign transactions up to a certain amount, and/or only for certain contracts,and/or only for certain functions (no transfer() but only play() for example). You could even revoke it after a certain period of time.

The flow to authorize a mobile would be something like 1) generate pub/priv key on mobile phone 2) authorize pubkey on the smart wallet with an “admin key” 3) tadaa. And since we have an implementation of nistp256 (used in smartphone secure enclaves) in Cairo, I’m sure we can get some creative and robust solutions.

This section is a special case the previous one but it is important to stress that we will be able to easily interact with the blockchain from a smartphone thanks to AA.

Finally, some good f****** gaming UX

On-chain games are cool but the more on-chain they are the more you’ll need to sign transactions. Imagine clicking “approve” 200 times on Metamask just to play a game. To solve this you can leverage the same Mobile key logic to create session keys authorized to play games for a certain period of time without having to sign every 5sec. This is what we leveraged to provide a better user experience for StarkDew valley during the DevConnect StarkNet hackathon. We generated a session key held in the browser’s local storage and only authorized to sign transactions for 2min. After 2min, the key was revoked and you needed to create a new one and authorize it again.

Another cool feature is batch transactions, or as @lordofafew likes to call it: the transaction cart. With EOAs you need the contract you want to interact with to support multicalls to be able to batch transactions. With AA you get this for free: just pass an entire array of functions+parameters to your transaction and see the magic happen. Now you can approve+transfer+revoke in a single transaction rather than three.

Batch transactions can even help you save on transactions fees on StarkNet since you’d only be changing the state once for the transfer, not for the approve/revoke (explanations here).

This is somewhat reminiscent of Arcade cabinets where you need a coin to play a game. Here, you could pay for your first transaction and if you happen to be winning, swap your hard-earned tokens to pay for your transactions fees and keep playing. This would only require you to add another swap() transaction at the top of your next batch of transactions. You can get crazy creative with this, which is why I’m excited about what the Cartridge team, who’s building a gaming-focused wallet on StarkNet, will come up with.

Shameless plugin

During the Devconnect StarkNet hackathon about half the teams were tinkering with AA. We built a session key, other folks built a deadman switch or a multisig wallet for guilds, and we all ended up forking the Argent, Braavos and Open Zeppelin contracts. Down the line we can’t all come up with our own version of a wallet contracts with their own peculiar logic.

Argent has started working on a plugin system (here), forked by the Ledger team (here) to help all the cool governance module integrate with smart wallets.

You could deploy your wallet with a single signing key, then add a multisig plugin, then a session key plugin, then a deadman switch plugin, without having to deploy a new wallet every time. You could also revoke them at will. There’s an entire ecosystem of plugins waiting to be built and mashed together.

Anyone could build a front-end on top of a hypothetical plugin registry to help users choose which plugins they’d like to use, and showcase which are currently being used. You could imagine an incentive system where the most popular plugins get some funding as a public good or from projects that leverage them the most.

NEOA’s Ark

I’m absolutely convinced everyone will eventually own NFTs. A key issue currently lies in the delivery of said NFTs. It’s possible to use your credit card through systems like wert.io where the user pays a company to run a transaction for them. The problem lies in actually getting the NFT: you will eventually need to create a wallet unless the NFT issuer wishes to custody your NFTs and possibly face legal and compliance issues.

With AA, NFT issuers could create a temporary smart wallet and authorize the buyer to identify themselves to get the main ownership of the wallet back, like a sort of escrow account. I’m also convinced that, while current web3 folks are huge on self-custody, third-party custody is the missing piece for mainstream adoption. AA would allow users to delegate the custody of their wallet to a banking service while ensuring they have the option to always retrieve their funds, or switch providers.

For blockchain to go mainstream it must become invisible. AA allows users to easily deploy wallets managed by 3rd parties to ease them into web3, and still have the option to go for full deluxe hardware-backed self-custody when they feel more comfortable. You can be completley oblivious to the inner workings of blockchain and have someone abstract it away for you, or you can be a hard-boiled self-custody maxi. AA gives you the option to not care, care less, or care later.

A list of other cool stuff you can do with AA

  • Pay for a transaction in another currency than the fee currency by adding a swap from a random token to the fee currency.

  • Matryoshka NFTs: create NFTs that act like wallets and hold tokens or other NFTs (like briq NFTs).

  • Guild wallets: like a normal multisig contract but with more features tailored for games (example).

  • Wallet Flashloan: run an atomic transaction that 1) changes ownership 2) does stuff 3) gives ownership back (not sure why you’d want to do this but that’s pretty funny).

  • Spam filter: only authorize inbound transfers from trusted tokens to avoid spam tokens and NFTs. You’d refuse receiving a transfer if it doesn’t come from a pre-approved list of vetted contracts using a system similar to EIP-165 interface checking (could use something like Kleros listings). AA doesn’t give it to you right out of the bat, it requires a change at the token-level as well, but the interface check is made easier at the wallet level thanks to AA.

  • Validium-only key storage: once volition kicks in, you could choose to store the pubkey of a given secondary key only on L2 to save on cost, and only store the admin key with L1-backed security.

  • The whole gamut of transaction rules: timelocks, velocity controls (only N transactions per day or Y amount of ETH), allowlists, banlists, deadman switches, etc.

  • Recurring transactions: authorize a keeper network like Yagi to run pre-approved transactions on your behalf every once in a while, to reap DeFi benefits or DCA for example.

Final thoughts

AA is an extremely powerful solution to fix glaring web3 UX issues, I hope this article gave you some better insights into it. I also encourage you to check out competing models such as MPC wallets. They are more centralized wallets leveraging complex algorithm to split key ownership but have the added benefit of getting cross-chain interoperability for free. AA is great as long as you’re staying on a single chain, at least for now. If you’re working on a system to allow cross-chain AA-based wallet, I’d love to chat.

Thanks a lot to @Crema_fr, @btchip, @loaf, @0xEvolve, @jniset, @GuthL, @wraitii, @itamarl, @0xChqrles, @starknetdev and the whole StarkNet fam for the brainstorms.

To go further

Intro to AA

Code implementations & tinkering

Edition

20230105: corrected the “spam token filter” part. I mistakenly said that AA would allow an account to filter any token. This is not true, at least not naively. You’d need to change the token standard to account for it and add an interface-type check like EIP-165 on the wallet for authorized tokens.

Subscribe to Sylve
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.
Arweave Transaction
GU8khL8iw01g6Q4…muzZboWm66t1qVk
Author Address
0x499eB561220eb35…4cDD4F5b76A2d2A
Content Digest
Un2EYccIpfE3BDe…siRIivZlBLNX7Ag