编者注：本文首发于公众号 “因雨成歌”，EthFans 经授权转载。
概述
账户抽象 [[Account Abstraction]] 是以太坊上的一种待实现的技术方案，按现阶段设计，在实现账户抽象之后，一个智能合约账户也可以主动发起交易，而无需依赖 “元交易” 的机制。
背景
以太坊的账户有两种类型，一种是外部账户，另一种是合约账户。外部地址是由用户的公钥经过哈希运算后取的后 20 个字节，形为 0x76D836358E7A2BB0F26c32Ce61Dc8DD540b02F7D 。目前的以太坊的事务类型只有一种，必须由外部地址发起，合约地址无法主动发起事务。因此，任何合约自身状态的改变，必须依赖于一个外部地址发起的事务，无论是一个多重签名账户，还是混币器，或是任何智能合约的配置变更，都需要由至少一个外部账户触发。这样的设计让以下两件事情无法完成。
1. 无需以太的主动事务
由于事务必须由外部账户发送并支付费用，而该费用是用以太（ETH）为单位结算的，因此该外部地址必须持有以太。当然，这种说法并不严谨，当 gasprice 为 0 时，事务无需支付手续费。可这种情况非常极端（见 [1]） ，对于普通用户来说，这样的事务可能永远无法入块。
2. 非secp256k1的原生验证方式
由于事务必须由外部账户发起，因此每笔事务的合法性检查就是在验证事务是否提供了该账户对应的合法的 secp256k1 签名。而如果要在验证中引入复杂逻辑（例如多重签名或社交恢复）或是采用不同的验证算法（例如 Eddsa、BLS、secp256r1 签名算法，使用这些签名算法是因为它们有特别的特性，或是对零知识证明友好，或是方便签名聚合减少带宽开销，或是与现有的硬件验证器兼容），则必须在智能合约层面实现。这也同时意味着，这种验证仍要由至少一个外部账户发起，并通过以太坊的 secp256k1 签名验证。
上述两条约束让普通用户很难使用以太坊。首先，无论使用以太坊上的什么应用，用户都必须持有以太（并承担以太价格波动的风险）。其次，用户需要处理复杂的费用逻辑，gas price、gas limit、事务阻塞，这些概念对用户来说过于复杂。许多区块链钱包或应用试图通过产品优化提高用户体验，但效果甚微。
如何解决上述两个问题呢？
核心思路在于将 “验证所有权” 的操作由共识层下放到合约层，即不去检查事务的发送者是否与资产所有人一致，而是检查其是否提供了合法的凭据。具体的做法为：用户对事务内容进行签名，并将签名交由一个第三方操作上链，这个第三方我们在接下来的文章中用 “运营商（operator）” 来指代。这种事务被称为 “元交易”。根据设计理念的不同，元交易方案大致分为两类：
1. 以账户为中心——智能钱包
以账户为中心的方案的目标是为用户创建一个基于智能合约管理的账户，用户可以使用该账户与区块链上的任意合约交互。智能钱包的理念由来已久，但在近一年来有了长足的进展。根据「智能钱包趋势」的统计（注：作者为本人，特此声明），目前「智能钱包」的运营商超过 10 家，总用户数超过 14 万。其中大部分智能钱包采用了为用户代付链上手续费的运营策略，再通过其它方式向用户收取费用。
以账户为中心的方案本质上是一套区块链账户系统，通用性强，且可以提供包括账户恢复、大额审批、转账白名单等附加特性。智能钱包的运营者协助用户创建、管理区块链上的可编程身份，并提供事务上链服务。一般来说，智能钱包会为用户支付链上的 gas 费，同时通过中心化计费系统向用户收取费用。这套模式和传统世界里的账户服务很像，例如运营商支付基站、光纤等费用，而用户只要充值话费就可以使用通信服务，而无需关心底层复杂的逻辑。
智能钱包也有其掣肘。一是安全问题，二是费用问题。
安全：如果账户合约存在漏洞，那么所有用户的资产都会遭受风险。专业的代码编写、安全审计和形式化验证，都只能减少风险发生的可能，而不能保证它不会发生 —— Argent 已经发生过。费用：智能钱包的账户创建需要费用，而转账和任何调用任何合约都会比外部地址花费更多费用。这导致智能钱包的用户需要支付更高的事务费用，这影响了他们的使用体验
2. 以资产为中心 —— 无气通证
无气通证也存在其问题。从目前的使用情况来看，极少有人使用这种特性(需要数据支持)。在「智能钱包，不止元交易」一文中，我分析了可能的原因，其中之一在于没有办法建立有效的计费系统。
以资产为中心的方案提高了资产的可用性。不同于智能钱包需要创建智能合约账户，无气通证可以支持外部账户在不使用以太的情况下进行转账，反而是智能合约账户需要兼容更多规范（例如 EIP-2126，让合约可以识别不同类型的签名格式），否则无法让无气通证的合约验证所有权
以资产为中心的方案的目标是创建允许由第三方支付费用的资产，实现 “无需 gas 的通证”。例如，DAI、USDC 都可以允许任意外部地址使用元交易的方式发送资产。这些通证协议都使用 EIP-712 协议验证拥有者的合法性。
账户抽象的发展史
根据 Matt Garnett 整理的账户抽象发展历史 [2]，从以太坊 2015 年上线起，账户抽象的讨论没有停止。本文将按照时间顺序，对账户抽象相关的EIP进行简要介绍。需要说明的是，该历史漏掉了 EIP-208，我做了相应补充。
EIP-101：货币与密码学抽象
[[November 15th, 2015]]
在这个 EIP [3] 中，Vitalik 讨论了对 Serenity 中的账户体系的设计。这个方案的主要思想是，每个账户都拥有自己的 “代码”，也即逻辑部分。由于该方案改动过大，与当前事务的兼容性不好，会造成许多安全隐患，该方案被搁置到分片之后。
EIP-86：事务来源和签名抽象
[[February 10th, 2017]]
经过漫长的讨论，Vitalik 提出了 EIP-86。EIP-86 是为账户抽象做技术准备，它定义了一种新的账户类型，允许用户创建基于智能合约的账户，该账户是一个代理合约（forwarding contract），存储 Ether，在入口点检查事务的签名，并将验证合法的事务转发到指定的地址，并支付相应的费用。这种机制对多签钱包、环签名混币、自定义的密码算法（例如 ed25519）等场景的实现有更多帮助。
对 EIP-86 的讨论展开了很久，值得说明的是，Vitalik 丰富了协议细节，提出了 EIP-208。EIP-86/208 计划于 Metropolis 阶段升级，但在第 19 次核心开发者会议 [4] 上，开发者提出了很多问题，并决定在 Metropolis 中暂缓引入，主要理由如下。
账户抽象带来新类型的事务，与传统事务必须有一个 EOA 作为发送者相比，这些事务没有发送者。这种事务破坏了事务哈希的唯一性，尽管这不会对 EVM 的执行造成影响，但是所有基于 “唯一性” 假设的外部操作都会收到影响。例如，所有通过事务哈希来定位事务的 RPC 接口。此外，账户抽象的 “无气支付” 是一个优化，但是必要性不足。因为其功能可以通过 “代理合约” 实现，唯一的问题是其开销会比原生实现要大一些。矿工的挖矿策略会受到极大影响，在被广泛接纳前，这些新类型的事务可能无法被很快广播。这种新类型的事务仍然保留了 nonce、gasprice、value 字段，且被设为 0。这非常不优雅，希望未来用新的事务类型解决，而不是引入技术债。
EIP-859：主网上的账户抽象
[[January 30th, 2018]]
与前两个 EIP 不同，EIP-859 并没有形成确定性的草案，而是始终在讨论过程中，没有定稿。该提案希望账户合约有一个相对规范的实现，即（1）检查签名（2）支付手续费（3）调用目的账户。
如果 EIP-859 实现，可以抽象（1）签名算法（2）更复杂的逻辑，并且不会破坏 “事务哈希唯一” 的特性，但仍然不能允许使用 ERC-20 支付费用。
这个提案在第 34 次和第 40 次核心开发者会议的笔记中被提及。根据会议笔记，第 33 次核心开发者会议上决定搁置该提案，而是聚焦于 Casper。而 Vitalik 在第 34 次会议 [5] 上承认该提案仍不成熟，但 “不管怎样在分片时会实现”。Hudson 指出，君士坦丁堡升级包含的内容太多了，因此不再考虑该提案。第 40 次核心开发者会议上，大家决定永久搁置该提案，无人反对。
EIP-2938：账户抽象
[[September 4th, 2020]]
时间又过了两年，ETH 2.0 的 Phase 0 已经启动，而账户抽象也被重新提上议程。出乎意料的是，该提案建议在 ETH 1.x 上首先实现。
简单来说，账户抽象的目标是让智能合约成为顶级的账户类型，而非受限制的必须由外部账户调用的账户，这样智能合约账户就可以主动发起事务并支付手续费。这个目标与 EIP-86 已经有了很大区别，当时的提案希望彻底消灭外部账户，或者说将所有的外部账户都变成合约账户，而此提案仍然保留了外部账户的存在。
以太坊当前的事务合法性只通过三个参数判断：ECDSA 签名、自增 nonce 和账户余额，因此节点非常容易判断一笔事务的合法性。然而，这势必造成了很多限制。EIP-2938 实现后，以下场景可以主动实现：
(1) 智能钱包使用 ECDSA 之外的算法验证签名；(2) 智能钱包的其它特性，包括多重签名和社交恢复；(3) 保护隐私的系统，例如 Tornado.cash；(4) 提高 DeFi 协议 gas 效率；(5) 用户使用其它 token，而不是 ETH 支付手续费。
目前，以上用户场景也可以通过间接的方式实现。该提案认为这种方式在技术和经济上都不高效。
EIP-2938 分为单租户和多租户两个阶段，顾名思义，其区别在于账户的拥有者是单个用户还是多个（不特定的）用户。在单租户阶段能满足 (1)、(2) 和 (5) 场景的需求，而只有在多租户阶段 (3) 和 (4) 才能实现。多租户阶段的技术方案仍未成型。有关 EIP-2938 的更多内容，可以参考 Status 发表，以太坊爱好者翻译的文章[6]。
代价是什么？—— 硬币的两面
毫无疑问，假设账户抽象成功部署，可以带来新的功能特性，但也一定有取舍，不可能得到美好的东西，但不付出什么代价。过去五年的讨论给了我们足够的经验，其负面影响甚至由于其复杂性而难以分析。尽管如此，本文将试图系统讨论其潜在收获和代价，以便读者公允地判断。「账户抽象的收获」参考了核心开发者 Peep an EIP 文档[7]。
1. 账户抽象的收获
（1）主动发送事务的智能合约账户。
智能合约账户可以无需 EOA 触发而主动发送事务，减少了对运营商的依赖，且 gas 消耗更少。
（2）提高混币器的隐私性。
现阶段，用户从类似 Tornado.cash 的混币器中提款仍需要依赖一个 EOA 账户发送事务，这个 EOA 账户是暴露隐私的脆弱环节。实现多租户的账户抽象后，任何人提取代币时，均无需额外支付费用，而直接从提款金额中扣除。
（3）使用其它代币支付手续费。
现阶段，用户必须使用 ETH 支付网络的手续费，在账户抽象实现之后，用户可以使用其它 token 支付手续费。但这不意味着在协议层矿工会接受非 ETH 作为手续费，而是通过和 DEX 交互换取 ETH 支付手续费。
（4）减少链上无效套利交易，提高可扩展性。
现阶段，在链上发现套利机会时，可能存在多个套利者同时发起套利交易，而首笔成功的套利事务会让其余事务的套利行为失效，但这些事务仍然会被打包在以太坊中（如果 gasprice 足够，且没有使用相同 nonce 替换该事务），这导致以太坊上存在大量的 “垃圾” 事务。而实现账户抽象之后，由于可以在账户权限验证阶段进行价格判断，那么套利者无需为失败的套利行为付费，链上也不会包含失败的套利事务，可以有效提高链的可扩展性。
2. 账户抽象的代价
（1）加大内存池验证事务有效性的开销
在现阶段，节点收到一笔事务时，很容易判断其有效性，并将其载入内存池。节点只需要判断三件事：签名的有效性、nonce 的合理性（账户当前 nonce 加 1 或合理的数值）、账户的余额，如果其中任意一条不满足，节点可以选择丢弃该事务。非法事务并不会支付手续费，节点是免费 “验证”，由于验证 ECDSA 的签名非常简单，开销极低，目前网络的安全性不会受到挑战。当引入账户抽象后，判断一笔事务的有效性的难度大了很多，节点需要为无效事务的验证花费更多计算资源，而不能从中收取任何费用。有关 DOS 攻击，参见[8]
（2）加大内存池确保事务有效性的开销
现阶段，一旦节点验证某笔事务的有效性，除非该账户使用相同 nonce 发送新的事务并被打包，否则这笔载入内存池的事务将永远有效，直到被打包进某个区块（也可能因为 gasprice 太低而一直没有打包）。而账户抽象之后，判断事务的有效性的难度提高了，内存池中的多笔事务在被打包前可以同时有效，但由于其有效性可能依赖全局状态，存在其中某一笔事务执行后剩余事务全部失效的可能性。因此，需要建立新的内存池规则，以避免这种情况的出现。
（3）引入新的事务类型、计费方式、挖矿和广播策略
首先，引入了新的事务类型。在 EIP-86/208 的讨论过程中，一度有一种倾向是 “消灭” EOA 账户，或者说把 EOA 账户包裹在一个智能合约账户内，这样链上的基本账户类型和事务类型都只有一种。而在本提案中，EOA 账户得以保留，即存在两种类型的账户——EOA 和 AA，也有两种事务类型。同时，AA 事务调用其它合约时必须加上前缀，以防止 EOA 账户发起对 AA 账户状态的修改，影响事务有效性的判断，这可能会带来兼容性的问题。其次，计费方式发生了变化。现阶段，矿工无需关心事务的内容，只需要确认事务的发起方的ETH余额大于 gaslimit*gasprice，就可以保证收到手续费。而在账户抽象之后，如何保证矿工可以收到手续费呢？本提案将一笔事务分拆成两个部分——验证阶段和执行阶段，用一个新的操作符 PAYGAS 间隔。在验证阶段，完成对账户权限的验证，在此阶段不允许调用外部数据或操作账户余额。与现阶段的方法一致，验证通过则支付手续费并开始执行事务，即使事务在执行阶段回滚，也仍然会被包含在区块中且支付费用，但验证不通过则丢弃该非法事务。再者，挖矿和广播策略变得更加复杂。为了保护内存池和矿工的安全，推荐的挖矿策略更加保守。每个账户的待处理事务只保留一个，不再保留更高 nonce 的事务；对验证阶段设置 gas 的容量上限；在 AA 账户发起的事务被打包进入区块之后，需要丢弃掉内存池所有对此账户进行操作的事务。为了避免前 2 条代价造成的潜在影响，以太坊协议层需要做相应的技术改动。
重新评估「收获」？
要评估账户抽象的必要性，首先不妨来回顾其 “收获”。“收获” 无非分为两种类型——原来不能做的，现在可以做了；比原来做得更好了。
（1）主动发送事务的智能合约账户。
智能钱包可以做到这件事情，此收获属于一种改进。由于事务的有效性依赖于合格的签名（或其它凭证），而非发送事务的 EOA 账户，因此任何 EOA 账户都可以提交事务，不存在信任或可靠性风险。由于无需转发事务，更少的 gas 消耗是一个合理的 “收获”，但能达到整体的最优吗？换句话说，在引入了如此复杂的技术改动之后，针对相同的事务内容，计算机在相同时间内可以处理更多的 AA 事务还是 EOA 事务？
结论：一种需要技术验证的改进。
（2）提高混币器的隐私性。
目前 Tornado.cash 使用运营商的模式，替代用户提交取款的收据。与智能钱包的运营商不同，隐私运营商可能不够稳定和 ，任何人可以替代提交事务，但隐私场景下的运营商可靠性会低于通用场景，可能造成服务不可用。不过，这需要在多租户阶段才能实现，而目前多租户模式的方案的可行性、安全性仍然需要验证。
结论：一种提高服务可用性的改进。但不知道能否上线，何时可以上线。
（3）使用其它代币支付手续费。
现在智能钱包在做类似的事情，例如 Argent、MYKEY 都允许用户使用 DAI 支付手续费，但这一操作并非原子的。使用稳定币等资产通过 DEX 兑换 ETH 支付手续费，乍看解决了原来不能解决的问题，但我想表达的是，真实需求并非是技术完备性，而是使用稳定的货币来对抗不稳定的手续费（ETH 价格波动、gasprice 价格波动、gas 消耗不确定）。使用链上事务直接置换手续费，有一种每次使用手机联网前，先买充值卡充话费的感觉，似乎回到了投币电话的时代。何况这笔事务还有巨大的失败风险，因为链上状态的改变可能影响价格。当然，这并不是说投币电话没有用处。
结论：一种可以实现原子化使用非 ETH 资产支付手续费的改进。但不解决价格波动问题，真实需求存疑，且计费方式效率低下。
（4）减少链上无效套利交易，提高可扩展性。
在研究过程中，关于 “减少链上无效事务可以提高链扩展性”的论述甚至让我怀疑整个账户抽象的动机。在现有的模型下，套利者追求套利机会，但由于策略公开，可能导致不同的套利者竞争，抬高网络费率并引入大量失败的套利事务。然而，套利者更明白这个道理，因此也会评估套利失败的后果，否则就要付出手续费的代价，恰恰是这个成本让系统处在动态博弈中。如果竞争套利的行为不需要付出成本，那么尽管不会出现无效的链上事务，但整个系统却会容纳更多的套利行为，让节点承受更多的无法收费的计算任务，何谈增加系统的可扩展性？
结论：不是改进，更像是为了链上 “干净” 的一种固执。
综上所述，这些声称的改进大多只是对现有实现的 “优化”，且缺少足够的验证，部分 “优化” 甚至经不起推敲。
总结
本文总结了以太坊 “账户抽象” 的背景，“账户抽象” 主要为了解决两个问题，一是无需 Ether 发送事务，二是实现自定义的验证逻辑和算法。为了解决这些问题，以太坊历史上提出了多个提案，本文分析了这些提案的企图和最终未采纳的原因。本文的重点是针对 EIP-2938 这个最新的关于账户抽象的分析，讨论了其 “收获” 和 “代价”。“账户抽象” 可以将一些现阶段需要引入“信任” 才能实现的功能变得更加可靠，例如为混币器提供更好的隐私，或是使用例如稳定币在内的资产支付手续费，但也不可避免地带来技术架构的大改动，其安全性也需要更完备的验证。引用阿剑的一段话“而如果某些技术，既没有增加人们可选的东西，又牺牲了人们实际上选择了的东西，那就没有理由对这些技术怀有信心。”
参考文章
[1] https://etherscan.io/tx/0x4f719da4e138bd8ab929f4110e84d773b57376b37d1c635d26cd263d65da99cb
[2] https://hackmd.io/@matt/r1neQ_B38
[3] https://github.com/ethereum/EIPs/issues/28
[4] https://github.com/ethereum/EIPs/pull/208#issuecomment-313872489
[5] https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2034.md
[6] https://ethfans.org/posts/account-abstraction-eip-2938-why-and-what
[7] https://tinyurl.com/peep-an-eip-2938
[8] https://ethresear.ch/t/dos-vectors-in-account-abstraction-aa-or-validation-generalization-a-case-study-in-geth/7937
APP 
