Demystifying Account Abstraction on Zk Rollups & Ethereum: Tech guy PoV

While today our crypto wallet are (only) used to access and manage our Cryptocurrencies, NFTs, integrate some staking options, I think there’s so much more things to do as an Account point of view. StarkNet & ZkSync introduced a long-term feature that followed Vitalik’s vision : Abstraction of Account.

Sir, What’s Abstraction ?

The abstraction process is the practice of hiding information. This increases the ability of a computer system to be used at a higher level with less knowledge of the processes going on underneath.

In a programmer PoV, let’s say he hides all but the relevant data about an object in order to reduce complexity and increase efficiency.

Account Abstraction definition

On the Ethereum network there are currently two types of accounts.

• EOA : External Owned Accounts are wallets from which cryptocurrency is transacted in send and receive functions that exist outside of the EVM (Ethereum Virtual Machine) : Cold Wallets as Ledger, MetaMask, Phantom, …

• Contract accounts are “Smart Contracts” that exist in the EVM. For example pools on Uniswap are basically Smart Contracts.

Ethereum account abstraction has the goal of reducing from two account types down to one, a Contract Account. The single account type will have the functionality to transact both tokens and contract. Developer and user will no longer need to make a distinction between account type since transacting will be moved fully into the EVM and off of the blockchain protocol.

External Owned Account precision

EOAs have three properties:

• A balance to represent the amount of ETH available to the account
• A nonce to ensure that every transaction is unique
• An address to uniquely identify the account on the network

It’s important to mention that on Ethereum, every transaction must be initiated from an EOA. That means that when a transaction is executed by the Ethereum Virtual Machine (EVM) , the first account being touched must be an EOA and the corresponding account must pay a fee to the miner for the execution of the entire transaction.

Every account on Ethereum is associated with a cryptographic object called the Keypair :

• Private Key : used to sign digital messages
• Public Key : allows anyone to verify that a given signature was signed by its corresponding private key

Account Abstraction on StarkNet and ZkSync

As of today, StarkNet and ZkSync 2.0 are the most advanced in terms of Account Abstraction and they both manage to implement it in a way.

AA holds two main goals :

• Signature abstraction: allow different account contracts to use different signature validation schemes.
• Payment abstraction : Allow different models of payment for transactions. For example, payment by another party/contract or pay in another token than ETH

The model of StarkNet Account are still represented by contracts, so-called “account contracts”. To put it in simple word : Any Cairo Smart Contract deployed on StarkNet can be an Account, the only requirement is that they comply with a specific interface with methods to validate and execute transactions.

On ZkSync side, an account has also 2 functions to implement : validateTransaction & isValidSignature

With this abstraction, we directly see opportunity :

• Using Multiple keypairs to validate a transaction (simply put multi-sig all-in-one)
• Changing the Keypair of you Account (like rotating keys)
• Using a different signing scheme than ECDSA

What could it bring ?

This could be the most important part of this story : let’s go more deeply on the use cases of Account Abstraction. We can split these use case in two different domain :

• User Simplification
• Technical Use Cases

User Simplification : Session Keys

Let’s say you are playing an On-Chain game : currently you need to sign every single transaction by your own. It means each time you have to make an action, you need to sign a transaction :

Collect rewards, move your character, send a message, …

Session Key is basically the idea to authorized to play games for a certain period of time. We generated a session key held in the browser’s local storage and only authorized to sign transactions for 10 minutes. After these 10 minutes, the key will be revoked and you will need to create a new one and authorize it again.

In that extend, you can also imagine creating batch transactions : the same abstraction as you would be in a Supermarket, choosing product, and paying only one time at the end.

User Simplification : Transaction automation and splitting rights

With Abstracted Account, you could 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 cold wallet and other keys held on less secure devices and only authorized to perform certain actions.

A cool example :

My most secured key, that I don’t use much, would be the only key that can transfer or send more than 1k$ to another Account, however, I can also have those less secure key on my computer to perform actions such as claiming rewards on some specific decided dApps (AAVE, …) or another one to perform any transaction on an On Chain game.

Now let’s say those key are held in a server that performs automated transactions / running your own bot : you can ensure that these key can only be used to perform actions you decided and improve security.

One last utility could be a protocol built that DCA on your behalf certains token as a recurring transaction.

Technical Use Case : Paying fees for someone else

This is one of the most interesting thing you can do with Account Abstraction. basically imagine that an account can pay the fees of another account, how genuine is that ? I can only imagine how powerful it could be for a protocol to onboard their users by paying their fees.

Final thoughts

We have seen how Account Abstraction can be a game changer in blockchain future. I am personally deeply convinced that a new era of use cases will come with Abstracted account, especially regarding the video game industry on-chain. I hope you understood everything about Account Abstraction, and that I gave you some reflexion area around the subject !

Later I will propose you a story on how you can customize a Cairo Account Smart Contract on StarkNet and build a real use-case together.

@ExoMonk

Ressources

• https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/account-abstraction/ — Account Abstraction, EthHub
• https://www.argent.xyz/blog/wtf-is-account-abstraction/
• https://github.com/argentlabs/argent-contracts-starknet — Cairo ArgentX Account implementation
• https://github.com/sambarnes/cairo-multisig — Cairo MultiSig Account Contract
• https://matterlabs.medium.com/introducing-account-abstraction-l2-l1-messaging-and-more-760282cb31a7 — ZkSync2.0 Account Abstraction