零知识到底用在哪里：zkLogin、协处理器与身份检查

2026-08-12

理解零知识系统，最有效的方式是把每个证明都对应到一个具体声明。证明可以隐藏凭证字段、证明链下计算的结果，或证明某项身份规则已经满足，而不公开底层文件。它不会让每个组件都自动变成无需信任，也不会把一次登录变成通用身份。本文依据 2026 年 8 月 10 日查阅的资料，沿着零知识证明、zkLogin、ZK 协处理器和身份检查的边界展开。

零知识证明到底隐藏了什么

零知识证明是一种让证明者说服验证者相信某个声明为真，同时隐藏选定见证数据的方法。声明可以是签名令牌包含某种关系、程序产生了某个结果，或凭证满足某项规则。证明本身不是声明，而是关于公开输入与私有输入之间关系的证据，并且这项关系由指定电路或程序定义。

这一区分很重要，因为隐私是有选择的。验证者可能看到布尔结果、公开承诺、网络标识、程序标识或时间戳，却看不到私有输入。年龄门槛证明可以隐藏出生日期，但它本身不能证明底层凭证由谁签发、签发者是否可靠，或验证者是否使用了正确政策。

因此，实际问题不是某个产品是否使用 ZK，而是哪些信息公开、哪些信息私有、谁生成见证、哪些密钥或设置参数需要信任，以及谁验证结果。系统即使使用了可靠证明，仍可能依赖 OAuth 提供商、盐服务、索引器、数据可用性层、凭证签发者，或一个选择了薄弱规则的应用。

zkLogin 如何把网页登录绑定到地址

搜索 zkLogin 解释的读者，应先理解身份绑定，而不是先把它当成钱包。Sui 的 zkLogin 使用 OpenID Connect 登录取得签名 JSON Web Token。应用还会生成短期临时密钥对。令牌中的 nonce 由临时公钥、随机数和过期 epoch 构成，因此后续交易会话与这次登录流程相绑定。

Sui 文档把盐服务和证明服务描述为不同的后端角色。盐值与签发者、应用受众和 subject 声明一起参与地址种子推导；只要盐值保持私密，就可以把 OAuth 标识与链上地址解关联。证明服务接收令牌及相关输入并生成 Groth16 证明。该证明会检查提供商签名、nonce 构造、声明值和地址推导之间的关系。

地址和会话密钥有不同的生命周期。只要底层签发者、受众、subject 和用户盐值不变，地址可以保持稳定；临时密钥则会在指定 epoch 过期。用户重新登录后，可以为同一个地址生成新的会话密钥和证明。验证者会在执行交易前检查证明和临时签名。这是一个特定于协议的流程，并不意味着每种社交登录都会产生自托管身份。

信任边界可以从细节中看出来。OAuth 提供商负责认证账户并签署令牌。应用负责前端和临时密钥。盐服务在其设计允许的情况下可能看到敏感输入，证明服务会处理令牌和证明输入。Sui 说明这些服务在自己的视图中可能把身份与盐值关联起来，虽然 JWT 不会发布到链上。因此，隐私结果取决于这些假设，也取决于用户盐值和会话密钥是否受到保护。

ZK 协处理器计算什么

理解 zk coprocessor 这个词，最好把它当成架构问题。协处理器把数据量大或计算量大的任务移到应用链之外，然后返回结果以及证明，说明任务使用了经过认证的输入并执行了声明的计算。在纯 ZK 设计中，验证合约可以检查证明并使用结果，而不必重复完整计算。

Brevis 文档用三个阶段说明这种模式：数据访问、应用计算和结果使用。应用请求历史链上数据，链下证明者运行自定义逻辑，然后把结果与证明提交给链上验证。相同结构可以支持历史活动门槛、成员资格规则、奖励计算或风险标记。证明不会自动证明数据源适当，而是证明系统实际编码并证明的关系。

这和单纯向索引器索取答案不同。未经证明的索引器响应要求合约或用户信任提供数据和计算的一方。ZK 协处理器可以把结果与经过认证的链上数据及电路绑定，从而减少这类信任。但电路、数据承诺、证明系统、验证器和更新流程都会成为需要审查的新组件。

协处理器也不是一个固定的产品功能。Brevis 区分纯 ZK 模式与 coChain 或乐观模式，两者在延迟、成本和挑战机制上不同。RISC Zero 则把可验证计算更一般地描述为：程序输出带有可检查的收据，验证者无需重跑原始计算或看到私有输入。这些资料说明了概念，但每个部署仍需要单独确认声明、输入认证和失败处理。

身份检查的证明边界在哪里

身份检查可以被表示为关于凭证的声明，而不是关于某个人的魔法证明。验证者可以询问签发者是否签署了凭证、凭证是否仍在有效期内、主体是否超过年龄门槛，或文件标识是否出现在撤销列表中。ZK 电路可以隐藏声明不需要的字段，同时只公开应用所需的最小结果。

因此，所谓 zero knowledge identity verification 应拆分为签发者、持有者和验证者角色。W3C 可验证凭证模型把凭证描述为签发者提出的声明，由主体或持有者持有，再以可检查真实性和完整性的机制提交给验证者。W3C DID 描述标识符和验证方法，但标准本身不会因为存在 DID 或凭证格式，就保证现实中的人、组织或文件真实。

以年龄检查为例，证明可以显示经过签名的出生日期早于政策截止日，却不公开日期。它不能自行判断签发者是否可靠地检查过文件、凭证是否属于当前持有者、政策截止日是否适用于某个司法辖区，或凭证是否已经撤销。这些分别属于签发者、绑定、政策和生命周期问题。

制裁、居住地、资质和账户唯一性也有相同边界。电路可以编码签发者属于批准集合且声明满足规则的谓词，但它不能自动修复薄弱的签发者注册表、被盗凭证、被攻破的钱包、错误的源记录或不完整的撤销数据。结果为真，只表示编码的谓词针对所提供输入通过验证，并不表示输入背后的所有现实事实都为真。

隐私是设计选择，不是证明输出

ZK 可以减少披露，但隐私取决于完整流程。验证者仍可能观察公开地址、时间、网络、应用受众、证明频率，或某项政策曾被尝试这一事实。如果应用重复使用标识符或公开承诺，多次提交可能可以关联。元数据可能比电路隐藏的私有见证透露更多信息。

zkLogin 通过盐值和 OpenID 声明展示了这一点。盐值帮助把 OAuth 标识与链上地址解关联，但丢失盐值可能导致地址无法恢复，暴露盐值则可能让 subject 声明可以被关联。OAuth 提供商、前端、盐服务、证明服务和验证者看到的流程片段不同。隐私审查应当画出这些视图，而不是把证明当作一个隐私开关。

对协处理器而言，隐私还取决于原始数据和见证在哪里处理。证明可以让链上验证者在看不到私有输入的情况下检查结果，但链下证明者或数据提供者可能在计算时看到它们。应用还可能公开结果、查询标识、区块范围或承诺。如果需要对证明者也保持机密，可能还需要私有证明、安全执行或加密计算，而不只是公开的 ZK 验证器。

最小披露原则很有用：只证明应用所需的谓词，使用有明确目的的受众或域分隔符，按照协议预期轮换会话材料，并记录保存和关联风险。这些控制不会消除信任，但能让剩余的信任和披露路径可以被审查。

信任模型必须点名哪些角色

先写清楚声明和公开输入。准确记录验证者接受什么、哪些数据被承诺、链上状态或凭证如何认证，以及哪个软件或电路版本生成证明。如果合约可以消费结果，还要记录验证器代码、升级权限、紧急路径和过期数据处理方式。

然后点名参与者。zkLogin 包括 OpenID 提供商、应用、临时密钥持有者、盐服务、证明服务和 Sui 验证者。协处理器还要加入数据源、索引器或轻客户端、证明者、验证器以及任何挑战或质押机制。身份检查还要加入签发者、持有者、钱包或展示层、验证者和撤销或状态服务。图中缺少角色本身就是风险信号。

接着把正确性与可用性和恢复分开。有效证明可能不能及时到达。提供商可能轮换密钥。盐服务可能不可用。凭证可能过期。链重组或最终性规则可能改变输入集合。协处理器的乐观路径可能依赖挑战窗口内有人诚实地提出挑战。这些是运营属性，不是数学证明会自动修复的失败。

最后审查设置和升级假设。Sui 记录了 zkLogin 的 Groth16 通用参考字符串仪式。其他系统可能使用透明证明系统、zkVM 收据、可信设置、委员会、质押层或组合方案。应询问谁可以改变电路、验证器、签发者注册表、提供商列表、数据源或政策。证明即使能正确验证昨天的政策，也可能不适合今天的政策。