It’s already here with Safe

This article aims to demystify what Account Abstraction really is, its associated benefits, and how Safe is implementing it to create a secure and usable Web3 experience. This is not a technical guide on implementing Account Abstraction, we’ll include links at the bottom for that.

The topic of Account Abstraction isn’t new, it has been a topic of long discussion since 2015. However, with significant momentum in EIP standards like 1271 and 4337, and killer smart contract wallets gaining adoption like Safe, Argent and Ambire, the topic is finally on the front page of Web3 discourse, and 2023 will be the year it goes mainstream in implementation.

Unfortunately, this newfound hype tends to create more inaccuracies and empty noise. There are many definitions and misconceptions now surrounding the topic in 2023. Let’s demystify them.

Let’s first start with a crypto glossary. 

     💳 An Account on a blockchain is an entity with a native token balance (e.g. ETH, GNO) that can be an entry point for transactions on the chain. Accounts can be user-controlled or deployed as smart contracts (see pic 1)

     📃 A Smart Contract Account is an account governed by code, as opposed to the more common Externally Owned Account (EOA) implementation, which is an account managed by a private key (see pic 2)

     🔎 In computer science, Abstraction means hiding information to increase focus attention on areas of greater importance.  

With the glossary out the way.. let’s define AA.

Account Abstraction is the idea of reducing the number of account types from 2 (EOA and smart contract) to 1 (just smart contract) in order to improve usability and flexibility in Web3. 

This is achieved by moving the validity conditions of a transaction (signature verification, gas payment, replay protection) out of the core protocol level (consensus layer) and into the EVM smart contract level (execution layer).

In other words, we’re not only talking about just using smart contract accounts instead of EOAs as the default account. We’re also talking about how a blockchain can interact with smart contracts, and how we can verify data from smart contracts. With AA, here are the specific components of an Account that we want to abstract away:

• Signature abstraction - Allow different account contracts to use different signature validation schemes.

• Gas abstraction - Allow different models of payment for transaction fees. For example, payment by another party/contract.

• Nonce abstraction - Allow different replay protection schemes besides a singular, linear nonce for an account. Such as multiple nonces for different types of transactions.

• Network abstraction - Smart contract accounts can be controlled by accounts on a different network via arbitrary message bridges.

Account Abstraction flips the model a bit. It requires us to think about accounts differently than we do right now, all with the core goal of improving UX and onboarding the next billion to Web3. 

Currently, by default, the chain considers an account to be a private and public key pair (i.e. ECDSA secp256k1 key pair). And verifies what you've done on a blockchain through signatures using this ECDSA public/private key pair. This means we, as users, need private keys (EOAs) to interact with the chain. And private keys are not user friendly to store, manage and recover.

Smart contract accounts on the other hand, are much more flexible and customisable, given their programmability (they’re simply code). The core goal of AA is to enshrine smart contract accounts as 1st class citizens and the default account. And it does this by removing the account specification from the core protocol level, and provides an entrypoint (or default account) instead that implements these specifications. This entrypoint can be implemented as a contract e.g. EIP4337, or natively in the protocol itself e.g. Starknet.

A simple analogy of AA is that we’re transitioning the system from iOS to Android. It will offer so much more in terms of flexibility and customizability, but as with any fundamental system change, we need to be careful about the security tradeoffs. A middle ground needs to be achieved with AA, and we at Safe will ensure that our formally verified contracts and developer tooling creates a baseline for devs to build new and secure dapps/wallets in this smart contract account era.

The Benefits of AA

The value of Account Abstraction is not generated by just implementing Account Abstraction at the contract or protocol level. It’s about the features that are built on top of it. Let’s separate out the benefits by the key components that AA abstracts away. 

📝By abstracting signature verification logic from the protocol, and allowing different account contracts to use different signature validation schemes, you enable the following at the application-layer:

• Native multisig

• Seedless logins

• Social recovery

• Batched tx’s (a default smart contract capability)

• Easy wallet migrations and key handling

• Hybrid custody setups

💱By creating a separate execution scheme at the protocol, you enable different models of payment:

• Pay for the gas of their users’ transactions

• User don’t need eth in their wallets

• New currencies for gas, don’t mandate a specific token (native or contract-defined) to be used for paying for transactions.

Tldr - these features will allow us to create a n00b-friendly experience to dapps and wallets, an experience that doesn’t involve managing private keys/seed phrases and holding/paying for gas. 

Given that Safe is a programmable smart contract account with a mature set of developer tools, the benefits outlined above are already possible and AVAILABLE RIGHT NOW WITH SAFE. We have multisig, batched tx’s, relaying and recovery mechanisms enabled by default at the contract level. But once native Account Abstraction comes along, it means we can enable all these SC features without the core need of EOAs or contract customisations to begin with. This is a major upgrade in UX, and soon, using an Ethereum account is going to be the same as using a bank. 

As Safe is the most widely adopted smart contract account on Ethereum/the EVM today. We understand that we have a big part to play in bringing AA to reality. Finding people to implement these new technologies seems to be the biggest bottleneck for account abstraction, but we’ve big plans to address with an upcoming EthDenver announcement 👀

Ultimately, we aim to help push native AA at the protocol level on each chain, but also plan to support contract standards like EIP4337 who are pushing in this direction, with the view that it will eventually be pushed to the validation layer and in the native code. Here’s a quick summary of our future plans:

EIP4337 support

• Our current contracts (v1.3) doesn’t permit you to use multisig with EIP4337 bundler. However, v1.4 of the core contracts solves this using Safe modules and will allow us to collect feedback as EIP4337 is implemented on mainnet.

Native Account Abstraction support

• Safe contracts v2.0 will support native account abstraction.

• We will incorporate the feedback collected from the module based EIP-4337 support to streamline support for native account abstraction on different chains.

2023 will be the year for Account Abstraction, and we will ensure developers are well funded for their AA efforts with Safe, be it through our grants or hackathons. To the next billion of Web3 users onboarded through AA, we say gm.