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

以太坊基金会和 Open Anonymity Project 于 10 月 1 日在以太坊主网上线了 zkAPI。用户可以先存入信用额度，并在之后证明某次 AI API 请求已付费，而无需向支付服务器提供身份信息，也无需让模型提供方知道资金地址。模型提供方仍会收到提示词。这样的分离有用，但它所提供的隐私承诺，比“与模型进行匿名对话”要窄得多。

• 以太坊基金会称，zkAPI 已于 10 月 1 日在主网上线，采用链上金库和链下证明校验。
• 一笔已注资的凭证可授权一个有上限、短时有效的 API 会话，而不是每个提示词都进行一次链上支付。
• 支付服务器会知道某次有效支出和会话总额；模型提供方会收到提示词和回复。
• 直接运行密钥模式避免内容中继；代理模式则让 zkAPI 服务器看到流量。
• 即使隐藏了支付来源，IP 地址、时间、重复使用的上下文和个人细节仍可能把不同会话关联起来。

以太坊基金会的技术公告对这条边界说得非常明确。证明隐藏的是哪一张凭证在为使用付费，而提供方负责运行模型并看到请求。公告还指出，网络元数据和提示词内容仍可能成为关联来源。这一点很重要，因为“私密 AI भुगतान”这类说法，很容易被理解成“私密 AI 使用”。

据基金会称，该项目已经上线，配有公开的 GitHub 仓库、一个持有 USDC 信用额度的主网金库，以及公告中链接的演示聊天界面。上线部署意味着确实存在可供检查的代码和合约，但并不意味着已经证明用户采用情况、安全审计范围、所有客户端配置下的匿名性，或能防止提供方通过识别用户写作风格和文档来关联身份。

一笔存款，替代一串 API 发票

大多数商业 AI API 会把密钥与账户和支付方式绑定。即便用户从未用姓名签署提示词，提供方也可以把请求与某个计费身份关联起来。zkAPI 引入了一个已注资的金库和一张私密凭证。用户将 USDC 等支持的资产存入合约；随后，用户设备上的软件会生成零知识证明，证明某张已注资凭证可以为受限使用付费，而无需披露具体是哪一张凭证。

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

这避免了把每一次模型请求都写到以太坊上。链上只会看到金库存款、关闭和提现，服务器则在链下验证支出证明。模型提供方会看到文本和 API 流量。支付服务器会看到会话已获得资金支持的证据以及总扣费额，但在直接模式下不会收到提示词。这些说法针对的是所描述的架构，并不等于证明某个具体部署的日志或网络配置永远无法关联用户。

还有一种更简单的代理模式。在该模式下，zkAPI 服务器会把用户请求转发给模型提供方。基金会表示，这样服务器就能看到流量。用户在两种模式之间做选择时，应当问清楚自己信任哪一方处理内容，以及哪一方只需要验证支付证明。一个看起来完全相同的本地界面，底层路由方式可能不同。

凭证证明价值，但不透露存款人身份

这套密码学构造使用了 Merkle 树中的承诺。证明会说明用户的凭证属于有效且已注资的凭证集合，但不会标识其叶子节点。一个由凭证秘密派生出的 nullifier 可以防止同一余额被重复花费。基金会提到，该设计使用 BN254 上的 Groth16 证明、Poseidon 哈希以及 32 层树。这些细节对实现者很重要，但其金融原则更简单：在不公开提供信用额度的账户的前提下，验证成员资格和剩余支出权限。

用户并不是通过隐藏身份就能免费使用。服务器必须检查支出证明，并在发放临时密钥前预留一个上限。提供方会对使用量进行计量。收据会在密钥过期后结算实际金额。若预留 10 美元上限而实际消耗 3 美元服务，系统的设计目标是只扣 3 美元，而不是 10 美元。这个例子说明的是预留逻辑，而不是公开定价或最低消费承诺。剩余余额会继续留在私密凭证中，具体取决于实现规则。

nullifier 解决的是一个特定失败场景：试图用同一张凭证花两次钱。它并不能证明 AI 模型回答准确，也不能保护提示词机密性，更不能阻止提供方记录请求。零知识证明只是对某个定义好的电路内交易有效性的陈述，它的保证不会自动扩展到随交易一起传输的其他数据。

合约的退出路径也很重要。基金会表示，即便 zkAPI 服务器消失，用户仍可关闭金库余额并在链上提现吗。这避免了把支付服务器变成取回资金的唯一通道。不过，这并不意味着退出过程是隐身的：以太坊会记录相关交易。用户能否退出取决于合约和必要秘密的持有情况，而谨慎的用户在投入大额资金前，应检查部署地址、权限以及是否有独立审查。

模型可以识别证明无法揭示的内容

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

网络元数据提供了另一条路径。在直接运行密钥模式下，提供方可能看到设备连接时的 IP 地址。在代理模式下，中介方可以看到流量，并可能看到其来源网络信息。基金会明确表示，稳定的 IP 和相关时间点会削弱隐私，并建议追求更强保护的用户使用网络匿名工具。VPN 或 Tor 可以改变网络路径，但都无法抹去提示词里输入的姓名。

这里可以把隐私分成三层来检验。支付隐私关注账单能否与资金凭证或个人关联；网络隐私关注服务是否能通过 IP、时间或设备特征识别连接；内容隐私则关注运行模型的一方是否能读取提示词。zkAPI 主要针对第一层。它可以减少模型提供方使用日志与用户支付来源之间的账户级关联，但本身并不能同时解决后两层问题。

这并不是藏在细则里的缺陷。项目自己的公告就说了，提供方会看到请求。诚实地说明边界，比夸大的匿名口号更有价值，因为它告诉用户应当把额外防护重点放在哪里。用这项服务提问一般性问题的人，可能会获得相当程度的支付去关联化；而把已签署合同和全名贴进去的人，无论支付路径如何，内容本身已经暴露了身份。

匿名集合即使证明正确，也可能很小

零知识可以隐藏究竟是哪一张凭证在付费，但现实中的“人群规模”同样重要。如果只有一个用户在很窄的时间窗口内以一个不寻常的金额为金库注资，随后又有一次同样显眼的提现吗，观察者就可以根据公开的时间和金额形成合理关联。证明本身可能仍然在密码学上有效且未被破坏，但来自外部信息的推断是另一种攻击。

32 层树只是设计中的容量参数，并不能证明今天已经有数十亿不同用户在混合自己的信用额度。一个刚上线的服务，可能只有很少一批已注资凭证。要评估现实中的匿名性，理想情况下需要按日期统计存款数量、不同活跃凭证数量以及提现模式，并以保护隐私的方式汇总。仓库代码或理论树规模都不能提供这些数字。

假设有 10 张凭证符合某次会话条件，而公开事实排除了其中 9 张。数学证明仍然可以完美隐藏其见证，但周边信息却会指向第 10 张。这个简单例子说明，可行集合的规模和多样性，比金库里交易总数更重要。统一金额、延迟活动和规律使用可能有所帮助，但最终能否被关联，取决于用户行为和服务设计。

AI 提供方那里还有第二种集合：共享同一个短时密钥的请求组。即便该密钥不能识别存款来源，它也会把同一会话中的请求联系起来。这是按会话计量的内在结果。如果客户端在后续会话中反复发送相同文档，提供方也可能跨密钥把它们关联起来。隐藏计费账户很有价值，但并不会迫使提供方忘记自己已经读过的内容。

如果不假设任何一方作弊，可以把单次会话的记录画出来：以太坊记录存款交易及其资金地址；用户设备保留凭证秘密，并向支付服务器发送证明；服务器记录证明有效性、nullifier 以及一个带上限密钥的签发事件；模型提供方记录该密钥、请求以及它计费的使用量；签名收据把密钥与计量总额关联起来；在关闭时，合约可以记录一次退出。每一方都只持有部分账本。

其目标隐私属性是：没有任何一个诚实方的账本会直接把资金地址与提供方的提示词连接起来。不过，联盟、数据泄露或掌握时间戳的外部观察者，可能会知道更多信息。如果用户存入一个不寻常的金额，并立刻发送一条同样不寻常的请求，事件关联可能就更容易。如果提供方收到一份能识别用户身份的文档，即便它从未看到金库地址，也能知道是谁在提问。这是一个组合问题，而不是零知识证明失效。

这份账本练习也说明了密钥有效期的重要性。会话凭证会刻意把它授权的所有请求归为一组，以便提供方计量。50 美元上限可能允许在同一密钥下发送很多提示词。更低的上限和更短的会话可以减少单个凭证内关联的内容量，但它们需要更频繁地生成证明，并可能增加延迟或成本。不存在一种对所有人都通用的“最私密设置”；用户和提供方是在便利性、成本和可关联性之间做选择。

公开的威胁模型应当明确列出保留了哪些记录以及保留多久。它应说明服务器在提交证明时是否记录源 IP，是否无限期保存 nullifier，以及在结算后提供方是否还能把收据标识符与请求内容关联起来。从数据库中删除计费姓名是有帮助的；但如果一个持久设备标识符悄悄重建了同样的画像，这就远远不够。

签名使用收据把信任转移到计量环节

提供方或服务器需要一种方式来对实际完成的工作收费。该设计使用与短时密钥及其使用量相关联的签名收据。这把一个核心商业问题转移到了计量准确性上。如果提供方多算了 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 处理、遥测、密钥有效期和提供方保留策略。
• 账单争议：检查请求失败、上限释放和有争议收据如何处理，同时不强制披露身份。

常见问题

zkAPI 已经在以太坊主网上线了吗？

以太坊基金会在 10 月 1 日表示，其金库以及配套客户端和服务器已上线，并链接了主网合约和代码仓库。

zkAPI 会把我的提示词对 AI 提供方隐藏起来吗？

不会。提供方需要接收提示词来运行模型。支付证明的设计目标，是隐藏使用信用额度的来源。

支付服务器会知道什么？

在所描述的直接模式下，它会知道存在一笔有效支付以及该会话的计量总额，但不会收到提示词，也不会识别具体存款。

代理模式和直接模式一样私密吗？

不是。基金会表示，代理会转发请求并能看到流量。直接运行密钥模式则是从设备把提示词直接发送给提供方。

IP 地址能识别用户吗？

它可以帮助关联会话，尤其是在结合时间和内容时。zkAPI 本身并不提供网络匿名性。

如果 zkAPI 服务器关闭会怎样？

基金会表示，金库合约提供链上退出，用户可以在不依赖该服务器的情况下关闭并提现吗。不过该实现仍值得审查。

存款和提现在以太坊上是不可见的吗？

不是。公开交易会暴露金库交互。证明的目标，是切断已注资凭证与后续计量 API 使用之间的联系。

这是不是一种与任何模型讨论机密材料的私密方式？

不是仅靠它就行。提供方会看到内容，用户还需要评估保留策略、网络元数据以及每条提示词的敏感程度。