AA SDK 是过去式，新范式 capabilities 已来临， 改变 AA 的开发者体验

使用 AA 构建很棒... 或者说真的棒吗？ 虽然 AA 的优势众所周知，但真正尝试使用 AA 构建的人都知道，开发者体验远非最佳。

幸运的是，一个范式转变即将来临，它将永远改变 AA 的开发者体验，使其变得更好。 在这篇博文中，我将解释：

• 目前使用 AA 存在的问题。
• 新范式，也就是“capabilities”，将如何极大地改善开发者体验。
• 作为开发者，你今天可以做些什么来为这种范式转变做好准备。

今天，使用 AA 构建意味着做以下两件事：

• 在你的应用程序中为用户创建一个嵌入式 AA 钱包。
• 通过特定于供应商的 API 与嵌入式 AA 钱包交互。

如果你以前从未用 AA 构建过，这听起来可能很疯狂 —— 事实确实如此。 嵌入式钱包很好，但是你为什么必须使用它们？ 为什么你必须通过特定于供应商的 API 来使用它们？

原因是，直到现在，DApp 无法通过标准化 API 与 AA 钱包进行通信。 相反，如果一个 DApp 想要利用 AA 钱包的功能，例如 gas 赞助，它不能只是使用用户可能带来的任何 AA 钱包。 相反，DApp 必须控制钱包本身 —— 通过将其嵌入到 DApp 中。

更糟糕的是，DApp 也与这些嵌入式 AA 钱包紧密耦合，因为每个 AA 钱包都使用不同的 API。 这种耦合发生在多个层面上：

• 智能账户具有不同的执行接口以及不同的模块接口。7579 和 6900 解决了这个问题 —— 只是它们彼此不兼容。 而且一些智能账户不符合任何一个标准。
• Paymaster 使用不同的 API，因此即使是赞助 gas 这样简单的行为也涉及到使用特定于供应商的 paymaster 接口。
• Bundler 可能是堆栈中最标准化的部分，但即使如此，仍然存在一些常见功能，例如估算 gas 价格，无法通过标准化 API 完成。

结果是，作为 DApp 开发者，今天使用 AA 意味着与堆栈不同层的多个 AA 供应商耦合在一起。试想一下，如果今天的钱包（例如 MetaMask、Rabby 等）使用不同的 API，基础设施提供商（例如 Infura、Alchemy 等）也使用不同的 API，那会是什么样子。你的 DApp 必须致力于使用特定的钱包，比如 MetaMask，以及特定的基础设施提供商，比如 Infura。现在，你的 DApp 无法为使用其他钱包的用户工作，你也无法切换到另一个基础设施提供商。那将是疯狂的 —— 然而，这就是今天 AA 的状态。

有一些解决方案可以解决这个问题。ZeroDev 聚合了多个 bundler/paymaster 提供商，因此当你使用 ZeroDev 时，你可以切换底层提供商而无需更改你的代码。但是，你仍然只能使用我们集成的基础设施提供商。Permissionless 提供了与领先的智能帐户和 bundler/paymaster 的集成，但你同样只能使用 Permissionless 集成的部分。此外，这些解决方案都不能让你的用户_自带_任意 AA 钱包到你的 DApp —— 你仍然必须通过嵌入式钱包使用 AA。

早在 2022 年 (!!) 时，Moody Salem（当时在 Uniswap 工作）提出了一个无害的 ERC，即 ERC-5792。最初的 ERC 与今天的样子几乎无法辨认 —— 它专门用于提供一个交易批处理 API，预计钱包将很快获得批处理来自 4337 和 3074 的交易的能力。然后，该 ERC 停滞不前，因为 4337 没有导致独立的智能钱包激增，并且 3074 已经胎死腹中。

然而，在过去的几个月中，由于许多项目的贡献，特别是 Base 和 WalletConnect，5792 焕发了新的生机。他们决定将 5792 从仅关注批处理扩展到成为通用的“capabilities ERC”。通过 5792，DApp 可以通过一个新的 RPC wallet_getCapabilities 发现连接的钱包的 “capabilities”。然后，DApp 可以通过一个新的 wallet_sendCalls RPC 使用这些 capabilities。

但 capabilities 到底是什么？ 为什么它们现在才成为现实？

简而言之，capabilities 是 DApp 可以通过标准化 API 使用的智能钱包功能。 每个 capability 由一个唯一的 key 标识。 到目前为止，已经提出了以下 capabilities：

• atomicBatch 又名 “transaction batching”，它在 5792 本身 中定义。
• paymasterService 又名 “sponsoring paymasters” (ERC-7677)，它允许 DApp 为用户赞助 gas。
• auxiliaryFunds 又名 “magic spend” (ERC-7682)。 这个 capability 向 DApp 表明，钱包能够从其他来源（如用户的 Coinbase 账户）“just-in-time”地提取资金，因此即使钱包看起来没有足够的余额，DApp 也不应阻止交易，这是 DApp 中的常见做法。
• permissions 又名 “session keys” (ERC-7715)。 此 capability 允许 DApp 向用户请求权限以执行特定交易，即使没有有效的钱包连接（从而实现订阅和自动交易等用例）。

但是，还有许多 AA 功能尚未标准化为 capabilities。 仅查看 ZeroDev 文档，你就可以找到许多示例，例如 delegatecall 和跨链交易。 在接下来的几个月中，我们预计会有更多 capabilities 实现标准化。

请注意，并非所有智能钱包功能都是 capabilities，因为它们可能不是 DApp 可以使用的功能。 例如，如果智能钱包使用 passkeys 进行交易签名，那么这实际上并不是此上下文中的“capability”，因为 DApp 不关心也不应该关心其用户如何使用钱包签署交易。 多重签名也属于这一类。

因此，capabilities 只是智能钱包功能的一个子集 —— _DApp 可以使用_的钱包功能。

那么 DApp 究竟如何使用 capabilities 呢？ 幸运的是，这只是一个两步过程：

• 步骤 1：使用 wallet_getCapabilities 发现连接的钱包支持的 capabilities。

例如，钱包可能会返回这样的响应：

Copy{
  "0x1": {
    "atomicBatch": {
        "supported": true
    }
  },
  "0x2105": {
    "atomicBatch": {
      "supported": true
    }
    "paymasterService": {
      "supported": true
    }
  }
}

从本质上讲，钱包返回它在每个链上支持的 capabilities。 在此示例中，钱包支持以太坊 ( 0x1) 上的 atomicBatchcapability，以及 Base ( 0x2105) 上的 atomicBatch 和 paymasterService。

• 步骤 2：使用 wallet_sendCalls 发送交易，同时指示要使用的 capabilities。

例如，假设你想使用 session key 发送一批交易，同时为你的用户赞助 gas。 你可以将 paymasterService 和 permissions capabilities 都包含在请求的 capabilities 字段中。 atomicBatch capability 隐含在 wallet_sendCalls 中。 这是一个示例请求：

Copyprovider.request({
  method: 'wallet_sendCalls',
  params: [{\
    version: '1.0',\
    chainId: '0x01',\
    from: '0xd46e8dd67c5d32be8058bb8eb970870f07244567',\
    calls: [\
      {\
        to: '0xd46e8dd67c5d32be8058bb8eb970870f07244567',\
        value: '0x9184e72a',\
        data: '0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675'\
      },\
      {\
        to: '0xd46e8dd67c5d32be8058bb8eb970870f07244567',\
        value: '0x182183',\
        data: '0xfbadbaf01'\
      }\
    ],\
    capabilities: {\
      paymasterService: {\
        url: "<paymaster_url>",\
      },\
      permissions: {\
        context: "<session_id>",\
      },\
    }\
  }]
})

有了 capabilities，DApp 不再需要与特定的 AA 钱包或基础设施紧密耦合。 相反，他们可以通过标准化 API 利用 AA 钱包功能。 这样，无论用户是使用嵌入式 AA 钱包还是将自己的钱包带到 DApp，DApp 都会通过完全相同的 API 与钱包通信，从而在与所有 AA 钱包兼容的同时保持单一代码路径。

capabilities 范式尤为重要，因为随着即将到来的 Pectra 升级，由于 EIP-7702（EIP-3074 的继任者），EOA 钱包将获得智能钱包功能，因此用户携带支持 capabilities 的钱包将越来越普遍。 可以利用 capabilities 的 DApp 将比不能利用 capabilities 的 DApp 具有显着优势 —— 最大的赢家将是享受改进的 UX 的用户。

ERC-4337 发布已经一年多了，你可能想知道为什么 capabilities 现在才成为现实。 在我看来，这归结为几个因素：

• AA 构建者需要时间来了解最重要的“AA 功能”到底是什么。 虽然从理论上讲，由于智能账户的可编程性，可能的模块数量不受限制，但在实践中，大多数 AA 用例都由三个功能主导：gas 赞助、交易批处理和权限（session keys）。 因此，有了这种理解，现在可以为这些最受欢迎的功能创建标准。
• Coinbase 和 WalletConnect 是这种新范式背后的两个主要驱动力，它们在该领域拥有足够的权重，可以打破每个人都为自己的生态系统构建的局部最大值。 虽然我们还致力于许多互操作性标准，特别是针对模块化账户和权限，但我们不一定能够让所有 AA 公司都像 Coinbase 和 WalletConnect 那样保持一致。 向他们致敬。

在 ZeroDev，我们始终坚持对整个领域有益的东西，而不是对我们自己有益的东西。 这就是为什么当我们本来可以反其道而行之并使用 Kernel（使用最广泛的智能账户）来锁定我们的用户时，我们创建了 模块化账户标准。 这也是为什么当我们拥有 最强大的 session keys 实现时，我们标准化了权限。 你可以称我们天真，但我们坚信，如果我们继续做对整个领域有益的事情，商业方面的事情就会迎刃而解。 到目前为止，事实证明确实如此 —— ZeroDev 现在是市场上使用最广泛、最受信任的 AA 解决方案之一。

所以，我们再次发现自己为了互操作性而拆除我们已经建立的护城河。 但我们这样做是因为我们相信只有糟糕的产品才需要锁定人们 —— 好的产品将通过为用户提供最大的价值而获胜，而这正是我们将继续通过 capabilities 做的事情。

截至今天，ZeroDev 已完全更新了 capabilities API。 这意味着两件事：

• 如果你正在使用 ZeroDev 构建钱包，你的钱包可以通过我们的 EIP-1193 提供商或我们的 WalletConnect 集成提供 capability API。 在这两种情况下，DApp 都可以通过 capabilities API 与你的钱包通信。
• 如果你正在构建 DApp 并使用 ZeroDev 作为嵌入式钱包，你现在可以使用 Viem 和 Wagmi 通过 capabilities API 与 ZeroDev 交互。 通过使用 capabilities API，你可以确保你的 DApp 将与你的用户可能携带的任何智能钱包一起使用，而不仅仅是嵌入式 ZeroDev 钱包。

要了解有关 ZeroDev 的 capabilities 支持的更多信息，请阅读此文档。

如今，DApp 通过特定于供应商的 SDK 与智能钱包通信，但这将成为过去。 借助 capabilities API，DApp 现在可以利用智能钱包功能，而无需与任何特定的智能钱包或 AA 基础设施提供商锁定。 这对开发者和用户来说都是一个胜利，并且将为智能钱包的广泛采用带来奇迹。

通过与 capabilities API 集成，DApp 不仅可以改善当今智能钱包用户的 UX，还可以为未来做好准备，在未来，由于 ERC-4337，将会有越来越多的智能钱包，甚至由于 EIP-7702，EOA 钱包也将变得智能。 capabilities 现在在 Viem 和 Wagmi 中得到支持这一事实使得与它们集成变得轻而易举。

如果你想立即开始使用 capabilities，请尝试将 ZeroDev 与 Wagmi 一起使用！

如果你喜欢这篇博文，你可以在这里放大它。

• 原文链接： docs.zerodev.app/blog/he...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～