Explanation of terms: a big review of Web3 account-related concepts

At the just-concluded Devcon, account abstraction is one of the hottest topics. Recently, abbreviations and codenames such as AA / EOA / SCW / 4337 can often be seen in various talks, panels and information streams. Coupled with the fact that the narrative started to move in the direction of "Onboarding next billion users", some new adjectives also started to appear before the product, such as seedless / gasless / social recovery / non-custodial. I believe that after reading these two sentences, your head has started to hurt, so let me do my best to help you sort out what these terms and concepts represent.

Before reading: This article is not a serious technical document, and may be explained or metaphorically used in imprecise but easy-to-understand language. You are welcome to use this as a starting point to explore the details of these technologies.

• EOA - Externally Owned Accounts

EOA is called external account in Chinese, and the address generated by MetaMask that we are most familiar with is EOA. It is characterized by a simple principle. For example, the generation rules are:

私钥→ 公钥→ Keccak256 哈希→ 最后20 Bytes → 十六进制字符串（EOA 地址）

It can be seen that this rule is very direct, all calculated by mathematical transformation, and the generated address does not have any structure and logic inside. There are also fixed rules when a node verifies whether a transaction is authorized by the address owner:

交易签名→ ec_recover → 公钥→ （用上面的规则生成）地址→ 对比要操作的地址

If the comparison results are consistent, the verification will be passed, and the follow-up process will be carried out;

Another setting of EOA is to act as the initiator of the transaction and pay gas, and the corresponding CA (contract account) can only be called by other CAs or EOA. That is to say, EOA is the trigger of a transaction. No matter how many contract calls follow, a transaction must be initiated by an EOA and pay enough gas to proceed.

It should be pointed out that EOA is a concept that only exists in Ethereum and other EVM-compatible chains (or EVM-like chains). Strictly speaking, mainstream non-EVM chains including BTC do not have this setting.

• CA - Contract Accounts

CA is called a contract account in Chinese (also known as an internal account ). Our common ERC-20 token contracts, DeFi business contracts, etc. have an address that looks very similar to EOA, which is CA.

In terms of setting, CA is the aborigines of the Ethereum world, and EOA and ETH are triggers and fuels for CA's business logic; in actual use, all assets on Ethereum except ETH are carried by CA, DeFi and other business logic are all implemented by CA. However, the setting of CA's inability to actively operate and pay gas also limits its ability. As early as 2016, there was a proposal to allow CA to pay for gas itself.

To put it simply, CA is an Ethereum account with internal logic, which can be either business logic (Token contract is used for bookkeeping, and pledge contract is used for lending and liquidation), or it can be account logic (such as the multi-signature logic of gnosis safe). ), and the latter is the concept of "SCW - Smart Contract Wallet" we are about to mention.

The CA's address rules are generated by calculation. There are two methods: CREATE and CREATE2, which will not be expanded here. You only need to remember that there is no necessary correspondence between the CA and the public key. For example, in the CA created by gnosis safe, you can set as many public keys as you want to unlock the assets corresponding to its address; of course, the CA can also not set any key , but it is determined by the logic of other CAs whether it can be unlocked, such as DeFi loan contracts, as long as the money is repaid, the pledged assets can be retrieved.

• SCW/A - Smart Contract Wallet/Account

The smart contract wallet should be best understood literally, that is, the wallet scheme using CA as the address, and our commonly used EOA wallet scheme uses the aforementioned public key transformation result as the address. Due to its internal logic, smart contract wallets can implement many functions that EOA cannot achieve, such as gas payment, batch transactions, permission management, offline authorization, social recovery, and more.

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

1. Gnosis safe uses smart contract wallet architecture to implement multi-signature logic;
2. Users can send different tokens to multiple addresses at the same time in an on-chain transaction, or they can complete approve and swap in one transaction when using uniswap, so as to achieve as much authorization as needed and avoid security caused by excessive authorization hidden danger.
3. Users can set different operating permissions for different assets, such as setting a higher operating threshold for PFP than ordinary ERC-20 tokens (for example, an admin key managed by a hardware wallet is required to transfer), so that even in the environment of daily use In the event of a key leak, hackers cannot transfer high-value assets, striking a balance between security and convenience.
4. Users can sign an offline authorization "Whoever can give me 100 ETH, I can transfer one of my BAYCs", so that users can complete atomic transactions P2P with others without authorizing a third-party contract.

• AA - Account Abstraction

Account abstraction is actually not a new concept. It can be traced back to some discussions in 2015. At that time, Vitalik believed that at least the cryptographic algorithm used by Ethereum to verify transactions should be replaced, such as replacing it with ed25519 with better performance ( details ). See here ), it can be said that Vitalik and EF have not stopped discussing and exploring the account abstraction scheme for 7 years. Here is an organized link tree to help you review the history.

So how do you understand account abstraction? Here I quote the description of its goal in 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 can be seen that Ethereum's expectation for account abstraction is to change the current situation that most people are using EOA, and hope that users will turn to SCW and completely remove the ecological dependence on EOA. In addition to the EIP-3074 mentioned in it, there is a more radical and long-term EIP-5003 , which is also quoted here (with 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.

It is not difficult to see that the goal of EIP-5003 is to convert EOA to CA at one time, so that all users can use SCW and completely solve the problem of forward compatibility. (After the above noun explanation, see if these abbreviations are smoother?)

At this point, everyone should have an understanding of the ins and outs of AA and its future goals. However, it should be pointed out that the concept of AA is not exclusive to Ethereum and EVM, and many chains already have different degrees of AA characteristics. For example, EOS / Polkadot / Near / Solona / Flow / Aptos … and even BTC (single-signature/multi-signature/Taproot), these chains have already made the account into a state with internal structure and even permission management ability at the time of design, and there are also StarkNet / CKB, etc. have more complete account abstraction capabilities. Speaking of which, it is not difficult to find that the AA of Ethereum is solving the historical problems caused by the unexpected popularity of EOA, thereby becoming more advanced and flexible at the account level.

• 4337 - ERC 4337

From the above discussion of AA, it is not difficult to see that ERC-4337 is only one of the many proposals in this direction, but why do people talk about it when they mention AA or SCW? Let's look at the subtitle of this document:

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

That is to say, ERC-4337 is the first time that AA's route has changed from "violent revolution" to "peaceful evolution". It no longer pursues the use of consensus layer changes to achieve AA, but instead uses SCW, a user-level solution. And in order to achieve better interoperability, ERC-4337 defines some interfaces that SCW should implement, as well as a framework for infrastructure such as meta-transaction packaging and gas payment. Its appearance enables various SCW solutions with great differences at present to have a unified user interface and share some open infrastructure built at the ecological level, which helps various scenarios to quickly implement their own SCW solutions. On the other hand, the promotion of ERC-4337 helps to promote other participants in the ecosystem to improve their compatibility with SCW, such as EIP-1271 required for signature verification and some rules that prohibit CA interaction defined in some DeFi protocols.

• Seedless

The seed here refers to the seed phrase, which is the mnemonic phrase that we are often asked to back up when we create a wallet. Then seedless means "without a mnemonic ", or it can also be said as " without a private key ". Note that this "none" does not mean that there is no key in the actual sense, but that the user does not need to back up the mnemonic/private key or perceive their existence.

A common question is, if the user does not back up the mnemonic phrase, does the user have no control over the account? Once the user switches to a new device environment, won't the account be inaccessible? That's right, just cutting off the function of users' backup mnemonics can only be regarded as a product design error, while seedless pursues that users "don't need" to know the existence of mnemonics, while still having full control over the account. In other words, the user (and only the user himself) has the ability to restore account control on the new device independently, but no longer relies on the mnemonic, which is a poor UX and too geek way. For example, the social recovery to be mentioned below is very Good one.

• Gasless

The gas here refers to the gas fee, so gasless means " gas fee-free ". Similarly, gasless does not really need to pay gas fees, but means that users do not need to be forced to understand the concept of gas, let alone purchase various native tokens in advance to pay for gas.

So who will pay for the gas? There are two cases:

One is when there is already a crypto asset in the user account, such as playing to earn to get tokens, or airdrops received, or transfers from others, as long as these tokens have a certain value and liquidity, there will be relayers willing to accept them They also help users pay for gas in order to earn revenue.

The other is that there is no valuable token in the user account, such as the account just created. If on-chain interaction is required at this time, the application side can choose to subsidize users some “targeted” gas to help them bootstrap, thereby reducing user churn. At this time, even if the consumption of gas subsidy is included, the overall user acquisition cost may be higher. Low; or it can be exchanged for some gas by letting users watch advertisements, etc. Both strategies work very well on L2 with lower gas cost.

• Social Recovery

Social recovery refers to a mechanism that leverages social connections to help users regain access to accounts in the event of lost keys. If you have used WeChat to log in to a new device, you should have had the experience of "let your two friends send xxx to your account to log in" - this is the effect that social recovery wants to achieve, but the verification party has changed from WeChat to smart contracts.

A common misunderstanding is to call the solution of using social accounts to create/log in wallets as social recovery, which is a mistake to equate "social relations" with "social platform accounts". The old smart contract wallet Argent has built-in social resilience. It requires your guardian to provide an Ethereum address so that you can provide a signature for authorization when you need to log in to a new device. However, the potential setting of this scheme is: your guardian Must be more professional than you are in managing your Ethereum account, otherwise when you need their signature, if their own account is already inaccessible, your account will suffer as well. Therefore, a more feasible way is to use the cryptographic tools such as email's cryptographic proof (DKIM Signature) or electronic passports to enhance the practicability of the social recovery scheme.

• Non-custodial

Non-custodial is arguably one of the most politically correct and abused concepts in the crypto industry, because many companies have their own definitions. Here I also share our definition of unmanaged, mainly in two aspects:

1. The wallet developer cannot operate the user's account without authorization
2. Wallet developers cannot prevent users from operating their own accounts

If you agree with these two points, then to judge whether a wallet is custodial, semi-custodial or non-custodial, you can directly test these two rules:

不满足1 → 托管；满足1 不满足2 → 半托管；1、2 都满足→ 非托管.

So what is the use of knowing what kind of hosting level it is? Users may not care about the principle behind it, as long as it is easy to use! Yes, in fact, I also partially agree with this point of view, at least at the current stage, the industry has not developed to the point where the user cognitive paradigm shift has occurred. In fact, I think three types of solutions are suitable for different scenarios:

1. Custody solution - suitable for scenarios such as exchanges, financial services of large institutions, and strong compliance, such as some services provided by coinbase. The characteristics are that the number of users is small, there is no need to deal with high-frequency interactions, and the unit price is high, which can support service providers to spend a lot of money to maintain a series of high defense systems.
2. Semi-hosted plan - suitable for relatively high-end individual user groups. They understand that the service party can review their own transactions and have the ability to prepare backup solutions in advance (such as exporting private keys), so that the security of their assets can not be affected when the service party actively or passively refuses service. In this way, you can enjoy safety and convenience in daily use, and in extreme cases, assets can be preserved. Note that this solution also has very high requirements on the operation and maintenance capabilities of the service provider. After all, there are a large number of individual users, and the daily interaction requirements with various applications are also higher. Furthermore, the requirements for data availability are high. After all, once the data saved by the server is lost It is possible that all unbacked users will never be able to access their accounts.
3. Unmanaged Scenario - For mass adoption oriented scenarios. It may sound counter-intuitive at first, but in terms of cost, the unmanaged solution is the only solution that can guarantee sufficient security and availability in low-cost per-customer scenarios. If an application party for a large-scale user scenario intends to choose the above two solutions, it must consider whether the other party can provide enough safe and usable services for its user group. All of your users will be implicated, and your business may be brought to a screeching halt. Countless cases in history tell a story, safety is no small matter, and being responsible for users is being responsible for yourself.

• MPC - Multi-Party Computation

Multi-party secure computing and zero-knowledge proof (ZKP) can be called the two "magic" of the current Web3. Once they are involved, it seems that somehow can do things that could not be done before. In fact, this is the case in some cases, especially ZKP, which can use probability to exchange feasibility; MPC achieves risk control or disaster recovery capabilities through decentralized control.

MPC is actually a paradigm, including many technical solutions, most of which refer to tss in the current Web3 context.

• TSS - Threshold Signature Scheme

Threshold signature is a distributed multi-party signature protocol, including distributed key generation, signature, and re-sharing algorithms to replace private key fragments without changing the public key.

A tss of mn refers to a public key corresponding to n private key fragments, of which the joint signature of m fragments can be successfully verified by the public key. It is not difficult to find that this logic is similar to multi-sig, and their difference is mainly in the number of public keys.

For example, the multi-signature of 2-2 is that there are 2 locks on a door, and both keys must be used to open them to open the door; the tss of 2-2 is that 1 lock is hung on a door, but the key has Two pieces, used together to open the door. For the sake of understanding, the description is not rigorous here. The combination of two keys is actually more in line with the Shamir Secret Sharing algorithm; the key fragments under the tss algorithm will not meet, but after they are signed separately, through a specific algorithm. Use the corresponding public key to verify the signature.

So does tss have to be managed or unmanaged? In fact, there is no necessary connection, it mainly depends on how the final plan is designed and chosen. The non-custodial scheme requires the user to have the ability to operate the account independently, so the user must master no less than a threshold number of key fragments. For example, if 2-3, the user needs to master 2 pieces, and the 2-2 scheme cannot achieve non-custodial, at most Do semi-custodial (such as ZenGo); but if users manage the most private key fragments, it will inevitably increase the requirements for user capabilities, and it is difficult to achieve mass adoption.

Writing here should cover the common nouns related to Web3 accounts, and the number of words is almost 5k. There are bound to be mistakes and omissions in so many contents, please feel free to slap the bricks, if you find any problems or have different opinions, just come to Twitter and ask me to mention them ( @ frank_lay2 ） , and I will also post on Twitter if there are any additions, changes or updates in the future. Sync with everyone in time.