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

cpbox
发布于 13小时前
阅读 73

以太坊账户抽象（AA）演进一、背景（简要）以太坊原生有两类账户：EOA（ExternallyOwnedAccount）：私钥控制，传统钱包。ContractAccount（合约账户）：由合约代码控制（如Safe）。问题：EOA无法自定义签名/验证逻辑、无法原生支持代付gas

# 以太坊账户抽象（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 讨论**

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

一、背景（简要）

以太坊原生有两类账户：

EOA（Externally Owned Account）：私钥控制，传统钱包。
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 交易"？

换句话说：

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 上要明确提示用户：
- 这是一次性操作还是会持续生效？
- 谁能代表你的账户执行？
- 如何撤销？
许多安全事件都来自用户误以为授权是一次性的但实际是持久化的。

总结