加密之外的零知识证明：KYC、年龄验证、供应链

零知识正在逃出加密这个沙盒。这项允许你证明一项陈述而不暴露底层数据的技术，如今已成为 KYC、年龄验证、供应链溯源、凭证检查与机密 ML 的可行集成工具。门槛比三年前低。工具是真实的。审计生态比加密那边薄，但存在。本文覆盖 六个具体的非加密用例，Wavect 已界定或已构建过，附成本区间、复杂度评级和关于“对你团队是否值得”的诚实问答。

ZK 对非加密产品到底解决什么？

一句话：证明关于私有数据的一项事实，而不暴露数据。这能映射到很多合规与隐私问题。监管自 2024 年以来在这些问题上施压更紧。年龄门、欧盟驻留检查、供应链溯源、凭证验证、私有 ML 推理。这些过去要么交出底层文档，要么信任一个中心化背书方。ZK 给了你第三种选项。

用例 1：隐私保护的 KYC

问题。你的产品需要知道用户已满 18 岁且为欧盟居民。它不需要知道用户的出生日期、街道地址或护照号。在 GDPR 下存储这些数据是一项负担，也是攻击者的诱人目标。

合适的 ZK 技术。zk-SNARK 加上由政府钱包或背书方签发的可验证凭证。视电路复杂度选 Groth16 或 PLONK。2026 年欧盟 eIDAS 2.0 钱包的推广让背书一侧越来越可行。

复杂度。中。电路很小。真正的工作量在与背书提供者的集成上。

成本区间。工程师周：4 到 8 周完成生产集成。验证器基础设施成本：可忽略。审计成本：与一家 ZK 专业机构的独立合作。

用例 2：受监管内容的年龄验证

问题。欧盟对成人内容、博彩和某些受监管类目的年龄验证规则在 2024 和 2025 年收紧。在若干司法管辖区，自我声明已不再合规。上传护照是 UX 灾难，也是数据保护风险。

合适的 ZK 技术。一个小电路，从政府签发的凭证中证明“出生年份在 X 之前”。这里 zk-SNARK 常常已经超出需要；范围紧凑、已知背书方的电路提供快速证明与小验证器。

复杂度。低到中，背书源选定后大多是低。

成本区间。单一司法管辖区上线 3 到 6 个工程师周。

用例 3：供应链溯源

问题。你需要证明你的货物经过了认证阶段（原产地、加工、运输、海关），同时不向竞争对手或对方暴露你的具体供应商、贸易路线或商业条款。

合适的 ZK 技术。zk-STARK 因透明（无可信设置）与后量子抗性而被选；如果证明大小比证明时间更重要则用递归 SNARK。证明在各阶段聚合；只有最终验证器看到结果。

复杂度。高。难点是数据模型，不是密码学。让供应商背书才是工作量。

成本区间。覆盖一条产品线的试点 8 到 16 个工程师周。

用例 4：私有凭证

问题。平台希望验证“此用户持有某认证大学学位”或“此用户是持牌专业人士”，无需存储或暴露完整文档。

合适的 ZK 技术。可验证凭证加上一份 ZK 选择性披露证明。zk-SNARK 在此适用。W3C VC 与 BBS+ 签名这类标准天然配对。

复杂度。中。标准已成熟，发证方一侧是摩擦所在。

成本区间。视发证方集成复杂度 4 到 10 个工程师周。

用例 5：机密 ML 推理

问题。用户希望在私有输入上运行一个模型，并相信使用了正确的模型，同时不向模型托管方暴露输入，也不向用户暴露模型权重。

合适的 ZK 技术。zkML 框架。这是本列表的前沿。证明生成很重。适合 30 秒到几分钟的证明时间也可接受的用例。

复杂度。高。诚实定位：2026 年仍是前沿。我们如何对待这种风险请见 bleeding-edge 服务。

成本区间。窄垂直试点 12 到 24 个工程师周。

用例 6：去中心化身份的选择性披露

问题。用户持有一个装着多份凭证的钱包。依赖方只应得知它需要的那个具体属性（驻留、职业、年龄段），不多不少。

合适的 ZK 技术。BBS+ 签名加选择性披露，再加一份可选的派生属性 ZK 谓词证明。在 EVM 一侧与账户抽象钱包配合得很好。

复杂度。中。

成本区间。5 到 10 个工程师周。

六个用例的成本全貌？

"ZK 终于变成了一种集成工具，不再只是仅限加密的研究项目。"

问答：ZK 对 KYC 是杀鸡用牛刀吗？

对某些团队来说是。如果你能把 KYC 外包给受监管的服务商、且自己不存数据，对大多数司法管辖区你已经有了可接受的答案。当下列情况出现时，ZK 才变得有吸引力：(a) 你希望对用户做重复验证而不必再问一遍，(b) 你在 eIDAS 2.0 钱包已上线且用户期望它的司法管辖区运营，或 (c) 一旦你的 KYC 数据库被攻破将危及生存。任一条成立，ZK 都能很快回本。

问答：证明生成实际要花多久？

取决于电路大小与证明器。对 KYC 风格的小电路，证明在现代笔记本上或浏览器 wasm 中需要几百毫秒。对复杂多背书电路，预期几秒。zkML 预期数十秒到几分钟。验证总是便宜，通常低于 100ms。UX 围绕证明器一侧设计，不是验证器一侧。

问答：小团队能在没有密码学家的情况下做吗？

对用例 1、2、4、6 来说，谨慎下可以。工具链（Circom、Noir、Halo2、plonky2、近期的 zkVM）已经成熟到一位强资深工程师集中爬几周坡就能上线一个生产电路。对用例 3 和 5，不行。你需要团队里有密码学专家或一位外部评审，加上一次合规外部审计。需要时我们会引入领域专家。详情请见我们的 零知识服务。

问答：账户抽象和 ZK 一起呢？

强组合。AA 钱包可以把 ZK 证明放进签名逻辑里链上或链下验证。这能解锁“此钱包只有附上新的年龄验证证明才能交易”这种流程。对受监管用户群的 Web3 产品，这已成为 2026 年的标准模式。

问答：需要智能合约参与吗？

不需要。ZK 完全在链下也跑得通。常规 web2 后端可以用一个小型库验证 SNARK 或 STARK。链只在你需要公开、抗审查的验证或与链上逻辑组合时才需要。我们界定过的大多数 KYC 与年龄验证部署是纯链下。