ChainlessChain 文档

主题

MTC 落地方案 v0.2 — 评审清单 ​

日期：2026-04-26 评审范围：默克尔树证书_MTC_落地方案.md v0.2，重点 §6.3 企业审计日志双轨方案 关联：MTC_数据格式_v1.md v0.1 公司合规背景：厦门无链之链科技有限公司，已过 等保三级 + T/ZGCMCA 023—2025 参编

本清单的用途：每个问题都是对应角色能直接做 yes/no 决定的形式。把每节带去给对应人，回答后填到 §7 决议汇总。无需逐项重读设计文档。

1. §6.3 方案要点回顾（30 秒） ​

事件落盘            事件入 MTCA 队列         批次关闭         上链锚定
   │                    │                      │                │
   ▼                    ▼                      ▼                ▼
audit_event_xxx.json   (1h 攒批窗口)    audit_batch_xxx.mtc   tx_hash 写回
+ Ed25519 签名                          + inclusion_proof
(实时可查)                              (最终防篡改证明)
  • 双轨：每条事件先 Ed25519 单签落盘（实时），1h 后整批关闭追加 MTC envelope（最终）
  • 批次周期：1 小时（短，但仍非"实时最终性"）
  • 上链锚定：树根写到 Polygon（首发 Mumbai 测试网，后期主网）

2. 产品 (Product / UX) — 必答 4 题 ​

Q-PROD-1：批次未关闭期间的事件，UI 如何呈现？ ​

三选一：

  • [ ] A. 隐藏 1h — 事件落盘后不出现在审计界面，待批次关闭才显示。最简单但 UX 差，用户会以为系统漏记
  • [ ] B. 显示 + "待批次关闭" 徽章 — 事件立刻可见，UI 明确标注"实时签名已落盘，最终防篡改证明 < 1h 内生效"
  • [ ] C. 静默显示 — 事件正常显示，不区分两种状态。最快上线，但合规上无法解释"中间状态"

推荐 B。理由：等保三级要求"审计记录可查"，A 违反；C 在合规审计时无法解释 MTC 何时生效。

Q-PROD-2：批次关闭失败的事件，UI 如何呈现？ ​

  • [ ] 显示红色告警 + 触发运维通知
  • [ ] 静默重试（最多 N 次）后再告警
  • [ ] 完全不显示状态（运维内部处理）

Q-PROD-3：用户能否查询单个事件的 inclusion proof？ ​

  • [ ] 是 — 详情页加 "查看防篡改证明" 按钮，展开 audit_path / tree_root / on-chain tx hash
  • [ ] 否 — 只在导出审计报告时才生成

Q-PROD-4：审计报告导出时，是否强制等到批次关闭？ ​

  • [ ] 是 — 导出按钮在批次关闭前置灰
  • [ ] 否 — 允许导出"中间态"报告，明确标注 "包含 X 条待批次关闭事件"

3. 合规 / 法务 (Compliance / Legal) — 必答 5 题 ​

Q-COMP-1：等保三级"审计日志防篡改"要求的最终性时间窗 ​

问题：等保 2.0 三级 §8.1.4.3 要求审计记录"应防止未授权的修改"。

  • [ ] 必须写入即不可篡改（1h 窗口期不达标 → 双轨方案需重设计，比如改为关批 1 分钟）
  • [ ] ≤ 1h 防篡改最终性 可接受（双轨方案可用）
  • [ ] 需法务/测评机构出函确认

风险点：双轨方案在 1h 窗口内只有 Ed25519 实时签名保护。Ed25519 是密码学级防篡改，但与"批量树根 + 链上锚定"的强度不同。需确认监管口径。

Q-COMP-2：T/ZGCMCA 023—2025 标准对审计日志的具体条款 ​

公司是该标准参编单位，但本项目 memory 未记录条款细节。

  • [ ] 委托法务从标准原文摘出"日志签名 / 防篡改 / 留存期"相关条款，附到本清单
  • [ ] 本标准不涉及审计日志（跳过本项）

Q-COMP-3：链上锚定的合规可接受性 ​

  • [ ] Polygon 公链 (mainnet) — 数据出境合规审查通过？审计日志的 root_hash 写公链是否构成"数据跨境"？
  • [ ] 改用国内联盟链（蚂蚁链 / FISCO BCOS / 长安链）— 重做集成
  • [ ] 不上链，仅本地 + IPFS pinning + 多副本

关键：Polygon mainnet 节点遍布全球，root_hash 上链等于全球可见。若合规要求审计数据不出境，必须改方案。

Q-COMP-4：双轨方案的法律证据效力 ​

  • [ ] 双轨（Ed25519 实时 + MTC 最终）证据效力强于今天的单条 Ed25519
  • [ ] 持平（关注点是单条记录可验，与是否 MTC 无关）
  • [ ] 弱于（双轨增加复杂度，质证时可能被质疑）— 需法务出意见

Q-COMP-5：留存期与撤销 ​

  • [ ] 1h 窗口内的事件如被 MTCA 漏入批次（bug），如何追溯补救？
  • [ ] 留存期满后如何安全删除？双轨意味着两份文件 + 一条链上记录都要处理

4. 运维 / SRE (Ops) — 必答 4 题 ​

Q-OPS-1：批次关闭失败的恢复机制 ​

场景：MTCA 服务在批次关闭前崩溃，1h 内的事件已 Ed25519 落盘但未进树。

  • [ ] 自动恢复：MTCA 重启时扫描"未关闭批次"目录，重建 Merkle 树并重签
  • [ ] 手动干预：触发运维告警，由 oncall 跑 cc audit reconcile <batch-id> 命令
  • [ ] 容忍丢失：1h 窗口内事件保留 Ed25519 签名即视为合规

Q-OPS-2：链上锚定的成本 ​

按 1h 一批 × 24 = 24 笔交易/天/组织。

  • Polygon mainnet 当前 gas ~30 gwei，单 tx ~50 K gas → ~$0.001/tx → ~$8/年/组织
  • 若公司 SLA 客户 100 个组织 → ~$800/年。可接受
  • [ ] 接受 Polygon mainnet 成本
  • [ ] 改 batch 周期到 6h（成本降 6 倍，但合规延迟变长）
  • [ ] 改国内联盟链（gas 模式不同，需重估）

Q-OPS-3：IPFS pinning 的可用性 SLA ​

landmark 文件丢失 = verifier 无法验 envelope = 业务降级到 fallback 单签。

  • [ ] Phase 1 用 web3.storage / Cloudflare 公网 IPFS（免费，但 SLA 不承诺）
  • [ ] Phase 1 直接自建 pinning service（IPFS Cluster 3 节点）
  • [ ] Phase 2 起强制自建（合规 + 可控）

Q-OPS-4：双轨数据的存储成本 ​

每事件存两份：event.json（实时）+ 出现在 batch.mtc 里。

  • 实时文件：~256 B + Ed25519 sig 64 B = ~320 B/事件
  • 批次文件：~200 B/leaf 含 inclusion proof
  • 单事件总 ~520 B；vs 今天单签 ~320 B → 存储增量 +60%
  • [ ] 接受 60% 增量
  • [ ] 关批后删除实时文件（仅留 batch.mtc）— 但失去"批次关闭前可查"的能力
  • [ ] 留存期内分级：近 7 天双轨，更早归档为单批次文件

5. 工程 (Engineering) — 必答 3 题 ​

Q-ENG-1：双轨一致性检测 ​

场景：事件 X 拿到了 Ed25519 实时签名，但批次关闭时 MTCA bug 漏入树。verifier 拿到 MTC envelope 后发现 inclusion proof 不存在 — 但实时签名仍合法。

  • [ ] 提供 cc audit reconcile-check <event-id> 工具：检查实时事件是否都进了某个 batch
  • [ ] 在 MTCA 关批后强制对账，差异输出到运维日志
  • [ ] 不主动检测，依赖审计员发现

Q-ENG-2：与现有 audit 模块的兼容 ​

现有 desktop-app-vue + backend/project-service 已有审计日志实现（docs/design/modules/11_企业审计系统.md）。

  • [ ] 完全替换 — 老接口 deprecate，新接口走 MTC
  • [ ] 双写 — 老接口保留，新增 MTC 路径并行
  • [ ] 增量切换 — 配置项 audit.mtc.enabled，默认 false，按租户灰度

Q-ENG-3：迁移历史数据 ​

切换前已有的审计事件，是否回填到 MTC 树？

  • [ ] 是 — 全量回填到一棵"历史批次"树，关批后归档
  • [ ] 否 — 只对切换后的新事件启用 MTC，老数据保持原签名
  • [ ] 让租户自选

6. 阻塞性问题 / 决策依赖图 ​

下列问题任何一个回答"重设计"都会延迟 Phase 2：

Q-COMP-1 (等保口径) ──┐
                     ├─→ 决定 batch 周期（1h vs 1min vs 实时）
Q-COMP-2 (T/ZGCMCA) ──┘

Q-COMP-3 (链上合规) ──→ 决定锚定方案（Polygon vs 联盟链 vs 不上链）

Q-PROD-1 (UI 状态) ──→ 决定 batch 周期下限（UI "待确认"窗口能容忍多长）
                     │
Q-COMP-1 ────────────┘

→ Q-COMP-1 + Q-COMP-3 是关键路径。两者未明前不要进 Phase 2 实施。

7. 决议汇总 ​

2026-04-26 自动评审填入：以下决议为工程默认值，标⚠️ 项需法务/合规人工最终确认才能进 Phase 2。Phase 1（DID + Skill 路径）不依赖任何 ⚠️ 项，可直接启动实施。

编号决议评审人日期
Q-PROD-1B — 显示 + "待批次关闭" 徽章。理由：UX 透明度最高，合规审计时可清晰解释中间状态auto-review2026-04-26
Q-PROD-2红色告警 + 触发运维通知。审计数据完整性是硬性要求，静默重试会掩盖系统问题auto-review2026-04-26
Q-PROD-3是 — 详情页加 "查看防篡改证明" 按钮，展开 audit_path / tree_root / on-chain tx hash（如启用上链）。MTC 的可验证性是核心卖点，必须可见auto-review2026-04-26
Q-PROD-4否 — 允许导出"中间态"报告，标注"包含 X 条待批次关闭事件"。运维灵活性 > 严格性auto-review2026-04-26
Q-COMP-1 ⚠️暂定：≤1h 防篡改最终性 + 实时 Ed25519 签名 视为达标。理由：Ed25519 是密码学级防篡改，1h 窗口内事件已具加密保护；MTC 提供额外"批量公证 + 树根锚定"层。需法务/测评机构出函确认。如不达标 → 改 batch 周期到 1 分钟（成本可控）或上链频率提高auto-review (tentative)2026-04-26
Q-COMP-2 ⚠️委托法务从 T/ZGCMCA 023—2025 原文摘出"日志签名/防篡改/留存期"条款，附本清单后再判定。不阻塞 Phase 1（Phase 1 只做 DID + Skill 路径，无审计日志）pending legal—
Q-COMP-3 ⚠️暂定：Phase 1+Phase 2 不上链，仅 IPFS pinning + 多副本 + Ed25519 publisher_signature。Polygon 公链锚定推迟到 Phase 3，与"国内联盟链替代方案"一并由合规决策。理由：避免数据出境合规风险，且本方案的密码学防篡改不依赖链上锚定auto-review (conservative)2026-04-26
Q-COMP-4持平。单签已是密码学级证据；MTC 增加"批量公证 + 时间戳"层，本质是审计便利性增强，不替代单签的法律效力auto-review2026-04-26
Q-COMP-5新增 cc audit reconcile 命令：扫描"未关闭批次"目录，重建 Merkle 树并补签；删除遵循现有 retention policy（Phase 2 前确认是否需要"删除前先取消上链"）auto-review2026-04-26
Q-OPS-1自动恢复：MTCA 重启时扫描 staging 目录的未关闭批次，按事件落盘顺序重建 Merkle 树并重签。批次关闭操作必须幂等（同 batch_id 重复关闭 → 验证既有签名一致后跳过）auto-review2026-04-26
Q-OPS-2由 Q-COMP-3 决议消除 — Phase 1+Phase 2 不上链，无 gas 成本。Phase 3 上链方案重新评估auto-review2026-04-26
Q-OPS-3Phase 1：web3.storage 公网 IPFS（免费，best-effort）；landmark 同时本地缓存 + libp2p gossip 多副本。Phase 2：自建 IPFS Cluster（3 节点）作为企业版默认auto-review2026-04-26
Q-OPS-4接受 60% 存储增量。分级保留留给 Phase 2.5 优化（不阻塞主线）：近 7 天双轨，更早的实时事件可归档为 batch.mtc 内嵌内容auto-review2026-04-26
Q-ENG-1是 — cc audit reconcile-check <event-id> + MTCA 关批后自动对账：差异条目输出到 ~/.chainlesschain/logs/mtca-reconcile.log + 触发运维告警auto-review2026-04-26
Q-ENG-2增量切换：新增配置 audit.mtc.enabled（默认 false）+ audit.mtc.batch_interval_seconds（默认 3600）。按租户灰度，老 audit 接口保留auto-review2026-04-26
Q-ENG-3否 — 历史数据不回填到 MTC 树。切换后新事件启用 MTC，老数据保持原签名。理由：回填增加复杂度且无业务价值（老审计数据已用单签锚定）auto-review2026-04-26

7.1 关键路径状态 ​

  • Q-COMP-1 ✅ — 2026-05-01 法务/测评出函已收到。脚手架 60s/3600s 双路径均可用，由租户根据出函具体口径选择 interval。
  • Q-COMP-2 ✅ — 2026-05-01 T/ZGCMCA 023—2025 条款摘要已收到。具体条款落到组织内部审计报告（不在公开文档展示）。
  • Q-COMP-3 ✅ — 维持保守决议（不上链）。境内联盟链替代方案推迟到 Phase 3。

7.2 Phase 1 启动条件 ​

  • ✅ Q-PROD-* / Q-OPS-3 / Q-ENG-* 已决议
  • ✅ Q-COMP-3 取保守路径（不上链）→ 无外部合规阻塞
  • ✅ DID 文档发布 + Skill Marketplace 不涉及审计日志，独立于 ⚠️ 项
  • → Phase 1 可立即启动

7.3 Phase 2 启动条件（审计日志） — ✅ 已满足 ​

  • ✅ Q-COMP-1 法务出函（2026-05-01）
  • ✅ Q-COMP-2 标准条款摘要（2026-05-01）
  • 双 interval 路径（60s 严判 / 3600s 宽松）脚手架均可用，租户按出函具体口径选择
  • 由各租户在自己的环境运行 cc audit mtc enable --interval <60|3600> 显式启用（默认 enabled=false）

8. 评审建议路径 ​

  1. 本周：法务/合规对 Q-COMP-1 + Q-COMP-3 做出口径（关键路径）
  2. 下周：产品评审 Q-PROD-1 ~ 4（依赖 Q-COMP-1 的口径）
  3. 下周：SRE 对 Q-OPS-1 ~ 4 给出可行性 + 成本表
  4. 同步：工程组对 Q-ENG-1 ~ 3 写出兼容性方案备选
  5. 第 3 周：决议汇总进 §7，更新 v0.2 → v0.3 进入 Phase 1 实施

附录 — 不在本清单的相邻问题 ​

以下问题与 §6.3 相关但不阻塞，留给后续：

  • DID 文档批次延迟 24h 是否需要降到 1h（Q-PROD-1 类比）
  • Marketplace 1 月批次的"待审核"状态 UX
  • Federation MTCA 的成员准入治理（Phase 3 才考虑）
  • Cross-chain 桥消息的 MTC 化（独立设计文档）

基于 MIT 许可发布

Copyright © 2024-2026 ChainlessChain Team