为什么仅靠零知识证明不足以保护用户隐私

零知识证明常被描述成隐私保护的完整答案。在公民科技中，这个承诺尤其有吸引力：一个人可以证明自己有资格参与、是唯一的真实个体、超过某个年龄，或居住在某个司法辖区，而无需公开完整身份证件。

这个承诺是真实的，但范围也比听起来更窄。

零知识证明保护的是“证明”本身。它不会自动保护用户的 IP 地址、浏览器指纹、电话号码、电子邮件、钱包实现、设备、操作系统，也不会自动保护围绕证明产生的时间戳和行为信号。如果这些周边层没有被谨慎设计，验证方仍然可能知道用户是谁。

本文改写自 2024 年 9 月向 NGI TrustChain 做的一次演示。核心观点很简单：零知识证明是私密公民参与的重要构件，但用户隐私是一种全栈属性。

为什么公民平台需要身份

并不是所有线上空间都需要身份验证。有些社区完全可以依靠持久化昵称和声誉系统来运作，而不需要正式凭证。

公民参与平台面对的是另一类问题。如果目标是收集有意义的公共意见、抵抗垃圾信息、减少计算宣传，或支持“一人一票”流程，系统就需要某种抗女巫攻击能力。实际场景中，它可能需要确认参与者是真实的人、属于某个相关社区，或符合某条公民资格规则。

抗女巫攻击有多种方式，但各有代价：

生物识别系统可以提供唯一性，但会带来严重的隐私和安全风险。
社交图谱系统在某些场景中有用，但难以规模化，隐私保证也往往较弱。
混合式信任网络适合某些社区，但通常只能提供较弱的唯一性。
政府或机构凭证可以提供更强的保证，但绝不能变成监控层。

这正是自主身份和零知识证明变得有吸引力的地方。它们提供了一种方式：验证资格，同时不要求用户暴露超过必要范围的个人数据。

零知识证明擅长什么

在一个简化的凭证流程中，有三方：

签发方确认某个人的某项事实，并签发凭证。
持有人保存凭证，并决定何时使用它。
验证方检查由该凭证生成的证明。

零知识技术可以让持有人证明某个具体声明，而不透露底层凭证。例如，用户可以证明自己已满 18 岁，而不透露出生日期；也可以证明自己收到了可信签发方的凭证，而不公开凭证的完整内容。

多种技术路线可以支持这个模式。BBS+ 凭证支持选择性披露和不可链接证明。其他方案会把更容易链接的凭证格式“Merkle 化”，再使用 ZK-SNARKs 来提高隐私。通用 zkVM 未来也可能让既有安全凭证上的事实证明更加容易。

这些工具很有价值，因为它们可以在证明层面提供签发方不可链接性。换句话说，签发方不应知道凭证在哪里被使用，同一凭证的不同使用也不应因为证明本身而被轻易关联。

这解决了一个重要问题，但并没有解决所有隐私问题。

威胁模型：从持有人出发

对公民参与来说，隐私模型必须从凭证持有人的角度开始。使用凭证的人必须掌控自己向谁透露什么。

这要求比今天大多数社交平台更严格的威胁模型：

验证方，也就是请求证明的平台，不应被盲目信任。除非系统让这种行为变得困难并可审计，否则它可能一直试图去匿名化用户。
签发方被信任来识别持有人并签发有效凭证，但不应被信任去知道该凭证之后在哪里、何时、为何被使用。
签发方和验证方不应能够通过合谋来识别用户。
专有客户端代码、钱包代码和验证方前端都应被视为风险面，除非它们开源、可检查，并最好经过第三方审计。

这与主流社交媒体模型非常不同。当前模式通常要求用户相信平台会负责任地收集、保存和保护个人数据。互联网平台的历史已经给了用户很多怀疑这种信任的理由。

隐私冰山的其余部分

最常见的错误，是把零知识证明当成整个隐私系统。实际上，证明只是一层。

过度披露

即使证明是用零知识方式生成的，验证方仍可能请求过多、过精确或过稀有的属性。用户也许没有公开完整身份证件，但多个属性组合起来仍然可能识别出这个人。

例如，在一个小社区中，同时证明精确年龄、城市、职业和会员身份，可能已经足以定位某个人。保护隐私的系统应优先使用粗粒度谓词，并坚持最小必要披露。

网络元数据

验证方可以尝试通过 IP 地址、浏览器指纹、设备元数据或请求时间，把证明和用户关联起来。如果证明是从同一个浏览器会话中提交，而该会话又包含登录或邮件验证，那么证明的数学隐私可能已经不再重要。

零知识默认不会隐藏网络层。传输隐私、代理、日志策略和会话隔离同样重要。

Cookie 和数据经纪商

第三方 Cookie、分析脚本、广告标识符和购买的数据，都可能削弱证明隐私。如果验证方在证明流程周围嵌入追踪代码，它可能把匿名证明和已知网页身份关联起来。

对公民平台来说，证明流程应完全避免第三方追踪器。不能一边依赖密码学协议来保护隐私，一边让普通网页基础设施泄露身份。

电子邮件、电话号码和账户恢复

电子邮件和电话号码很方便，但也是强身份标识。如果验证方把它们与零知识证明关联起来，证明就可能成为更大身份画像的一部分。

这并不意味着公民平台永远不能使用邮件或电话。它意味着这些标识符应尽可能与证明事件隔离，只在真正必要时使用，并受到清晰的数据保留政策约束。

永久标识符

如果同一个永久标识符出现在证明周围，零知识证明仍然可能被链接。钱包地址、DID、凭证主体 ID、设备标识符或稳定账户 ID，都可能成为关联抓手。

需要假名性的系统应使用按关系或按场景生成的标识符，而不是通用标识符。默认情况下，用户不应在互不相关的公民空间之间携带同一条轨迹。

时间关联

即使标识符被隐藏，时间也可能暴露关系。验证方可能把证明生成的时刻与另一项请求关联起来，例如登录事件、通知点击或页面加载。

设计者应把时间戳视为敏感数据。批处理、延迟提交、最小化日志，以及认证和证明展示之间的隔离，都可以降低关联风险。

钱包、设备和供应链风险

证明本身可能在密码学上是正确的，但钱包或客户端仍可能泄露敏感数据。专有钱包可能发送遥测。被攻破的 SDK 可能泄露属性。恶意前端可能请求超过用户理解范围的信息。

开源不能神奇地消除这些风险，但闭源会让风险更难检查。对高信任的公民系统而言，开源客户端、可复现构建、独立审计和最小遥测都应被视为核心基础设施。

行为推断

机器学习可以从看似无害的模式中推断身份。写作风格、活动时间、设备行为、位置模式和互动历史，都可能缩小匿名集合。

这也是隐私不能被简化为证明的原因。匿名参与还需要产品、审核和数据保留方面的选择，避免建立不必要的行为档案。

更好的可信匿名证明架构

保护隐私的凭证流程，应以“验证方想知道更多不该知道的信息”为默认假设。

至少，一个使用零知识证明的公民平台应考虑以下原则：

请求满足公民要求的最不精确证明。
避免把证明展示与可识别账户流程混在一起。
除非用例真正需要，不要把电话、邮箱、钱包地址或永久 DID 绑定到证明事件。
让第三方 Cookie、分析和追踪器远离证明流程。
最小化日志，尤其是 IP 地址、时间戳和请求元数据。
需要持续参与时，使用特定场景的假名。
让验证方前端、证明请求逻辑、钱包集成和 SDK 开源并可审计。
让用户能理解证明请求，知道自己正在证明什么、没有透露什么。
防止签发方回调或其他能让签发方知道凭证在哪里被使用的机制。

目标不只是匿名证明，而是可信匿名：用户、审计者和公民社会都能检查平台的隐私承诺是否符合实际行为。

开放挑战

仍有许多困难工作。

首先，用户体验还不够好。大多数人无法理解凭证 schema、选择性披露、证明请求、签发方不可链接性或关联攻击。一个安全产品必须解释隐私属性，而不是要求用户成为密码学家。

第二，凭证生态是碎片化的。BBS+、SD-JWT、移动驾照、护照芯片、Merkle 化凭证和基于 zkVM 的证明都做出不同取舍。公民平台需要互操作性，但不能退回到隐私最弱的共同标准。

第三，抗女巫攻击和隐私仍然存在张力。更强的唯一性往往要求更强的身份依据。挑战在于只验证必要事项，并防止这种验证变成通用身份图谱。

第四，防滥用不应重新制造监控。匿名或假名空间仍需要审核、频率限制和责任机制。这些机制必须被设计成不会悄悄重新识别所有人。

最后，开源是必要但不充分的。发布代码有帮助，但用户还需要可复现构建、独立审计、清晰治理，以及部署层面的保证：他们检查的代码就是实际运行的代码。

结论

零知识证明非常强大。它们让人们无需透露底层数据就能证明事实，也能阻止签发方追踪凭证的使用地点。

但证明并不是整个隐私系统。验证方仍可能攻击周边层：属性、元数据、Cookie、电子邮件、电话号码、永久标识符、时间、钱包、设备和行为模式。

对公民科技来说，这一区分非常重要。如果数字身份成为公共参与的一部分，它不能变成另一种监视公民的方式。零知识证明可以成为答案的一部分，但只有当它位于更广泛的架构中：数据最小化、不可链接、开源可审计，以及用户控制。

实践上的结论很清楚：使用零知识，但不要止步于此。