Bitroot博客
返回官网 ↗
© 2026 Bitroot · 本站内容仅供一般性参考,不构成财务、投资、法律或税务建议。
编辑标准返回官网
← 全部文章
AI 与可信计算·2026/08/12·约 6 分钟

可信计算框架:ZK、TEE 与 MPC 在可验证 AI 中的分工

说明零知识证明、可信执行环境与多方安全计算各自证明什么、信任什么、成本落在哪,以及它们如何与链上结算、算力网络组合,而不是互相替代;并提示如何阅读相关工程目标。

作者: Bitroot 核心团队 · 编辑标准

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

问题定义:证明什么

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

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

很少有一种技术同时在三者上最优。组合是常态,见堆栈分工 《去中心化 AI 堆栈》。融合时的信任缺口清单见 《Web3 与 AI 融合》。

零知识证明:数学可验证,电路很贵

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

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

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

TEE:把边界下沉到硬件,信任芯片与供应链

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

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

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

MPC:谁都不看全量原文,一起算出结果

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

  • 门限密钥:私钥分片,签名时聚合,完整密钥不落地。
  • 联合统计 / 联邦式更新:共享梯度或统计量而非原始数据集。
  • 模型权重分片推理:与确权设计衔接,见 《AI 资产确权》。

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

怎么组合,而不是怎么堆砌

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

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

威胁模型怎么写进选型表

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

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

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

威胁模型要写进产品说明

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

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

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

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

把这三项成本写进同一张表,再叠加结算层 gas 与确认延迟,才能判断某 AI 工作流是否经济上可重复。性能术语见 《性能指标术语表》;算力生命周期见 《分布式 GPU 与边缘算力》。

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

与结算层的接口契约

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

小结

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

延伸阅读

去中心化 AI 堆栈分布式 GPU 与边缘算力Web3 与 AI 融合:信任缺口
← 上一篇Bitroot 乐观并行化机制:检测、重执行与确定性下一篇 →Web3 与 AI 融合:信任缺口在哪里
本文目录
问题定义:证明什么零知识证明:数学可验证,电路很贵TEE:把边界下沉到硬件,信任芯片与供应链MPC:谁都不看全量原文,一起算出结果怎么组合,而不是怎么堆砌威胁模型怎么写进选型表威胁模型要写进产品说明成本会计:不要只比「安不安全」与结算层的接口契约小结延伸阅读
阅读设置