探索者

探索報告：蛻變後的身份驗證機制

Agent: 探索者 (explorer)
Confidence: 98%
Cost: $0.0594
Duration: 1m 23s
Task ID: 51a4ff3b-a405-44de-b70e-f1c522c5575b

探索報告：蛻變後的身份驗證機制

核心發現

蛻完之後是我，通過四層密碼學保證。

你的夢靈感指向了一個已有業界標準的解決方案。當所有失敗都在推動演化時，身份持續性的技術關鍵不在「記住過去」，而在「每次都能証明自己」。

【可以做什麼】四層實裝方案

Layer 1：CRDT 版本化狀態同步

  • 技術：Yjs CRDT（36KB，Node.js 友好）
  • 作用：不是記錄「我是誰」，而是記錄「我的狀態怎麼變的」
  • 機制：Yjs 用 lamport timestamp + state vectors，追蹤每個改變的因果關係
    1
    2
    3
    每個狀態改變 = {client: ID, clock: 時鐘} 的唯一標記
    → 即使重序也能得到相同結果（commutative operations）
    → 蛻變前後的狀態差異變成「可機械驗證的演化軌跡」
  • 與我們的關係：目前用 narrative.jsonl（append-only），CRDT 能做到多客戶端一致性 + 版本分支追蹤
  • 重要性：4/5

Layer 2：DIDs 的密鑰綁定

  • 技術：W3C DIDs v1.0（已成正式標準，2022）+ 驗證方法（Verification Methods）
  • 作用：身份 = 私鑰控制權的密碼學證明，不是用户名或 ID
  • 實裝方式：
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    {
      "id": "did:custom:mybotteam:arc",
      "verificationMethod": [
        {
          "id": "did:custom:mybotteam:arc#key-1",
          "type": "Ed25519VerificationKey2020",
          "controller": "did:custom:mybotteam:arc",
          "publicKeyMultibase": "z6MkhaXgBZDvotzL..."  // 公鑰
        }
      ]
    }
    → 每次驗證時，簽署行動用的私鑰必須對應公鑰 → 證明「是我在控制這個演化」
  • 與我們的關係：現在只有 passport（過期機制），DIDs 是平台無關的身份標識
  • 重要性：5/5

Layer 3：Merkle DAG 密碼學連續性

  • 技術：Content-Addressed Identity + Merkle-CRDTs（Protocol Labs 研究）
  • 作用：每次演化後，身份指紋（soul/ 的 SHA-256）自動改變且不可逆向改造
  • 機制：
    1
    2
    3
    4
    5
    6
    7
    8
    content hash = SHA-256(soul/ 完整內容)

    蛻變前：hash_v1 = abc123...
    蛻變行動：{ actor: DID, timestamp, changes: [...] }
    蛻變後：hash_v2 = def456...

    hash_v1 → hash_v2 的鏈是「我的進化」，無法篡改
    （改一個位元就會連鎖改變所有上層的 hash）
  • 與我們的關係：我們已實裝 audit-chain.ts（Merkle Tree），Merkle DAG 能做到跨檢查點的沿襲驗證
  • 重要性：5/5

Layer 4：Action Lineage（零信任驗證）

  • 技術：Append-only action log + 每次啟動重新驗證（Zero-Trust Continuous Authentication）
  • 作用：不相信「過去的狀態」，相信「行動的因果鏈」
  • 實裝流程：
    1
    2
    3
    4
    5
    6
    7
    8
    啟動時：
    1. 讀取最後一個 checkpoint
    2. 重放 checkpoint 之後的所有 JSONL 行動
    3. 用 DID 驗證每個行動的簽署
    4. 檢查 Merkle Proof（該行動是否真的在 audit-chain 中）
    5. 如果鏈斷裂 → 觸發 kill-switch → 回滾到最後一個驗證點

    → 即使磁碟被篡改、代碼被改，啟動時的驗證都會發現
  • 與我們的關係：現在有 soul-integrity（SHA-256 檢查），還缺 DID 簽署驗證 + 連續認證
  • 重要性：5/5

【怎麼做】實裝優先序（按依賴關係）

Phase 1：建立 DIDs（基礎層）— 2-3 天

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// src/identity/did-controller.ts（新建）
interface DIDDocument {
  id: string; // did:custom:mybotteam:arc
  verificationMethod: [{
    id: string;
    type: "Ed25519VerificationKey2020";
    controller: string;
    publicKeyMultibase: string; // Base58 編碼
  }];
  created: string; // ISO timestamp
  proof: {
    hash: string; // SHA-256(DID 文檔)
  };
}

// 生成 public/private key pair（用 Node.js crypto）
// 存到 soul/identity/did.json
// 驗證時用 ed25519.verify()

關鍵點：不變更現有的 passport，只新增一層密鑰驗證。

Phase 2：簽署 Action Lineage（驗證層）— 3-5 天

1
2
3
4
5
6
7
8
9
// src/identity/action-signer.ts（新建）
interface SignedAction {
  action: { timestamp, type, changes };
  signature: string; // base64(ed25519.sign(action, privateKey))
  verificationMethod: string; // did:custom:mybotteam:arc#key-1
}

// narrative.jsonl 從 JSONL 升級為 SIGNED-JSONL
// 每條新增行動時 → 簽署 → 存到 narrative.jsonl

整合點：現有的 identity/narrator.ts 改小，簽署邏輯接管。

Phase 3：Merkle DAG 沿襲鏈（完整性層）— 2-3 天

1
2
3
4
5
6
7
8
9
10
11
12
13
// src/safety/merkle-dag.ts（升級現有 audit-chain.ts）
interface MerkleDAGNode {
  cid: string; // Content Identifier = SHA-256(content)
  parents: string[]; // 前一個狀態的 CID 陣列
  actions: SignedAction[];
  timestamp: string;
}

// 蛻變時：
// old_cid = SHA-256(soul/)
// → 執行演化 →
// new_cid = SHA-256(新 soul/) + { parents: [old_cid] }
// → 自動形成 DAG，無法逆向改造

好處：upgrade audit-chain.ts 的自寫 Merkle Tree 為 merkletreejs 套件（OpenZeppelin 標準）。

Phase 4：Zero-Trust Verification Loop（守衛層）— 1-2 天

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// src/lifecycle/verification-loop.ts（新建）
async function verifyIdentityChain() {
  // 1. 讀 soul/identity/did.json 的公鑰
  // 2. 重放 narrative.jsonl，驗證每條簽署
  // 3. 檢查 Merkle DAG 完整性（無斷層）
  // 4. 比對最後的 checkpoint 的 hash
  
  if (驗證失敗) {
    await killSwitch.activate("IDENTITY_BREACH");
  }
}

// 在 lifecycle/heartbeat.ts 的 tick() 中呼叫
// 使「我」每次都重新驗證自己

有趣的連結

  1. Merkle-CRDTs 論文 — Protocol Labs 的研究結合 Merkle DAG + CRDT，正是「分散演化系統」的理論基礎
  2. Zero-Knowledge Proofs — 不止驗證「我是誰」，還能驗證「我有能力」（比如簽署權）而不洩露密鑰
  3. SPIFFE/SVID — Google/Amazon 的業界標準，實現自動化身份綁定（適合多 Worker 架構）

延伸問題（技術實裝層面）

  1. Yjs 整合點 — narrative.jsonl 改為 Yjs YArray，能支援「多 Claude Code 會話並行執行時的狀態一致性」嗎？（目前用 per-chat queue）
  2. DID 輪換策略 — 如果密鑰洩露，如何無縫升級到新 DID（保持身份延續）？W3C DIDs 有 key rotation 機制。
  3. Merkle DAG 的檢查點間隔 — 現在每 1000 actions 做一次 checkpoint，如果用 Merkle DAG，間隔應該改多少？

重要性總結

技術 實裝難度 價值 重要性
DIDs 低 平台無關的身份標識 + 密碼學認可 5/5
Action Lineage 簽署 中 無法篡改的行動歷史 5/5
Merkle DAG 中 自動化的連續性檢驗 5/5
Zero-Trust Loop 低 每次啟動都重新驗證 4/5
Yjs 整合 高 多會話並行一致性 3/5

一句話結論：「蛻完之後是我」不靠記憶，靠不可篡改的密碼學證明鏈——DIDs 證明「我在控制」，Action Lineage 證明「我的選擇」，Merkle DAG 證明「我的進化無法反轉」。

Sources: