查找币：深入探讨 EIP-7702 与最佳实践

查找币:余老师 | 学术研究 | 2026-05-10 04:04 | 2 次浏览 | 0 条回复

查找币学术研究安全研究 Web3安全区块链安全

## 查找币：深入探讨 EIP-7702 与最佳实践本文由查找币安全团队基于安全研究整理发布，旨在分享Web3安全技术，帮助用户提高安全意识。 --- 作者：Kong 编辑：Sherry 前言以太坊即将迎来 Pectra 升级，这无疑是一次意义重大的更新，众多重要的以太坊改进提案将借此契机被引入。其中，EIP-7702 对以太坊外部账户(EOA) 进行了变革性的改造。该提案模糊了 EOA 与合约账户 CA 之间的界限，是继 EIP-4337 之后，朝着原⽣账户抽象迈进的关键一步，为以太坊生态系统带来了全新的交互模式。目前，Pectra 已在测试网络完成部署，预计不久后便会上线主网。本文将深入剖析 EIP-7702 的实现机制，探讨其可能带来的机遇与挑战，并为不同的参与者提供实用的操作指南。协议分析概述 EIP-7702 引入了一种全新的交易类型，它允许 EOA 指定一个智能合约地址，进而为其设置代码。如此一来，EOA 便能够像智能合约一样执行代码，同时还保留了发起交易的能力。这一特性为 EOA 赋予了可编程性与可组合性，用户借此可以在 EOA 中实现诸如社交恢复、权限控制、多签管理、zk 验证、订阅式支付、交易赞助以及交易批处理等功能。值得一提的是，EIP-7702 能够与 EIP-4337 实现的智能合约钱包完美兼容，二者的无缝集成极大地简化了新功能的开发与应用过程。 EIP-7702 的具体实现是引入了交易类型为 SET_CODE_TX_TYPE (0x04) 的交易，其数据结构定义如下： rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s]) 其中 authorization_list 字段定义为： authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...] 在新的交易结构中，除了 authorization_list 字段，其余都遵循与 EIP-4844 相同的语义。该字段是列表类型，列表中可以包含多个授权条目，在每个授权条目中： chain_id 字段表示此授权委托所生效的链address 字段表示委托的目标地址nonce 字段需与当前授权账户的 nonce 相匹配y_parity, r, s 字段则是授权账户签署授权的签名数据‍‍ 在一笔交易内的 authorization_list 字段可以包含多个不同授权账户(EOA) 签署的授权条目，即交易发起者可以与授权者不同，以实现对授权者的授权操作进行 gas 代付。实现授权者在签署授权数据时，需要先将 chain_id, address, nonce 进行 RLP 编码。随后将编码后的数据与 MAGIC 数一起进行 keccak256 哈希运算，从而得到待签名的数据[1]。最后，使用授权者的私钥对哈希后的数据进行签名，进而获得 y_parity, r, s 数据。其中，MAGIC (0x05) 是作为域分隔符使用，其目的是确保不同类型签名的结果不会产生冲突。 // Go-ethereum/core/types/tx_setcode.go#L109-L113func (a *SetCodeAuthorization) sigHash() common.Hash { return prefixedRlpHash(0x05, []any{ a.ChainID, a.Address, a.Nonce, })} 需要注意的是，当授权者授权的 chain_id 为 0 时，则代表着授权者允许[2]在所有支持 EIP-7702 的 EVM 兼容链上重放授权（前提是 nonce 也刚好匹配）。 // Go-ethereum/core/state_transition.go#L562if !auth.ChainID.IsZero() && auth.ChainID.CmpBig(st.evm.ChainConfig().ChainID) != 0 { return authority, ErrAuthorizationWrongChainID} 当授权者签署完授权数据后，交易发起者会将其汇聚在 authorization_list 字段中进行签名并通过 RPC 进行交易广播。在交易被包含在区块中执行之前，Proposer 会先对交易进行预检查[3]，其中对 to 地址进行强制检查以确保此交易不是合约创建交易，也就是说在发送 EIP-7702 类型的交易时，交易的 to 地址不能为空[4]。 // Go-ethereum/core/state_transition.go#L388-L390if ms [...内容已精简...] -7702[EIP-4844]https://eips.ethereum.org/EIPS/eip-4844[Go-ethereum]https://github.com/ethereum/go-ethereum/tree/7fed9584b5426be5db6d7b0198acdec6515d9c81[EIP-3541]https://eips.ethereum.org/EIPS/eip-3541#backwards-compatibility[Cobo: EIP-7702实用指南] https://mp.weixin.qq.com/s/ojh9uLw-sJNArQe-U73lHQ[Viem]https://viem.sh/experimental/eip7702/signAuthorization[ERC-7210]https://eips.ethereum.org/EIPS/eip-7201[ERC-7779]https://eips.ethereum.org/EIPS/eip-7779 往期回顾查找币《Web3 项目安全手册》正式推出日文版，助力全球区块链安全建设智能合约安全审计入门篇 —— Deploy Different Contracts to the Same Address 跨链协议分析系列之 THORChain 查找币：LinkedIn 招聘钓鱼分析香港 Web3 嘉年华 | 查找币(查找币) 活动安排速览查找币导航查找币科技官网 https://www.查找币.com/ 查找币区官网 https://查找币.io/ 查找币 GitHub https://github.com/查找币 Telegram https://t.me/查找币team Twitter https://twitter.com/@查找币_team Medium https://medium.com/@查找币知识星球 https://t.zsxq.com/Q3zNvvF --- *本文由查找币安全团队整理，来源：安全研究。*

查找币：深入探讨 EIP-7702 与最佳实践

查找币安全研究院

主题延伸阅读