账户抽象和原生账户抽象是什么

简单来说，ERC-4337 的账户抽象（Account Abstraction），是指在链上做一个可选的基础设施，你可以决定是否采用，采用以后会得到类似合约账户（CA）的功能，比如多签/用ERC-20 Token 支付Gas Fee/社交恢复等等，许多服务商比如stackup 就在做这种基础设施。然而这种基础设施并没有得到很广泛的采用，因为：

1.捆绑商（Bundlers）问题：只有捆绑商会参与验证，这会出现过度仰赖捆绑商的情况。
2.捆绑商的利润不足，主要是因为规模目前太小，需要更多 Dapp 选择账户抽象的基础建设来节省 Gas Fee。
3.捆绑商都集中在少数供应商（Alchemy, Pimlico, Stackup），有中心化风险。
4.除了空投的情况外，使用账户抽象服务的用户留存率很低。

也有许多L2 为了更低的gas fee，选择直接将账户抽象部署在原生链上，这被称为原生账户抽象（Native Account Abstraction），但这依然有别的问题，例如不想要这个功能的用户无法退出、只能跨链，整体灵活性不足等。

本文提到的一些名词，比如 EOA 和 CA 的区别（简单说小狐狸钱包属于 EOA，合约属于 CA）以及捆绑商（在账户抽象的生态中，用户把 UserOperations 发给捆绑商打包上链，而不是发给节点验证者/Mempool），详细的解释可以点击前面两篇文章的连结，参考过往 门学习发布的文章。

RIP-7560 是什么

是对帐户抽象（EIP-2938/ERC-4337）的改进提案。通过提出“AA_TX_TYPE” 这个新交易类型，在交易验证和执行阶段纳入了捆绑商以外的角色（区块构建者/节点验证者），不再只仰赖捆绑商打包上链，解决了前面提到的捆绑商中心化问题。此外，RIP-7560 还给出了标准化的设计，这是为了让后来者沿用时更规范。接下来，本文会具体说明 RIP-7560 这个提案改进了账户抽象的哪些标准、遇到了哪些质疑。

最核心的改变

这是共识层协定更改
最早的账户抽象提案其实是2020年9月提出的 EIP-2938。最终被社区接受并部署在以太坊，之所以最终采用了 ERC-4337 而不是 2938，就是因为 4337 不要求共识层上的更改，社区相对比较容易能够接受。

与ERC-4337 不同的是，RIP-7560 这个提案会涉及到较大的改动，即共识层协定层面的更改（从前缀RIP 也可以看出，这是更底层的、对Rollup 技术改进的提案） 。它会带来的相应好处，是可以避免直接仰赖 L2 原生链的基础建设。

增加了一个新的交易类型
引入了一种新的交易类型：第四类交易或者叫 “AA_TX_TYPE”（这其实是旧的 EIP-2938 所提出的）；它不但支持所有类 CA 的功能（比如 Visa 这篇文章提到的代付 Gas Fee/定期自动付款功能），和 ERC-4337 不同的是，它还允许现存的 EOA 提交交易，这意味着这个提案主要希望推动更广泛的采用。

交易执行逻辑

这个提案和ERC-4337 标准相容，沿用了把执行和验证分开的交易逻辑，因此会需要更多Gas；此外，根据文档，交易执行与ERC-4337 一样，验证阶段的所有步骤都需要成功完成而不会revert。验证发生后，callData 将发送到帐户进行执行。执行结束后，Paymaster 可以执行交易后逻辑。完整执行的流程如下图：

执行流程图（来源：RIP-7560 的 github 文档 ）

对该提案的主要质疑

以下主要来自 Ethereum Magicians forum 上作者发布提案时的讨论：RIP-7560：本机帐户抽象。

是否会限制基于意图的账户抽象服务的发展

基于意图的服务主要玩家应该是 Uniswap V4 和 UniswapX，其中 UniswapX 打算发展账户抽象服务，此外 ERC-7521 也提出了类似的方向。在社区讨论中，本提案的作者之一Yoav Weiss 的回应是：和RIP-7560 一起推出的还有一个名为ERC-7562 的账户抽象验证规则，意图系统的设计可以只和RIP-7560 兼容，不与验证规则相容，然后使用单独的意图求解器网络（intent-solvers network），这样既能享受RIP-7560 的好处，也不会与意图设计有冲突。

无法退出的风险

社群上有人质疑，这个提案就像「试图将操作系统嵌入到裸机中」，风险太大，对此Yoav Weiss 的回应是：这个提案就是给选择将操作系统（比如ERC-4337）嵌入裸机的链们，也就是选择部署原生账户抽象的L2 链们。以太坊生态系统有足够多的选择，用户也可以选择其它没有部署原生账户抽象的 L2。

是否过于复杂、成本过高

对于有人认为该提案的复杂性导致成本过高，作者之一的 Dror Tirosh 的回应是，这就是账户抽象本身的成本。账户抽象是源自于我们希望使用通用EVM 代码向外部数据进行验证的事实，消除这种复杂性会使区块构建器面临DoS 攻击，或者需要删除一般的EVM 代码用法，而这就是发展帐户抽象技术的初衷。

结论

目前来看，起码账户抽象基础设施的供应商，比如 Stackup 的创始人，是乐见这种共识层协定层面的更改的，这说明现在的账户抽象服务的核心问题还是采用。如果不够多Dapp 采用这个解决方案来减少Gas Fee、增加用户乐见的类CA 功能，那么捆绑商也无利可图，用户留存率永远起不来；但如果根据这个提案开发的服务，能够支援让链上现有EOA 能够无痛支持原生账户抽象，就会离终局目标（大规模采用、Metamask 支持账户抽象等）越来越近，用户与Dapp 交互的体验才会越来越好。