Account Abstraction 初探

什么是账户抽象

在回答这个问题之前，我们先思考两个问题「以太坊有哪些账户类型」以及「为什么要提出账户抽象」。

账户类型

EOA(externally owned account)

CA (contract account)，不能主动发起交易

为什么提出「账户抽象」

从上面的 EOA 交易机制流程图中我们可以发现目前存在的一些问题：

私钥管理 -> 单点失败风险（no you key, no you coin）

依赖于 ECDSA 签名 -> 无法对抗量子计算

交易验证逻辑写在协议层 -> 糟糕的用户体验

纵观近几年的 EIP 提案，开发者们始终希望用户的账户具备图灵完备的能力。相关工作一直都在进行，终于 ERC-43371 应运而生。业内也统一了「Account Abstraction」的说法。

这个方案不需要修改协议层，实现了把账户抽象的交易验证从协议层抽离出来，放在了应用层。但是虽然在应用层，它还是属于一个技术标准，新开发的智能合约钱包们应该遵循这个标准2。

重新回到一开始的问题 ——「什么是账户抽象」。回顾上述内容，我们大概已经明白了 EOA 交易机制目前存在的问题以及 ERC-4337 的交易流程。于是可以试着给「账户抽象」下个定义：

账户抽象是一种使用可编程方式来验证交易有效性的技术方案

应用场景

找回私钥

Gas 费代付，批量授权及交易

权限管理

用户可以找回账户私钥，解决了「单点失败」的问题，开发者可以在 Web3 的世界中引入 Two-factor 验证来授权，私钥丢失了也可以使用邮箱找回。

用户可以获得更好的交易体验，不必再去理解什么是 Gas 的问题。Defi 场景下的先授权再交易步骤，也可以合并成一笔交易，更加地方便。

用户可以对账户进行权限管理，在一个公司或者 DAO 组织，管理者可以根据不同的用户角色设置不同的支出权限。

相关产品

thirdweb

unipass

biconomy

visa

一些思考

尽管已经看到有很多的产品加入了「AA」这个赛道，但它目前仍处于非常早期的阶段。我很喜欢 lixin 在这个播客3中的类比，「AA」之于「EOA」就如同「自动挡汽车」之于「手动挡汽车」。当自动挡汽车刚出现的时候，会充斥着费油和不安全的质疑声。

或许 ERC-4337 已经给账户抽象搭好了框架，但是谁也无法预测它的下一个产品形态 —— 相关的标准仍在制定中。这条路上充满了未知，机会，也许是荆棘。不过这也正是它最迷人的地方不是吗？

Footnotes

EIP-4337 ↩

账户抽象将给 web3 带来怎样的生命力？ ↩

Ep.29: HODLong 后浪 ↩