---
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-Hant/blog/aibitrootweb3ai)。融合時的信任缺口清單見 [《Web3 與 AI 融合》](/zh-Hant/blog/web3-ai-convergence)。

## 零知識證明：數學可驗證，電路很貴

ZK 讓驗證者檢查陳述為真，而不必重跑全部運算或看到隱私輸入。對鏈友善的一點是驗證相對便宜（尤其 SNARK 類）；難點是證明生成與電路工程。

- **zk-SNARK**：證明小、驗證快，部分方案依賴可信設定；可用 MPC 儀式降低單點信任。
- **zk-STARK**：無可信設定、偏向量子抗性敘事，證明更大，適合不同的成本曲線。

對大模型而言，「全推論 ZK」往往仍不經濟；更現實的是：對關鍵約束做電路（合規規則、聚合統計、模型雜湊綁定），或對抽樣/摺疊後的運算生成證明。效能數字高度依賴電路與硬體加速，應視為工程目標而非通用 SLA。把 ZK 驗證合約跑在平行 EVM 上，改善的是結算與驗證交易的吞吐量，而不是神奇地降低證明生成成本。

## TEE：把邊界下沉到硬體，信任晶片與供應鏈

TEE（例如 SGX、TrustZone、SEV 等）用隔離執行與遠端證明，讓使用者驗證「程式碼跑在聲稱的 enclave / 安全世界裡」。適合延遲敏感的推論、金鑰操作，以及需要機密性但不想付滿 ZK 成本的路徑。

代價包括：效能損耗、記憶體與介面限制、側通道與供應鏈風險、廠商差異導致的可移植性。誠實的做法是**最小可信運算基**：只把金鑰與敏感切片放進 TEE，其餘在普通環境，並結合挑戰與日誌雜湊。算力網路如何接驗收，見 [《分散式 GPU 與邊緣算力》](/zh-Hant/blog/gpuai)。

遠端證明本身也要進狀態機：證明過期、廠商吊銷清單，以及「證明了錯誤程式碼」的治理問題，都不會因為貼了 TEE 標籤就消失。

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

MPC 基於秘密分享等協議，讓多方在不暴露各自輸入的前提下聯合運算。典型用途：

- **門限金鑰**：私鑰分片，簽章時聚合，完整金鑰不落地。
- **聯合統計 / 聯邦式更新**：共享梯度或統計量，而非原始資料集。
- **模型權重分片推論**：與確權設計銜接，見 [《AI 資產確權》](/zh-Hant/blog/ai-data-ownership)。

通訊輪次與運算放大是主要成本；參與方數量與惡意模型（半誠實 vs 惡意）會急劇改變可行性。MPC 不是「預設的加密雲」，而是為高價值、多方不願交出資料的場景準備的工具。

## 怎麼組合，而不是怎麼堆砌

| 需求偏向 | 更常優先 | 主要代價 |
|----------|----------|----------|
| 公開可驗證、驗證者輕量 | ZK | 證明生成與電路 |
| 低延遲機密推論 | TEE（+ 稽核/挑戰） | 硬體信任與側通道 |
| 多方輸入永不集中 | MPC | 通訊與協議複雜度 |
| 結算與爭議 | 鏈上合約 + 證明/證明承諾 | 確認延遲與 gas |

鏈（尤其是平行 EVM 結算層）負責任務狀態機與支付，不負責替代上述密碼學；架構見 [《平行 EVM 架構概覽》](/zh-Hant/blog/bitrootevm)。混合執行如何分流輕重任務，見 [《AI 原生區塊鏈》](/zh-Hant/blog/ai-native-blockchain)。測試網口徑下的確認與吞吐數字，描述的是結算基板，讀法見 [《效能指標術語表》](/zh-Hant/blog/performance-metrics-glossary)。

## 威脅模型怎麼寫進選型表

選型前寫清楚：對手能否控制執行節點的 OS、能否收買證明者、機密要對抗多久、驗證者的硬體預算。主機被控但遠端證明難以偽造時，TEE 有意義；需要公開且可長期複驗時，ZK 更合適；多方絕對不交出原文時，MPC 幾乎不可避免。把「企業級安全」當成單一分數，會掩蓋不可比的維度。與 Agent 相關的缺口見 [《Web3 與 AI 融合》](/zh-Hant/blog/web3-ai-convergence)。

落地時還要把「證明由誰生成、誰驗證」寫進維運手冊：是任務執行者自證、獨立的證明市場，還是由協議指定驗證者抽樣複算。角色不清時，TEE 遠端證明和 ZK 證明都可能變成擺設。證明驗證交易本身會佔用結算層吞吐量，因此平行 EVM 的價值在於讓驗證與結算交易更跟得上，而不是降低證明生成的漸近複雜度。堆疊位置見 [《去中心化 AI 堆疊》](/zh-Hant/blog/aibitrootweb3ai)。

電路與 enclave 程式碼本身也需要版本治理：過時的證明電路、未輪換的測量值，或廠商微碼變更，都可能讓「昨天還能驗證」的流程今天失敗。版本雜湊應進入任務的中繼資料，並與 [《AI 資產確權》](/zh-Hant/blog/ai-data-ownership) 中的製品版本策略對齊。

## 威脅模型要寫進產品說明

同一套 ZK/TEE/MPC 組合，在半誠實對手與惡意對手下的含義完全不同。產品資料若只寫技術名詞而不寫對手能力，讀者無法判斷「可驗證」強到哪一步。至少應聲明：執行節點是否可能隱瞞輸入、是否可能合謀、證明過期與金鑰輪換如何處理，以及鏈上爭議窗口由誰推進。

對 AI 推論市場而言，常見的折中是：日常用 TEE 或抽樣重算來壓延遲，對高價值結算切換到更強的證明；訓練任務則更依賴檢查點（checkpoint）、冗餘與經濟罰沒，而不是每次梯度都做全 ZK。混合執行分流見 [《AI 原生區塊鏈》](/zh-Hant/blog/ai-native-blockchain)；結算層角色見 [《平行 EVM 架構概覽》](/zh-Hant/blog/bitrootevm)。

## 成本會計：不要只比「安不安全」

選型常被簡化成安全等級排序。更有用的是單位任務的證明成本、延遲分位，以及失敗時的人工介入成本。TEE 可能在 p50 延遲上勝出，卻在供應鏈稽核上更貴；ZK 可能在公開可驗證上勝出，卻在證明生成佇列上排隊；MPC 可能在資料永不集中上勝出，卻在參與方維運上最重。

把這三項成本寫進同一張表，再疊加結算層的 gas 與確認延遲，才能判斷某個 AI 工作流在經濟上是否可重複。效能術語見 [《效能指標術語表》](/zh-Hant/blog/performance-metrics-glossary)；算力生命週期見 [《分散式 GPU 與邊緣算力》](/zh-Hant/blog/gpuai)。

可驗證 AI 的成熟標誌，不是名詞是否齊全，而是能否在故障與爭議發生時指出：信任錨在哪、證據如何提交、鏈上狀態如何收斂。做不到這三點，框架就仍停留在簡報上。

## 與結算層的介面契約

證明、遠端證明引用或 MPC 簽章最終都要變成合約可理解的輸入。介面應約定：哪些欄位上鏈、哪些只存承諾、驗證失敗時任務狀態如何轉移，以及過期證明是否自動作廢。介面含糊時，再強的密碼學也會在應用層被「人工確認」稀釋。平行 EVM 負責讓這些狀態轉移足夠快；它不負責生成證明本身。

## 小結

可信運算框架的價值，是為 AI 運算提供可論證的完整性與機密性選項，並明確每條選項的信任假設。沒有銀彈；有的是按威脅模型選型。任何把 ZK/TEE/MPC 寫成「企業級一鍵安全」的表述，都值得降級為：在特定假設下可降低特定風險。本文不構成投資建議。

## 延伸閱讀

- [《去中心化 AI 堆疊》](/zh-Hant/blog/aibitrootweb3ai)
- [《分散式 GPU 與邊緣算力》](/zh-Hant/blog/gpuai)
- [《Web3 與 AI 融合：信任缺口》](/zh-Hant/blog/web3-ai-convergence)