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 可轉移保證商業靈活性
  • 防女巫攻擊是去中心化身份的永恆挑戰，需要多種手段組合