Ethereum zkAPI 上线：AI 调用可以付费，却不暴露付款身份吗？
Ethereum Foundation 与 Open Anonymity 推出的 zkAPI 已在主网上运行，通过预付费金库、零知识证明和短期 API Key，把调用内容与付款身份分开。本文解释其机制、适用场景及尚未解决的隐私边界。
Jacky Wang
6 分钟阅读
今天使用任何主流 AI API，支付账户通常就是身份锚点：API Key 连接到账户，账户连接到付款方式，而同一个账户发出的提示词、模型选择和使用时间可以长期汇聚成一份行为档案。
10 月 1 日，Ethereum Foundation 介绍了由 Open Anonymity Project 合作实现的 zkAPI。它试图解决一个长期存在但经常被忽略的问题：能否让用户证明“我有钱支付这次 API 调用”，却不告诉服务方“我是谁、哪笔充值属于我，以及不同会话是否来自同一个人”？
官方称该系统已经运行在 Ethereum 主网。它不是让模型看不到提示词的“全链隐私 AI”，而是一个更具体的基础设施：把 API 使用权、付款身份与请求内容拆成不同的数据域。
zkAPI 解决的到底是什么问题？
传统 API 计费依赖账户。用户注册邮箱、绑定信用卡或充值余额，再通过长期 API Key 发起请求。这种模式简单有效，但供应商能够把请求与同一个身份持续关联。
逐次链上支付也不是理想替代方案。每次 API 调用都发交易，会带来延迟、Gas 成本和公开的交易图谱。对于聊天、RPC、图片生成等高频服务，这种粒度几乎不可用。
zkAPI 采用“充值一次、私密消费多次”的思路。用户先把 USDC 等资产存入 Ethereum 金库，随后在本机生成零知识证明，证明某个私密余额足以覆盖一次调用或一个会话，而不公开具体是哪笔充值。
这个设计最早由 Davide Crapis 与 Vitalik Buterin 在 Ethereum Research 的 ZK API Usage Credits 提案 中讨论，当前实现则把协议、客户端、服务端和合约组成了一套可运行系统。
一次私密 API 会话如何完成？
按照 Ethereum Foundation 公布的运行模式，一次调用大致分为四步。
1. 用户先向链上金库存入余额
充值是一笔普通 Ethereum 交易。金库记录的是承诺值，用户本地持有可消费的私密 note。区块链能够看到有人存入资金，但不直接知道后来哪次 API 请求消费了这笔钱。
2. 本地客户端生成支付证明
应用继续使用 OpenAI 或 Ollama 兼容接口，只是把请求指向本机客户端。客户端生成 Groth16 零知识证明，证明余额有效且尚未被重复消费。
3. 服务端签发短期、限额的 API Key
zkAPI 服务端验证证明后，临时生成一个带美元上限的运行时 Key。Key 只保存在用户设备内存中。用户的提示词随后直接发给模型提供商，而不是经过负责验证付款的 zkAPI 服务端。
4. 会话结束后按实际用量结算
模型提供侧记录 Key 的累计用量并生成签名收据，系统从私密余额中扣除实际花费。一个证明可以覆盖一个会话，避免每个请求都生成证明或进行链上结算。
Merkle Tree 与 nullifier 各自做什么？
zkAPI 把有效余额承诺组织在 Merkle Tree 中。用户可以证明“我的 note 位于有效集合里”，却不指出自己对应哪一个叶子节点。
每次消费还会产生 nullifier，即由 note 的秘密派生出的单向序列号。正常用户每次使用新的状态，外部无法据此把多个请求关联起来；如果同一余额被重复消费，系统会看到重复 nullifier 并拒绝该行为。
开源实现 当前使用 BN254 曲线上的 Groth16、Poseidon 哈希和 32 层 Merkle Tree，并提供 OpenAI Chat Completions、Responses API 与 Ollama 兼容端点。这意味着现有聊天界面、编辑器或 Agent 工具理论上只需改成本地地址，而不必重写上层应用。
“付款匿名”不等于“完整匿名”
这是理解 zkAPI 最重要的边界。
在直接运行时 Key 模式下，模型提供商仍会看到提示词和响应，因为它必须执行推理。提供商也可能看到 IP 地址、请求时间和设备产生的其他网络特征。zkAPI 隐藏的是付款身份以及付款记录与会话之间的链接，不会自动隐藏内容或网络来源。
用户如果在不同会话中反复提交姓名、公司文件、独特写作风格或相同上下文，模型提供商仍可能重新关联这些会话。Tor、VPN 或可信执行环境可以分别缓解网络和内容层问题，但它们不属于 zkAPI 本身提供的完整保证。
此外，隐私集合的实际强度取决于使用者数量和行为分布。系统即使在密码学上正确，如果同一时间只有极少数用户充值和消费，时间相关性仍可能缩小匿名集。
为什么它对 AI Agent 特别重要？
Agent 与普通聊天不同。它们可能持续调用模型、RPC、搜索、代码执行、图片生成和第三方数据接口。如果所有服务都依赖长期账户和长期 Key，一个 Agent 的完整任务路径就可能被不同平台分别记录，并通过付款关系与组织身份连接起来。
私密预付凭证提供了另一种机器支付模型：Agent 获得有额度、有期限的使用权，而不是拿到长期账户凭据。额度耗尽后权限自然结束；服务方能确认付款，却不必知道背后是哪个钱包、员工或组织。
可扩展场景也不止 AI。Ethereum Foundation 列出的方向包括区块链 RPC、图片和视频生成、VPN、带宽以及机器对机器服务。共同特征是：调用频繁、单次金额小、服务方需要防止滥用，而用户不希望付款记录形成持久身份。
对开发者和产品团队意味着什么？
短期内，zkAPI 更像一个实验性基础设施，而不是 Stripe 或 API Gateway 的即插即用替代品。团队如果考虑测试，应重点验证以下问题：
- 本地证明生成对延迟、CPU 和移动设备电量的影响；
- Key 到期、用量收据失败或服务端离线时的恢复路径；
- 链上充值、提现和紧急退出是否经过独立审计；
- 供应商是否能通过 IP、时间或提示内容重新关联会话；
- 合规场景是否允许服务方只验证付款，而不识别客户身份；
- 匿名集、流动性和运营成本能否支撑真实用户规模。
目前的代码仓库、主网合约与客户端证明“系统可以运行”，并不等于它已经经过大规模生产验证。项目的采用量、安全审计和实际隐私效果仍需持续观察。
我的判断：API Key 会逐渐变成可编程使用权
传统 API Key 同时承担身份、权限和计费三个职责，泄露后往往拥有过长寿命和过大权限。Agent 时代更合理的凭证应当是短期、限额、限定模型和限定操作范围的能力票据。
zkAPI 的意义不只是把 Web3 支付接到 AI 上，而是展示了另一种授权结构：先证明资格和预算，再获得一个最小化、会自动失效的运行时能力。零知识证明进一步允许资格验证与真实身份分离。
它能否成为通用标准仍不确定。链上成本、证明性能、供应商集成、监管义务和匿名集规模都可能限制采用。但如果机器开始自主购买推理、数据和计算资源，“无需长期账户、可验证余额、最小化身份暴露”的支付层会越来越有价值。
zkAPI 不是完整隐私的终点，却可能是 API 从账户制走向可编程、可撤销、隐私化使用权的一次重要实验。
参考资料
- Ethereum Foundation：Introducing zkAPI — private usage credits for any API
- Ethereum Research：ZK API Usage Credits — LLMs and Beyond
- Open Anonymity：zkAPI EF collaboration repository
- Open Anonymity Project on GitHub