全文

付款纪录与服务内容为何会被连在一起

以太坊基金会在 2026 年 10 月 1 日介绍 zkAPI，目标是降低 API 使用与付款身分之间的连结。一般服务常把多次请求放在同一账户下，方便计费，也形成长期使用纪录。这里要解决的是数据如何被串连，而不只是付款时是否填入姓名。假设两个工作阶段使用同一个可识别账户，即使每次付款金额不同，服务仍可能把它们理解成同一人的活动。

证明有额度，不必交代哪笔存款

来源描述的设计让使用者先存入额度，再以零知识证明取得消费授权。可以把它理解成回答一个范围受限的问题：是否具备足够且未重复使用的付款能力，而不交出所有相关数据。这与单纯把姓名栏位删掉不同，因为删除栏位后，固定帐号仍可能充当身分标记。设计的价值在于减少完成验证所需暴露的关系，但证明的涵盖范围也限定了它能保护什么。

消费上限是预留，不必等于最后帐单

zkAPI 的短效密钥带有消费上限，工作阶段结束后依实际用量结算。假设使用者授权最多十单位预算，服务最后只用了三单位，上限与实际收费就应分别记录。十单位表示可以接受的最大暴露，三单位才是这个例子的用量。若界面把两者都叫余额，容易让人误会预留已被永久扣除。这个假设也说明，限制支出与核对计量是不同问题，设定上限不能替代对帐。

付款保密不会让请求内容自动保密

即使付款与存款之间的关系被隐藏，服务仍可能读到请求内容。假设使用者在输入中直接写入公司名称与完整专案数据，付款层的隐私不会把这些字抹掉。时间、网络来源与重复输入也可能提供额外线索。来源另区分直接使用短效密钥与代理转送模式，后者让转送方接触流量。因此，判断谁看得到什么，必须沿实际数据路径逐一追踪，不能把单一隐私功能扩大成全面匿名。

可验证付款仍需要可理解的服务边界

本站认为，这类设计最有价值的地方是将权限压缩到一次工作所需的范围：有限预算、有限期间与有限数据揭露。对使用者而言，仍需分辨授权是否过期、用量如何记录，以及中断后哪部分额度可再使用。这些是产品与结算语意问题，不能只靠证明有效就自动解决。本文依十月的设计介绍说明机制，不把所有 API、供应商或后续版本都描述成已具备相同能力。