以太坊Pectra升级：EIP-7702全面解析与影响

以太坊主网即将迎来 Pectra 升级，这次更新可不简单哦！它一次性引入了多个以太坊改进提案（EIPs），其中 EIP-7702 对以太坊外部账户（EOA）进行了重磅改造。这项提案不仅模糊了 EOA 和合约账户（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 字段。这个字段中的每个元素代表了一次地址代理的授权哦！

• chain_id：这是授权生效的链 ID，避免重放攻击的必备元素。

• nonce：授权方地址的 nonce，跟普通交易的 nonce 一样，也有防重放的功能。

• address：在地址代理时指定的代理地址。

• y_parity, r, s：这些是签名数据，通过 ecrecover 方法可以获取到 authority 地址，也就是发起授权的 EOA 地址。

每个交易可以包含多个这样的授权。要注意的是，这些授权是独立签名的，和本体交易的签名不一样，因此可以实现地址授权行为的 gas 代付。钱包服务商或应用开发者可以为 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，同时保留 authority 自身的 storage。这种体验和 ERC-1167 代理合约非常相似。

影响与机会：EIP-7702 赋予 EOA 在保留原有交易能力的同时，具备 Proxy 合约的特性。用户可以通过 SET_CODE_TX_TYPE (0x04) 交易来设置、修改或移除 Proxy 的实现合约。

关于 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，才能进行资金归集和转账交易。这一过程繁琐且费用高昂，曾经也导致了链上交易费用飙升和交易拥堵的情况。

EIP-7702 的到来可以将 EOA 地址无缝转化为合约钱包，且因其 gas 代付机制，不再需要 gas 充值交易的步骤。同时，可以利用合约钱包的可编程性，将多笔归集转账打包为单笔交易，从而减少交易数量，节省 gas 消耗。最终，归集效率提升，成本降低，是必然的结果。💰

EIP-7702 带来的潜在风险

EIP-7702 引入了新的账户功能，但同时也伴随潜在的安全风险，因此钱包服务商、合约开发者和用户都需保持警惕。⚠️ 由于 EIP-7702 带来了新交易类型 SET_CODE_TX_TYPE (0x04)，这不仅是个技术更新，还直接影响到普通用户的体验。所以，像 Metamask、Rabby 这样的软件钱包，以及各种硬件钱包，得赶紧更新他们的系统，以支持这个新玩意儿。

提醒用户的必要性 🚨

EIP-7702 的授权机制可能让人失去整个账户的控制权，因此钱包服务商在界面上得给用户足够的警示。提示的级别应该和 Token Approve、Permit 相当，甚至还得更高。

如果在新交易类型的对接和用户互动中安全检查不够严谨，很可能就会让用户掉进钓鱼陷阱 🐟。

普通用户的关注点 👀

普通用户要时刻关注以太坊的新交易类型，留意各类钱包的更新。对这些新交易类型，得学会识别并给予足够重视。

这类交易需要特别验证 Delegation 的目标合约。如果有技术能力，最好能审计合约的源代码，避免安全隐患。用户还应该关注授权合约是否开源，并查看是否有第三方的可信审计报告。

新交易类型比起以往的交易更难审计，且控制钱包的能力也更强。未来一定会出现利用这一交易类型的钓鱼攻击，普通用户得积极学习相关知识，提高安全意识 🧠。

合约开发者的挑战 💻

对于合约开发者来说，EIP-7702 提供了全新的视角。由于目前针对 Delegation 合约尚无成熟的公开库或开发标准，开发者可能需要自创 Delegation 合约。建议多做调研，以规避新特性带来的安全风险。

根据 Cobo 安全团队的分析，EIP-7702 在合约安全方面需要特别注意以下几点：

1. Delegation 合约的初始化抢跑问题

EIP-7702 只赋予了 set code 的能力，却没有提供初始化合约的功能。对比大家熟悉的 Proxy 机制，EIP-7702 就像是给了更新实现的能力，但没法调用 initialize 函数。

例如，在现有的主流合约钱包中，比如 ERC-4337 的官方实现，提供了一个 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 的存储管理模式，采用 namespace 的方式，给 storage 空间分配独立的区域，别再用默认的 0x0 开头的 slot 啦。

权限管理问题⚖️

EIP-7702 和 Proxy 合约几乎是一对孪生兄弟，但在 EIP-7702 的场景下，合约管理是在以太坊协议层面进行的。可以理解为 Proxy 有个固定的、不可变的 owner。因此，EOA 账户可以随时更新合约，随意修改 storage 空间里的数据，想干啥就干啥。

👀 开发者得注意这点，开发 DApp 时别完全信任 EOA storage 空间的数据，尤其是那些习惯了 Solana 和 SUI 用户模型的开发者们，得多留心。普通用户在使用时也要小心哦。

🔑 比如，将 EOA 代理到多签钱包后，最高权限还是得靠 EOA 私钥自己。

新型 EOA 的安全假设问题🚨

旧版本合约可能会依赖发起者是 EOA 的安全假设，这下可就打破了。常见的做法是用如下代码来检查调用者是不是 EOA：

require(msg.sender == tx.origin, "Only EOA")

但更进一步的假设是 EOA 没有合约调用能力，因此不设批量调用限制或重入检查逻辑。

在 EIP-7702 的场景下，EOA 和合约的边界开始变得模糊，EOA 也能执行代码了。即使通过了上述检查，往该 EOA 转账 ETH 仍可能触发 EOA 代理合约的 fallback，造成重入问题。或者某些限制每笔交易只能调用一次的方法（例如某些代币的挖矿分发方法、NFT mint 方法等），在新场景下可以通过 EOA Proxy 代码实现批量调用，导致开发者没想到的套利攻击。

参考资料

[1] EIP-3541: https://eips.ethereum.org/EIPS/eip-3541 微小发报道：

• ERC-1167: 轻量合约，简化了合约的部署过程，节省了链上资源！更多详情在EIP-1167。

• EIP-7702: 新的提案，旨在提升以太坊的功能性和可扩展性，具体信息看EIP-7702。

• ERC-4337 SimpleAccount: 这个简单账户合约实现了账户抽象，提升用户体验，查看代码请访问SimpleAccount.sol。

• ERC-7201: 另一个重要的提案，关注合约的安全性和灵活性，详细信息可见EIP-7201。