不求谌解

不求谌解

💻 Web Dev / Creative 💗 ⚽ 🎧 🏓
twitter
github
jike
email

Account Abstraction Exploration

image

What is Account Abstraction#

Before answering this question, let's consider two questions: "What are the types of accounts in Ethereum?" and "Why propose account abstraction?"

Account Types#

  • EOA (externally owned account)
  • CA (contract account), cannot initiate transactions actively

Why propose "Account Abstraction"#

image

From the above EOA transaction mechanism flowchart, we can identify some existing problems:

  • Private key management -> single point of failure risk (no you key, no you coin)
  • Reliance on ECDSA signatures -> unable to resist quantum computing
  • Transaction verification logic written in the protocol layer -> poor user experience

Looking at the EIP proposals in recent years, developers have always hoped that user accounts would have Turing-complete capabilities. Relevant work has been ongoing, and finally, ERC-43371 has emerged. The industry has also unified the term "Account Abstraction".

image

This solution does not require modification of the protocol layer. It abstracts the transaction verification of account abstraction from the protocol layer and places it in the application layer. However, even though it is in the application layer, it still belongs to a technical standard. Newly developed smart contract wallets should adhere to this standard2.

Returning to the initial question - "What is account abstraction". After reviewing the above content, we probably understand the problems with the EOA transaction mechanism and the transaction flow of ERC-4337. So we can try to define "account abstraction" as follows:

Account abstraction is a technical solution that uses programmable methods to verify the validity of transactions.

Use Cases#

  • Recovering private keys
  • Gas fee delegation, batch authorization, and transactions
  • Permission management

Users can recover their account private keys, solving the problem of "single point of failure". Developers can introduce two-factor authentication in the Web3 world for authorization, and even if the private key is lost, it can be recovered using an email.

Users can have a better transaction experience without having to understand the concept of Gas. In the DeFi scenario, the steps of pre-authorization and then transaction can be merged into a single transaction, making it more convenient.

Users can manage the permissions of their accounts. In a company or DAO organization, managers can set different spending permissions based on different user roles.

Some Thoughts#

Although many products have joined the "AA" track, it is still in a very early stage. I really like the analogy that lixin made in this podcast3, where "AA" is to "EOA" as "automatic transmission cars" are to "manual transmission cars". When automatic transmission cars first appeared, they were filled with doubts about fuel consumption and safety.

Perhaps ERC-4337 has laid the framework for account abstraction, but no one can predict its next form - the relevant standards are still being formulated. This road is full of unknowns, opportunities, and perhaps thorns. But that's also what makes it so fascinating, isn't it?

Footnotes#

  1. EIP-4337

  2. What vitality will account abstraction bring to Web3?

  3. Ep.29: HODLong 后浪

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.