EIP-7702 提案详解

赞助商：TickersBar是一个追踪加密货币价格的浏览器插件，可以在浏览网页的时候随时查看加密货币的价格变化。

设计背景与目标

以太坊一直追求账户抽象（Account Abstraction, AA），旨在消除传统外部账户（EOA）与智能合约账户之间的功能差异。EOA 目前存在多方面限制：私钥遗失风险高、仅支持固定签名算法、无法原生多签、只能用 ETH 支付 Gas、无法批量操作等，这些问题导致用户体验不佳。账户抽象的目标是让每个账户都能执行合约代码，从而增强安全性和可用性。

EIP-7702 正是在这一背景下提出的方案。它希望在不要求用户放弃现有 EOA 的前提下，为 EOA 增加短期功能改进，解决上述痛点。具体目标包括：

批量交易（Batching）：允许用户在一次交易中原子性地执行多个操作。例如将过去必须分两步完成的 ERC-20 授权和交换，合并为单笔交易。
Gas 赞助（Sponsored Transactions）：支持由账户 X 替用户账户 Y 支付手续费，即第三方代付 Gas。这样用户在没有 ETH 的情况下也能发送交易，提高链上交互的直观性。
权限分级（Privilege De-escalation）：支持用户为账户创建权限受限的子密钥（session key）。用户可以授予某子密钥执行特定操作的权力（如只能花费 ERC-20 代币且每日上限1%余额，或限定于某 DApp），而非让主私钥拥有对账户的完全控制。

通过上述改进，EIP-7702 希望提升整个应用生态的用户体验，使传统 EOA 用户无需迁移到新合约钱包也能享受智能账户的便利。这被视为迈向全面账户抽象的一大步，将 EOAs 与智能合约钱包的功能差距大幅缩小。

技术机制

EIP-7702 引入了一种新的交易类型（“设置代码交易”），允许在交易执行期间为一个或多个 EOA 临时挂载智能合约代码。其基本机制是：交易中包含一个“授权列表”（authorization list），每项授权由待执行的合约代码指针和对应账户的签名构成。在交易处理时，客户端会执行如下流程：

设置代码：对于授权列表中的每个签名账户，若该账户目前没有合约代码，则将其代码字段设置为提供的合约代码（即挂载指定的合约逻辑）。如果账户地址已存在代码但符合特殊格式，则视为委托调用指示符。
验证并执行：当交易真正执行时，EOA 将按所挂载的合约逻辑处理交易。例如，合约代码通常包含verify（验证签名/权限）和execute（执行操作）两个部分，用以替代 EIP-3074 中的 AUTH 和 AUTHCALL 操作码。这样，EOA 在该笔交易中表现得与智能合约钱包相同，可以调用其它合约、转账等。
移除代码：交易完成后，将对应 EOA 的代码字段恢复为空值，撤销本次挂载。EOA 返回普通账户状态，不保留合约逻辑。（注：原始提案中设计为交易结束后自动清除代码，但在后续讨论中作者也提出可选择让代码持久化，需用户显式用另一笔 EIP-7702 交易来清除或更换代码，以避免频繁部署脚本化代码碎片。无论实现细节如何，用户始终可以通过新授权交易来撤销或更新先前的代码授权。)

上述过程确保在单笔 EIP-7702 交易中，可以封装执行多个账户的操作。例如，用户签名好一系列操作，由捆绑器（bundler）打包发送链上时，每个用户的 EOA 都会在该交易中暂时变为能执行代码的合约账户，然后逐一验证并执行各自授权的操作，执行完毕后账户代码恢复为空。这一机制类似于 ERC-4337 的 UserOperation 捆绑，但由协议层直接支持，无需独立的入口点合约和内存池。换言之，EIP-7702 允许多个用户操作在链上一同原子执行，实现跨账户的打包交易（如多个用户共同签名参与的交易）。

为了实现上述功能，EIP-7702 不新增 EVM 操作码，而是利用已被禁用的特殊字节作为“委托调用标识”。EOA 被设置的代码实际是一个以 0xEF 开头的委托指示器，后跟一个目标合约地址。当有对该 EOA的调用发生时，EVM识别到其代码为委托标识，就会从提供的目标地址加载实际的代码并在该 EOA上下文中执行（类似于合约中的 delegatecall）。这样设计的好处是，代码逻辑可以部署在链上某处复用，EOA 只需存储对它的指针，减少重复代码的开销。此外，通过限制只有代码字段符合特定格式的 EOA 才能发起交易，保持了网络对“EOA/合约”身份的基本区分和安全约束。

值得注意的是，钱包软件在实现 EIP-7702 时需要提供特殊支持。例如，当用户尝试签名这种“设置代码”交易时，钱包应提示其正在赋予某段代码对账户的控制权，并确认用户明确理解风险。为了安全，钱包不应允许任意 DApp 引导用户签署未经审核的授权代码；更合理的做法是让用户从受信任的模板中选择（如经过审核的智能钱包模块代码），以降低恶意代码侵占账户的风险。

与其他相关EIP 的关系

EIP-4337（账户抽象合约钱包）和 EIP-3074（授权调用）是账户抽象领域的重要相关提案。EIP-7702 可以看作它们思想的结合与改进：

对比 EIP-3074：EIP-3074 提议增加两个新的 EVM 操作码 AUTH/AUTHCALL，使EOA可以授权一个“调用者合约”（invoker）代为发送交易，以实现代付和批量操作等功能。但 3074 因新增操作码和潜在安全隐患遭到质疑，迟迟未能部署。EIP-7702 则避免了新增操作码，改用新交易类型和代码挂载机制来实现等价的功能。它保留了3074的优点：用户无需换用新地址即可享受智能钱包特性，多个操作可原子执行，Gas 可由他人代付等。同时，7702 将 AUTH/AUTHCALL 的逻辑上移到合约代码级别，通过 verify/execute 实现授权验证与操作执行。这避免了将短期过渡性的指令写死在 EVM 中，防止将来完全转向合约账户后遗留无用的操作码。可以说，7702 在功能上继承了 3074，并规避了其长期协议负担。需要注意的是，由于两者原理相似，EIP-7702 也继承了 EIP-3074 提到的一些安全风险（授权滥用等），开发者在实现代码模块时需遵循安全最佳实践（例如签名包含随机数nonce、防止重放）。
对比 EIP-4337：ERC-4337 提供了一套无需共识层修改的账户抽象方案，通过用户操作池和入口点合约实现智能合约钱包的通用框架。它已经在主网部署（2023年）并被广泛采用。相比之下，EIP-7702 是共识层的改进，但与 ERC-4337 高度兼容。首先，7702 提供的合约代码指针可以直接指向现有的 ERC-4337 智能钱包合约代码，这意味着用户授权的代码很可能就是如今 DApp 和钱包生态中成熟的智能账户逻辑。这样一来，EOA 挂载的代码模块与纯合约钱包使用的模块是相同的，避免出现“两套钱包生态”而导致的碎片化。其次，在有捆绑器的环境下，EOA 通过 EIP-7702 “伪装”成合约账户参与 ERC-4337 的打包也不成问题，EntryPoint 可以将其视作兼容的钱包。总体而言，7702 与 4337 不冲突且互补：4337 已经为智能钱包铺设了基础设施（如支付工厂合约、批量器等），7702 则让传统 EOA 立即享受这些基础设施带来的好处，并为未来彻底转变为合约账户做好铺垫。
与其他提案：EIP-7702 的出现也考虑了与其它账户抽象提案的衔接。例如 EIP-5003（提议引入 AUTHUSURP 操作码实现EOA永久迁移为合约）提供了“一步到位”的账户转换方案，但由于不可逆和兼容性问题尚未被采纳。Vitalik 在设计7702时将 EIP-5003 视为可能的后续步骤，即先用7702实现临时的代码挂载提升EOA功能，再通过类似5003的机制在将来实现永久的EOA->合约账户迁移。因此，7702 可以看作以温和、逐步演进方式推进账户抽象：短期内增强EOA，长期愿景是配合后续升级彻底过渡到智能合约账户的终局状态。

总的来说，EIP-7702 融合了 EIP-3074 和 ERC-4337 的思路，走一条中间道路：既避免引入长久负担的新操作码，又与现有智能钱包生态配合良好，防止社区分裂成两种不兼容的账户体系。它所需的改动相对独立，理论上可与 ERC-4337 并行运行。一旦7702落地，EIP-3074 的需求将大幅降低（两者功能重叠，7702是更前向兼容的实现），而4337生态将因7702的加入变得更加强大、统一。

对开发者和用户的意义

对用户而言，EIP-7702 带来了传统 EOA 无法实现的众多智能钱包特性，显著改善使用体验：

一笔交易，多项操作：用户可以用一个签名完成过去需要多次点击确认的交互。例如跨链桥接或去中心化交易所操作，可以将批准、兑换、转账等步骤打包为一次提交，节省时间并避免中途失败。从此“不再需要为一次交换提交两次交易”。
交易手续费抽象：EOA 可采用Gas 代付模式，由第三方（如项目方的中继器或支付钱包）承担交易费用。用户在新链上没有原生代币也能直接使用 DApp，降低了初始门槛；DApp 也可通过补贴 Gas 提升用户留存。
无缝身份验证：支持多种签名方式和设备。由于代码可以自定义验证逻辑，EOA 不再局限于ECDSA签名。手机的安全模块、生物识别等（如 Passkey 无密码登录）都可用来授权交易。这意味用户可用指纹/面容等更友好的方式签名，提高安全性的同时减少对私钥的直接暴露。
会话密钥与限权账户：通过挂载特定代码，用户可以实现临时授权。例如在一个 DApp 中“登录”并赋予一个次级密钥有限时间或额度的操作权限（24小时内可执行特定操作等），期间用户无需每次都手动签名。这类似于Web2的会话机制，让频繁交易（如定投、游戏操作）更加顺畅，同时风险可控（授权过期后自动失效）。
灵活的安全策略：EOA 可集成多签和社交恢复等安全机制。例如，用户可将EOA升级为多重签名账户，与家人设备或朋友共同控制；若主私钥丢失，也可以通过预先设置的守护人合约来恢复资产。尽管 EOA 的私钥仍然有最终控制权，但通过代码逻辑可以增加额外的保护层。
跨链与模块化体验：因为交易可指定ChainID，EOA 可以跨多个网络使用同一套授权逻辑。在支持的场景下，用户不必手动切换网络，就能由同一EOA对不同链的资产/合约进行操作（由后台处理跨链调用和手续费），呈现出更平滑的多链体验。
无须更换地址：最直观的是，用户不需要放弃原来的地址和资产。通过 EIP-7702，现有 EOA 地址即可获得智能账户的功能扩展。这避免了将资产转移到新钱包、更新联系人地址等繁琐步骤。用户仍使用熟悉的钱包账户，却能享受智能合约钱包的完整功能。例如，未来钱包应用（如 Safe 等）可直接将用户的EOA纳入其智能账户体系，提供统一的高级功能体验。

当然，目前 EIP-7702 并非万能。由于EOA的私钥依然存在，并且对账户拥有最高权限，用户仍需妥善保管私钥/助记词。挂载的智能代码无法限制私钥直接签名一笔普通交易转走所有资产，因此在多签场景下，其它共同拥有者仍需信任原EOA持有者不作恶。同时，如果私钥遗失或被盗，尽管通过社交恢复等机制可以一定程度补救，但黑客若抢先发起撤销授权的交易，仍可能绕过合约逻辑直接控制账户。因此，7702是一种过渡方案，赋予EOA新能力的同时，其安全依赖仍与传统EOA相同，需要用户保持警惕。

对开发者而言，EIP-7702 打开的则是一个新天地：

钱包开发：钱包厂商可以在不改变用户地址的情况下提供智能账户功能，这将成为差异化卖点和行业趋势。开发者需要为新的交易类型和签名流程提供支持（例如解析授权列表、对接 bundler），并设计清晰的UI引导用户进行授权操作。另外，钱包需内置经过审计的模块代码库，供用户选择挂载，以保证安全。这类似于应用商店模型 — — 钱包提供官方支持的模块（多签模块、每日限额模块等），开发者也可以贡献模块供用户加载。总之，7702促使钱包从管理私钥的工具，演进为模块化智能账户平台，开发者有机会打造丰富的新功能插件。
智能合约/模块开发：EIP-7702 扩大了智能合约钱包代码的适用范围。之前仅服务于合约账户的逻辑（如 Gnosis Safe 模块）现在可以直接服务数以千万计的 EOA 用户。这意味着合约钱包代码将高度标准化和复用：开发者可以编写通用的“授权+执行”合约逻辑，让用户挂载后即获得某种能力。由于7702与ERC-4337钱包兼容，“一份代码，两处运行”成为可能 — — 开发者编写的合约既可部署给 4337 合约钱包使用，也可供 EOA 用户通过7702加载使用。这降低了开发和维护成本，有利于形成统一的智能账户模块生态。
DApp 集成：应用开发者在设计交互时可以假设用户有智能账户能力。例如，可以开发一次点击完成复杂操作的流程，而不再被“一笔交易只能做一件事”的限制束缚。对于需要经常交互的应用（如游戏、社交），可以利用会话密钥免去重复签名；对于新用户，可以通过Gas赞助降低上手门槛。随着7702功能普及，DApp 可以提供更接近 Web2 的顺滑体验，而不必关心用户背后用的是EOA还是合约钱包。这将激发新型用例出现。例如，多人协作的链上项目可以用7702实现链上多签批准流程；去中心化交易可以接受EOA直接批量签发的离线订单集合，等等。开发者应更新对账户模型的认知，充分利用账户抽象提供的新可能性。

总体而言，EIP-7702 为用户和开发者搭建了一座桥梁，让传统账户即时拥有了智能合约的可编程性。用户获得了更安全便捷的体验，开发者则拥有更强大的工具来构建创新应用。当然，在享受这些好处的同时，各方也需注意安全边界，如审核合约模块、警惕社工诈骗等。但不可否认的是，7702的到来标志着以太坊用户体验的巨大飞跃。

生态影响与部署路径

兼容性：EIP-7702 对现有以太坊协议进行了修改，但大部分改动是向后兼容的，普通用户不使用该功能则不会受到影响。EOA 若不采用授权交易，行为与此前完全相同。对于智能合约，大多数情况下7702也是透明的。不过需要警惕的是，少数合约依赖于 tx.origin 的旧有假设可能会被打破。例如，有些合约用 require(tx.origin == msg.sender) 来阻止合约合约的嵌套调用（试图确保只有EOA直接调用）。在7702情况下，EOA 可以在一次交易中通过其挂载代码触发多次内部调用，此时 tx.origin 仍是该 EOA，但 msg.sender 为EOA本身的合约逻辑合约，二者相等却不是在最外层调用帧中，因而绕过了此类检查。这种模式本身被认为是不安全的反模式，因此少量合约可能需要升级其防护逻辑（改用更可靠的重入保护方案）。除此之外，EIP-7702 还使得 EOA 在内部调用合约时可能增加 nonce 或转移余额（因为EOA代码可以创建合约或发送ETH），这打破了过去 “只有发起交易自身才改动其nonce/余额” 的假设。这些变化对于绝大多数应用来说并不构成问题，但作为共识层变更，需要在客户端实现和智能合约审计中加以考虑。
安全性：社区对7702的安全讨论主要集中在授权代码的审核和私钥权限的问题上。为避免用户掉入骗局，以太坊核心开发者强调钱包软件必须在交互上做好把关，不应让用户随意加载未知来源的代码。另外，EIP-7702 默认不提供像合约创建时那样的初始化过程，意味着如果账户存储需要初始化，必须通过签名交易在上链后进行，开发者需防范恶意方抢先设置存储的攻击。对于模块升级，提案也建议采用不会冲突的存储布局或在更换代码前清理旧存储，以免新旧合约逻辑的存储槽位重叠造成错误。总的来说，7702本身作为协议提供了机制，安全与否很大程度取决于所挂载的合约代码是否可靠。因此业界也在制定一些标准（如 ERC-7201）和最佳实践来指导安全的委托合约实现。未来，随着生态成熟，我们可能看到经安全公司审计认证的“官方模块库”，供用户放心使用。
升级路径：EIP-7702 属于以太坊共识层的核心改进，需要通过网络升级（硬分叉）部署。根据以太坊基金会公布的路线图，它已被纳入2025 年的 Pectra 升级（代号 “布拉格” 的下一次硬分叉）。截至目前（2025年中），7702 提案已进入最后的技术审查阶段，Last Call 截止日期为 2025年4月1日。客户端开发团队已针对7702编写实现和测试用例（在测试网Prague进行验证）。只要后续安全审计和社区共识没有出现重大障碍，7702 将随 Pectra 升级在主网激活。届时，每个以太坊节点都会接受新的交易类型，矿工/验证者也会按新规则处理授权列表和代码挂载。
社区支持：EIP-7702 由 Vitalik 等核心开发者亲自撰写提出，被认为是继 EIP-1559、质押提现后以太坊“用户层”（User Layer）的又一重大升级。许多以太坊研究者和钱包团队对其表示支持和兴趣。例如智能钱包项目 Safe 已提前开发了 EIP-7702 的原型，供开发者试验其功能。主流钱包如 MetaMask、Ledger 等也在关注该提案，评估如何在其产品中集成支持。一些安全专家对7702持谨慎乐观态度，认为它在提升体验的同时需要用户增强安全意识。总体而言，社区对7702的讨论热度和认可度都很高 — — 它被视作“可能是以太坊历史上影响最大的变化之一”，因为它直指普罗大众使用以太坊的方式变革。随着升级临近，我们将看到越来越多的教育科普、开发工具支持 EIP-7702，为最终的主网上线做准备。
长期影响：如果 EIP-7702 成功部署，我们可以预见以太坊生态会逐步过渡到智能账户为主流的时代。现有数以亿计的EOA地址将获得新生，无需迁移就能融入智能合约钱包生态。这不仅改善单个用户的体验，也会催生新的协议设计 — — 例如 DeFi 协议可以假设用户操作是原子批处理的，从而推出更复杂的组合交易；DAO 工具可以利用多签模块直接调用成员的EOA进行投票执行等。更重要的是，7702为“最终的账户抽象”（即彻底淘汰EOA、使所有账户皆为可编程合约）铺平了道路。未来可能引入的新提案（如彻底禁用EOA私钥直接发交易等）将建立在7702的基础之上。在理想情况下，几年之后用户甚至无需意识到 EOA 与合约账户的区别 — — 每个账户默认即是带有自定义安全与权限逻辑的钱包。要达成这一步，还需解决私钥完全替代、量子抗性等问题。但毫无疑问，EIP-7702 已经把以太坊推向全面账户抽象的门槛，其生态影响将是深远且积极的。我们正迈向一个更安全、易用、多功能的以太坊网络。

引用

From 4337 to 7702: A Deep Dive into the Past and Future of Ethereum Account Abstraction Track

EIP-7702: Set Code for EOAs: Add a new tx type that permanently sets the code for an EOA

EIP-7702: A Win for Smart Accounts in Ethereum’s Pectra Upgrade?

EIP-7702 Explained: How it Works and Everything You Need to Know

Pectra Mainnet Announcement

A Comprehensive Guide to Ethereum’s EIP-3074 and EIP-7702