原文标题：《账户抽象的动机、历史和分析》
撰文：姚翔，MYKEY 研究部门负责人

账户抽象 Account Abstraction 是 以太坊上的一种待实现的技术方案，按现阶段设计，在实现账户抽象之后，一个智能合约账户也可以主动发起交易，而无需依赖「元交易」的机制。

背景

以太坊的账户有两种类型，一种是外部账户，另一种是合约账户。外部地址是由用户的公钥经过哈希运算后取的后 20 个字节，形为 0x76D836358E7A2 BB0F26c32Ce61Dc8DD540b02F7D 。目前的以太坊的事务类型只有一种，必须由外部地址发起，合约地址无法主动发起事务。因此，任何合约自身状态的改变，必须依赖于一个外部地址发起的事务，无论是一个多重签名账户，还是混币器，或是任何智能合约的配置变更，都需要由至少一个外部账户触发。这样的设计让以下两件事情无法完成。

无需以太的主动事务

由于事务必须由外部账户发送并支付费用，而该费用是用以太（ETH）为单位结算的，因此该外部地址必须持有以太。当然，这种说法并不严谨，当 gasprice 为 0 时，事务无需支付手续费。可这种情况非常极端（见 [1]） ，对于普通用户来说，这样的事务可能永远无法入块。

非 secp256k1 的原生验证方式

由于事务必须由外部账户发起，因此每笔事务的合法性检查就是在验证事务是否提供了该账户对应的合法的 secp256k1 签名。而如果要在验证中引入复杂逻辑（例如多重签名或社交恢复）或是采用不同的验证算法（例如 Eddsa、BLS、secp256r1 签名算法，使用这些签名算法是因为它们有特别的特性，或是对零知识证明友好，或是方便签名聚合减少带宽开销，或是与现有的硬件验证器兼容），则必须在智能合约层面实现。这也同时意味着，这种验证仍要由至少一个外部账户发起，并通过以太坊的 secp256k1 签名验证。

上述两条约束让普通用户很难使用以太坊。首先，无论使用以太坊上的什么应用，用户都必须持有以太（并承担以太价格波动的风险）。其次，用户需要处理复杂的费用逻辑，gas price、gas limit、事务阻塞，这些概念对用户来说过于复杂。许多区块链钱包或应用试图通过产品优化提高用户体验，但效果甚微。

如何解决上述两个问题呢？

核心思路在于将「验证所有权」的操作由共识层下放到合约层，即不去检查事务的发送者是否与资产所有人一致，而是检查其是否提供了合法的凭据。具体的做法为：用户对事务内容进行签名，并将签名交由一个第三方操作上链，这个第三方我们在接下来的文章中用「运营商（operator）」来指代。这种事务被称为「元交易」。根据设计理念的不同，元交易方案大致分为两类： (责任编辑：admin)