---
title: "ZK vs FHE vs MPC vs TEE：2026 年怎么选"
canonical: https://wavect.io/zh/blog/zk-vs-fhe-vs-mpc-vs-tee/
language: zh
description: "四项隐私技术、四种信任模型、四张价签。一份写给架构师的 2026 年决策框架，附诚实的性能数字和逼你做出选择的欧盟监管。"
image: "https://wavect.io/img/blog/headers/header_zk-vs-fhe-vs-mpc-vs-tee.png"
---

[**返回**](/zh/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/)

[Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt

10 分钟 阅读 · 5 Jul 2026 最近审核 2026年8月7日

[**下一篇**](/zh/blog/building-real-applications-zero-knowledge-fhe-2026/)

# ZK vs FHE vs MPC vs TEE：2026 年怎么选

要点速览

ZK、FHE、MPC 与 TEE 保护不同陈述，并暴露不同信任边界。不存在固定性能倍数；电路、参数、实现、阈值、网络、硬件与远程证明都会影响结果，必须测试具体系统。欧盟规则通常要求选择性披露、受控访问、韧性与机密性等属性，而不是指定密码技术。EUDI 技术工作仍在评估 BBS 与混合 ZK。已于 2026-08-07 按一手来源复核。

四项技术如今在争抢同一页架构幻灯片：零知识证明、全同态加密、安全多方计算和可信执行环境。它们经常被当成可互换的“隐私技术”摆出来，但它们不可互换。它们回答不同的问题，价格天差地别，失败方式也各不相同。这篇文章就是客户问“我们到底需要哪个”时，我们希望世上早就存在的那份对比：信任模型、诚实的 2026 年性能数字，以及越来越多地逼你做出选择的欧盟监管。完整的构建方法论，请从我们的 [ZK 与 FHE 务实指南](/zh/blog/building-real-applications-zero-knowledge-fhe-2026/) 开始。

这是工程视角，不是供应商推销。所有数字要么有出处，要么标注为经验法则。参考点来自 Wavect 在 [零知识](/zh/services/zero-knowledge/) 与 [前沿技术](/zh/services/bleeding-edge/) 上的工作。

## 每项技术到底做什么？

- 零知识证明（ZK）： 证明一个陈述为真，而不出示证据。验证者得知“此人年满 18 岁”或“这次计算跑对了”，仅此而已。见我们的 [术语表](/zh/glossary/zero-knowledge/) 和 [生产环境深潜](/zh/blog/zero-knowledge-proofs-production-2026/) 。
- 全同态加密（FHE）： 在加密数据上计算。处理你查询的服务器从没见过查询、数据或结果。深潜： [FHE 里什么能交付](/zh/blog/fully-homomorphic-encryption-practical-2026/) 。
- 安全多方计算（MPC）： 多方在谁都不公开自己输入的前提下共同算出一个结果。三家医院算一个联合统计量；没有一家看到另一家的病人。
- 可信执行环境（TEE）： 硬件隔离的 enclave（Intel TDX、AMD SEV-SNP、NVIDIA 机密 GPU），跑的是连云运营商都看不见的明文计算，并附带一份“正在运行预期代码”的密码学证明（attestation）。

应比较具体的信任边界。ZK 依赖证明假设以及电路、编译器、setup、实现与验证器；FHE 依赖方案、参数、实现与密钥；MPC 增加协议特定的阈值和不合谋假设；TEE 增加硬件、固件、远程证明和侧信道假设。这些假设不会自动换算成固定性能倍数，必须测试具体技术栈。

## 哪四个问题能选出技术？

1. 谁不许看到数据？ 如果答案是“我们公司以外没人”，就此打住：访问控制、TLS 和静态加密解决这个问题，本页每一项技术都是杀鸡用牛刀。如果答案是“执行计算的运营方”，接着往下读。
2. 核心需求是验证还是计算？ 如果第三方需要 *核验* 某件事（年龄、储备金、一次计算的完整性），那就是 ZK，没有然后。如果一个不受信的一方需要在隐藏数据上 *计算* 某件事，那是 FHE、MPC 或 TEE。
3. 被隐藏的计算有多大？ 查询、评分或小模型可以评估 FHE。大型流水线或交互模型通常先评估 TEE，除非真实负载的端到端 FHE 基准能满足延迟与成本。
4. 有多少个独立的参与方持有输入？ 一个客户端加一个服务器，偏向 FHE 或 TEE。多个互不信任、彼此之间网络还不错的组织，偏向 MPC，它就是为这个形状而生的，而在通信成本咬人的公网上则很挣扎。

## 并排比起来是什么样？

|  | ZK | FHE | MPC | TEE |
| --- | --- | --- | --- | --- |
| 你信任的是 | 数学（证明可靠性） | 数学（格） | 达到阈值的参与方 | 芯片厂商，以及没有侧信道 |
| 性能代价 | 通常证明者较重，验证成本依系统而变 | 开销大且依操作而变 | 依协议、阈值与网络而变 | 常接近原生，但依平台和负载而变 |
| 2026 年成本信号 | 已展示实时区块证明；需核算具体证明 | 有快速原语；必须测完整应用 | 在目标网络上测轮次与数据量 | 计入机密计算溢价与远程证明 |
| 成熟度 | 生产级（L2、Google Wallet、World ID） | 窄查询场景生产级（Apple、Microsoft） | 金融与密钥管理领域生产级 | 处处生产级，含机密 GPU |
| 对运营方隐藏什么 | witness（证据） | 一切 | 一切（拆分在各方之间） | 一切，前提是你信任硬件 |
| 杀手级用例 | 选择性披露、可验证计算 | 私有查询、小型私有 ML | 跨组织分析 | 规模化机密 AI |
| 主要失败模式 | 约束不足的电路、trusted setup 失误 | 被误用于交互式负载 | 合谋、网络延迟 | 侧信道攻击、厂商信任 |

![Kevin Riedl](/img/team/kevin.webp)

"没有人会因为选了 TEE 被开除，而且他们大多是对的。昂贵的错误发生在团队用 FHE 去扛本该 TEE 扛的负载，或者用 TEE 去守一个只有数学守得住的承诺。"

## TEE 现在到底有多好？

好到已经是规模化机密计算的默认答案，这也正是为什么密码学选项需要一个明确的理由才配取代它们：

- CPU enclave 成熟了。 Intel TDX 和 AMD SEV-SNP 隔离整台虚拟机，降低了相对 SGX 的集成工作。公开开销会随虚拟化、内存、I/O、远程证明与负载变化，个位数结果不能作为通用规划值。
- GPU 加入了。 NVIDIA 的 H100 是第一款机密计算 GPU，并延续到 H200 和 Blackwell 世代。机密 LLM 推理已作为云产品交付，微调可在同样的机密 GPU 虚拟机上进行，开销常常由加密的 PCIe 传输而非计算主导 [(arXiv 2505.16501)](https://arxiv.org/abs/2505.16501) 。
- 信任的那道坎还在。 TEE 证明的是你在真硬件上跑着预期的代码。它保护不了你免受被攻陷的厂商、某些物理攻击，以及源源不断发表的侧信道论文。对多数商业威胁模型，这点残余风险可以接受。对“我们必须做到无法响应针对用户数据的传票”，不可以接受，而这正是 FHE 和 MPC 赚回自身开销的那条线。

## 为什么赢家的模式是组合，而不是单选？

一些 2026 年架构会叠加这些工具，而不是只挑一个：

- 大头给 TEE，核心给密码学。 把重流水线跑在机密虚拟机里，把 FHE 或 MPC 留给那段小而高风险、硬件信任不可接受的计算。
- ZK 盖在上面负责可验证性。 TEE 或 MPC 集群负责算；一个 ZK 证明让外部各方不用重跑就相信计算是对的。下游每个人的验证都保持廉价。
- 真实的例子形状： 一个机密 GPU 推理服务，返回一份运行了哪个模型版本的 ZK 证明；一个 MPC 联盟，其结果附带监管者可核验的证明；一次装在普通应用里的 FHE 查询，Apple 交付的字面上就是这个。

Nillion 这类项目把 MPC、HE 和 ZK 编排在一个开发者界面后面。只有从一开始就为替换设计接口、密钥所有权、数据格式与回退语义，组合才会降低路线图风险。从 TEE 转向 FHE 并不是自动替换。

## 欧盟监管在强制什么，什么时候生效？

对面向欧盟的产品，监管正在悄悄把这份菜单变成必读材料：

- eIDAS 2.0 / EUDI 钱包，期限 2026 年底。 选择性披露是核心。当前官方工作正在评估 BBS 与混合 ZK 方案，同时标准、硬件、assurance 与各国实施仍在推进。不能据此推断全面批准或禁止。
- EHDS。 健康数据二次使用要求受控访问、适当的假名化或匿名化以及安全处理环境。HE、MPC、联邦学习或 TEE 可帮助实现，但法规没有指定统一技术。
- GDPR。 经 FHE 处理或经 ZK 验证的数据算不算匿名化，是一场进行中的法律辩论，不是已定的教义。PET 能加强你第 25 条“通过设计保护数据”的叙事；它们不会自动把数据移出 GDPR 的适用范围。在营销话术跑到法律前面之前，先让法务介入。我们关于 [AI 应用的欧盟数据驻留](/zh/blog/eu-data-residency-ai-apps-2026/) 的文章覆盖了相邻地带。
- DORA 与 AI 法案 带来韧性、证据和治理义务，但不指定 TEE、ZK、FHE 或 MPC。应从受监管流程选择控制措施并记录满足的属性。

贯穿这一切的规律：监管者没有强制指定某种密码学，他们强制的是属性（最小化、选择性披露、机密性），而这个工具箱恰好是把这些属性规模化交付的唯一方式。

## 什么时候普通的访问控制才是赢家？

比这篇文章的存在所暗示的更常见。在下列情况选无聊的技术：

- 所有经手数据的各方已经在合同层面互相信任（一家公司、一份 DPA、一朵云）。
- 隐私承诺是营销，不是架构。用户很少为他们感知不到的密码学保证付费；他们为能用的产品付费。
- 敏感计算又大、又交互、又卡延迟，而且没有监管逼这个问题。TEE 加严格 IAM 加审计日志，是一个站得住、交付得了的答案。
- 你的团队还撑不起密码学部署所要求的可观测性、密钥管理和审计节奏。数学是容易的部分；运维成熟度才是难的部分。

## 常见问题

### ZK、FHE、MPC 和 TEE 各用一句话说清区别？

ZK 证明一个事实而不出示证据；FHE 在始终保持加密的数据上计算；MPC 让多方在不共享输入的前提下共同计算；TEE 在一层你必须信任的硬件隔离里跑明文计算。

### ZK、FHE、MPC、TEE 哪个最安全？

没有通用排名，因为它们保护不同陈述并暴露不同实现边界。ZK 与 FHE 仍依赖正确的软件、参数、电路、设置与密钥管理；MPC 增加协议特定的阈值假设；TEE 增加硬件、固件、远程证明与侧信道假设。应按威胁模型比较具体系统并实测。

### TEE 对 GDPR 合规够用吗？

通常够，作为通过设计保护数据叙事的一部分：带 attestation 的机密虚拟机或 GPU 实质性地压缩了运营方的访问。但 TEE 不会让数据变成匿名，甚至 FHE 的输出是否脱离 GDPR 适用范围在法律上也未有定论。合规来自整个处理流程的设计并配合法律审查，不来自任何单项技术。

### 这些技术可以组合吗？

可以。TEE 可以承载大型负载，FHE 或 MPC 可以覆盖不能接受硬件信任的小型计算，ZK 可以让定义明确的结果可验证。后续替换仍需明确设计接口、密钥所有权、数据格式与回退语义，并非自动升级。

### 在 2026 年 eIDAS 钱包期限之前，欧盟公司该做什么？

针对当前 EUDI 流程做原型并隔离凭证适配器。上线前核对 assurance、认证硬件、各国 rollout 与 relying-party 规则。BBS 与混合 ZK 仍处于活跃技术工作中。

## 来源与核验

1. Mopro (2026). Circuit-specific proving and verification benchmarks. [zkmopro.org](https://zkmopro.org/docs/performance/)
2. Apple Machine Learning Research (2024). Production HE and private information retrieval. [machinelearning.apple.com](https://machinelearning.apple.com/research/homomorphic-encryption)
3. European Union (2025). Regulation (EU) 2025/327 on the European Health Data Space. [eur-lex.europa.eu](https://eur-lex.europa.eu/eli/reg/2025/327/oj)
4. European Digital Identity Wallet (2026). ZK proofs from multi-message signatures. [github.com/eu-digital-identity-wallet](https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/blob/main/docs/technical-specifications/ts14-zkps-from-mms.md)
5. W3C (2026). Data Integrity BBS Cryptosuites v1.0, Candidate Recommendation Draft. [w3.org](https://www.w3.org/TR/vc-di-bbs/)
6. Confidential GPU research (2025). Performance analysis of confidential GPU workloads. [arxiv.org](https://arxiv.org/abs/2505.16501)

## 最终思考

这四项技术不可互换。ZK 回答验证，FHE 回答在真实负载可行时的盲计算，MPC 回答定义阈值下的多组织计算，TEE 承载大型机密负载并引入不同硬件信任边界。

按威胁模型选择，测试具体技术栈，并把欧盟规则映射为所需属性，而不是声称法规指定某项技术。

## 你可能也喜欢..

[**2026 年的全同态加密：什么能交付，什么还是炒作** Apple 的生产级 FHE、Zama 的主网、诚实的开销数字，以及 LLM 跑在 FHE 下的现实核查。](/zh/blog/fully-homomorphic-encryption-practical-2026/) [**Wavect vs 一家通用型开发外包** 通用型卖产能，我们卖产品判断，加上把前沿技术安全交付的工程能力。](/zh/compare/wavect-vs-dev-agencies/)

隐私与密码学

## 继续浏览此集群

超越炒作的零知识、FHE 与隐私保护计算。

[从核心文章开始**2026 年的零知识证明：什么真正达到了生产就绪**](/zh/blog/zero-knowledge-proofs-production-2026/)

- [面向 AI 智能体的 zkTLS：验证网页数据而不泄露秘密](/zh/blog/zktls-ai-agents/)
- [在 2026 年用 ZK 和 FHE 构建真实应用：一份务实指南](/zh/blog/building-real-applications-zero-knowledge-fhe-2026/)
- [2026 年的零知识证明：什么真正达到了生产就绪](/zh/blog/zero-knowledge-proofs-production-2026/)
- [2026 年的全同态加密：什么能交付，什么还是炒作](/zh/blog/fully-homomorphic-encryption-practical-2026/)
- [加密之外的零知识应用](/zh/blog/zero-knowledge-use-cases-outside-crypto/)

只收重要内容

## 关注与你相关的内容

每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。

[**返回**](/zh/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/)

[Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt

10 分钟 阅读 · 5 Jul 2026 最近审核 2026年8月7日

[**下一篇**](/zh/blog/building-real-applications-zero-knowledge-fhe-2026/)

邮件订阅新文章 ×

×

通过邮件获取新文章

我们发布时给你一封简短邮件。免费，不做跟踪。

## Structured Data

```json
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@id": "https://wavect.io/#organization",
      "@type": [
        "Organization",
        "ProfessionalService",
        "LocalBusiness"
      ],
      "employee": [
        {
          "@id": "https://wavect.io/team/kevin-riedl/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Kevin Riedl",
          "url": "https://wavect.io/team/kevin-riedl/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        },
        {
          "@id": "https://wavect.io/team/christof-jori/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Christof Jori",
          "url": "https://wavect.io/team/christof-jori/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        }
      ],
      "founder": [
        {
          "@id": "https://wavect.io/team/kevin-riedl/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Kevin Riedl",
          "url": "https://wavect.io/team/kevin-riedl/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        },
        {
          "@id": "https://wavect.io/team/christof-jori/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Christof Jori",
          "url": "https://wavect.io/team/christof-jori/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        }
      ],
      "legalRepresentative": [
        {
          "@id": "https://wavect.io/team/kevin-riedl/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Kevin Riedl",
          "url": "https://wavect.io/team/kevin-riedl/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        },
        {
          "@id": "https://wavect.io/team/christof-jori/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Christof Jori",
          "url": "https://wavect.io/team/christof-jori/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        }
      ],
      "name": "Wavect GmbH",
      "subjectOf": {
        "@id": "https://wavect.io/verified-claims.json#dataset",
        "@type": "Dataset",
        "creator": {
          "@id": "https://wavect.io/#organization",
          "@type": [
            "Organization",
            "ProfessionalService",
            "LocalBusiness"
          ]
        },
        "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.",
        "inLanguage": "en",
        "isAccessibleForFree": true,
        "license": "https://creativecommons.org/licenses/by/4.0/",
        "name": "Wavect verified publication claims",
        "url": "https://wavect.io/verified-claims.json"
      },
      "url": "https://wavect.io/"
    },
    {
      "@id": "https://wavect.io/team/kevin-riedl/#person",
      "@type": "Person",
      "jobTitle": "Managing Director",
      "name": "Kevin Riedl",
      "sameAs": [
        "https://www.wikidata.org/wiki/Q139796365",
        "https://www.linkedin.com/in/wsdt",
        "https://github.com/wsdt"
      ],
      "url": "https://wavect.io/team/kevin-riedl/",
      "worksFor": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      }
    },
    {
      "@id": "https://wavect.io/team/christof-jori/#person",
      "@type": "Person",
      "jobTitle": "Managing Director",
      "name": "Christof Jori",
      "sameAs": [
        "https://www.wikidata.org/wiki/Q139796367",
        "https://www.linkedin.com/in/jocr77/",
        "https://github.com/jo-chris"
      ],
      "url": "https://wavect.io/team/christof-jori/",
      "worksFor": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      }
    },
    {
      "@id": "https://wavect.io/#website",
      "@type": "WebSite",
      "inLanguage": [
        "en",
        "de",
        "es",
        "zh"
      ],
      "name": "Wavect",
      "potentialAction": {
        "@type": "SearchAction",
        "query-input": "required name=search_term_string",
        "target": {
          "@type": "EntryPoint",
          "urlTemplate": "https://wavect.io/search/?q={search_term_string}"
        }
      },
      "publisher": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      },
      "url": "https://wavect.io/"
    },
    {
      "@id": "https://wavect.io/zh/blog/zk-vs-fhe-vs-mpc-vs-tee/#webpage",
      "@type": "WebPage",
      "dateModified": "2026-07-07",
      "inLanguage": "zh",
      "isPartOf": {
        "@id": "https://wavect.io/#website",
        "@type": "WebSite"
      },
      "lastReviewed": "2026-07-07",
      "url": "https://wavect.io/zh/blog/zk-vs-fhe-vs-mpc-vs-tee/"
    }
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "abstract": "ZK、FHE、MPC 与 TEE 保护不同陈述，并暴露不同信任边界。不存在固定性能倍数；电路、参数、实现、阈值、网络、硬件与远程证明都会影响结果，必须测试具体系统。欧盟规则通常要求选择性披露、受控访问、韧性与机密性等属性，而不是指定密码技术。EUDI 技术工作仍在评估 BBS 与混合 ZK。已于 2026-08-07 按一手来源复核。",
  "articleBody": " 博客概览/Web3 与隐私/隐私与密码学 ZK vs FHE vs MPC vs TEE：2026 年怎么选 要点速览 ZK、FHE、MPC 与 TEE 保护不同陈述，并暴露不同信任边界。不存在固定性能倍数；电路、参数、实现、阈值、网络、硬件与远程证明都会影响结果，必须测试具体系统。欧盟规则通常要求选择性披露、受控访问、韧性与机密性等属性，而不是指定密码技术。EUDI 技术工作仍在评估 BBS 与混合 ZK。已于 2026-08-07 按一手来源复核。 四项技术如今在争抢同一页架构幻灯片：零知识证明、全同态加密、安全多方计算和可信执行环境。它们经常被当成可互换的“隐私技术”摆出来，但它们不可互换。它们回答不同的问题，价格天差地别，失败方式也各不相同。这篇文章就是客户问“我们到底需要哪个”时，我们希望世上早就存在的那份对比：信任模型、诚实的 2026 年性能数字，以及越来越多地逼你做出选择的欧盟监管。完整的构建方法论，请从我们的 ZK 与 FHE 务实指南开始。 这是工程视角，不是供应商推销。所有数字要么有出处，要么标注为经验法则。参考点来自 Wavect 在零知识与前沿技术上的工作。 每项技术到底做什么？ 零知识证明（ZK）：证明一个陈述为真，而不出示证据。验证者得知“此人年满 18 岁”或“这次计算跑对了”，仅此而已。见我们的术语表和生产环境深潜。 全同态加密（FHE）：在加密数据上计算。处理你查询的服务器从没见过查询、数据或结果。深潜：FHE 里什么能交付。 安全多方计算（MPC）：多方在谁都不公开自己输入的前提下共同算出一个结果。三家医院算一个联合统计量；没有一家看到另一家的病人。 可信执行环境（TEE）：硬件隔离的 enclave（Intel TDX、AMD SEV-SNP、NVIDIA 机密 GPU），跑的是连云运营商都看不见的明文计算，并附带一份“正在运行预期代码”的密码学证明（attestation）。 应比较具体的信任边界。ZK 依赖证明假设以及电路、编译器、setup、实现与验证器；FHE 依赖方案、参数、实现与密钥；MPC 增加协议特定的阈值和不合谋假设；TEE 增加硬件、固件、远程证明和侧信道假设。这些假设不会自动换算成固定性能倍数，必须测试具体技术栈。 哪四个问题能选出技术？ 谁不许看到数据？如果答案是“我们公司以外没人”，就此打住：访问控制、TLS 和静态加密解决这个问题，本页每一项技术都是杀鸡用牛刀。如果答案是“执行计算的运营方”，接着往下读。 核心需求是验证还是计算？如果第三方需要核验某件事（年龄、储备金、一次计算的完整性），那就是 ZK，没有然后。如果一个不受信的一方需要在隐藏数据上计算某件事，那是 FHE、MPC 或 TEE。 被隐藏的计算有多大？查询、评分或小模型可以评估 FHE。大型流水线或交互模型通常先评估 TEE，除非真实负载的端到端 FHE 基准能满足延迟与成本。 有多少个独立的参与方持有输入？一个客户端加一个服务器，偏向 FHE 或 TEE。多个互不信任、彼此之间网络还不错的组织，偏向 MPC，它就是为这个形状而生的，而在通信成本咬人的公网上则很挣扎。 并排比起来是什么样？ ZKFHEMPCTEE 你信任的是数学（证明可靠性）数学（格）达到阈值的参与方芯片厂商，以及没有侧信道 性能代价通常证明者较重，验证成本依系统而变开销大且依操作而变依协议、阈值与网络而变常接近原生，但依平台和负载而变 2026 年成本信号已展示实时区块证明；需核算具体证明有快速原语；必须测完整应用在目标网络上测轮次与数据量计入机密计算溢价与远程证明 成熟度生产级（L2、Google Wallet、World ID）窄查询场景生产级（Apple、Microsoft）金融与密钥管理领域生产级处处生产级，含机密 GPU 对运营方隐藏什么witness（证据）一切一切（拆分在各方之间）一切，前提是你信任硬件 杀手级用例选择性披露、可验证计算私有查询、小型私有 ML跨组织分析规模化机密 AI 主要失败模式约束不足的电路、trusted setup 失误被误用于交互式负载合谋、网络延迟侧信道攻击、厂商信任 \"没有人会因为选了 TEE 被开除，而且他们大多是对的。昂贵的错误发生在团队用 FHE 去扛本该 TEE 扛的负载，或者用 TEE 去守一个只有数学守得住的承诺。\" TEE 现在到底有多好？ 好到已经是规模化机密计算的默认答案，这也正是为什么密码学选项需要一个明确的理由才配取代它们： CPU enclave 成熟了。Intel TDX 和 AMD SEV-SNP 隔离整台虚拟机，降低了相对 SGX 的集成工作。公开开销会随虚拟化、内存、I/O、远程证明与负载变化，个位数结果不能作为通用规划值。 GPU 加入了。NVIDIA 的 H100 是第一款机密计算 GPU，并延续到 H200 和 Blackwell 世代。机密 LLM 推理已作为云产品交付，微调可在同样的机密 GPU 虚拟机上进行，开销常常由加密的 PCIe 传输而非计算主导 (arXiv 2505.16501)。 信任的那道坎还在。TEE 证明的是你在真硬件上跑着预期的代码。它保护不了你免受被攻陷的厂商、某些物理攻击，以及源源不断发表的侧信道论文。对多数商业威胁模型，这点残余风险可以接受。对“我们必须做到无法响应针对用户数据的传票”，不可以接受，而这正是 FHE 和 MPC 赚回自身开销的那条线。 为什么赢家的模式是组合，而不是单选？ 一些 2026 年架构会叠加这些工具，而不是只挑一个： 大头给 TEE，核心给密码学。把重流水线跑在机密虚拟机里，把 FHE 或 MPC 留给那段小而高风险、硬件信任不可接受的计算。 ZK 盖在上面负责可验证性。TEE 或 MPC 集群负责算；一个 ZK 证明让外部各方不用重跑就相信计算是对的。下游每个人的验证都保持廉价。 真实的例子形状：一个机密 GPU 推理服务，返回一份运行了哪个模型版本的 ZK 证明；一个 MPC 联盟，其结果附带监管者可核验的证明；一次装在普通应用里的 FHE 查询，Apple 交付的字面上就是这个。 Nillion 这类项目把 MPC、HE 和 ZK 编排在一个开发者界面后面。只有从一开始就为替换设计接口、密钥所有权、数据格式与回退语义，组合才会降低路线图风险。从 TEE 转向 FHE 并不是自动替换。 欧盟监管在强制什么，什么时候生效？ 对面向欧盟的产品，监管正在悄悄把这份菜单变成必读材料： eIDAS 2.0 / EUDI 钱包，期限 2026 年底。选择性披露是核心。当前官方工作正在评估 BBS 与混合 ZK 方案，同时标准、硬件、assurance 与各国实施仍在推进。不能据此推断全面批准或禁止。 EHDS。健康数据二次使用要求受控访问、适当的假名化或匿名化以及安全处理环境。HE、MPC、联邦学习或 TEE 可帮助实现，但法规没有指定统一技术。 GDPR。经 FHE 处理或经 ZK 验证的数据算不算匿名化，是一场进行中的法律辩论，不是已定的教义。PET 能加强你第 25 条“通过设计保护数据”的叙事；它们不会自动把数据移出 GDPR 的适用范围。在营销话术跑到法律前面之前，先让法务介入。我们关于 AI 应用的欧盟数据驻留的文章覆盖了相邻地带。 DORA 与 AI 法案带来韧性、证据和治理义务，但不指定 TEE、ZK、FHE 或 MPC。应从受监管流程选择控制措施并记录满足的属性。 贯穿这一切的规律：监管者没有强制指定某种密码学，他们强制的是属性（最小化、选择性披露、机密性），而这个工具箱恰好是把这些属性规模化交付的唯一方式。 什么时候普通的访问控制才是赢家？ 比这篇文章的存在所暗示的更常见。在下列情况选无聊的技术： 所有经手数据的各方已经在合同层面互相信任（一家公司、一份 DPA、一朵云）。 隐私承诺是营销，不是架构。用户很少为他们感知不到的密码学保证付费；他们为能用的产品付费。 敏感计算又大、又交互、又卡延迟，而且没有监管逼这个问题。TEE 加严格 IAM 加审计日志，是一个站得住、交付得了的答案。 你的团队还撑不起密码学部署所要求的可观测性、密钥管理和审计节奏。数学是容易的部分；运维成熟度才是难的部分。 常见问题 ZK、FHE、MPC 和 TEE 各用一句话说清区别？ ZK 证明一个事实而不出示证据；FHE 在始终保持加密的数据上计算；MPC 让多方在不共享输入的前提下共同计算；TEE 在一层你必须信任的硬件隔离里跑明文计算。 ZK、FHE、MPC、TEE 哪个最安全？ 没有通用排名，因为它们保护不同陈述并暴露不同实现边界。ZK 与 FHE 仍依赖正确的软件、参数、电路、设置与密钥管理；MPC 增加协议特定的阈值假设；TEE 增加硬件、固件、远程证明与侧信道假设。应按威胁模型比较具体系统并实测。 TEE 对 GDPR 合规够用吗？ 通常够，作为通过设计保护数据叙事的一部分：带 attestation 的机密虚拟机或 GPU 实质性地压缩了运营方的访问。但 TEE 不会让数据变成匿名，甚至 FHE 的输出是否脱离 GDPR 适用范围在法律上也未有定论。合规来自整个处理流程的设计并配合法律审查，不来自任何单项技术。 这些技术可以组合吗？ 可以。TEE 可以承载大型负载，FHE 或 MPC 可以覆盖不能接受硬件信任的小型计算，ZK 可以让定义明确的结果可验证。后续替换仍需明确设计接口、密钥所有权、数据格式与回退语义，并非自动升级。 在 2026 年 eIDAS 钱包期限之前，欧盟公司该做什么？ 针对当前 EUDI 流程做原型并隔离凭证适配器。上线前核对 assurance、认证硬件、各国 rollout 与 relying-party 规则。BBS 与混合 ZK 仍处于活跃技术工作中。 来源与核验 Mopro (2026). Circuit-specific proving and verification benchmarks. zkmopro.org Apple Machine Learning Research (2024). Production HE and private information retrieval. machinelearning.apple.com European Union (2025). Regulation (EU) 2025/327 on the European Health Data Space. eur-lex.europa.eu European Digital Identity Wallet (2026). ZK proofs from multi-message signatures. github.com/eu-digital-identity-wallet W3C (2026). Data Integrity BBS Cryptosuites v1.0, Candidate Recommendation Draft. w3.org Confidential GPU research (2025). Performance analysis of confidential GPU workloads. arxiv.org 最终思考 这四项技术不可互换。ZK 回答验证，FHE 回答在真实负载可行时的盲计算，MPC 回答定义阈值下的多组织计算，TEE 承载大型机密负载并引入不同硬件信任边界。 按威胁模型选择，测试具体技术栈，并把欧盟规则映射为所需属性，而不是声称法规指定某项技术。 你可能也喜欢.. 2026 年的全同态加密：什么能交付，什么还是炒作 Apple 的生产级 FHE、Zama 的主网、诚实的开销数字，以及 LLM 跑在 FHE 下的现实核查。 Wavect vs 一家通用型开发外包 通用型卖产能，我们卖产品判断，加上把前沿技术安全交付的工程能力。 隐私与密码学 继续浏览此集群 超越炒作的零知识、FHE 与隐私保护计",
  "articleSection": "Engineering",
  "author": {
    "@id": "https://wavect.io/team/kevin-riedl/#person",
    "@type": "Person",
    "name": "Kevin Riedl",
    "sameAs": [
      "https://www.wikidata.org/wiki/Q139796365",
      "https://www.linkedin.com/in/wsdt",
      "https://github.com/wsdt"
    ],
    "url": "https://wavect.io/team/kevin-riedl/"
  },
  "citation": [
    {
      "@type": "WebPage",
      "name": "zkmopro.org",
      "url": "https://zkmopro.org/docs/performance/"
    },
    {
      "@type": "WebPage",
      "name": "machinelearning.apple.com",
      "url": "https://machinelearning.apple.com/research/homomorphic-encryption"
    },
    {
      "@type": "WebPage",
      "name": "eur-lex.europa.eu",
      "url": "https://eur-lex.europa.eu/eli/reg/2025/327/oj"
    },
    {
      "@type": "WebPage",
      "name": "github.com/eu-digital-identity-wallet",
      "url": "https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/blob/main/docs/technical-specifications/ts14-zkps-from-mms.md"
    },
    {
      "@type": "WebPage",
      "name": "w3.org",
      "url": "https://www.w3.org/TR/vc-di-bbs/"
    },
    {
      "@type": "WebPage",
      "name": "arxiv.org",
      "url": "https://arxiv.org/abs/2505.16501"
    }
  ],
  "dateModified": "2026-08-07",
  "datePublished": "2026-07-05",
  "description": "ZK、FHE、MPC 与 TEE 保护不同陈述，并暴露不同信任边界。不存在固定性能倍数；电路、参数、实现、阈值、网络、硬件与远程证明都会影响结果，必须测试具体系统。欧盟规则通常要求选择性披露、受控访问、韧性与机密性等属性，而不是指定密码技术。EUDI 技术工作仍在评估 BBS 与混合 ZK。已于 2026-08-07 按一手来源复核。",
  "headline": "ZK vs FHE vs MPC vs TEE：2026 年怎么选",
  "image": "https://wavect.io/img/blog/headers/header_zk-vs-fhe-vs-mpc-vs-tee.svg",
  "inLanguage": "zh",
  "mainEntityOfPage": {
    "@id": "https://wavect.io/zh/blog/zk-vs-fhe-vs-mpc-vs-tee/",
    "@type": "WebPage"
  },
  "publisher": {
    "@id": "https://wavect.io/#organization",
    "@type": [
      "Organization",
      "ProfessionalService",
      "LocalBusiness"
    ]
  },
  "url": "https://wavect.io/zh/blog/zk-vs-fhe-vs-mpc-vs-tee/",
  "wordCount": 424
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/",
      "name": "首页",
      "position": 1
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/blog/overview/",
      "name": "博客概览",
      "position": 2
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/blog/topics/web3-privacy/",
      "name": "Web3 与隐私",
      "position": 3
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/blog/clusters/privacy-cryptography/",
      "name": "隐私与密码学",
      "position": 4
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/zh/blog/zk-vs-fhe-vs-mpc-vs-tee/",
      "name": "ZK vs FHE vs MPC vs TEE：2026 年怎么选 | ",
      "position": 5
    }
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "ZK 证明一个事实而不出示证据；FHE 在始终保持加密的数据上计算；MPC 让多方在不共享输入的前提下共同计算；TEE 在一层你必须信任的硬件隔离里跑明文计算。"
      },
      "name": "ZK、FHE、MPC 和 TEE 各用一句话说清区别？"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "没有通用排名，因为它们保护不同陈述并暴露不同实现边界。ZK 与 FHE 仍依赖正确的软件、参数、电路、设置与密钥管理；MPC 增加协议特定的阈值假设；TEE 增加硬件、固件、远程证明与侧信道假设。应按威胁模型比较具体系统并实测。"
      },
      "name": "ZK、FHE、MPC、TEE 哪个最安全？"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "通常够，作为通过设计保护数据叙事的一部分：带 attestation 的机密虚拟机或 GPU 实质性地压缩了运营方的访问。但 TEE 不会让数据变成匿名，甚至 FHE 的输出是否脱离 GDPR 适用范围在法律上也未有定论。合规来自整个处理流程的设计并配合法律审查，不来自任何单项技术。"
      },
      "name": "TEE 对 GDPR 合规够用吗？"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "可以。TEE 可以承载大型负载，FHE 或 MPC 可以覆盖不能接受硬件信任的小型计算，ZK 可以让定义明确的结果可验证。后续替换仍需明确设计接口、密钥所有权、数据格式与回退语义，并非自动升级。"
      },
      "name": "这些技术可以组合吗？"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "针对当前 EUDI 流程做原型并隔离凭证适配器。上线前核对 assurance、认证硬件、各国 rollout 与 relying-party 规则。BBS 与混合 ZK 仍处于活跃技术工作中。"
      },
      "name": "在 2026 年 eIDAS 钱包期限之前，欧盟公司该做什么？"
    }
  ]
}
```
