以太坊账户抽象（AA）演进

一、背景（简要）

以太坊原生有两类账户：

1. EOA（Externally Owned Account）：私钥控制，传统钱包。
2. Contract Account（合约账户）：由合约代码控制（如 Safe）。

问题：EOA 无法自定义签名/验证逻辑、无法原生支持代付 gas、多签、恢复等功能 → 因而出现"账户抽象（AA）"一系列提案

二、关键提案概览（时间顺序）

• EIP-86 (2017)：最早的 AA 思路（未采纳）。
• EIP-2938 (2021)：协议层交易类型尝试（未采纳）。
• EIP-3074 (2021)：AUTH / AUTHCALL — EOA 授权 invoker 执行（实验式）。
• EIP-5003 (2022)：AUTHKEY / AUTHUSURP — 将 3074 思路做成持久化授权 / 迁移（中间形态）。
• ERC-4337 (2022/2023 生态化)：链外 bundler + EntryPoint 合约实现 AA（无需硬分叉，生态层落地）。
• EIP-7702 (2024 → 2025 部署)：Type-4 临时代码执行，兼顾安全与兼容性（随 Pectra 上线主网，2025 已生效）。

注意：这里临时执行代码其实也可以是永久执行，后续会讲到

三、各提案核心机制（要点）

1. EIP-3074 — AUTH / AUTHCALL

思路：在 EVM 层加入两个新操作码，允许 EOA 用签名授权某个合约（invoker）代表它发起调用。

优点：

• 实现轻量、直接
• 可实现会话密钥、代付等

问题：

• 授权滥用风险
• 与生态其他方案兼容性差
• 未进入主网

2. EIP-5003 — AUTHKEY / AUTHUSURP（中间形态）

思路：在 3074 基础上引入链上持久授权（或一次性"迁移"），允许将 EOA 的控制权转交或绑定到授权公钥/合约。

优点：

• 解决 3074 的"仅临时"限制
• 支持长期代理/升级

问题：

• 状态变更多、不可逆或复杂
• 与 ERC-4337 兼容性差
• 未被主流采用，成为后续设计参考

3. ERC-4337 — 生态层账户抽象（EntryPoint + UserOperation）

思路：不改共识层，通过 EntryPoint 合约 + UserOperation + bundler/paymaster 实现 AA。用户提交 UserOperation（包含验签、执行逻辑），bundler 打包并上链。

优点：

• 无需硬分叉即可广泛部署
• 支持灵活的验证器（多签、社会恢复、账户代理、代付 gas）
• 已在 L2 / 钱包生态中广泛落地（Safe、ZeroDev 等）

缺点：

• 依赖生态基础设施（bundler、paymaster）
• 相对于协议层方案在某些场景 gas 成本更高
• 与链上低层特性整合有限

4. EIP-7702 — 临时加载合约代码（已上线）

思路：在交易中允许 EOA 临时携带/加载一段验证/执行字节码，该代码在该笔交易内代表账户进行验证与执行，执行结束恢复为普通 EOA（Type-4 交易）。

优点：

• 在协议层实现 AA 能力（兼顾安全与灵活）
• 与 ERC-4337 场景兼容，可相互配合
• 无需永久改变账户状态或迁移资产，降低风险

状态：随 Pectra 升级部署到主网（2025），成为协议层的可用 AA 工具。

四、对比表（快速参考）

提案	实现层次	主要机制	是否需硬分叉	部署状态	核心特点
EIP-3074	协议层	AUTH/AUTHCALL 操作码	是	未采纳	EOA 授权合约代执行
EIP-5003	协议层	持久化授权/迁移	是	未采纳	3074 的持久化版本
ERC-4337	生态层	EntryPoint + UserOp	否	已落地	无需分叉，生态广泛支持
EIP-7702	协议层	临时代码挂载	是	已上线(2025)	协议层 AA，兼容 4337

总结：

• EIP-3074 提供了"EOA 授权合约代执行"的基本思想
• EIP-5003 试图把授权做成持久化/迁移
• ERC-4337 选择在合约层实现 AA（无需协议变更，生态快速落地）
• EIP-7702 则在协议层实现了一种更安全、兼容的临时 AA 机制，并被主网采用

ERC-4337 与 EIP-7702 是并行并互补的两种机制。

五、定义：到底什么是 "7702 交易"？

EIP-7702 交易是一种新的以太坊交易格式，与传统的 Type 0 / Type 2（EIP-1559）不同，它允许交易中包含一个「authorization 列表」和（可选的）「临时代码（ephemeral code）」，从而让 EOA 能像智能合约一样执行复杂逻辑。

换句话说：

Type 4 交易 = 普通交易 + 授权信息 + 临时代码执行上下文

1. 执行逻辑（简化流程）

在执行 Type 4 交易时，EVM 会执行以下逻辑顺序：

a) 解析授权列表

• 如果交易中携带了授权（authorizationList），EVM 会验证其签名是否有效。

b) 临时挂载代码（ephemeral code）

• 如果授权包含代码实现（或直接附带临时代码），节点会在执行该交易时将这段代码暂时挂载到该账户地址上。

c) 执行交易调用

• 这时该地址表现得就像一个智能合约账户：
  • 可以自定义验证逻辑
  • 批量调用
  • 签名检查
  • gas 代付等

d) 执行完成后

• 如果是一次性授权（临时代码）：执行结束即恢复为普通 EOA
• 如果是持久授权：则授权关系留存（地址表现为"长期有 code"）

2. EIP-7702 的两种授权语义（核心点）

a) 一次性/交易内临时代码（ephemeral）

在单笔 Type-4 交易里带上 contract_code，该代码只在该笔交易执行期间被挂载用于验证与执行，交易结束后不再生效。

b) 持久化授权（persistent authorizations）

EIP-7702 也允许通过 authorization 列表为某个 EOA 指定"实现合约（implementation）"，该实现会持续有效，直到被另一次授权替换或显式撤销。

换句话说，EOA 会被视为"有代码"的账户，直至授权变更。

3. 为什么会设计成可"持续生效"？

兼容与便利：

• 允许现有合约钱包实现（或第三方服务）成为 EOA 的长期实现
• 便于把合约钱包能力无缝赋给现有地址（例如 batch、paymaster、社会恢复）

灵活性：

• 既能实现一次性临时代码（低风险场景）
• 也能支持长期委托（更接近 EIP-5003 的迁移/绑定思路，但 7702 用可替换授权避免不可逆迁移）

因此规范允许"授权列表"这样的结构，使得有些授权看起来像"把某实现写到账号上直到下一次改写"。

4. 实际表现：为什么你的地址会"一直被当合约执行"？

如果你或某个服务提交了持久化的 authorization（或反复提交了相同 implementation 的授权），那么节点/客户端在处理后续交易时会把该 EOA 视为"有 code"的账户，按合约逻辑进行验证/调用——因此它看上去就是"永远像合约"。

5. 如何撤销或替换这种"长期"行为

方法一：提交新的 EIP-7702 授权替换旧的实现

用新的 authorization（例如空实现或不同合约地址）覆盖即可；EIP-7702 规定授权可以被替换。

方法二：提交一次性交易而不携带持久授权

对于希望只临时使用合约能力的场景，确保交易只包含一次性 contract_code（不写入持久 authorization 列表）。

方法三：钱包/服务层撤销按钮

主流钱包或 relayer 服务（如 Biconomy、QuickNode 指南）会提供"撤销授权 / 撤销委托"的方法（大多是发起一笔新的 7702 tx 来替换）。

6. 安全与注意事项

️ 重要提示：

• 长期授权等同于把执行控制逻辑交给第三方实现，需要谨慎（类似 EIP-5003 的风险点，但 7702 允许替换，不是不可逆迁移）。

• 在 UX 上要明确提示用户：

  • 这是一次性操作还是会持续生效？
  • 谁能代表你的账户执行？
  • 如何撤销？

• 许多安全事件都来自用户误以为授权是一次性的但实际是持久化的。

---

总结

以太坊账户抽象的演进体现了从协议层到生态层、从实验到落地的完整过程：

1. 早期探索（EIP-86, EIP-2938）为 AA 奠定基础思路
2. EIP-3074/5003 尝试在协议层解决，但因安全和兼容性未被采纳
3. ERC-4337 在生态层成功落地，成为当前主流 AA 方案
4. EIP-7702 在协议层提供了灵活且安全的 AA 能力，与 4337 互补

未来，以太坊可能会进一步统一这些方案，最终实现完全的原生账户抽象。

---

科普先介绍到这里，如果你有什么见解，欢迎来 cpbox 讨论