跳轉到

D-20260706-05｜鏈身分信任根＋經濟壞損復原階梯

背景與驅動力

使用者兩問：怎麼辨識某條鏈是本專案的鏈、可否偽造；經濟壞掉能否修好機制後從未壞點分支續行。盤點發現三層信任鏈與「修法 ＋ 重算」能力架構上皆已存在但全為隱含，鏈重生更是零著墨（災難表只有基建災難）。

考慮過的選項

（流水帳未記錄替代方案；本決策以修正 ／ 收斂 ／ 翻案形式成立——既有隱含能力的明文化。）惟記錄一項評估不動：LEDGER_DB_ADDRESS 不列入版本規範六欄位表（位址非版本欄位、避免第三鏡像面）。

決定

  • 鏈身分信任根雙錨：LEDGER_DB_ADDRESS 位址錨（DB manifest CID 純內容派生、不含域名）＋ genesis governanceSigners 治理錨；驗證鏈 ＝ 位址 → genesis signer set → 檢查點多簽鏈 → log head → 事件簽章 ＋ 全網重算；信任根收斂於官方 build（開源 ＋PR／CI＋SRI）。偽造面：改史、假檢查點、平行假鏈全被錨鎖死；殘餘風險僅 eclipse 遮蔽——只能使人晚看到、不能使人看到假的。
  • 復原階梯三級：參數壞損 ＝ 治理緊急回滾；規則壞損 ＝ 修正隨 derive_logic major 出貨 ＋ 全網重算（毒害在重算中消失），生效切點 ＝ 鏈上事件錨、隨版寫死、禁 wall-clock——規則因此 epoch 化；帳本壞損 ＝ 鏈重生。
  • 鏈重生（最後手段）：以最後良好帳本檢查點為新鏈起點——治理 quorum 議決切點並公告 → 新 OrbitDB log（新位址）、genesis 內嵌 initialStateCid＝ 切點 derived state（出身證明：新鏈可驗證繼承舊鏈多簽信任、非憑空 genesis）→ client major 出貨新位址收斂全網；餘額、信譽、UGC 註冊、fork 血緣全保留，消失的只有切點後事件（公告重跑）。
  • 追溯政策：預設帶切點既往不咎；僅 exploit 所得顯著失衡時允許追溯，scope 僅及規則 bug 下的不當所得（合法既得權益不回收）。切點與追溯範圍為升版 PR 必載欄位。
  • fork 專案原樣部署 ＝ 同一條鏈（位址、genesis、端點全在 build 內容、與 origin 無關）；改 ledger 位址才是平行宇宙，MIT 允許且與官方鏈互不相通。

後果與影響

「事件不可篡改 ≠ 解讀不可修正」成為經濟層的復原哲學。位址錨直接站在域名遷移不變式（D-20260704-03）之上；三階部署狀態（D-20260713-01）再釘死位址的取得方式與缺值行為。權威見 資料系統.md。