Understanding the Account Abstraction That Determines the Future of Web3 in One Article

One Article Explains the Account Abstraction That Shapes the Future of Web3

Author: Block Engine

Ethereum account abstraction is a hot topic in the entire Ethereum ecosystem. Founder Vitalik has even published multiple articles specifically discussing the importance of account abstraction to Ethereum, which is a key work for Ethereum to target the next billion users. So, what is “account abstraction”?

“Account abstraction” is a proposal aimed at improving the interaction between users and Ethereum, and it is also a topic that is increasingly being discussed in the cryptocurrency community. However, you may wonder what exactly is “account abstraction” and why should you care about it? This article aims to help you understand account abstraction by introducing its past, present, and future. We will answer all questions about this topic, especially the “who”, “what”, “why”, and “how” of account abstraction.

Key points summary:

• CertiK Security Report Nearly 1 billion USD will be stolen in 2023 due to fraud, vulnerability exploitation, and hacker attacks.
• Doodles version of the holey shoes sold out in 3 days, blue-chip NFTs sell to save themselves.
• With the innovative low transaction volume, where is the way out for NFTs?

• Programmable self-managed accounts (“smart accounts”) can reduce friction for new users joining the web3 ecosystem. However, Ethereum’s design limits the widespread adoption and use of smart accounts.

• Account abstraction introduces significant changes, paving the way for the widespread adoption of trustless and censorship-resistant smart accounts. Different methods are currently being considered to implement account abstraction, each with its own unique advantages and trade-offs.

What is account abstraction?

Like other new concepts in Web3, account abstraction is difficult to define. However, we can better understand it by first interpreting and discussing various terms related to Ethereum account abstraction:

1. Abstraction: A (quite complex) term in computer science, roughly meaning to hide information about the system or application, so that less is known about the underlying processes when using it. It is also defined as “the process of hiding system complexity by providing an interface that is easier to operate”.

2. Account: A representation of a user on the blockchain, capable of sending or receiving transactions and interacting with other on-chain accounts. Ethereum has two types of accounts: Externally Owned Accounts (EOAs) and Contract Accounts (also known as “smart contracts”).

2a. Externally Owned Account (EOA): An Ethereum account generated using wallet software (such as MetaMask), encrypted and managed by a pair of public and private keys. An EOA is “active” (it can initiate transactions and pay network fees for EVM execution). However, it is limited to performing basic operations such as sending Ether or interacting with contracts.

2b. Contract Account: An Ethereum account deployed in the form of a smart contract, controlled by the logic written in the code (rather than a private key). Contract accounts are “passive”: they can only send transactions based on the transactions of EOAs and cannot pay fees. However, they are programmable and can execute arbitrary logic based on the code stored at their address.

3. Wallet: The interface for managing Ethereum account funds – How a wallet operates depends on the type of account it is connected to. Wallets based on EOA (such as MetaMask) require a private key to authorize transactions. Meanwhile, smart contract wallets are connected to contract accounts and can use arbitrary logic to authorize transactions (e.g., using multi-signature schemes). With these definitions, we can now define the account abstraction.

Definition of Account Abstraction

Account abstraction is a proposal aimed at improving the flexibility of Ethereum account management and behavior. This goal is achieved by introducing account contracts: special-purpose smart contracts that define and manage user Ethereum accounts (now referred to as smart accounts).

With account abstraction, you can enjoy programmable fund access by using a smart contract wallet instead of relying solely on private keys to ensure security. This is possible because your smart account can customize the rules for transactions and asset transfers.

So, how does “abstraction” fit into all of this?

From a network perspective, “account abstraction” means that the Ethereum protocol does not see the details of account types. Each account (including self-regulatory accounts) is just a smart contract, and users are free to decide how to manage and operate individual accounts.

From a user perspective, “account abstraction” means that certain technical details of interacting with Ethereum accounts are hidden behind higher-level interfaces. This improves wallet design and greatly reduces the complexity of using web3 applications.

It is necessary to clarify some concepts because confusion surrounding account abstraction comes from not knowing (a) what is being abstracted and (b) where the abstraction takes place. Accounts are not necessarily abstracted from users (even if they are abstracted from the protocol). You still need a wallet address to receive funds and a signing key to ensure that only you can use the funds.

From a user’s point of view, account abstraction is more like using a smart account that abstracts some of the details of interacting with the blockchain. Here is the scenario of a user interacting with a dapp for the first time:

With account abstraction, wallet developers can create systems that handle these processes in the background and simplify the user experience of web3. Some use cases (which we will discuss in detail later) include not needing to store mnemonic phrases/private keys, not needing to pay network transaction fees, and not even needing to create on-chain accounts themselves.

Benefits of Account Abstraction

As mentioned earlier, account abstraction eliminates much of the friction when using web3 wallets and interacting with dapps. This brings web3 closer to the user experience of web2, where all users, whether beginners or experienced, can benefit from the same level of flexibility, security, and ease of use.

In particular, account abstraction has a significant impact on self-custody in the future. With the functionality provided by account contracts, using a web3 wallet is like using a bank account or application without trusting the bank.

In the following chapters, we will introduce the different aspects of account abstraction and discuss how they improve the user experience of Ethereum. Specifically, we will discuss signature abstraction, fee abstraction, and nonce abstraction.

Signature Abstraction

Currently, transactions from externally owned accounts (EOAs) must have a signature generated using the Elliptic Curve Digital Signature Algorithm (ECDSA) with the account’s private key to be valid. This provides a simple security model for most EOAs: as long as the private key remains in the user’s possession, the funds are secure. However, it also has some limitations:

1. It is well known that EOAs are difficult to secure, especially as malicious actors are constantly developing new methods to compromise private keys. We have witnessed numerous phishing attacks, social engineering, deception, malicious software injections, and similar attacks challenging the security of web3 users.

2. Self-custody can feel like an extreme sport. Unlike regular bank accounts, if you lose your mnemonic phrase/private key, you cannot “recover” your EOA wallet. This poses a challenge for new users who must cope with the potential loss of assets in an Ethereum account that cannot be recovered.

Signature abstraction addresses these issues by no longer treating ECDSA signatures as the default authorization mechanism for externally owned accounts. Instead, users can define custom rules for authorizing wallet-initiated transactions. In other words, you can decide what constitutes a valid transaction.

Implementing signature abstraction opens up possibilities for more advanced authorization schemes. This way, using a web3 wallet feels similar to web2 banking applications, if not better. Here are some use cases:

1. Transaction limits: If the amount exceeds a predetermined limit, the wallet connected to your smart account can reject the transaction (or require additional authorization). Sound familiar? That’s right – banks already do this to protect your accounts and credit cards from fraud, unauthorized use, and other security-related impacts.

2. Multi-party approvals: You can delegate partial control of your account to trusted individuals, known as “guardians.” Guardians can be friends, family members, service providers, or even your own independent device (such as a hardware wallet). This allows you to enable web2-style multi-factor authentication (MFA) for your wallet by requiring guardian approval for transactions that withdraw funds from your smart account.

3. Key rotation and revocation: With smart accounts, if a previous key is lost or stolen, you can generate a new signing key. For added security, you can have guardians freeze your account during the recovery process and require their approval for the key rotation/revocation process (i.e., social recovery). This is similar to freezing a credit card in case of loss or theft without losing access to your bank account.

4. Trusted Sessions: Do you dislike having to approve every operation when interacting with dapps in your browser? Great! You can use smart accounts to create special “session keys” that allow applications to automatically sign transactions within a specific timeframe. This means you can interact with dapps, such as playing blockchain games, without being bothered by wallet pop-up windows.

At a high level, session keys are based on smart contracts that control the interaction between your account and dapps. You always have control over the session keys and can manage the signing permissions of dapps, such as how much balance can be deducted or which functions can be called.

5. Automatic Payments: Similar to the idea of session keys, you can approve service providers to “extract” funds from your smart account (within predefined rules). This allows you to set up recurring payments and subscriptions using web3 wallets. Can you imagine using your Ethereum account to pay for Netflix subscriptions or utility bills?

Fee Abstraction

Currently, every Ethereum transaction must have a “transaction fee” that represents how much the sender is willing to pay for the execution of the transaction. The transaction fee is measured in Ether, which is the native token of Ethereum. This creates some issues, especially for new users who now need to acquire Ether before sending transactions.

Account abstraction does not eliminate the need to pay transaction fees, but it abstracts away the details of how and when users choose to pay the fees (fee abstraction). For example, account abstraction can enable “sponsored transactions,” where another account pays the gas fee for the user’s transaction. Some benefits of sponsored transactions:

1. No need to hold ETH for paying network transaction fees: Have you ever wished to pay transaction fees with ERC-20 tokens in your wallet? With sponsored transactions, you can have an ETH relayer pay the fees for your transactions, and then pay with other tokens like DAI or USDC.

2. Feeless transactions: Dapp developers can sponsor transactions to minimize the friction for new Ethereum users. You can basically use web3 applications without understanding “gas” and enjoy the one-click experience provided by web2 applications.

3. Social Login: Dapps may deploy a contract wallet on your behalf, solving the pain point of setting up a wallet before sending on-chain transactions. And the best part? The wallet can use identity authentication infrastructures like Web3Auth and WebAuthn, allowing users to create Web3 accounts using existing credentials such as email addresses or Facebook/Twitter accounts.

Nonce Abstraction

Smart accounts on Ethereum have a special feature: batch transactions. Through batch processing, you can merge multiple operations into one on-chain transaction, reducing the cost and complexity of interacting with dapps. The following are important reasons for transaction batching:

Your EOA stores a value called “nonce”, which shows how many transactions you have sent (you can think of it as a transaction counter). New transactions must strictly increase the nonce value by 1 to be valid – this rule prevents others from “replaying” the same transaction and stealing your funds (which could happen).

But there is also a problem. Nonces force you to process transactions in a first-in-first-out (FIFO) manner. Suppose there are two transactions (A and B), with nonces of 0 and 1 respectively. In this case, you need to send transaction A and wait (for its execution) before sending transaction B.

If transaction B is sent while transaction A is not completed, the former will be rejected because its nonce exceeds the specified range (EOA’s current nonce + 1). In fact, this is also an important reason for “stuck transactions” when using wallets.

Nonce abstraction allows you to create custom replay protection mechanisms (instead of Ethereum’s protocol strictly ordering transactions). For example, you can have a nonce scheme that allows parallel processing of multiple transactions. This will solve the problem of transaction congestion/stagnation and significantly improve interaction with dapps.

However, nonce abstraction is difficult to implement in practice and may undermine certain invariants that are crucial for security and user experience (such as transaction hash uniqueness). This is where transaction batching comes in:

Because smart accounts can process multiple transactions simultaneously, the need for complex nonce abstraction schemes largely disappears. Going back to the previous example, we can imagine that transaction A and transaction B are just part of a hypothetical operation, such as asset exchange on Uniswap:

Transaction A: Approve the Uniswap contract to access your tokens;

Transaction B: Complete the token exchange

By batching the approvals and exchange workflow into one transaction, gas fees are lower and waiting time is shorter when using dapps.

Future prospects for account abstraction

Ethereum founder Vitalik Buterin first proposed this concept years ago, but there are still some differences in the best way to implement account abstraction. For example, implementing EIP-3074 and EIP-5003 would allow existing EOAs to upgrade to smart accounts. However, these proposals require a hard fork of Ethereum, and the community is currently focused on more urgent upgrades, so it seems impractical at the moment.

In contrast, EIP-4337 has gained broad support because it achieves account abstraction without the need for extensive modifications to the Ethereum protocol. However, for users currently using EOA-based wallets, this means that assets must be transferred from EOAs to newly deployed contract accounts – considering the high network transaction fees on Ethereum, this process can be both complex and expensive.

We believe that account abstraction is key to providing Web3 newcomers with a seamless experience similar to Web2. However, we also understand that EOA alone cannot guarantee mass adoption of cryptocurrencies. Therefore, finding a way to provide the benefits of account abstraction without disrupting familiar wallet operations for users is a major direction for future innovation.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!