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

零知识证明与全同态加密在过去两年跨过了一条线。Apple 在数亿部 iPhone 上跑 FHE。Google Wallet 用一个零知识证明来证明你的年龄。证明一整个以太坊区块如今只需几秒，而不是几分钟。可即便如此，大多数以“我们用 ZK 吧”或“我们用 FHE 吧”开局的项目仍然会失败，因为技术从来就不是那个该先问的问题。这篇指南就是我们在写下第一行电路代码之前使用的决策框架：这些工具什么时候有意义、2026 年它们的成本是多少，以及团队在它们身上烧掉预算的五种方式。

这是工程视角，不是供应商推销。下面每个数字都有出处；凡是供应商的预测而非已交付的结果，我们会明说。参考点来自 Wavect 在零知识与前沿技术上的工作。

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

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

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

把它想象成一架信任阶梯。ZK 只要求你信任证明系统的数学。FHE 要求你信任密码学。MPC 要求你信任多数参与方保持诚实。TEE 要求你信任 Intel、AMD 或 NVIDIA。一个普通数据库则要求你信任运营者。阶梯每往下一级，就更快也更便宜。工程上的问题从来不是“哪个最安全”，而是“你的威胁模型允许你走到阶梯的哪一级”。四者的深度对比见 ZK vs FHE vs MPC vs TEE。

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

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

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

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

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

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

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

两件事很扎眼。第一，每一个成功的 FHE 部署都是一次私有查询或一段收窄的计算，从来不是“把我们整个后端加密着跑”。第二，成功的 ZK 部署都是把单个敏感事实藏在一个证明后面，而不是试图让整个应用零知识化。范围纪律是它们的共同点。

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

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

比绝对数字更重要的是不对称性。ZK 对证明者贵一次，之后对每个验证者几乎免费，所以它适合“证明一次、到处验证”的产品。FHE 每一次运算都贵，所以它目前只适合小而高风险的计算，别的都不行。如果有人给你报的 FHE 基准好得离谱，查一下他们是不是在引用一篇 MPC 论文。把这两者混为一谈，是这个领域内容里最常见的单一错误，我们在 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 扛交互式负载。1,000 倍以上的开销意味着任何用户实时等待的东西都不在范围内，加密的 LLM 聊天离实用还有数年。在融资 PPT 里承诺它的团队，后来都悄悄换成了 TEE。把 FHE 的范围限定在查询、匹配、打分和小模型推理上，那里它是真的能用。

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

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

1. 先把那一个真正要紧的秘密隔离出来。不是“把应用做成隐私的”，而是“服务器永远不许得知被查询的电话号码”，或者“场馆永远不许得知出生日期”。一句话，一个秘密，一个验证者。
2. 只让它走昂贵路径。Apple 模式：系统的 99% 是一个普通应用，那次私有查询是唯一的 FHE 调用。Google 模式：钱包就是个普通钱包，年龄检查是唯一的 ZK 证明。
3. 选无聊、有人维护的工具。2026 年做 ZK，这意味着一个 Rust zkVM（SP1、RISC Zero）或 Noir，而不是手写电路。做 FHE，这意味着 Zama 的 TFHE-rs 和 Concrete ML、OpenFHE，或 Apple 的 Swift 库。完整的工具表在 ZK 那篇和 FHE 那篇里。
4. 为审计做预算，别只为构建做预算。电路审计加模糊测试是发布 ZK 的固定成本。跳过它，就是别人写漏洞赏金报告时拿你当主角的方式。RISC Zero 为一个在先前多轮审计之后才被发现的 Bug 付了 5 万美元赏金，这说明即便对最顶尖的团队，这件事也有多难。
5. 尽早谈好退路。如果延迟或成本的数字算不拢，TEE 是诚实的退路，而且对很多欧盟合规场景它已经足够。第二周做这个决定很便宜。第八个月做，就是一次重写。

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