EIP-7702 解决了什么问题？
任何构建过 dApp 的人都知道，区块链用户体验存在显著的摩擦。用户必须为简单操作签署多个交易，必须仅使用原生代币支付手续费，并且管理完全访问其账户的私钥。这些限制源于外部拥有账户（EOAs）的基本结构——以太坊上的标准用户账户。
EIP-7702 旨在通过允许 EOAs 将其执行委托给智能合约来解决这些用户体验问题，有效地赋予它们可编程能力，而无需用户迁移到全新的钱包。
为什么用户不想迁移到智能账户
虽然智能账户提供了更优越的功能，但让用户从现有的 EOAs 迁移到智能账户面临几个重要原因的挑战：
入门摩擦
智能账户要求用户：
部署一个新合约（需要支付手续费） 将资金存入这个新账户 学习新的接口和工作流程 支付部署手续费（对于新用户来说是一个恶性循环）
账户历史和身份的丧失
当用户迁移到智能账户时：
他们会获得一个全新的区块链地址 他们的 EOA 的交易历史不会被转移 他们的链上声誉和身份变得支离破碎 NFT、POAPs 和其他数字收藏品留在旧地址 他们失去了与识别其先前地址的 dApp 的连接
有限的可移植性
EOAs 在钱包之间具有通用的可移植性：
任何钱包软件都可以使用私钥或助记词导入 EOA 相同的地址在所有钱包界面中均可正常工作
智能账户具有有限的可移植性：
不同的钱包支持不同的智能账户实现 在钱包提供商之间搬迁可能很困难或不可能 每个智能账户实现具有不同的功能和限制 跨钱包兼容性没有保证
这些迁移障碍解释了尽管智能账户的好处，大多数用户仍然继续使用 EOAs。EIP-7702 试图通过在现有 EOAs 上引入智能账户功能，来缩小这一差距，而无需用户更改地址或迁移资金。
当前以太坊账户的情况
在深入 EIP-7702 之前，让我们回顾一下当前的以太坊账户类型：
外部拥有账户（EOAs）：这些是由私钥控制的传统用户账户。当你创建 MetaMask 钱包时，你在创建一个 EOA。这些账户： 可以发起交易 不能包含代码 完全由私钥控制 必须使用原生 ETH 支付手续费 合约账户：这些是你部署的智能合约。它们： 包含并执行代码 由其代码逻辑控制 无法发起交易（只能响应交易） 不能直接支付手续费（由调用者支付） 智能账户：这些是被设计为用户账户的智能合约。它们提供许多可编程特性：该领域有几个标准（ERC-4337、ERC-7579、ERC-6900）以及多个提供智能账户解决方案的供应商（如 Biconomy Nexus、Safe、Kernel、Alchemy 等）。虽然这些实现的架构可能不同，但它们都旨在提供超出 EOAs 所能提供的增强能力。 多种授权方法：包括多重签名要求、社交恢复和时间锁 手续费抽象：使用 ERC-20 代币支付费用，而不使用 ETH 或由第三方赞助费用 批量交易：在单个交易中执行多个操作 可编程权限：会话密钥、支出限额和特定于应用的权限 恢复机制：在没有助记词的情况下恢复访问的选项 模块化组件：可插拔验证、执行、Hook 和回退
问题在于大多数用户的 EOAs 来自 MetaMask 等钱包，迁移到智能账户需要额外的步骤和教育。EIP-7702 通过增强 EOAs 以引入一些智能账户功能，提供了一条中间道路。
EIP-7702：技术概述
EIP-7702 引入了一种新的交易类型，其中包含一个“授权”字段。该字段允许 EOA 所有者将其账户的执行委托给智能合约。简单来说，你的 EOA 可以说：“当我接收到交易时，请运行这个智能合约代码。”
工作原理：
用户从他们的 EOA 签署一条特殊的授权消息 该授权包含在交易中 在处理时，以太坊网络记录该 EOA 应委托给特定的智能合约 对该 EOA 的未来交易将执行智能合约的代码 重要的是，这些交易中的 msg.sender保持为 EOA 的地址
这不同于代理合约，因为委托发生在协议层面——没有为每个用户部署单独的合约。相反，EOA 似乎具有直接附加的代码。
EIP-7702 能做什么？
EIP-7702 为 EOAs 启用三种主要增强功能：
1. 交易批处理
目前，像“批准代币和交换”这样的常见操作需要两个独立的交易。利用 EIP-7702，这些可以合并为一个原子交易。例如，一个 DEX 可以允许用户在一个交易中批准并交换代币，从而降低手续费并改善用户体验。
更高级的批处理可能包括这样的操作：一个步骤的输出作为下一个步骤的输入。
2. 费用赞助
EIP-7702 启用了第三方费用支付场景。例如：
应用程序可以为其用户的交易支付费用 用户可以使用 ERC-20 代币而不是 ETH 支付手续费 服务可以提供交易打包和费用优化
3. 权限管理
用户可以创建具有限制权限的子密钥，例如：
只能与特定应用交互的密钥 每天只能支出其持有的 1% 的密钥 可以交易 ERC-20 代币但不能交易 ETH 的密钥
重要限制
尽管有这些好处，EIP-7702 有一些关键限制，使其不同于完全的智能账户：
EOA 的私钥依然至高无上的权能：私钥始终可以通过签署新交易来覆盖任何授权。这意味着无法实现真正的多重签名或时间锁功能。 没有部署的持久性：与拥有自己地址的已部署智能合约账户不同，EIP-7702 的委托可以被覆盖。这意味着 EOA 仍然在本质上是一个具有智能功能的 EOA，而不是一个真正的智能账户。 多链问题：默认情况下，EIP-7702 的授权是链特定的，这意味着用户需要为每个链签署单独的授权。有一种变通方法，用户可以签署一个 chain_id设置为0的授权，这将在所有链上有效。然而，只有当用户的 EOA 在所有链上具有相同的 nonce 时，这种方法才有效，而在实践中这很少发生。这个限制可能导致在多链工作时出现同步问题。
谁控制 EIP-7702？钱包，而不是应用
这点很重要：EIP-7702 由钱包控制，而不是应用程序。
虽然从技术上讲，任何实体都可以创建 EIP-7702 授权，但钱包提供商已明确表示，他们将拒绝应用程序中包含授权字段的交易。相反，钱包将自行管理 EIP-7702 的授权，将用户升级到钱包所选择的智能账户实现。
这意味着：
每个钱包将选择自己的智能账户实现 用户无需迁移到新钱包 应用程序无法直接使用 EIP-7702 将用户账户委托给其首选的智能账户 随着不同钱包采用不同的实现，将出现分化
嵌入式钱包的特殊情况
嵌入式钱包，如 Privy、Dynamic、Web3Auth、Magic 等，代表了一个独特的类别，可能具有不同的 EIP-7702 实现策略。与独立钱包不同，嵌入式钱包提供商可能允许开发者委托到自定义智能合约账户实现。
根据与嵌入式钱包开发者的对话，他们似乎计划建立合理的默认配置，并在需要时允许开发者覆盖这些默认设置。这将为应用程序开发者在如何利用 EIP-7702 功能方面提供更多灵活性。
这些实施策略的具体细节尚待揭晓，因为嵌入式钱包提供商尚未公开宣布他们对 EIP-7702 的支持计划。随着这些提供商发布他们的官方实现，将会有更多信息可用。
应用程序如何使用 EIP-7702 功能
由于应用程序无法直接控制 EIP-7702 授权，那么它们如何从这些功能中受益呢？几种方法正在逐渐出现：
ERC-7710/7715 方法
此方法将 EIP-7702 与另外两个标准结合：
ERC-7710：为智能合约创建一个标准接口，以将权限委托给其他合约。可将其视为 ERC-20 批准函数的扩展，但适用于任意权限。 ERC-7715：引入了一种新的 JSON-RPC 方法，称为 wallet_grantPermissions，应用程序可以用它向钱包请求权限。
流程如下：
一个钱包使用 EIP-7702 将用户的 EOA 委托给支持 EIP-7710 的智能合约 应用程序通过 EIP-7715 请求从用户账户支出的权限 钱包向用户显示该请求 如果批准，应用程序现在可以通过代理执行操作
应用程序可以选择：
请求其合约与用户账户交互的直接权限，或者 部署自己的智能账户（称为“伴随账户”）与用户账户交互
ERC-5792 方法
此方法利用 ERC-5792 中定义的wallet_sendCalls JSON-RPC 方法：
应用程序使用 wallet_sendCalls将多个函数调用发送到钱包钱包决定如何将这些调用打包为一个序列 钱包可以在后台使用 EIP-7702 将其作为批处理执行 用户仅需对整个序列签名一次
该方法对于单链上简单的批处理场景特别有用，例如将代币批准和兑换操作结合起来。钱包处理所有打包交易的复杂性，应用程序不需要知道钱包如何实现此功能。
ERC-5792 仅用于_批量执行_。对于复杂于此的任何操作，你需要使用 ERC-7710/ERC-7715。
伴随账户方法
Biconomy 的解决方案利用他们所称的“伴随账户”——特定应用的智能账户，充当中介。流程如下：
应用程序为自身使用部署一个伴随智能账户 用户授予该伴随账户权限（如果钱包支持的话，通过 EIP-7710/7715） 伴随账户然后处理复杂的操作，如批处理、费用赞助等。
这种方法允许每个应用程序实现所需的确切智能账户功能。例如：
DeFi 应用可能会部署一个具有批量交易功能的伴随账户 游戏应用可能会部署一个具有免手续费交易的账户 跨链应用可能会部署一个具有多链执行能力的账户
融合执行（Biconomy 的回退机制）
鉴于并非所有钱包最初都会支持 EIP-7710/7715，Biconomy 创建了一种称为“融合执行”的回退机制，可以与任何钱包一起使用：
该方法重新利用常规 EVM 交易或 ERC-20 允许功能中的字段 用户似乎向伴随账户进行常规转账 隐藏在该交易中的额外信息（压缩成一个哈希） 交易被发送到： 常规以太坊 RPC（用于转账） 一个处理其他指令的专门节点
这使得即使在不支持较新标准的钱包中，也能实现复杂操作。
使用 EIP-7702 实现廉价智能账户部署
EIP-7702 的一个经常被忽视的特性是，它使开发者能够以比以前便宜高达 80% 的成本为用户部署新的智能账户。它通过利用 EIP-7702 代理只需 12500 gas 的事实来实现。通过使用一些巧妙的密码学技巧——例如Nick 的方法和签名打包——开发者可以仅通过 EIP-7702 部署完全功能的智能账户（支持资源锁定、时间锁和多重签名）。
这种方法的部署成本节省使伴随账户在以太坊主网上的使用成为可行（伴随账户的部署成本在0.5 范围内），并在 rollups 上基本免费。此外，对以智能账户为优先的（无 EOA）钱包来说，使得新用户的上手成本同样可负担。
在我们的详细指南中了解更多。
这对开发者意味着什么
如果你是应用程序开发者，这里有你需要知道的：
你不能直接使用 EIP-7702：钱包控制授权，而不是应用程序 关注钱包实现：主要钱包将以不同方式实现 EIP-7702，你需要适应每一种 考虑伴随账户：如果你需要特定的智能账户功能，开发伴随账户方法可能是最灵活的解决方案 为分化做好准备：并非所有链都会同时实现 EIP-7702，且并非所有钱包将以相同方式支持它 看超出基本用例的情况：尽管批量和费用赞助是初始重点，EIP-7702 与其他技术的结合可能会启用更高级的功能，如多链操作和基于意图的交易
开发者工具：Biconomy 的 AbstractJS
对于开发者来说，导航 EIP-7702 生态系统可能是一个挑战。实施钱包兼容性检查以支持 ERC-7710/ERC-7715/ERC-5792，部署伴随智能账户以及处理各种编码要求可能迅速导致复杂的条件逻辑和难以维护的代码。
为了解决这些挑战，Biconomy 提供了 AbstractJS——一个基于viem构建的全面 TypeScript SDK，简化了 EIP-7702 的集成。这个工具包将钱包功能检测、伴随账户部署和交易编码的复杂性抽象到一个干净的开发者接口上。
Biconomy 正在积极增强 AbstractJS 以支持所有 EIP-7702 功能，计划在 Pectra 合并时（预计在 2025 年 4 月左右）实现生产就绪的实现。
展望未来
EIP-7702 代表了区块链用户体验演进中的重要一步，但它并不是最终形式。该标准本身只是更广泛的生态系统改进的一部分，包括 EIP-7710、EIP-7715、ERC-4337 等。
最有趣的进展可能来自这些标准的结合，以创造新的用户体验。例如，将 EIP-7702 的委托与基于意图的系统结合，可能允许用户表述他们想要实现的目标（例如，“在所有 DEX 上以最佳价格交换 X 为 Y”），而不是指定确切的交易参数。
虽然在钱包实施不同的方法时会有分化和成长的痛苦，但整体方向是更用户友好的区块链交互，隐藏复杂性而不牺牲安全或控制。
术语表
EOA（外部拥有账户）：以太坊上的标准用户账户，由私钥控制。
EIP-7702：一个以太坊改进提案，允许 EOAs 将其执行委托给智能合约。
ERC-7710：一个标准接口，用于智能合约将权限委托给另一个合约。
ERC-7715：一个标准，引入了一种新的 JSON-RPC 方法，应用程序可以用它向钱包请求权限。
ERC-5792：一个标准，定义了一个“钱包调用 API”，允许应用程序发送多个调用以由钱包打包。
ERC-4337：一个“账户抽象”标准，使得智能合约钱包无需对以太坊协议进行更改。
智能账户标准：包括 ERC-7579 和 ERC-6900 在内的各种智能合约账户标准，为模块化、可编程用户账户提供框架。
伴随账户：一个特定于应用的智能账户，作为用户与应用间的中介。
融合执行：Biconomy 的方法，启用智能账户功能而无需钱包支持较新标准。
MEE（模块化执行环境）：一个高级执行系统，可以处理复杂的交易流，包括多链操作。
原文链接：blog.biconomy.io/a-compr... 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
登链社区是一个 Web3 开发者社区，通过构建高质量技术内容平台和线下空间，助力开发者成为更好的 Web3 Builder。
登链社区网站 : learnblockchain.cn
开发者技能认证 : decert.me
B 站 : space.bilibili.com/581611011
YouTube : www.youtube.com/@upchain
【免责声明】市场有风险，投资需谨慎。本文不构成投资建议，用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资，责任自负。
