一、定义

以太坊的基础建立在两种账户类型上，一种承载用户的钱包，另一种承载智能合约的逻辑。他们的功能大多不兼容：用户的钱包无法进行逻辑判断，而承载智能合约的账户无法做任何逻辑之外的事情。账户抽象的目标就是消除这种不兼容，提供一致性体验：去掉特殊性，寻找共性。

账户

以太坊有两种基本的账户类型：外部账户（Externally Owned Accounts - EOA）以及合约账户（Contract Account – CA）。EOA 即普通用户最经常接触的一类账户，如 MetaMask 钱包中的地址，它由用户通过私钥控制；而 CA 则是被部署在以太坊网络中的智能合约，由其代码进行控制，没有私钥。两类账户的异同之处如下所示：

抽象

抽象指从具体问题中，提取出具有共性的模式，再使用通用的解决方法加以处理。换言之，抽象是一个「一般化」的过程，需要去掉特殊性，寻找共性。
在区块链的发展中，从比特币到以太坊实际上也是抽象化的过程。比特币网络最初的目的是想实现点对点的支付系统，带有特殊的明确目的；而以太坊把区块链变成了更加一般化的系统，去掉了专为点对点支付的特殊性，提取了区块链技术的共性搭建出了新的网络，有了以太坊虚拟机，使区块链上可以自由地构造各种不同的协议与应用，拓展了区块链生态。

账户抽象

账户抽象则是指要将以太坊的账户进行一般化，去除特殊性。以太坊拥有两种账户类型，EOA 和 CA 各有自身的特性，其中 EOA 是更「顶层」的账户，任何交易都只能依赖 EOA 发起并支付 ETH 作为 gas，且 EOA 仅能使用 ECDSA 签名方案，由特定的 Secp256k1 椭圆加密算法实现。但 EOA 不直接支持代码逻辑。支持代码逻辑的 CA 需要由 EOA 进行部署和发起交易。

这一切都是以太坊底层的特殊的强制设计。而账户抽象的目的就是希望使以太坊的账户一般化，使其拥有更高的自由度，拓展账户的可能性。针对账户的特殊性进行一般化就可以提取出以下几个账户抽象的关键：

1. 密码学抽象：即账户的签名验证不再仅限于特定的加密算法，用户可以自定义选择不同的加密算法作为安全机制
2. 账户功能抽象：支持代码逻辑，实现自定义功能
3. 交易抽象：账户都可以发起交易；gas 支付自定义

总而言之，对开发者来说，账户抽象意味着更高的自由度和更多的可能性；对用户来说，账户抽象则能从多个维度带来更好的使用体验，比如安全性、易用性、功能性。

二、现状

以太坊的标准交易是没有发送方字段的，如果做了一次资金转账，那么具体消费的是什么地址上的资金？实际是通过其 VRS 参数（即用户签名）反解析出发送方地址的。这样的外部账户（EOA）设计会衍伸出更多的问题：

1. 私钥难保护：用户失去私钥（遗失、黑客攻击、密码学上的被破解）意味着地失去所有资产。
2. 签名算法少：原生协议在验证交易上只能使用 ECDSA 签名和验签算法。
3. 签名权限高：无原生多签（多签只能通过智能合约实现协作），单签即可执行任意操作。
4. 交易手续费只能通过 ETH 支付，并不支持批量交易。
5. 交易隐私泄露：一对一交易容易分析账户持有者的隐私信息。

实现账户抽象，将所有权（Owner）和签名权（Signer）分离，从而才能逐个解决上述问题。其实历史的方案有很多，最终都会汇聚到两种路线。

第一种路线是让 EOA 地址变为 CA 地址

EIP-101
早在 2015 年 11 月 15 日，Vitalik 就提出以合约作为账户的新结构。将账户从 4 个字段简化为仅 code 和 storage 两个字段，改变手续费支持由 ERC20 支付，通过预编译合约将原生代币改为类 ERC20 来存余额（可具备代扣授权等功能），将交易字段精简到只有 to、startgas、data 和 code。
现在看来，简直是大跃进式变革，会大幅改动底层设计，让每个账户地址都拥有自己的“代码”逻辑，还能衍生出其他的功能，比如
让交易使用更多加密算法，可以由各地址内部 Code 来指定验签鉴权方法，具备抗量子攻击特性，因为代码具备升级特性。让以太币具备与 ERC20 合约一致的功能特性，核心效果有了代扣授权，从而无需原生币的损耗，提升账户的自定义空间，兼容社交恢复、sbt 支持、密钥找回等

EIP-859
试图解决 Code 的部署问题，核心作用是，如果出现了若交易方合约未部署，则使用交易附带 code 参数执行合约钱包部署，其次还提出新的 PAYGAS 操作码，除了支付 gas 外，也成为一笔交易的参数中验证部分与执行部分的分隔符。

第二种路线是让 EOA 地址驱动 CA 地址

EIP-3074
在 EVM 中加入两个新的字节码 AUTH 和 AUTHCALL，让 EOA 能透过这两个字节码授权合约代替 EOA 的身份去呼叫其他合约。概括来说一个 EOA 能将一则已签的消息（交易）送至自己信任的合约（称作 Invoker）上，此 Invoker 合约可以利用 AUTH 和 AUTHCALL 操作码来代替这个 EOA 送出这笔交易。

EIP-4337
用交易内存池实现账户抽象，总之，受到 MEV 的启发进行设计，其核心价值是可以完全避免共识层协议更改。提出新的事务对象 UserOperation，用户将此对象发送到内存池中，由 bundlers 从矿工维度批量打包交付合约执行交易事务，本质上是把底层的交易与帐户运作拉到合约层面执行。

EIP-5189
通过背书人来操作抽象账户，这算是优化了 EIP4337 的逻辑，是面对恶意的 Bundler 通过建立资金罚款背书 endorser 的机制来防止 Dos 阻塞攻击。该提案引入了一个 endorser 的角色，合约钱包的开发者定义 endorser 合约，从而帮助确认提交的元交易的质量，帮助 bundler 确定该交易是否该留在 mempool 中。该提案将账户抽象为 bundler 带来的风险转移至钱包开发者，希望开发者负责编码、部署 endorser 合约。

三、EIP-7702 改进协议

它通过新的交易类型来区分，可以允许 EOA 在单笔交易中临时具备智能合约的功能，进而支持业务上进行批量交易、无 Gas 交易和自定义权限管理等，且无需引入新的 EVM opCode（影响往前兼容性）。
他可以让用户在不部署智能合约的情况下，就可以获得大部分 AA 的能力，甚至可以提供第三方代用户发起交易的能力，且不需要用户提供私钥，只需签名授权的信息。

数据结构

定义了新的交易类型 0x04，该交易类型的 TransactionPayload 是下列内容的 RLP 编码序列化结果
重要的是其中新增了 authorization_list 对象，存储签名者希望在其 EOA 中执行的代码，用户签署交易的同时也签署要执行的合约代码，他作为二维列表存在，说明可以批量存放多个操作信息，执行批量操作。

交易生命周期

验证阶段
在执行交易的开始阶段，对于每个 authorization_list 的 [chain_id, address, nonce, y_parity, r, s] 元组：
从签名 r、s 中采用 ecrecover 恢复出签名者地址（注意这是以太坊本身的机制，所以该 EIP 没有改变签名算法）。authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]（与之前解签名得出 from 地址类似，这里得出的是针对这个 list 的局部签名地址）
验证 authority 签名者的代码是否为空或已经委托（验证交易是否属于有效 7702 交易，后续会通过 delegation 机制去代理执行交易）。
验证 authority 签名者的 nonce（防 authority 的签名重放）。
设置 authority 签名者的代码为 0xef0100 || address（用于绕过 EIP3607 防碰撞策略的）
增加 authority 签名者的 nonce（防局部签名重放）。
将 authority 签名者账户添加到已访问地址列表中（转热地址，降低查询存储的 gas 费）

执行阶段
要执行的合约代码以及操作指令在哪里？“新”版本仅更改了代码部署方面的行为。不再将帐户代码设置为 contract_code，而是从 authorization_list 中检索代码 address 并将该代码设置为帐户代码。所以，当需要执行授权代码时，从 authorization_list 的 address 字段指定的地址加载代码，并在签名者账户的上下文中执行。这意味着用户的合约代码实际上是存储在链上的某个特定地址，而不是直接包含在交易中。而操作指令和相关参数则存储在交易负载的 data 字段中。

影响

1. 打破了账户余额只能因源自该账户的交易而减少的不变量。
2. 打破了交易执行开始后 EOA nonce 增加 1 的不变量（可能同时增加多个）。
3. 打破了 tx.origin 和 msg.sender 两个比对的防护逻辑，很多过往的合约有风险了。
4. 打破了 EOA 本身无法发出事件的现状，对部分链上事件识别监听可能需要注意。
5. 打破了 EOA 地址接受 ERC20、721、1155 等资产必然成功的现状（因为回调机制，可能失败）

四、愿景

账户抽象普及并达成共识后，合约账户的兼容性、经济性都将得到提升。它的终态，可能会包括以下功能和应用场景：

1. 无私钥：用户无需再保管助记词或私钥；可以通过生物验证、设备验证等多种验证方式
2. 账户恢复：可以通过生物识别、社交验证等方式进行账户恢复
3. 无 gas 交互：用户可以使用交易中涉及的 ERC-20 代币进行 gas 支付，或直接指定固定的账户进行支付，而无需提前准备 ETH 作为 gas；或在交易失败时无需支付 gas 费用
4. 自定义安全机制：可以随着密码学的发展，选择更优的安全机制
5. 隐私性：基于环签名等方式实现的更有效的链上隐私性
6. 账户临时托管：用户可以设置管理方、时常、交互等要求，将账户托管给他人进行管理，达到时间或要求后自动收回。
7. 账户抵押 / 交易：账户内包含资产及积累的链上信用历史，账户本身可以在链上市场进行直接的抵押、交易
8. 账户权限限制和分割：可以许可给他人部分账户权限，比如仅能使用账户内的 NFT 而不能使用代币
9. 自定义工作流：设置自动的触发点和流程。比如 A 账户余额每比 1Eth 多出 0.5ETH 时，就自动将多余的 0.5ETH 转入 B 账户，B 账户在某个 token 达到一定价格时，就自动将 ETH swap 成某 token……
10. 交易限制：可以设置交易时间、额度，超过时间或超出额度的交易则不能成功
11. 白名单 / 黑名单：限制与黑名单的地址进行交互，比如黑名单地址发送的资产会被自动退回，以规避之前 tornado cash 被制裁后，向其他地址「投毒」，导致地址被其他协议前端错误封禁的情况。
12. 账户分类管理系统：用户在不同场景下使用专用的账户，拥有一个更合理的账户管理体系。比如某个账户作为 gas 账户仅存放 ETH，其他所有账户的交互都由 gas 账户进行支付；某个账户仅存放蓝筹 NFT，不会被轻易动用；某个账户作为游戏专用账户
13. 模块化代码功能：为用户提供不同的功能模块，用户无需懂代码，只需按照自己的需求，组合功能模块，即可自定义符合自己习惯和需求的账户。

参考链接：
EIP-7702 协议
账户抽象：7 年路线演化