跳至正文
Anon Wallet

私密 Paymaster 中继

Anon 使用 Oblivious HTTP（OHTTP）分离钱包网络身份和 paymaster 请求。中继接收浏览器连接但无法解密；paymaster 解密处理请求，但连接来自中继而非浏览器。

隐私目标很明确：任何单一运营方都不应能将用户 IP 与提交给 paymaster 的交易请求关联。 OHTTP 不隐藏最终交易在链上公开的信息。

Wallet                 Independent relay                 Paymaster
  |                           |                              |
  | HPKE-encrypted request    |                              |
  |-------------------------->| opaque request               |
  |                           |----------------------------->|
  |                           |                    decrypt, validate,
  |                           |                    sponsor, and submit
  |                           |<-----------------------------|
  | encrypted response        |                              |
  |<--------------------------|                              |

sees: request + own IP        sees: client IP + ciphertext  sees: request + relay IP

私密请求包含什么

钱包在本地准备操作，包括已签名交易数据、零知识证明、费用报价和费用代币，将其编码为内部请求，用 paymaster 当前的 HPKE 公钥加密。

中继只收到 OHTTP 加密封装，无法读取交易、证明、费用代币、地址或加密响应。Paymaster 持有 HPKE 私钥，能打开封装。对私密 Railgun 操作，证明仍按协议保护屏蔽转账细节；中继增加浏览器连接与提交之间的传输层不可关联性。

请求流程

  1. 钱包预先配置中继 URL 及独立固定的 Ed25519 paymaster 签名密钥。生产值也发布在公知发现文档。
  2. 经中继获取 GET /ohttp-configs，使用固定签名密钥验证 HPKE KeyConfig，防止中继替换成其控制的密钥。
  3. Gas 报价和支持代币等不含身份的公开读取经中继获取，使用允许列表，可按 paymaster 的 Cache-Control 缓存。
  4. 钱包用 HPKE 封装私密执行或状态请求，以 message/ohttp-req 发送到 POST /gateway。
  5. 中继向固定 paymaster 目标转发不透明封装，不从用户输入选目标，也不是开放代理。
  6. Paymaster 解密内部请求，验证证明、签名报价、费用和交易，再将接受的任务提交至链上。
  7. Paymaster 加密响应，中继仅转回 message/ohttp-res，无法读取。

各方能观察什么

参与方 可观察 设计上不可观察
钱包 自己的请求、密钥、响应、网络连接 其他用户活动
中继 客户端 IP、密文大小、时序、允许的公开读取路径和查询 OHTTP 请求或响应明文；paymaster 私钥
Paymaster 解密请求、结果、时序、中继 IP 在中继及入口移除客户端 IP 转发时的客户端 IP
链上观察者 最终交易公开的数据和时间 传输中的 OHTTP 明文

安全保证

  • 中继处的内容机密性。 HPKE 加密每个私密请求和响应；中继无解密或签名密钥。
  • Paymaster 处的网络身份分离。 不转发客户端 IP 头的前提下，连接来自中继而非钱包。
  • 抵御密钥替换。 客户端用在中继渠道之外固定的 Ed25519 密钥验证轮换 HPKE 配置。发现机制不替代固定信任锚。
  • 密文完整性。 认证加密使被修改的密文验证失败。中继仍能丢弃、延迟或重放，因此应用必须安全处理重试。
  • 受限转发。 固定目标、明确的公开读取路径、Go 服务的 1 MiB 请求上限及严格 OHTTP 媒体类型，确保它不是通用代理。
  • 无浏览器凭据。 公开响应用通配符 CORS，不使用 cookie、授权头或浏览器凭据。

限制与假设

中继是分离信任的隐私工具，不是完整匿名网络。

  • 中继和 paymaster 必须由不同且不串通的主体运营；合并观察结果可重新关联 IP 与请求。
  • 全局观察者可按大小和时序关联两端流量，OHTTP 不提供混合网络式抗流量分析。
  • 中继可记录 IP 和流量元数据，请按威胁模型选择独立性及数据政策合适的运营方。
  • 直接调用 paymaster 会暴露网络地址；配置、公开报价、执行和状态请求均需经中继。
  • OHTTP 不隐藏公开链元数据、时间、地址复用或交易本身披露的数值。
  • 不保证可用性；中继可阻断、延迟、限流或选择性拒绝。

使用公共中继

Anon 提供兼容浏览器的 https://relay.anon.inc。当前 URL 和签名密钥可在 https://anon.inc/.well-known/anon-paymaster.json发现。

其他公共中继需满足：

  • 指向您希望使用的 paymaster；
  • 实现相同的 /ohttp-configs、/gateway、gas 报价及支持代币路由；
  • 允许客户端来源或提供兼容 CORS；
  • 独立于 paymaster 运营；
  • 具备可接受的可用性、日志与保留政策。

客户端不能将公共中继指向任意 paymaster。固定目标是防止开放代理的刻意设计；每个目标都需运营方配置并部署兼容实例。

自行运行中继

完整 Go、Docker 和 Cloudflare Worker 实现公开于 github.com/anondotinc/paymaster-relay，含测试、部署配置、健康检查和浏览器预检验证。

Go 与 Docker

Go 服务重新构造上游请求且不转发客户端头，提供最强的客户端 IP 分离，可运行于容器、虚拟机或 Kubernetes：

git clone https://github.com/anondotinc/paymaster-relay.git
cd paymaster-relay
docker build -t anon-ohttp-relay .
docker run --rm -p 8080:8080 \
  -e OHTTP_GATEWAY_URL="https://paymaster.example.com" \
  anon-ohttp-relay

在容器前终止 TLS，仅公开中继路由，设置合理的请求体和速率限制，避免记录请求体。

Cloudflare Worker

使用您控制的 Cloudflare 账户、区域及自定义域名部署。Fork 仓库后编辑 worker/wrangler.toml：

  • 选择唯一的 Worker name；
  • 替换自定义域名 routes[].pattern；
  • 将 TARGET 设为目标 paymaster 的 HTTPS OHTTP 网关。

从仓库根目录部署并验证：

make cloudflare-login
make deploy RELAY_URL=https://relay.example.com

Cloudflare 在部署时管理自定义域名 DNS 与证书。

Cloudflare 客户端 IP 注意事项： 对非 Cloudflare 源站的 Worker 子请求，官方说明 CF-Connecting-IP 包含客户端地址且 Worker 无法修改。Paymaster 入口必须在日志或应用处理前移除访客 IP 头。无法保证时请用 Go 中继。见 Cloudflare HTTP 头参考。

运营检查项

  • 独立于 paymaster 组织运营。
  • 仅指向预期的 HTTPS paymaster 网关。
  • 不转发浏览器 cookie、授权值、用户代理或客户端 IP 头。
  • 禁用请求和响应体日志，尽量缩短元数据保留期。
  • 保持精确的 OHTTP 请求和响应媒体类型。
  • 收紧公开读取允许列表，遵守上游缓存时效。
  • 限流不应创建稳定的逐用户标识。
  • 监控 /health，部署后验证 /gateway 浏览器预检。
  • 公布 URL、运营方身份、日志政策及支持的 paymaster 目标。

参考