0 Fork 0

Files

T

admin ce8e6ceed9 chore(工作区): 纳入版本控制基线（回收 411 MB 过程产物）

回收 411 MB（470 M → 58.8 M），全部经回收站，可恢复：
- 待清理/（146.2 M，含 relay 分片 128 M 与 42 项过程目录）
- tmp/（32.4 M，按接续棒命名的过程临时区）
- .workbuddy/tmp/（39.5 M）
- 4 份 workbuddy.db 冗余副本（101 M，09-23 事故的坏副本 / 抢救产物）
- tmp/im16/gw/centrifugo 二进制（63.9 M，可重下）+ 缓存残留

入库范围：常驻规则（CODEBUDDY.md / README.md / state.py）、在途接续入口与
接续包、docs/、交付物/、交接单/、归档/、scripts/、.codebuddy/、
.workbuddy/memory/；共 398 件，其中 >60 KB 的 26 件全为文档。

排除（.gitignore）：tmp/、待清理/、运行态日志与缓存、*.db 与 DB 备份整目录、
打包二进制（*.tar.gz / *.tgz）、记忆修复前备份。

2026-09-24 07:51:03 +08:00

45 KiB

Raw Blame History

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

📌 术语：本文以「分布式」指代本项目（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. 三行结论

范围已澄清 ⇒ 237 号文的禁止清单不适用（无发行、无兑换、无撮合、无定价、无衍生品，仅用去中心化技术做存储与查询）⇒ §1 给出唯一仍需处理的合规项。
架构：两套子系统 + 一条窄桥（§2）——A 层可公开但不含明文隐私；B 层不公开、但仍是多节点共识网络（不公开 ≠ 不共识，见 §2.3 纪律 2），中间靠匿名 ID 映射桥接。
隐私保密的最优解不是"选一种强加密"，而是"四层组合"（§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）。大文件不进链。

🔴 自研链的两条硬红线

⛔ 自研的是"链"，不是"密码学"。共识、存储引擎、网络、接口、状态机 —— 这些自研合理；AES-GCM / HMAC / SHA-256 / SM2-SM3-SM4 等国密算法绝不自己实现，一律用成熟库（libsodium / OpenSSL / 国密 SDK）或硬件密码模块。自研密码学 = 事故，且无任何性能理由需要这么做（性能瓶颈在共识与 IO，不在密码学原语）。
⛔ 不重写共识算法的安全性假设。可从 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 的证明时间与内存随输入规模膨胀。

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

选型纪律：

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

3.4.5 三条必须知道的棱角

证明成本要按"批量"算，不是按"逐块"算。12 秒级实时证明需要 16× RTX 5090 级别硬件；小规模私有链应改为批量证明（每 N 秒 / 每批出一个证明）⇒ 硬件门槛大幅下降，代价是确认延迟。⇒ "高性能"要用"低延迟 + 批量证明"换，而不是靠堆硬件。
可验证 ≠ 实现无误。zkVM 的安全性来自数学，但验证者仍须信任证明系统的实现；RISC-V zkVM 的 guest/host 边界是新兴攻击面；经 Groth16 封装后 不再后量子。
"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 金库，承担三件事：

存必须由平台可读的隐私数据（实名、联系方式、支付 Token、凭据哈希、风控日志）；
存用户密钥（§4.3）—— 这是 B 层最容易设计错的一处；
以 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）

🔴 三条必须守的约束：

key 不能是裸明文标识。若 key = user_email，链上所有节点都能看出"哪些记录属于同一邮箱"以及查询分布。⇒ key 应为 HMAC(域密钥, 规范化标识)（即 §5.2 的盲索引），既保留"可等值定位"，又不泄露原文。
低熵 key 必须截断或复合（§5.2 硬约束 1）—— 否则频率分析可还原该字段。
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 化范围"就能覆盖，不必上密码学重武器。

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

🔴 绝不在低熵字段上建盲索引。经典反例：给"HIV 状态"建盲索引 ⇒ 任何有库读权限的人都能看出哪些记录状态相同，几乎等于直接还原该字段。
- 缓解：① 干脆不建（不想暴露就别建索引）；② 复合索引（与其他字段一起哈希）；③ 截断（见下）。
✅ 截断 HMAC 长度以控制每次查询返回行数。目标"平均 N 条/查询"：100 万行、想平均 3 条 ⇒ log2(10⁶/3) ≈ 18 bit。截断还能防"试探性写入探测"（攻击者插入一条记录，看是否产生相同 hash 从而反推）。
- ⚠️ 不随数据量放大索引 ⇒ 仅轻微性能开销（1000 万行时平均选 30 条，应用层解密过滤仍很快）。
✅ 范围查询用 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 因范围澄清已作废，其余架构部分被本文取代）

45 KiB Raw Blame History Unescape Escape