我这两天翻 @Dusk 的 Citadel 文档，最关心的不是“链上身份”四个字，而是一张资格凭证从申请到使用，中间到底要经过谁。受监管资产需要确认居住地、年龄或投资者资格，但如果每次验证都把整套身份资料交出去，隐私只是从公开链搬回中心化数据库。

Citadel 2 把流程拆成用户、License Provider 和 Service Provider。许可方在线下核验用户、签署属性，再发布加密凭证并登记进合约；用户使用服务时生成持有有效凭证的零知识证明，由合约验证并记录公开 session，再把对应 cookie 交给服务方。服务方仍要决定信任哪些许可方、接受哪些属性以及是否放行。这个设计把“证明有资格”和“公开全部身份”分开了。

可真正难的地方不在第一次签发，而在凭证发生变化之后。如果用户资格过期、监管规则更新、许可提供方撤销授权，旧 session 是否立即失效？服务方离线或索引延迟时，会不会继续接受已经过期的证明？License Provider 掌握多大权限，凭证元数据会不会反过来形成可关联轨迹？这些问题决定它是隐私身份系统，还是多了一层复杂登录。

所以我现在看 #dusk 的身份能力，更想等业务数据：有多少许可方接入，凭证撤销传播要多久，验证失败率如何，用户能否管理分享过的权限。官方目前还写着完整 JavaScript SDK 将稍后提供，说明开发者接入尚未完全成熟。$DUSK 可以为链上动作提供 gas，但需求是否成立，要看 Citadel 能不能把签发、证明、撤销和审计接成闭环。

零知识证明能减少暴露，不会自动解决身份治理。谁签、谁撤、谁承担错误放行责任，才是这套系统最终要回答的问题。