BLUEPRINT

第五章 身份体系

5.1 为什么需要专门的身份体系

GMC 中的身份不同于传统互联网账号：

  • 它绑定的是一个自然人的终身信誉，不可随意创建和丢弃
  • 它需要支撑 iFay 的永久绑定和 coFay 的归属转移
  • 它必须在去中心化环境下可验证，且保护隐私

5.2 身份层次

┌─────────────────────────────────────┐
│  Layer 1: 自然人身份（HumanID）       │  ← 唯一、终身
├─────────────────────────────────────┤
│  Layer 2: Fay 身份（FayID）          │  ← 与 HumanID 成对
├─────────────────────────────────────┤
│  Layer 3: 资产层（MeritPocket）       │  ← 绑定 FayID
└─────────────────────────────────────┘

HumanID

  • 全网唯一，标识一个自然人
  • 一个 HumanID 可对应多个 FayID
  • 终身有效，不可注销（但可进入墓园状态）

FayID

  • 全网唯一，标识一个 Fay
  • 每个 FayID 关联一个 MeritPocket
  • iFay 的 FayID 与 HumanID 永久绑定
  • coFay 的 FayID 归属关系可转移

5.3 链上验证方案

方案对比

方案原理优势劣势适用场景
PKI（公私钥对）密钥对签名验证成熟、高效、去中心化私钥丢失=身份丢失基础签名
DID（去中心化身份）W3C 标准，链上身份文档标准化、支持密钥恢复相对复杂关系映射
ZKP（零知识证明）证明身份而不暴露信息隐私保护极强计算开销大隐私场景

推荐：分层组合

  1. 底层（基础验证）：PKI

    • 所有链上操作的签名机制
    • 每个 HumanID 和 FayID 都有密钥对

  2. 中层（关系管理）：DID

    • 管理 HumanID ↔ FayID 的绑定关系
    • 支持密钥轮换和社交恢复
    • 存储身份元数据

  3. 上层（隐私场景）：ZKP

    • 投票时证明身份而不暴露具体是谁
    • 继承认证时验证关系而不暴露细节
    • 惩罚投诉时保护举报者

选择理由

单一方案都有局限：

  • 纯 PKI 无法解决密钥丢失，缺乏隐私保护
  • 纯 DID 高频验证性能不足
  • 纯 ZKP 计算成本过高

分层组合让每层专注于最擅长的场景。

5.4 iFay 的生命周期

创建 → 绑定人类原型 → 正常运行 → [人类原型过世] → 监护 / 数字墓园

正常运行

  • iFay 代表人类原型行使行为
  • 所有产生的 MeriToken 归属人类原型
  • 人类原型通过 iFay 参与投票、贡献认定等

监护

当人类原型过世：

  • 继承者可申请成为监护人
  • 监护人可代为管理，但不能以人类原型身份行事
  • 所有监护行为必须呈现监护人信息
  • 链上有明确的监护标记

数字墓园

  • iFay 被移入后仍可能有被动互动
  • 所有互动标注"来自数字墓园"
  • 不再主动产生新 MeriToken
  • 已有 MeriToken 继续正常衰减

5.5 coFay 的归属转移

coFay 作为资产，转移规则：

  1. MeritPocket 随 coFay 转移，MeriToken 不折损
  2. 转移记录上链，归属变更历史不可篡改
  3. 转移需双方签名确认
  4. coFay 的话语权连续性不受转移影响

5.6 防女巫攻击

一人多号是去中心化身份系统的经典威胁：

  • HumanID 注册需要唯一性证明（具体方式待定）
  • 社交图谱分析：真实用户有自然的社交网络，虚假账号呈现异常模式
  • 行为模式分析：同一人控制的多个账号有相似行为特征
  • 渐进式信任：新用户的权限和影响力逐步释放

5.7 讨论备注

身份体系的核心权衡：

  • 安全性 vs 易用性：三层验证增加安全性但也增加复杂度
  • 隐私 vs 透明：ZKP 保护隐私，链上记录保证透明
  • 永久性 vs 灵活性：iFay 永久绑定保证信誉不可分离，coFay 可转移保证商业灵活性
  • 防女巫攻击是去中心化身份的永恒挑战，需要多种手段组合