EIP-7702 全面指南

EIP-7702解决了什么问题？

任何构建过dApp的人都知道，区块链用户体验存在显著的摩擦。用户必须为简单操作签署多个交易，必须仅使用原生代币支付手续费，并且管理完全访问其账户的私钥。这些限制源于外部拥有账户（EOAs）的基本结构——以太坊上的标准用户账户。

EIP-7702旨在通过允许EOAs将其执行委托给智能合约来解决这些用户体验问题，有效地赋予它们可编程能力，而无需用户迁移到全新的钱包。

为什么用户不想迁移到智能账户

虽然智能账户提供了更优越的功能，但让用户从现有的EOAs迁移到智能账户面临几个重要原因的挑战：

入门摩擦

智能账户要求用户：

• 部署一个新合约（需要支付手续费）
• 将资金存入这个新账户
• 学习新的接口和工作流程
• 支付部署手续费（对于新用户来说是一个恶性循环）

账户历史和身份的丧失

当用户迁移到智能账户时：

• 他们会获得一个全新的区块链地址
• 他们的EOA的交易历史不会被转移
• 他们的链上声誉和身份变得支离破碎
• NFT、POAPs和其他数字收藏品留在旧地址
• 他们失去了与识别其先前地址的dApp的连接

有限的可移植性

EOAs在钱包之间具有通用的可移植性：

• 任何钱包软件都可以使用私钥或助记词导入EOA
• 相同的地址在所有钱包界面中均可正常工作

智能账户具有有限的可移植性：

• 不同的钱包支持不同的智能账户实现
• 在钱包提供商之间搬迁可能很困难或不可能
• 每个智能账户实现具有不同的功能和限制
• 跨钱包兼容性没有保证

这些迁移障碍解释了尽管智能账户的好处，大多数用户仍然继续使用EOAs。EIP-7702试图通过在现有EOAs上引入智能账户功能，来缩小这一差距，而无需用户更改地址或迁移资金。

当前以太坊账户的情况

在深入EIP-7702之前，让我们回顾一下当前的以太坊账户类型：

1. 外部拥有账户（EOAs）：这些是由私钥控制的传统用户账户。当你创建MetaMask钱包时，你在创建一个EOA。 这些账户：
   • 可以发起交易
   • 不能包含代码
   • 完全由私钥控制
   • 必须使用原生ETH支付手续费
2. 合约账户：这些是你部署的智能合约。它们：
   • 包含并执行代码
   • 由其代码逻辑控制
   • 无法发起交易（只能响应交易）
   • 不能直接支付手续费（由调用者支付）
3. 智能账户：这些是被设计为用户账户的智能合约。它们提供许多可编程特性：该领域有几个标准（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可以说：“当我接收到交易时，请运行这个智能合约代码。”

工作原理：

1. 用户从他们的EOA签署一条特殊的授权消息
2. 该授权包含在交易中
3. 在处理时，以太坊网络记录该EOA应委托给特定的智能合约
4. 对该EOA的未来交易将执行智能合约的代码
5. 重要的是，这些交易中的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有一些关键限制，使其不同于完全的智能账户：

1. EOA的私钥依然至高无上的权能：私钥始终可以通过签署新交易来覆盖任何授权。这意味着无法实现真正的多重签名或时间锁功能。
2. 没有部署的持久性：与拥有自己地址的已部署智能合约账户不同，EIP-7702的委托可以被覆盖。这意味着EOA仍然在本质上是一个具有智能功能的EOA，而不是一个真正的智能账户。
3. 多链问题：默认情况下，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，应用程序可以用它向钱包请求权限。

流程如下：

1. 一个钱包使用EIP-7702将用户的EOA委托给支持EIP-7710的智能合约
2. 应用程序通过EIP-7715请求从用户账户支出的权限
3. 钱包向用户显示该请求
4. 如果批准，应用程序现在可以通过代理执行操作

应用程序可以选择：

• 请求其合约与用户账户交互的直接权限，或者
• 部署自己的智能账户（称为“伴随账户”）与用户账户交互

ERC-5792方法

此方法利用ERC-5792中定义的wallet_sendCalls JSON-RPC方法：

1. 应用程序使用wallet_sendCalls将多个函数调用发送到钱包
2. 钱包决定如何将这些调用打包为一个序列
3. 钱包可以在后台使用EIP-7702将其作为批处理执行
4. 用户仅需对整个序列签名一次

该方法对于单链上简单的批处理场景特别有用，例如将代币批准和兑换操作结合起来。钱包处理所有打包交易的复杂性，应用程序不需要知道钱包如何实现此功能。

ERC-5792仅用于批量执行。对于复杂于此的任何操作，你需要使用ERC-7710/ERC-7715。

伴随账户方法

Biconomy的解决方案利用他们所称的“伴随账户”——特定应用的智能账户，充当中介。流程如下：

1. 应用程序为自身使用部署一个伴随智能账户
2. 用户授予该伴随账户权限（如果钱包支持的话，通过EIP-7710/7715）
3. 伴随账户然后处理复杂的操作，如批处理、费用赞助等。

这种方法允许每个应用程序实现所需的确切智能账户功能。例如：

• DeFi应用可能会部署一个具有批量交易功能的伴随账户
• 游戏应用可能会部署一个具有免手续费交易的账户
• 跨链应用可能会部署一个具有多链执行能力的账户

融合执行（Biconomy的回退机制）

鉴于并非所有钱包最初都会支持EIP-7710/7715，Biconomy创建了一种称为“融合执行”的回退机制，可以与任何钱包一起使用：

1. 该方法重新利用常规EVM交易或ERC-20允许功能中的字段
2. 用户似乎向伴随账户进行常规转账
3. 隐藏在该交易中的额外信息（压缩成一个哈希）
4. 交易被发送到：
   • 常规以太坊RPC（用于转账）
   • 一个处理其他指令的专门节点

这使得即使在不支持较新标准的钱包中，也能实现复杂操作。

使用EIP-7702实现廉价智能账户部署

EIP-7702的一个经常被忽视的特性是，它使开发者能够以比以前便宜高达80%的成本为用户部署新的智能账户。它通过利用EIP-7702代理只需12500 gas的事实来实现。通过使用一些巧妙的密码学技巧——例如Nick的方法和签名打包——开发者可以仅通过EIP-7702部署完全功能的智能账户（支持资源锁定、时间锁和多重签名）。

这种方法的部署成本节省使伴随账户在以太坊主网上的使用成为可行（伴随账户的部署成本在$0.2 - $0.5范围内），并在rollups上基本免费。此外，对以智能账户为优先的（无EOA）钱包来说，使得新用户的上手成本同样可负担。

在我们的详细指南中了解更多。

这对开发者意味着什么

如果你是应用程序开发者，这里有你需要知道的：

1. 你不能直接使用EIP-7702：钱包控制授权，而不是应用程序
2. 关注钱包实现：主要钱包将以不同方式实现EIP-7702，你需要适应每一种
3. 考虑伴随账户：如果你需要特定的智能账户功能，开发伴随账户方法可能是最灵活的解决方案
4. 为分化做好准备：并非所有链都会同时实现EIP-7702，且并非所有钱包将以相同方式支持它
5. 看超出基本用例的情况：尽管批量和费用赞助是初始重点，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 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～