钱包隐私 Paymaster 能力草案 - ERCs

ERC PR : TODO

DEMO : Link

摘要

借助 EIP-5792，应用可以通过 capabilities 向 wallet 传达高级执行偏好。该提案引入了 privacyPaymaster capability，使应用能够请求兼容的 wallet 使用由用户控制、保护隐私的 paymaster 来资助 gas。

dapp 表达意图；wallet 负责执行隐私保护。

所有 gas 支付逻辑——包括 paymaster 选择、gas 支付准备和 gas 支付授权——都在 wallet 内部完成，不会向应用暴露用户身份、内部状态或 paymaster 细节。

动机

如今，gas 支付是一种隐式的身份泄露。

即使用户在价值转移中使用了保护隐私的机制，支付 gas 的地址仍然会公开可见，并且可在多次交互之间被关联。这形成了一层持久的身份层，而现有隐私工具并不能完全解决这一问题。

现有解决方案如 paymasterService（ERC-7677）依赖于应用指定的外部服务。这些方案引入了可信第三方，使其能够关联活动，并造成审查和可用性依赖，以及泄露用户意图和元数据。

当前在 wallet 中配置了保护隐私的 paymaster 的用户，没有标准化的方式向应用表明这一能力，确保 wallet 自动使用保护隐私的 gas 支付，或防止回退到与身份关联的 gas。

该提案定义了一种恢复用户控制权的 capability。wallet 决定如何支付 gas。dapp 只声明意图。正确性不需要外部服务。不会暴露用户状态。与由 dapp 选择 gas sponsor 的 paymasterService 不同，privacyPaymaster 确保用户——通过自己的 wallet——是决定 gas 如何被资助的唯一权威。

规范

术语“必须（MUST）”、“不得（MUST NOT）”、“应该（SHOULD）”和“可以（MAY）”应按 RFC 2119 中的描述理解。

概述

privacyPaymaster capability 完全由 wallet 实现。wallet 维护一个或多个由用户配置的 privacy paymaster provider。底层机制——无论是零知识证明、stealth funding，还是其他任何构造——都属于实现细节，不会暴露给应用。

当 wallet_sendCalls 请求包含 privacyPaymaster capability 时，wallet：

1. 验证 capability 对象。
2. 从内部配置中选择合适的 provider。
3. 在内部估算 gas。
4. 组装所有字段都已确定的最终交易。
5. 完全在客户端使用所选 provider 准备 gas 支付。
6. 将生成的 gas 支付授权纳入交易。
7. 向用户展示最终交易以供批准。
8. 提交执行。

实现者注意： 本规范与底层 AA 执行模型无关。以下说明上述抽象术语如何映射到具体模型：

• ERC-4337: 交易对象是 UserOperation，gas 支付授权是 paymasterAndData，提交到 bundler。
• EIP-7702: 交易对象是 type 0x04 的 set-code 交易。当与 ERC-4337 基础设施一起使用时，适用 paymasterAndData 模型。否则，gas 支付授权由委托合约的 paymaster module 处理，提交到标准 mempool。
• EIP-8141 (Draft — targeted for Hegotá): 交易对象是 Frame Transaction（type 0x06）。gas 支付授权在 VERIFY frame 的 APPROVE 调用中表达。直接提交到 mempool，不经过 bundler。

wallet MUST 应用与其执行模型相适应的构造。无论使用哪种模型，上述规范性要求都适用。

应用不参与 provider 选择、gas 估算、gas 支付准备或 paymaster 配置。

Capability 响应

wallet 通过 wallet_getCapabilities 在每条配置了 privacy paymaster 的链上表明支持。

{
  "0x2105": {
    "privacyPaymaster": {
      "supported": true
    }
  },
  "0xa": {
    "privacyPaymaster": {
      "supported": true
    }
  }
}

响应中缺失的链，或存在但 "supported": false 的链，表示该链未配置 privacy paymaster。

capability 响应 MUST NOT 包含 provider 配置、余额或任何内部用户状态。

Capability 请求

应用在 wallet_sendCalls 中包含 privacyPaymaster capability，以请求保护隐私的 gas 支付。

{
  "version": "2.0.0",
  "chainId": "0x2105",
  "calls": [\
    {\
      "to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567",\
      "data": "0xd09de08a"\
    }\
  ],
  "capabilities": {
    "privacyPaymaster": {
      "optional": false
    }
  }
}

optional 字段 MUST 明确设置为 true 或 false。空的 capability 对象（即缺少 optional 字段）无效，wallet MUST 以错误码 5700 拒绝，这与 EIP-5792 的错误处理一致。

最佳努力示例：wallet 在可用时使用 privacy paymaster，否则正常继续：

{
  "version": "2.0.0",
  "chainId": "0x2105",
  "calls": [\
    {\
      "to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567",\
      "data": "0xd09de08a"\
    }\
  ],
  "capabilities": {
    "privacyPaymaster": {
      "optional": true
    }
  }
}

无效示例：wallet MUST 以错误 5700 拒绝：

{
  "version": "2.0.0",
  "chainId": "0x2105",
  "calls": [\
    {\
      "to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567",\
      "data": "0xd09de08a"\
    }\
  ],
  "capabilities": {
    "privacyPaymaster": {}
  }
}

当 optional 为 false 时：

• wallet MUST 使用 privacy paymaster 支付 gas。
• 如果该 capability 无法满足（没有配置的 provider、余额不足、准备失败），wallet MUST 拒绝该请求。
• wallet MUST NOT 静默回退到其他 gas 支付方式。

当 optional 为 true 时：

• 如果配置了 privacy paymaster 且可以满足，wallet SHOULD 使用它。

• 如果该 capability 无法满足，wallet MAY 按默认 gas 支付行为继续。

• • *

Wallet 要求

支持 privacyPaymaster capability 的 wallet：

1. MUST 在每条配置了 privacy paymaster 的链上通过 wallet_getCapabilities 表明支持。

2. MUST 在内部维护用户配置的 provider。provider 选择、合约地址和实现细节 MUST NOT 向应用暴露。

3. MUST NOT 在任何 capability 字段或响应中向应用暴露 provider 配置、余额或任何内部用户状态。

4. MUST 确保 gas 支付准备不会泄露用户身份、交易意图，或 gas 资助与使用之间的关联。

5. MUST 在提交前向用户展示最终交易以供批准。

6. MUST 以错误码 5700 拒绝 privacyPaymaster capability 对象为空的 wallet_sendCalls 请求。

7. 如果 optional 为 false 且该 capability 无法满足，MUST 拒绝 wallet_sendCalls 请求。

8. 如果 optional 为 false，MUST NOT 静默回退到其他 gas 支付方式。

9. 当 privacyPaymaster 可以满足时，MUST 在同一请求中优先于任何 paymasterService capability。

10. MUST 确保 gas 支付授权不能在交易之间重用，并防止 replay 攻击。

11. SHOULD 在配置了多个 provider 时，允许用户在 wallet 设置中指定默认 provider。

理由

职责分离

dapp 声明意图。wallet 执行交易。provider 实现机制。这种分层最小化了信任假设，并在每一层都防止身份泄露。这与 EIP-5792 中 wallet_ 命名空间 RPC 背后的原则相同——将执行权威推入 wallet，而不是应用。

为什么要新建 capability，而不是扩展 paymasterService

paymasterService capability（ERC-7677）本质上由 server 驱动：dapp 提供一个 URL，wallet 向外部服务发起 RPC 调用。privacyPaymaster capability 则完全颠倒了这一点——wallet 是唯一的参与者。没有 URL，没有外部 RPC，也不需要 server 参与即可保证正确性。这些是在架构上不兼容的模型，因此需要单独的 capability key。

为什么 dapp 不指定 provider 细节

暴露 provider 配置会使 dapp 侧指纹识别成为可能，泄露实现细节，并增加攻击面。所有这类数据都保留在 wallet 内部。dapp 的唯一角色是声明意图：强制或可选地请求保护隐私的 gas 支付。

为什么空 capability 对象无效

与需要 url 字段的 paymasterService 不同，privacyPaymaster 不要求 dapp 提供任何配置。然而，optional 决定了根本不同的 wallet 行为——强制拒绝或优雅回退。允许空对象会使 dapp 意图变得模糊，并带来静默、未被发现的隐私失败风险。要求显式设置 optional 能确保 dapp 对其隐私需求有明确意图，这与 EIP-5792 capability 设计的精神一致。

为什么内部用户状态被排除在 capability 字段之外

诸如余额或消费历史之类的 wallet 内部状态不得暴露给 dapp。暴露这些信息会使 dapp 能够对用户进行指纹识别、跟踪活动，并可能将链上事件与特定用户关联起来——这直接破坏了该 capability 旨在提供的隐私保证。

为什么 optional: false 强制拒绝而不是静默回退

从隐私 gas 静默回退到与身份关联的 gas，是一种用户无法察觉的隐私失败模式。当 optional 为 false 时显式拒绝，可确保用户和应用能清晰、可审计地知道隐私保证是否得到满足。

为什么 privacyPaymaster 优先于 paymasterService

如果在同一个 wallet_sendCalls 请求中同时存在两种 capability，privacyPaymaster 反映了用户对保护隐私的 gas 的明确配置。允许 paymasterService 覆盖它将违背用户意图，并重新引入用户原本希望避免的身份关联。

安全考虑

客户端准备完整性

所有 gas 支付准备 MUST 在 wallet 隔离的执行上下文中本地完成。provider 特定的 secret material MUST NOT 被 content scripts、注入的页面脚本或 dapp 控制的执行上下文访问。

防止静默回退

当 optional 为 false 时，wallet MUST NOT 静默降级为与身份关联的 gas 支付。gas 支付准备阶段的任何失败 MUST 作为明确错误暴露给 dapp 和用户。

提交层考虑

提交层在交易被纳入之前会观察交易，并可能尝试对其进行关联。wallet SHOULD 考虑提交端点的信任模型，以及该层进行时间或元数据关联的可能性。

Replay 和双花防护

wallet 和 paymaster provider MUST 确保 gas 支付授权不能在交易之间重用，并防止 replay 攻击。

paymasterService 冲突

dapp 可能在同一请求中同时包含 paymasterService 和 privacyPaymaster。当 privacyPaymaster 已配置且可满足时，wallet MUST 优先使用它，并在这种情况下完全忽略 paymasterService 字段。

非目标

本提案不：

• 标准化 provider 使用的隐私机制。

• 定义 paymaster 合约接口或链上协议要求。

• 保证特定的匿名集大小或隐私级别。

• 规定提交层行为或提交层隐私属性。

• 替代或修改用于应用赞助 gas 用例的 paymasterService（ERC-7677）。

• • *

向后兼容性

该 ERC 引入了新的 capability key privacyPaymaster。未实现该 capability 的 wallet 不会在 wallet_getCapabilities 响应中包含它。应用在 wallet_sendCalls 请求中包含 privacyPaymaster 之前 SHOULD 检查 capability 支持，或者 SHOULD 将其标记为 optional: true，以便在不支持的 wallet 上优雅降级。

如果应用在不支持该 capability 的 wallet 上以 optional: false 包含 privacyPaymaster，将收到标准的 EIP-5792 不支持 capability 错误（5700），这与现有的 EIP-5792 错误处理一致。

wallet_getCallsStatus 响应不受该 capability 影响。dapp 使用标准的 EIP-5792 wallet_getCallsStatus 流程跟踪交易状态。gas 是通过 privacy paymaster 还是其他机制支付的，不会反映在状态响应中，这与 gas 支付细节属于 wallet 内部信息的原则一致。

版权

版权及相关权利通过 CC0 放弃。

• 原文链接： ethereum-magicians.org/t...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～