延伸阅读
EIP-7702 是什么?从币安热钱包被盗事件,看懂以太坊账户授权的安全风险
来源:知乎 · 查看原文
在区块链世界,私钥一直被认为是保护数字资产的最后一道防线。
只要私钥没有泄露,别人就很难直接控制你的钱包。
但如果有一天,你没有主动转账,私钥也没有被明确证实泄露,钱包里的资产却依然可能面临被转走的风险,你会不会感到意外?
2026 年 10 月 29 日发生的币安热钱包安全事件,就让一个以往相对专业的技术问题进入了更多人的视野:EIP-7702 账户委托机制,以及它可能带来的安全风险。
公开安全分析指出,这起事件涉及攻击者利用 EIP-7702 机制,将相关钱包委托给恶意清扫合约,随后转移资产。
这究竟是怎么回事?
EIP-7702 是什么?它为什么可能影响钱包资产?普通用户又该如何识别和防范相关风险?
本文将从基本原理开始,逐步解释这些问题。
一、先理解一个问题:为什么钱包授权会带来风险?
假设你的以太坊钱包里有:
2 ETH;
5000 USDT;
一些其他 ERC-20 代币。
你的私钥一直保存在自己手里,没有主动转账。
某天,你访问了一个 DeFi 网站。网站提示你签署一条授权信息,你觉得只是正常操作,于是点击确认。
之后,你发现钱包里的资产出现异常。
问题来了:你没有主动转账,为什么资产仍可能被转走?
原因之一是,你签署的操作可能不只是普通的登录或消息验证,而是授予了其他程序一定的资产操作能力。
要理解这种风险,需要先区分两种不同的授权机制。
1. 传统 ERC-20 授权:允许指定地址使用某种代币
以 USDT 为例。
当你调用代币合约的 approve 方法时,可以授权某个地址在指定额度内使用你的代币。
例如:
钱包地址:W
代币:USDT
授权对象:A
授权额度:5000 USDT
这意味着,在授权仍然有效的情况下,A 可以通过代币合约的相关方法,在额度范围内转走你的 USDT。
这里需要注意:
A 不会获得你的私钥;
A 不会获取你其他代币的权限;
这笔授权针对特定代币合约;
如果授权额度没有被使用完,风险可能持续存在。
这也是为什么钱包安全工具经常会检查 Token Approval,代币授权。
2. EIP-7702 委托:允许钱包使用指定合约的代码
EIP-7702 是另一种机制。
它允许传统以太坊外部拥有账户【EOA】,在授权后,将账户的代码执行委托给一个已经部署的智能合约。
简单理解为:
传统代币授权是:
我允许 A 使用我的某种代币。
而 EIP-7702 委托更接近:
我允许自己的钱包使用 A 提供的程序逻辑来执行操作。
这两者的影响范围并不相同。
如果被委托的代码设计得很安全,它可以让钱包支持批量交易、代付 Gas、更加灵活的权限管理等功能。
但如果委托目标是恶意合约,或者代码存在严重缺陷,风险就远远超出一次普通的代币授权。
以太坊官方规范也明确提醒,设计不当的委托代码可能让攻击者获得对账户资产近乎完全的控制能力。
二、EIP-7702 到底是什么?为什么要设计它?
EIP 是 Ethereum Improvement Proposal 的缩写,以太坊改进提案。
EIP-7702 的正式名称是:
Set Code for EOAs:为外部拥有账户设置代码。
它属于以太坊 Pectra 升级的一部分,并于 2025 年 5 月随该升级在以太坊主网上启用。
要想理解它,要先认识以太坊中常见的两类账户。
1. EOA:传统钱包账户
我们平时使用 MetaMask 等钱包创建的普通账户,通常属于 EOA。
它的典型特征是:
由私钥控制;
可以主动签署交易;
本身没有像普通智能合约那样部署业务代码;
传统操作通常需要用户签署相应交易。
2. 智能合约账户:由代码定义行为
智能合约账户的行为由部署在链上的代码决定。
开发者可以通过代码实现:
多个操作打包执行;
复杂的权限管理;
交易赞助;
更灵活的资产操作流程。
但传统 EOA 与智能合约账户在使用体验上存在差异。
EIP-7702 的目标之一,就是让传统 EOA 能够获得部分智能账户能力,而不必完全放弃原来的账户地址。
3. EIP-7702 是怎么实现的?
假设你有一个普通钱包 W,希望让它具备智能账户功能。
你可以通过 EIP-7702 授权,将 W 的代码执行委托给已经部署的合约 A。
概念上可以理解为:
原来的钱包 W
|
| 签署有效的 EIP-7702 授权
|
v
钱包 W 设置委托标记
|
v
指向合约 A
|
v
当钱包 W 被调用时
可以执行合约 A 提供的代码
需要特别注意:并不是将钱包资产转入合约 A。
钱包 W 仍然是原来的账户地址,资产也不会仅仅因为设置委托就自动转移。
变化的是:钱包 W 的代码执行行为可以受到委托目标所提供的代码影响。
这也正是它的价值与风险所在。
三、币安热钱包事件:需要关注的是什么?
2026 年 10 月 29 日发生的币安热钱包事件中,攻击者利用 EIP-7702 委托机制,将相关热钱包指向攻击者部署的清扫合约,随后转移资产。独立分析还描述了多条链上的资金流动。
但是,不能把所有尚未确认的攻击细节都当作事实。尤其是攻击者如何获得签名、授权操作为何能够通过安全系统,以及不同链上的攻击是否使用了完全相同的方式,都应以官方调查和可靠的后续证据为准。
从安全原理上看,这类事件值得关注的地方有三个。
1. EIP-7702 不是攻击者
EIP-7702 是一种协议功能。
它允许钱包委托代码,从而实现更灵活的账户能力。
如果没有这项功能,攻击者就不能以同样的方式利用 EIP-7702 委托机制。但这并不意味着协议本身存在漏洞。
就像汽车可以帮助人们出行,也可能被不法分子利用一样,技术能力本身与具体攻击行为需要分开讨论。
2. 攻击者如何获得有效授权
EIP-7702 的授权需要符合协议规定的签名和账户状态等条件。
因此,分析具体事件时,一个重要问题是:
攻击者为什么能够取得有效的授权,或者让系统接受相应的授权?
可能涉及的安全问题包括:
私钥或签名能力泄露;
钱包或交易签名系统被入侵;
用户或操作人员被诱导签署危险授权;
授权验证、交易审批或安全监控存在缺陷。
这些是不同的攻击路径,不能在没有证据时直接认定某一种就是事件的真实原因。
3. 授权恶意合约,资产风险可能很大
假设某个钱包委托给了恶意清扫合约。
如果该合约的代码能够访问钱包的资产操作能力,并且没有有效的安全限制,那么攻击者就可能尝试将资产转移到指定地址。
因此,真正需要审查的,不只是委托目标的名字,而是:
委托目标是什么;
它的代码具体做什么;
谁能够调用相关功能;
它是否限制转账对象和金额;
是否存在未经授权就可以执行的危险路径。
这也是为什么不能把 EIP-7702 委托简单等同于普通的 ERC-20 授权。
四、钱包可以委托多个合约吗?
这是一个很重要的问题。
假设你的钱包 W 先委托给合约 A,后来又将委托目标改为合约 B。
第一步:
钱包 W
|
v
委托目标 A
第二步:更换委托目标
钱包 W
|
v
委托目标 B
对于同一条链上钱包,EIP-7702 新的委托可以替换原来的委托。
A 不会仅仅因为过去曾经是委托目标,就永久保留通过那条旧委托执行代码的能力。
但这并不意味着更换委托就可以彻底消除 A 带来的风险。
我们需要区分三种情况。
情况一:A 只有旧的 EIP-7702 委托
如果 A 只能通过 W 当前的 EIP-7702 委托关系执行相关代码,那么当 W 的委托被替换为 B 后,旧的 A 不能再通过原来的委托关系执行。
情况二:A 还拥有独立的代币授权
假设你曾经另外授权 A 使用 5000 USDT。
后来,你把 EIP-7702 委托从 A 改为 B。
这笔独立的 USDT 授权不会因为委托关系改变而自动撤销。
只要对应的代币授权仍然有效,A 就可能继续使用剩余额度。
更换委托目标不等于撤销所有代币授权。
情况三:攻击者已经掌握钱包私钥
如果攻击者已经掌握 W 的私钥,那么问题更加严重。
攻击者可能利用私钥签署新的交易或授权。即使你清除了旧的委托,也不能仅凭这一步就恢复钱包的安全性。
说明一个常见误解:
智能合约不能仅仅因为被委托,就直接读取你的钱包私钥。
私钥通常保存在钱包的安全环境中,不会因为 EIP-7702 委托而自动暴露给合约。
真正的风险在于恶意代码能够利用被授予的账户执行能力,或者攻击者本身已经取得了有效签名能力。
如果私钥泄露,应迁移资产、使用安全的新钱包,并检查其他仍然有效的授权。
五、怎么检查自己的钱包是否存在 EIP-7702 委托?
理解原理之后,最实际的问题就是:
我怎么知道自己的钱包是否已经委托给某个合约?
对于以太坊主网,我们可以通过 RPC 查询钱包的链上代码。
1. EIP-7702 委托在链上是什么样子?
标准的 EIP-7702 委托标记由两部分组成:
0xef0100 + 20 字节委托目标地址
因此,标准委托标记的总长度为 23 字节。
例如:
0xef0100
490aac77c960b0569c8e446ac7e12490bd44ca1d
前面的 0xef0100 是委托标记,后面的 20 字节是委托目标地址。
这是 EIP-7702 规范定义的格式。
2. 为什么可以通过 eth_getCode 检查?
以太坊提供了 eth_getCode RPC 方法,可以查询某个地址在指定区块状态下的链上代码。
如果钱包当前存在标准 EIP-7702 委托,查询结果就可以用于识别上述委托标记。
所以,检测流程可以简化为:
输入钱包地址
|
v
通过 RPC 查询链上代码
|
v
判断代码长度是否为 23 字节
|
v
检查前 3 字节是否为 ef0100
|
+---- 是:解析后 20 字节
| 输出委托目标地址
|
+---- 否:未发现标准委托标记
3. 这里使用 Go 实现一个简单的检测程序
我自己也实际搭建并测试了这个基础检测程序。
项目使用 Go 和 go-ethereum 客户端库,通过以太坊主网 RPC 查询指定钱包的链上代码。
关键代码如下:
code, err := client.CodeAt(ctx, address, nil)
if err != nil {
log.Fatalf("查询钱包链上代码失败: %v", err)
}
fmt.Printf("链上代码长度: %d 字节
", len(code))
fmt.Printf("链上代码: 0x%x
", code)
fmt.Println()
if len(code) == 23 && bytes.Equal(code[:3], delegationPrefix) {
delegateAddress := common.BytesToAddress(code[3:])
fmt.Println("检测结果: 发现 EIP-7702 委托")
fmt.Printf("当前委托目标: %s
", delegateAddress.Hex())
fmt.Printf("委托目标浏览器: https://etherscan.io/address/%s
", delegateAddress.Hex())
fmt.Println()
fmt.Println("注意:检测到委托不代表该目标一定恶意。")
fmt.Println("建议继续检查委托目标的合约代码、来源及安全性。")
return
}
fmt.Println("检测结果: 未发现标准 EIP-7702 委托标记")
fmt.Println("说明:本次查询到的链上代码不符合标准委托标记格式。")
fmt.Println("这不代表该钱包没有 ERC-20 授权,也不代表它从未使用过 EIP-7702。")
如果检测到委托,程序会输出当前委托目标地址;如果没有检测到,则输出未发现标准委托标记。
========== EIP-7702 委托检测 ==========
网络: Ethereum Mainnet
RPC: https://ethereum-rpc.publicnode.com
钱包地址: 0x1111111dD38A3739119BeA9fB2211A13e0306A8c
链上代码长度: 23 字节
链上代码: 0xef0100490aac77c960b0569c8e446ac7e12490bd44ca1d
检测结果: 发现 EIP-7702 委托
当前委托目标: 0x490Aac77c960B0569C8E446aC7E12490bD44Ca1D
委托目标浏览器: https://etherscan.io/address/0x490Aac77c960B0569C8E446aC7E12490bD44Ca1D
注意:检测到委托不代表该目标一定恶意。
建议继续检查委托目标的合约代码、来源及安全性。
该程序只负责识别委托关系,不负责判断目标合约是否恶意。
查询结果只能反映所选链和查询时点的状态。它不能证明钱包过去从未使用过 EIP-7702,也不能代替对其他链的独立检查。
4. 检测到委托,就说明钱包被盗了?
当然不是。
一个钱包可能因为正常的智能账户功能而委托给经过审计的合约。
所以,检测到委托之后,还需要进一步分析:
委托目标是否为你预期的地址;
目标合约是否经过审计;
合约是否存在可被任意人调用的危险功能;
该委托是否由你本人或可信钱包服务设置;
钱包是否还存在独立的 ERC-20 授权。
同样,没有检测到 EIP-7702 委托,也不代表钱包绝对安全。
传统代币授权、私钥泄露以及其他类型的签名授权,都可能带来不同的风险。
六、EIP-7702 委托与传统代币授权,应该分开检查
为了避免混淆,我们可以把两种检测方式放在一起比较。
重要的结论是:
两种检测互相补充,不能相互替代。
七、普通用户应该如何降低风险?
并不是所有用户都需要完全避免 EIP-7702。
这项技术确实可以改善钱包的使用体验。但对于普通用户来说,理解授权内容比盲目追求新功能更重要。
1. 不要随意签署看不懂的授权
如果钱包突然要求你签署与当前操作明显不符的授权,尤其是涉及代码委托、账户权限或复杂交易的内容,应暂停操作。
不要因为网站显示“领取奖励”“验证钱包”或“免费领取代币”,就默认所有签名都是安全的。
2. 认真核对委托目标
如果钱包提示你将账户委托给某个合约,应确认:
该地址是否来自官方渠道;
合约是否为预期的实现;
是否存在可信的审计报告;
钱包是否清楚展示了委托目标和实际影响。
只看到合约地址还不够,因为普通用户通常无法直接判断代码是否安全。
3. 定期检查传统代币授权
如果你曾经使用过 DEX、借贷协议或其他 DeFi 应用,可以定期检查代币授权。
不再需要的授权可以考虑撤销,但要注意撤销交易也需要支付 Gas。
同时,撤销代币授权并不等于清除 EIP-7702 委托。
4. 如果发现未知委托,不要直接继续操作
建议先确认当前网络和委托目标,再评估风险。
如果确认委托未经本人授权,或者存在明显恶意行为,应优先考虑保护剩余资产,并使用可信的钱包工具处理委托和其他授权。
如果有理由怀疑私钥或签名系统已经泄露,单纯更换委托目标并不足以解决问题。
5. 对交易所而言,风险控制不能只依赖单一技术
交易所热钱包通常涉及签名系统、交易审批、权限管理、监控与资金管理等多个环节。
针对 EIP-7702 相关风险,可以考虑:
对敏感授权设置更严格的审批流程;
限制热钱包可以执行的操作;
监控异常委托和大额资金流动;
对签名系统实施隔离与访问控制;
在关键交易广播前增加独立验证。
这些措施的目的,是降低单一环节失效导致重大资产损失的概率。
八、总结:EIP-7702 不是问题,授权安全才是核心
回到最开始的问题:
为什么一个以太坊钱包可能在没有发生传统意义上私钥直接泄露的情况下,仍然面临严重的资产风险?
因为账户安全不只取决于私钥是否泄露,还取决于用户授予了什么权限、授权如何被验证,以及获得权限的代码实际能够做什么。
EIP-7702 为传统钱包提供了新的账户能力,也引入了新的安全考量。
我们可以记住三个结论:
第一,EIP-7702 本身是一项协议功能,不应把使用该功能的攻击直接等同于协议漏洞。
第二,更换或清除 EIP-7702 委托,不会自动撤销所有独立的代币授权,也无法解决已经发生的私钥泄露。
第三,检测钱包安全时,应该同时关注当前委托、传统代币授权和私钥或签名系统的安全。任何单一检测都无法证明钱包绝对安全。
感谢大家看到最后,其实最重要的不是记住所有技术名词,而是在每一次签名前弄清楚:
我正在授权什么?
谁会获得什么能力?
如果我后悔了,应该如何撤销?
理解这些问题,才能在享受区块链技术带来便利时,更好地保护自己的数字资产。