EIP-7702钱包陷阱：浏览器看着正常，代码却在偷钱

一个地址在区块链浏览器上看起来平平无奇：一个EOA，交易历史很短，没有任何风险标记。你可能会毫不犹豫地给它转一笔小额测试资金。

但这笔测试资金从未真正到达——或者说，它在同一个区块里到达又离开了。转入的资金被自动转发到另一个地址。没有来自钱包所有者的交易，没有可以撤销的授权。这个钱包已经被「委托」了。

EIP-7702 改变了什么

EIP-7702（随 Pectra 升级上线）允许一个 EOA 为自己设置代码。所有者签署一个「授权元组」（authorization tuple），账户的代码就变成了一个委托指示符：0xef0100 || <委托地址>。账户仍然是 EOA——同样的地址、同样的私钥——但此后每次调用都会执行委托地址的代码。

对钱包来说，这功能很强大：批量交易、代付 Gas、社交恢复。但对攻击者来说，这是一份大礼：一次签名授权，账户就变成了一个提线木偶，而在大多数界面上它看起来仍然像普通 EOA。

攻击面在哪里

问题的核心在于信息不对称。区块链浏览器通常展示的是地址的交易历史、余额和代币持有情况，但不会主动高亮「这个地址的代码已经被委托给另一个合约」这一关键信息。用户看到的是一个干净的历史记录，却看不到背后正在运行的转发逻辑。

EOA（外部持有账户） 是以太坊上由私钥直接控制的账户类型，与由代码控制的合约账户相对。在 EIP-7702 之前，EOA 的代码字段始终为空，无法执行自定义逻辑；合约账户可以执行逻辑但没有私钥。EIP-7702 打破了这一二元对立：它通过一种特殊格式的代码前缀 0xef0100 让 EOA「临时」指向一份合约代码。注意这不是把 EOA 变成合约——地址、私钥、nonce 语义全部保留，只是调用时会额外执行被委托的代码。这一设计属于以太坊「账户抽象」大方向的一部分，目标是在不迁移资产、不更换地址的前提下，让 EOA 获得智能账户的能力。

授权元组（authorization tuple） 是 EIP-7702 的核心数据结构，本质上是一段由 EOA 私钥签名、可以被任何人广播上链的声明。它包含六个字段：chain_id（限定生效的链，0 表示任意链）、address（被委托的合约地址）、nonce（防止重放）、y_parity 与 r、s（签名本身）。一旦被打包进交易，该 EOA 的代码字段就被设置为对应委托指示符。关键在于：元组是离线签名的，攻击者只要拿到一次签名就能随时上链「激活」。签名一旦暴露在内存池或历史交易中，就等同于公开，任何人可以用 ecrecover 反推出签名者地址，因此元组本身也可以作为取证依据。

六个签名，一个目标

安全研究者拉取了所有触及该地址的 Authorization 元组。每个元组都是签名数据——包含链 ID、委托地址、nonce，以及 y-parity 和 r/s 签名对。你不需要钱包来读取这些数据，你需要的是 ecrecover。

从每个元组中恢复签名者后发现，全部六个授权都来自同一把密钥，且全部六个都指向同一个委托地址。

这个委托地址的代码很短，但读完就真相大白：收到转账时，它直接转发到一个硬编码的地址。没有任何你可以满足的条件，没有任何你可以走的分支。如果你发送 0.01 ETH，它就留下 0.01 ETH——你之后每一个发送「小额测试」的人也一样。

为什么六个签名很重要

多个授权签名指向同一委托地址，说明这不是一次偶然的操作失误，而是有计划的部署。攻击者可能在批量扫描暴露过私钥或签署过恶意授权的地址，然后逐一设置委托。六个签名来自同一密钥，意味着这个地址的所有者（或曾经控制该密钥的人）在多个场合签署了授权。

ecrecover 是以太坊虚拟机内置的一个预编译合约，作用是「给定消息哈希和 ECDSA 签名，反推出签名者的地址」。它不需要私钥、不需要联网、不依赖任何中心化服务，因此成为链上取证的基本工具。在本例中，研究者对每个授权元组按 EIP-7702 定义的格式重建待签名消息（包含 magic number 0x05、chain_id、委托地址和 nonce），调用 ecrecover 即可得到签名者。如果所有六个元组恢复出同一个地址，就能确凿地证明这些授权来自同一把私钥，与地址的「干净历史」并不矛盾——因为签名可以完全在链下完成，只在最后一刻上链。

本可以拦住它的三重检查

在向任何地址发送资金之前，三次链上读取就能给出答案——不需要索引器：

1. 读代码，不读历史

对该地址调用 eth_getCode。返回空 = 普通 EOA。返回以 0xef0100 开头 = 已委托：接下来的 20 字节就是委托地址。「还没有交易」什么都说明不了——一个被委托的账户可以拥有完全干净的交易历史。

2. 读委托合约

拿到委托地址，读取它的代码。问一个核心问题：普通转账进来会发生什么？它会转发吗？转发给谁？目标地址是硬编码的吗？这就是资金被吸走的地方——藏在约 30 字节的字节码里，不在任何 UI 上。

3. 读授权记录

拉取该账户的 Authorization 元组（它们存在于委托交易的交易数据中）。用 ecrecover 验证签名者。如果某个元组的签名者不是账户所有者，这是一个优先级高于一切的红色警报。

元规则：小额测试不是安全策略

对抗吸血合约，「小额测试」不是安全策略——它连测试金额一起吞。对一个被委托给吸血合约的钱包，唯一安全的转账金额是零。

为什么 AI Agent 需要关心这件事

这不是只影响人类用户的问题。AI Agent 正在成为链上活动的重要参与者——而加密支付是许多 Agent 获取报酬的方式。这意味着钱包就是它们的支付通道，而「浏览器上看着没问题」根本不算验证。

Agent 将自主发送资金，而 EIP-7702 吸血陷阱恰恰是那种能通过表面检查的陷阱：地址格式正确、历史记录合理、代码对每一次哈希查询都能正确响应。对自动化系统来说，如果不做链上代码层面的检查，几乎不可能区分一个正常地址和一个委托给吸血合约的地址。

从漏洞到工具

安全研究者将这个预检流程打包成了一个 Agent 技能。Crypto Wallet Safety Check 是一个 SKILL.md，引导 Agent 完成上述检查——委托指示符、委托代码、授权记录、nonce、蜜罐检测、permit 钓鱼——仅使用公共 RPC 端点，构造上就是只读的。另有一个配套工具 Onchain Claim Verifier 用于验证支付声明。

这两个工具在 Ko-fi 和 Payhip 上都有发布，用户可以根据偏好选择平台。

更大的图景

EIP-7702 代表了以太坊账户抽象路线上的重要一步，但它也打开了一个新的攻击面。传统的安全建议——比如「先发小额测试」——在这个新范式下已经失效。对于人类用户和 AI Agent 来说，链上安全的第一原则正在变成：先读代码，再看历史。

浏览器展示给你的是一个地址。区块链展示给你的是它将做什么。先读代码。

背景补充

eth_getCode 是标准 JSON-RPC 方法，接收一个地址和区块号，返回该地址在该区块的代码字节。对普通 EOA 返回 0x（空），对合约账户返回完整字节码，对 EIP-7702 委托账户则返回以 0xef0100 开头的 23 字节数据（3 字节前缀 + 20 字节委托地址）。这个前缀 0xef0100 是 EIP-3541 保留的「魔法字节」，普通合约无法部署以它开头的代码，所以它成为判断「是否被委托」的确定性标志。只需调用一次公共 RPC 就能得到答案，无需索引器、无需浏览器、无需信任第三方——这正是它适合嵌入 AI Agent 预检流程的原因。