Account Abstraction 初探
什么是账户抽象
在回答这个问题之前，我们先思考两个问题「以太坊有哪些账户类型」以及「为什么要提出账户抽象」。
账户类型
- EOA(externally owned account)
- CA(contract account)，不能主动发起交易
为什么提出「账户抽象」
从上面的 EOA 交易机制流程图中我们可以发现目前存在的一些问题：
- 私钥管理 -> 单点失败风险（no you key, no you coin）
- 依赖于 ECDSA 签名 -> 无法对抗量子计算
- 交易验证逻辑写在协议层 -> 糟糕的用户体验
纵观近几年的 EIP 提案，开发者们始终希望用户的账户具备图灵完备的能力。相关工作一直都在进行，终于 ERC-4337[1] 应运而生。业内也统一了「Account Abstraction」的说法。
这个方案不需要修改协议层，实现了把账户抽象的交易验证从协议层抽离出来，放在了应用层。但是虽然在应用层，它还是属于一个技术标准，新开发的智能合约钱包们应该遵循这个标准[2]。
重新回到一开始的问题——「什么是账户抽象」。回顾上述内容，我们大概已经明白了 EOA 交易机制目前存在的问题以及 ERC-4337 的交易流程。于是可以试着给「账户抽象」下个定义：
账户抽象是一种使用可编程方式来验证交易有效性的技术方案
应用场景
- 找回私钥
- Gas 费代付，批量授权及交易
- 权限管理
用户可以找回账户私钥，解决了「单点失败」的问题，开发者可以在 Web3 的世界中引入 Two-factor 验证来授权，私钥丢失了也可以使用邮箱找回。
用户可以获得更好的交易体验，不必再去理解什么是 Gas 的问题。Defi 场景下的先授权再交易步骤，也可以合并成一笔交易，更加地方便。
用户可以对账户进行权限管理，在一个公司或者 DAO 组织，管理者可以根据不同的用户角色设置不同的支出权限。
相关产品
一些思考
尽管已经看到有很多的产品加入了「AA」这个赛道，但它目前仍处于非常早期的阶段。我很喜欢 lixin 在这个播客[3]中的类比，「AA」之于「EOA」就如同「自动挡汽车」之于「手动挡汽车」。当自动挡汽车刚出现的时候，会充斥着费油和不安全的质疑声。
或许 ERC-4337 已经给账户抽象搭好了框架，但是谁也无法预测它的下一个产品形态——相关的标准仍在制定中。这条路上充满了未知，机会，也许是荆棘。不过这也正是它最迷人的地方不是吗？