Files
dsh_ai1net_server/docs/分布式数据链路/分布式数据链路-技术方案与落地路线_20260919.md
T

335 lines
22 KiB
Markdown
Raw Normal View History

# 分布式数据链路 · 技术方案与落地路线
> 📌 术语:本文以「分布式」指代本项目(2026-09-19 由「去中心化」更名);引用原文、DAO 专有名词与行业泛指保留原措辞。
> 版本 v1.0 | 2026-09-19 | 状态:**待拍板(S0 未开工)**
> 本文是**决策 + 落地**文档:给出"要不要做、做到哪一档、怎么分步"的判据,不写空泛的区块链科普。
> 事实依据见 **§10**,其中标注口径与来源;凡实测值均注明"常态/峰值/理论"区别,避免误用。
---
## 0. 结论先行
**三行判定:**
1. **若目标只是"防内部篡改 + 可审计"** ⇒ **不用区块链**。透明日志(Merkle 只追加日志)+ 定期把根哈希锚定到公链,即可获得"篡改可检测、且不可抵赖"的效果,成本比自建链低一个数量级。
2. **若目标要求"多方各自持节点、彼此不完全信任、共同写入"** ⇒ 用**联盟链**(国内合规场景优先 FISCO BCOS),**不要自研链**。自研链的代价不在技术可行性,在运维与团队。
3. **若目标面向公众、且要求"资产归用户所有、可自由流通"** ⇒ 上**公链 L2**(Arbitrum / Base)。但这意味着**链上数据全网公开** ⇒ **敏感数据永远不上链**(§5 是硬红线)。
**一条反判定**:如果做链的理由是"区块链听起来更安全"——**不要做**。链解决的是*信任*问题,不是*安全*问题;对单方持有的数据,链带来的攻击面(合约漏洞、密钥管理、节点运维)大于它消除的风险。
---
## 1. 范围与前提
**覆盖**:数据分层落点 · 三档技术路线选型 · 敏感数据专项 · 准入合规 · 分阶段落地 · 验收判据 · 负面清单。
**不覆盖**:具体业务建模、代币经济设计、跨境数据传输安排。
**前提假设**(若与实际不符,§2/§4 的选型结论需重算):
| 编号 | 假设 | 若为否则影响 |
|---|---|---|
| P1 | 参与方数量为个位数,且各自**有能力运行节点** | ≥数十方 ⇒ 联盟链运维成本失控,转 L2 或托管方案 |
| P2 | 存在**至少两个互不完全信任**的写入方 | 只有一个写入方 ⇒ 直接走 §4.1 路线 A,不必上链 |
| P3 | 不对**社会公众**开放节点 / 仅对授权成员开放 | 对公众开放 ⇒ §6 备案为强制前置(详见该节判据) |
| P4 | 业务在中国境内运营 | 境外运营 ⇒ §6 适用性另判 |
---
## 2. 第一决策:到底需不需要"链"
按目标对号入座,**命中即停**,不要越级选型(越级 = 平白多一条运维线)。
| 你的真实目标 | 需要链吗 | 推荐方案 | 关键理由 |
|---|---|---|---|
| 防止 DBA / 内部人偷偷改库 | **不需要** | 路线 A:哈希链审计日志 + 锚定 | 你要的是"改了一定被发现",不是"改不了" |
| 对外证明"这条记录 X 时间就是这个值" | **不需要** | 路线 A | 第三方时间戳 + 锚定即可,可验证成本近 0 |
| 多家公司共同记账、要对账分账 | **需要(联盟链)** | 路线 B | 需要多方共同写入与准入控制 |
| 用户资产要能自由转让 / 跨平台流通 | **需要(公链)** | 路线 C | 只有公链提供无需许可的可组合性 |
| 数据要"上链才显得可信" | **不需要** | ⛔ 不做 | 信任来自可验证性,不来自"用了区块链"这个词 |
**判据句式**:先回答"**谁和谁之间不信任**"。
- 没有第二个不信任的主体 ⇒ 无需链。
- 对手是"自己人" ⇒ 检测优先(路线 A)。
- 对手是"合作方" ⇒ 共同写入(路线 B)。
- 对手是"任何人" ⇒ 无需许可(路线 C)。
---
## 3. 数据分层落点(核心模型)
一句话:**值钱和要防改的上链,隐私和高频的留在链下,大文件的只有哈希上链。**
| 层 | 放什么 | 典型技术 | 不得出现 |
|---|---|---|---|
| **链上** | 匿名 ID · 数值状态(余额/积分/等级)· 业务流水 · 大文件的**内容哈希** · 权限变更记录 | 公链 L2 / 联盟链 | 明文密码、卡号、身份证、私钥、邮箱、手机号 |
| **链下 · 关系库** | 密码哈希(Argon2id)· 卡号 Token · 邮箱 · 实名信息 · 会话与风控 | PostgreSQL / MySQL + 列级加密 + 细粒度访问控制 | —— |
| **链下 · 对象/去中心化存储** | 3D 资源 · 玩家生成内容 · 详细日志 · 存档快照 | S3 / 自建 MinIO / IPFS / Arweave | 明文敏感字段 |
**关键澄清**:**"加密后上链"不等于安全**,理由四条(这是最常见的误区):
1. **不可撤** —— 算法破了或密钥泄了,历史区块仍在,无法换算法重来;
2. **元数据泄露** —— 时间、频率、大小、地址关联性本身就是隐私;
3. **密钥轮换不可行** —— 轮换后旧密文永久留链,形成"历史数据永远更弱"的斜坡;
4. **合规冲突** —— 删除权(§6.3)要求真删,链上做不到。
**正确姿势**:链上只放**无关联性的哈希 / 匿名 ID**;敏感明文与身份映射**只存关系库**,且二者之间的映射关系本身就是保护对象。
---
## 4. 三档技术路线
### 4.1 路线 A:透明日志 + 锚定(成本最低,优先评估)
**组成**:只追加审计日志(RFC 6962 式 Merkle 树)→ 定期(如每小时/每天)计算根哈希 → 把根哈希写入公链交易备注字段,或提交给第三方可信时间戳服务。
**为什么够用**:透明日志给的是**篡改可检测性**,且提供两种密码学证明:
- **包含证明**:某条记录确实在某个版本的日志里;
- **一致性证明**:新旧两个版本的日志互为前缀(即"只追加、没被改写")。
任何人拿到这些证明都能独立验证,无需信任日志运营方。一旦发现不一致,即构成不可抵赖的证据。
| 优点 | 缺点 |
|---|---|
| 成本极低(锚定一次几百字节,年成本可忽略) | 只**检测**篡改,不**阻止**篡改(需配合告警) |
| 无需多节点共识、无需新运维线 | 不提供"多方共同写入"(写入方仍是单一主体) |
| 可验证性对第三方开放 | 需要**有人真的去验证**(否则形同虚设 ⇒ 必须设外部监督或自动校验) |
| 可随时升级为路线 B/C 的上层 | —— |
**适用**:单组织内部防篡改、存证、日志不可否认、审计留痕。
### 4.2 路线 B:联盟链(多方互信,国内合规场景)
| 对比项 | FISCO BCOS | Hyperledger Fabric |
|---|---|---|
| 定位 | 国产自主可控,金融/政务 | 企业级通用,生态最大 |
| 共识 | PBFT(秒级确认)· 支持 Raft/PoA | 可插拔:Raft / Kafka / BFT |
| 国密 | **原生** SM2/SM3/SM4 | 需自行配置国密模块 |
| 部署难度 | **低**(单机 4 节点一条命令) | 高(依赖较多,链码生命周期复杂) |
| 合约语言 | Solidity | Go / Node.js / Java |
| 隐私 | 群签名/环签名 + 权限合约 | **通道(Channel)** + 私有数据集,隔离更强 |
| 吞吐量 | 单链约 1,000–3,000 TPS,集群可线性扩展 | 优化后 5,000+ TPS |
| 国内应用 | 金融、政务、医疗广泛 | 医疗、物流、跨境 |
**选型建议**:
- **国内运营 + 需过合规** ⇒ **FISCO BCOS**(国密原生是决定性优势,部署简单对小团队友好);
- **已有 Go/Java 团队 + 需要强数据隔离** ⇒ Fabric(通道机制在"不同参与方看到不同数据"上更成熟);
- **两者都不要** ⇒ 见 §4.3。
**⚠️ 必须承认的局限**:联盟链的"去中心化"是**准入式**的——节点是已知且授权的,共识只在成员间达成。它能解决"合作方互不信任",**不能**解决"公众可验证"。若后者是硬需求,必须走路线 C。
### 4.3 路线 C:公链 L2(面向公众的资产层)
**为什么是 L2 而不是 L1**:L2 已是行业主流扩容方案,且费用与延迟已达到日常交互可用。**EIP-4844(2024-03 Dencun)blob** 是改变 L2 经济学的关键升级,数据可用性成本降约 90%,此后 L2 处理了以太坊约 60–70% 的交易量;blob 容量在 2026-01 又扩容过一次。
**性能如实说明**(三种口径必须分清,混用是最常见的误导):
| 口径 | 数值 | 说明 |
|---|---|---|
| 理论 TPS | 数万 | 营销材料常用,不具备参考价值 |
| **峰值实测** | 2,000+ | 仅在 meme 币等尖峰时段出现 |
| **常态实测** | **两位数 ~ 低三位数**(Base ≈ 89、Arbitrum ≈ 57) | **这才是规划容量时应使用的数字** |
| L1 对照 | 15–25 TPS | —— |
**费用与终局性**:
| 网络 | 类型 | 常态单笔 | 终局性 |
|---|---|---|---|
| Base | Optimistic | < $0.01 | 秒级确认 / 7 天挑战期 |
| Arbitrum | Optimistic | $0.01–$0.03 | 秒级确认 / 7 天挑战期 |
| Optimism | Optimistic | $0.01–$0.05 | 秒级确认 / 7 天挑战期 |
| zkSync / Linea / Scroll / Starknet | ZK | $0.01–$0.10 | **分钟级 ~ 数小时**(无需 7 天) |
**🔴 一条常被说反的事实**:ZK 相对 Optimistic 的优势是**终局性**(分钟级 vs 7 天挑战期)与**不依赖"存在诚实少数"这一安全假设**;**不是"验证速度更快"**——ZK 的证明生成反而是额外开销。选型时若"提现到 L1 的等待时间"是硬指标,选 ZK;否则 Optimistic 生态与流动性更成熟。
**公链 L2 的代价**:链上数据**全网公开且永久**。因此路线 C 只承载 §3 表格中"链上"那一栏的内容,其余一律不上链。
---
## 5. 敏感数据专项(硬红线)
### 5.1 三类数据的正确做法
| 数据 | ⛔ 禁止 | ✅ 正确做法 |
|---|---|---|
| 登录密码 | 上链(任何形式,含加密) | **Argon2id** 加盐哈希,存关系库;验证在服务端完成(bcrypt 属次选) |
| 银行卡 / 支付账号 | 上链、自建存储 | **Tokenization**:经 PCI-DSS 认证的支付网关生成无意义 Token,链上/业务库只放 Token |
| 实名信息(身份证等) | 上链 | 链下加密存储 + 细粒度权限;链上只放**不可反推**的匿名 ID |
| 私钥 / 助记词 | 上链、服务端明文保存 | 用户自持(硬件钱包 / 设备安全芯片);服务端只做签名验证 |
| 生物特征 | 上链 | 不出设备;仅存比对结果 |
### 5.2 零知识证明能做什么、不能做什么
**能做**:在不公开明文的前提下证明**某个命题为真**(如"该用户已成年""余额充足""身份已核验过")。用户本地生成证明,链上只验证证明,看不到原文。
**不能做**:
- ❌ 不能替代密码存储(它证明"我知道密码",但不解决"密码本身怎么存");
- ❌ 不能防住**输入侧**泄露(客户端被木马,证明生成前原文已丢);
- ❌ 不解决**关联性**(同一个证明反复提交仍可被关联分析);
- ❌ 引入显著的计算与工程复杂度,**不是免费选项**。
**判据**:只有当"必须向链上/第三方证明某个结论、但不想交出原始数据"是硬需求时,才引入 ZK;否则先用 §5.1 的分层方案。
### 5.3 私有链为什么也不是隐私容器
私有链的"私有"指的是**准入**,不是**可见性**。在"全状态复制型"链上,任何拿到节点访问权的人都能直接读底层状态库(LevelDB / RocksDB 等)拿到全量历史数据,且缺少关系库那种**列级加密与动态脱敏**能力。
⚠️ **但不要过度概括**:并非所有联盟链框架都如此——Fabric 的**通道(Channel)**与**私有数据集**、Corda 的 need-to-know 分发,本身就提供可见性隔离。**选型时以具体框架的隔离机制为准,别拿"区块链"这个大类下结论。**
---
## 6. 准入合规(中国境内运营)
### 6.1 适用性判据(**决定成本的第一道闸门**)
《区块链信息服务管理规定》第二条界定适用范围为:*基于区块链技术或者系统,通过互联网站、应用程序等形式,**向社会公众提供信息服务***。
⇒ **按条文文义**:
- **对公众开放**(任何人可访问/可参与节点) ⇒ **落入适用范围**,§6.2 全部条款适用;
- **纯内部使用、不对公众提供任何信息服务** ⇒ 一般不构成该《规定》所称的"区块链信息服务"。
⚠️ **边界模糊地带**:对内系统但**对外提供了查询/展示入口**(如"公众可查存证"页面),实务上极易被认定为"向社会公众提供信息服务"。**开做前应就此点取得书面确认**(备案系统咨询或法律意见),不要自行推定。
### 6.2 若落入适用范围 —— 强制义务清单
| 条款 | 义务 | 时限 / 要求 |
|---|---|---|
| 第 11 条 | **备案** | 提供服务之日起 **10 个工作日**内;变更 **5 个工作日**内;终止 **30 个工作日**前注销 |
| 第 8 条 | **真实身份认证** | 基于组织机构代码 / 身份证号 / 手机号;**未认证不得提供服务** |
| 第 9 条 | **安全评估** | 开发上线新产品 / 新应用 / 新功能前,报网信办安全评估 |
| 第 13 条 | **标注备案编号** | 对外服务的网站、应用程序**显著位置** |
| 第 6 条 | 内容处置能力 | 对禁止内容具备**即时和应急处置**能力;记录备份保存**不少于 6 个月** |
| 第 12 条 | 备案时限 | 材料齐全 ⇒ 20 个工作日内予以备案 |
| 罚则 | 未备案或填报虚假信息 | 责令限期改正;拒不改正或情节严重 ⇒ 警告 + **1 万 ~ 3 万元**罚款 |
**注意**:备案是**持续义务**(第 14 条定期查验),不是一次性动作。备案制度仍在运行中(网信办已发布至第二十四批境内区块链信息服务备案编号,最新批次 2026-07-21)。
### 6.3 删除权 vs 不可篡改(**最难调和的一处冲突**)
《个人信息保护法》第四十七条规定:处理目的已实现/不再必要、停止提供产品或服务、个人撤回同意、违法或违约处理等情形下,个人信息处理者**应当主动删除**;未删除的,**个人有权请求删除**。
这与链上"不可删除"直接冲突。**三种可选解法**:
| 解法 | 做法 | 优点 | 缺点 |
|---|---|---|---|
| **① 链上只放无关联哈希**(首选) | 链上不存个人信息,只存与身份无关的 ID 与哈希;个人信息全在链下,删除在链下完成 | 删除权可满足;链上无需改动 | 需要设计好"链上 ID ↔ 链下身份"的隔离,且隔离层本身要防关联 |
| **② Crypto-shredding** | 敏感数据加密后上链,删除 = 销毁密钥 | 链上数据"逻辑删除" | 密钥管理成为单点;历史密文仍在(若密钥又被恢复则失效) |
| **③ 不上链** | 涉及个人信息的部分一律留在关系库 | 最干净 | 需要业务上接受"这部分不享链上特性" |
**推荐组合:① + ③**。② 仅在"①不可行且必须落链"时启用,并须评估密钥托管风险。
### 6.4 数据出境
若节点/存储部署在境外,或数据需跨境传输 ⇒ 另需按数据出境相关规定评估。**此项取决于你的部署拓扑,本文不预设结论。**
---
## 7. 落地路线(S0–S4)
**核心原则:不一步到位。** 每阶段独立可验收、独立可回滚;**S1 与 S2 已完成 80% 的目标,S3/S4 只在明确需要时才做。**
### S0 · 判定与取证(不写代码)
**动作**:按 §1 逐条核对 P1–P4;按 §2 确定"谁和谁不信任";按 §6.1 确定合规适用性。
**产出**:一页判定表(含每条的**证据**,不是结论)。
**验收**:§2 目标表命中唯一一行;P1–P4 全部有证据支撑。
**退出条件**:若 §2 命中"不需要链"且 P2 不成立 ⇒ **就此结束,不做 S1 之后的任何事**。
### S1 · 链路骨架:只追加审计日志(不引入任何区块链)
**动作**:建立 Merkle 只追加日志,覆盖关键状态变更(余额、权限、订单、配置);提供**包含证明**与**一致性证明**的查询/校验接口;建立**自动校验器**(定时重算根哈希 + 与历史比对,不一致即告警)。
**产出**:日志模块 + 证明接口 + 校验器 + 告警通道。
**验收判据**(可测):
- 篡改任一条历史记录 ⇒ 校验器**在下一轮必报警**(做一次真实的注入测试);
- 提供第三方可独立验证的证明(导出原始证明 + 验证脚本);
- 日志写入对主流程延迟影响 **< 5 ms**(实测)。
**回滚**:日志为旁路写入,停用即恢复,业务无影响。
### S2 · 敏感数据合规化
**动作**:按 §5.1 整改——密码切 Argon2id;卡号切 Tokenization;实名信息与链上 ID 解耦;全库扫描确认**任何链上/日志字段都不含明文敏感数据**。
**验收判据**:
- 对全量链上/日志条目做**正则 + 字段级**扫描,敏感模式命中 **0**;
- 删除请求权可被执行且**可证明**(走一遍真实的删除流程);
- 密钥不在代码库、不在日志、只在密钥管理设施中。
**回滚**:逐项可回退;密码哈希迁移需保留双验证周期。
### S3 · 锚定(让第三方可验证)
**动作**:定时把日志根哈希锚定到公链交易备注字段,或提交可信时间戳服务;对外提供"如何独立验证"的说明。
**验收判据**:任取一个历史时间点,第三方仅凭公开信息**可独立验证**该时刻的根哈希与当前日志一致。
**成本**:取决于锚定频率,按次计费,年成本量级极低(单次仅数百字节)。
**回滚**:仅停止锚定,已锚定记录无需撤回。
### S4 · 按需升级
仅在 §2 明确命中"多方互信"或"公众资产"时才做:
- 多方互信 ⇒ **FISCO BCOS**(部署简单、国密原生)或 Fabric(强隔离);
- 公众资产 ⇒ **公链 L2**(Base / Arbitrum 生态成熟;若提现等待是硬指标则选 ZK 系)。
**前置**:S1–S3 的日志与数据分层**已经是**升级的基础,不要推倒重来。
**升级判据**:出现"第三方要求共同写入"或"资产需要对外流通"的**书面需求**,且已确认 §6 合规路径。
---
## 8. 验收判据汇总(便于后续对照)
| # | 判据 | 通过标准 |
|---|---|---|
| 1 | 篡改可检测 | 注入篡改 ⇒ 校验器下轮必报警 |
| 2 | 链上无敏感数据 | 全量扫描敏感模式命中 = 0 |
| 3 | 删除权可执行 | 真实走通删除流程,且链上不留可关联信息 |
| 4 | 第三方可验证 | 外部方仅凭公开信息可完成验证 |
| 5 | 性能不退化 | 日志旁路延迟 < 5 ms |
| 6 | 合规就位(若适用) | 备案编号已下且已公示;实名、安全评估、6 个月留存齐备 |
| 7 | 有外部监督 | 存在**独立的**验证主体或自动校验,不能只有写入方自己校验 |
⚠️ 第 7 条最易被忽略:**没有任何人去验证的透明日志,等于没有**。
---
## 9. 明确不做(负面清单)
- ⛔ **不做"加密后上链"** —— 满足不了删除权,且形成"历史数据永远更弱"的斜坡(§3)。
- ⛔ **不把"用了区块链"当作安全性的证明** —— 链解决信任,不解决安全。
- ⛔ **不自研链底层** —— 自研需 20 人以上底层团队、年成本超 500 万量级;用成熟框架可省约 60% 人力。除非业务有成熟框架无法覆盖的硬需求。
- ⛔ **不为"防内部篡改"引入多节点共识** —— 检测就够了(§4.1)。
- ⛔ **不在未做 S0 判定前写代码** —— 本方案的最高价值在 §2,不在实现。
- ⛔ **不把敏感数据交给 ZK 兜底** —— ZK 不解决输入侧与存储侧问题(§5.2)。
---
## 10. 事实依据与来源
**合规**(条文原文,权威性最高)
- 《区块链信息服务管理规定》第 2/6/8/9/11/13 条 —— 网信办官网 `cac.gov.cn/2019-01/10/c_1123971164.htm`
- 备案制度运行状态 —— 国家互联网信息办公室境内区块链信息服务备案编号公告(第二十四批,2026-07-21)
- 《个人信息保护法》第四十七条(删除权)
**L2 与费用 / 性能**(⚠️ 均为**公开来源实测值**,非官方;用于量级判断)
- 常态 TPS 与费用:Base ≈ 89 TPS(峰值 159)、Arbitrum ≈ 57 TPS(峰值 2,000+)、Optimism ≈ 130 TPS —— 2026 年第三方实测汇总
- EIP-4844(Dencun,2024-03):L2 数据成本降约 90%,L2 承载以太坊约 60–70% 交易量;blob 容量于 2026-01 再次扩容
- 终局性:Optimistic 7 天挑战期;ZK 系分钟级 ~ 数小时(各网络实测)
- ⚠️ 数字口径提示:**理论值(数万)与峰值(2,000+)不可用于容量规划**,规划应用常态值。
**联盟链选型**
- 部署难度、国密支持、共识机制、隐私机制对比 —— FISCO BCOS 与 Hyperledger Fabric 公开技术文档 + 2026 年第三方对比分析
- 自研链成本量级(20 人团队 / 年 500 万)—— 2026 年行业选型分析,⚠️ 量级参考
**透明日志**
- RFC 6962(Certificate Transparency)—— Merkle 只追加日志、包含证明、一致性证明的规范来源
**⚠️ 勘误记录(对 Google AI Mode 原回答的纠正,保留以便溯源)**
| 原回答说法 | 勘误 |
|---|---|
| L2 现状未提 EIP-4844 | 漏掉改变 L2 经济学的关键升级 |
| "实际最高可处理 2,000+ TPS" | 混淆**峰值**与**常态**;常态为两位数 |
| "ZK 的安全性与**验证速度**更具优势" | 优势是**终局性**与安全假设,不是验证速度 |
| "私有链缺少行级权限、任何节点可读全量" | 对全状态复制型成立,但 Fabric 通道 / Corda 有隔离 ⇒ 过度概括 |
| "Arbitrum Nova 承载 The Beacon" | 举例错误:The Beacon 在 Arbitrum(后支持 Ronin),已退出 Treasure 生态 |
| "Sequregator" | 拼写错误,应为 **Sequencer** |
| 密码哈希仅提 bcrypt/scrypt | 漏 **Argon2id**(当前首选) |
---
*本文档为决策依据,§0/§2 的判定需结合实际业务形态确认后再进入 S1。*