English | 中文版

One of the most talked-about subjects at DevCon was account abstraction. Recently, you may have noticed acronyms and abbreviations like AA, EOA, SCW, and 4337 in a variety of presentations, panels, and streams. After reading these two sentences, your brain must already be hurting. Next, I'll try to help you figure out what all these terms and ideas really mean.

This article is not a serious technical document, so it may use words that aren't exact but are easy to understand. You are invited to use it as a starting point to learn more about these technologies.

EOA: Externally Owned Accounts

EOA stands for Externally Owned Accounts. The MetaMask accounts we are very familiar with are EOAs. It has a very simple mechanism. For example, to generate an EOA, all you need to do is to generate in order:

Private Key → Public Key → Keccak256 hash → last 20 Bytes → hexadecimal representation

The final hexadecimal will be the address of the EOA. As you can see, this rule is quite basic and entirely mathematical. There is no extra structure or logic in the address that was created.

When an node verifies whether a transaction is approved by the address owner, it follows a similar set of fixed rules:

Transaction Signature → ec_recover → Public Key → Address

If the address recovered is the same as the address the transaction wants to operate on, which means that the owner of the address signed the transaction, then the node will process the transaction; otherwise, the transaction will fail.

It is worth noting that in EVM chains, EOA has the exclusive right to initiate transactions and pay for gas. CA (contract account) on the other hand, cannot start transactions and must be called by other CAs or EOAs. The distinction between EOA and CA is also unique to EVM chains, as there is just one account type in many other blockchains, including Bitcoin.

CA - Contract Acccount

CA is an abbreviation for Contract Account (also once called internal account). Most likely, you are already familiar with CAs and interact with them every day. Commonly used ERC-20 token contracts, DeFi business contracts, and other contracts with an address that looks like EOA are all examples of this.

In terms of design, CA is the native of Ethereum, and EOA and ETH are the triggers and fuel to execute CA's business logic. All ethereum assets, with the exception of ETH, are held by CA, and non-native functionalities like DeFi are entirely implemented by CA. Even though there was a proposal as early as 2016 to let CA pay for its own gas, it still can't do so today, limiting what CA can potentially achieve.

In essence, a CA is an Ethereum account with its own internal logic, which can either be business logic (like token contracts for bookkeeping and pledge contracts for lending and clearing) or account logic (like the multi-signature logic of gnosis safe). The latter is precisely the "SCW - Smart Contract Wallet" we are about to discuss.

The CA's address can be calculated deterministically, and there are two methods: CREATE and CREATE2. You only need to keep in mind that a CA and a public key do not have a one-to-one correspondence. For instance, gnosis safe's CA can have any number of public keys to unlock the assets associated with its address. A CA can also be used without any key at all; in this case, its internal logic will decide who has permission to use it. For instance, under the terms of DeFi's lending agreement, the pledged assets locked inside the account may be reclaimed immediately upon repayment of the loan.

SCW/A: Smart Contract Wallet/Account

Smart contract wallet is fairly straightforward to understand; it is basically a wallet made of a CA instead of a EOA. Since it has a highly customizable internal logic, a smart contract wallet can do a lot of things that EOA can't, such as gas payment, batch transactions, permission management, offline authorization, social recovery, etc...

Here are a few examples to demonstrate the capability of smart contract wallets:

1. Gnosis Safe uses smart contract wallet to implement multi-signature logic.

2. Users can send different tokens to multiple addresses in one single on-chain transaction.

3. When using UniSwap, users can approve and swap in a single transaction, allowing them to only authorize what is necessary and prevent security risks brought on by excessive authorization.

4. Users can set differentiated policies for different assets, such as a stricter policy for PFPs than for standard ERC-20 tokens (e.g., requiring a hardware wallet signature to approve your Bored Ape transfer). By doing so, even if the primary key is compromised, hackers still cannot steal the more valuable assets. By fine-tuning the policies, smart contract wallets can offer a safer and smoother user experience.

5. Natively support P2P atomic swaps without relying on any third-party contract. All the users need to do is signing an authorization, "whoever gives me 100 ETH can have one of my BAYCs."

AA - Account Abstraction

Account abstraction is not a new idea, with early discussions dating back to 2015. At the time, Vitalik believed it was important to at least be able to customize the cryptographic algorithm used by Ethereum to validate transactions, such as replacing the ECDSA with the higher-performing ed25519. It is safe to say that Vitalik and EF have continued to discuss and explore account abstraction over the past seven years. Here is a well organized link tree to help you understand the history if you are interested.

So what exactly is account abstraction. Here is a brief description from ERC-4337:

Achieve the key goal of account abstraction: allow users to use smart contract wallets containing arbitrary verification logic instead of EOAs as their primary account. Completely remove any need at all for users to also have EOAs (as status quo SC wallets and EIP-3074 both require)

It's clear that Ethereum's goal for account abstraction is to change the current situation where most people use EOA. They want users to switch to SCW so that the ecosystem no longer depends on inflexible EOA that limits what people can do with their wallets. In addition to EIP-3074, which is mentioned there, there is also EIP-5003, which is more radical and has a longer-term focus (with some omissions):

EOAs … are limited by the protocol in a variety of critical ways. These accounts do not support rotating keys for security, batching to save gas, or sponsored transactions to reduce the need to hold ether yourself. There are countless other benefits that come from having a contract account or account abstraction, like choosing one’s own authentication algorithm, setting spending limits, enabling social recovery, allowing key rotation, arbitrarily and transitively delegating capabilities, and just about anything else we can imagine.

…This EIP provides a path not to enshrine EOAs, but to provide a migration path off of them, once and for all.

The goal of EIP-5003 is clear: to convert all EOA to CA at once so that all users can use SCW, thus circumventing the problem of backward compatibility.

You should now understand the fundamentals of AA as well as its long-term goals. It is worth noting that the concept of AA is not unique to Ethereum and EVM. Many chains already have varying degrees of AA natively. Wallets can, for example, customize their internal logic and manage privileges on EOS, Polkadot, Near, Solona, Flow, Aptos, and even BTC. Account abstraction capabilities that are even more comprehensive can be found in chains such as StarkNet and CKB. At this point, it should be clear that the current AA movement in Ethereum is an attempt to address the historical legacy left by EOA's unexpected popularity in order to create a more sophisticated and adaptable account system for the ecosystem.

ERC-4337

It is clear from the discussion of AA above that ERC-4337 is only one of many proposals in the push of AA on Ethereum. But why do people always bring it up when discussing AA or SCW? The document's subtitle offers some clue:

An account abstraction proposal which completely avoids consensus-layer protocol changes, instead relying on higher-layer infrastructure.

ERC-4337 shifts AA from "violent revolution" to "peaceful evolution." Instead of using lower-level consensus layer changes to achieve AA, it now only relies higher-layer infrastructures that are easier to push. To improve interoperability, ERC-4337 defines common interfaces and infrastructure frameworks for SCW, such as meta-transaction packaging and delegated gas payment. ERC-4337 allows different SCW solutions to have a unified user interface and shared ecosystem infrastructures, allowing developers to easily implement their own SCW solutions. It also makes SCW more compatible with the rest of the ecosystem by getting more support for EIP-1271, which is needed for SCW to interact with other contracts, and by changing the fact that some DeFi protocols currently don't let CA interact with them.

Seedless

The seed here refers to the seed phrase, which is a set of mysterious words that we are often asked to back up when we make a wallet. This means that there is no seed phrase or private key. Note that "seedless" doesn't mean there isn't a key, but that the user doesn't have to back up the key or even know its existence.

A common question is: If the user doesn't have the seed phrase, does that mean the user has no control over the account? Won't the user's account be inaccessible once they switch to a new device? Yes, it's not enough to just stop users from accessing the seed phrase. The idea behind seedless is that the user (and only the user) can have root control of their account without having to use a bad, overly geeky UX like a seed phrase. A possible solution is a mechanism like the one we'll talk about below: social recovery.

Gasless

Gas means "gas fee," and "gasless" means "no gas fee." Gasless doesn't mean no gas fee. It means you don't need to understand gas or buy native tokens to pay for it.

So who is going to pay for the gas? There are two cases:

When users already have cryptocurrency in their account, like play-to-earn tokens, airdrops they have received, or transfers from others. Relayers will accept these tokens as long as they have some value and liquidity and are willing to pay the user's gas in exchange for a small fee.

When users have a new account or no valuable tokens, the app can subsidize gas to help them get started. This can help apps reduce user churn and thus achieve a lower overall user acquisition cost, even when the gas subsidy is considered. In exchange for gas, the user can also watch advertisements. Both of these strategies work well on L2, where gas prices are low.

Social Recovery

Social recovery is a mechanism that uses users' social connections to help them regain access to their account if they lose their key. If you've ever tried to recover your WeChat or Facebook account, you've probably seen messages like "having two of your friends send xxx to your account to log in." That is what Social Recovery is all about, except in the context of Ethereum, the verifying party has shifted from WeChat/Facebook to a smart contract.

It's a common mistake to assume that wallets using social accounts for login are doing social recovery. These solutions frequently just use social accounts for login and recovery through centralized servers. To find a genuine social recovery mechanism, one can look at Argent, one of the most well-known smart contract wallets. It requires your guardian to provide an ethereum address that can be used as a signature for authorization when you need to log in to a new device. This solution assumes your guardian is better at handling wallets than you are, as theirs become your insurance. Such an assumption can cripple mass adoption because most first-time web3 users lack experienced web3 users to serve as guardians. Therefore, relying on everyday tools with built-in cryptography, such as email cryptographic proof (DKIM Signature) or chip-enabled passports, is a more practical strategy.

Non-custodial

One of the most overused and politically correct terms in the cryptocurrency sector is undoubtedly non-custodial. Since every wallet project frequently has its own definition of the term, I'll also share ours here, which has two main components:

1. The wallet provider cannot operate the user's account without permission

2. The wallet provider cannot stop users from operating their own accounts

If you agree on these two points, you can use them to determine whether a wallet is custodial, semi-custodial, or non-custodial:

• Does not satisfy 1 → Custodial

• Satisfy 1 but not 2 → Semi-custodial

• Satisfy both 1 and 2 → Non-custodial

What good is knowing a wallet's custody level? Users may only want a working solution. I agree with this partially. At least for now, the majority of people care very little about the web3 ideals. In fact, I think each of the three types of solutions works best in different use cases:

1. Custodial solutions are good for exchanges, large institutions, and situations that require a high level of regulatory compliance. One such example is Coinbase. These solutions have low Web2 user volume, limited user interaction, and high revenue per user (ARPU). Only then can the provider afford a high security system that is costly on a per user basis.

2. Semi-custodial solutions suit seasoned users. They're aware of the provider's ability to censor their transactions and know how to prepare a backup (such as exporting private keys) so they can still control their account in the event of an active or passive denial of service. This allows users to have the peace and comfort without sacrificing control. This solution places high demands on the provider's DevOp capability, as a large volume of individual users will generate tons of requests. Data availability is extremely important in this case, as users without backups may never be able to access their accounts once server data is lost.

3. Non-custodial solutions are best for mass adoption use cases. Only non-custodial solutions can guarantee security and availability in a low ARPU scenario. If an application serving a large user base chooses either of the above options, it must consider whether the provider offers sufficient security and availability. If insider mischief or hacking causes the service to go down, all its users will be affected and its business may collapse. Security is no small matter, and being responsible for your users is being responsible for yourself.

TSS: Threshold Signature Scheme

Threshold Signature Scheme (TSS) is a distributed multi-party signature protocol that includes algorithms for distributed key generation, signing, and key rotation that does not change the public key.

An m-n TSS means that a public key corresponds to n private key fragments, and m of them is needed to successfully generate a signature. This logic is very similar to multi-sig, and the main difference between them is the number of public keys. TSS has a single public key, whereas in multi-sig there are many of them.

A 2-2 multi-sig is a door with two locks that must be opened with both keys; a 2-2 TSS is a door with one lock but two keys that must be turned together to open the door. To be more specific, the key pieces of the TSS algorithm are not combined to form a single private key, but rather generate signatures that can be verified together.

Is there a direct relationship between TSS and custody level? The answer is No. The cryptography design matters. Non-custodial solutions require the user to be able to operate the account independently, which means controlling at least the threshold number of key fragments. The user must control at least two fragments to control 2-3 TSS. 2-2 TSS is inevitably semi-custodial because the user can only control one fragment (such as ZenGo). Non-custodial TSS solutions often hurt user experience because users must now manage the majority of key fragments, the loss of which will result in account lost forever.

This nearly 5,000-word article should cover most terms related to Web3 accounts. Such length inevitably leads to errors and omissions. If you find any, please let me know and you can reach me on Twitter at @frank lay2. I will also keep you up to date on Twitter with any additions, changes or updates.