隱私不是把資料藏起來，
而是重新安排誰能做什麼

Circle 的 Arc 想用可信執行環境，讓鏈上程式在不公開狀態的前提下仍可組合、除錯與接進企業系統。它換掉的不是信任，而是信任被放置的位置。

來源：Zero Knowledge Podcast Episode 405 ｜原始發表日期：2026 年 7 月 8 日

SCROLL

PART 1 ｜ Arc 想解的不是「上鏈」

公開帳本適合驗證，
卻不適合所有金融工作

Sergey Gorbunov 在訪談中把 Arc 描述為以 USDC 作為 gas token 的 EVM 相容鏈，目標是機構金融。但機構要處理的交易、部位與客戶關係，往往不能把每一筆狀態攤在公開帳本上。Arc 的 Privacy Sector 因此嘗試讓私密執行與公開鏈並存。

這不是讓所有事情變成黑箱。公開鏈仍負責可驗證的結算與協調；私密區域則把某些程式執行、帳戶與交易狀態留在受限環境中。問題從「資料要不要上鏈」變成「哪些資訊必須公開，哪些計算可以在可驗證的隔間中完成」。

訪談中的設計取向：隱私若完全切斷組合性與開發流程，實務上很難被大量採用。Arc 想把私密執行放進既有 EVM 與企業工作流程可接住的位置。

PART 2 ｜為何不是全部交給 ZK 或 FHE

受訪者把 TEE、零知識證明與全同態加密放在同一張取捨表上。ZK 可以把某個聲明的正確性做成可驗證證據；FHE 的理想是直接在密文上運算。兩者都有很強的密碼學性質，但在通用程式、延遲、除錯與既有工具鏈上，成本仍可能很高。

TEE 是另一種路徑：在硬體隔離的執行環境裡處理敏感資料，外部系統依賴硬體與遠端證明來確認程式在預期環境中運行。它讓開發者較容易沿用熟悉的程式模型與基礎設施，也把風險從「演算法是否成立」移到硬體、韌體、供應鏈與證明流程是否可信。

公開鏈結算、排序與可驗證協調

隱私區域受限環境處理私密狀態

遠端證明確認程式與環境符合宣告

外部系統依結果接續支付、合規或服務流程

PART 3 ｜可組合性不是自動附贈

節目談到的關鍵不是把資料加密後封存，而是私密執行能否與合約、開發者工具與企業系統共同運作。若每個私密區域都是孤島，應用只能在封閉資料庫裡跑。若所有資料都為了組合性重新公開，隱私又失去意義。

因此 Privacy Sector 面對的是授權問題：哪些程式可以讀取哪一類狀態？誰可驗證一個結果？跨區傳遞時保留的是原始資料、經過篩選的聲明，還是只能觸發下一步的權限？這些規則決定了「私密」是保護使用者，還是只是把可見性從公眾移給平台營運者。

隱私限制原始資料與狀態的揭露範圍。

組合讓其他程式能在必要的權限下接續工作。

可審查讓外部人能檢查規則、版本與例外處理。

PART 4 ｜ TEE 不會刪除信任

TEE 的實用性不等於它是免信任方案。使用者與整合方仍得問：受信任硬體來自誰？遠端證明驗了什麼版本？金鑰怎麼管理？發現漏洞時，能不能撤銷、升級與留下可追溯的記錄？這些問題不在介面上，卻決定隱私承諾能否成立。

Gorbunov 的論點較像工程排序：當市場需要今天就能部署的私密、可程式化執行，TEE 提供一條實作路線；ZK 與 FHE 仍是重要方向，且可能在不同工作負載或未來成熟度下更合適。讀者不必把它理解成三種技術的勝負，而是三種不同的揭露、效能與信任成本。

隱私系統最重要的問題，
不是「資料有沒有被藏起來」，
而是「誰仍能在什麼條件下使用它」。

TEE 可以降低公開揭露，卻不能替代對硬體、證明、權限與升級流程的檢查。

Zero Knowledge Podcast Episode 405 保留 Sergey Gorbunov 對 Arc、Axelar、TEE、ZK、FHE、企業金融與隱私工程取捨的完整討論。