以太坊 zkAPI 隐藏了谁在为 AI 付费，但模型仍能看到提示词

以太坊基金会与开放匿名项目于10月1日在以太坊主网上推出了zkAPI。用户可以存入信用额度，并证明之后的一次AI API请求已获支付，而无需向支付服务器透露身份，也无需向模型提供商透露资金来源地址。提供商仍然会收到提示词。这种分离是有用的，但它所主张的隐私范围比与模型进行匿名对话要窄。

以太坊基金会的技术公告对这条边界异常明确。该证明隐藏了是哪张票据为使用付费，而提供商运营模型并看到请求。公告还指出网络元数据和提示词内容是仍然存在的关联来源。这一点很重要，因为“私密AI支付”这个说法很容易被听成“私密AI使用”。

据基金会称，该项目已上线，并配有公开的GitHub仓库、一个持有USDC信用额度的主网金库，以及从其公告链接出的演示聊天界面。上线部署只能证明有代码和合约可供审查。它并不能证明用户采用情况、安全审计的范围、每种客户端配置下的匿名性，或能否防范一个能识别用户写作和文档的提供商。

一次存款取代一连串API账单

大多数商业AI API将密钥与账户和支付方式关联起来。即便用户从未在提示词上署名，提供商也能将请求与账单身份关联起来。zkAPI引入了已注资金库和私密票据。用户将USDC等受支持资产存入合约；用户机器上的软件随后生成零知识证明，证明一张有效的已注资票据可以为有界使用付费，而不披露是哪张票据。

支付服务器验证该证明，并签发一个短时效、以美元为上限的API密钥。在基金会描述的直接运行时密钥模式中，提示词会带着该密钥从用户设备发送到AI提供商。会话结束后，一份签名收据记录计量使用量，私密余额按实际使用金额扣费，而不是简单按预留上限扣费。一个证明可以覆盖包含多个请求的一个会话。

这避免了把每一次模型请求都放到以太坊上。链上看到的是金库存款、关闭和提款，而服务器在链下验证消费证明。模型提供商会看到文本和API流量。支付服务器会看到会话已获注资的证据以及总费用，但在直接模式下不会收到提示词。这些是关于所述架构的主张，并不证明某个特定部署的日志或网络配置永远无法关联用户。

还有一种更简单的代理模式。在该模式中，zkAPI服务器将用户请求中继给模型提供商。据基金会称，该服务器可以看到流量。在两种模式之间做选择的人应当问：他们信任哪一方处理内容，哪一方只需要验证支付证明。一个看起来完全相同的本地界面，在底层可能会以不同方式路由请求。

该票据在不指明其存款人的情况下证明价值

该密码学构造在默克尔树中使用承诺。一个证明表明用户的票据属于有效的已注资票据之一，而不标识其叶节点。一个由票据秘密派生出的无效化符（nullifier）防止同一余额被花费两次。基金会指明使用 BN254 上的 Groth16 证明和 Poseidon 哈希，并采用 32 层树。这些细节对实现者很重要，但财务原则更简单：验证成员资格和剩余的消费权限，而不公开提供信用的账户。

用户并不能通过隐藏身份来获得免费使用。服务器必须在发放临时密钥之前检查消费证明并预留一个上限。提供商对使用进行计量。收据在密钥过期后结算实际金额。如果预留了 10 美元的上限而消耗了 3 美元的服务，系统应当收取 3 美元，而不是 10 美元。该示例说明的是预留逻辑，而非公布的价格或保证的最低金额。剩余余额留在私有票据中，受实现规则的约束。

无效化符针对一个特定的失败情形：试图将一张票据花费两次。它并不证明 AI 模型回答准确、不保护提示的机密性，也不阻止提供商记录请求。零知识证明是关于在既定电路下交易有效性的陈述。其保证不会自动扩展到随交易一同流动的其他数据。

合约的退出路径也很重要。基金会表示，即使用户的 zkAPI 服务器消失，用户也可以关闭金库余额并在链上提款。这避免了让支付服务器成为取回资金的唯一途径。它并不会让退出变得不可见：以太坊会记录相关交易。用户的退出能力取决于合约以及对必要秘密的持有，谨慎的用户在向该机制分配大额价值之前，应检查部署地址、权限以及任何独立审查。

提供商能够识别出证明无法揭示的内容

支付证明可以隐藏资金来源，而请求正文却包含一个人的姓名、雇主、病史或专有代码。读取提示的模型提供商可以通过重复的短语、上传的文件、对话历史或高度独特的事实，将其与先前的会话关联起来。无需钱包链接。一个关于未发布产品的提示，若在三次会话中使用相同的内部项目名称，其本身就是标识符。

网络元数据提供了另一条路径。在运行时密钥模式下，提供商可能看到设备连接所用的 IP 地址。在代理模式下，中间人可以查看流量，并可能查看其来源网络信息。基金会明确指出，稳定的 IP 和相关的时序会削弱隐私，并建议寻求更强保护的用户使用网络匿名工具。VPN 或 Tor 可以改变网络路径，但两者都无法消除键入提示中的姓名。

存在一个三层隐私测试。支付隐私询问账单能否与资金票据或个人关联。网络隐私询问服务能否通过 IP、时序或设备特征识别连接。内容隐私询问任何操作模型的人能否读取提示。zkAPI 主要针对第一层设计。它可以减少模型提供商的使用日志与用户支付来源之间的账户级关联。它本身并不提供另外两层。

这并不是隐藏在细则中的缺陷。该项目自己的公告称提供商可以看到请求。诚实的描述比宽泛的匿名口号更有力，因为它告诉用户应在何处集中采取额外的预防措施。使用该服务提出通用问题的人可能会获得实质性的支付不可关联性。粘贴一份已签署合同和全名的人，无论支付路径如何，都已在内容中披露了身份。

即使证明可靠，匿名集也可能很小

零知识可以隐藏若干票据中哪一张进行了支付，但实际的人群规模很重要。如果只有一个用户在一个狭窄的时间窗口内以不寻常的存款金额为一个金库注资，并且在一次会话之后出现同样独特的提款，观察者可以根据公开的时序和金额形成一种看似合理的关联。证明可能在密码学上仍然有效且未被破解。从外部信息进行推断是一种独立的攻击。

32 层树是设计中的容量参数，而不是如今有数十亿不同用户正在混合其信用的证据。一项新上线的服务可能只有少量已注资票据。要在实践中评估匿名性，人们会希望获得带有日期标注的存款数量、不同的活跃票据数量以及提款模式，并进行注重隐私的聚合。代码仓库或理论上的树规模并不能提供这些数字。

假设有十张票据符合某次会话的条件，而公开事实排除了其中九张。数学证明仍然可以完美地隐藏其见证，而周围的信息却指向第十张。这个简单的例子说明了为什么合理集合的大小和多样性比金库中交易的原始数量更重要。金额标准化、延迟活动和规律使用可能有所帮助，但用户行为和服务设计决定了可供关联的信息。

在 AI 提供商处还存在第二种集合：共享一个短期密钥的一组请求。该密钥可以在其受限会话内链接请求，即使它无法识别存款。这是对会话进行计量的固有特性。如果客户端在后续会话中反复发送相同的文档，提供商也可能跨密钥将它们关联起来。隐藏计费账户是有价值的，但这并不能迫使提供商忘记它所读取的内容。

在不假设任何人作弊的情况下，绘制单次会话的记录。以太坊记录存款交易及其资金来源地址。用户设备保留票据秘密并向支付服务器发送证明。服务器记录证明的有效性、一个无效化符以及为一个受限密钥签发的事件。模型提供商记录该密钥、请求以及它所计费的使用量。签名收据将该密钥与计量总额绑定。在关闭时，合约可以记录一次退出。每一方都持有一份部分账本。

预期的隐私属性是，任何单个诚实方的账本都不会直接将资金来源地址与提供商的提示词连接起来。联盟、数据泄露或拥有时间戳的外部观察者可能掌握更多信息。如果用户存入一笔不寻常的金额并立即发送一个不寻常的请求，关联事件可能会变得更容易。如果提供商收到一份能识别用户的文档，即使它从未看到金库地址，也能知道是谁提出的请求。这是一个组合问题，而不是零知识证明的失败。

账本演练还揭示了密钥生命周期的重要性。会话凭证有意将其授权的所有请求分组，以便提供商可以对它们进行计量。50 美元的上限可能允许一个密钥下有许多提示词。更低的上限和更短的会话可以减少单个凭证内被链接的内容量，但它们需要更频繁的证明，并可能增加延迟或费用。不存在普遍私密的设置；用户和提供商在便利性、成本和可链接性之间进行选择。

公开的威胁模型应明确指出保留哪些记录以及保留多长时间。它应说明服务器在提交证明期间是否记录源 IP 地址、是否无限期存储无效化符，以及提供商在结算后是否可以将收据标识符与请求内容关联起来。从数据库中删除计费名称是有帮助的。但如果一个持久性设备标识符悄悄重建了相同的画像，那就不够了。

签名使用收据将信任转移到计量中

提供商或服务器需要一种对实际执行的工作收费的方式。该设计使用与短期密钥及其使用量相关联的签名收据。这将一个核心商业问题转移到了计量的准确性上。如果提供商多计了 token、请求或时间，有效的支付证明无法纠正底层账单。签名使所声明的总额日后难以被改写；它并不能证明所声明的使用量在提供商的费率卡下是公平的。

客户应该询问计费单位是什么、谁签署收据、未使用的预留如何释放，以及当请求中途失败时会发生什么。这些是披着不寻常密码学外衣的普通计费问题。上限限制了单次会话中意外费用的规模，但许多小会话仍可能累积可观的成本。速率限制和发票可能需要一个保护隐私的争议处理流程。

这种权衡是运营层面的。传统 API 账户简化了客户支持、退款和滥用调查，因为提供商可以识别买家。zkAPI 从预期的支付路径中移除了持久性计费身份。提供商可能仍需要滥用控制、适用情况下的制裁筛查以及使用量执行。基金会表示定价和速率限制可以保留，但实际集成将展示服务如何在无账户支付与其义务和欺诈控制之间取得平衡。

一个实际测试是故意中断的会话。客户端获得一个受限密钥，发出若干请求，失去网络访问，随后重新连接。收据是否只反映已交付的使用量？用户能否在本地审计计量金额而无需将提示词发送到支付服务器？如果服务器消失，用户能否如宣传的那样通过合约取回未使用的余额？这些测试超越了证明是否验证通过，进而检验产品在故障情况下是否保持了所承诺的分离。

链上合约是逃生舱，而非隐私护盾

据基金会称，该金库合约可以验证存款、关闭和逃生操作的证明。链上退出路径之所以重要，是因为服务提供商关闭不应将用户资金困在运营商的数据库中。该合约用智能合约风险取代了部分机构信任。即使隐私概念本身是合理的，证明验证、记账或提款逻辑中的漏洞仍可能影响资金。一个活跃的地址是部署的证据，而非审计证书。

公开存款和提款也有隐私成本。知道用户资金地址的人可以观察到该地址与金库进行了交互。他们可能看不到它支付了哪个 API 会话，但可以看到参与行为和金额。如果同一用户迅速将一笔不寻常的金额提取到已与其关联的地址，周围的部分匿名性可能会缩小。私密票据打破了确定性的计费关联；它并不能抹去公开的资金交易。

该项目源于一项零知识 API 积分的以太坊研究设计，基金会将其认定为 Davide Crapis 和 Vitalik Buterin 的工作。研究提案和生产系统回答的是不同的问题。前者提出了一种构造；后者必须处理密钥存储、前端行为、服务中断、收据纠纷、升级和真实的对手。10 月 1 日的发布将该想法推进为一个可测试的部署，而这才是相关的新鲜切入点。

以太坊更广泛的隐私努力并非同一产品。Crypto.news 对一项拟议原生隐私设计的报道涉及的是协议变更草案，而 zkAPI 是一个当下正在运行的应用。近期 zk.money 钱包的发布涉及的是另一环境中的私密转账。两者都不应被引作证据，证明通过 zkAPI 发送的 AI 提示对其模型提供商是隐藏的。

隐私声明应经得起可复现的测试

独立审查者可以从无关地址创建两个已注资的票据，与同一模型提供商发起短会话，并检查客户端、支付服务器和提供商可见的每个数据包和日志。审查者应分别测试直接模式和代理模式。如果直接模式下的支付服务器收到了提示，那就与所描述的分离相矛盾。如果提供商收到了存款地址或持久计费账户标识符，那么即使证明电路是可靠的，预期的不可关联性也在集成层失败了。

更难的测试是统计性的。运行大量金额和时间各异的会话，然后考察仅拥有公开链数据和服务器日志的一方能否以高于随机概率的水平将资金与使用关联起来。基准取决于实际的匿名集以及对手拥有哪些辅助数据。一次成功的小型实验室演示并不能在极小的生产用户基数下确立隐私，但它创造了一种衡量部署是否随时间改进的方法。

内容测试直截了当且发人深省。在两个全新的会话密钥下提交同一份独特的文档。如果提供商能在两者中都识别出它，那么支付不可关联性并未给用户带来对话不可关联性。关于支付的声明应通过前两项测试来评估；关于匿名 AI 使用的声明还必须通过第三项测试。公布模式、威胁模型和结果将让用户能够针对其实际关切选择正确的工具。

最有力的论据是将计费与有用内容解绑

有许多正当理由可以向 AI 提供商提出敏感问题，而不必建立与账户永久关联的使用档案。一名记者测试公开文件、一名研究人员探索有争议的假设，或一名开发人员在智能体内部使用 API，可能希望提供商看到当前请求，同时切断持久的计费关系。zkAPI 的设计针对的正是这一较窄的需求。它还让机器能够为按量计费的服务付费，而无需为每个请求管理一个长期存在的个人账户。

反对过度宣称的理由同样充分。提供商仍然能看到提示，而某些提示必然会泄露身份。有严格保密要求的企业可能需要合同控制、本地模型或机密计算，以及支付不可关联性。一些用户可能更偏好拥有成熟支持和退款机制的普通账户，而非争议机制仍不成熟的加密支付层。选择取决于实际的威胁模型。

crypto.news 所讨论的以太坊隐私路线图将隐私框定为一项更广泛的目标。路线图并不会将其未来的保护赋予今天的这个应用。AI 用户必须判断实际处理提示的实时客户端和提供商路径。

Crypto.news 在另一篇入门文章中解释了零知识证明更狭义的机制。证明揭示了一个确定的事实而不揭示见证；它不是通用的隐形斗篷。其对专注于隐私的以太坊基础设施的采访强调了不同产品如何保护不同的数据。对 zkAPI 而言，有用的问题是每一步中哪一方看到哪条记录，而不是该项目是否符合“隐私”这个宽泛词汇。

对怀疑性解读的最佳反证将是在没有持久身份关联的情况下进行的有节制的使用、清晰的模式标签、独立的安全审查，以及一份涵盖 IP、浏览器遥测和收据的已发布威胁模型。对夸大营销主张的最佳反证已经出现在基金会的帖子中：提供商看到了提示。这两种观察可以同时成立。

基金会将机器对机器 API 支付列为一种可能的应用。一个自主代理可能会使用一张已注资的票据或许多短会话发送数百次调用。如果其任务携带客户记录，模型提供商即使在该代理的支付来源保持私密的情况下，也能了解到这些客户的信息。隐私收益属于计费环节；它不应被传递给请求中提及的每一个主体。

代理还需要预算控制。每个密钥的上限限制了一个会话，但除非客户端执行更广泛的支出策略，否则一个循环可以反复获取密钥，直到票据被耗尽。运营者应定义每日或任务级别的限额、告警以及与密码学证明分离的暂停控制。证明验证的是授权信用，而不是代理的调用是否必要或经济。

当多个代理共享一个信用池时，内部记账可能成为隐藏的计费系统。运营者可能需要将费用分配给团队或客户，而不将其身份导出给 API 提供商。这可以通过本地账本完成，但它会创建另一个需要保护的敏感数据集。从账户计费转向票据计费并不会废除对账；它只是将其转移了位置。

最后，代理可以通过行为暴露自己。按相同时间表重复调用、相同的工具标头和相同的任务特定短语，可能会使分离的短寿命密钥容易被聚类。隐藏链上资金票据对于支付监控是有用的。它并不能防御代理随每个请求发送的行为指纹。

部署仍然需要威胁模型审计

截至 10 月 2 日，基金会表示代码、服务器、客户端和保险库均已上线。该帖子链接了一个主网合约和代码库。它并未在公告中发布确定的用户数量、经审计的总价值、所有第三方集成，或保证每个客户端配置都使用直接运行时密钥模式。此功能并未声称某个具名提供商存在违规或不当行为。它指明了每一方预期接收的信息，以及项目作者承认的额外泄露。

外部评估应检查客户端默认设置和出站连接。浏览器演示是否向无关域发送遥测？本地客户端是否保留密钥或提示日志？支付服务器能否将签发时间戳与网络地址关联？收据能否跨会话关联？电路和合约更新如何治理？证明可以在数学上无懈可击，而用户界面却意外泄露了它本应分离的身份。

同一评估应测试 AI 提供商的视角。它将看到其处理的内容和一个会话凭证。它可能会根据请求路径收集设备或网络元数据。提供商的数据保留政策和任何合同条款仍然至关重要。支付层可以减少一个身份信息来源，而不会约束所有其他来源。

如果 zkAPI 能够可靠地阻止模型提供商将有用的请求绑定到计费账户，同时保留用户收回资金的能力，那它确实是一项真正的进步。但对于任何仅仅因为付款是以零知识方式证明的就期待私密对话的人来说，它会令人失望。这两个主张应当分开评判。

值得关注的事项

• 模式标注：检查每个客户端是否在用户发送提示词之前，将直接运行时密钥或代理路由方式明确显示出来。
• 主网活动：寻找有日期的已注资票据和使用量统计，且报告方式不损害用户的匿名性。
• 安全审查：阅读独立评估的范围，涵盖合约退出、证明电路、客户端存储和收据结算。
• 元数据控制：在实际集成中测试 IP 处理、遥测、密钥生命周期和提供商保留策略。
• 计费争议：检查失败请求、额度释放和有争议的收据如何处理，且不强制披露身份。

常见问题