下面按论文第 2 部分（系统设计）的结构，把 GeneralDID 的核心设计讲清楚（对应 2.1～2.3）。

---

2 系统设计总体思路

GeneralDID 的系统设计由两块组成：分布式身份管理方案 + 双凭证模型。前者用“唯一 MainID + 多个 UserID”在可监管与不可链接之间取平衡：MainID 用来监督/防 Sybil，多 UserID 用来缓解属性链接的隐私问题；后者用承诺证明与零知识证明保护敏感凭证属性、链上身份数据与加密凭证之间的关联隐私。 (基于区块链的物联网身份管理系统.pdf)

---

2.1 系统架构

角色与链上形态

系统包含 发行者、验证者、用户（持有人）、监管者，总体交互关系见图 2。(基于区块链的物联网身份管理系统.pdf) (基于区块链的物联网身份管理系统.pdf)

• 发行者：在联盟链里由“委员会节点”承担；发行者作为全节点，签署并颁发凭证。(基于区块链的物联网身份管理系统.pdf)
• 验证者：任何 IoT 应用或设备都可以作为验证者；资源受限终端可作为轻节点。(基于区块链的物联网身份管理系统.pdf)
• 监管者：由政府机构/行业联盟等节点组成，负责核验用户注册身份真实性并审计。(基于区块链的物联网身份管理系统.pdf)
• 用户：每个用户持有一对 DID（MainID，UserID）；MainID 在监管场景唯一，UserID 用于日常大量用户场景。(基于区块链的物联网身份管理系统.pdf)

阈值与算法接口

• 采用 T-Shamir 阈值方案：至少选择 $t$ 个节点参与验证事务，增强联盟链下的签发/验证可信性。(基于区块链的物联网身份管理系统.pdf)
• 系统形式化为 Π =（Setup，CreateDID，CreateClaim，CreateCredential，VerifyCredential），并给出了各算法输入输出与关键密码参数（群、双线性映射、SHA-256 哈希、签名方案等）。(基于区块链的物联网身份管理系统.pdf)

---

2.2 分布式身份管理方案（MainID / UserID）

目标：不可链接 + 可监管

论文明确指出：可监管要求追溯真实身份、隐私要求不可链接，两者矛盾；GeneralDID 通过建立 MainID 与 UserID 的映射表，在保证隐私下提供监管，同时抵御 Sybil 与链接攻击。(基于区块链的物联网身份管理系统.pdf)

身份注册与共识流程

• 遵循 W3C DID 思路，构建“1 个 MainID + 多个 UserID”的身份系统；其中 MainID 用 Pedersen 承诺表示：Com := Comm(v,r)=g^v h^r，且随机数 r 会随不同凭证变化。(基于区块链的物联网身份管理系统.pdf)
• 注册步骤（论文列了关键操作）：
  1. IoT 用户/设备客户端发起 MainID 注册请求，并向监管者提交可验证身份证明（如电子身份证、设备 MAC 地址等）；监管者验证并公布结果。(基于区块链的物联网身份管理系统.pdf)
  2. 之后通过 PBFT 共识：主节点广播预准备/准备，备份节点检查并进入准备、提交阶段，收集足够提交信息后回复客户端。(基于区块链的物联网身份管理系统.pdf)
  3. 客户端确认共识达成后获得 MainID，并在本地秘密存储。(基于区块链的物联网身份管理系统.pdf)
  4. 用户可再申请 UserID，并提交 MainID 承诺开启新一轮共识；区别在于 UserID 对网络公开。(基于区块链的物联网身份管理系统.pdf)

“公开令牌”解决监管开承诺的负担

身份验证时，理论上每个凭证随机数都不同，监管者若要“打开承诺”需要对应的 r，全部记录会造成负担；因此系统让用户提供一个可公开验证的令牌 Tk=(pk)^r，使监管者无需存储 r 也能打开承诺并完成证明（文中给出对数等式证明思路），同时支持批量验证。(基于区块链的物联网身份管理系统.pdf)

---

2.3 双凭证模型（明文凭证 + 承诺凭证）

两类凭证定位

• 明文凭证：内容不加密，验证者可直接查看/验证，隐私较弱。
• 加密凭证/承诺凭证：用加密保护敏感信息；文中把加密后的属性称为“承诺属性”，对应的凭证称“承诺凭证”。(基于区块链的物联网身份管理系统.pdf)

承诺属性与声明（claim）

• 承诺凭证中用 Pedersen 承诺对属性加密：对属性值向量加密得到 com = Comm(attv,r)，承诺在计算上不可区分；必要时用户可向验证者披露 v 与 r 来核验一致性。(基于区块链的物联网身份管理系统.pdf)
• 声明支持两种形态：
  • 明文声明：claim_i = {uprop, attv, U}
  • 承诺声明：claim_i = {uprop, com, U} (基于区块链的物联网身份管理系统.pdf)
• 用户对 claim 用私钥签名；未申请 UserID 时用 MainID 私钥，使用 UserID 身份时用 UserID 私钥。(基于区块链的物联网身份管理系统.pdf)

凭证创建与上链策略（哈希 / 承诺）

• 凭证创建前需要共识：发行者对声明共识与验证，分别签名后组合成 ξ，再形成 cred={pkU, claim, ξ}，并由发行者对摘要（哈希或承诺）签名生成 ξI。(基于区块链的物联网身份管理系统.pdf)
• 上链支持两种策略：
  • 哈希上链（隐私要求较弱时）：sc = H(cred,r)，proof=(sc, ξI) 通过合约上链。(基于区块链的物联网身份管理系统.pdf)
  • 承诺上链（属性熵低时防遍历攻击）：用 sc = Comm(cred,r) 替代哈希摘要，更安全。(基于区块链的物联网身份管理系统.pdf)
    系统因此能按隐私/安全需求灵活选择上链方式。(基于区块链的物联网身份管理系统.pdf)

---

如果你想更“落地”一点，我也可以按 “注册→拿到 MainID/UserID→申请凭证→验证凭证” 画一条时序流程，把每一步谁发什么数据、链上记录什么、链下保存什么梳理成一页笔记。

你可以把它理解成：MainID = “可监管的主身份锚点（根身份）”，UserID = “对外使用的多个假名身份（化名/子身份）”；作者把两者“绑成一对”来用，从而兼顾监管与隐私。 (基于区块链的物联网身份管理系统.pdf)

MainID 和 UserID 的区别（用一句话抓住）

• MainID：** 每个用户唯一**，主要给监管/审计/防 Sybil 用；论文里说它在监管过程中是唯一的，并且用 Pedersen 承诺形式隐藏（链上发布承诺，必要时监管方可核验/打开）。 (基于区块链的物联网身份管理系统.pdf)
• UserID：** 一个用户可以有多个**，用于日常应用对外出示；对网络公开，用来降低不同凭证/不同业务之间被“关联（链接攻击）”的风险。 (基于区块链的物联网身份管理系统.pdf)

更形象一点：

• MainID 像“实名主档案号（但平时不直接公开，用承诺藏起来）”
• UserID 像“每个 App/每个场景一个昵称/账号（公开可用，但彼此尽量不容易串起来）”

这俩和 DID 是什么关系？

论文里有两层“DID”的用法：

1) 按 W3C DID 概念：UserID 更像标准 DID

论文在“DID 格式”里给了典型 DID 语法 did:method-name:method-specific-id，并说“每个用户 ID 对应一个 DID 文档（公钥、验证方法等）”。这更符合 UserID=标准 DID 字符串 + DID 文档 的模式。 (基于区块链的物联网身份管理系统.pdf)
而示例凭证里也出现了 uiid: "did:cpp:..." 这种字段，明显就是 DID 字符串。 (基于区块链的物联网身份管理系统.pdf)

2) 在 GeneralDID 系统内部：作者把“一个人的 DID”扩展成 (MainID, UserID) 这一对

论文在系统架构里直接写“每个用户都持有一对 DID（MainID，UserID）”，并在算法 CreateDID 里把 DID = (MainID, UserIDs) 当作输出。也就是说，他们把“用户的身份标识符 DID”定义成一个包含主标识 MainID + 若干假名标识 UserID 的组合结构。 (基于区块链的物联网身份管理系统.pdf)

所以总结：UserID 更贴近标准 W3C DID（可公开、配 DID 文档）；MainID 是系统为了“可监管/抗 Sybil”额外引入的“主锚点”，并通过承诺隐藏；GeneralDID 把二者组合起来当成它的 DID 体系。 (基于区块链的物联网身份管理系统.pdf)

它们分别在什么时候用？

• 注册/监管/KYC/审计：围绕 MainID（但通常是 MainID 的承诺形式在链上/流程里流转）。 (基于区块链的物联网身份管理系统.pdf)
• 日常登录、出示凭证、访问 IoT 应用：用某个 UserID（公开、可多次/多场景创建）。 (基于区块链的物联网身份管理系统.pdf)

如果你愿意，我可以结合论文里的示例凭证字段（miid/uiid/token）把“一次完整的出示与验证”里 MainID/UserID 各自出现在哪一步，按时序画成 6~8 步的流程图式文字版。

下面给你按“一次完整的出示与验证”画成 8 步时序（带你点名 miid / uiid / token 分别在什么时候出现、对应 MainID / UserID 哪一块）。

前置：系统里把用户标识符定义成 DID = (MainID, UserIDs) (基于区块链的物联网身份管理系统.pdf)；样例 VC 里在 basicdata 放了 miid / uiid / token，在 claim 里也有 muid / uuid / token (基于区块链的物联网身份管理系统.pdf)，并且文中明确说 basicdata 加入了 miid 与 uiid (基于区块链的物联网身份管理系统.pdf)。
（从命名与样例格式上，uiid/uuid 对应 UserID（did:...），miid/muid 对应 MainID（十六进制/承诺相关标识）；token 对应监管可用的公开令牌 Tk，见下文。）

---

一次“出示 → 验证”文字版流程图（6–8 步）

1）验证者发起验证（Challenge）
验证者生成挑战 chal 并下发给用户（同时带上访问策略/要验证的属性集合）。验证算法输入里就包含 chal 与 DID (基于区块链的物联网身份管理系统.pdf)。

• 这里：还没用到 miid/uiid/token（只是启动会话）。

2）用户选定本次要用的“假名身份”UserID
用户从自己的一组 UserIDs 中挑一个来对外出示，把它写进样例里的 uiid（DID 字符串那种：did:cpp:...） (基于区块链的物联网身份管理系统.pdf)。

• UserID 出现位置：basicdata.uiid（以及后面 claim 里的 uuid） (基于区块链的物联网身份管理系统.pdf)。

3）用户把“主锚点”MainID 以 miid/muid 的形式带上（用于可监管/抗 Sybil 的那条线）
在样例里，basicdata 里带了 miid (基于区块链的物联网身份管理系统.pdf)，claim 里带了 muid (基于区块链的物联网身份管理系统.pdf)。论文的设计目标是“唯一 MainID + 多 UserID”，所以这一步你可以把它理解为：对外主要用 uiid（UserID），但同时携带一个与 MainID 相关的字段作为可监督锚点（通常会是 MainID 的承诺/映射相关数据）。(基于区块链的物联网身份管理系统.pdf)

• MainID 出现位置：basicdata.miid、claim.muid（样例字段）。

4）用户生成公开令牌 token（Tk），随凭证/声明一起出示
论文在“身份验证”里专门定义了公开可验证令牌：Tk = (pk)^r，并说“只要用户公开令牌，监管者就可以打开承诺，而无需存储随机数 r” (基于区块链的物联网身份管理系统.pdf)。样例凭证中 basicdata.token、claim.token 就是这个 token 字段 (基于区块链的物联网身份管理系统.pdf)。

• token 出现位置：basicdata.token + claim.token（样例）。
• token 的作用：主要给监管/审计那条链路用（第 8 步）。

5）用户对本次要出示的 claim/凭证材料签名（绑定“我确实控制这个 DID”）
文中创建声明时：用户签名 ξU = Sign(skU, claim)，并明确说明：未申请 UserID 时用 MainID 私钥；使用 UserID 身份时用 UserID 私钥 (基于区块链的物联网身份管理系统.pdf)。

• 这一步是 UserID/MainID 在“私钥层面”出现：你选哪个身份出示，就用哪个身份对应私钥签。

6）用户 → 验证者：提交“可验证凭证/出示包”
把以下东西打包发给验证者：
basicdata{miid, uiid, token} + claim{muid, uuid, token, 属性…} + proof/签名…（样例结构就是这么组织的） (基于区块链的物联网身份管理系统.pdf)。

7）验证者做链上/链下验证：验签 + 验策略 + 验凭证有效性
验证算法 VerifyCredential(chal, DID, pkI, cred, T)：验证者根据树结构/策略 T 检查凭证有效性，通过则输出 1 (基于区块链的物联网身份管理系统.pdf)。
同时，凭证侧会涉及发行者/委员会签名与摘要证明：cred = {pkU, claim, ξ}，以及发行者签名的 (sc, ξI) 之类（文中给了创建凭证与证明结构）(基于区块链的物联网身份管理系统.pdf)。

• 这里 uiid/uuid 用于定位用户公钥/验证方法（DID 文档思路）；miid/muid 一般不用于日常公开验证，但会作为可监督锚点存在于材料里。

8）（可选）触发监管/审计：监管者用 token 去“打开/核验”MainID 承诺
当需要追溯或审计时，监管者利用 Tk=(pk)^r 与承诺 Com=Comm(v,r)=g^v h^r 进行证明/核验；文中给了“无需 r 也能证明”的思路（对数等式证明） (基于区块链的物联网身份管理系统.pdf)。

• 这一步里：MainID 的可监管性真正落地，而 UserID 仍然承担日常对外的假名身份。

---

如果你希望我把 miid vs muid、uiid vs uuid 在样例结构里更“对齐”成一张小表（哪个字段更像“元数据层”，哪个更像“声明层”），我也可以按论文的样例 JSON 直接给你标注。

1）这篇论文里的 “DID” 是不是 W3C 标准 DID？

结论是：它一部分“像 W3C DID”，一部分是作者为监管/抗 Sybil 额外加的扩展。 (基于区块链的物联网身份管理系统.pdf)

• UserID 基本就是 W3C DID 的用法
  论文先给了标准 DID 语法 did:method-name:method-specific-id，并说“每个用户 ID 对应一个 DID 文档（公钥、验证方法等）”；样例里 uiid/uuid 也确实是 did:cpp:... 这种 DID 字符串形式。(基于区块链的物联网身份管理系统.pdf)

• MainID 不是 W3C DID 里那个“字符串 DID”的典型形态
  它是系统为了可监管/抗 Sybil引入的“主标识符锚点”，且用 Pedersen 承诺形式表示（Com = Comm(v,r)）并随凭证随机数变化。(基于区块链的物联网身份管理系统.pdf)

• 作者把二者合起来，自己定义了一个“身份结构”
  在系统架构里直接写“每个用户都持有一对 DID（MainID，UserID）”，并在算法里把 DID = (MainID, UserIDs) 当成输出。也就是说：对外互操作更像用 UserID（W3C DID），对内系统用 MainID+UserID 的组合来平衡隐私与监管。 (基于区块链的物联网身份管理系统.pdf)

---

2）按样例字段（miid/uiid/token）画“一次出示→验证”流程图（8 步）

下面这个流程严格对应论文样例 VC 结构：basicdata{miid, uiid, token} + claim{muid, uuid, token, ...} + proof{...} (基于区块链的物联网身份管理系统.pdf)

text
┌──────────────────────┐
│ ① 验证者 Verifier     │
│  发起验证，生成挑战 chal│
└─────────┬────────────┘
          │  chal
          ▼
┌──────────────────────┐
│ ② 用户 Holder         │
│  选择本次对外身份：UserID│
│  → 样例字段：uiid / uuid │
└─────────┬────────────┘
          │
          ▼
┌──────────────────────┐
│ ③ 用户带上“主锚点”MainID │
│  → 样例字段：miid / muid  │
│  （用于可监管/抗 Sybil 的锚）│
└─────────┬────────────┘
          │
          ▼
┌──────────────────────┐
│ ④ 用户生成公开令牌 token │
│  Tk = (pk)^r           │
│  → 样例字段：basicdata.token│
│             claim.token     │
│  作用：监管方无需保存 r 也能核验/打开承诺│
└─────────┬────────────┘
          │
          ▼
┌──────────────────────┐
│ ⑤ 用户组装要出示的材料   │
│  basicdata{miid, uiid, token}│
│  claim{muid, uuid, token, 属性...}│
│  proof{signature/ZKP...}     │
│  并用“所选身份”的私钥签名（用UserID则用UserID私钥）│
└─────────┬────────────┘
          │  VP/VC 出示包
          ▼
┌──────────────────────┐
│ ⑥ 验证者 Verifier      │
│  验签 + 验访问策略 T     │
│  校验发行者签名/链上摘要证明等│
└─────────┬────────────┘
          │ 通过/拒绝
          ▼
┌──────────────────────┐
│ ⑦ 通过：授权访问/完成认证 │
│  拒绝：返回失败原因（策略不满足/签名不合法/凭证无效等）│
└─────────┬────────────┘
          │（可选：触发审计/追责）
          ▼
┌──────────────────────┐
│ ⑧ 监管者 Regulator（可选）│
│  利用 token(Tk) + MainID 承诺逻辑做核验/打开承诺│
│  并通过 MainID↔UserID 映射实现“可监管追溯”│
└──────────────────────┘

如果你想把 miid vs muid、uiid vs uuid 的“为什么在 basicdata 和 claim 里各放一份”也讲清楚，我可以按样例 JSON 的层级逐字段标注它们分别承担“元数据定位/声明主体/审计锚点”的角色。

下面按你这篇《Blockchain-based access control architecture for multi-domain environments》论文的 3.2 Access control architecture process，把“3.2 的过程”用一条主流程 + 4 个子流程（3.2.1～3.2.4）讲清楚。(多域DID.pdf)

---

3.2 总体主流程（Fig. 3 那条大流程在讲什么）

论文把多域环境放进一个联盟链/联邦链里：各域都是链上节点；用户用 DID + 公私钥对证明身份；权限与资源都用 可验证凭证（VC）表达；大部分动作由智能合约自动执行，并把关键哈希/日志写链，便于追溯审计。(多域DID.pdf)

主线分两段：(多域DID.pdf)

1. 域内阶段：用户注册拿 DID；申请权限拿“电子权限凭证”；发布资源拿“电子资源凭证”；凭证存到私有/公共/域内 registry。
2. 跨域访问阶段：用户带着 DID + 权限凭证去请求另一个域的资源；链上合约完成身份认证→权限判定→资源凭证校验→返回资源；把访问日志上链。

---

3.2.1 用户注册（User registration）

目标：让用户进入多域系统时，拿到自己的 DID + 公私钥对。流程是：(多域DID.pdf)

1. User → Blockchain：registerReq(userInfo)（提交域要求的注册信息）
2. Blockchain → Admin：把 userInfo 转给管理员审核
3. Admin：若同意，生成 sig = Sign(ska, Hash(userInfo))，并把自己的 DID、公钥等信息连同 sig 回链
4. Blockchain(合约 registerUser)：生成 didu, pku, sku，生成 DID Document，并把（DID、公钥、加密后的 userInfoHash 等）写链
5. Blockchain → User：registerRes(didu, pku, sku, userInfoHash)（用户拿到 DID 和密钥对）

这里的关键点：DID 是身份标识，密钥对用于后续所有操作签名/认证。(多域DID.pdf)

---

3.2.2 资源管理（Resource management）

这一部分分两块：CPT 创建 + 资源发布（资源凭证）。(多域DID.pdf)

(1) CPT 创建

CPT 可以理解为“某类凭证的 Claim 模板/字段规范”，方便不同域跨域理解数据结构。(多域DID.pdf)

1. Admin → Blockchain：createCptReq(dida, pka, ska, claimStruct)
2. Blockchain(合约 createCpt)：生成 cpt（含签名 proof 等）并写链
3. Blockchain → Admin：createCptRes(cpt)（后续发 VC 时按这个结构填 claim）

(2) 资源发布（Resource release）

资源发布者用 VC 把资源“声明出来”（电子资源凭证）。(多域DID.pdf)

1. User → Blockchain：queryCptReq(cptId) 先取模板
2. Blockchain(合约 queryCpt)：校验 CPT 没被篡改，返回 claimStruct
3. User → Blockchain：releaseReq(didu, pku, sku, resourceInfo)（按模板组织资源数据并提交）
4. Blockchain(合约 createResource)：生成 resourceCredential（由用户私钥对 claim 签名，链上记录其哈希）
5. Blockchain → Registry：存储 resourceCredential（通常放域 registry）
6. Blockchain → User：releaseRes(resourceCredential)

---

3.2.3 权限管理（Authority management / Authorization）

目的：给用户发“电子权限凭证”（permission VC），让他能访问某些资源/服务。(多域DID.pdf)

1. User → Blockchain：authorizeReq(didu, pku, sku, authorityInfo)（也会先查 CPT，论文图里省略了查 CPT 的重复步骤）
2. Blockchain → Admin：把 didu + authorityInfo 给管理员审批
3. Admin：若同意，sig = Sign(ska, Hash(didu || authorityInfo)) 回链（证明“管理员同意授权”）
4. Blockchain(合约 authorize)：同时认证 user 和 admin；验管理员签名 sig；生成 authorityCredential（由管理员私钥签 claim）
5. Blockchain → Registry：把权限凭证存到私有/公共/域 registry（取决于用户或域规则）
6. Blockchain → User：authorizeRes(authorityCredential)（返回凭证 ID 或凭证本体）

---

3.2.4 访问控制（Access control）

这是“真正访问资源”的自动化闭环：认证 → 判权 → 校验资源凭证 → 返回资源 → 记日志。(多域DID.pdf)

1. User → Blockchain：accessReq(didu, pku, sku, credentialId, resourceId, domain)
2. Blockchain(合约 authenticate)：先做身份认证；失败则拒绝（论文还提到可能冻结 DID）
3. Blockchain → Registry：queryCredential(credentialId) 取“电子权限凭证”
4. Blockchain(合约 verifyAuthority)：
   • 检查该凭证哈希是否上链（防伪造）
   • 检查有效期
   • 校验发行者公钥与签名（防篡改）
   • 判断该凭证是否包含访问 resourceId 的权限
     不通过则拒绝，可能冻结该权限凭证
5. Blockchain → Registry：queryResource(resourceId) 取“电子资源凭证”
6. Blockchain(合约 verifyResource)：验证资源凭证真实性/是否被篡改；通过则得到 resource
7. Blockchain(合约 generateLog)：无论允许/拒绝都生成访问日志并写链（用于审计追责）
8. Blockchain → User：accessRes(resource)（或返回失败结果）

---

如果你愿意，我可以把这 3.2 的四个子流程（注册/资源发布/授权/访问）再压缩成一张“消息时序表”（每一步“谁 → 谁：函数(参数)”），方便你直接复述或画图。

下面按你问的 3 个点来讲（都基于《多域DID.pdf》这篇里的 3.2 流程与伪代码）。

---

1) userInfoHash 里一般包含哪些东西？

论文里这个名字其实有点“误导”：在注册合约 registerUser 里，userInfoHash = Encrypt(pku, userInfo)——它不是 hash，而是用用户公钥 pku 把 userInfo 加密后的密文。(多域DID.pdf)

所以它“能包含什么”，取决于 userInfo 里放了什么。论文的表述是：用户提交的是该域要求用于审核/评估的用户信息。(多域DID.pdf)
并且至少可以确定一点：userInfo 里要有 domain 字段，因为 DID 生成直接用到了 userInfo[domain]：didu = "did:" + userInfo[domain] + ":" + generateAddress(pku)。(多域DID.pdf)

更通俗地说：

• userInfo：域 A 要求你填的“注册表单”（它想确认你是谁/你是不是本域成员/你是不是某设备等）。(多域DID.pdf)
• userInfoHash（密文）：把这份“注册表单”用你的公钥加密后，上链存一份“别人看不懂的密文”。(多域DID.pdf)
• 论文也强调 DID Document 本身不应泄露或推断出个人隐私数据，所以隐私类信息更可能是通过这种“加密后上链/备份”的方式存，而不是明文写进 DID Document。(多域DID.pdf)

---

2) CPT、资源、权限三者的关系是什么？

一句话：CPT 就是“凭证里 claim 字段的标准模板/字段字典”，资源凭证和权限凭证都靠 CPT 来对齐结构与含义。

• CPT 的定义：它预先定义不同业务的 Claim 数据结构（例如电子文凭、电子驾照这类），发行/填充凭证时照这个结构来填。(多域DID.pdf)
• 资源发布时：发布者先选一个 CPT，然后按 CPT 规定的 Claim 结构去组织资源数据并签发“资源凭证”。(多域DID.pdf)
• 授权（权限）时：流程里明确写了“类似资源发布，用户也要先 query CPT，拿到权限凭证的 Claim 结构，再填 authorityInfo 发起授权申请”。(多域DID.pdf)
• 跨域为什么离不开 CPT：论文在“跨域数据异构”里说得很直白——不同域数据结构差异大，但 VC 除了 claim 外格式统一；而 claim 的结构和字段含义由 CPT 给出，验证方在跨域验权、取资源时通过查询 CPT 来“读懂 claim”。(多域DID.pdf)

你可以把 CPT 理解成：“资源/权限凭证的 JSON schema + 字段含义说明书”。

---

3) 四个子过程更通俗、并讲清楚“用户生成什么、发给区块链什么”

我按“谁生成什么 → 发给谁什么 → 链上做什么 → 最后用户拿到什么”来写。

3.2.1 用户注册（拿 DID + 密钥对）

用户做什么 / 发什么：

1. 用户 → 区块链：registerReq(userInfo)（提交该域要求的注册信息）(多域DID.pdf)

管理员做什么 / 发什么： 2) 管理员审核通过后：sig = Sign(ska, Hash(userInfo))，把签名等回传链上表示“同意注册”。(多域DID.pdf)

区块链合约做什么： 3) registerUser(...) 会：

• 验管理员身份与签名；
• 生成用户密钥对 (pku, sku)；
• 用 userInfo[domain] 和 pku 派生地址生成 didu；(多域DID.pdf)
• 把 userInfo 用用户公钥加密成 userInfoHash（密文）；(多域DID.pdf)
• 生成 DID Document，并把 didu, pku, userInfoHash 写链。(多域DID.pdf)

用户最终拿到什么： 4) 区块链 → 用户：registerRes(didu, pku, sku, userInfoHash)（DID + 公私钥 + 加密后的注册信息备份）(多域DID.pdf)

---

3.2.2 资源管理（先建 CPT，再发布资源凭证）

(A) 管理员创建 CPT（定义模板）

管理员发什么：

1. 管理员 → 区块链：createCptReq(dida, pka, ska, claimStruct)（把“Claim 模板/结构”提交上链）(多域DID.pdf)

链上做什么 / 返回什么： 2) 区块链合约生成 CPT 并上链，返回 createCptRes(cpt)；后续发 VC 时可以通过查询 CPT 获取 claimStruct。(多域DID.pdf)

(B) 用户发布资源（发“资源凭证”）

用户先拿模板： 3) 用户 → 区块链：queryCptReq(cptId)（我要发布某类资源，先取对应 CPT）(多域DID.pdf)
4) 区块链 → 用户：返回 claimStruct（告诉你 claim 该怎么填）(多域DID.pdf)

用户再发资源： 5) 用户按 claimStruct 组织资源数据，连同自己的 DID/密钥 → 区块链：releaseReq(didu, pku, sku, resourceInfo)(多域DID.pdf)

链上做什么： 6) 区块链合约创建 resourceCredential（资源凭证），里面会把 claim 签名并把凭证哈希写链作为防篡改凭据（伪代码里是 uploadBlockchain(Hash(resourceCredential))）。(多域DID.pdf)
7) 资源凭证存入域 registry，返回给用户。(多域DID.pdf)

---

3.2.3 权限管理（发“权限凭证”）

用户发什么：

1. 用户先 query CPT（论文说这步与资源发布类似），拿到权限凭证的 claimStruct；然后把授权信息填好。(多域DID.pdf)
2. 用户 → 区块链：authorizeReq(didu, pku, sku, authorityInfo)（“我想要某些权限”，并证明我控制该 DID）(多域DID.pdf)

管理员发什么： 3) 区块链把请求转给管理员；管理员同意则签：sig = Sign(ska, Hash(didu || authorityInfo)) 回链。(多域DID.pdf)

链上做什么 / 用户拿到什么： 4) 区块链合约 authorize(...)：同时认证用户与管理员、验管理员签名，通过后生成 authorityCredential（权限凭证），并存入私有/公共/域 registry。(多域DID.pdf)
5) 区块链 → 用户：返回权限凭证（或凭证 ID）。(多域DID.pdf)

---

3.2.4 访问控制（带 DID + 权限凭证去访问资源）

用户发什么：

1. 用户 → 区块链：accessReq(didu, pku, sku, credentialId, resourceId, domain)

• DID+密钥用于身份认证
• credentialId 指向“权限凭证”
• resourceId+domain 指向目标资源在哪个域(多域DID.pdf)

链上做什么： 2) 先 authenticate(didu, pku, sku) 做身份认证；失败可能冻结 DID。(多域DID.pdf)
3) 向 registry 拉取权限凭证：queryCredential(credentialId)，然后合约 verifyAuthority(...) 判断它是否允许访问该 resourceId（不通过会拒绝且可能冻结权限凭证）。(多域DID.pdf)
4) 通过后再去拉取资源凭证：queryResource(resourceId)，合约 verifyResource(...) 校验资源凭证没被篡改，最终返回资源。(多域DID.pdf)
5) 无论成功/失败都 generateLog(...) 写链留痕便于审计追责。(多域DID.pdf)

---

如果你希望我把“资源凭证 claim 里一般会有哪些字段 / 权限凭证 authorityInfo 通常怎么设计（比如 RBAC/ABAC）”也接着说明，我可以结合论文 Appendix 里的 VC/CPT 示例结构继续往下拆。

在这篇《多域DID》的架构里，DID 基本上就是“可被别人看到/可被引用”的公开标识符——但要分清“对谁公开”。

DID 是否公开？谁会知道？

1）对“联盟链/同一条链的参与方”来说：是公开的

论文把 DIDs 归为 blockchain data，并明确写了“记录在区块链里”。(多域DID.pdf)
区块链又是点对点广播、各节点共同维护账本的，所以链上参与节点都能看到这些 DID 记录。(多域DID.pdf)

2）对“你要去访问资源的对方/验证者”来说：你也会主动暴露 DID

因为跨域访问时，用户必须提交 DID 来证明身份与权限：论文写“用户在跨域访问资源时需要提供 DID 和凭证”。

3）对“整个互联网所有人”来说：不一定

这套方案是 consortium blockchain（联盟链） 场景。(多域DID.pdf)
所以一般不是谁都能随便读链；只有加入这条链/能访问链数据的人，以及你交互的验证方，才会知道你的 DID。

---

DID 公开会不会泄露隐私？

论文的思路是：DID / DID Document 公开，但不放隐私数据。

• DID Document 只放“与 DID 相关的信息”（公钥、服务等），并且强调它不会泄露或让人推断出用户隐私。(多域DID.pdf)
• 另外，注册时提交的用户信息不是明文挂在 DID 上：注册合约里把 userInfo 用公钥加密成 userInfoHash 再上链（其实是密文）。(多域DID.pdf)
• 只要各域连到同一条链，就可以“解析/访问 DID Document 的内容”来做跨域认证。(多域DID.pdf)（这也侧面说明 DID Document 预计是可被域间读取的）

---

一句话总结

是的，这篇里的 DID 设计上就是“公开可用的身份标识符”：联盟链节点能看到、你跨域访问时也会提供给对方；但作者通过“DID Document 不含隐私 + userInfo 加密上链”来避免直接隐私泄露。fileciteturn1file10L2-L4(多域DID.pdf)

可以的，但要先把“规则”分两层看：链层规则 vs 业务层规则。

1) 同一条联盟链上，“哪些规则必须一致”？哪些可以不同？

必须一致（链层规则）

这是联盟链自身的共识、交易验证、节点治理这些“底座规则”。论文里说多域环境里“每个域作为节点共同治理联盟链”，并由联盟链委员会负责部署/维护智能合约、做治理工作。(多域DID.pdf) (多域DID.pdf)
这些通常对全网一致，否则账本无法达成一致。

可以不同（业务层规则）

同一条链上可以部署不同的智能合约/同一合约不同参数来表达不同业务规则。论文明确：

• 管理员/域可以“根据服务需求定义所需 CPT”。(多域DID.pdf)
• 权限凭证存哪里也能按“用户需求或域规则”决定（私有/公共/域 registry）。(多域DID.pdf)
• “各域可以指定管理员或用智能合约自动化业务管理”。(多域DID.pdf)

所以：同链 ≠ 同业务政策。同一条链可以容纳“不同域、不同任务、不同权限策略/模板”。

---

2) 你举的例子，在论文里就是标准闭环（同链完成 DID→授权→验权）

你描述的三段流程，论文在 3.2 里基本都写成了智能合约驱动的步骤：

A. 用户请求获得 DID（注册）

用户先向链提交注册请求，链侧合约产出 didu + (pku, sku)。(多域DID.pdf)

B. 获得 DID 后，在同链上获取“任务授权”（权限凭证）

用户提交 authorizeReq(didu, pku, sku, authorityInfo)；管理员审批后签名；链上合约生成 electronic permission credential（权限凭证） 并存入 registry。(多域DID.pdf)

这里的“任务授权”在论文模型里就是 权限凭证里 claim 的内容，它的字段结构通常由 CPT 约定（先 query CPT 再填 authorityInfo）。(多域DID.pdf) (多域DID.pdf)

C. 获得授权后，在同链上验证“这个任务是否被授权”

访问/验权走 accessReq(didu, pku, sku, credentialId, resourceId, domain)：

• 先 authenticate(didu,pku,sku) 做身份认证；(多域DID.pdf)
• 再从 registry 拉取权限凭证 queryCredential(credentialId)；(多域DID.pdf)
• 合约 verifyAuthority(didu, credential, resourceId) 判断“这张权限凭证是否包含访问该 resourceId/任务的权限”；(多域DID.pdf)
• 最后写审计日志 generateLog(...)。(多域DID.pdf)

这正对应你说的：“有人拿 DID → 再拿任务授权 → 再验任务是否授权”，而且都在同一条联盟链的合约流程里完成。(多域DID.pdf)

---

3) 如果你想让“不同用户/不同任务有不同规则”，落到设计上怎么做？

按论文这套思路，最常见是三种“可变点”：

1. 不同 CPT：不同任务类型/资源类型用不同 CPT 定义 claim 字段与含义（相当于不同“规则模板”）。(多域DID.pdf)
2. 不同 authorityInfo 内容：同一 CPT 下，给不同用户发的权限凭证 claim 不同（允许哪些任务/资源、有效期等）。(多域DID.pdf)
3. 不同域的发放与存储策略：不同域可以有不同管理员审批逻辑、不同 registry 存储位置规则。(多域DID.pdf) (多域DID.pdf)

如果你愿意，我可以把“任务=resourceId”的映射方式讲得更具体：比如把“任务凭证/任务发布”也当成 resource credential，然后授权凭证里明确允许执行/领取哪些 taskId（对应 resourceId），这样 verifyAuthority 就能直接判断。

不一定。

在这篇《多域DID》里，“域 A / 域 B”更像组织/管理边界（医院、大学、研究机构这种），它们各自运行联盟链的节点，共同维护同一条联盟链账本 (多域DID.pdf)。联盟链上记录的是 DID、CPT、智能合约、访问日志等“区块链数据” (多域DID.pdf)。

但域内部不要求再搞一条“域内区块链”。域内通常还有一个“registry（凭证/资源库）”来存放可验证数据（资源凭证、权限凭证），这个 registry 的实现方式可以很多样：** 云存储、IPFS，甚至“private chains（私有链）”**都可以 (多域DID.pdf)。

所以你可以这样理解：

• 必选（论文主链）：域 A、域 B 作为节点一起组成/治理同一条联盟链（链上放 DID/CPT/日志等）。(多域DID.pdf) (多域DID.pdf)
• 可选（域内存储）：域 A 自己的“域 registry”可以用私有链来实现（那就相当于域内也有一条链），也可以不用链，用云/IPFS 等。(多域DID.pdf)

如果你愿意，我可以把“联盟链上放什么 vs 域 registry 里放什么”按数据类型（DID、CPT、资源VC、权限VC、日志）列一张对照表。

你的理解非常接近，但需要稍微精确一点。

在这篇 GeneralDID 论文里（《基于区块链的物联网身份管理系统》），所谓“域”并不是链本身，而是：

一个参与联盟链治理的组织单元（例如某机构、行业节点等）。

---

一、域 A / 域 B 是什么？

在系统架构（图 2，系统架构图）里明确写到：

• 有 N 个委员会节点 (c1, c2, …, cN)
• 联盟区块链由这些节点共同维护
• 采用 T-Shamir 阈值方案 + PBFT 共识
• 委员会节点作为“凭证发行者”

📌 也就是说：

联盟链由多个“委员会节点”共同组成
每个域可以拥有一个或多个这样的节点

---

二、那“域内部”是不是区块链？

论文没有说域内部必须再建一条链。

它的结构是：

text
联盟链（GeneralDID 主链）
    ↑
    ├── 域 A（拥有一个或多个委员会节点）
    ├── 域 B（拥有一个或多个委员会节点）
    ├── 域 C …

域本质是：

• 一个组织边界
• 有自己的管理员
• 可能有自己的用户
• 在联盟链上运行节点
• 参与凭证签发和共识

而不是说：

域内部一定再跑一条独立区块链

---

三、那“管理委员会”怎么理解？

你说：

域内是不是多个用户管理者构成了管理委员会？

更准确的说法应该是：

✅ 委员会 = 联盟链上的共识节点集合

论文说：

• 发行者被配置为全节点
• 委员会节点需要达到 t 个才能验证事务（阈值签名）
• 使用 PBFT 共识

所以：

委员会是跨域的，不是域内独立的。

换句话说：

• 域 A 可能有 2 个节点
• 域 B 可能有 3 个节点
• 域 C 可能有 1 个节点

它们一起构成 N 个委员会节点
然后用 PBFT 达成共识

这才是“管理委员会”。

---

四、那域内部是什么结构？

域内部通常包含：

• 普通用户（持有 DID）
• 设备（轻节点）
• 管理员（负责审批）
• 一个或多个区块链全节点（加入联盟链）

可以理解为：

text
域 A
 ├── 用户1
 ├── 用户2
 ├── 设备若干
 └── 区块链节点（加入联盟链）

---

五、总结成一句话

域 ≠ 一条独立区块链
域 = 参与联盟链治理的一个组织单元
委员会 = 所有域的节点共同组成的联盟链共识层

如果你愿意，我可以给你画一张“域—委员会—联盟链”的三层结构示意图，帮你彻底理清。

是的，你理解得基本正确 👍

在 GeneralDID 这篇论文里：

T-Shamir 阈值方案 + PBFT 共识

指的是 ——
联盟链上的多个委员会节点（通常来自不同域）之间
采用的联合签发与共识机制。

我给你拆开讲清楚。

---

一、PBFT 共识 —— 是“联盟链层”的共识

论文第 2.1 节系统架构中写到：

• 假设有 N 个委员会节点 (c1, c2, …, cN)
• 采用 PBFT 共识
• 需要达成共识后才能确认事务（如凭证签发）(基于区块链的物联网身份管理系统.pdf)

PBFT 是典型的：

多个节点之间达成一致
容忍部分恶意节点（拜占庭容错）

所以：

✔ 这是联盟链层面的共识
✔ 是多个域的节点之间的共识
✔ 不是域内部用户之间的共识

---

二、T-Shamir 阈值方案 —— 是“联合签发”的机制

论文明确写到：

需要选择至少 t 个节点验证事务
才能完成签发或验证 (基于区块链的物联网身份管理系统.pdf)

这意味着：

• 不是一个发行者说了算
• 必须至少 t 个委员会节点参与
• 才能生成有效签名

这叫：

阈值签名机制

举个简单例子：

假设：

• 总共有 7 个域节点
• 设置阈值 t = 4

那么：

• 至少 4 个节点同意
• 凭证才算有效

---

三、把两者合在一起怎么理解？

PBFT 解决的是：

“这笔交易是否写入区块？”

T-Shamir 解决的是：

“这张凭证是否有效？”

两者层级不同：

层级	机制	解决什么
区块层	PBFT	区块共识
业务层	阈值签名	多方联合签发凭证

---

四、是不是“多个域之间采用这个方式”？

✔ 是的。

更准确地说：

联盟链上的委员会节点（可能来自不同域）
共同采用 PBFT 共识
并通过 T-Shamir 阈值机制联合签发凭证。

所以结构是：

text
域 A —— 节点1
域 B —— 节点2
域 C —— 节点3
域 D —— 节点4
...
        ↓
  组成联盟链委员会
        ↓
   PBFT 共识
        ↓
  阈值签名发凭证

---

五、关键理解点

域 ≠ 一条链
域 = 一个组织单元

联盟链 = 所有域的委员会节点组成的共识网络

T-Shamir + PBFT 是：

联盟链层的安全保障机制
而不是某个域内部的机制

---

如果你愿意，我可以给你画一张：

• “域 — 委员会节点 — 阈值签名 — PBFT”四层结构图

你会一下子彻底通透这个架构。

这一页里的 claim 就是“凭证里的一条声明/断言”。

在你截图这段定义里，作者把身份注册阶段用到的凭证 $C_d$ 看成由 k 条声明组成：

• $claims=(claim_i)_{i=1}^k$
• 每一条 $claim_i=\{a_i, v_i\}$：
  • $a_i$：这条声明的属性名（比如 name、gender、idNumber、deviceMAC 之类）
  • $v_i$：该属性的属性值（比如 Bob、male、…）

所以你可以把 claim 理解成“属性—值（attribute-value）对”；而 $CS$ 或 $claims$ 就是一组 claim，把用户的“身份先证/注册信息”用结构化的方式表达出来。

对应到论文后面给的可验证凭证示例里，claim 里出现的 "name":"Bob", "gender":"male" 就是典型的 claim（属性=值）实例。(基于区块链的物联网身份管理系统.pdf)

另外，这篇 GeneralDID 在后续把 claim 写得更“身份系统化”一些：它会把一条声明写成带主体关系的三元组，例如 $claim_i=(uprop, attv, U)$（属性、属性值、主体U），或把属性值换成承诺 $com$ 来保护隐私。(基于区块链的物联网身份管理系统.pdf) (基于区块链的物联网身份管理系统.pdf)

可以，把论文里的 claim 当成“对某个主体 $U$ 的属性声明”。论文给了两种写法：明文声明 claim_i = {uprop, attv, U}，以及把属性值用承诺隐藏的承诺声明 claim_i = {uprop, com, U}。(基于区块链的物联网身份管理系统.pdf)

---

例子 1：明文 claim（最直观）

假设主体是用户 Bob（用他的某个标识符/ID 表示为 U），他要声明两条属性：name=Bob、gender=male。

按论文的“明文声明”形式，可以理解成两条 claim：

• $claim_1 = \{\text{name}, \text{"Bob"}, U\}$
• $claim_2 = \{\text{gender}, \text{"male"}, U\}$ (基于区块链的物联网身份管理系统.pdf)

用接近 JSON 的写法（便于看）：

json
{
  "claim": {
    "U": "did:cpp:DDaF300661a5794480B6a1da38658cA867",
    "name": "Bob",
    "gender": "male"
  }
}

这和论文给的样例凭证里 claim 段非常一致：里面就直接出现了 "name":"Bob"、"gender":"male"（同时还带了 uuid/token 等字段）。(基于区块链的物联网身份管理系统.pdf)

---

例子 2：承诺 claim（把属性值藏起来）

如果想隐藏 gender=male 这样的属性值，就把 attv 换成承诺 com：

• 仍然是 $uprop=\text{gender}$
• 但 $attv=\text{"male"}$ 不再明文出现
• 改为 $com = Comm(attv, r)$
• 所以 $claim=\{\text{gender}, com, U\}$ (基于区块链的物联网身份管理系统.pdf)

示意：

json
{
  "claim": {
    "U": "did:cpp:DDaF300661a5794480B6a1da38658cA867",
    "gender_commitment": "Com = Comm(\"male\", r)"
  }
}

如果你愿意，我也可以把样例里的 uuid/muid/token 一起纳入这个例子，解释它们分别是“主体标识/主锚点/公开令牌”在 claim 里的作用位置。

对，不一样：claim 是 VC（可验证凭证）里面的一部分，VC 是“整张证书/凭证”。

• 在《多域DID》这篇里，作者直接写：Verifiable Credential 主要由 Claim 和 Proof 两部分组成；其中 Claim 是“声明内容/陈述部分”，Proof 是发行者对 Claim 的数字签名等验证材料。(多域DID.pdf)
• 在 GeneralDID 这篇里也类似：VC 由元数据（basicdata）、声明（claim）和证明（proof）组成；claim 里放的是具体属性（例如 name、gender 等），proof 里放签名或零知识证明。(基于区块链的物联网身份管理系统.pdf) (基于区块链的物联网身份管理系统.pdf)

用一个直观例子

GeneralDID 的样例 VC 里，整张 VC 结构是 basicdata + claim + proof，其中 claim 只是中间那一段：(基于区块链的物联网身份管理系统.pdf)

json
{
  "basicdata": { "miid": "...", "uiid": "...", "token": "..." },
  "claim": { "name": "Bob", "gender": "male", "uuid": "...", "token": "..." },
  "proof": { "...": "签名/零知识证明相关字段" }
}

所以你可以记成一句话：
VC = “装着声明(claim) + 证明(proof) + 一些元数据”的完整容器；claim = 里面具体讲了什么（属性/事实）的那部分。

不太行——**只剩 basicdata + claim，它就不再是“可验证凭证(VC)”了，只能算“声明数据/自述数据”。**原因是：这两篇论文都把“可验证”的关键放在 proof 上。

1) 只有 claim 和 basicdata 行不行？必须要 proof 吗？

在 GeneralDID 这篇里，作者明确把 VC 定义为 “元数据(basicdata) + 声明(claim) + 证明(proof)”，并且说 proof 就是证书的数字签名或零知识证明。(基于区块链的物联网身份管理系统.pdf) (基于区块链的物联网身份管理系统.pdf)
所以你把 proof 去掉，验证者就少了“我怎么相信这份 claim 没被篡改/确实由某个发行者(或你)签过/确实满足ZKP”的依据——它就不满足论文里的“可验证”。

在《多域DID》那篇也一样：VC 主要由 Claim 和 Proof 构成，proof 的作用就是记录发行者对 claim 的数字签名。(多域DID.pdf)
并且他们后续在验权时会直接检查 credential[proof[publicKey]] 和 credential[proof[proofValue]] 的签名，也就是靠 proof 来验真、防伪造/篡改。(多域DID.pdf)

结论：

• 你当然“可以”只存 claim/basicdata 当业务数据用；
• 但它就不是 VC，也就不能按论文流程做可信验证/防篡改/跨域通用验证。

2) “device VC 能不能改成 claim？”

可以分两种意思：

A) 你只是想让设备少发点数据

那你可以让设备只上送 claim（或 claim+最少元数据）到网关/服务端，然后由网关/管理员/发行者把它“封装成 VC”（补齐 proof）。
因为在论文的设计里，claim 是 VC 的内容部分，proof 才让它可验证。(多域DID.pdf)

B) 你想把“设备凭证”彻底变成 claim（不再有 proof）

那就等于你接受：它只是自声明，别人无法按论文的验签逻辑验证真伪；在多域访问控制里会直接卡住（验权/验资源都要验 proof）。(多域DID.pdf)

如果你告诉我你说的 “device VC” 是 设备身份凭证 还是 设备数据/任务结果凭证，我可以按你那个场景给一个“最省资源但仍可验证”的具体打包格式（比如：设备只签 challenge，网关做 VC proof，链上只存 hash）。

1) “basicdata + claim + proof” 是普遍做法吗？

从思想上挺普遍：一张 VC 基本都要包含三类信息——

• 声明内容（你要表达什么：属性/权限/资源等）
• 元数据（谁签发、给谁、什么时候、生效/过期、类型等，方便流转与解析）
• 可验证性材料（签名/证明，让别人能验证“没被篡改、确实由某发行者背书/确实满足某条件”）

但字段名字和拆分方式不一定统一：

• 在《多域DID》这篇里，直接把 VC 概括为 Claim + Proof（Proof 记录发行者对 Claim 的数字签名）(多域DID.pdf)
• 在 GeneralDID 这篇里，作者把 VC 写成 凭据元数据(basicdata) + 声明(claim) + 证明(proof)，并明确说明 proof 可以是数字签名或零知识证明(基于区块链的物联网身份管理系统.pdf)(基于区块链的物联网身份管理系统.pdf)

所以：“三块内容”很常见，但不一定都叫 basicdata/claim/proof，也不一定都放在同一层字段里。

---

2) 既然 claim 用了承诺（commitment），为什么还要零知识证明（ZKP）？

一句话：承诺只负责“把值藏起来”，ZKP 负责“在不打开承诺的情况下，让验证者相信你满足某个条件/你确实知道里面的值”。

更具体点分三种典型需求：

A. 证明“你确实知道承诺里是什么”，但又不泄露它

GeneralDID 里 claim 可以是承诺声明：claim_i = {uprop, com, U}，com 是对属性值向量的 Pedersen 承诺(基于区块链的物联网身份管理系统.pdf)。
如果没有 ZKP，验证者要确认 com 对应的值，只能让你直接公开 (v, r) 去“打开承诺”，这就泄露隐私了（论文也说只有“必要时”才透露 v 和 r）(基于区块链的物联网身份管理系统.pdf)。
ZKP 的作用就是：不公开 v/r，也能证明“我知道 opening（或知道承诺值）”(基于区块链的物联网身份管理系统.pdf)。

B. 证明“承诺里的值满足某个谓词/条件”

比如年龄≥18、权限属于某集合、属性在某范围内。论文在 ZKP 段落里举了范围证明的例子：证明承诺值 $u$ 落在 $[a,b]$ 区间而不泄露 $u$(基于区块链的物联网身份管理系统.pdf)。
承诺本身做不到“证明范围/集合成员资格”，它只保证隐藏与绑定；谓词证明靠 ZKP。

C. 证明“这份承诺声明/凭证是可信的、没被篡改、且和签发过程绑定”

GeneralDID 明确把 proof 定义为“证书的数字签名或零知识证明”(基于区块链的物联网身份管理系统.pdf)，并且在安全分析里也强调“验证过程是零知识的，不会泄露额外信息”(基于区块链的物联网身份管理系统.pdf)。
也就是说：承诺解决“内容保密”，proof（签名/ZKP）解决“可信可验证”。

---

如果你愿意，我可以拿你前面那段样例 VC（含 miid/uiid/token）再具体举一个“承诺 claim + ZKP proof”的例子：比如证明“gender 的承诺值属于 {male,female} 之一”但不暴露具体是哪一个。

下面给你一个**“最小但完整”**的例子：先把 DID 体系的完整架构讲清楚，再给出 VC 的数据结构（用论文里的字段风格写一个示例 JSON）。

---

A) GeneralDID 的 DID 体系：完整架构（MainID + UserID）

参与角色（谁在系统里）

GeneralDID 的联盟链里有：委员会节点/发行者、验证者、监管者、用户(持有人)，并且假设有 $N$ 个委员会节点；采用 T-Shamir 阈值方案（至少 t 个节点参与）来验证/签发事务。(基于区块链的物联网身份管理系统.pdf)
每个用户持有一对 DID：(MainID, UserID)，其中 MainID 监管场景唯一，UserID 用于日常应用。(基于区块链的物联网身份管理系统.pdf)

标识符长什么样（MainID / UserID）

• 系统把用户标识符形式化为：DID = (MainID, UserIDs)（一个 MainID + 多个 UserID）。(基于区块链的物联网身份管理系统.pdf)
• UserID 是公开的（论文明确说 UserID 对网络公开）。(基于区块链的物联网身份管理系统.pdf)
• MainID 通常以承诺形式参与流程，并通过“公开令牌 Tk”辅助监管打开承诺（论文定义 Tk 并用于打开承诺）。(基于区块链的物联网身份管理系统.pdf)

一张“架构图式”文字版（你脑子里该怎么画）

text
[监管者]  ←(KYC/审计/打开MainID承诺：Tk)→  [联盟链]
                                      ▲
                                      │(PBFT共识 + t-of-N阈值签发)
[用户/设备钱包] ──(注册MainID/申请UserID)───┘
      │
      ├─对外用：UserID (公开) → 给验证者/应用
      └─对内锚点：MainID (唯一/可监管) → 需要时给监管者
[验证者/应用]  ←(出示VC并验证)→  [联盟链/合约/签名验证]

---

B) GeneralDID 的 VC 架构：basicdata + claim + proof

论文把 VC（可验证凭证）写成三段：凭据元数据 basicdata + 声明 claim + 证明 proof，并给了样例（含 miid/uiid/token）。(基于区块链的物联网身份管理系统.pdf)
同时说明：proof 是数字签名或零知识证明。(基于区块链的物联网身份管理系统.pdf)

另外，claim 有两种：

• 明文声明：claim_i = {uprop, attv, U}
• 承诺声明：claim_i = {uprop, com, U}（把属性值用 Pedersen 承诺隐藏）(基于区块链的物联网身份管理系统.pdf)

---

C) 一个“最简单但完整”的示例（DID + VC）

1) 用户/设备的 DID（GeneralDID 口径）

• MainID：系统内部唯一、用于监管
• UserID：公开 DID 字符串（例如 did:cpp:...）(基于区块链的物联网身份管理系统.pdf)

假设设备拿到：

• MainID：0xMAIN...（实际系统里经常以承诺/映射方式用）
• UserID：did:cpp:Thermo01

2) 设备“权限 VC”（沿用论文的字段风格）

下面这个 JSON 结构对齐论文样例：basicdata{miid, uiid, token} + claim{...} + proof{...}(基于区块链的物联网身份管理系统.pdf)

json
{
  "basicdata": {
    "miid": "0xMAIN... (MainID相关标识/承诺锚点)",
    "uiid": "did:cpp:Thermo01 (本次对外使用的UserID)",
    "token": "Tk = (pk)^r (给监管可打开承诺用)"
  },
  "claim": {
    "uuid": "did:cpp:Thermo01",
    "perm": "read:hvac_status",
    "exp": "2026-12-31"
  },
  "proof": {
    "type": "signature-or-zkp",
    "signatureValue": "..."
  }
}

• 这里 claim.perm/exp 只是举例；论文允许 claim 表达任意 属性-值-主体（或属性承诺）关系。(基于区块链的物联网身份管理系统.pdf)
• proof 必须有，因为论文把 proof 作为“可验证性材料”（签名或ZKP）。(基于区块链的物联网身份管理系统.pdf)

---

补一嘴：多域DID那篇的 VC / DID “标准口径”长啥样（方便你对照）

多域DID论文更贴近 W3C 的表述：VC 主要由 Claim + Proof 构成，Proof 记录发行者对 Claim 的签名。(多域DID.pdf)
它还给了 DID Document 示例（有 id、公钥列表、serviceEndpoint）。(多域DID.pdf)
在它的“资源凭证”生成算法里，VC 里会包含 @context/id/type/claim/issuer/issuanceTime/expirationTime/proof(publicKey, proofValue, type...) 这类字段。(多域DID.pdf)

---

如果你想，我可以把上面的例子继续扩成一次完整交互（注册DID → 申请权限VC → 出示给验证者 → 验签/验策略 → 必要时监管用Tk审计），用 6–8 步时序把消息里到底带哪些字段写得一清二楚。

这张图是在讲：信任域 A 里，一个用户 $U^A$ 怎么拿到自己的 DID，同时又做到 (1) 委员会背书“你的身份声明是真的”、(2) 防止同一个身份重复注册（Sybil/重复注册）、(3) 不把敏感值明文写到链上（用承诺隐藏）。

---

图里 4 列分别是谁/是什么

• 用户 $U^A(pk_U^A, sk_U^A)$：域 A 的用户，手里有公私钥。
• 委员会 $C^A$：域 A 的“委员会/管理节点集合”（用阈值签名，多节点共同签）。
• 联盟链 $Bchain'$：图里用于“查重索引”的那条链（存/提供某种索引结构 CBF 给查询）。
• 联盟链 $Bchain_A$：域 A 自己用于生成 DID 与 DID 文档的链（把 $pk_U^A$ 和 DID 绑定进 DID 文档）。

---

关键符号先对齐

• 声明：claim = {a, v}
  • $a$：属性名（比如“身份证号”“学号”“设备序列号”等）
  • $v$：属性值（比如具体号码）
• 阈值签名：
  • $\delta_i^{Oracle} = TS.Sig(claim)$：第 $i$ 个委员会节点对 claim 做的“部分签名”
  • $\delta^{Oracle} = TS.Comb(\delta_i^{Oracle})$：用户把至少 $t$ 份部分签名合成一个“可验证的整体签名”
• Pedersen 承诺：C_v = Pedersen(v, r)
  作用：把 $v$ “藏起来”，链上/外部只看到 $C_v$，不知道 $v$ 是啥（但你之后可以用 $v,r$ 打开它证明一致）。
• $ctx =$ “合法身份”：上下文/类型标签（说明这个声明属于“身份注册”的那类）。
• $C_d^{Oracle} = \{pk_U^A, ctx, claim, \delta^{Oracle}\}$：可以把它理解成“委员会背书过的注册材料包/Oracle 凭证”。

小提醒：图里把 claim 从 {a,v} 改成了 (a, C_v)：意思是 后续查重与上链只用承诺 $C_v$，避免直接暴露 $v$。

---

按步骤把整张图串起来（步骤 1～4）

✅ 步骤 1：用户提交明文声明，委员会用阈值方式“背书它是真的”

1. 用户先构造：claim = {a, v}，发给委员会（图上写“开放信道”）。
2. 委员会选出至少 $t$ 个节点，执行 DECO 协议去验证这个 claim（你可以先把它理解成：委员会用某种可验证方式确认“你提供的 a=v 是真的”，比如来自可信数据源/证明）。
3. 每个参与节点各出一份部分签名：
   $\delta_i^{Oracle} = TS.Sig(claim)$
4. 用户收集到 ≥t 份后合成：
   $\delta^{Oracle} = TS.Comb(\delta_i^{Oracle})$

接着用户做两件事：

• 设 ctx = "合法身份"
• 把敏感值 $v$ 变成承诺：C_v = Pedersen(v, r)，并把 claim 改成：claim = (a, C_v)
• 组装 Oracle 材料包：
  $C_d^{Oracle} = \{pk_U^A, ctx, claim, \delta^{Oracle}\}$
  再发给委员会

---

✅ 步骤 2：委员会做“查重”（防同一身份重复注册）

委员会收到 $C_d^{Oracle}$ 后：

1. 先验证 $C_d^{Oracle}$（至少要能验：这个 $\delta^{Oracle}$ 确实是对 claim 的阈值签名，说明 claim 通过过委员会验证）。
2. 执行 SearchCBF：
   • 根据 claim 里的属性名 $a$，去 $Bchain'$ 上查询对应的 $CBF_a$（图里写“查询与 claim 中的属性 a 对应的 CBFa”）
3. 执行 CheckCBF：
   • 检查 C_v 是否属于 CBF_a
   • 如果 属于：意味着“这个属性值（的承诺表示）以前注册过/疑似重复”，一般应当拒绝或走异常流程
   • 如果 不属于：说明没注册过 → 进入步骤 3

这里的 CBF 从命名上很像“（计数）布隆过滤器 Counting Bloom Filter”一类的集合摘要结构：能高效做 membership 检查，用于“是否已登记过”。（仅根据图中命名推断）

---

✅ 步骤 3：真正生成 DID（在 $Bchain_A$ 上落 DID 文档）

查重通过后：

1. 用户把自己的公钥 $pk_U^A$ 提交给 $Bchain_A$ 上的智能合约
2. $Bchain_A$ 生成：
   • DID（图里例子：did:ethr:...）
   • DID 文档（把 $pk_U^A$ 和 DID 绑定写进去）
3. $Bchain_A$ 把 DID 返回给用户

---

✅ 步骤 4：用户获得 DID（注册完成）

用户收到 DID，即完成身份注册。

---

用一个具体例子帮助你直观理解

假设：

• $a=$ “身份证号”
• $v=$ “6101xxxxxxxxxxxxxx”

流程就是：

1. 把 {身份证号, 6101...} 给委员会验证（DECO），委员会 $t$-of-$n$ 阈值签名背书
2. 把 $v$ 做承诺 $C_v$，委员会去 $Bchain'$ 查 CBF_身份证号，看 $C_v$ 是否已出现过（出现过就认为重复注册风险）
3. 没出现过 → 去 $Bchain_A$ 用公钥生成 DID 与 DID 文档

---

如果你把这张图所在论文的前后两页也截一下（尤其是对 CBF / SearchCBF / CheckCBF / DECO 的文字定义部分），我可以把“CBF 究竟是什么结构、查重失败时怎么处理、是否会更新 CBF_a（把 C_v 加进去）”这些细节也补全到实现级别。

对，你的理解大体正确，但我帮你把“合起来”的对象说得更精确一点（按你图里的符号）。

步骤 1 在做什么（按图逐句翻译）

1. 用户先给委员会发明文声明

   $$claim=\{a, v\}$$

   这里 $a$ 是属性名（比如“身份证号/学号/设备序列号”），$v$ 是属性值。

2. 委员会选出至少 $t$ 个节点跑 DECO 来核验 claim 的真实性
   图里写的是“选择 $t$ 个委员会节点执行 DECO 协议来证明 claim”。意思就是：委员会节点先确认“你这个 $\{a,v\}$ 是真的/符合注册要求”。

3. 每个参与节点各自产生一份“部分签名”

   $$\delta_i^{Oracle} = TS.Sig(claim)$$

   这一步产生的是阈值签名方案里的 share/partial signature，不是最终签名。

4. 用户收集到 ≥t 份部分签名后，把它们“组合”成一个可验证的阈值签名

   $$\delta^{Oracle} = TS.Comb(\delta_i^{Oracle})$$

   你说的“合起来生成有效凭据”，这里更准确是：

   • 用户合成的是 委员会的阈值签名 $\delta^{Oracle}$
   • 这个签名证明“至少 $t$ 个委员会节点认可了该 claim”

⚠️ 关键纠正：这里不是“用户把 $t$ 份签名再和自己的签名合起来”。
图里用户做的是 Comb（组合部分签名），并没有出现“用户再签一遍”的步骤。用户的参与主要是“收集 + 组合”。

5. 用户随后把敏感值 $v$ 变成承诺再封装成一个材料包（Oracle 凭证）
   图里接着写：
   • 生成 ctx = "合法身份"
   • 把 $v$ 做承诺：$$ C_v = Pedersen(v,r) $$$$
   • 把 claim 改成 $(a, C_v)$（以后不直接暴露 $v$）
   • 组装： $$C_d^{Oracle}=\{pk_U^A, ctx, claim, \delta^{Oracle}\}$$
   这个 $C_d^{Oracle}$ 才更像你说的“有效的凭据/背书材料”：它包含用户公钥、上下文、承诺后的 claim，以及委员会阈值签名背书 $\delta^{Oracle}$。

---

用一句话总结步骤 1

DECO 负责“委员会确认 claim 真实”；T-Shamir 负责“至少 $t$ 个委员会节点共同背书”；用户负责“收集部分签名并组合成阈值签名”，然后把 $v$ 承诺化并打包成 $C_d^{Oracle}$。

如果你愿意，我也可以顺着讲你图里的步骤 2/3/4：为什么要去查 CBF_a、CheckCBF 在防什么（重复注册/Sybil），以及最后 Bchain_A 怎么生成 DID 文档。

你这张图里把“身份注册”拆成了两类账本职责，所以画了两条“联盟链”：

1) 两条联盟链分别干什么？为啥要两个？

Bchain_A：发 DID / 存 DID 文档的“域内身份链”

看你截图的步骤 3：用户把公钥 $pk_U^A$ 提交到 Bchain_A 的智能合约，然后生成 DID（例：did:ethr:...）和 DID 文档，并把 $pk_U^A$、DID 写进 DID 文档里，再把 DID 返回给用户。
➡️ 也就是说 Bchain_A 负责“把公钥 ↔ DID”这件事登记下来，属于“身份登记账本”。

Bchain′：做“查重/防重复注册”的“全局索引链”

你截图的步骤 2：委员会在验证 $C_d^{Oracle}$ 后，会去 Bchain′ 查 CBF_a 并做 CheckCBF。
➡️ 也就是说 Bchain′ 不负责发 DID，而是负责提供“是否已注册过”的查询依据（更像索引/登记册）。

为什么要分两条？

从设计动机上通常是三点（结合你图的流程就能解释通）：

1. 职责分离：

   • Bchain_A：专注 DID/DID Doc 的生命周期（注册、解析、更新等）。
   • Bchain′：专注“同一个真实凭证/属性值不要被重复用来注册多个 DID”（去重/防 Sybil）。

2. 降低可链接性：
   你图里把敏感值 $v$ 先做了承诺 $C_v=Pedersen(v,r)$，再拿 $C_v$ 去查 CBF_a；这样做“查重”时不需要把 $v$ 明文广播到发 DID 的那条链上。

3. 系统工程上也常见多账本/多存储：很多架构会把不同数据放在不同存储/链里（例如一些数据放 registry/甚至 private chain），避免所有东西都挤在一个账本里。(多域DID.pdf)

注意：你这张图把两条都叫“联盟链”，更像是“一个全局联盟链（Bchain′）+ 每个信任域一条域链（Bchain_A、Bchain_B…）”这种多链结构。

---

2) “按属性名 a 去 Bchain′ 查 CBF_a” 这一步到底在干嘛？

这一步的目的就是：用属性维度做去重，防止同一个身份凭证被重复注册。

• claim={a,v}：$a$ 是属性名（如身份证号/学号/设备序列号这类“强唯一属性”），$v$ 是属性值。
• 步骤 1 后你把 $v$ 变成了承诺 $C_v$，并把 claim 改成 $(a, C_v)$。
• 到步骤 2：
  1. SearchCBF：根据属性名 $a$，去 Bchain′ 找到对应的过滤器/集合摘要 CBF_a（可以理解为“所有用‘身份证号’注册过的条目集合摘要”）。
  2. CheckCBF：检查 $C_v$ 是否已经在 CBF_a 里出现过。
     • 如果“在”：说明这个属性值（对应的身份凭证）可能以前已经用于注册 → 判定为重复注册风险/拒绝/走人工。
     • 如果“不在”：说明没用过 → 才进入步骤 3 去 Bchain_A 发 DID。

这类“用唯一属性防止 Sybil/重复身份”是很多 DID/身份系统的核心目标之一（你之前那篇 GeneralDID 也把“防 Sybil”作为目标之一）。(基于区块链的物联网身份管理系统.pdf)

---

如果你愿意，我可以再把 CBF 可能是什么（Counting Bloom Filter 的概率型查重）、以及“查重命中时为什么是 可能（误判）”这块也用 3–5 句话讲清楚（一般论文会在后文解释如何处理误判/更新 CBF）。

你理解得对：这套“防同一身份重复注册”的思路，本质就是拿某个（些）身份属性做去重——只不过图里是用 属性名 $a$ 去定位一个“去重索引”（$CBF_a$），再用 **属性值（经处理后的表示）**去做 membership 检查。

下面把你两个问题分别讲清楚。

---

1) 多个属性怎么声明？查重时只查一个关键属性吗？

1.1 多个属性怎么声明

图里为了讲清楚流程，用了最简形式：一条声明

$$claim=\{a,v\}$$

真实系统里一般会是一组声明（claims 列表），每条 claim 是一个“属性名—属性值”对。类似 GeneralDID 文中写的：一个证书可以包含 $m$ 个声明要求 claim={claim1,...,claimm}，每个 claim_i 表达一个属性及其值（明文或承诺）。(基于区块链的物联网身份管理系统.pdf)

所以对应到你这张图，直觉上就是：

$$claims=\{(a_1,v_1),(a_2,v_2),...,(a_m,v_m)\}$$

然后每个 $v_i$ 可能都会被变成承诺 $C_{v_i}$。

1.2 查重时是不是只查一个关键属性就够？

通常是查一个或少数几个“强唯一属性”，原因很现实：

• 强唯一属性：身份证号、学号、设备序列号/IMEI 这类“天然唯一”的字段。用它来查一次，就能把“一个人重复注册多个 DID”基本按住。
• 如果每个属性都查：会带来更多复杂度和误伤（比如地址、昵称这种不唯一属性，查重没有意义；甚至会造成合法用户被误判）。

所以实践上常见两种策略：

1. 单关键属性查重：只用一个最强的 $a^\*$（比如身份证号）建索引、查重。
2. 少数关键属性查重：比如“身份证号 + 手机号/设备序列号”，任意一个命中就拒绝/人工复核。

1.3 你图里“用承诺 $C_v$ 查重”有个隐藏前提

你图里是把 $v$ 变成 $C_v=Pedersen(v,r)$ 然后检查 $C_v \in CBF_a$。

这里要能“查出重复”，必须满足一个前提：同一个 $v$ 在不同注册尝试时，映射到的“用于查重的表示”要一致（或至少可一致比较）。
否则如果每次都换随机数 $r$，同一个 $v$ 会生成不同的 $C_v$，那 CBF 就查不出来“重复”。

所以一般会在“查重用的表示”上做成：

• 要么 对 r 做确定化（例如按规则从 $v$ 派生，或固定 r），
• 要么干脆查重用 Hash(v) 这类确定值，而承诺用于别的隐私证明环节。

（你这篇图的正文如果有解释 “r 怎么处理 / CBF 存什么”，那就能确定它用的是哪一种。）

---

2) 为啥要用 Bchain_A 上链生成/存 DID？委员会 $C^A$ 直接登记不行吗？

2.1 “委员会直接登记”当然可以，但等价于你在信任一个中心化注册处

如果让 $C^A$ 直接维护一份数据库/注册表（DID → 公钥 → DID 文档）：

• ✅ 可以工作
• ❌ 但你必须信任它“永不作恶/不被攻破/不篡改历史记录/对外提供一致视图”
• ❌ 容易回到传统 CA 的“单点风险/中心化”问题（论文也指出传统集中式依赖 CA 容易单点故障，而区块链用去中心化、不可篡改、可追溯来替代这种信任）。(基于区块链的物联网身份管理系统.pdf)

2.2 用 Bchain_A 的核心价值

把 DID 文档写到链（或写哈希到链）主要带来：

• 一致性：所有参与方看到同一份“谁的 DID 对应哪个公钥/文档”的状态
• 不可篡改+可追溯：后续出了争议能审计
• 去中心化治理：尤其当委员会节点是多方组成，且采用阈值/共识时（GeneralDID 里也强调委员会节点在联盟链中做发行者，至少 $t$ 个节点参与验证事务）。(基于区块链的物联网身份管理系统.pdf)

2.3 “委员会上传” vs “必须区块链”——更准确的说法

• **委员会可以作为“提交者”**去调用 Bchain_A 的合约写入（这很常见：链上写入的发起者就是管理员/委员会）。
• 但把最终登记落在链上，是为了让“登记结果”成为全网共同维护的、可验证的公共事实；否则你就得额外设计“如何让其他域/验证者信任并同步委员会那份登记表”。

---

如果你把这张图所在论文/章节（包含对 CBF 的定义、以及是否更新 CBF_a、如何处理误判、r 的取法）再发两页截图，我可以把“它到底查的是 Hash(v) 还是 Commitment(v,r)”和“查重命中后的处理分支”给你补成严格版。

有可能理论上会重复，但要看你这个系统怎么构造 DID 的命名空间。

1) 按 W3C 的语法：是否重复取决于 method-name / method-specific-id

论文里给的 DID 语法是 did:method-name:method-specific-id (基于区块链的物联网身份管理系统.pdf)
所以 “唯一性”默认是在同一个 method-name 命名空间里谈的：

• 如果两个域用不同的 method-name（比如 did:au:... vs did:bu:...），那它们天然就不会撞。
• 如果两个域都用同一个 method-name（比如都用 did:ethr:...），那就要看 method-specific-id 会不会撞。

2) 多域DID这篇里：跨域一般不会撞，因为 DID 里把“域”塞进去了

它的注册算法里直接写了：
didu = "did:" + userInfo[domain] + ":" + generateAddress(pku) (多域DID.pdf)

也就是说 domain 被放在 DID 的第二段（等价于 method-name 的位置），例如：

• 域A：did:DomainA:0xABC...
• 域B：did:DomainB:0xABC...

哪怕 generateAddress(pku) 的结果一样（后面解释为什么几乎不会），只要 domain 不同，整个 DID 也不同。

所以在这篇的默认设计下，“不同域生成同一个 DID”通常不会发生。

3) 那你说的 did:ethr:12345 这种，会不会跨域撞？

如果你真的让多个域都用同一个 method（都用 ethr），并且 method-specific-id 又是那种很短/可重复的编号（比如 12345 这种域内自增），那当然可能撞：

• 域A 也发了 did:ethr:12345
• 域B 也发了 did:ethr:12345

但在多域DID论文的实现里，第三段不是自增号，而是 generateAddress(pku)（从公钥导出的地址）(多域DID.pdf)：

• 想“撞出同一个地址”，基本等价于“生成了同一个公钥/同一个私钥”，随机碰撞概率在密码学上可以认为极低。
• 真出现同地址，更可能是同一主体复用同一把密钥在不同域注册；那反而可能是你想要的“同一 DID 跨域复用”。

你可以怎么确保“绝不撞”

• 像论文这样：把 domain 放进 method-name（did:<domain>:<addr>）(多域DID.pdf)
• 或者如果坚持用 did:ethr：确保 method-specific-id 里带上足够的命名空间信息（至少别用短编号；通常用链/网络标识+地址这种）

如果你把你说的“不同域生成 did:ethr:12345”的具体生成规则（是自增？哈希？地址？）贴一下，我可以帮你判断它在你设计下的“撞号风险”到底有多大，以及怎么改最省事。

你抓到点了：Bchain′ 本来就不需要存 DID，它在这张图里承担的是“查重索引/黑名单（已用过的身份属性）”这一类功能，而不是“身份登记（DID→公钥→DID 文档）”。

---

1) Bchain′ 上没有 DID，那它到底存什么？

从你截图的步骤 2可以看出来，委员会在 Bchain′ 上查的是 $CBF_a$：

• 先从 claim=(a, C_v) 里拿到属性名 $a$（比如“身份证号”“学号”“设备序列号”这种属性类型）
• 去 Bchain′ 上“查询与属性 $a$ 对应的 $CBF_a$”
• 再用 CheckCBF 去检查 $C_v$ 是否已经“属于/存在于”这个 $CBF_a$

所以 Bchain′ 存的不是 DID，也不是完整属性值 v，而是类似下面这种结构：

(属性名 a) → (一个集合摘要/过滤器 CBF_a)
里面记录了“这个属性类型下，已经注册过的那些属性值的某种不可逆表示”（图里用的是承诺 $C_v$）。

它的作用就是：给“是否重复注册”提供一个全局可查询的索引，而不是给你“解析 DID 文档”。

---

2) “根据 claim 里的属性名 a 去 Bchain′ 查询 CBF_a” 这一步是在干嘛？

一句话：定位“查重集合”。

因为系统可能支持很多种可用于注册的属性（身份证号 / 护照号 / 设备 MAC / 学号……），不同属性类型各自维护一份“已使用列表”。所以要先用 $a$ 找到对应那一份：

• SearchCBF：按属性名 $a$ 找到 对应的 CBF_a
• CheckCBF：判断当前这个人提交的 $C_v$（对 v 的承诺）是否已经出现过
  • 出现过 ⇒ 同一个身份凭证可能被重复用来注册（重复注册/Sybil 风险）
  • 没出现过 ⇒ 才进入步骤 3 去 Bchain_A 生成 DID

---

3) 你说“进一步的属性”——这里其实不是“进一步”，而是“索引里按属性类型分桶”

Bchain′ 并不是在存“更多属性信息”，而是存**“某类属性是否已经被用过”**的结构化索引。

顺带一提：在 GeneralDID 这类体系里，声明（claim）本身也可以是多条（一个证书含 m 个声明），每条可以是明文或承诺形式。(基于区块链的物联网身份管理系统.pdf)
所以如果一个注册场景有多个属性，设计上就有两种常见做法：

1. 只选 1 个关键强唯一属性查重（最常见，比如只用身份证号/设备序列号）
2. 对多个强唯一属性都查一遍（比如身份证号 + 手机号，任一命中就拒绝/人工复核）

---

4) 一个关键实现提醒（不影响你理解，但很重要）

你图里用的是 $C_v = Pedersen(v,r)$ 去查重。要让“重复 v 能被查出来”，系统必须保证同一个 v 在查重时得到的表示是可比较/可复现的（例如固定或可派生的 r，或者查重用确定性摘要）。否则如果每次随机换 r，同一个 v 会生成不同 $C_v$，那 CheckCBF 就查不出重复了。

---

如果你把这张图所在论文的**“CBF / SearchCBF / CheckCBF”**文字定义那一段（通常紧挨着图）再截一页，我可以把：

• CBF 到底是不是 Counting Bloom Filter
• 命中后的处理分支（拒绝/人工/更新）
• 成功注册后是否/如何把 $C_v$ 写回更新到 $CBF_a$
  这几处细节给你补成“可实现版本”。

CBF_a 不是“凭空来的”，它一般是 系统在一开始就维护的一份“去重索引”，后续随着注册不断更新。结合你图里的写法（SearchCBF / CheckCBF），最常见、也最符合命名的解释是：

1) CBF_a 是什么

• CBF_a 可以理解为：针对某个属性名 a 的集合摘要/过滤器（常见就是 Counting Bloom Filter / Bloom Filter 一类）。
• 它里面不存 DID，也不存明文属性值 v，而是存“用于去重的表示”（你图里用的是 C_v，即对 v 的 Pedersen 承诺）。

2) 它“从哪来”

通常有两种来源方式（你图的流程更像第 1 种）：

A. 系统初始化时创建（最常见）

• 在系统部署时（或某个属性第一次被用作注册属性时），委员会/链上合约在 Bchain′ 上创建：
  • 一个映射：a -> CBF_a
  • 初始 CBF_a 为空（还没人注册过）。

B. 由历史注册记录“构建/重建”出来（次常见）

• 如果链上保留了所有已登记条目的某种记录（或日志），也可以离线/定期把它们汇总，重新生成 CBF_a 再写回链上。
• 这种更像“维护成本换一致性”，但图里没画出这种重建流程。

3) 它怎么被“填充/更新”

当某个用户注册成功（也就是查重通过、DID 发放完成）后，系统会做一件关键事（图里没画出来，但必须有，不然查重永远查不到“已注册”）：

• 把该用户用于查重的条目插入到 CBF_a 里
  例如插入 C_v（或插入某个确定性摘要）。

下次再有人拿同一个属性值来注册时：

• SearchCBF 找到这个属性的 CBF_a
• CheckCBF 发现“已存在”，就拒绝或转人工复核。

4) 一个你值得注意的点（很关键）

你图里用的是 C_v = Pedersen(v, r) 去查重。如果每次 r 都随机，同一个 v 会对应不同 C_v，那 CheckCBF 就很可能“查不出重复”。

所以实际实现里通常会保证“查重用的表示是可复现/可比较的”，常见做法是：

• 查重用 Hash(v) 这种确定值；承诺用于别的隐私证明环节
  或
• 让查重阶段的 r 可确定化（例如由 v 派生），保证同一 v 产生同一条目

如果你把这张图对应论文里 CBF / SearchCBF / CheckCBF 的文字定义那段也发我（通常紧挨着图），我可以告诉你它到底采用的是哪一种。

你理解接近了，但还差一个关键点：** 域 B 并不是“自己去链上查到某个匿名凭证就放行”**，而是——

域 B 只从联盟链 Bchain′ 取到“当前累加器值 $G_A$”（一坨摘要），然后要求用户提交一个零知识证明 $\pi_e$，证明“我手里那张匿名凭证对应的元素 $e$ 确实被包含在 $G_A$ 里”。验证通过后才给 token，用户再用 token 访问服务。

下面按图里的步骤把逻辑捋顺（你图的步骤 1–6）。

---

这张图在表达的“跨域认证”到底是啥

步骤 1：本域拿“匿名凭证”（cred），但不直接上链

• 用户先算一个假名/化名： $$Nym_U^A = a^{sk_U^A} b^s$$ （目的：跨域时不暴露真实身份/真实公钥，但能绑定“我就是这个凭证持有人”）
• 用户把这个 $Nym$ 发给域 A 的委员会 $C^A$。
• $C^A$ 给这个 $Nym$ 签发匿名凭证：cred=(e,n,s)（图上写“颁布匿名凭证 cred 给 Nym”）。

注意：从图上看，上链的不是 cred 本体，而是后面步骤 2 里的 累加器值 $G_A$。

---

步骤 2：域 A 把“凭证集合的摘要”更新到联盟链 Bchain′

这步是“准备阶段”（图里也写了步骤 1、2 是准备阶段）。

• 域 A 维护一个“全局累加器” $G_A$，它代表“域 A 已签发且有效的匿名凭证集合”的摘要。
• 新发了一些匿名凭证后，会收集新增元素集合 $E_{add}=\{...,e_i,...\}$（图里写 $e_i\in [A,B]_\delta$，通常表示这些 $e_i$ 是按规则挑的数/素数元素）。
• 用这些元素更新累加器，例如图里给的形式： $$G_A = u^{e_1 e_2 \cdots e_n} \bmod N$$
• 然后把包含 $G_A$ 的交易/新区块上传到联盟链 Bchain′（图右侧写“上传 $G_A$ 到联盟链中”）。

所以 Bchain′ 上存的是：最新的 $G_A$（以及可能的更新记录），而不是每个用户的 cred。

---

真正的“跨域认证”是步骤 3–6

步骤 3：用户向域 B 发起服务请求（带 Nym）

用户用 ServiceRequest(Nym_U^A, C^B, SP^B) 去拿到访问请求 request_s，并把请求发给域 B。

直觉上：我用假名 Nym 来申请访问域 B 的某个服务 $SP^B$。

---

步骤 4：域 B 从链上取“最新的 $G_A$”

域 B 取到“当前最新的 $G_A$”（图里写“获取当前的 $G_A$ 用于跨域认证”）。

---

步骤 5：用户生成零知识证明 $\pi_e$：证明“我属于 $G_A$ 里的集合”

用户运行 GenNIZKProof 生成 $\pi_e$，发给域 B。

这个证明要表达的意思是：

我知道某个元素 $e$（它来自我持有的匿名凭证 cred），并且我能证明 $e$ 属于累加器 $G_A$，但我不把 cred / e 的细节直接暴露给你。

这就是零知识证明典型用途：证明“我知道/我满足某条件”，但不泄露秘密细节。你前面那篇 GeneralDID 也用类似表述：证明者可以生成证明，使验证者信服但不泄露信息，并可作为非交互式零知识证明附加/验证。 (基于区块链的物联网身份管理系统.pdf)

---

步骤 6：域 B 验证 $\pi_e$，通过则发 token，用户用 token 访问服务

• 域 B 验证 $\pi_e$（图里写“验证 $\pi_e$，证明属于 e 属于 $G_A$”）
• 验证通过：域 B 发布 token
• 用户用 token 访问 $SP^B$

---

所以你那句话，哪里需要改一下？

你说：

“域A把匿名凭证上传到联盟链bchain'，域B只要查出这个匿名凭证在这个联盟链的累加器上，就认为他是可信的，就让他访问？”

更准确应该是：

1. 域 A 不一定把匿名凭证 cred 上链；它在链上发布的是“凭证集合摘要”——最新的 累加器值 $G_A$（步骤 2）。
2. 域 B 自己没法‘查到某个 cred 在不在’（累加器不是列表/索引），它只能拿到 $G_A$。
3. 必须由用户提交 $\pi_e$ 来证明“我的 cred 对应的元素在 $G_A$ 里”（步骤 5–6）。
4. 验证通过后域 B 才发 token，再用 token 放行访问（步骤 6）。

另外也提醒一句：“在 $G_A$ 里”通常只证明“你是域 A 认可的某个合法成员/凭证未被撤销”；至于你是否有访问 $SP^B$ 的更细权限，很多方案会把它绑定在 request / token 里，或还要叠加域 B 自己的授权策略（图里用 token 作为最终访问凭据，暗示这里还有“授权/会话控制”的意思）。

如果你愿意，我可以把这张图里的每个符号（$e,n,s$、$u,N$、$E_{add}$、$[A,B]_\delta$、$\pi_e$）分别“在协议里扮演什么角色”再做一张对照表，读起来会更顺。

是的——按你这张“累加器 + 匿名凭证 + NIZK”的跨域认证流程图来看，域 B 默认只能学到一件事：

“这个请求者持有域 A 认可的一张有效匿名凭证（对应的元素在 $G_A$ 里）”
也就是“合法成员/未被撤销（在集合内）”这一类成员资格证明。

它并不会自动得到 DID，更不会自动读到“DID 文档里有什么属性”。（因为这套协议本身就不以 DID 为核心，而是以 Nym + 匿名凭证 cred + 证明 $\pi_e$ 为核心。）

---

那域 B 想知道“某些属性”，还能实现吗？

**可以，但需要在“成员资格证明”之外再加一层“属性证明/属性凭证”。**仅靠“我在累加器里”这一句，域 B 只能判断“你是 A 的合法人”，不能判断“你具备某种属性”。

常见有 3 种做法（从最贴近你图的方式开始）：

方案 1：匿名凭证本身就带属性，用 ZKP 做“选择性披露/谓词证明”

把 cred 做成“属性型匿名凭证”（类似 Idemix 思路）：

• 域 A 给用户签发匿名凭证时，把属性一起写进去（比如：role=doctor、org=A-hospital、level>=3 等）。
• 用户跨域时，不给域 B 看明文属性，而是给 零知识证明：
  • 证明“我的凭证里包含 role=doctor”
  • 或证明“age ≥ 18”（范围证明）
• 域 B 验证通过就放行/发 token。

这和 GeneralDID 里“承诺隐藏属性 + ZKP 证明满足条件”的思路是一致的：承诺负责隐藏，ZKP 负责证明性质（例如范围证明、我知道承诺的 opening 等）。(基于区块链的物联网身份管理系统.pdf)

✅ 优点：域 B 能获得“你满足某条件”，但不必知道你是谁、也不必知道全部属性。
⚠️ 代价：实现复杂度与计算量更高。

---

方案 2：继续用你图里的“成员资格证明”，但另外出示一张“属性 VC”

也就是把“跨域认证”和“属性披露”拆成两件事：

1. 你按图走：用 $\pi_e$ 证明“我属于域 A 的合法集合 $G_A$”→ 域 B 信你是“合法成员”。
2. 同时你再给域 B 一张属性 VC/权限 VC，只包含域 B 关心的字段（比如 role=doctor、licenseValid=true），域 B 验签即可。多域DID那篇就强调：VC 的 claim 记录具体业务字段，proof 记录签名；跨域时通过 CPT 让对方理解 claim 字段含义。(多域DID.pdf)

如果还想保护隐私：属性 VC 也可以做成“承诺 claim + ZKP proof”（只证明必要字段/谓词），不必把全部属性摊开。(基于区块链的物联网身份管理系统.pdf)

✅ 优点：工程上最直观、最模块化（认证一套、属性/权限一套）。
⚠️ 关键点：域 B 必须信任 VC 的发行者（比如信任域 A 的委员会，或信任联盟链委员会）。

---

方案 3：用“对偶身份/成对标识”（pairwise DID 或每域一套化名）

如果域 B 确实需要 DID 体系里的解析能力（比如要走 DID Document、服务端点等），但又不想把跨域行为关联回真实身份：

• 给域 B 用一个只在 B 域出现的 DID_B（或化名），与 A 域的 DID_A 不可关联；
• 属性通过 VC（或 ZKP）提供；
• 必要时由监管方做“可追溯但默认匿名”的揭示。

多域DID那篇的默认模型是“跨域要提供 DID + VC”，但同时强调 DID 文档不应泄露隐私、用户信息可加密上链。(多域DID.pdf)

✅ 优点：兼容 DID 生态（解析 DID 文档、服务发现）。
⚠️ 缺点：要额外设计“不可链接”机制（pairwise/一事一ID）。

---

最关键的一句话

• 你图里的方案：本质是“成员资格（在集合里）→ 发 token”。它默认不提供 DID 细节，也不提供属性细节。
• 域 B 想要属性：完全可以，但要么让“匿名凭证携带属性并用 ZKP 证明”，要么“额外出示属性 VC（可选择性披露/承诺+ZKP）”，两者都能在不暴露真实身份的情况下做到。

如果你告诉我“域 B 想知道的属性”是哪一类（角色/资质/年龄范围/组织归属/设备类型等），我可以给你选一个最简单的落地组合，并把“请求里带哪些字段、域 B 具体验证哪些东西”写成 6–8 步的时序。

不行，一般情况下你不能“只改 claim 然后自己把 proof 也改掉”——因为论文里这两类体系都把 proof 当成“发行者对 claim 的签名/证明”，它的作用就是防篡改。

1) 在《多域DID》这篇的模型里：你删字段＝签名失效

论文把 VC 说成 Claim + Proof，其中 Proof 就是“发行者对 Claim 的数字签名”。(多域DID.pdf)
而它的凭证生成算法里也写得很直：proof[proofValue] = Sign(sku, Hash(claim)) ——也就是签名直接签在 Hash(claim) 上。(多域DID.pdf)
验证时会专门去验这个 proof，确保凭证没被篡改。(多域DID.pdf)

所以如果原 claim 里有：

• 身份证号
• 用户等级

你把“身份证号”删掉，只留“等级”，那么 Hash(claim) 变了，原来的 proof 立刻验不过。proof 你也没法“自己重算”，因为那需要发行者私钥。

✅ 在这个模型下想“只出示等级”，通常只有两条路：

1. 让发行者给你重新签发一张只包含等级的 VC（或者把身份证号和等级拆成两张 VC）。
2. 体系本身换成“支持选择性披露/派生证明”的 VC 机制（下面说）。

---

2) 在 GeneralDID（你前面那篇）里：可以“只透露部分”，但靠的是 ZKP/承诺，不是“改原 proof”

GeneralDID 明确写：VC 由 basicdata + claim + proof 组成，且 proof 可以是数字签名或零知识证明。(基于区块链的物联网身份管理系统.pdf)
并且它的零知识证明部分说得很清楚：证明者可以生成 NIZK 证明，“附加到凭证中/账本中”，让任何验证者验证，同时不泄露秘密信息。(基于区块链的物联网身份管理系统.pdf)
另外它支持把属性做成承诺：claim_i = {uprop, com, U}（把属性值藏起来）。(基于区块链的物联网身份管理系统.pdf)

这意味着“只出示等级”的正确做法是：

• 原 VC 不改（里面可能有身份证号的承诺、等级的明文或承诺）
• 你在出示时额外生成一个 proof（ZKP/派生证明），证明“我的等级=X / ≥X”，但不 раскры身份证号
• 验证者验证你给的 ZKP + 发行者对承诺/摘要的签名即可

---

给你一个超简单例子（对应“身份证号 + 用户等级，只出示等级”）

假设发行时 claim 里变成两条承诺：

• com_id = Comm(idNumber, r1)（身份证号承诺，不公开）
• com_level = Comm(level, r2)（等级承诺）

发行者签名的是整个 claim（里面含 com_id、com_level）。

出示时你给验证者：

• 公开 level：同时给出 (level, r2) 让对方能打开 com_level 验证一致
• 不公开身份证号：只给 com_id（不给 (idNumber, r1)）
• 再给一个 ZKP：证明“我确实知道 com_id 的 opening”（或证明它与同一主体绑定），但不泄露身份证号本身

这样验证者能确认：

• 你的“等级”是真的（因为能打开 com_level 且发行者签过）
• 你确实是这张凭证的合法持有人/同一主体（靠 ZKP/签名体系）
• 但看不到身份证号

---

一句话总结

• 在多域DID那篇（SM2 对 Hash(claim) 签名）里：你想只出示等级，不能改 proof；要么拆分签发，要么换成支持选择性披露的机制。
• 在 GeneralDID 那种“承诺 + ZKP”里：可以只透露部分，但做法是保持原 VC 不动，出示时生成额外的 ZKP/派生证明。

如果你把你当前 VC 的具体字段结构（claim 里有哪些字段、哪些敏感）贴一下，我可以按“最少改动”的方式告诉你：是更适合“拆成两张 VC”，还是“改成承诺+ZKP”那种呈现方式。

不是同一件事：ZKP 通常不需要用到 DID 的私钥；DID 私钥更多是用来“签名”，证明你是这个 DID/凭证的持有人。

论文里这两类“证明”分别靠什么秘密量

• 数字签名（Signature）：用 DID 对应的私钥 skU 来签。论文明确写了用户会用自己的私钥对声明 claim 签名，且 skU 可能是 MainID 或 UserID 对应的私钥。 (基于区块链的物联网身份管理系统.pdf)
  另外在验证阶段，用户还会用私钥去签“验证者的挑战”。 (基于区块链的物联网身份管理系统.pdf)
• 零知识证明（ZKP）：用的是你“知道某个秘密信息”的见证(witness)。论文举的例子是：证明者掌握承诺的初始值（也就是承诺的 opening），能在不泄露信息 $v$ 的情况下让验证者相信。 (基于区块链的物联网身份管理系统.pdf)

所以：

• 如果你的 ZKP 是“证明我知道承诺 $Com=Comm(v,r)$ 的 opening”，那 witness 是 $(v,r)$（比如身份证号 idNumber 和随机数 r1），而不是 DID 私钥。 (基于区块链的物联网身份管理系统.pdf)
• DID 私钥更多用在“我控制这个身份”的签名环节（签 claim / 签挑战）。 (基于区块链的物联网身份管理系统.pdf) (基于区块链的物联网身份管理系统.pdf)

---

回到你的例子：claim 里有「身份证号、用户等级」，我只想出示“用户等级”，proof 怎么弄？

在 GeneralDID 这种“承诺 + ZKP”的思路里，常见做法是：

1. 身份证号做承诺：com_id = Comm(idNumber, r1)（不公开 idNumber,r1）
2. 等级要么明文，要么也做承诺：
   • 明文：直接给 level=VIP3
   • 承诺：给 com_level = Comm(level, r2)，并公开 (level, r2) 让对方能打开它核对一致性（论文说“必要时可透露 v 和 r 给验证者核验一致性”）。 (基于区块链的物联网身份管理系统.pdf)
3. proof 分两层：
   • 发行者/委员会对整张凭证的签名（VC 自带的 proof，不改它）——否则你自己改 claim 会导致验签不通过（proof 里可以是数字签名或 ZKP）。 (基于区块链的物联网身份管理系统.pdf)
   • 你额外生成一个 ZKP：证明“我确实知道 com_id 的 opening（idNumber,r1）”但不泄露身份证号。这个 ZKP 用的秘密就是 (idNumber,r1)，不是 DID 私钥。 (基于区块链的物联网身份管理系统.pdf)
4. 再用 DID 私钥签验证者挑战（把这次出示绑定到“你确实是持有人”）。 (基于区块链的物联网身份管理系统.pdf)

一句话记忆：

• ZKP 证明“我知道承诺里的秘密/满足条件”（witness 通常是承诺 opening）。
• DID 私钥签名证明“我就是这个身份/凭证的持有人”。

如果你把你现在 VC 的 claim 具体长什么样（字段列表、哪些想隐藏、哪些要展示）贴一下，我可以按这个论文口径给你写一个更贴近实现的“出示包 VP”结构：哪些字段原样带、哪些字段用承诺、ZKP 证明语句写成什么形式。

下面给你一个**“低空多域异构互联”场景下的 DID 完整体系（强调：跨域用设备时尽量匿名，但其他域仍能拿到设备能力用于派单）。我把它按你图里的 三层盒子形式分别写： DID 体系架构**、设备能力 VC 架构，并用两篇论文的机制拼起来（多域联盟链 + GeneralDID 的 MainID/UserID、承诺与 ZKP）。

---

① DID 体系完整架构（低空多域异构互联）

多域思路：多个域（例如城市A空管/运营商A、城市B空管/运营商B、应急域C、监管域R）作为节点加入同一条联盟链；跨域访问时需要出示 DID 和 VC，由合约自动做身份与权限判断。(多域DID.pdf)

text
DID体系完整架构（低空多域异构互联）

┌─────────────────────────────────────────────────────────────┐
│ 1. 标识层：DID（我是谁）                                      │  ← 必须
│                                                             │
│  (A) MainID：设备“根身份锚点”（可监管、抗Sybil）               │
│      - 每台设备唯一；监管需要时可追溯                           │
│      - 链上通常不直接放明文，而是放承诺 Com=Comm(v,r)           │
│      - 用户注册/验证时可提供公开令牌 Tk=(pk)^r 供监管打开承诺    │
│        （免存 r）                                              │
│                                                             │
│  (B) UserID：跨域/跨任务“假名DID”（对外匿名使用）               │
│      - 设备在每个域、甚至每次任务都生成一个新的 UserID_x         │
│      - UserID 对网络公开，用于日常应用与跨域交互                 │
│                                                             │
│  例：MainID(仅监管) = Com=Comm(v,r)                            │
│      UserID_B(在域B用) = did:lowsky-b:0x9f...                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘
  依据：系统定义 DID=(MainID, UserIDs)，MainID唯一、UserID适用日常场景(基于区块链的物联网身份管理系统.pdf)
       UserID 对网络公开(基于区块链的物联网身份管理系统.pdf)
       Tk=(pk)^r 用于打开 MainID 承诺(基于区块链的物联网身份管理系统.pdf)

┌─────────────────────────────────────────────────────────────┐
│ 2. 文档层：DID Document（我的公钥/端点）                        │  ← 必须
│                                                             │
│  - 每个 UserID_x 都有一个 DID Document：                        │
│      publicKeyList：该假名身份的验签公钥                         │
│      serviceEndpoint：该域可用的通信/任务接口（如C2/任务API）     │
│  - 跨域时，只要各域连同一条链，就能解析 DID Document 并读取内容     │
│                                                             │
│  (示意字段，参考论文附录)                                      │
│  { "id": "did:au:0x...",                                       │
│    "publicKeyList":[{"type":"SM2","publicKey":"..."}],         │
│    "service":[{"type":"Domain-B UTM","serviceEndpoint":"..."}] }│
│                                                             │
└─────────────────────────────────────────────────────────────┘
  依据：DID 可解析为 DID Document，记录公钥列表与服务等(多域DID.pdf)
       附录示例包含 publicKeyList 与 serviceEndpoint(多域DID.pdf)
       同链可跨域映射/访问 DID Document 内容(多域DID.pdf)

┌─────────────────────────────────────────────────────────────┐
│ 3. 凭证层：VC（我的“能力属性/资质”）                             │  ← 可选但本场景强烈建议
│                                                             │
│  - 域B在派任务前，需要知道设备能力（可靠等级、关键能力等级、       │
│    能力边界、合规约束），这些用“设备能力VC”表达                    │
│  - VC 的核心是 claim + proof：claim放业务字段，proof放发行者签名   │
│  - 为了匿名：claim 里不放 MainID/真实身份，只绑定当前 UserID_B     │
│    并支持“选择性披露/谓词证明（ZKP）”——只让域B看到必要能力字段      │
│                                                             │
└─────────────────────────────────────────────────────────────┘
  依据：VC 由 Claim 和 Proof 构成，Proof 记录发行者对 Claim 的签名(多域DID.pdf)
       GeneralDID 也给出“元数据basicdata + 声明claim + 证明proof”，proof可为签名或ZKP3(基于区块链的物联网身份管理系统.pdf)

---

② 设备能力 VC 架构（只证明能力，用于跨域派单）

多域环境里，各域数据结构不一样，所以建议像论文那样用 CPT 预定义 claim 的字段结构与含义，让别的域“读得懂”。(多域DID.pdf)

text
设备能力VC（DeviceCapabilityVC）结构

┌─────────────────────────────────────────────────────────────┐
│ 1) Claim（能力声明：域B关心的字段）                               │
│   - subjectDid：当前跨域假名 UserID_B（只绑定“本次/本域身份”）      │
│   - reliabilityLevel：设备可靠等级（例：R3）                        │
│   - keyCapabilityLevel：关键能力等级（例：C2：夜航/载荷/续航等级）   │
│   - capabilityBoundary：能力边界（例：最大载重、航程、风速上限…）    │
│   - complianceConstraints：合规约束（例：仅VLOS/禁飞区规则/频段…）   │
│   - (可选) com_xxx：对某些敏感字段做承诺（不想全 раскры时）          │
│      claim_i 可是明文 {uprop, attv, U}，也可用承诺 {uprop, com, U}   │
│                                                                     │
└─────────────────────────────────────────────────────────────┘
  依据：claim 可为明文声明或承诺声明(基于区块链的物联网身份管理系统.pdf)

┌─────────────────────────────────────────────────────────────┐
│ 2) Proof（可验证性：发行者签名 + 可选ZKP）                         │
│   - issuerSignature：发行者对 Hash(claim) 的签名                     │
│      proofValue = Sign(sk_issuer, Hash(claim))（思想同论文算法）     │
│   - zkProofs（可选）：选择性披露/范围证明                            │
│      例：证明 reliabilityLevel ≥ R2、或“具备夜航能力”，但不 раскры     │
│      其他不相关字段                                                  │
│                                                                     │
└─────────────────────────────────────────────────────────────┘
  依据：Proof 是发行者对 Claim 的签名机制(多域DID.pdf)
       proofValue=Sign(sk,Hash(claim)) 的签名式样在论文凭证构造中出现(多域DID.pdf)
       GeneralDID：proof 可是数字签名或零知识证明(基于区块链的物联网身份管理系统.pdf)
       ZKP 可附加到凭证/账本，做范围证明等(基于区块链的物联网身份管理系统.pdf)

---

③ 跨域使用设备时，如何“匿名 + 可派单”（极简流程）

1. 设备在域B生成新的 UserID_B + DID Document（公钥、域B任务接口端点）。DID Document 可跨域解析读取(多域DID.pdf)。
2. 设备出示 DeviceCapabilityVC：claim 里只绑定 subjectDid=UserID_B，不带 MainID。
3. 域B合约/调度器验证 VC：
   • 验 proof（发行者签名），并按 CPT 理解 claim 字段语义(多域DID.pdf)；
   • 若只需部分字段：设备给必要字段 + 对其余字段给 ZKP（例如证明“可靠等级≥R2”）。(基于区块链的物联网身份管理系统.pdf)
4. 验证通过 → 域B按能力给设备分配任务（可再发一个“任务授权凭证/任务token”，这里你若需要我也能按同样结构补一个）。
5. 监管需要追溯时：可走 MainID 路径（承诺 + Tk），做到“默认匿名、必要可追溯”。(基于区块链的物联网身份管理系统.pdf)

---

如果你愿意，我可以把 CPT（能力VC的 claimStructure） 也按《多域DID》附录那种 JSON 模板写出来（字段类型、是否必填、范围等），这样你直接就能用来做“低空任务派单”的能力标准。

你的划分思路是对的：敏感字段→承诺 +（必要时）ZKP；非敏感字段→明文。关键是你后面问的那句——“签名（proof）和 ZKP 要怎么关联，验证者不看敏感值怎么验证整张凭证？”——答案在于：** 发行者签名的对象不是敏感明文，而是“承诺后的 claim”**。

---

1）为什么“只签名 + 明文/承诺混合”依然可验证？

在多域DID论文里，VC 的 proof 本质是对 claim 的数字签名，典型就是 proofValue = Sign(sk, Hash(claim))。(多域DID.pdf)
因此，只要 claim 本身可被哈希，验证者就能验签——不需要知道 claim 里每个字段的“原始明文”，因为它验的是“claim 这份结构化数据有没有被篡改”。

GeneralDID 明确允许 claim 里用两类声明：

• 明文声明：claim_i = {uprop, attv, U}
• 承诺声明：claim_i = {uprop, com, U}（敏感值变成承诺 com）(基于区块链的物联网身份管理系统.pdf) (基于区块链的物联网身份管理系统.pdf)

同时它把 VC 结构写成 basicdata + claim + proof，并说明 proof 可以是数字签名或零知识证明。(基于区块链的物联网身份管理系统.pdf)

所以核心做法是：发行者对“含承诺的 claim”签名，而不是对敏感明文签名。

---

2）那“只出示用户等级，不出示身份证号”，proof 怎么办？

你不能“改 claim 再改 proof”——因为 proof 的签名需要发行者私钥（多域DID里就是签 Hash(claim)）。(多域DID.pdf)

正确做法有两条路：

路线 A：最简单（工程上常用）——拆成两张 VC

• VC1：只含“用户等级”（非敏感）
• VC2：含“身份证号”等敏感（不给域B出示）

你出示 VC1 即可，proof 原封不动。

路线 B：你说的“敏感承诺 + 非敏感明文”，并做选择性披露（更贴近 GeneralDID）

假设原始信息是：{身份证号, 用户等级}，你希望只透露“用户等级”。

发行时（由发行者签发）把 claim 设计成：

• level：明文（非敏感）
• idNumber：承诺 com_id = Comm(idNumber, r1)（敏感）(基于区块链的物联网身份管理系统.pdf)
  发行者对整个 claim 做签名：proofValue = Sign(issuerSK, Hash(claim))（思想同多域DID）。(多域DID.pdf)

出示时（给验证者域B）：

1. 把**完整 VC（含 com_id）**给域B（这样域B能验发行者签名，确认“这份 claim（含 com_id）没被篡改、确实由发行者背书”）。(基于区块链的物联网身份管理系统.pdf)
2. 你公开 level（本来就是明文）。
3. 你不公开身份证号：不提供 (idNumber, r1)，因此域B无法从 com_id 还原身份证号。
4. 如果域B还需要确认“你确实不是随便塞了个 com_id 糊弄”，你给一个 ZKP：证明“我知道 com_id 的 opening（我知道 idNumber 和 r1）”或证明它满足某个条件（例如格式/范围），但不泄露 idNumber。GeneralDID 里就描述了这种 NIZK：证明者掌握承诺的初始值，能在不泄露信息的情况下让验证者信服；还可以扩展到范围证明。(基于区块链的物联网身份管理系统.pdf)

这样，“签名”和“ZKP”的关联点是：ZKP 里引用的就是 VC 里那条被签名保护过的承诺 com_id。域B先验签确认 com_id 没被换过，再验 ZKP 确认你确实“拥有/满足条件”。

---

3）一句话回答你的疑问

• 签名（proof）保证：claim（含承诺字段）整体没被篡改、确实由发行者背书（多域DID里就是签 Hash(claim)）。(多域DID.pdf)
• ZKP 保证：在不公开敏感值的前提下，你对“claim 里的承诺字段”有知识/满足谓词（GeneralDID明确可把证明附加到凭证并让任何验证方验证）。(基于区块链的物联网身份管理系统.pdf)

如果你愿意，把你“设备能力 VC”里哪些字段算敏感、哪些不敏感列一下（比如：可靠等级是否敏感？能力边界是否敏感？合规约束是否敏感？），我可以帮你直接把一份 CapabilityVC 的 claim 结构按“明文 + 承诺 + 对应要做的 ZKP 类型（范围/集合/知道opening）”配好。

你的划分思路基本就是论文想表达的“双凭证/双属性”路线：非敏感字段明文放 claim；敏感字段用承诺 com 放 claim，需要时再配 ZKP。GeneralDID 明确支持“明文声明/承诺声明”两种 claim 形式：claimi = {uprop, attv, U} 或 claimi = {uprop, com, U}，并且必要时也允许把承诺的 (v,r) 给验证者核对一致性。(基于区块链的物联网身份管理系统.pdf)

你担心的关键点是对的：签名 proof 和 ZKP 必须“绑”在同一份 claim 上，否则验证者不知道敏感明文时就无法验证“整张凭证”的一致性/完整性。解决方式是：

1）发行者签名签的不是敏感明文，而是“包含承诺的 claim”

在多域DID那篇里，proof 的典型生成方式就是对 Hash(claim) 做签名：proof[proofValue] = Sign(sku, Hash(claim))。(多域DID.pdf) 论文也概括了 VC=Claim+Proof，Proof 记录的是“发行者对 Claim 的数字签名”。(多域DID.pdf)

所以你把身份证号变成承诺 com_id 放进 claim 里，发行者签名覆盖的是：

• 明文字段（用户等级）
• 承诺字段（com_id）

验证者验签时只需要看到 claim（含 com_id），不需要知道身份证号明文，也能确认“这份 claim 没被篡改、确实由发行者背书”。

（GeneralDID里同样是“对摘要签名”，并且摘要 sc 可以是哈希或承诺，最后生成证明 ξI = Sign{skI,(pkU, sc, ξ)}。(基于区块链的物联网身份管理系统.pdf)）

---

2）ZKP 证明的“公共输入”引用的就是这条被签名保护的承诺 com_id

GeneralDID对 ZKP 的描述是：证明者掌握秘密信息（例如“承诺的初始值/opening”），可以生成非交互式零知识证明，在不泄露敏感值的情况下让验证者信服；证明还能附加到凭证/账本供任何验证系统验证。(基于区块链的物联网身份管理系统.pdf)
并且 GeneralDID 明确说 proof 可以是“数字签名或零知识证明”。(基于区块链的物联网身份管理系统.pdf)

因此“关联方式”就是：ZKP 里要证明的对象就是 claim 里的 com_id（它已经被发行者签名锁定了，换不了）。

---

3）把你那个例子写成“发行/出示/验证”三步（最直观）

A. 发行（Issuer签发）

claim 设计成混合：

• level = VIP3（明文）
• com_id = Comm(idNumber, r1)（身份证号承诺）(基于区块链的物联网身份管理系统.pdf)
  发行者生成 proof：对 Hash(claim) 签名。(多域DID.pdf)

B. 出示（Holder只想给“等级”）

你给域B的材料里：

1. VC 原样给（claim 里仍然包含 com_id，但没有 idNumber 明文）
2. 域B直接读取 level 用于派单
3. idNumber,r1 不给，因此域B无法从 com_id 反推出身份证号；同时“必要时你也可以选择透露 (v,r) 让对方核对”，但你这里不想透露。(基于区块链的物联网身份管理系统.pdf)

注意：在“普通签名=Sign(Hash(claim))”这种 VC 里，如果你把 claim 的某个字段直接删掉（不发 com_id），那 Hash(claim) 就变了，签名会验不过——所以通常是“claim 不删字段，只把敏感值换成承诺”。

C. 验证（Verifier怎么验）

域B验两件事就够：

• 验 proof（发行者签名）：确认 claim（含 com_id）没被篡改、确实由发行者签过。(多域DID.pdf)
• 用 level 做业务判断/派单。

---

4）那 ZKP 什么时候需要？怎么跟签名“锁死”？

如果域B除了“等级”以外，还想确认“你确实拥有那张身份证号承诺对应的秘密”（防止你随便塞个 com_id），就让你额外给一个 ZKP：

• 证明语句（直观理解）：我知道 (idNumber, r1)，使得 com_id = Comm(idNumber, r1)。(基于区块链的物联网身份管理系统.pdf)
• 这个 ZKP 的公共输入里必须包含 VC 里的 com_id（最好也包含 claim 或其哈希），这样你无法把“一个VC的签名”+“另一个com_id的ZKP”拼接作弊。

论文没有把“把 claim 哈希塞进 Fiat–Shamir challenge”写成公式，但它已经说明 NIZK 通过哈希验证且可附加到凭证中。(基于区块链的物联网身份管理系统.pdf) 工程实现里把“被签名的 claim（或其哈希）”作为 ZKP 公共输入/挑战，是最常见的绑定方式。

---

5）你的场景最终可以落成一句话

• 签名 proof：保障“整张 claim（明文+承诺）没被篡改、由发行者背书”（哪怕验证者不知道敏感明文也能验）。(多域DID.pdf)
• ZKP：在不 раскры 敏感明文的情况下，证明你对“claim 里被签名锁定的承诺字段”确实有知识/满足谓词。(基于区块链的物联网身份管理系统.pdf)

如果你愿意，我可以按你“低空多域设备能力VC”的字段（可靠等级、关键能力等级、能力边界、合规约束）帮你做一张“哪些明文、哪些承诺、分别配哪种ZKP（范围/集合/知晓opening）”的表，直接用于跨域派单。

可以，你这个“最小披露（selective disclosure）”在你们讨论的 “明文+承诺混合 claim + 发行者签名 +（可选）ZKP” 体系里，最常用就两种做法——看你想不想暴露“具体等级”。

---

做法 1：披露“具体等级”，其他都不披露（最简单、实现最直观）

发行时（Issuer 签发 VC）

把 不想让别人看到的字段（如身份证号）做成承诺 com 放进 claim；发行者对整个 claim（含这些承诺）做签名即可——VC 结构里本来就有 basicdata/claim/proof，且 proof 可以是签名或 ZKP。(基于区块链的物联网身份管理系统.pdf) (基于区块链的物联网身份管理系统.pdf)

示意（claim 混合明文+承诺）：

json
claim: {
  level_com: Comm(level, rL),
  id_com:    Comm(idNumber, rI)
}
proof: issuerSignature( Hash(claim) )

（“承诺声明”这种形式在文中就是 claim_i={uprop, com, U}。(基于区块链的物联网身份管理系统.pdf) (基于区块链的物联网身份管理系统.pdf)）

出示时（Holder 只想给“等级”）

你把 整张 VC 原样给对方（里面有 id_com 但不含身份证明文），然后只额外给：

• level 和 rL（用来打开 level_com）

论文明确说“必要时，用户可以将 v 值和随机 r 透露给承诺 Com 的验证者，以确保验证者确认它们的一致性”。(基于区块链的物联网身份管理系统.pdf)

验证者怎么验？

1. 验发行者签名（proof）→ 确认 claim（包括 id_com）没被篡改
2. 用你给的 (level, rL) 打开 level_com → 确认等级是真的
3. 由于你没给 (idNumber, rI)，对方看不到身份证号

注意：你不是“把身份证号字段删掉”；你是让它以承诺形式留在 claim 里，这样签名还能验，而值依然不泄露。

---

做法 2：连“具体等级”都不暴露，只证明“等级 ≥ 某阈值”（更强的最小披露）

如果你只想让对方知道“够不够用”（例如任务要求 level≥3），那就不揭示 level 明文，而是给 范围证明/谓词证明：

论文里说得很直接：证明者可以在不泄露信息的情况下生成 NIZK，并且可以扩展到范围证明（如证明承诺值落在区间内），把证明附加到凭证/账本里供任何验证系统验证。(基于区块链的物联网身份管理系统.pdf)

出示时你给对方什么？

• VC 原样（含 level_com）
• 一个 ZKP：证明 level_com 里那个 level 满足 level ≥ 3（或属于某集合）

验证者怎么验？

• 先验发行者签名（保证 level_com 没被换）
• 再验你给的 ZKP（保证“确实 ≥3”，但不知道具体是 3 还是 5）

---

什么时候选哪种？

• 要“具体等级”用于精细分配：用做法 1（开承诺只开 level）
• 只要“够不够格”用于准入/派单门槛：用做法 2（ZKP 证明 ≥阈值）

---

额外一句：最小披露的“最省事工程方案”

多域DID那篇也强调 claim 可以包含一个或多个声明（Claims），proof 是对 claim 的签名。(多域DID.pdf)
所以你还可以直接让发行者拆分签发：

• LevelVC（只含等级）
• IDVC（含身份证号承诺等）
  跨域派任务只要求出示 LevelVC，实现最小披露更简单。

---

如果你把你“设备能力 VC”的字段列一下（可靠等级/关键能力等级/能力边界/合规约束里哪些算敏感、哪些必须明文），我可以帮你直接给出一份 CapabilityVC 的 claim 设计：每个字段用“明文 / 承诺 / 范围证明 / 集合证明”哪一种最合适。

对的——在 GeneralDID 这篇里，claim 本来就允许包含多个属性/多条声明，不是只能是单个 {a,v}。

1) 论文里对“多属性 claim”的正式定义

文中明确写了：假设一个证书包含 $m$ 个声明要求：

$$claim=\{claim_1,claim_2,\dots,claim_m\}$$

并且每条声明既可以是明文声明 claim_i={uprop,attv,U}，也可以是承诺声明 claim_i={uprop,com,U}。(基于区块链的物联网身份管理系统.pdf)

在算法定义里也同样把声明写成集合：CreateClaim(...) 输出的 claim={claim1,...,claimn}，其中 claim_i=(uprop,attv,U)。(基于区块链的物联网身份管理系统.pdf)

所以你写的这种形式本质上没问题，比如可以理解为：

$$claim=\{(a_1,C_{v_1}),(a_2,C_{v_2}),\dots\}$$

只是论文里更常用 claim_i 这个写法。

2) 那为什么你截图那行写成 TS.Sig(claim)，看起来像“单个属性”？

因为很多流程图/协议步骤会把 claim 当成“本次要被委员会背书的那份声明对象”，这个对象可以是：

• 一条声明（单属性，如 {a,v}），也可以
• 一组声明（多属性，如 {claim1,...,claimm}）

也就是说：TS.Sig(claim) 里的 claim，既可以是单条，也可以是多条打包后的结构；实现里常见两种方式：

1. 对整个 claim 集合做一次阈值签名（把整个集合序列化后签）；或
2. 对每个 claim_i 分别做阈值签名（得到 $\delta_i^{Oracle}$ 的一组签名）

3) 如果你要做“多个属性一起承诺”，论文也支持

它还提到可以对“属性值向量”做承诺：com = Comm(attv, r)（attv 是属性值向量）。(基于区块链的物联网身份管理系统.pdf)
这时一个 claim_i 里就能装“多个属性值的承诺”（向量承诺），再配合明文/承诺声明形式。(基于区块链的物联网身份管理系统.pdf)

在无人机（UAV）场景里，“去重/防同一设备重复注册（Sybil）”本质就是：选一个（或极少数几个）强唯一、难伪造、可被权威核验的属性当作 MainID 的“真实锚点”。GeneralDID 在注册时也明确要求用户/设备向监管者提交可验证的身份证明（例子给了“电子身份证、设备 MAC 地址或其他可信凭证”），由监管者核验后再生成/登记主标识 (基于区块链的物联网身份管理系统.pdf)；同时强调 MainID 对每个用户/设备是唯一，用于监督与防 Sybil (基于区块链的物联网身份管理系统.pdf)。

无人机去重建议：按“可靠程度”从高到低选属性

优先级 S（最推荐）：硬件根密钥/硬件证明（强不可克隆）

用“设备安全元件/飞控安全芯片里不可导出的设备根密钥公钥（或其证书链）”当去重锚点。
理由：难伪造、难批量复制；最适合做“唯一身份”锚点（相当于把“设备是谁”绑定到硬件 Root-of-Trust）。

在多域系统里，设备本来也会作为“用户”进入系统注册、申请 DID 和密钥对 (多域DID.pdf)，所以用硬件根来做注册核验很贴合流程。

优先级 A：监管登记号 / 远程识别模块序列号（强唯一但依赖外部管理）

如果你的低空体系里本来就有“监管侧的设备登记号”或“远程识别（Remote ID）模块序列号/证书”，也很适合做去重锚点。
理由：业务上天然要求“一个设备一个号”，而且容易被监管/平台核验；缺点是依赖外部登记体系的完整性。

优先级 B：制造商出厂序列号 + 制造商签名证明（中强）

“机身 SN/飞控 SN”这类序列号本身可被仿造，但如果你要求制造商对 SN 与设备公钥的绑定出具签名证明/证书，强度会明显上升（靠“可验证的可信凭证”思路）。这也符合 GeneralDID 所说的“其他可信凭证”这一类证据输入 (基于区块链的物联网身份管理系统.pdf)。

优先级 C：网络标识（MAC/IMEI/ICCID 等）（不建议单独用）

论文举例里提到 MAC 地址可作为可验证身份证明之一 (基于区块链的物联网身份管理系统.pdf)，但在无人机场景里MAC/IMEI 很容易被改写/克隆，更适合作为“辅助校验/风控因子”，不建议作为唯一去重锚点。

---

多属性怎么声明？查重是不是只用一个关键属性？

可以“多属性声明”，但“查重通常只用 1 个主锚点 + 少数辅助锚点”：

• GeneralDID 允许一个证书包含多条声明：claim = {claim1, ..., claimm}，每条可以是明文或承诺形式 (基于区块链的物联网身份管理系统.pdf)。
• 工程上建议：
  • 去重主键：只选 一个 最强的（例如“硬件根公钥/其证书哈希”）。
  • 辅助键：再选 1–2 个（例如“监管登记号、制造商 SN”）做异常检测与找回/换件处理。
  • 否则你会遇到：弱属性（比如地址/型号）导致误判，或者维护成本飙升。

---

最贴合你前面“承诺 + ZKP”的落地方式（简述）

• 注册阶段把“去重主键”作为可验证身份证明提交给监管者/委员会核验（GeneralDID就是这么走）(基于区块链的物联网身份管理系统.pdf)。
• 链上只登记它的承诺/摘要，把隐私风险压到最低；后续跨域用 **UserID（假名）**对外匿名，但仍可做到“必要可追溯、可监管”。（MainID 唯一且用于监管/防 Sybil 的定位在文中明确）(基于区块链的物联网身份管理系统.pdf)

如果你告诉我：你们的无人机硬件条件（有没有安全芯片/远程识别模块/出厂证书体系），我可以按“可实现”的口径给你选一个主去重属性 v，再给一个“辅助属性集合”，并配一条完整注册/跨域使用流程。

你这个疑问完全成立：如果去重用的是 $C_v=Pedersen(v,r)=g^v h^r$，那么 同一个 $v$ 只要 $r$ 换了，$C_v$ 就会变成另一个值——那“查 $C_v$ 是否已存在”就查不出重复了。

为什么会这样？

Pedersen 承诺的设计目标之一就是“隐藏性”：随机数 $r$ 提供随机隐藏（perfect hiding），所以同一个 $v$ 用不同 $r$ 会生成不同承诺值。论文里也把它写得很明确：$Com=Comm(v,r)=g^v h^r$，并强调随机性来自 $r$；甚至还指出 如果 $r=0$，承诺就不再隐藏而偏“绑定”。(基于区块链的物联网身份管理系统.pdf)

同时，这篇 GeneralDID 里也提到 不同凭证会使用不同随机数 $r$（“随不同的凭证变化”）。(基于区块链的物联网身份管理系统.pdf)
所以你直觉上会觉得“那怎么还能去重？”——这个点确实需要额外机制，否则逻辑对不上。

---

那用 $C_v$ 去重到底该怎么做才合理？

从你截图那段 SearchCBF / CheckCBF 的流程来看，CBF 里存的是“可比较的标记”。要想“同 $v$ 必然命中”，去重用的标记必须满足：

同一个 $v$ 在不同注册尝试中映射到 同一个 tag（或可被一致比较）

常见有 3 种实现路线（你可以对照看看你那篇图/正文更像哪一种）：

路线 A：去重阶段把 $r$ 固定（极端做法：$r=0$）

• 让 $C_v = g^v h^0 = g^v$ 成为确定值
• 这样同 $v$ → 同 $C_v$ → CBF 才能命中

代价：隐藏性变弱（论文也提示 $r=0$ 时“不是隐藏的”）。(基于区块链的物联网身份管理系统.pdf)
但如果 $v$ 熵很高（如身份证号/硬件根公钥哈希），实际仍可能可接受。

路线 B：让 $r$ 确定化（例如由 $v$ 派生）

例如：

• $r = H(v)$ 或 $r = H(a \,\|\, v)$
  这样同 $v$ 每次都会得到同 $r$，从而同 $C_v$。

优点：仍保留一定“结构上的承诺形式”；缺点：如果攻击者能猜 $v$，仍可能离线枚举（取决于 $v$ 的熵）。

路线 C：去重不存 $C_v$，而是存一个“确定性去重标签”

也就是把“隐私承诺”和“去重标记”拆开：

• 隐私用：$C_v = Comm(v,r)$（照常用随机 $r$）
• 去重用：$tag = HMAC_k(v)$ 或 $tag = H(v \,\|\, salt)$（确定值，写入 CBF）

这在工程上最常见：承诺负责隐私，tag 负责可比对去重，两者不冲突。

---

结论怎么说最准确？

• 你说得对：如果 $r$ 真的是每次都随机，那用 $C_v$ 做 CBF 去重在逻辑上就会失效。
• 所以“用 $C_v$ 去重”要成立，系统必须隐含/额外规定 $r$ 在去重场景是固定或确定化，或者 去重实际用的是另一个确定性 tag（而不是随机承诺）。
• 仅从 GeneralDID 这篇对 Pedersen 承诺的描述来看，它明确承认 $r$ 带来随机隐藏、且 $r=0$ 会改变隐藏性。(基于区块链的物联网身份管理系统.pdf)

如果你把“CBF/CheckCBF”那篇论文的这一段后面两三段（通常会说明“r 怎么取 / CBF 里到底存什么”）也截出来，我可以帮你判断它到底采用了上面 A/B/C 的哪一种，并指出是否存在隐私/误判/枚举风险。

这一步“获取匿名凭证（cred）”本质上就是：用户先生成一个“假名/化名” $Nym$，然后域 A 的委员会 $C^A$ 给这个 $Nym$签发一张匿名凭证（可以理解成“对 $Nym$ 的匿名签名/可证明成员资格”），以后跨域时用户用零知识证明证明“我确实拿到了这张凭证”，但不暴露真实身份。

下面按你图里的符号把它拆开讲清楚。

---

0）系统里有哪些公开参数

图里出现的 $a,b,c_0$（以及后面用到的 $N,u$ 等）一般都是系统公开参数（大家都知道）。

用户自己有一个长期秘密（图里写成 $sk_u^A$）。

---

1）用户生成“假名” $Nym$（匿名性来自这里）

用户随机选一个新随机数 $s$，然后计算：

$$Nym_{U^A}^{C^A} = a^{sk_u^A} \, b^s$$

直觉解释：

• $a^{sk_u^A}$：把“我掌握某个长期秘密”编码进来（绑定到用户/设备的秘密，不用公开）
• $b^s$：每次新选的随机遮罩（确保每次生成的 $Nym$ 都不一样，避免被链接）

所以用户把 $Nym$ 发给委员会时，即便是开放信道，别人也很难反推出 $sk_u^A$；同时不同会话的 $Nym$ 也不会自然关联。

---

2）委员会给 $Nym$ “签发匿名凭证” cred（为什么公式里有 $p^e=\dots$）

图里写“颁布匿名凭证 $cred=(e,n,s)$（或你截图里写成 $cred=(e,v,s)$）给 $Nym$，其中 $p^e = a^{sk_u^A} b^s c_0$”。

这通常表示委员会在做一种**“签名式凭证”**（非常像 CL 签名 / RSA 类累加器体系里那套）：

• 委员会会挑一个新的素数 $e$（注意你后面步骤 2 的累加器更新也在收集 $e_i$，说明 $e$ 很可能就是“要塞进累加器的成员标识”）
• 然后委员会计算一个值 $p$，让下面的关系成立：

$$p^e = a^{sk_u^A} b^s c_0 \;=\; Nym \cdot c_0$$

你可以把它理解成：

委员会给你的凭证里包含一个“签名部件” $p$ 和一个“成员素数” $e$，使得别人只要看到 $p,e,Nym,c_0$ 就能验证“这是委员会发的、结构正确的凭证”。

为啥委员会能算出 $p$？
通常这类方案里，委员会掌握某种“发行者秘密/陷门”（例如在 RSA 模数体系里知道 $\varphi(N)$，从而能求 $e$ 次根），所以能构造出满足 $p^e=\dots$ 的 $p$。

---

3）那 cred 里到底包含什么？（你图里符号有点不统一）

你截图里写的是 $cred=(e,v,s)$ 或 $cred=(e,n,s)$，但又出现了 $p^e=\dots$。

在这类协议里，cred 至少要包含 $e$（因为后面累加器要用），还通常会包含：

• 一个“签名/见证”部件（很可能就是图里的 $p$ 或你看到的 $n$/$v$ 中某一个）
• 以及用户自己的随机数 $s$（或足够让用户后续生成证明的辅助信息）

所以你可以先按这个最稳的理解记住：

cred = “(成员素数 e) + (签名/见证部件 p 或 n/v) + (必要的随机性信息)”
并且满足图里那条核心约束 $p^e = Nym \cdot c_0$。

---

4）为什么这叫“匿名凭证”？

• 委员会签的是 $Nym$（化名），不是你的 DID/真实身份
• $Nym$ 里有随机项 $b^s$，跨会话不可链接
• 后面跨域验证不会直接把 cred 明文给对方看，而是用 NIZK 证明“我拥有某个 $e$ 且它在累加器里、且凭证关系成立”

所以域 B 最后通常只能学到：“你是域 A 认可的一员（集合成员）”，而不是你是谁。

---

如果你把这张图对应正文里对 $e,n(v),p$ 各自含义的那一小段也截出来，我可以把“cred 的三个分量分别是什么、委员会到底发给用户哪几个数、用户后面生成 $\pi_e$ 具体用哪些 witness”给你对齐到完全一致的符号级解释。