不求谌解

不求谌解

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

Exploring Account Abstraction

What is Account Abstraction#

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

Account Types#

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

Why Propose "Account Abstraction"#

image

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

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

Over the past few years of EIP proposals, developers have consistently hoped that user accounts would possess Turing-complete capabilities. Related 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 modifications to the protocol layer, achieving the separation of transaction verification for account abstraction from the protocol layer to the application layer. However, even at the application layer, it still belongs to a technical standard, and newly developed smart contract wallets should adhere to this standard2.

Returning to the initial question—"What is account abstraction?" Reviewing the above content, we have likely understood the current issues with the EOA transaction mechanism and the transaction process of ERC-4337. Thus, we can attempt to define "account abstraction":

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

Application Scenarios#

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

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

Users can enjoy a better transaction experience without needing to understand what Gas is. In DeFi scenarios, the steps of authorizing first and then transacting can also be merged into a single transaction for convenience.

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

Some Thoughts#

Although we have seen many products entering the "AA" track, it is still in a very early stage. I really like Lixin's analogy in this podcast3: "AA" to "EOA" is like "automatic cars" to "manual cars." When automatic cars first appeared, there were many doubts about fuel consumption and safety.

Perhaps ERC-4337 has already laid the framework for account abstraction, but no one can predict its next product form—related standards are still being formulated. This path is filled with unknowns and opportunities, perhaps thorns as well. But isn't that what makes it most fascinating?

Footnotes#

  1. EIP-4337

  2. What Vitality Will Account Abstraction Bring to Web3?

  3. Ep.29: HODLong The Next Wave

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