在 2026 年用零知识证明与 FHE 构建真实应用：一份务实指南

零知识证明与同态加密已跨过生产门槛。Apple 公开了用于私有查询和 ML 的生产 HE 用例，Google Wallet 用零知识证明证明年龄，以太坊区块也能在数秒内证明。本指南从信任模型出发，说明这些工具何时有意义、怎样估算成本，以及哪些错误会烧掉预算。

这是工程视角，不是供应商推销。公开测量均附来源；规划区间会明确标注。参考点来自 Wavect 在零知识与前沿技术上的工作。

ZK 和 FHE 能给你什么，普通加密给不了？

标准加密保护的是静态存储和传输中的数据。而你想对数据做点什么的那一刻，就得先解密，于是执行计算的一方看得一清二楚。隐私增强技术堵的就是这个缺口，各有各的路子：

• 零知识证明（ZK）让一方证明某个陈述为真，却不透露为什么为真。“我年满 18 岁”，但不出示出生日期。“这次计算跑对了”，但不用重跑一遍。ZK 的本质是可验证性加上选择性披露。
• 全同态加密（FHE）让服务器在自己读不了的数据上做计算。输入加密着进来，计算加密着跑，结果加密着回去。FHE 的本质是把计算外包给一个永远不许看到数据的运营方。基础概念见我们的术语表条目。
• 安全多方计算（MPC）让多方在谁都不交出自己输入的前提下共同完成一次计算，代价是参与方之间沉重的网络流量。
• 可信执行环境（TEE）在硬件隔离的 enclave 里运行代码。速度接近原生，但你得信任芯片厂商，还得指望侧信道攻击不存在。

它们是不同的信任边界，不是一架严格的阶梯。ZK 与 FHE 除密码假设外还依赖实现、编译器、电路、参数与密钥管理。MPC 增加协议特定的阈值与不合谋假设；TEE 增加硬件、固件、远程证明与侧信道假设。工程问题是哪些假设符合威胁模型和工作负载。

你真的需要这些吗？先跑一遍决策树。

这个领域最昂贵的错误是密码学杀鸡用牛刀。在任何一项技术进入你的架构之前，诚实地回答四个问题：

1. 用户信任你看到他们的数据吗？如果信任，且法律允许，那就用数据库、访问控制、TLS 和静态加密。这不是妥协，这是绝大多数产品的正确架构。PET 解决的是信任问题。没有信任问题，它们什么都解决不了，还花掉不少钱。
2. 是否有第三方需要在看不到底层数据的情况下验证某件事？年龄检查、偿付能力证明、凭证核验、“这段代码跑对了”。这是 ZK 的地盘，也是几个选项里最成熟的。我们的深潜文章：ZK 里什么真正达到了生产就绪。
3. 是否必须让一个不受信的一方在它永远不许看到的数据上做计算？处理健康记录的云服务、一次不能让服务器得知任何查询信息的数据库检索。这是 FHE 或 MPC 的地盘，而且只有在工作负载小而明确时才行得通。现实核查：FHE 里什么能交付、什么还是炒作。
4. “我们看不到你的数据”是核心产品承诺或监管要求，还是一个锦上添花？如果只是锦上添花，一个 TEE 用接近原生的速度就能给你大部分故事。如果它就是产品本身，那就为真正的密码学以及随之而来的工程投入做预算。

注意这个规律：技术选择是从信任模型里推出来的，而不是反过来。那些从“我们想用 FHE”出发、事后再找问题的团队，最后都出现在下面的失败清单里。

"如果用户信任你看到他们的数据，一个数据库就胜过一套密码系统。有意思的项目，是那些这种信任在结构上不可能存在的项目。"

2026 年到底有什么真正跑在生产环境里？

这已经不再是一个研究领域。一份你可以拿给董事会看的部署清单，每一条都附带一个教训：

最清楚的公开 HE 部署集中在私有查询或收窄计算，而不是完整加密后端。许多成功 ZK 部署也只隐藏一个敏感事实。范围纪律是共同分母。

它要花多少钱？2026 年的数字。

我们在架构评审里用的经验法则。这些是用于规划的数量级数字，每篇深潜文章里有精确、有出处的数据：

比绝对数字更重要的是不对称性。ZK 通常把主要成本放在证明端，验证端相对更低；FHE 则在每次加密运算中持续付出成本。但两者都必须按具体系统与工作负载测量，不能把单一原语基准外推到完整产品。

这些项目失败的五种方式是什么？

每一种我们都见过或评审过。它们以可预测的方式失败：

• 1. 一个登录就够的地方用了密码学。团队在同属一家公司的服务之间传 ZK 证明。威胁模型里根本没有对手。结果是一个更慢、更贵、但架构图很唬人的系统。如果你信任运营者，就用访问控制。
• 2. 约束不足的电路。ZK 漏洞的主流类别是电路因为缺少某条约束，接受了本该拒绝的证明。zkFuzz 这类研究工具在 2025 年找到了数十个这样的 Bug，其中包括 zkEmail 广泛使用的 zk-regex 组件里的十一个 (zkFuzz, arXiv 2025)。一个没有电路审计和模糊测试的 ZK 系统不是安全产品，是一项负债。
• 3. Trusted Setup 上抄近路。现实世界里最早的 ZK 攻击不是什么高深数学，而是被搞砸的 Groth16 trusted setup (zkSecurity)。2026 年你已经很少需要按应用做一次 trusted setup：透明证明系统（STARK 家族）彻底绕开了这个仪式。默认选它们。
• 4. 隐私技术到位，用户同意缺席。Apple 发布的 Enhanced Visual Search 用了货真价实的强密码学（FHE 加差分隐私），却默认开启、不问用户，结果在 2025 年 1 月吃了一场公开反弹 (The Register)。完美的数学替代不了一个 opt-in 对话框。监管者和用户评判的是同意流程，不是格密码参数。
• 5. 没有端到端基准就选 FHE。单一原语很快不代表产品可交互。序列化、密文膨胀、key switching、自举、网络与完整操作组合共同决定结果。测完整请求路径，并为硬延迟预算保留 TEE 退路。

怎样界定一个能扛住现实的首个项目？

从上面那些部署里提炼出来的、行得通的模式：

1. 先把那一个真正要紧的秘密隔离出来。不是“把应用做成隐私的”，而是“服务器永远不许得知被查询的电话号码”，或者“场馆永远不许得知出生日期”。一句话，一个秘密，一个验证者。
2. 只让它走昂贵路径。在 Apple 公开的模式中，应用其余部分保持常规，私有查询是边界清楚的 HE 步骤。Google 模式中，年龄检查是边界清楚的 ZK 步骤。
3. 选有人维护的工具，再做基准测试。2026 年做 ZK，这意味着一个 Rust zkVM（SP1、RISC Zero）或 Noir，而不是手写电路。做 FHE，逻辑从 TFHE-rs 开始，BFV 查询从 Apple 的 Swift 库开始。CKKS 已没有一个稳妥的性能默认项：CPU 上测试 Poulpy、Lattigo、SEAL 和 OpenFHE，适用时再加入 FIDESlib 这类 GPU 原生选项。完整工具表和生命周期说明在 ZK 那篇和 FHE 那篇里。
4. 为审计做预算，别只为构建做预算。电路审计加模糊测试是发布 ZK 的固定成本。跳过它，就是别人写漏洞赏金报告时拿你当主角的方式。RISC Zero 为一个在先前多轮审计之后才被发现的 Bug 付了 5 万美元赏金，这说明即便对最顶尖的团队，这件事也有多难。
5. 尽早谈好退路。如果延迟或成本算不拢，应按威胁模型与监管要求评估 TEE。尽早决定比深度集成后再改便宜得多。

还有一个值得点名的驱动力：监管把这个领域往前拉的速度比产品需求更快。按 eIDAS 2.0，每个欧盟成员国必须在 2026 年底前提供数字身份钱包，而该框架明确鼓励零知识风格的选择性披露。European Health Data Space 在健康数据的二次使用上指向隐私增强技术。如果你面向欧盟销售，问题正从“我们为什么要用这个”变成“监管者预期哪些部分要用”。决策框架那篇把监管条目映射到了具体的技术选择。

来源与核验

1. Apple Machine Learning Research (2024). Production homomorphic-encryption use cases and private lookup design. machinelearning.apple.com
2. Google (2025). Open-source zero-knowledge technology for age assurance. blog.google
3. Microsoft Research (2021). Homomorphic encryption in Edge Password Monitor. microsoft.com
4. Mopro (2026). Mobile and browser proving benchmarks. zkmopro.org
5. zkFuzz (2025). Differential fuzzing results across public ZK circuits. arxiv.org
6. zkSecurity (2026). Documented Groth16 setup exploits. zksecurity.xyz