作者：Cobo Global
以太坊主网即将迎来的 Pectra 升级是一次较大更新，一次性引入了多个以太坊改进提案（Ethereum Improvement Proposals, EIPs）。其中 EIP-7702 实现了对以太坊外部账户（ Externally Owned Account, EOA ）的重大改造，该提案模糊了 EOA 与合约账户（Contract Account, CA）的边界，提供的新能力对普通用户、各种基础设施提供商、开发者都会产生重大影响。
近期 Pectra 已经在测试网中完成，预计很快就可以上线主网。本文将深入分析 EIP-7702 的实现，展示其可能带来的机会与风险，为各类用户、从业者提供参考。
EIP-7702 概述
EIP-7702 的实际标题为 EIP-7702: Set EOA account code 副标题 Add a new tx type that permanently sets the code for an EOA。这比较概括了介绍了这个提案的核心要素：提供了一种可以为 EOA 设置合约代码的交易类型。
具体来说，这次提案引入交易类型为 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 = [[chain_id, address, nonce, y_parity, r, s], ...]
相比于我们常见的 0x02 交易类型，主要变化是添加了 authorization_list 字段。authorization_list 中的每个元素表示进行一次地址代理的授权。其中：
- chain_id 为授权生效链 ID，用于防重放
- nonce 为授权方地址的 nonce，与普通交易 nonce 一致，也用于防重放
- address 为进行地址代理时指定的代理。
- y_parity, r, s 为签名数据，通过 ecrecover 可以得到 authority 地址，即发起授权的 EOA 地址。
每个交易中可以包含多个上述授权。并且需要注意上述授权有独立的签名，与本体交易的签名不同，因此可以实现对地址授权行为的 gas 代付。钱包服务商或者 App 开发者，可以为 authority 支付 gas 实现 EOA 的授权，而无须 authority 自身地址上保存 gas。
交易上链后，会将 authority 地址的 code 字段设置成对代理地址的 委托标识（Delegation Designation, DD）。DD 的形式如下：
0xef0100 || address
其中 0xef0100 为固定前缀，address 为代理的目标地址。这里有一个细节，根据 EIP-3541，用户无法通过常规的合约部署手段（ to 为空的交易，create/create2 指令）部署 0xef 开头的合约代码。因此上述委托只有 EOA 才能发起，通过 0x04 交易完成。
委托完成后，所有针对 authority 的合约调用，均会使用 address 上的 code 作为 code，同时使用 authority 自身的 storage。使用体验十分类似 ERC-1167 代理合约。
总结：EIP-7702 使 EOA 在保留原本发起交易能力的基础上，同时具备 Proxy 合约的效果。用户可以通过 SET_CODE_TX_TYPE (0x04) 交易来设置、修改、移除 Proxy 的 Implementation 合约。
其他关于 EIP-7702 的技术细节可以阅读提案原文。
EIP-7702 带来的影响与机会
EIP-7702 是一项重大改变，对区块链行业中的各个参与方都带来了重大影响，也提供了许多新的机会。
合约钱包服务商
从提案本身的标题和实现机制中可以看出，EIP-7702 本身并不专门提供有关账户抽象（Account Abstraction, AA）的上层能力（如 gas 抽象，nonce 抽象, 签名抽象等），只是提供了将 EOA 转化成 Proxy 合约 的基础能力。因此该提案并不与现行的各类合约钱包基础设施（如 Safe, ERC-4337 等）相冲突。相反，EIP-7702 与现有的合约钱包可以几乎无缝融合。允许用户的 EOA 转变成 Safe 钱包，ERC-4337 钱包。从而集成合约提供的多签、gas 代付、批量交易、passkey 签名等等功能。合约钱包提供商如果能快速、顺滑地集成 EIP-7702，可以有效扩展用户群体，提升用户体验。
DApp 开发者
由于 EIP-7702 对 AA 钱包的用户体验上有所提升，DApp 开发者可以考虑更大范围的接入 AA 钱包，为用户与 DApp 交互提供更便捷安全的体验。如利用合约钱包的批量交易能力一次性完成多个 DeFi 操作。
另一方向 DApp 也可以考虑根据项目特性为用户定制开发 Delegation 合约，为用户提供专有的复杂合约交互功能。
资产托管方
对于交易所、资金托管方，通常需要管理大批量的地址作为其用户的充币地址，并定期进行资金归集。传统的资金归集模式中使用 EOA 地址作为充币地址，进行归集时需要向充币地址充值一定金额的 gas，并由充币地址向出金地址进行转账交易。整个资金过程涉及大量的交易发送，流程很长且需要支付高额的 gas 费用。历史上也出现过机构进行资金归集导致链上交易费用攀升，交易拥堵的情况。
EIP-7702 的出现可以将 EOA 地址无缝转化成合约钱包，由于 EIP-7702 的 gas 代付机制，不再需要 gas 充值交易的存在。同时可以利用合约钱包的可编程性，将多笔归集转账打包在单笔交易中，减少交易数量并节约 gas 消耗。最终提高归集效率，降低归集成本。
EIP-7702 带来的潜在风险
EIP-7702 带来了新的账户功能，同时也引入了潜在的安全风险，需要钱包服务商、合约开发者、用户保持警惕。
钱包服务商
由于 EIP-7702 引入了一个新的交易类型 SET_CODE_TX_TYPE (0x04)，也该交易类型也普通用户直接相关。因此 Metamask, Rabby 等软件钱包服务商与各种硬件钱包服务也需要更新软件以适配新的交易类型。
由于 EIP-7702 授权存在接管整个账户的可能，因此需要钱包服务商在 UI 展示上给予用户足够的警示，提示等级应该与 Token Approve, Permit 相当甚至更高。
对新交易类型的对接、用户交互上如果安全检查不够严格，有可能导致用户遭受钓鱼攻击。
普通用户
普通用户也需要对以太坊新交易类型保持关注，留意各类软件钱包及硬件钱包的更新。对新的特殊交易类型能够有效的识别并投入足够的重视。
此交易类型需要重点验证 Delegation 的目标合约，在有技术储备的前提下，最好能够对合约源码进行审计，避免引入安全风险。普通用户则需要关注授权的合约是否开源并提供第三方可信的审计报告。
新交易类型相比以往的交易类型更难以审计，且具备更强的对钱包的控制能力。可以预见未来一定会出现使用此交易类型的钓鱼攻击。普通用户一定要积极储备相关的知识，提高安全意识。
合约开发者
对于合约开发者，EIP-7702 提供了新的视角。针对 Delegation 合约尚没有成熟的公开库组件或者开发标准，在升级的前期很可能需要开发者各自实现自己的 Delegation 合约。建议开发者进行足够的调研，以保证规避新特性引入的安全风险。
经过 Cobo 安全团队的分析，EIP-7702 在合约安全上需要注意的内容包括但不限于以下几点：
1. Delegation 合约的初始化抢跑问题
EIP-7702 只提供了 set code 的能力，并不提供初始化合约的能力。对比开发者熟悉的 Proxy 机制来看，EIP-7702 相当于提供了更新 implemention 的能力，但未提供调用 initialize 函数的能力。
以现存的各种主流合约钱包为例，如 ERC-4337 官方实现中的钱包，其提供了 initialize 方法并且 initialize 方法上无任何权限检查。第一个调用该方法的用户可以获取钱包的所有权。
contract SimpleAccount {
function initialize(address anOwner) public virtual initializer {
_initialize(anOwner);
}
}
包括 Safe 等其他主流合约钱包也基本都存在类似的问题。因为在过往合约钱包的实现中，往往将部属合约和初始化打包在一个交易中，实现原子化操作，从而避免了抢跑问题的发生。
但在 EIP-7702 的场景下，授权签名在 authorization_list 中单独存在，抢跑机器人可以在内存池中监控授权交易，并抢先发送授权交易，同时调用初始化函数，抢夺合约钱包的权限。如果 EOA 钱包内已经有一定的加密资产，则可能在抢跑过程中直接进行资产转移，给用户造成资金损失。我们可以大胆推测在升级完成的最初一段时间，链上一定会出现基于 EIP-7702 初始化抢跑的攻击发生。
经过调研，绝大部分原有 Proxy 模型下的代码实现在 EIP-7702 场景下不能安全初始化。开发者应该对原有代码进行 EIP-7702 适配后，再开放给用户使用。用户也应注意不要对各种旧版本合约进行授权，保证资金安全。
对于开发者来说，适配 EIP-7702 主要是对初始化方法进行权限校验。典型的检验代码可能形如：
require(msg.sender == address(this), "Only self")
或
require(ECDSA.recover(hash, signature) == address(this), "Only signed")
以保证只有 EOA 自身、或者持有合法签名后才能调用初始化方法。考虑到 gas 代付场景，后者可能更为常用。
2. Delegation 合约的存储结构冲突问题
在 EIP-7702 场景下，EOA 可能会频繁的进行 Delegation 更新，相当于 Proxy 升级。由于各个 Delegation 合约可能由不同钱包厂商、DApp 开发者提供，彼此实现可能各不相同。不同于单一开发者场景下的合约升级那样容易保证各个版本的兼容性。
不同 Delegation 合约的变量存储结构大概率是完全不同的，如果合约间复用了相同的 Storage slot，那么可能会读取到错误的数据或者写入非预期的数据，造成合约功能异常。并且数据一旦出错，进行修复也需要很高的技术能力，普通用户很难处理。
这里推荐开发者使用 ERC-7201 的 Storage 管理模式，采用 Namespace 方式使用独立的 Storage 空间，避免使用默认的 0x0 开始的 slot。
3. Delegation 权限管理问题
EIP-7702 与 Proxy 合约十分类似，但在 EIP-7702 场景下从以太坊协议级别进行了 implementation 合约的管理。相当于 Proxy 拥有一个固定不可变的 owner。因此 EOA 账户可随时更新合约，修改 Storage 空间内的任意数据，进行任意操作。
开发者应该注意到这个不同，开发 DApp 时不能信任 EOA Storage 空间的数据，尤其是习惯了 Solana, SUI 用户模型下的开发者更要注意这个问题。普通用户在使用时也需要留意此问题。
比如将 EOA 代理到多签钱包后，最高级的权限仍为 EOA 私钥自身。
4. 新型 EOA 打破原有安全假设的问题
在旧版本合约中可能有些依赖发起者是 EOA 的安全假设会被打破。典型的，现有规范中常使用如下代码检查调用方是否为 EOA
require(msg.sender == tx.origin, "Only EOA")
进一步的可能假设 EOA 不具备合约调用能力而不进行批量调用的限制或者重入检查逻辑。
在 EIP-7702 场景下，EOA 与 CA 边界开始模糊，EOA 也具备执行代码的能力。即使通过了上述检查，向该 EOA 转账 ETH，仍可能触发 EOA 代理合约的 fallback 导致重入问题。或者某些限制每个交易只能调用一次的方法（如某些代币的挖矿分发方法、NFT mint 方法等），在新场景下可以通过 EOA Proxy 代码实现批量调用，实现开发者非预期的套利攻击。
参考资料
[1] EIP-3541: https://eips.ethereum.org/EIPS/eip-3541
[2] ERC-1167: https://eips.ethereum.org/EIPS/eip-1167
[3] EIP-7702: https://eips.ethereum.org/EIPS/eip-7702
[4] ERC-4337 SimpleAccount: https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/accounts/SimpleAccount.sol
[5] ERC-7201: https://eips.ethereum.org/EIPS/eip-7201
