dsh_ai1net_server/docs/分布式数据链路/分布式数据存储与查询-架构设计与隐私保护方案_20260919.md

# 分布式数据存储与查询平台 · 架构设计与隐私保护方案

> 📌 术语：本文以「分布式」指代本项目（2026-09-19 由「去中心化」更名）；引用原文、DAO 专有名词与行业泛指保留原措辞。

> 版本 v1.2 ｜ 2026-09-19 ｜ 状态：**架构已定 · 待评审**
> 主文档：`分布式数据链路-技术方案与落地路线_20260919.md`
> 前一版：`面向公众资产平台与隐私金库-落地方案_20260919.md`（合规判定部分因**范围澄清**已调整，见 §1）
> 本文回答三件事：**范围重定（§1）· 架构落地（§2–§4）· 隐私保密的最优解（§5，本文重点）**

### 📌 v1.1 修订记录（依据用户 2026-09-19 四条修正）

| # | 用户修正 | 本文落点 |
|---|---|---|
| 1 | **B 层要支持多节点共识，只是不公开** | §2.2 架构图 · §2.3 纪律 2 —— 纠正 v1.0"不参与共识"的**过度收窄**；"不公开" ≠ "不共识" |
| 2 | **区块链自研**（便于优化性能与加密）；**对象存储用正规平台方案** | §3.2 选型表改为自研链 ＋ 云对象存储；新增**两条自研红线**（不自研密码学 / 不悄悄削共识假设）＋ 分阶段建议 |
| 3 | **B 层用户信息里还要包含用户密钥** | §4.3（新增）—— ⚠️ 指出这是**全架构最危险处**，必须门限分片存放（B 层只持 1 片），整钥存放 ⇒ A 层零知识失效 |
| 4 | **B 层加密安全优先；可查询内容用 KV：key 便于查询 / value 需解密查看** | §4.2（新增 KV 模型）＋ §3.3.1（B 层查询链路）＋ 三条约束（key 必须盲索引化 / 低熵截断 / key-value 密钥域分离） |

### 📌 v1.2 修订记录

| # | 用户提问 | 本文落点 |
|---|---|---|
| 5 | **"没有比 FISCO BCOS 更好的参考吗？需要 2 层链高性能安全方案，例如 StarkNet 的 zkVM"** | **§3.4（新增整节）** —— 纠正三个概念（zkVM ≠ 共识 ≠ 链）＋ 🔴 给出 **ZK 对 B 层的真正价值 = 解开"要多节点共识 vs 要加密"的死结（节点盲验证）** ＋ 2026 zkVM 实测格局与选型短名单 ＋ 修订后的分阶段路线（自研共识 ＋ 成熟 zkVM 证明 ＋ 云对象存储） |

---

## 0. 三行结论

1. **范围已澄清 ⇒ 237 号文的禁止清单不适用**（无发行、无兑换、无撮合、无定价、无衍生品，仅用去中心化技术做**存储与查询**）⇒ §1 给出**唯一仍需处理的合规项**。
2. **架构：两套子系统 + 一条窄桥**（§2）——**A 层可公开但不含明文隐私；B 层不公开、但仍是多节点共识网络**（不公开 ≠ 不共识，见 §2.3 纪律 2），中间靠匿名 ID 映射桥接。
3. **隐私保密的最优解不是"选一种强加密"，而是"四层组合"**（§5）——存储层非确定性加密 · 查询层盲索引 · 计算层机密计算 · 密钥层门限托管。**单靠任何一层都不成立**，这是本文最重要的判断。

---

## 1. 范围重定与剩余合规项

### 1.1 已澄清：237 号文禁止清单不适用

用户明确：**只用区块链去中心化技术做数据存储与查询**，不做以下任何一项 ——

| 237 号文禁止事项 | 本项目 |
|---|---|
| 法币与虚拟货币兑换 | ✗ 不做 |
| 虚拟货币之间兑换 | ✗ 不做 |
| 作为中央对手方买卖 | ✗ 不做 |
| 为交易提供信息中介与定价服务 | ✗ 不做 |
| **代币发行融资** | ✗ **无代币发行** |
| 虚拟货币衍生品交易 | ✗ 不做 |

⇒ **§1.1 判定：不落入该通知的规制范围。** 前一版方案的连带责任、经营范围禁用字样、支付通道不可得等结论**随之撤销**。

### 1.2 仍需处理的唯一一项：区块链信息服务备案

⚠️ **这一项与 237 号文无关，单独成立**，别因为 §1.1 通过就跳过。

**判据**：《区块链信息服务管理规定》第二条 —— 适用范围是"*基于区块链技术或者系统，通过互联网站、应用程序等形式，**向社会公众提供信息服务***"。

**本项目面向公众提供数据的存储与查询服务 ⇒ 落入适用范围**，需履行：

| 条款 | 义务 |
|---|---|
| 第 11 条 | 提供服务起 **10 个工作日**内备案；变更 5 个工作日内；终止 30 个工作日前注销 |
| 第 8 条 | **实名认证**（组织机构代码 / 身份证号 / 手机号）；**未认证不得提供服务** |
| 第 9 条 | 新产品 / 新应用 / 新功能上线**前**报安全评估 |
| 第 13 条 | 对外服务显著位置**标注备案编号** |
| 第 6 条 | 禁止内容即时处置能力；记录留存 **≥ 6 个月** |
| 第 14 条 | 备案信息**定期查验**（持续义务） |

**成本量级**：这是一个**流程性**要求（提交材料 + 等 20 个工作日），不是架构级改造。⇒ **不影响 §2–§5 的技术设计**，但排期上要留出前置时间。

### 1.3 一条与"数据出境"相关的提醒

去中心化存储（IPFS / Arweave / 公链）的节点分布**天然在境外**。若存的是个人信息，需按数据出境相关规定评估。**若选择"密文出境 + 密钥不出境"，法律定性需专业意见**——本文不预设结论，但这条会影响 §3 的存储选型。

**📌 v1.1 更新**：对象存储已按用户拍板改为**正规云平台托管方案**（可选境内区域）⇒ 该项风险**显著下降**。⚠️ 但**A / B 两层的链节点若跨境部署，仍会触发同一问题** ⇒ 链节点地域在 §3.2 定稿时须一并确认。

---

## 2. 总体架构：两套子系统 + 一条窄桥

### 2.1 为什么必须拆成两套

因为两个需求的安全目标**在数学上相反**：

- **公开可验证**要求数据能被任何人读取与校验；
- **隐私保密**要求数据不能被任何人读取（包括平台自己）。

把它们放进同一套存储 ⇒ **必然二选一失败**（要么隐私泄露，要么公开验证失效）。⇒ 唯一的正解是**两套独立系统**，各自把目标做到极致，中间只留一条**极窄且强审计**的桥。

### 2.2 架构图

```
┌────────────────────────────────────┐  ┌────────────────────────────────────┐
│  A 层 · 分布式存储与查询层         │  │  B 层 · 隐私金库（私有共识链）       │
│  （可公开 / 半公开）                 │  │  （不公开 · 多节点共识 · 授权准入）   │
│                                    │  │                                    │
│  · 密文 blob（用户数据本体）         │  │  · KV：key 可查 / value 加密         │
│  · 盲索引 token（可查询的指纹）      │  │  · 实名 · 联系方式 · 支付 Token      │
│  · 匿名所有者 ID                    │  │  · 凭据哈希 · 风控日志               │
│  · 内容哈希 / 版本链                │  │  · 用户密钥托管（门限分片）           │
│  · 访问控制策略（密文）              │  │  · 私有共识：多节点 · 授权准入        │
│                                    │  │                                    │
│  ⛔ 永不出现：明文隐私、真实身份      │  │  ⛔ 不出公网：仅授权节点可达          │
└─────────────┬──────────────────────┘  └──────────────┬─────────────────────┘
              │                                        │
              │   算法：HMAC(域密钥, userId)            │
              └────────────┬───────────────────────────┘
                           ▼
              ┌────────────────────────────────┐
              │  窄桥 · 匿名 ID 映射表          │
              │  · 独立加密（与两侧均不同密钥）  │
              │  · 双人授权 + 每次访问留痕       │
              │  · 标注：最高价值攻击目标        │
              └────────────────────────────────┘
```

### 2.3 三条架构纪律（不可协商）

| # | 纪律 | 违反后果 |
|---|---|---|
| 1 | **A 层永不出现明文个人信息**（含邮箱、手机号、实名、卡号） | 一旦上链 ⇒ 永久公开且不可撤回 |
| 2 | **B 层不公开，但仍须是多节点共识网络**（私有链 · 授权准入 · 节点不暴露公网） | 单节点存储 ⇒ 既无防篡改能力、也无容错；节点若暴露公网 ⇒ 隐私边界失守 |
| 3 | **窄桥独立加密、独立审计、双人授权** | 桥表泄露 ⇒ A 层全部匿名性失效，**且历史记录永久可关联** |

**第 2 条的关键澄清（2026-09-19 用户修正）**：**"不公开" ≠ "不共识"**。B 层是**私有链**——节点授权准入、数据不出公网，但**共识机制照常运行**（多节点、防篡改、可容错）。此前版本写成"不参与共识"是把"不公开"误推成"单机数据库"，属**过度收窄**。

**第 3 条最易被低估**：匿名 ID 本身是安全的，但**"谁是谁"的映射一旦泄露，链上全部历史记录立即变成实名档案**——且无法撤回。⇒ 桥表按"泄露即灾难"级别设计。

---

## 3. A 层设计：分布式存储与查询

### 3.1 存储什么、存在哪

| 对象 | 存放 | 说明 |
|---|---|---|
| 数据本体 | **密文 blob**（用户侧加密后上传） | 平台/链上只见密文 |
| 可查询性 | **盲索引 token**（HMAC 指纹） | §5.2 详解 |
| 归属 | 匿名 ID | 由 §2 桥表生成 |
| 完整性 | 内容哈希 + 版本链 | 防篡改、可验证历史 |
| 访问控制 | 加密后的策略对象 | 谁能解、何时能解，都加密 |

### 3.2 存储载体选型（2026-09-19 用户拍板后修订）

| 方案 | 特点 | 定位 |
|---|---|---|
| **自研链（本项目）** | **性能与加密策略可按业务定制 —— 这是用户拍板的理由** | ✅ **A 层与 B 层的主链** |
| FISCO BCOS | 国密 SM2/SM3/SM4 原生；PBFT 秒级；单机 4 节点一条命令可起；1,000–3,000 TPS | 过渡方案 / **自研的对照基准与算法参考** |
| Fabric | 通道 / 私有数据集隔离更强；部署复杂、国密需自配 | 需"不同参与方看到不同数据"时 |
| 透明日志 + 公链锚定 | 只提供篡改可检测；成本低一个数量级 | 单方写入、只需可验证性 |
| **对象存储（正规云平台）** | 用户拍板：**用正规平台方案**（OSS / COS / S3 等托管服务） | ✅ 密文 blob 存储（重） |

**建议组合**：**自研链（A 层公开链 ＋ B 层私有链两套共识网络）＋ 正规云对象存储（密文 blob）**。大文件不进链。

#### 🔴 自研链的两条硬红线

1. **⛔ 自研的是"链"，不是"密码学"**。共识、存储引擎、网络、接口、状态机 —— 这些自研合理；**AES-GCM / HMAC / SHA-256 / SM2-SM3-SM4 等国密算法绝不自己实现**，一律用成熟库（libsodium / OpenSSL / 国密 SDK）或硬件密码模块。**自研密码学 = 事故**，且无任何性能理由需要这么做（性能瓶颈在共识与 IO，不在密码学原语）。
2. **⛔ 不重写共识算法的安全性假设**。可从 PBFT / Raft 等**已被形式化研究过的算法**出发做工程优化与裁剪，但要清楚**削掉了哪条安全假设**（如降节点数、放宽超时、简化视图切换），并在文档中留痕。⇒ **"优化性能"最常见的代价是容错阈值下降**，这一点必须在架构评审时被明确讨论。

**自研的代价（如实列出，供排期与预算参考）**：需自建底层团队与运维线；公开参考量级为**20 人以上团队 / 年成本 500 万级**，用成熟框架可省约 60% 人力。⇒ 用户已拍板自研（理由：性能与加密可控），**本文按此执行**，但建议**分阶段**：先以 FISCO BCOS 跑通业务闭环与验收判据，再逐步替换为自研实现，**避免在业务未验证时先投入重资产**。

### 3.3 查询链路（关键：全程无明文）

```
用户发起查询
   │  ① 客户端把查询条件转成 token（HMAC，密钥不出设备）
   ▼
提交 token 到查询接口
   │  ② 链上/索引层按 token 做等值或前缀匹配（只见 token，不见明文）
   ▼
返回匹配的记录指针（密文 blob 地址 / 内容哈希）
   │  ③ 客户端按指针取回密文
   ▼
④ 客户端本地解密 → 得到明文
```

**这条链路的核心性质**：**服务端与链上在任何一步都没有机会看到明文，也没有解密密钥**。⇒ 这是"平台零知识"的实现方式，也是最强的隐私保证。

**代价（必须提前接受）**：
- 服务端**无法**做服务端解密后的业务逻辑（如风控、统计、客服查证）⇒ 这类需求必须走 §5.4 的合规通道；
- 查询能力**受 token 设计限制**（等值易、范围难、模糊难，见 §5.2）。

#### 3.3.1 B 层查询链路（KV 模型 · 授权可解）

A 层是"**平台永不可解**"，B 层是"**平台在授权下可解**"⇒ 两条链路的差异在于**解密权来源**：

```
① 客户端提交 key_token = HMAC(域密钥, 规范化标识)
   ▼
② B 层私有链按 key_token 定位（链上只见 token，不见原文）
   ▼
③ 取回 value 密文（AES-256-GCM）
   ▼
④ 授权判定：本请求是否有权解密该 value？
      · 无 → 返回密文 / 拒绝
      · 有 → 走 §4.5 密钥授权流程（V1: KMS 取 DEK；V2: 门限多角色授权）
   ▼
⑤ 应用层解密并返回（全程审计留痕）
```

**🔴 与 A 层的根本差别（一句话记住）**：

| | A 层 | B 层 |
|---|---|---|
| 数据形态 | 密文 blob ＋ 盲索引 token | **KV**（key 可查 / value 加密） |
| 共识网络 | 公开准入的多节点 | **私有准入的多节点** |
| 平台能否解密 | **永不**（密钥分片，平台只持 1 片） | **授权下可**（受审计约束） |
| 密钥位置 | 用户设备（主） | 分片存 B 层（1 片）＋ 用户设备 ＋ 第三方 |

### 3.4 证明层选型（zkVM 与有效性证明）—— 回应"有没有比 FISCO BCOS 更好的参考"

> 用户 2026-09-19 提问：**"分阶段先用 FISCO BCOS 跑通…没有更好的参考吗？需要 2 层链 高性能安全的方案，例如 StarkNet 的 zkVM"**

#### 3.4.1 先纠正三个容易混的概念

| 概念 | 是什么 | **不是什么** |
|---|---|---|
| **zkVM** | 可验证计算引擎：程序（Rust/RISC-V）跑完，产出"它按规则执行了"的证明 | ⛔ **不是共识**、不给 TPS、不给最终性 |
| **ZK-rollup（Starknet 等）** | **L2 的完整形态** = 结算锚定在 L1 ＋ 有效性证明 ＋ 排序器 | ⛔ 不是"一个 zkVM 产品" |
| **有效性证明（validity proof）** | 让节点**不必重放全部交易**就能确认状态转换正确 | ⛔ 不解决"谁来排序、谁有最终性" |

**⇒ 关键判断：zkVM 是「证明层」组件，不是「链」的替代品。** 把"换成 zkVM 的链"理解成性能方案，是把两个正交的东西搞混了。

**⚠️ 另一处必须澄清**：**Starknet 用的不是通用 zkVM，而是 Cairo 专用语言 ＋ Stwo（circle-STARK / Mersenne31）**。若要"通用 Rust 进、证明出"，应看 **SP1 / RISC Zero / OpenVM**，而不是 Starknet 技术栈。两者性能在同一量级（见 3.4.3），差别在**是否接受专用语言与生态绑定**。

#### 3.4.2 🔴 对本项目最有价值的一点：ZK 恰好解开 B 层的死结

B 层需求是"**加密安全优先**"＋"**要多节点共识**"。这两条**天然冲突**：

> 节点要验证状态转换，就得看到数据；看到数据 ⇒ 加密白做。

**有效性证明正是这个冲突的解**：节点**验证证明**即可确认"状态转换合法"，**全程看不到 value 明文**。⇒ **B 层的每个节点都可以是"盲验证者"**。

这条比"选哪个链框架"重要得多 —— 它意味着 **ZK 在你这里的首要价值是「隐私」，不是「性能」**。

#### 3.4.3 2026 年 zkVM 格局（实测数据，标注口径）

| zkVM | 背景 | 标志性结果 | 生产状态 |
|---|---|---|---|
| **SP1（Hypercube）** | Succinct | **93–99.7% 以太坊区块 < 12 s**（约 160× RTX 4090 或 16× RTX 5090）；**约 $0.02/证明** | ✅ **生产级**（约 90% rollup proving 份额，OP / Base / Unichain 在用） |
| **RISC Zero** | RISC Zero | R0VM 2.0 把单块证明从 **35 min → 44 s**；Boundless 市场已跑 **542 万亿 cycles** | ✅ **生产级**（支撑在线 coprocessor） |
| **OpenVM 2.0** | Axiom ＋ 社区 | 8× RTX 5090 上 **P99 9.8 s** | ✅ 2026-07 起生产版 |
| Jolt | a16z crypto | 32 核 CPU **>100 万 RISC-V cycles/s**，证明约 50 KB | ⚠️ **Alpha，官方明确不建议用于生产** |
| Airbender | Matter Labs（ZKsync） | 单 GPU ethproofs 结果 | ⚠️ 特定 ZKsync OS 版本，⛔ 非通用生产 zkVM |

**硬件成本已大幅下降**：2024 年需 **$300–400K** GPU 集群 / 数小时；2026 年约 **$24–48K** 硬件即可（约 10 秒级）。**证明成本约 45× 下降**，公开 tracker 上单块成本由 1 月 $1.69 降至 12 月 **< $0.04**。

**消费级硬件上的 1 百万 cycle 证明时间**（M3 Max，公开基准归一化）：Stwo ≈ **80 s** ｜ SP1 ≈ **95 s** ｜ RISC Zero ≈ **3 min** ｜ zkSync Boojum ≈ 5 min。⇒ **第一梯队彼此差距已不大**，选型不该只看这一项。

#### 3.4.4 选型建议（可直接执行）

**保守短名单 = SP1 ／ RISC Zero ／ OpenVM。** 依据：Fenbushi Capital（2025-08）对八款 zkVM 的独立基准显示，这三者整体最稳健，且 **GPU prover 内存占用近乎恒定**；而多款更年轻的 zkVM 的**证明时间与内存随输入规模膨胀**。

> ⚠️ **最后一句对我们特别关键**：本项目的**数据量会持续增长**，"随规模膨胀"的实现在两年后就会变成事故。

**选型纪律**：
1. **锁定一个已审计的 release 版本**，并在**自己的程序上**跑基准（⛔ 不信厂商基准，那只是一个已发布的基准，不是中立认证）；
2. 若接受专用语言、且看重 STARK 的透明性与后量子内层 ⇒ 可评估 **Cairo / Stwo** 路线；
3. **⛔ 不要为了"新技术"引入第 4 条运维线** —— zkVM 需要 GPU 资源与证明运维，这笔账要算进预算。

#### 3.4.5 三条必须知道的棱角

1. **证明成本要按"批量"算，不是按"逐块"算**。12 秒级实时证明需要 16× RTX 5090 级别硬件；**小规模私有链应改为批量证明**（每 N 秒 / 每批出一个证明）⇒ 硬件门槛大幅下降，代价是**确认延迟**。⇒ **"高性能"要用"低延迟 + 批量证明"换，而不是靠堆硬件**。
2. **可验证 ≠ 实现无误**。zkVM 的安全性来自数学，但**验证者仍须信任证明系统的实现**；RISC-V zkVM 的 **guest/host 边界是新兴攻击面**；经 Groth16 封装后 **不再后量子**。
3. **"L2"这个词在本项目里可能不成立**。L2 的定义要素是"**结算锚定在某个 L1**"。若 A / B 两层都是你自己的链、没有要锚定的公链 ⇒ 准确叫法是 **"应用链 / 主权链 ＋ 有效性证明"**，不是二层链。⛔ 术语用错会在评审与合规材料里连带出错。

#### 3.4.6 修订后的架构结论（取代 §3.2 的"分阶段建议"）

> **共识与证明必须分开做，两者正交、都不可省：**
> **共识（自研，负责排序与最终性）＋ 有效性证明（成熟 zkVM，负责状态转换正确性）**

- **共识决定 TPS 上限** ⇒ 这是自研链要优化的地方（用户方向正确）；
- **证明决定验证成本与隐私强度** ⇒ 这里**不要自研**，直接用成熟 zkVM（正好落在 §3.2 红线 1"不自研密码学"上）；
- **A 层**（公开）：证明用于**扩容 + 公众可验证**（任何人都能验证状态转换）；
- **B 层**（私有共识）：证明用于**节点盲验证** —— 即 3.4.2 那个死结的解，**这是 ZK 在本项目的第一价值**。

**参考对标（比 FISCO BCOS 更贴近本项目）**：**Matter Labs 的 Prividium** —— 面向受监管金融机构的**私有许可链**，据报道已有 5 家美国银行存款规模合计超 **$600B** 通过 Cari Network 在其上构建；其 Elastic Chain 方向即"多条应用专用 ZK 链共享证明层"。⚠️ 该数据来自公开报道与厂商口径，**作为方向参照而非中立认证**。

**⇒ 回答用户的问题**：**有更好的参考，但不是"换一条更快的链"，而是"把证明层加进来"。** FISCO BCOS 仍适合作为**跑通业务闭环的临时底座**（部署最快、国密原生），但它只是脚手架；**目标形态应为"自研共识 ＋ 成熟 zkVM 证明 ＋ 云对象存储"**。

**分阶段（修订版）**：

| 阶段 | 底座 | 目的 |
|---|---|---|
| 步骤 1 | **FISCO BCOS** | 跑通业务闭环、**冻结全部验收判据**（≤ 数周量级，纯脚手架） |
| 步骤 2 | 自研共识替换 | 优化排序与最终性；⛔ 不削容错假设 |
| 步骤 3 | **接入 zkVM 证明层** | 先做 A 层可验证性 → 再做 B 层盲验证（3.4.2） |
| 步骤 4 | 按需 | 专用硬件 / 证明市场（外包证明）以规避 GPU 资产 |

⚠️ **顺序纪律**：**步骤 3 依赖步骤 1 冻结的判据**。若判据未冻结就引入证明层，"优化"会失去基准，无法判断是否真的变好。

---

## 4. B 层设计：隐私金库（私有共识链）

### 4.1 定位

**B 层 = 私有链上的加密 KV 金库**，承担三件事：

1. 存**必须由平台可读**的隐私数据（实名、联系方式、支付 Token、凭据哈希、风控日志）；
2. 存**用户密钥**（§4.3）—— 这是 B 层最容易设计错的一处；
3. 以 **KV 形式对外提供"可查询但不可直接读"的访问**（§4.2）。

与 A 层的区别：**B 层平台能解密（受审计约束），A 层平台解不开**。但**两层都是多节点共识网络**，差别只在**是否公开准入**（用户 2026-09-19 修正）。

### 4.2 KV 模型：key 可查、value 加密（用户 2026-09-19 拍板）

**结构**：`key → value`，其中 **key 可索引（便于查询），value 密文（取回后解密查看）**。

| 部分 | 处置 | 说明 |
|---|---|---|
| **key** | **规范化 → 盲索引化 → 入链** | ⚠️ 裸明文 key 会把"谁在查谁"暴露给所有节点 ⇒ 见下方约束 1 |
| **value** | **AES-256-GCM 加密**（每记录随机 IV，或按需 SIV） | 密文直接落链；解密需密钥授权 |
| **查询** | 按 key 定位 | 等值查询 O(1) 级；范围 / 模糊见 §5.2（bucket 化 / n-gram） |

**🔴 三条必须守的约束**：

1. **key 不能是裸明文标识**。若 `key = user_email`，链上所有节点都能看出"哪些记录属于同一邮箱"以及查询分布。⇒ **key 应为 `HMAC(域密钥, 规范化标识)`**（即 §5.2 的盲索引），既保留"可等值定位"，又不泄露原文。
2. **低熵 key 必须截断或复合**（§5.2 硬约束 1）—— 否则频率分析可还原该字段。
3. **value 的加密密钥必须与 key 的派生密钥不同源**（域分离）⇒ 攻破 key 空间不能推导出 value 密钥。

**这个模型的一大工程收益（值得记住）**：**key 与 value 的加密可独立演进**——将来升级 value 加密算法时，key 索引结构完全不用动；反之亦然。这是 KV 相比"整体加密文档"的决定性优势。

### 4.3 用户密钥的托管（存 B 层，但设计要当心）

用户密钥（用于解密 A 层数据本体）**存放在 B 层**。⚠️ 这里是整个架构**最危险的一处**：

> **若 B 层存的是"可直接使用的用户私钥"，则 B 层一旦被攻破 ⇒ A 层的"平台零知识"当场失效，全部用户数据可解。**

⇒ **必须门限分片存放，而不是整钥存放**：

| 方案 | 做法 | 结果 |
|---|---|---|
| ⛔ 整钥存 B 层 | 用户私钥（或其加密态 ＋ 平台持解密钥）直接存 | 平台单方即可解密**全部**用户数据 ⇒ 零知识失效、B 层成为单点 |
| ✅ **门限分片存 B 层**（推荐） | 用户密钥 **Shamir 分片**，如 **2-of-3**：用户设备 1 片 ＋ B 层 1 片 ＋ 第三方托管 1 片；**B 层只持 1 片** | B 层被攻破也**拿不到完整密钥**；用户丢设备仍可恢复 |

⇒ **B 层存的是"密钥分片"，不是"密钥"**。这一条让"用户可恢复"与"平台不可解密"**同时成立**（与 §5.4 一致）。

### 4.4 三档实现

| 档 | 做法 | 平台能否解密 | 代价 |
|---|---|---|---|
| **V1 加密库 + KMS**（基线） | PostgreSQL + 应用层 AES-256-GCM 字段级加密；KEK 在 KMS/HSM | 能（受审计） | 平台是信任单点 |
| **V2 门限解密**（推荐） | 密钥 N-of-M 分片（Shamir / MPC）；解密需多角色授权 | **单方不能** | 工程复杂、有延迟 |
| **V3 客户端加密 + 私有链存储** | 用户设备本地加密，密钥不出设备 | **完全不能** | 见 §5.5 |

### 4.5 密钥管理硬要求（V1 / V2 共担）

- **信封加密**：每租户/每数据集一把 DEK，DEK 用 KMS 里的 KEK 加密后与元数据同存；
- **DEK 缓存**：启动或首次访问时解密一次并缓存（TTL 10–15 min），**不要每行都调 KMS**（暖态约 1–3 ms/次）；
- **无停机轮换**：DEK 版本化 —— 写用 v2，读先试 v2 再回落 v1，批量回填；
- **信任拆分**：盲索引的 salt / pepper **存 KMS 或 HSM**，⛔ 绝不入库；
- 密钥**绝不**出现在：代码库、明文配置、日志、备份目录、工单、聊天记录。

---

## 5. 用户隐私保密：有没有更好的办法

**这是本次的核心问题，答案分四层。**

### 5.0 先纠正一个提问方式

**不存在"选一种最强加密就完事"的方案。** 隐私保密面对的是一个**根本矛盾**：

> **加密越强 ⇒ 越不可查询；越可查询 ⇒ 泄露越多。**

随机 IV 的 AES-GCM 每次加密同一明文都产生不同密文 —— 这是你要的安全属性，**也正是数据库无法回答 `WHERE email = 'x'` 的原因**（两串密文永不相等，索引失效、JOIN 失效、LIKE 无望、ORDER BY 变成随机序）。

⇒ **所以要回答的问题不是"泄不泄露"，而是"泄露多少可以接受、以及用什么手段把这个泄露压到最小"。**

**更好的办法 = 分层组合，每层解决不同问题。**

### 5.1 四层组合（推荐架构）

| 层 | 技术 | 解决什么 | 泄露/代价 |
|---|---|---|---|
| **L1 存储层** | **非确定性加密**（AES-256-GCM，随机 IV / AES-SIV 视场景） | 数据本体保密 | 无泄露；但不可查询 |
| **L2 查询层** | **盲索引**（HMAC(域密钥, 规范化明文)，截断，每租户盐） | 恢复**等值 / 前缀**查询 | 只泄露"两行是否相等"，可控 |
| **L3 计算层** | **机密计算 TEE**（SEV-SNP / TDX） | 必须明文计算时的保护 | 开销 **2–10%**；信任硬件厂商 |
| **L4 密钥层** | **信封加密 + 门限托管** | 密钥不出设备 / 可恢复 | 工程复杂度 |

**一个常见失败模式**：只做 L1（加密了但没法用）或只做 L2（能查了但泄露失控）。**必须有分层。**

### 5.2 L2 详解：可查询加密的五种方案对比

| 方案 | 支持查询 | 泄露什么 | 强度 | 判断 |
|---|---|---|---|---|
| **确定性加密**（AES-SIV / 固定 IV） | 等值 | **频率分布 + 行间相等模式** | 中 | ⚠️ 低基数字段（性别、状态）是**频率分析的完美靶子**；仅适合高基数不透明 ID |
| **盲索引**（HMAC 列） | 等值 | **仅"是否相等"**（比 OPE 泄露少） | 中 | ✅ **工程首选**。密文列保持非确定性，另存一列 HMAC |
| **N-gram 分词哈希** | 前缀 / 中缀 | 片段频率可统计 | 中低 | 索引膨胀 **2–4×**；用于前缀模糊 |
| **加密布隆过滤器** | 包含判断 | 中 | 中 | 特定场景 |
| **保序加密 OPE** | 范围 / 排序 | 🔴 **完整顺序** | **低** | ⛔ **已死** —— Naveed 等（CCS 2015）推断攻击可利用公开辅助分布（人口统计）**直接还原明文** |
| **SSE / FHE** | 关键词等值 / 任意 | 理论极少 | 高 | 性能代价极高，见 §5.3 |

**⇒ 结论：80% 的敏感字段查询是"等值 + 粗粒度范围"，用"非确定性加密 + 盲索引 + bucket 化范围"就能覆盖，不必上密码学重武器。**

#### 盲索引的三条硬约束（血泪经验）

1. 🔴 **绝不在低熵字段上建盲索引**。经典反例：给"HIV 状态"建盲索引 ⇒ 任何有库读权限的人都能看出哪些记录状态相同，**几乎等于直接还原该字段**。
   - 缓解：① **干脆不建**（不想暴露就别建索引）；② **复合索引**（与其他字段一起哈希）；③ **截断**（见下）。
2. ✅ **截断 HMAC 长度以控制每次查询返回行数**。目标"平均 N 条/查询"：100 万行、想平均 3 条 ⇒ `log2(10⁶/3) ≈ 18 bit`。截断还能防"试探性写入探测"（攻击者插入一条记录，看是否产生相同 hash 从而反推）。
   - ⚠️ 不随数据量放大索引 ⇒ 仅轻微性能开销（1000 万行时平均选 30 条，应用层解密过滤仍很快）。
3. ✅ **范围查询用 bucket 化，不用 OPE**。把数值/时间映射到桶（月、$10 区间）再建 token；粒度越粗泄露越少、索引越小，代价是**应用层过滤的假阳性**（典型放大 1.2–1.5×）。
   - 学术对照：256 桶覆盖 10¹¹ 值时每桶约 3.9×10⁸ 个值，而 OPE 泄露的是**双射排序** —— 声明式 SQL 代理的研究已证明 bucket 泄露**严格小于 OPE**。

#### 实测性能与存储账（可直接用于容量规划）

| 项目 | 数值 |
|---|---|
| 等值查询（确定性加密或盲索引） | 存储开销 **1.1–1.3×**；p95 延迟 **+5–15 ms** |
| 前缀查询（n-gram） | 索引膨胀 **2–4×**；建议限制前缀字段数量 |
| 范围查询（bucket 化） | 假阳性放大 **1.2–1.5×**；端到端 p95 **+10–30 ms** |
| 全文检索（独立加密检索服务） | 索引 **2–5×** 原文；写入 **+20–80 ms**；读多一次网络跳 |

### 5.3 L3 详解：需要"在明文上算"时选什么

| 维度 | **TEE**（SGX/TDX/SEV-SNP） | **MPC** | **FHE** |
|---|---|---|---|
| 防"被攻破的 OS / 虚拟机监控器" | ✅ 设计如此 | ✅ 若协议假设成立 | ✅ 服务端无明文 |
| 侧信道暴露 | **高**（微架构 / 中断 / 故障注入） | 较低（但输出仍可能泄露） | 避开 TEE 边界；实现与元数据可泄露 |
| 对硬件厂商的信任 | **高** | 低 | 低 |
| 对手不串谋的假设 | 低-无 | **强依赖**（通常需要诚实多数） | 通常无（门限解密会引入） |
| 远程证明 | **必需** | 非硬件 | 依赖电路与密码学评估 |
| **性能开销** | ✅ **2–10%**（SEV-SNP）；TDX 3–10%；SGX 5–20% 且受 EPC 内存限制 | 受网络限制（约 1 ms 级延迟）；批处理可降 2–4 个数量级 | 🔴 **1,000–10,000×**（三到四个数量级） |
| 成本 | **最低溢价** | 较高（多方 + 协议开销） | **最高** |

#### 🔴 关于 FHE 的如实说明（最容易吹过头的技术）

**能上生产的形态只有一种：窄模式的私有查找。**

已落地的生产案例清一色是**私有信息检索（PIR）**——小查询、有界计算、可容忍异步延迟：
- **Apple Live Caller ID Lookup**（iOS 18+，BFV 方案，已开源 `swift-homomorphic-encryption`）——iPhone 向服务端核验陌生来电，**不泄露号码**；
- **Microsoft Edge Password Monitor** —— 密态比对失泄密语料库；
- **Zama Protocol**（以太坊主网 2025-12）—— TFHE 实现加密余额与隐私转账，吞吐 **数十 TPS**。

**⛔ 反面事实**：**没有任何公司把整个后端跑在 FHE 上**，包括最有钱的那些。通用/实时计算仍慢 3–4 个数量级。**"把后端整体同态加密"是当前不成立的目标。**

**选型口诀**：**逻辑与比较用 TFHE，机器学习用 CKKS，精确查找用 BFV/BGV**。库首选：TFHE-rs（TFHE）、`swift-homomorphic-encryption`（BFV 私有查找）；CKKS 需自测 Poulpy / Lattigo / SEAL / OpenFHE / GPU 原生方案（如 FIDESlib）。

#### ⚠️ TEE 也要如实说明：它是"移动靶"不是一次性证明

- 历史攻击：**Foreshadow**（推测执行破 SGX 机密性）、**Plundervolt**（欠压破 SGX 完整性）、**中断类攻击**破 SEV-SNP / TDX；**2026 年 AMD 仍发公告 AMD-SB-3034**（SEV-SNP 路由错配，特权攻击场景下完整性可被破坏）。
- **实践数据**：对 179 个开源 TEE 项目的学术分析发现 **约 1/3 绕过了官方 SDK 的密码学 API**，另有相近比例存在不安全编码 ⇒ **硬件保证强，但软件实现能把它毁掉**。
- 结论：**TEE 可用，但要把它当作持续的系统安全工程目标，而不是买来就有的证明。**
- ✅ **最实用的姿势**：**用 TEE 做密钥释放**（KMS 仅在远程证明通过时才释放密钥）—— 这把密钥的使用收进硬件隔离，显著缩小主机被攻破时的爆炸半径。

### 5.4 L4 详解：密钥托管与恢复（解决"丢了就没了"）

这是**V3（客户端加密）最大的软肋**：用户丢钥 = 数据永久丢失。**更好的办法是门限密钥托管。**

| 方案 | 做法 | 优点 | 缺点 |
|---|---|---|---|
| 用户独持（纯 V3） | 密钥只在设备 | 平台零知识最彻底 | **丢钥即永久丢失** |
| **门限托管**（推荐） | 主密钥 **Shamir 分片**分给 N 方（用户设备 + 平台 + 用户指定受托方…），M-of-N 可重建 | 可恢复；**单方拿不到完整密钥** | 需多方协作、有延迟 |
| 社交恢复 | 指定守护人集，多数同意可重置 | 体验好 | 守护人被串通/胁迫 |
| 托管式（平台持钥） | 平台保管 | 体验最好 | **平台零知识失效** |

**建议**：**"用户设备持 1 片 + 平台持 1 片 + 用户指定第三方持 1 片"，2-of-3 恢复**。⇒ 平台**单方无法解密**（零知识仍成立），但**用户丢设备可恢复**（不再是灾难）。这是本方案对"V3 硬代价"的正面解法。

**与 B 层的关系**：平台持的那 1 片**即落在 B 层**（§4.3）⇒ B 层存的是**密钥分片**而非整钥。⚠️ 这是本方案与"B 层存用户密钥"这条需求**唯一相容的实现方式** —— 若 B 层存整钥，A 层的零知识承诺立刻作废。

### 5.5 综合推荐（一句判据）

> **按"平台是否需要读到明文"分档，而不是按"数据有多敏感"分档。**

| 数据类别 | 方案 | 理由 |
|---|---|---|
| 数据本体（用户自己的数据） | **A 层 + 客户端加密 + 门限托管**（§3.3 + §5.4） | 平台不该看见，且用户丢钥可恢复 |
| 需等值/前缀检索的字段 | **盲索引（截断 + 每租户盐，salt 在 KMS）** | 泄露最小、成本最低 |
| 需范围检索的字段 | **bucket 化 token**（⛔ 不用 OPE） | OPE 已被证明可还原明文 |
| 需明文计算的极敏感子集 | **TEE 隔离区 + 远程证明门控的密钥释放** | 开销仅 2–10%，但须接受硬件信任 |
| 需向第三方证明"结论为真" | **ZK 证明**（只证明命题，不交数据） | 与 FHE 互补：ZK 证明事实，FHE 计算密文 |
| 必须平台可读（实名/客服） | **B 层 V1/V2** | 这是合规与运营的现实需要 |
| **⛔ 绝不用** | **加密后上链（长期存）** | 不满足删除权；密钥轮换不可行 ⇒ "历史数据永远更弱"的斜坡 |

### 5.6 一个所有人都忘的泄露面：元数据

**加密保证的是"内容"，不是"模式"。** 以下信息**FHE 也不保护**：
- **访问模式**（何时查了哪条）
- **搜索模式**（同样的查询反复出现 ⇒ 可关联）
- **时间与频率**（数据量、更新节奏）
- **记录数量与大小**

**缓解手段**：查询填充（定长/填充响应）、批处理混淆、延迟随机化、门限解密策略、输出过滤。⇒ **这些不是可选项，是"号称加密但被流量分析打穿"的分水岭。**

---

## 6. 验收判据

| # | 判据 | 通过标准 |
|---|---|---|
| 1 | A 层零明文隐私 | 全量链上/索引条目做正则 + 字段级扫描，敏感模式命中 **0** |
| 2 | 服务端不可解密 | 用平台全部权限（含 DBA + KMS 管理员）尝试解密 A 层数据 ⇒ **失败** |
| 3 | 匿名性成立 | 关联性测试：仅凭公开数据无法反推或交叉关联出真实身份 |
| 4 | 桥表受控 | 双人授权 + 每次访问留痕；独立密钥；访问日志与业务日志分离 |
| 5 | 盲索引泄露受控 | 查询平均返回行数在目标区间（如 3 ± 2）；单字段频率分布测试无异常 |
| 6 | 密钥不出金库 | 密钥只在 KMS/HSM；代码 / 日志 / 备份零命中；轮换演练成功 |
| 7 | 可恢复 | 模拟用户丢失设备 ⇒ 门限恢复流程可重建数据（真跑一遍） |
| 8 | 删除权可执行 | 真实走通删除；链上不留可关联信息 |
| 9 | 篡改可检测 | 注入篡改 ⇒ 校验器下轮必报警 |
| 10 | 元数据泄露已评估 | 有访问/搜索模式的缓解措施，且有流量分析演练 |
| 11 | 备案就位 | 备案编号已下且已公示；实名、安全评估、6 个月留存齐备 |
| 12 | **B 层共识有效** | 停 1 个节点仍可写入与查询（容错演练）；新增节点须授权准入（不满足则说明"共识"名不副实） |
| 13 | **B 层 key 不泄露标识** | 抽样全量 key：**无法从 key 直接读出邮箱 / 手机号等原文** |
| 14 | **用户密钥为分片态** | 仅凭 B 层全部数据与全部权限，**无法重建任何用户的完整密钥**（真做一次尝试） |

⚠️ **第 2 条是本方案的立身之本**：如果平台某条路径能解密 A 层数据，那"零知识"就是宣传而非事实。

---

## 7. 分阶段落地

| 阶段 | 内容 | 退出条件 |
|---|---|---|
| **S0** | 确定 A/B 数据边界（哪些字段走哪层）；发起备案 | 数据分类表完成；备案已提交 |
| **S1** | **B 层 V1**：字段级加密 + KMS + 审计 + 删除流程 | 判据 6、8 通过 |
| **S2** | **A 层存储**：客户端加密 + 密文 blob 存储 + 版本链 | 判据 1、9 通过 |
| **S3** | **查询层**：盲索引（截断 + 每租户盐）+ bucket 化范围 | 判据 5 通过；等值查询 p95 达标 |
| **S4** | **窄桥**：匿名 ID + 独立加密映射表 + 双人授权 | 判据 3、4 通过 |
| **S5** | **密钥层**：门限托管 + 恢复流程 | 判据 7 通过（真跑恢复演练） |
| **S6** | **自研链替换**（用户已拍板方向）—— 先用 FISCO BCOS 跑通业务闭环并冻结判据，再逐步替换共识 / 存储 / 接口层；⛔ 密码学原语始终用成熟库 | 自研链通过**全部既有判据**（尤其判据 9 篡改可检测、判据 2 服务端不可解密）；容错演练通过 |
| **S7** | **按需**：TEE 隔离区（+ 证明门控密钥释放）；窄模式 FHE | 有明确需求与预算 |

**顺序纪律**：
- **S4 桥必须先于 A 层对外开放**（否则匿名性不成立）；
- **S5 必须在用户大规模上传数据之前**（否则无法安全迁移已加密数据）；
- **S6 是可选层** —— 不要为了技术新颖而引入 TEE / FHE（它们各自带来新的运维线和攻击面）。

---

## 8. 负面清单

- ⛔ **不用保序加密** —— 泄露完整顺序，Naveed 等（CCS 2015）已证明可结合公开统计分布还原明文；
- ⛔ **不给低熵字段建盲索引** —— 等于直接暴露该字段（HIV 反例）；
- ⛔ **不把加密后数据长期上链** —— 删除权不满足 + 密钥轮换不可行；
- ⛔ **不追求"后端整体 FHE"** —— 慢 3–4 个数量级，无一家公司做到；
- ⛔ **不把 TEE 当一次性证明** —— 是移动靶（Foreshadow / Plundervolt / AMD-SB-3034）；
- ⛔ **不假设"加密了就安全"** —— 元数据 / 访问模式 / 搜索模式不加密；
- ⛔ **不让 A 层任何路径能解密** —— 否则零知识是宣传；
- ⛔ **不在 S5 完成前让用户大规模上传** —— 密钥方案变更会导致存量数据无法迁移；
- ⛔ **不自研密码学** —— 链可以自研（用户已拍板），但 **AES-GCM / HMAC / SHA-256 / SM2-SM3-SM4 绝不自己实现**，一律用成熟库（libsodium / OpenSSL / 国密 SDK）或硬件密码模块。**自研密码学 = 事故**（§3.2 红线 1）；
- ⛔ **不悄悄削共识安全假设** —— 可从 PBFT / Raft 出发做工程优化与裁剪，但必须写清**削掉了哪条假设**并在评审中讨论；⚠️ "优化性能"最常见的代价是**容错阈值下降**（§3.2 红线 2）；
- ⛔ **不在 B 层整钥存放用户密钥** —— 必须门限分片（B 层只持 1 片），否则 B 层被攻破 ⇒ A 层零知识当场失效（§4.3）；
- ⛔ **不用裸明文做 KV 的 key** —— 必须是盲索引 token（`HMAC(域密钥, 规范化标识)`），否则链上节点可看出"哪些记录同属一人"（§4.2 约束 1）；
- ⛔ **不用统一密钥同时派生 key 与 value 的加密密钥** —— 必须域分离（§4.2 约束 3）；

---

## 9. 来源

**可查询加密与泄露**
- 盲索引 / 确定性加密 / OPE / SSE 的泄露对比与工程实践 —— 2026 年可搜索加密工程手册；.NET 加密实践指南（五种方案矩阵）；中文密文检索选型分析
- 🔴 **OPE 推断攻击** —— Naveed, Kamara, Wright, "Inference Attacks on Property-Preserving Encrypted Databases", CCS 2015
- **盲索引截断与低熵字段风险**（含"平均 N 条/查询"的比特数计算）—— Ciphersweet 安全讨论
- **bucket 化泄露严格小于 OPE 的形式化证明 + 1M 行医疗记录实测** —— Springer, "Dual Blind Indexes for Queryable Column-Level Encryption"（256 桶 / 10¹¹ 值 ⇒ 每桶约 3.9×10⁸ 值）
- 性能与存储账（+5–15 ms / 1.1–1.3× 等）—— 2026 CTO 实践手册

**机密计算 / MPC / FHE 三方对比**
- TEE 开销（SEV-SNP 2–10%、TDX 3–10%、SGX 5–20% 且受 EPC 限制）、历史攻击（Foreshadow、Plundervolt、SEV-SNP/TDX 中断攻击）、**AMD-SB-3034**、179 个开源 TEE 项目约 1/3 绕过官方密码学 API —— 2026 年机密计算对比分析 + 独立基准
- MPC 与 FHE 性能（ABY3 十亿级 AND 门/秒；SECRECY 1 亿 shares 约 2 秒；SPDZ 实现层漏洞）—— 同上
- **FHE 生产现状**（Apple Live Caller ID、Apple Enhanced Visual Search、Microsoft Edge Password Monitor、Zama Protocol 数十 TPS；1,000–10,000× 开销；"没人把后端跑在 FHE 上"）—— 2026 FHE 生产现状分析（含厂商数据标注）
- **FHE 方案选择**（TFHE 逻辑 / CKKS ML / BFV 精确查找）与库推荐 —— 同上

**合规**
- 《区块链信息服务管理规定》第 2/6/8/9/11/13/14 条 —— 网信办 2019-01-10
- 备案运行状态 —— 网信办境内区块链信息服务备案编号公告（第二十四批，2026-07-21）

**技术选型**
- FISCO BCOS / Fabric 对比（国密、共识、部署、隔离）—— 公开技术文档 + 2026 第三方分析
- RFC 6962（Certificate Transparency）—— Merkle 只追加日志规范

**zkVM 与有效性证明（v1.2 新增）**
- zkVM 生产格局与实测（SP1 Hypercube 93–99.7% 以太坊区块 <12 s / 约 $0.02 每证明 / 约 160× RTX 4090 或 16× RTX 5090；RISC Zero R0VM 2.0 35 min→44 s；OpenVM 2.0 8× RTX 5090 P99 9.8 s；Jolt 32 核 >100 万 cycles/s 但为 Alpha；Airbender 为 ZKsync OS 特定版本）—— 2026 年 ZK 生产就绪度分析（含厂商数据标注）+ 独立基准汇总
- **八款 zkVM 独立基准**（SP1 / RISC Zero / OpenVM 整体最稳健；GPU prover 内存近乎恒定，年轻实现随输入规模膨胀）—— Fenbushi Capital，2025-08
- 消费级硬件百万 cycle 证明时间（Stwo ≈80 s / SP1 ≈95 s / RISC Zero ≈3 min）—— 2026 年公开基准归一化
- 证明成本下降幅度（约 45×；单块成本 $1.69 → <$0.04）—— ethproofs 公开 tracker / 2026 分析
- zkVM 内部引擎（STARK ＋ recursion / multilinear / sum-check）与后量子性说明 —— 2026 年可验证计算技术综述（含 a16z 对 Jolt 的评估）
- **Prividium**（Matter Labs 面向受监管金融机构的私有许可链；据报道 5 家美国银行存款合计超 $600B 经 Cari Network 构建）—— ⚠️ 公开报道 + 厂商口径，**作方向参照，非中立认证**

**⚠️ 提示**：§1.2 备案适用性、§1.3 数据出境定性、以及"平台零知识"与司法配合义务的关系，建议取得执业法律意见后定案。本文为技术方案，不构成法律意见。

---

*相关文档：`分布式数据链路-技术方案与落地路线_20260919.md`（通用判定与三档路线）｜`面向公众资产平台与隐私金库-落地方案_20260919.md`（其 §1.1 因范围澄清已作废，其余架构部分被本文取代）*