EIP-7702

让 EOA 在一笔交易中临时拥有智能合约能力

整理自官方规范 · Pectra 升级 · 更新于 2025 · 原始 EIP ↗ · GitHub ↗

EOA 通过 Type 4 交易写入授权，临时获得委托合约的全部能力

HTTP 最初是无状态的。Cookie 没有重写 HTTP——它在现有协议上叠加了一层状态。你的浏览器地址没有变，服务器开始认识你了。

Git 最初没有大文件支持。Git LFS 没有重写 Git——它通过指针文件给 Git 加了一个能力层。你的仓库地址没有变，但现在能存 GB 级文件了。

EOA 和智能合约的二分法，是以太坊最古老的设计约束，也是最大的 UX 税。 EIP-7702 用同一个思路打破它：不是创建新账户，而是给旧账户借用能力。 你的地址没有变，私钥没有变，历史没有变。它只是在需要时穿上合约的外衣。

核心洞察

账户抽象的终点不是新建一个更好的账户，而是让旧账户学会新技能。EIP-7702 是这个方向在协议层的第一次落地。

动机：一个存在了六年的裂缝

↑ top

以太坊从第一天起就有一道裂缝：真正持有资产的是 EOA，强大的可编程性只存在于合约。这不是 bug，是设计选择——但这个选择的代价，随着时间推移变得越来越高。

很多人以为这个问题已经被 ERC-4337 解决了。没有。ERC-4337 造了一座更好的新桥，但要走上去，你得先把资产从旧桥搬过来。大多数用户不愿意搬。于是那道裂缝继续存在。

旧账户不能做什么

场景	EOA 的困境	合约账户的做法
批量操作	需要发送多笔独立交易，每笔付 Gas，且无法原子性	单次调用，内部循环，原子成功或回滚
Gas 代付	必须自持 ETH，无法由第三方代缴 Gas	Paymaster 可接管 Gas，用户无需持有 ETH
权限委托	私钥一旦共享即全权委托，无法限制操作范围	Session Key / 白名单合约精确限权
签名验证	只支持 ECDSA secp256k1，无法换算法	任意签名方案（WebAuthn、Passkey、BLS…）

ERC-4337 通过引入 UserOperation 和 Bundler 解决了上述问题，但代价是：现有 EOA 必须将资产迁移到新部署的 Smart Account 合约中。对于已积累大量历史的 EOA（NFT、DeFi 持仓、ENS 绑定等），迁移成本极高。

DESIGN GOAL

EIP-7702 的目标是：让现有 EOA 原地升级，无需迁移资产，即可获得智能合约的全部能力。

新交易类型：Type 4

↑ top

以太坊的交易格式不是一成不变的。每当有新的核心需求出现，就会通过 EIP 定义一种新的交易类型，向后兼容旧格式。Type 4 是目前最新的，专门为 EIP-7702 的委托授权机制设计。

交易类型演进

类型	前缀	引入提案	核心新增	解决的问题
Legacy (Type 0)	无前缀	创世	`gasPrice`	以太坊最原始的交易格式，所有字段一次性定价
Type 1	`0x01`	EIP-2930	`access_list`	预声明会访问的存储槽，降低跨合约调用的 Gas 不确定性
Type 2	`0x02`	EIP-1559	`max_fee` + `max_priority_fee`	Gas 定价分为基础费（烧掉）+ 小费，费用更可预测
Type 3	`0x03`	EIP-4844	`blob_versioned_hashes`	Blob 数据携带（Proto-Danksharding），为 L2 提供临时数据层
Type 4	`0x04`	EIP-7702	`authorization_list`	EOA 可携带签名授权列表，将自身代码设为委托指示符，原地获得智能合约能力

以太坊交易类型演进 — 每种类型向后兼容，现有节点同时支持所有类型

Type 4 字段详解

Type 4 在 Type 2 的所有字段基础上，新增了 authorization_list：

字段	类型	Type 2 有？	说明
chain_id	uint256	✓	目标链 ID，防止跨链重放
nonce	uint64	✓	发送者账户 nonce，防重放
max_priority_fee_per_gas	uint256	✓	给矿工/验证者的小费上限
max_fee_per_gas	uint256	✓	每单位 Gas 愿意支付的最高价（含基础费）
gas_limit	uint64	✓	Gas 上限
destination	address	✓	to 地址。可以是授权后的 EOA 自身，实现"升级 + 调用"同笔完成
value	uint256	✓	随交易转移的 ETH（wei）
data	bytes	✓	calldata，调用合约时的函数选择器 + 参数
access_list	list	✓	EIP-2930 预热存储槽，降低 Gas
authorization_list	list of tuples	✦ 新增	核心新字段。每个元组携带一个 EOA 的授权签名，允许该 EOA 将自身代码设为委托指示符。一笔交易可同时授权多个 EOA。
signature_y_parity / r / s	bytes	✓	交易发送者（sponsor）的签名，用于支付 Gas。与 authorization_list 内每个元组的签名是两套独立签名。

KEY INSIGHT

交易发送者（sponsor）与授权的 authority 可以是不同地址。Alice 签署授权元组，Bob 打包交易并支付 Gas——这是 Gas 代付的基础机制。

RLP 编码结构

完整的 Type 4 交易以 0x04 前缀开头，后跟 RLP 编码体：

// Type 4 Transaction = 0x04 || rlp([...])
rlp([
  chain_id,                  // uint256，目标链 ID
  nonce,                     // uint64，发送者 nonce
  max_priority_fee_per_gas,  // uint256
  max_fee_per_gas,           // uint256
  gas_limit,                 // uint64
  destination,               // address，to 地址
  value,                     // uint256，ETH（wei）
  data,                      // bytes，calldata
  access_list,               // list，EIP-2930
  authorization_list,       // ← Type 4 新增，授权元组列表
  signature_y_parity,        // uint8，发送者签名
  signature_r,               // bytes32
  signature_s                // bytes32
])

交互演示：构建一笔 Type 4 交易

填入参数，实时查看 Type 4 交易结构与普通 Type 2 的差异：

🔧 Type 4 Transaction Builder 调整参数，观察 authorization_list 如何嵌入交易

EOA 地址（authority）

委托目标合约（delegate）

Chain ID

Gas 代付方（sponsor，可与 EOA 不同）

Authorization Tuple

↑ top

authorization_list 中的每个元素是一个授权元组（authorization tuple），它由 authority（被授权的 EOA）使用私钥签名，声明"我同意将我的账户代码委托给 address"。

// 单个授权元组结构
[
  chain_id,   // uint256，目标链；0 = 任意链均有效
  address,    // address，委托目标合约
  nonce,      // uint64，authority 当前的 nonce（防重放）
  y_parity,   // uint8，ECDSA 签名恢复参数
  r,          // bytes32
  s           // bytes32
]

签名覆盖的内容（magic 前缀 + keccak256）：

keccak256(0x05 || rlp([chain_id, address, nonce]))

字段含义

字段	类型	必须	说明
chain_id	uint256	是	指定此授权在哪条链上有效。 chain_id = 0 表示该授权在所有 EVM 兼容链上均有效（跨链授权），需谨慎使用；非零值则仅在指定链上生效，防止跨链重放。
address	address (20B)	是	委托目标合约地址，即 authority 的账户代码将被设置为指向该地址的委托指示符。设为 `0x0000...0000`（零地址）时，清除当前委托，恢复为空代码 EOA。
nonce	uint64	是	必须等于 authority 账户的当前 nonce。执行授权后，authority 的 nonce 自增 1。这防止了旧授权签名的重放攻击。
y_parity, r, s	ECDSA sig	是	authority 对上述内容的签名。通过 `ecrecover` 还原出 authority 地址，确认是该 EOA 本人授权的委托行为。

CAUTION

chain_id = 0 的风险：使用跨链授权签名意味着该授权在 Ethereum 主网、Polygon、X Layer 等任何 EVM 链上都有效。如果委托合约在某条链上存在恶意版本，攻击者可以在该链上重放该授权。除非有明确需求，建议始终指定具体的 chain_id。

Delegation Code（0xef0100）

↑ top

当一个 authorization tuple 被成功验证并执行后，EVM 将 authority 的账户代码（account.code）设置为一段特殊的 23 字节"委托指示符"（delegation designator）：

delegation_designator = 0xef0100 || address (20 bytes)
                         // 总计 23 bytes

格式解析与执行语义

字节段	内容	含义
0xef	1 byte	由 EIP-3541 保留的无效操作码前缀，确保该代码永远不会被当作普通 EVM 字节码执行，EVM 能够识别这是一个特殊标记。
0x0100	2 bytes	版本标识，当前为 v1（`0x01`），保留扩展空间。第二字节 `0x00` 为填充。
address	20 bytes	委托目标合约的地址。EVM 在执行 authority 账户的代码时，将加载此地址的代码，并以 DELEGATECALL 语义运行——`storage`、`msg.sender`、`address` 均属于 authority 自身。

执行语义：DELEGATECALL 等价

当外部合约调用拥有委托指示符的 EOA 时，EVM 的行为等价于：

// 伪代码：调用 authority 账户时的 EVM 行为
if account.code.startsWith(0xef0100):
    delegate_address = account.code[3:23]
    delegate_code    = load_code(delegate_address)
    // 以 DELEGATECALL 语义执行：
    // - storage  → authority 自身
    // - msg.sender → 调用者
    // - address  → authority
    execute(delegate_code, context=authority)

TIP

委托指示符是持久化的：一旦在某笔 Type 4 交易中写入，即使该交易结束，authority 的代码依然保持为委托指示符，直到发送新的 Type 4 交易将其清除或覆盖。

执行规则

↑ top

每个 authorization tuple 按以下流程处理：

Authorization Tuple 处理流程（任一验证失败则 skip 当前 tuple，继续处理下一个）

Authority 验证流程

chain_id 检查：若 chain_id != 0 且 chain_id != current_chain_id，则跳过该 tuple。
签名恢复：使用 ecrecover 从签名中还原出 authority 地址。若失败（无效签名），跳过。
代码检查（可选条件）：若 authority 已有代码，且不是委托指示符格式（0xef0100 前缀），则跳过。这防止意外覆盖真实的智能合约代码。
nonce 检查：若 tuple 中的 nonce 不等于 authority 的当前账户 nonce，则跳过。
写入代码：将 authority 的 account.code 设置为 0xef0100 || address。
nonce 自增：authority 的 nonce 加 1。

状态变更

变更项	值
authority.code	`0xef0100 \|\| address`（23 bytes）
authority.nonce	+1（每个有效授权执行一次自增）
authority.storage	不变（委托合约共享 authority 的存储空间）
authority.balance	不变（除非委托合约逻辑修改了余额）

清除委托

将授权元组中的 address 设为零地址 0x0000000000000000000000000000000000000000，可清除当前委托，authority 的账户代码恢复为空（即变回普通 EOA）：

// 清除委托的授权元组
[
  chain_id,
  0x0000000000000000000000000000000000000000,  // 零地址
  nonce,
  y_parity, r, s
]

TIP

清除委托是可撤销设计的关键。与不可逆的账户迁移不同，EIP-7702 允许用户随时取消委托，完全恢复为普通 EOA，无任何残留。

典型应用场景

↑ top

批量交易（Batch Transactions）

EOA 获得委托代码后，可以在一笔交易中原子性地执行多个操作，彻底消除多步骤交互中"前一笔失败、后一笔悬空"的问题。

// 委托合约：BatchExecutor
contract BatchExecutor {
    struct Call {
        address target;
        uint256 value;
        bytes   data;
    }

    function execute(Call[] calldata calls) external payable {
        for (uint i = 0; i < calls.length; i++) {
            (bool ok,) = calls[i].target.call{value: calls[i].value}(
                calls[i].data
            );
            require(ok, "call failed");
        }
    }
}

EOA 委托给 BatchExecutor 后，调用 execute() 即可在单笔交易中完成：Approve USDC → Swap → Add Liquidity，且具备原子性。

Gas 代付（Gas Sponsorship）

EIP-7702 天然支持"由他人替我发交易并付 Gas"的模式。用户（Alice）离线签署授权元组， Gas 提供方（Relayer）将其打包进 Type 4 交易并发送，由 Relayer 支付所有 Gas 费用。

Alice 无需持有 ETH，由 Relayer 支付 Gas 发送 Type 4 交易

Session Keys（会话密钥）

委托合约可以实现时间限制、金额上限、白名单合约等精细权限控制。用户将 EOA 委托给 Session Key 管理合约，DApp 拿到的仅是受限的操作许可：

// 简化示意：Session Key 委托合约
contract SessionKeyWallet {
    struct Session {
        uint256 expiry;       // 过期时间
        uint256 spendLimit;  // 单次花费上限
        address allowedTo;  // 只能调用此合约
    }

    mapping(address => Session) public sessions;

    function grantSession(address key, Session calldata s) external {
        require(msg.sender == address(this), "only self");
        sessions[key] = s;
    }

    function execute(address to, uint256 value, bytes calldata data) external {
        Session memory s = sessions[msg.sender];
        require(block.timestamp < s.expiry,    "expired");
        require(value <= s.spendLimit,         "over limit");
        require(to == s.allowedTo,             "not allowed");
        to.call{value: value}(data);
    }
}

临时权限（Temporary Permissions）

游戏、SocialFi 等场景常需要"这次游戏过程中，DApp 可以替我签署某些操作"。 EIP-7702 允许用户临时委托给游戏合约，游戏结束后发送清除授权的 Type 4 交易，完全恢复为普通 EOA。

与 ERC-4337 对比

↑ top

第一次听到 EIP-7702 的开发者，十个里有九个会说："这不就是 ERC-4337 吗？功能重复了。" 这个判断几乎总是错的。

ERC-4337 让你搬进一套更好的新公寓。EIP-7702 让你在原来的家里装上智能家居。搬家和装修解决的不是同一个问题。

维度	ERC-4337	EIP-7702
账户模型	新部署 Smart Account 合约，资产需迁移	现有 EOA 原地升级，无需迁移
执行路径	UserOperation → Bundler → EntryPoint → Account	Type 4 Tx → EVM → EOA（with delegate code）
协议侵入	无协议变更，纯合约层实现	需要协议层支持（硬分叉），Pectra 升级引入
Gas 代付	Paymaster 合约，功能完整	Relayer 模式，由交易发送者代付
签名验证	任意方案（WebAuthn、BLS、多签…）	取决于委托合约实现，理论上也可任意
可撤销性	资产留在 Smart Account，EOA 已无直接控制	随时清除委托，完全恢复 EOA
适用场景	新用户、需要完整 AA 能力的产品	现有 EOA 用户的渐进式升级

INSIGHT

两者互补而非竞争。ERC-4337 提供完整的 AA 能力，EIP-7702 让现有 EOA 以最小成本享受智能账户的核心功能。在实践中，EIP-7702 委托的目标合约完全可以是一个 ERC-4337 兼容的 Smart Account 合约。

与 EIP-3074 对比

↑ top

EIP-3074 是 EIP-7702 的前身提案，同样旨在扩展 EOA 能力，但两者的设计理念存在根本差异：

维度	EIP-3074	EIP-7702
机制	引入 `AUTH` 和 `AUTHCALL` 两个新 EVM 操作码	引入新交易类型 + 账户代码写入
信任模型	EOA 授权给 Invoker 合约，Invoker 可以代表 EOA 调用任何合约	EOA 将代码设为委托指示符，调用方通过 EOA 本身执行
风险	Invoker 合约若有漏洞，可能被滥用代表 EOA 执行恶意操作	委托合约直接暴露给 EOA 的存储，须信任委托目标
可撤销	签名在 commit 内单次有效，无需撤销	委托持久化，需主动发送清除交易才能撤销
最终结果	Pectra 升级中被 EIP-7702 取代，未被采纳	已纳入 Pectra 升级，2025 年主网激活

安全考量

↑ top

重入风险

EOA 拥有代码后，与其他合约交互时存在重入攻击面。委托合约应当实现标准的重入保护（ReentrancyGuard）。尤其需要注意：在委托代码执行过程中，外部合约可以回调 EOA（此时 EOA 有代码），需要显式保护关键状态变更。

跨链重放（chain_id = 0）

使用 chain_id = 0 签署的授权对所有 EVM 链有效。若目标委托合约在另一条链上存在地址碰撞或恶意版本，该授权可被重放。强烈建议始终指定具体的 chain_id，除非你明确需要跨链授权。

Nonce 管理

每笔 Type 4 交易可携带多个授权元组，每个有效元组执行后会使 authority 的 nonce 自增。若并行创建了多个依赖同一 nonce 的授权签名，只有第一个会成功执行，后续将因 nonce 不匹配而被跳过。

存储隔离缺失

委托合约以 DELEGATECALL 语义运行，直接读写 authority（EOA）的存储槽。若委托合约与其他合约共享存储布局，可能产生存储冲突。委托合约的存储变量布局应当经过审慎设计，避免槽位重叠。

CAUTION

委托合约拥有与合约本身相同级别的账户访问权，包括 ETH 转移、任意存储读写。委托给未经审计的合约等同于将私钥托管给它——请务必只委托给经过严格审计的合约。

最佳实践

指定 chain_id：除非明确需要，不使用 chain_id = 0
委托合约审计：只委托给经过安全审计的合约
最小权限：委托合约应实现细粒度权限控制，不授予超出需要的操作权
设置有效期：Session Key 类委托应加入时间限制
监控清除：重要 EOA 应监控 authorization_list，及时发现未预期的委托
测试撤销路径：上线前务必验证清除委托（零地址授权）的流程可正常工作

Quick Reference

↑ top

概念	值 / 说明
交易类型	`0x04`（Type 4），Pectra 升级引入
委托指示符	`0xef0100 \|\| address`，23 bytes，写入 authority.code
签名内容	`keccak256(0x05 \|\| rlp([chain_id, address, nonce]))`
授权元组	`[chain_id, address, nonce, y_parity, r, s]`
清除委托	将 address 设为 `0x0000...0000`，code 变回空
跨链授权	`chain_id = 0`，任意链均生效，谨慎使用
执行语义	DELEGATECALL 等价：存储、msg.sender、address 属于 authority
EIP 状态	Final，已纳入 Ethereum Pectra 升级（2025 主网激活）
作者	Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, Matt Garnett

理解测验

↑ top

Q1. EIP-7702 授权元组中 chain_id = 0 意味着什么？

Q2. 委托指示符（delegation designator）的正确格式是？

Q3. 以下哪项正确描述了 EIP-7702 委托合约的执行语义？

Q4. 如何清除一个 EOA 上的委托，让它恢复为普通 EOA？

Q5. EIP-7702 与 ERC-4337 最核心的区别是？

0/5

Summary

↑ top

项目	核心内容
本质	让 EOA 临时或持久拥有智能合约代码，无需迁移资产
新机制	Transaction Type 4 + authorization_list + 委托指示符（0xef0100）
授权元组	[chain_id, address, nonce, y_parity, r, s]，authority 签名
执行语义	DELEGATECALL 等价，委托代码在 authority 的存储和上下文中运行
可撤销	发送 address=0 的授权元组即可清除，完全恢复为普通 EOA
典型用途	批量交易 · Gas 代付 · Session Keys · 临时权限委托
与 ERC-4337	互补：7702 服务于现有 EOA 渐进升级，4337 提供完整 AA 能力
主要风险	委托合约安全性 · chain_id=0 跨链重放 · 存储槽冲突 · 重入
状态	Final，已随 Pectra 升级激活于以太坊主网（2025）

最后

你那个已经积累了多年历史的 EOA——它的 NFT、它的 DeFi 持仓、它绑定的 ENS 域名——都不需要动。以太坊在 Pectra 升级中做了一个选择：尊重历史，而不是要求迁移。

EOA 不会消失，也不需要搬家。它正在原地变强。