A Developer’s Guide into Account Abstraction Models

One of the core factors that has contributed to the influx of new users to crypto and usage of crypto wallets is accounts abstraction (AA). While continuous developments are being made around this concept, the idea of account abstraction was first proposed by Vitalik Buterin, founder of Ethereum, in 2015. Its fundamental proposition was to move crypto from the current approach of EOA accounts (which are accounts that are externally owned and controlled by private keys) to a model where accounts can be customised depending on their application and are controlled by smart contracts.

This article assumes the reader has no prior knowledge of AA models and aims to introduce the general concept AA by exploring its implementation in two prominent blockchains, namely Ethereum and Solana. By discussing their differences and the unique advantages each chain derives from the implementation of AA models at the core of their account structures, readers will better understand how these implementations can be adjusted to suit various needs.

What is an Account

It is a general misconception among most crypto users that the term “account” refers to a wallet. This assumption however cannot be further from the truth. As a developer, it is important to note that an account is not a wallet. A wallet is simply an application that acts as gateways to interact with blockchain. So what then is an account?

Accounts on Ethereum

In Ethereum, accounts are basically “objects” that constitute the state of the blockchain. These objects consist of a 20-byte address, and state transitions within the blockchain are as a result of transfer of value and information between these accounts. An Ethereum account contains four fields:

• The nonce, a counter that tracks processed transactions
• The account’s current ether balance (ETH)
• The account’s contract code-hash which is the hash of the EVM code of the contract. The contract is immutable but its state is mutable (For EOAs, this is a hash of an empty string since EOAs do not store code)
• Storage, an encoding of the state of the account In Ethereum, there are two types of accounts: externally owned accounts(EOA) which are controlled by private keys, and contract accounts, which are controlled by their contract code. EOAs do not store code and transmit information only by creating and signing transactions. Contract accounts on the other hand store code which activates whenever that account receives a message, therefore enabling it to read and write to internal storage and send messages or create contracts (contracts on Ethereum can be analogous to “agents” within the EVM that executes a piece of code as instructed by a transaction or message. They have direct control over their own ETH balance and their own key/value store to keep track of persistent variables).

(source: Helius.dev)

Accounts on Solana

On Solana, accounts are more like storage which is capable of holding every type of data ranging from tokens to a program’s state variables such as integers, publickeys and even entire programs. The Solana account model requires that every account has an owner, and multiple accounts can have a single owner.
A good analogy of the account model on Solana is a computer filesystem where a computer file can reference multiple data and state variables such as name, address, email e.t.c. Comparatively, in Solana, public keys can be likened to reference storage of state and data such as lamport, owner, rent, and executable.
Similar to Ethereum, Solana accounts are of two main types:

• Executable, which consist of immutable programs that own and create other accounts that store state,
• Non-executable, which are “storage or data” accounts that contain all other types of data like program variables, token balances, NFTs, etc.

Executable accounts can further be delineated into Program Accounts, which are accounts that store user-customised executable programs, and Native Program Account, which store core native programs such as the System Program which is responsible for the creation of accounts.
Through executable accounts, instructions can be communicated to the network on how to execute transactions and through non-executable accounts, data can be stored (without the ability to execute code.)

(source: Helius.dev)

The image above describes examples of executable and non-executable accounts. Bubblegum is an example of a Program Account by Metaplex used to create and manage compressed NFTs. Vote Program is a Native Program Account used to create and manage accounts that keep track of voting states. Associated Token Account, System Account and Stake Account are all non-executable accounts that store some form of data. Associated Token Account refers to accounts that hold data associated with a particular token, its balance and its owner (for example, 6ysptGHvXxPUs7T6jV5MGq157VUCUdreXQspt3w36EJF holds 10 USDC). Stake Account is used to stake/delegate token to validators and earn rewards.

Accounts on Solana follow a specified structure defined by the AccountInfo struct:

pub struct AccountInfo<'a> {
    pub key: &'a Pubkey,
    pub lamports: Rc>,
    pub data: Rc>,
    pub owner: &'a Pubkey,
    pub rent_epoch: Epoch,
    pub is_signer: bool,
    pub is_writable: bool,
    pub executable: bool,
} 

The AccountInfo struct holds the following fields:

• key, which is a unique 32-byte public key by which accounts are identified
• lamports, which specifies the number of lamports owned by the account. Lamport is the unit of SOL which is the native token of Solana, and one lamport is one-billionth of one SOL
• data is a reference to a raw data byte array that is stored by the account. It can be modified by programs and can store anything The field owner specifies the owner of the account represented by the address of a program account (PubKey). A few rules guide account ownership on Solana:
  • Only an account owner can alter its state and withdraw lamport
  • Anyone can deposit lamports into an account
  • The owner of an account can reassign ownership to a new owner provided the account data is reset to zero
• is_signer is a boolean that indicates if a transaction has been signed by the owner of the account- this means that the account holds the private key that corresponds to the public key and has the authority to approve transactions
• is_writable field is a boolean which signifies whether an account state can be modified.
• executable is a boolean that indicates whether an account is an executable or non-executable account.
• rent_epoch refers to the next epoch at which an account will owe rent.

Account Abstraction Models

Account abstraction is quite a broad concept, but narrowing it down, Account abstraction models simply aim to describe the process of abstracting away the rigid and built-in structures of accounts within a blockchain, therefore allowing them to be more flexible and adaptable. Its models hide the core technology of the user accounts from the users, enabling a more rich and less technical experience.
Developers can utilise AA models to create customised and fluid user-friendly on-chain accounts where they can define their own custom logic for storing assets and executing transactions over the network.
Through AA models, developers can create smart contracts (called programs on Solana) that can take up roles as customised user accounts and interact with other accounts, as well as execute composable program interactions.
The advantages of AA models have far more crucial consequences on how users interact with programs and contracts on-chain by enabling implementation of custom execution logic while eliminating the need for a rigid set structure and giving developers the leeway to tailor user account structures to their specific needs. To gain further understanding of why AA models crucial for the next phase of development in blockchain, we shall examine their implementation within Ethereum and Solana.

Account Abstraction in Ethereum

Until recently, account structures have been very rigid in Ethereum, leaving no room for developers to create and implement custom user accounts, therefore leading to poor user experience in storing and managing assets on-chain. This is why most popular Ethereum wallets such as Metamask only give users the option of creating EOA accounts, which means limited customization and flexibility since these accounts are controlled by private keys and can only be used to store data (ETH, ERC-20) and interact with smart contracts only by signing transactions.
With the advent of ERC-4337 merged a novel account structure on EVM called Contract Accounts which was an improvement on EOA by introducing account abstraction- its implementation gave developers on Ethereum more possibilities through smart contracts that stores data, and code. Therefore eliminating the rigidity that came with accounts that are solely controlled by private keys, replacing it with functionality that is determined by the code within the smart contracts. The role that EIP- 4337 which eventually became the ERC-4337 standard played in the implementation of account abstraction on Ethereum will be discussed in another article.

Account Abstraction in Solana

Solana blockchain since its inception has always implemented account abstraction at its core, therefore rendering accounts on Solana more flexible and simplifying the engineering of complex interactions between accounts and programs (programs are smart contracts on Solana).
The account model on solana embraces separation of concerns at its core. Non-executable accounts (data accounts) storing data. They share some similarities with Ethereum EOA- both types of accounts are mainly used to hold and manage tokens, and interact with decentralised applications and smart contacts. Transactions can also be signed only by use of a private key on both types of accounts.
With Solana however, programs can actually create and manage specific accounts by extending AA implementation through a feature called Program Derived Addresses (PDAs) therefore extending developers ability to define custom logic for managing these accounts. With PDAs, there can be flexibility in rules that govern how transactions are signed by authorising programs to execute various operations on-chain on behalf of the PDA in a way that does not require the need for private keys. Therefore abstracting the burden placed on users to manage actions without the use of private keys such as storage and management of SPL assets, batched transactions and multi-signature (multi-sig) account management features. PDAs also extend the functionality of accounts by enabling them to interact and manage executable accounts within one another; a feature known as Cross-Program Invocation (CPI).

Conclusion

Despite the difference in the implementations of AA models within these two popular chains, we can see that the benefits of AA are tremendous and hold lots of possibilities for what developers can accomplish. On Ethereum, implementations of AA models still remains an ongoing area of research and development as a result of its more rigid account structure at its core, while it is more obvious in Solana as a result of its flexible account models enabling complex interaction between account layers. One of the core use cases for AA models is the implementation of smart wallets which is anticipated to onboard the next generation of crypto users due to their advanced features such as social account recovery, permissionless asset management and other benefits.
However, presently implementation of AA models also has some challenges such as restraint in limitation of program composability by not exposing an IDL interface, a practice typically referred to as security through obscurity.

References/Further resources
Solana docs
Ethereum Organization
Vitalik Buterin, On Abstraction, https://blog.ethereum.org/2015/07/05/on-abstraction
https://developers.metaplex.com/bubblegum