链上 AI 推理结果验证：用 TEE 和零知识证明保障可信执行

链上 AI 推理结果验证用 TEE 和零知识证明保障可信执行一、调用了一个第三方 AI 推理服务如何证明它真的用了宣称的模型这个问题在去中心化 AI 场景中尤为关键。用户支付 Token 获取 AI 推理结果。推理节点声称使用了GPT-4 级别的模型。但没有人能验证它是不是用了一个更便宜的模型代替。用户付了 GPT-4 的价格拿到的是 GPT-3.5 的输出甚至可能是蒸馏过的小模型。在中心化场景下这个问题由平台的声誉和 SLA 解决。但在去中心化 AI 推理市场中推理节点是匿名的声誉机制不够用。我们在设计去中心化 AI 推理市场时第一时间遇到了这个问题。节点 A 报价 $0.002/次声称用 Llama-3-70B节点 B 报价 $0.001/次也声称用 Llama-3-70B。用户无法判断 B 是真的更便宜还是在偷工减料。如果没有验证机制劣币驱逐良币——诚实节点因为成本高被淘汰作弊节点因为便宜占据市场。这就是 AI 推理的可信执行问题。需要一种机制让任何人都能验证推理确实执行了、使用了指定的模型、输入输出没有被篡改。这相当于给 AI 推理过程加一个防伪标签。两种主流方案TEE可信执行环境和 ZKP零知识证明。TEE 用硬件保证执行环境不被篡改CPU 内部有一块加密区域飞地飞地里的代码和数据即使操作系统也无法读取或修改。ZKP 用数学证明推理结果的正确性证明者生成一个证明验证者无需知道推理过程就能确认结果正确。两种方案的权衡点不同TEE 性能好但依赖特定硬件ZKP 安全性更强但计算开销极大。二、TEE 与 ZKP 的对比TEE 方案的工作原理是把推理代码和模型放进 CPU 的安全飞地中执行。飞地执行完后输出一个远程证明Remote Attestation证明里包含飞地的代码哈希MRENCLAVE、签名者哈希MRSIGNER和自定义报告数据。报告数据里包含输入哈希、输出哈希和模型哈希确保三者绑定不可篡改。验证者拿到证明后先验证飞地身份是否在白名单中再验证报告数据是否匹配。TEE 的性能开销约 5-10%对推理延迟的影响可以接受。ZKP 方案的工作原理是把推理过程转化为零知识电路。证明者执行推理并同时生成 ZK 证明证明里包含我用了这个模型、这个输入、得到了这个输出的数学证据。验证者只需验证证明的有效性无需重新执行推理。ZKP 的安全性基于数学难题不依赖任何硬件。但问题在于生成一个 ZK 证明的计算量是推理本身的 100-10000 倍。目前一个小型神经网络MNIST 级别的 ZK 证明需要数分钟大规模 Transformer 模型的 ZK 证明在可预见的未来不现实。实际落地的选择很明确当前阶段用 TEE等 ZKP 技术成熟后再迁移。TEE 虽然有侧信道攻击风险但在大多数商业场景下已经足够。我们团队在 2024 年下半年用 Intel SGX 搭建了去中心化推理 PoC验证延迟开销约 7%可以接受。flowchart TB A[AI 推理结果验证] -- B[TEE 方案] A -- C[ZKP 方案] B -- B1[Intel SGX / AMD SEV] B1 -- B2[安全飞地中执行推理] B2 -- B3[硬件签名: 代码输入输出] B3 -- B4[链上验证签名] B4 -- B5[优点: 性能好, ~5% 开销] B5 -- B6[缺点: 依赖硬件, 抗侧信道] C -- C1[将推理转为零知识电路] C1 -- C2[生成 ZK 证明] C2 -- C3[链上验证证明] C3 -- C4[优点: 数学可证, 无硬件依赖] C4 -- C5[缺点: 证明生成极慢, 目前不实用]三、TEE 验证的 Go 实现下面是 TEE 推理验证的核心 Go 实现。包括推理节点端生成证明和验证端校验证明两部分。生产环境中推理节点运行在 SGX 飞地内验证端可以是链上智能合约或链下验证服务。package tee_attestation import ( crypto/sha256 encoding/hex encoding/json fmt time ) // TEEAttestation TEE 远程证明 type TEEAttestation struct { MRENCLAVE string json:mr_enclave // 飞地度量值代码哈希 MRSIGNER string json:mr_signer // 签名者度量值 ISVPRODID uint16 json:isv_prod_id // 产品 ID ISVSVN uint16 json:isv_svn // 安全版本号 ReportData string json:report_data // 自定义数据输入输出哈希 Attestation string json:attestation // 原始证明Intel ECDSA 签名 Timestamp int64 json:timestamp } // InferenceRecord 推理记录 type InferenceRecord struct { ModelID string json:model_id // 模型标识 ModelHash string json:model_hash // 模型文件哈希 InputHash string json:input_hash // 输入哈希 OutputHash string json:output_hash // 输出哈希 TEEProof *TEEAttestation json:tee_proof,omitempty NodeID string json:node_id // 执行节点ID ChainTxHash string json:chain_tx_hash,omitempty } // TEEVerifier TEE 证明验证器 type TEEVerifier struct { // 白名单已知的合法飞地度量值 allowedEnclaves map[string]bool // MRENCLAVE - is_allowed allowedSigners map[string]bool // MRSIGNER - is_allowed } // NewTEEVerifier 创建验证器 func NewTEEVerifier() *TEEVerifier { return TEEVerifier{ allowedEnclaves: make(map[string]bool), allowedSigners: make(map[string]bool), } } // RegisterEnclave 注册合法飞地 func (v *TEEVerifier) RegisterEnclave(mrenclave string) { v.allowedEnclaves[mrenclave] true } // RegisterSigner 注册合法签名者 func (v *TEEVerifier) RegisterSigner(mrsigner string) { v.allowedSigners[mrsigner] true } // VerifyInference 验证推理记录 func (v *TEEVerifier) VerifyInference(record *InferenceRecord) error { if record.TEEProof nil { return fmt.Errorf(缺少 TEE 证明) } proof : record.TEEProof // 1. 验证飞地身份 if !v.allowedEnclaves[proof.MRENCLAVE] { return fmt.Errorf(未授权的飞地: %s, proof.MRENCLAVE[:16]) } // 2. 验证签名者 if !v.allowedSigners[proof.MRSIGNER] { return fmt.Errorf(未授权的签名者: %s, proof.MRSIGNER[:16]) } // 3. 验证报告数据 hash(input output model_hash) expectedData : sha256.Sum256([]byte( record.InputHash record.OutputHash record.ModelHash, )) if proof.ReportData ! hex.EncodeToString(expectedData[:]) { return fmt.Errorf(报告数据不匹配推理结果可能被篡改) } // 4. 验证时间戳防止重放攻击 now : time.Now().Unix() if now-proof.Timestamp 3600 { return fmt.Errorf(证明已过期超过 1 小时) } // 5. 验证 Intel ECDSA 签名生产环境调用 IAS/DCAP API // ias_verify(proof.Attestation) return nil } // SubmitToChain 将推理记录上链存证 func (v *TEEVerifier) SubmitToChain(record *InferenceRecord) (string, error) { // 验证通过后才上链 if err : v.VerifyInference(record); err ! nil { return , fmt.Errorf(验证失败拒绝上链: %w, err) } // 序列化记录 data, err : json.Marshal(record) if err ! nil { return , err } // 计算存证哈希 proofHash : sha256.Sum256(data) proofHashHex : hex.EncodeToString(proofHash[:]) // 模拟上链生产环境调用智能合约 txHash : 0x proofHashHex record.ChainTxHash txHash fmt.Printf(推理证明已上链: TX%s\n, txHash) return txHash, nil } // ---- 推理节点端生成 TEE 证明 ---- func GenerateAttestation( input, output, modelHash string, privateKey ed25519.PrivateKey, ) *TEEAttestation { // 计算报告数据 combined : input output modelHash reportHash : sha256.Sum256([]byte(combined)) // 签名报告数据 signature : ed25519.Sign(privateKey, reportHash[:]) return TEEAttestation{ MRENCLAVE: allowed_enclave_hash_placeholder, MRSIGNER: allowed_signer_hash_placeholder, ISVPRODID: 1, ISVSVN: 1, ReportData: hex.EncodeToString(reportHash[:]), Attestation: hex.EncodeToString(signature), Timestamp: time.Now().Unix(), } }四、当前技术的局限性TEE 有旁路攻击风险。Intel SGX 历史上出现过多次安全漏洞LVI、SGAxe、Foreshadow。虽然已被修补但零风险是不存在的。侧信道攻击通过观察飞地的内存访问模式、缓存命中时间等物理信号来推断飞地内部的数据。对于高安全要求的场景如金融推理需要搭配侧信道防护措施。好消息是这些攻击需要物理接触或高权限访问远程攻击难度极高。ZKP 推理的实用性还很远。目前一个小型神经网络MNIST 级别的 ZK 证明需要数分钟到数小时。大规模 Transformer 模型的 ZK 证明在可预见的未来不现实。但这个领域进展很快ezKL 和 Modulus Labs 等团队在推动 ZK-ML 的工程化值得持续关注。我们踩过一个工程坑TEE 飞地的内存有限SGX v1 只有 128MB EPC70B 参数的模型根本放不进去。解决方案是 SGX 飞地只做推理调度和结果签名模型推理实际在飞地外执行但通过加密通道传输。这降低了安全性但解决了内存限制。SGX v2 支持更大 EPC但需要特定硬件型号。适合 TEE 验证的场景去中心化 AI 推理市场需要防作弊的经济激励需要合规审计的 AI 系统每次推理可追溯多方参与的联邦学习场景保护各方数据隐私。不适合的场景内部推理服务自己的硬件不需要自我证明、对延迟极度敏感的实时推理TEE 开销虽小但不可忽略。五、总结TEE 和 ZKP 是链上 AI 推理可信验证的两条路径。TEE 当前更实用性能开销约 5-10%硬件签名保证执行环境不被篡改。ZKP 是数学上更优雅的方案不依赖任何硬件但证明生成速度目前无法支撑大规模模型。验证流程包括飞地身份校验、签名验证、报告数据匹配、时间戳防重放。推理证明上链后不可篡改可被任意第三方验证。落地建议当前阶段选 TEE用 Intel SGX 或 AMD SEV 搭建 PoC。飞地白名单通过链上治理更新新的模型版本需要重新注册飞地度量值。持续关注 ZK-ML 进展当 ZK 证明生成时间降到分钟级以内时可以开始评估迁移。当前主要局限TEE 的侧信道安全性和 ZKP 的推理效率两者都在快速演进中。