图片原始来源 · 原公告架构图说明性引用 · 未改动内容；网页缩放展示
在按量计费的API场景里，“隐私额度”常被当成一个笼统的匿名开关。按zkAPI在2026年10月1日公告中的设计，它想拆开的只有一件事：谁为这次调用付了钱，与这次调用由谁发出、问了什么，不必落在同一条记录上。额度就是连接支付与请求的那张凭证，但它的作用范围有明确边界。
它拆开了什么
按公告设计，用户先把资金存入以太坊上的金库合约，形成一笔只能由持有者支配的额度；随后由本机客户端生成零知识证明，向服务端表明“这笔额度足以支付本次用量，且没有被重复花费”。服务端核验后签发短期、限额的API密钥，提示词由本机直接发往模型提供方。支付侧看到花费，模型侧看到内容，两者之间不直接传递身份对应关系。
这里要避免过度承诺。公告把网络匿名与内容隐私列为独立问题：它不隐藏IP，提供方仍可能依据稳定的IP、请求时间与金额模式做关联；提示词里的个人信息、写作风格、重复上下文，也可能让多次会话被重新识别。所谓“拆开”，拆的是账单身份与请求之间的直接链接，不是让请求变得不可识别。
一笔教学计算
以下数字均为说明性假设，不来自公告。设某开发者存入30 USDC，单次会话密钥上限2 USDC：
| 环节 | 发生什么 | 各方可见 |
|---|---|---|
| 存入 | 一笔普通链上交易进入金库合约 | 公链可见存款金额与地址，看不到后续具体用途 |
| 申请密钥 | 本地客户端提交额度足够且未重复使用的证明 | 服务端确认支付有效，不直接获知对应哪笔存款 |
| 调用模型 | 提示词从本机发往提供方 | 提供方看到请求内容，不直接获知付款人 |
| 结算 | 密钥到期后按签名用量回执扣减额度 | 支付侧看到该会话的总花费 |
若这场会话实际用了1.2 USDC，未用完的预留额度如何退回，公告只说明按实际计量用量扣减、而非按预留上限收费，具体结算细节应以实现为准，不宜自行补写协议规则。这个例子要说明的是：额度证明的是“可花多少钱”，不是“你是谁”。重复花费同一笔额度会产生重复的花费标识，从而暴露该次尝试，但公告并未承诺暴露之外的其他信息。
判断它是否适合你
可以用三个问题快速筛选：
- 你的顾虑是账单与身份被串起来吗？ 如果是，这类设计对症；如果你担心的是提供方看到你的IP或请求内容，它不对症，需要另配网络层与内容层手段。
- 提供方是否接受证明而非账号？ 公告称集成方接受证明、按签名用量回执结算，但这依赖服务方配合，不能假设已被全网采用。
- 会话内容本身是否可被指纹化？ 同一写作风格、反复出现的个人细节、复用的对话历史，都可能成为关联线索。缓解办法是减少身份信息、拆分上下文，或借助本地模型生成请求。
两个容易混淆的点
其一，匿名不等于花费不可见。链上仍能看到存款、关闭与提取，只是看不到某笔余额具体支付了什么。其二，公告提到另有更简单的代理模式，由zkAPI服务端中继请求，运维更容易，但中继能看到流量；本地短期密钥模式正是为减少支付中介接触内容而设计。评估时应区分两种模式，而不是笼统认为“用了就隐私”。
关于上线状态：项目方称该实现已于2026年10月1日在以太坊主网运行，这是项目自述，合约安全性未经独立验证。本文是对该公告的回顾解读，不是当日新闻，也不代表已经过实际使用检验。