在典型的 zk 应用中，用户常通过手机或浏览器在本地生成 SNARK 证明，确保私密数据不离开设备。但由于这些设备算力有限，复杂语句的证明往往力不从心。为解决计算瓶颈，证明委托（proof delegation）的思路应运而生：用户可将计算任务交给具备强大算力的外部服务器。但如果直接发送原始数据进行委托，会破坏零知识性，因此隐私证明委托（Private Proof Delegation, PPD）应运而生，强调加密传输私密输入。常见的隐私方案包括 MPC（多方计算）、FHE（同态加密）和 TEE（可信执行环境）三类。本文聚焦 TEE 方案，它在当前云计算环境中最为实用，依赖硬件隔离与内存加密，确保数据计算全程在一个受保护的环境内进行，操作系统、管理程序均无法访问或篡改。此外，通过远程认证（remote attestation），客户端还能在数据发送前确认该环境确实运行了预期代码。TEE 成为无需信任服务器运营方，即可实现私密计算的重要基础。 TEE-based 私密证明委托系统主要由五部分构成：客户端、TD Host（宿主操作系统）、TD Guest（TEE 虚拟机）、远程认证服务方与验证者。客户端希望生成基于私密输入的 zk 证明但缺乏算力，因此将任务转交给 TD Guest。TD Host 运行 TEE 虚拟机（如 Intel TDX 中的 Trusted Domain, TD），但无法访问其中数据。TD Guest 内部运行 zk Prover，通过安全通道（如基于 TLS 或 Keylime 的 mTLS）接收来自客户端的加密数据，进行证明运算，并将结果返回。为确保信任基础，客户端会先请求 TD Guest 生成「TD Quote」，并通过认证服务验证 TEE 状态是否合法、可信。系统不仅在启动时进行「launch-time attestation」，还结合 Linux IMA 和 Keylime 实现「runtime attestation」，实时监控 TEE 中二进制文件、配置、库等是否被篡改。双层认证机制使得客户端能够放心地将敏感数据传入 TEE。证明计算过程本身无需特殊修改，可使用标准 zk SNARK 工具链完成，提升部署兼容性与工程灵活性。 实验以 Azure 平台上的 Intel TDX TEE 虚拟机为基础，对 Semaphore 与 zkEmail 两类典型电路进行了评估，涵盖纯 TEE 内证明、普通虚拟机证明与端到端委托模式（含认证）的对比。在 Semaphore 场景中，端到端延迟平均约 2.9 秒，其中 Keylime 与 TDX 认证合计仅占约 1.7 秒，证明时间约 1.1 秒，表明 TEE 认证延迟可接受，适合嵌入交互式或按需证明流程。zkEmail 场景中因电路复杂，证明时间高达 67 秒以上，但 TEE 的相对开销低于 5%，对整体性能影响有限。相较于 MPC 协议（如 CoCircom 协同证明耗时约 700ms）或手机本地证明（MoPro 平均 165~1267ms，但受限于内存瓶颈），TEE 在通用性、安全性与成本之间提供了均衡方案。尤其在云环境中，启用 TEE 的 VM 月费用仅增加 2 美元，而 MPC 需部署多个节点，成本显著更高。整体来看，TEE 架构已具备生产级部署潜力，尤其适用于数据隐私、安全可验证性与性能要求并存的 zk 应用场景。【原文为英文】\n原文链接