---
id: 7
title: 可信计算框架：ZK、TEE 与 MPC 在可验证 AI 中的分工
slug: trusted-computing-framework
date: 2026/08/12
summary: 说明零知识证明、可信执行环境与多方安全计算各自证明什么、信任什么、成本落在哪，以及它们如何与链上结算、算力网络组合，而不是互相替代；并提示如何阅读相关工程目标。
keywords: 零知识证明,TEE,MPC,可验证AI,Bitroot
heroImage: /images/community-bg.png
---

链能保证「状态按规则更新」，不能自动保证「链下那次矩阵乘法没被偷换」。可验证 AI 要把计算放到可抽查的边界里。ZK、TEE、MPC 常被写成三件套口号；更有用的是分清：各自把信任锚在数学、硬件还是门限诚实假设上，以及谁适合训练验收、谁适合低延迟机密推理、谁适合密钥与联合统计。

## 问题定义：证明什么

对 AI 工作负载，常见需要证明或保护的对象包括：

- **完整性**：输出确实由声称的模型与输入产生（或满足某策略约束）。
- **机密性**：输入、权重或中间激活不被执行节点看到。
- **可用性**：部分节点掉线仍能完成签名或重构（门限方案）。

很少有一种技术同时在三者上最优。组合是常态，见堆栈分工 [《去中心化 AI 堆栈》](/zh/blog/aibitrootweb3ai)。融合时的信任缺口清单见 [《Web3 与 AI 融合》](/zh/blog/web3-ai-convergence)。

## 零知识证明：数学可验证，电路很贵

ZK 让验证者检查陈述为真，而不必重跑全部计算或看到隐私输入。链上友好点是验证相对便宜（尤其 SNARK 类）；难点是证明生成与电路工程。

- **zk-SNARK**：证明小、验证快，部分方案依赖可信设置；可用 MPC 仪式降低单点信任。
- **zk-STARK**：无可信设置、偏抗量子叙事，证明更大，适合不同成本曲线。

对大模型，「全推理 ZK」往往仍不经济；更现实的是：对关键约束做电路（合规规则、聚合统计、模型哈希绑定），或对抽样/折叠后的计算出证明。性能数字高度依赖电路与硬件加速，应视为工程目标而非通用 SLA。把 ZK 验证合约跑在并行 EVM 上，改善的是结算与验证交易的吞吐，不是 magically 降低证明生成成本。

## TEE：把边界下沉到硬件，信任芯片与供应链

TEE（如 SGX、TrustZone、SEV 等）用隔离执行与远程证明，让用户验证「代码跑在声称的 enclave / 安全世界里」。适合延迟敏感的推理、密钥操作、需要机密性但不想付满 ZK 成本的路径。

代价包括：性能损耗、内存与接口限制、侧信道与供应链风险、厂商差异导致的可移植性。诚实做法是**最小可信计算基**：只把密钥与敏感切片放进 TEE，其余在普通环境，并结合挑战与日志哈希。算力网络如何接验收，见 [《分布式 GPU 与边缘算力》](/zh/blog/gpuai)。

远程证明本身也要进状态机：证明过期、厂商吊销列表、以及「证明了错误代码」的治理问题，都不会因为贴了 TEE 标签而消失。

## MPC：谁都不看全量原文，一起算出结果

MPC 基于秘密分享等协议，让多方在不暴露各自输入的前提下联合计算。典型用途：

- **门限密钥**：私钥分片，签名时聚合，完整密钥不落地。
- **联合统计 / 联邦式更新**：共享梯度或统计量而非原始数据集。
- **模型权重分片推理**：与确权设计衔接，见 [《AI 资产确权》](/zh/blog/ai-data-ownership)。

通信轮次与计算放大是主成本；参与方数量与恶意模型（半诚实 vs 恶意）会急剧改变可行性。MPC 不是「默认加密云」，而是为高价值、多方不愿交数的场景准备的工具。

## 怎么组合，而不是怎么堆砌

| 需求偏向 | 更常优先 | 主要代价 |
|----------|----------|----------|
| 公开可验证、验证者轻 | ZK | 证明生成与电路 |
| 低延迟机密推理 | TEE（+ 审计/挑战） | 硬件信任与侧信道 |
| 多方输入永不集中 | MPC | 通信与协议复杂度 |
| 结算与争议 | 链上合约 + 证明/证明承诺 | 确认延迟与 gas |

链（尤其并行 EVM 结算层）负责任务状态机与支付，不负责替代上述密码学；架构见 [《并行 EVM 架构概览》](/zh/blog/bitrootevm)。混合执行如何分流轻重任务，见 [《AI 原生区块链》](/zh/blog/ai-native-blockchain)。测试网口径下的确认与吞吐数字，描述的是结算基板，读法见 [《性能指标术语表》](/zh/blog/performance-metrics-glossary)。

## 威胁模型怎么写进选型表

选型前写清：对手能否控制执行节点 OS、能否收买证明者、机密要对抗多久、验证者硬件预算。主机被控但远程证明难伪造时 TEE 有意义；需要公开可长期复验时 ZK 更合适；多方绝不交原文时 MPC 几乎不可避免。把「企业级安全」当单一分数会掩盖不可比维度。与 Agent 相关的缺口见 [《Web3 与 AI 融合》](/zh/blog/web3-ai-convergence)。

落地时还要把「证明谁生成、谁验证」写进运维手册：是任务执行者自证、独立证明市场、还是抽样由协议指定的验证者复算。角色不清时，TEE 远程证明和 ZK 证明都可能变成摆设。证明验证交易本身会占用结算层吞吐，因此并行 EVM 的价值在于让验证与结算交易更跟得上，而不是降低证明生成的渐近复杂度。堆栈位置见 [《去中心化 AI 堆栈》](/zh/blog/aibitrootweb3ai)。

电路与 enclave 代码本身也需要版本治理：过时证明电路、未轮换的测量值、或厂商微码变更，都可能让「昨天还能验证」的流程今天失败。版本哈希应进入任务元数据，并与 [《AI 资产确权》](/zh/blog/ai-data-ownership) 中的制品版本策略对齐。

## 威胁模型要写进产品说明

同一套 ZK/TEE/MPC 组合，在半诚实对手与恶意对手下含义完全不同。产品材料若只写技术名词不写对手能力，读者无法判断「可验证」强到哪一步。至少应声明：执行节点是否可能隐瞒输入、是否可能合谋、证明过期与密钥轮换如何处理、以及链上争议窗口由谁推进。

对 AI 推理市场，常见折中是：日常用 TEE 或抽样重算压延迟，对高价值结算切换更强证明；训练任务则更依赖检查点、冗余与经济罚没，而不是每次梯度的全 ZK。混合执行分流见 [《AI 原生区块链》](/zh/blog/ai-native-blockchain)；结算层角色见 [《并行 EVM 架构概览》](/zh/blog/bitrootevm)。

## 成本会计：不要只比「安不安全」

选型常被简化成安全等级排序。更有用的是单位任务的证明成本、延迟分位、以及失败时的人工介入成本。TEE 可能在 p50 延迟上胜出，却在供应链审计上更贵；ZK 可能在公开可验证上胜出，却在证明生成队列上排队；MPC 可能在数据永不集中上胜出，却在参与方运维上最重。

把这三项成本写进同一张表，再叠加结算层 gas 与确认延迟，才能判断某 AI 工作流是否经济上可重复。性能术语见 [《性能指标术语表》](/zh/blog/performance-metrics-glossary)；算力生命周期见 [《分布式 GPU 与边缘算力》](/zh/blog/gpuai)。


可验证 AI 的成熟标志，不是名词是否齐全，而是能否在故障与争议发生时指出：信任锚在哪、证据如何提交、链上状态如何收敛。做不到这三点，框架就仍停留在幻灯片。

## 与结算层的接口契约

证明、远程证明引用或 MPC 签名最终都要变成合约可理解的输入。接口应约定：哪些字段上链、哪些只存承诺、验证失败时任务状态如何迁移、以及过期证明是否自动作废。接口含糊时，再强的密码学也会在应用层被「人工确认」稀释。并行 EVM 负责让这些状态迁移足够快；它不负责生成证明本身。

## 小结

可信计算框架的价值，是给 AI 计算提供可论证的完整性与机密性选项，并明确每条选项的信任假设。没有银弹；有的是按威胁模型选型。任何把 ZK/TEE/MPC 写成「企业级一键安全」的表述，都值得降级为：在特定假设下可降低特定风险。本文不构成投资建议。

## 延伸阅读

- [《去中心化 AI 堆栈》](/zh/blog/aibitrootweb3ai)
- [《分布式 GPU 与边缘算力》](/zh/blog/gpuai)
- [《Web3 与 AI 融合：信任缺口》](/zh/blog/web3-ai-convergence)