以太坊 Pectra 升级：EIP-7702 深度解析与最佳实践指南

前言

以太坊即将迎来 Pectra 升级，这是一次意义重大的更新。其中，EIP-7702 对以太坊外部账户(EOA)进行了变革性改造。该提案模糊了 EOA 与合约账户 CA 之间的界限，是朝着原生账户抽象迈进的关键一步，为以太坊生态系统带来了全新的交互模式。

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 相同的语义。authorization_list 是列表类型，可包含多个授权条目。每个授权条目中：

• chain_id 表示授权委托生效的链
• address 表示委托的目标地址
• nonce 需与当前授权账户的 nonce 匹配
• y_parity, r, s 是授权账户签署授权的签名数据

一笔交易的 authorization_list 可包含多个不同授权账户(EOA)签署的授权条目，实现对授权者的授权操作进行 gas 代付。

实现

授权者签署授权数据时，需先将 chain_id, address, nonce 进行 RLP 编码。然后将编码后的数据与 MAGIC 数一起进行 keccak256 哈希运算，得到待签名数据。最后，用授权者的私钥对哈希后的数据签名，获得 y_parity, r, s 数据。MAGIC (0x05) 作为域分隔符使用，确保不同类型签名的结果不会冲突。

当授权者授权的 chain_id 为 0 时，表示授权者允许在所有支持 EIP-7702 的 EVM 兼容链上重放授权（前提是 nonce 也刚好匹配）。

授权者签署完授权数据后，交易发起者将其汇聚在 authorization_list 字段中进行签名并通过 RPC 广播交易。交易执行前，Proposer 会先进行预检查，确保此交易不是合约创建交易，即发送 EIP-7702 类型交易时，交易的 to 地址不能为空。

此类交易要求 authorization_list 字段至少包含一项授权条目。如果多个授权条目由同一授权者签署，最终只有最后一个授权条目生效。

交易执行时，节点先增加交易发起者的 nonce 值，再对 authorization_list 中的每个授权条目进行 applyAuthorization 操作。在 applyAuthorization 操作中，节点先检查授权者的 nonce，然后增加授权者的 nonce。这意味着如果交易发起者与授权者为同一用户(EOA)，签署授权交易时 nonce 的数值应该再加 1。

节点应用授权条目时，如遇任何错误，该条目将被跳过，交易不会失败，其他授权条目继续应用，以避免批量授权场景中的 DoS 风险。

授权应用完成后，授权者地址的 code 字段将被设置为 0xef0100 || address，其中 0xef0100 是固定标识，address 是委托的目标地址。EIP-3541 的限制确保此类标识只能由 SET_CODE_TX_TYPE (0x04) 类型的交易部署。

授权完成后，授权者若要移除授权，只需将委托的目标地址设置为 0 地址即可。

通过 EIP-7702 引入的新交易类型，授权者(EOA)既可像智能合约执行代码，又保留发起交易的能力。相较于 EIP-4337，这为用户带来了更接近原生账户抽象(Native AA)的体验，大大降低了使用门槛。

最佳实践

EIP-7702 为以太坊生态注入新活力的同时，新的应用场景也带来新的风险。以下是生态参与者在实践过程中需要警惕的方面：

私钥存储

即便 EOA 委托后可借助智能合约内置的社交恢复等手段解决因私钥丢失导致的资金损失问题，但仍无法避免 EOA 私钥被泄露的风险。执行委托后，EOA 私钥依旧对账户拥有最高控制权，持有私钥便能随意处置账户中的资产。用户或钱包服务商在为 EOA 完成委托后，即便完全删除存储在本地的私钥，也不能完全杜绝私钥泄露风险，尤其是在存在供应链攻击风险的场景中。

对于用户来说，使用委托后的账户时，仍应将私钥保护放在首位，时刻注意：Not your keys, not your coins。

多链重放

用户签署委托授权时，可通过 chainId 选择委托生效的链，也可选择 chainId 为 0 进行委托，使委托在多链上重放生效，方便用户一次签名即可在多链上委托。但需注意，在多链上委托的同一合约地址中，可能存在不同的实现代码。

钱包服务商在用户进行委托时，应检查委托生效链与当前连接的网络是否相符，并提醒用户签署 chainId 为 0 的委托可能带来的风险。

用户也应注意，不同链上的相同合约地址，其合约代码并不总是相同，应先了解清楚委托的目标。

无法初始化

当前主流智能合约钱包多采用代理模型，钱包代理在部署时，通过 DELEGATECALL 调用实现合约的初始化函数，达成钱包初始化与代理钱包部署的原子化操作，避免被抢先初始化的问题。但用户使用 EIP-7702 进行委托时，仅会更新其地址的 code 字段，无法通过调用委托地址进行初始化。这使得 EIP-7702 无法像常见的 ERC-1967 代理合约一样在合约部署的交易中调用初始化函数进行钱包初始化。

开发者将 EIP-7702 与现有 EIP-4337 钱包进行组合适配时，应在钱包的初始化操作中进行权限检查（如通过 ecrecover 恢复签名地址进行权限检查），以避免钱包初始化操作被抢跑的风险。

存储管理

用户使用 EIP-7702 委托功能时，可能因功能需求变更、钱包升级等原因，需要重新委托到不同的合约地址。但不同合约的存储结构可能存在差异（如不同合约的 slot0 插槽可能代表不同类型的数据），重新委托可能导致新合约意外复用旧合约的数据，引发账户锁定、资金损失等不良后果。

用户应谨慎处理重新委托的情况。

开发者在开发过程中应遵循 ERC-7201 提出的 Namespace Formula，将变量分配到指定的独立存储位置，以缓解存储冲突的风险。此外 ERC-7779 (draft) 还专为 EIP-7702 提供了重新委托的标准流程：包括使用 ERC-7201 防止存储冲突，并在重新委托之前验证存储兼容性，以及调用旧委托的接口清理存储的旧数据。

假充值

用户进行委托后，EOA 也将可作为智能合约使用，因此中心化交易所(CEX)可能面临智能合约充值普遍化的情况。

CEX 应通过 trace 检查每笔充值交易的状态，防范智能合约假充值风险。

账户转换

实施 EIP-7702 委托后，用户账户类型可在 EOA 与 SC 之间自由转换，账户既可发起交易，也可被调用。这意味着当账户调用本身并进行外部调用时，其 msg.sender 也将是 tx.origin，这会打破一些仅限 EOA 参与项目的安全假设。

合约开发者不应再假设 tx.origin 始终是 EOA。同样，通过 msg.sender == tx.origin 检查来防御重入攻击也将失效。

开发者在开发过程中应假设未来的参与者可能都为智能合约。

合约兼容性

现有的 ERC-721，ERC-777 代币在对合约进行转账时都具有 Hook 功能，这意味着接收者必须实现相应的回调函数以成功接收代币。

开发者应确保用户委托的目标合约实现相应的回调函数，以确保能和主流代币兼容。

钓鱼检查

实施 EIP-7702 委托后，用户账户中的资产可能都将由智能合约控制，一旦用户将账户委托到恶意合约，攻击者窃取资金将变得轻而易举。

钱包服务商应尽快支持 EIP-7702 类型的交易，并在用户进行委托签名时，向用户着重展示委托的目标合约，以缓解用户可能遭受钓鱼攻击的风险。

此外，对账户委托的目标合约进行更深入的自动分析（开源检查，权限检查等）可以更好地帮助用户避免此类风险。

总结

本文围绕以太坊即将到来的 Pectra 升级中的 EIP-7702 提案展开探讨。EIP-7702 通过引入新的交易类型，使 EOA 具备可编程性与可组合性，模糊了 EOA 与合约账户的界限。由于目前还没有经过实战考验的兼容 EIP-7702 类型的智能合约标准，因此在实际应用中，不同的生态参与者，如用户、钱包服务商、开发者、CEX 等，都面临着诸多挑战与机遇。本文所阐述的最佳实践内容无法涵盖所有潜在风险，但仍值得各方在实际操作中借鉴应用。