问题所在：数据共享的全有或全无困境
传统的身份验证是全有或全无的：
- 证明你年满 21 岁？ 上传驾照 → 服务方会看到出生日期、姓名、地址、照片、驾照号码
- 证明你有工作？ 共享在职证明信 → 雇主会看到职位、薪资、入职日期、经理姓名
- 证明你有 10 万美元收入？ 上传工资单 → 银行会看到确切薪资、雇主、社保号、扣除项
你无法只证明恰好所需的最小信息。要么”共享一切”，要么”无法验证”。
这造成了隐私噩梦：
- 数据泄露：服务方存储你完整的驾照数据 → 一旦泄露，一切都会暴露
- 监控：每个服务方都知道你确切的出生日期、地址、收入——跨服务方聚合这些信息，你就被画像了
- 责任风险：存储不必要 PII 的服务方将面临 GDPR/CCPA 合规成本和风险
零知识证明（ZKP） 解决了这个问题：一种密码学技术，让你能够在不暴露底层数据的情况下证明某事为真。
什么是零知识证明？
零知识证明 是一种密码学方法，其中：
- 证明者（你）想要证明某件事（例如：“我年满 21 岁”）
- 验证者（服务方）想要核实这是真的
- 零知识：验证者只能得知该陈述为真——除此之外一无所知（不知道你的出生日期，不知道你的姓名）
经典示例：洞穴
想象一个圆形洞穴，有两条路径（A 和 B），在洞穴中央的一扇上锁的门处交汇。你知道打开这扇门的密码。
如何在不透露密码的情况下证明你知道它？
- 你进入洞穴（验证者看不到你走的是哪条路）
- 验证者喊道：“从 A 路出来！”
- 你（若有需要）用密码打开门，从 A 路出来
- 多次重复——如果你每次都能按要求从指定路径出来，验证者就知道你确实持有密码
- 零知识：验证者从未看到密码，只知道你能在洞穴中自由穿行
现实中零知识证明应具备的属性
一个有效的零知识证明必须满足：
- 完备性：如果陈述为真，诚实的证明者能够说服诚实的验证者
- 可靠性：如果陈述为假，任何作弊的证明者都无法说服验证者（除非概率极低）
- 零知识性：验证者除了陈述是否为真之外，得不到任何其他信息
BBS+ 签名：面向可验证凭证的零知识证明
BBS+（Boneh-Boyen-Shacham 签名） 是一种专为选择性披露设计的密码学签名方案——能在不暴露凭证全部字段的情况下证明其中的特定声明。
BBS+ 的工作原理
-
签发者创建带有多个属性的凭证：
{ "name": "Alice", "birthdate": "1998-03-15", "address": "123 Main St", "license_number": "D1234567" } -
签发者使用 BBS+ 签名（生成覆盖所有属性的签名）
-
Alice 将凭证存储在 Affinidi Vault 中
-
服务方请求证明：“证明你年满 21 岁”
-
Alice 创建零知识证明：
- 从凭证推导出证明：“出生日期表明年龄 ≥ 21”
- 该证明仅披露这一声明——不透露实际的出生日期
- 证明包含签名验证信息（确认是签发者签署的）
-
服务方验证证明：
- 检查：签名是否有效？声明是否为真？签发者是否可信？
- 得知：“Alice 年满 21 岁” ✓
- 不会得知：出生日期、姓名、地址、驾照号码
BBS+ 的独特之处
相较于标准数字签名（RSA、ECDSA）：
- 标准签名：对整个凭证进行签名 → 暴露凭证就会暴露所有字段
- BBS+：对单个属性分别签名 → 可以披露一部分，隐藏其余部分
相较于其他零知识证明系统（zk-SNARK、zk-STARK）：
- zk-SNARK/zk-STARK：通用型零知识证明，需要可信初始设置或高强度计算
- BBS+：专为凭证设计，无需可信初始设置，选择性披露效率高
关键优势：
- ✅ 无需可信初始设置（不同于 zk-SNARK）
- ✅ 证明体积小（不论凭证大小如何，约 300 字节）
- ✅ 验证速度快（毫秒级）
- ✅ W3C 标准（用于可验证凭证规范）
- ✅ 不可关联性（来自同一凭证的多个证明无法被相互关联）
实践中的选择性披露
示例 1：年龄验证
场景： 证明你年满 21 岁，以便在线购买酒类。
传统方案：
- 上传驾照照片
- 服务方会看到：出生日期（1998-03-15）、姓名（Alice）、地址（123 Main St）、驾照号码（D1234567）、照片
BBS+ 选择性披露：
- 政府签发带有 BBS+ 签名的驾照凭证
- 服务方请求：“证明年龄 ≥ 21”
- Alice 的 Vault 创建证明：
age_over_21 = true（由出生日期 ≥ 2005-07-22 推导得出） - 服务方验证该证明，只得知：“此人已年满 21 岁” ✓
服务方看不到的内容：
- ❌ 确切的出生日期
- ❌ 姓名
- ❌ 地址
- ❌ 驾照号码
- ❌ 照片
结果： 隐私得到保护，合规要求得到满足，服务方不会因存储不必要的 PII 而面临数据泄露风险。
示例 2：贷款收入验证
场景： 为获得房贷批准，证明收入超过 10 万美元。
传统方案：
- 上传近 3 个月的工资单
- 银行会看到：确切薪资（12 万美元）、雇主名称、社保号、扣除项、年初至今收入
BBS+ 选择性披露：
- 雇主签发带有 BBS+ 签名的收入凭证：
{ "employee": "Alice", "salary": 120000, "employer": "Company X" } - 银行请求：“证明收入 > 10 万美元”
- Alice 的 Vault 创建证明：
income_greater_than_100k = true（由薪资字段推导得出） - 银行验证该证明，只得知：“收入超过 10 万美元” ✓
银行看不到的内容：
- ❌ 确切薪资（12 万美元）
- ❌ 雇主名称
- ❌ 入职日期
- ❌ 职位
结果： 贷款审批得以推进，Alice 的确切薪资保持私密，银行存储的 PII 更少（降低 GDPR 合规风险）。
示例 3：在职经历验证
场景： 证明你曾担任”工程师”职位，而不透露薪资或绩效评级。
传统方案：
- 前雇主提供推荐信
- 新雇主会看到：职位、薪资、绩效评级、离职原因
BBS+ 选择性披露：
- 前雇主签发在职凭证：
{ "employee": "Alice", "title": "Senior Engineer", "salary": 120000, "rating": 4.5, "start": "2020-01-15", "end": "2024-06-30" } - 新雇主请求：“证明你曾担任工程师职位”
- Alice 的 Vault 创建证明：
title = "Senior Engineer"且employment_dates = "2020-01-15 至 2024-06-30" - 新雇主验证该证明，只得知：职位 + 任职日期 ✓
新雇主看不到的内容：
- ❌ 薪资
- ❌ 绩效评级
- ❌ 离职原因
结果： 在职经历得到验证，Alice 自主控制共享内容，前雇主的敏感数据得以保密。
技术深度解析：BBS+ 选择性披露的工作原理
步骤 1：凭证签发
签发者（例如政府、雇主）创建带有 n 个属性的凭证：
属性 = { a₁, a₂, a₃, ..., aₙ }签发者生成 BBS+ 签名：
σ = Sign(sk, {a₁, a₂, a₃, ..., aₙ})其中：
sk= 签发者的私钥σ= BBS+ 签名（覆盖所有属性）
凭证 = { 属性, σ, 签发者 DID }
步骤 2：存储
用户将凭证存储在 Affinidi Vault（设备安全隔区）中。
步骤 3：选择性披露（生成证明）
验证者请求证明某项特定声明：“证明属性 a₃ 满足条件 C”
用户的 Vault 生成零知识证明：
π = Prove(σ, {a₃}, 条件_C)其中：
π= 零知识证明- 证明包含：
- 已披露的属性：
a₃（仅在验证者需要精确值时） - 隐藏的属性：
a₁, a₂, a₄, ..., aₙ（保持保密） - 签名有效性证明（确认这是签发者签署的）
- 条件证明：
C(a₃) = true
- 已披露的属性：
关键属性： 证明 π 不会透露任何关于隐藏属性的信息（甚至连它们的存在与数量都不会透露）。
步骤 4：验证
验证者收到证明 π 并检查：
- 签名是否有效？ 该证明是否源自受信任签发者的有效 BBS+ 签名？
- 条件是否满足？ 披露的数据是否满足所请求的条件？
- 是否未被篡改？ 密码学完整性检查
如果所有检查都通过：声明验证通过 ✓
验证者得知：
- ✅ 声明为真（例如”年龄 > 21”）
- ✅ 由受信任的权威机构签发
- ❌ 关于隐藏属性的任何信息
不可关联性：抵御追踪的隐私保护
问题： 即便有了选择性披露，服务方能否跨多次验证追踪你？
举例：你向服务方 A 和服务方 B 分别证明”年满 21 岁”。它们能否关联这两次证明并确认是同一个人？
BBS+ 提供不可关联性：
- 每个证明都包含随机盲化因子
- 来自同一凭证的两个证明看起来完全不同
- 各服务方无法相互关联证明来追踪用户
结果： 你可以向多个服务方证明相同的声明，而它们并不知道这是你。
注意事项： 如果你披露了身份识别属性（例如姓名），服务方显然可以进行关联。不可关联性防御的是密码学层面的关联——仅凭签名结构本身，服务方无法关联多个证明。
BBS+ 与其他零知识证明系统的对比
| BBS+ (选择性披露) | zk-SNARK | zk-STARK | |
|---|---|---|---|
| 应用场景 | 可验证凭证 | 通用计算 | 通用计算 |
| 可信初始设置 | ❌ 不需要 | ✅ 需要 (每个电路各不相同) | ❌ 不需要 |
| 证明体积 | 约 300 字节 | 约 200 字节 | 约 50-100 KB |
| 证明生成时间 | 快 (毫秒级) | 慢 (数秒) | 中等 (数秒) |
| 验证时间 | 快 (毫秒级) | 快 (毫秒级) | 中等 (毫秒级) |
| 抗量子性 | ❌ 不具备 | ❌ 不具备 | ✅ 具备 |
| 标准化程度 | W3C VC 规范 | 研究阶段 | 研究阶段 |
何时使用 BBS+：
- 需要选择性披露的可验证凭证
- 需要生产就绪的标准化方案
- 需要快速生成/验证证明
- 不希望使用可信初始设置
何时使用 zk-SNARK/zk-STARK：
- 通用计算验证（例如”我运行了这个程序，并得到了这个输出”）
- 需要最小的证明体积 (zk-SNARK)
- 需要抗量子安全性 (zk-STARK)
Affinidi 使用 BBS+，原因如下：
- 符合 W3C 可验证凭证标准
- 无需可信初始设置（任何签发者都可以签名）
- 速度足以支持实时流程（登录、验证）
- 证明体积小，能在移动设备上正常运行
局限性与权衡
1. 验证者必须信任签发者
零知识证明证明”凭证声明 X”为真，而不暴露 X 的具体值——但验证者必须信任签发者：
- 如果政府签发了年龄凭证 → 银行会信任它
- 如果某个随意的网站签发了年龄凭证 → 银行不会信任它
解决方案： 信任注册表（TRQP）实时验证签发者的权威性。
2. 谓词证明能力有限
BBS+ 支持谓词（条件）：
- ✅ 年龄 ≥ 21（比较运算）
- ✅ 收入 > 10 万美元（比较运算）
- ✅ 职位 = “工程师”（相等判断）
- ✅ 日期范围检查（起始日期 ≤ X ≤ 结束日期）
无法证明：
- ❌ 复杂计算（“过去 3 次薪资的平均值 > 9 万美元”）
- ❌ 跨凭证证明（“我从凭证 A 得到的收入 + 从凭证 B 得到的资产 > 50 万美元”）
对于复杂证明，需要使用 zk-SNARK 或应用层逻辑。
3. 不具备抗量子安全性
BBS+ 依赖椭圆曲线配对（与目前大多数密码学方案一样）——容易受到量子计算机的攻击。
后量子 BBS+ 变体 目前正在研究中（基于格的签名方案）。
当前的缓解措施：
- 能够攻破 ECC 的量子计算机预计还需 10-15 年
- 凭证的生命周期较短（数月到数年）
- 当后量子威胁迫在眉睫时，可迁移至新的签名方案
4. 验证者会得知你选择证明的内容
零知识证明会暴露你正在证明的声明：
- 证明”年龄 > 21” → 验证者得知你证明了年龄（虽然不是确切出生日期，但知道年龄与之相关）
- 证明”担任工程师职位” → 验证者得知你的职位（尽管薪资依然被隐藏）
关于你正在证明某事这一事实本身，并不是零知识的。
若追求真正的隐私：不要证明会透露过多背景信息的声明。
Affinidi 技术栈中的 BBS+
BBS+ 的应用位置：
- Elements Services 使用 BBS+ 签名签发凭证
- Affinidi Vault 生成 BBS+ 证明（选择性披露）
- 验证者（应用、服务方）通过 OpenID4VP 验证证明
示例流程（带选择性披露的无密码登录）：
[用户 Alice 登录服务]
↓
服务请求: "证明你是 X 公司的员工"
↓
Alice 的 Vault:
- 持有在职凭证 (姓名、职位、薪资、入职日期)
- 生成 BBS+ 证明: "受雇于 X 公司，职位 = 工程师"
- 隐藏: 薪资、确切入职日期、绩效评级
↓
服务验证该证明:
✓ 签名有效 (X 公司签发的)
✓ 声明为真 (Alice 是员工)
↓
Alice 登录成功——服务方从未看到薪资或完整凭证结果： 无密码认证 + 隐私保护型验证。
真实世界的落地应用
BBS+ 并非纸上谈兵——它已经具备生产就绪能力：
- ✅ W3C 可验证凭证规范将 BBS+ 列为推荐的签名套件
- ✅ 欧盟数字身份钱包架构使用了选择性披露（BBS+ 或等效方案）
- ✅ Affinidi Elements Services 如今已在签发 BBS+ 签名的凭证
- ✅ 多国政府（加拿大、新西兰、新加坡）正在试点将 BBS+ 用于数字身份
证明体积： 约 300 字节（可放入二维码、NFC 标签、URL 参数）
速度： 生成证明约 10 毫秒，验证约 5 毫秒（速度足以支持实时流程）
兼容性： 可在所有平台运行（iOS、Android、Web、嵌入式设备）
快速上手 BBS+ 选择性披露
构建你的第一个选择性披露流程：
- 签发一份带有多个属性的凭证（年龄、姓名、地址）
- 存储在 Affinidi Vault 中（用户自有钱包）
- 请求选择性披露（“证明年龄 > 21”）
- 验证证明（检查签名 + 条件）
文档：
相关资源
技术深度解析
相关解决方案
总结
零知识证明（ZKP） 让你能够在不暴露底层数据的情况下证明某事为真。
BBS+ 签名 为可验证凭证实现了选择性披露：
- 证明”年龄 > 21”而不透露出生日期
- 证明”收入 > 10 万美元”而不透露确切薪资
- 证明”担任工程师职位”而不透露薪资或绩效评级
关键属性：
- ✅ 无需可信初始设置
- ✅ 速度快（毫秒级）
- ✅ 证明体积小（约 300 字节）
- ✅ 不可关联（无法跨多次验证进行追踪）
- ✅ W3C 标准（生产就绪）
权衡取舍：
- ⚠ 仅限于谓词证明（比较、相等判断）
- ⚠ 尚不具备抗量子安全性
- ⚠ 验证者必须信任签发者（可通过信任注册表解决）
Affinidi 使用 BBS+ 的场景：
- Elements Services（凭证签发）
- Affinidi Vault（证明生成）
- OpenID4VP 流程（登录/验证过程中的选择性披露）
结果： 隐私保护型身份验证——只共享所需的内容，不多不少。