在第一部分 中，我们探讨了 EIP-7702 的采用将如何展开。
在第二部分中，我想重点介绍 EIP-7702 将如何影响 DApp，以及作为 DApp 开发者可以做些什么来利用 EIP-7702。
EIP-7702 的快速概述
首先，快速回顾一下。EIP-7702 是计划在以太坊下一个升级（Pectra）中上线的 EIP 之一，预计在 2025 年 4 月发布。
通过 EIP-7702，一个普通帐户（EOA）可以将自身“升级”为智能帐户，同时仍然保持 EOA 的身份并保留相同的地址。
一旦帐户被升级，用户就可以体验大多数 AA 的好处，例如 gas 赞助、交易批处理、Passkey等。
两种类型的 DApps
为了本文的目的，我们将区分两种类型的 dapps，我称之为“开放 dapps”和“封闭 dapps”。
-
开放 dapps 是用户自带钱包的 dapps。这是我们最习惯的 dapps 类型。示例包括 Uniswap、AAVE 等。
-
封闭 dapps 是主要（或完全）通过内嵌钱包工作的 dapps。从某种意义上说，封闭 dapp 是具有 DApp 特定 UI 的钱包，但我称之为 dapps，以将其与一般目的的钱包如 MetaMask 区分开来。ZeroDev 客户的示例包括
Infinex , DeFi.App , 和 Dimo .
EIP-7702 对于开放 DApps
最近，MetaMask 公开承诺 支持 EIP-7702 ，因此可以合理预期，其他主要钱包也会很快跟上。因此，开放 dapps 的开发者必须适应一个新现实：用户连接到你的 dapp 的钱包可能是一个智能钱包，且越来越可能如此。
这引出了两个问题：
-
你如何知道连接的钱包是否是智能钱包？
-
如果用户连接了智能钱包，你该怎么做？
检测智能钱包
检测智能钱包很简单 — ERC-5792
定义了一个标准的 RPC wallet_getCapabilities，用于返回钱包支持的“功能”列表。比如，一个钱包可能会以以下方式响应：
{
"0x0": {
"permissions": {
"supported": true
}
},
"0x2105": {
"paymasterService": {
"supported": true
},
},
}
这里，特殊值 0x0 表示钱包在所有网络上支持“permissions”（交易委托）功能，而它仅在链 ID 0x2105（Base）上支持“paymasterService”（gas 赞助）。
因此，如果你的 DApp 打算使用智能钱包功能，应该在钱包连接后调用 wallet_getCapabilities（或使用
ERC-7846
来批量处理钱包连接与功能发现），以便了解连接钱包支持哪些功能。
幸运的是，Viem和 Wagmi 已经支持 wallet_getCapabilities，因此你仅需一个函数/钩子即可使用此 RPC。
使用智能钱包
一旦你发现智能钱包的功能，就需要决定是否使用这些功能。
通常，你应该决定某项功能是否对你的 dapp 是必需的或可选的。
-
必需意味着你的 dapp 无法在没有该功能的情况下运行。例如，如果你正在构建一个为用户自动交易的 AI 代理，你可能会要求用户的钱包支持“permissions”功能，这允许用户将交易委托给 AI 代理执行。没有这个功能，你的 dapp 将无法按预期工作，因此如果连接的钱包不支持 permissions，你的 dapp 将简单地拒绝工作。
-
可选意味着你的 dapp 可以在没有该功能的情况下运行。例如，如果你正在构建一个 Web3 游戏，你可能会决定希望为支持 gas 赞助的用户的钱包赞助费用（“paymasterService”功能）。但是，如果用户的钱包不支持 gas 赞助，他们将按常规支付自己的 gas 费用。
你是否希望要求某项功能，或将其保持为可选，最终是一个产品决策。该功能对你的应用体验是否至关重要？你是否有足够的工程能力来构建备选方案，以防该功能不被支持？这些都是决定你如何处理功能（或缺乏功能）的问题。
如何使用功能
由于智能帐户是智能合约，它们在理论上是无限灵活的，可以支持无限数量的功能。在实践中，功能遵循 80-20 法则，少数功能能够满足大多数使用案例。在 ZeroDev 的经验中，最有用的功能是：
-
交易批处理
-
gas 赞助
-
permissions（有时称为“会话密钥”）
-
链抽象
对于每一个功能，DApp 开发者会有或将会有一个标准钱包接口可供使用。
目前，交易批处理的接口已经通过 ERC-5792 标准化。
对于 gas 赞助，ERC-7677 定义了使用 ERC-4337 支付者的接口，虽然还有其他不依赖于 ERC-4337 的赞助 gas 的方法。
对于 permissions，标准化要困难得多，因为有许多可能的方法，包括会话密钥、会话帐户（ERC-7710 ）和子帐户（ERC-7895）。统一这些方法的一次尝试是ERC-7715 但这仍在进行中。
“链抽象”是一个快速发展的领域，具有更多竞争的方法，但好消息是，这不需要任何复杂的钱包接口，从而简化了标准化。目前至少有两个 ERC（ERC-7682和 ERC-7811 ）解决链抽象，但它们仍处于早期采用阶段。
我需要了解 100 种不同的 ERC 才能使用 EIP-7702 吗？
如果你读到这里，可能会想——我真希望不用学习 100 种不同的 ERC 就能使用 EIP-7702！
那么，好的消息和坏消息。坏消息是，确实会有一堆不同的 ERC 指定智能钱包的不同功能。好消息是，借助合适的工具，你无需了解这些 ERC 中的大多数 — 库会为你处理这些。
你猜对了 — ZeroDev
就是这样的库！我们努力保持在智能钱包标准化的前沿，以便你不必这样做。
现在让我们转向“封闭 dapps”，其中的故事要简单得多。
EIP-7702 对于封闭 DApps
“封闭 dapp”是主要或完全通过内嵌钱包工作的 dapp。如今，大多数 AA 应用都是封闭 dapps，因为目前唯一支持智能帐户的钱包是内嵌钱包。如上所述，一旦现有的独立钱包采用 EIP-7702 成为智能钱包，这种状况将会改变。
EIP-7702 对封闭 dapps 的影响相对简单，因为 dapp 无需处理具有不同功能的众多钱包。相反，dapp 是针对一个单一钱包——内嵌钱包进行编程，并完全控制该钱包提供的功能。
因此，封闭 dapp 要做的唯一决定是：内嵌钱包应该使用常规智能帐户，还是 EIP-7702 帐户（智能 EOA）？
智能 EOA 与常规智能帐户
常规智能帐户——即仅是智能合约且不是 EOA 的智能帐户——相较于智能 EOA 具有若干优势：
另一方面，智能 EOA 也具有若干优势：
-
不依赖于智能帐户基础设施：由于 EIP-7702 帐户也是 EOA，它可以在不依赖任何“智能帐户基础设施”（如 ERC-4337 捆绑器）的情况下发送交易。如果你希望帐户能够在仅支持常规节点 RPC 而不支持捆绑器 RPC 的新网络上工作，这一点尤其重要。
-
与任何智能帐户实现无锁定。常规智能帐户通常通过 CREATE2 通过特定合约工厂部署。因此，尽管该帐户后来可能更新为使用另一种实现，它将在新网络上始终与原始实现一起部署。密钥存储将解决此问题，但尚未准备好投产。另一方面，智能 EOA 的地址完全基于其私钥派生，地址不绑定于任何特定的智能帐户实现。相反，你可以轻松地将智能 EOA 重新委托给不同的智能帐户实现。
-
与 EOA 钱包的互操作性：由于智能 EOA 仅是 EOA，用户可以通过导入私钥将其导入任何 EOA 钱包。相反，常规智能帐户无法轻松导入现有钱包。
综上所述，常规智能帐户和智能 EOA（EIP-7702 帐户）各有其优势。要在二者之间选择，请遵循以下一般指南：
-
如果你希望基于常规智能帐户构建，通常情况如下： - 你希望完全基于Passkey构建，因为 1）希望用户无需管理种子短语，或 2）不想支付给第三方 MPC 系统以为用户管理 EOA 密钥。 - 你希望用户能够撤销/轮换所有密钥。
-
如果你希望基于 EIP-7702 帐户构建，通常情况如下： - 你不希望与任何特定的智能帐户实现绑定。 - 你希望你的 DApp 在可能没有智能帐户基础设施的新网络上工作（例如，捆绑器）。 - 你希望用户在不使用任何智能帐户功能（批处理、赞助、权限等）的情况下发送大量常规交易。 - 你希望用户能够将其帐户导入到其他钱包。
结论
EIP-7702 为 DApp 开发者构建以前无法实现的 Web3 体验提供了巨大潜力。然而，这也带来了独特的挑战，特别是功能碎片化——许多功能尚未得到充分标准化，因此 DApps 可能必须为不同的智能钱包编写不同代码。
然而，借助合适的工具，作为 DApp 开发者，构建基于 EIP-7702 的应用并不会那么困难。
-
ZeroDev
正在与所有领先的内嵌钱包提供商（例如 Privy/Dynamic/Turnkey）合作，以便你可以通过几行代码将你的内嵌钱包转化为 EIP-7702 智能 EOA。
-
使用 ZeroDev SDK，你可以轻松构建任何功能，从基本的交易批处理和 gas 赞助到高级的权限和链抽象。ZeroDev SDK 将始终与最新标准兼容，因此你可以放心，你今天编写的代码在未来随着越来越多的钱包变为智能钱包时仍将正常工作。
如果你准备开始尝试 EIP-7702，请立即查看
此教程!
