以太坊Pectra升级深度解析EIP-7702实用指南

以太坊即将迎来 Pectra 升级，这次升级意义重大，将引入多项重要的以太坊改进提案。其中，EIP-7702 对以太坊外部账户（EOA）进行了革命性改造，模糊了 EOA 与合约账户（CA）之间的界限，是继 EIP-4337 之后迈向原生账户抽象（Native AA）的关键一步，为以太坊生态带来了全新的交互模式。Pectra 已在测试网络完成部署，预计很快将上线主网。本文将深入剖析 EIP-7702 的实现机制，探讨其机遇与挑战，并为不同参与者提供实用指南。

EIP-7702 引入了一种全新交易类型，允许 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 相同的语义。authorization_list 是列表类型，可包含多个授权条目，每个条目包含 chain_id（生效链）、address（目标地址）、nonce（与授权账户 nonce 匹配）、y_parity, r, s（授权账户签名数据）。

授权者在签署授权数据时，需先将 chain_id, address, nonce 进行 RLP 编码，与 MAGIC 数（0x05）进行 keccak256 哈希运算，得到待签名的数据，再使用私钥签名。MAGIC 作为域分隔符，确保不同类型签名不冲突。当授权者授权的 chain_id 为 0 时，授权在所有支持 EIP-7702 的 EVM 兼容链上重放生效。

交易发起者将授权条目汇聚在 authorization_list 中签名并广播。Proposer 会先预检查交易，强制检查 to 地址非空（非合约创建交易），并要求 authorization_list 至少包含一项授权条目。若多个条目由同一授权者签署，最终只有最后一个生效。

交易执行时，节点先增加发起者 nonce，再对 authorization_list 中的每个授权条目进行 applyAuthorization 操作。applyAuthorization 会先检查授权者 nonce，再增加其 nonce。若发起者与授权者为同一用户，签署授权交易时 nonce 应再加 1。

节点应用授权条目时，若遇错误会跳过该条目，但交易继续执行，避免批量授权场景中的 DoS 风险。授权应用完成后，授权者地址的 code 字段被设置为 0xef0100 || address，其中 0xef0100 是固定标识，确保此类代码只能由 SET_CODE_TX_TYPE 部署。授权者可通过将目标地址设为 0 地址来移除授权。

EIP-7702 使授权者（EOA）兼具智能合约执行与交易发起能力，为用户带来更接近原生账户抽象的体验。尽管如此，新应用场景也带来新风险，生态参与者需注意：

**私钥存储**
EOA 委托后可借助智能合约实现社交恢复，但私钥泄露风险依然存在。执行委托后，EOA 私钥仍对账户拥有最高控制权。用户或钱包服务商在完成委托后，即便删除本地私钥，也无法完全杜绝泄露风险，尤其在供应链攻击场景中。用户应时刻牢记：Not your keys, not your coins。

**多链重放**
用户可通过 chainId 选择委托生效链，或使用 chainId 为 0 在多链上重放。但需注意，多链上同一合约地址可能存在不同代码。钱包服务商应检查委托链与当前网络是否相符，并提醒用户签署 chainId 为 0 委托的风险。

**无法初始化**
主流智能合约钱包采用代理模型，通过 DELEGATECALL 调用初始化函数。EIP-7702 委托仅更新地址 code 字段，无法调用初始化函数。开发者组合适配时，应在钱包初始化操作中增加权限检查，避免初始化被抢跑。

**存储管理**
重新委托可能导致新合约复用旧合约数据，引发账户锁定或资金损失。用户应谨慎处理重新委托。开发者应遵循 ERC-7201 的 Namespace Formula，将变量分配到指定存储位置，缓解冲突风险。ERC-7779 (draft) 提供重新委托标准流程，包括使用 ERC-7201 防止冲突，验证存储兼容性，并清理旧数据。

**假充值**
EOA 委托后可作为智能合约使用，CEX 可能面临智能合约假充值风险。CEX 应通过 trace 检查充值交易状态，防范风险。

**账户转换**
EIP-7702 后，账户可在 EOA 与 SC 间转换，打破仅限 EOA 参与项目的安全假设。开发者应假设未来参与者可能为智能合约，并通过 msg.sender == tx.origin 检查防御重入攻击将失效。

**合约兼容性**
ERC-721、ERC-777 代币在转账时具有 Hook 功能，接收者需实现回调函数。委托目标合约应实现相应回调函数，确保与主流代币兼容。

**钓鱼检查**
账户委托恶意合约可能导致资金被盗。钱包服务商应尽快支持 EIP-7702 交易，并在用户签名时展示委托目标合约，缓解钓鱼风险。对目标合约进行深入自动分析可帮助用户避免风险。

EIP-7702 通过引入新交易类型，使 EOA 具备可编程性与可组合性，模糊 EOA 与合约账户界限。目前尚无实战考验的兼容 EIP-7702 的智能合约标准，不同生态参与者面临挑战与机遇。本文所述最佳实践虽无法涵盖所有风险，但仍值得借鉴应用。

**示例**
[Set EOA Account Code] https://holesky.etherscan.io/tx/0x29252bf527155a29fc0df3a2eb7f5259564f5ee7a15792ba4e2ca59318080182
[Unset EOA Account Code] https://holesky.etherscan.io/tx/0xd410d2d2a2ad19dc82a19435faa9c19279fa5b96985988daad5d40d1a8ee2269

**相关链接**
[1] https://github.com/ethereum/go-ethereum/blob/7fed9584b5426be5db6d7b0198acdec6515d9c81/core/types/tx_setcode.go#L109-L113
[2] https://github.com/ethereum/go-ethereum/blob/7fed9584b5426be5db6d7b0198acdec6515d9c81/core/state_transition.go#L562
[3] https://github.com/ethereum/go-ethereum/blob/7fed9584b5426be5db6d7b0198acdec6515d9c81/core/state_transition.go#L304
[4] https://github.com/ethereum/go-ethereum/blob/7fed9584b5426be5db6d7b0198acdec6515d9c81/core/state_transition.go#L388-L390
[EIP-7702]https://eips.ethereum.org/EIPS/eip-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