加密合約落地，先把證據和揭露規則講清楚

Fhenix在2026年10月20日發布的技術文章討論了合約使用加密數值計算時的安全問題。它值得關注的地方，是把應用設計帶回了一個常常由密碼學主導的話題。Fhenix技術文章

對於考慮採用鏈上保密應用的企業，首先要決定哪些資訊不應被其他參與者得知，隨後還要決定這些參與者必須能夠核驗什麼。兩種要求可能產生張力：採購流程需要隱藏競爭者的報價，同時又要證明最後遵循了事先公布的選擇規則。把報價隱藏起來，並沒有回答規則由誰制定、誰能修改，以及發生爭議後誰可以查看結果。

本文提出的是分析框架，不是對某項部署的安全評估。架構文件可以說明設計主張，不能證明實作中不存在缺陷；研究某類系統的論文，也不能直接成為某個具體產品存在漏洞的證據。

報價保密之後，交易規則仍需明確

假設一家採購方採用加密招標。供應商提交競爭對手無法讀取的價格，採購方則希望選出滿足交付和品質要求的最低報價。保密有明確的商業理由：供應商不應為了競爭一筆訂單，就必須公開整套定價策略。

但數值最低，並不一定代表業務上應該中選。供應商可能使用了錯誤的幣別，沒有計入運費，或者承諾了不符合要求的交付日期。即使加密算術完全正確，也可能比較了本來就不應放在一起比較的輸入。因此，應用在開始計算之前，就需要定義什麼是合格報價。加密技術無法替採購方判斷交付承諾是否可信，也無法判斷招標規格是否真正符合採購需求。

輸出端同樣存在選擇。採購方可能只需要知道中選供應商和最終應付金額。向所有參與者公開完整排名，可能揭露超出交易需要的商業資訊；反過來，揭露過少又可能讓落選供應商無法質疑前後不一致的決定。合適的揭露政策應來自交易目的及其爭議處理安排，而不是由某一種密碼學技術自動決定。

計算有效與決定合理，需要不同證據

2023年1月17日提交的《Verifiable Fully Homomorphic Encryption》論文將計算完整性視為獨立問題，並研究應對惡意執行的保護方法。這是歷史技術研究，不是對當前CoFHE實作的漏洞認定。研究論文

對於上述假想招標，這提示我們區分兩類保證。技術核驗關注的是：指定的操作是否確實作用於指定的輸入。業務審查關注的是：這些輸入和操作是否代表各方約定的採購規則。前者的證明不能悄悄替代後者。如果一項加密比較準確執行了已經過時的准入條件，它仍可能選出業務上無法接受的供應商。

這種區分還會改變證據的組織方式。一份有用的審查紀錄，應當把規則版本、被接受的輸入集合、正在核驗的計算，以及最後揭露的結果聯繫起來。脫離這些背景的密碼學檢驗，即使在數學上有意義，也可能不足以解釋採購決定。這是本文對證據設計的分析判斷，並不意味著某個協定會自動提供全部相關紀錄。

採購團隊尤其需要在系統上線前約定誰負責解釋這些紀錄。技術人員能夠確認程式執行情況，卻未必有權解釋商業例外；業務負責人能夠說明採購目的，也未必知道一項證明涵蓋了哪些條件。把兩種責任都交給一個籠統的「系統已驗證」標籤，會使爭議發生後的溝通更加困難。

權限設計本身就是產品的一部分

Zama當前的ACL文件區分長期有效的密文權限和僅在當前交易內有效的權限，並單獨說明讓數值能夠被公開解密的授權。這些對應不同的應用選擇。Zama ACL文件

採購團隊可以藉助這種區分，把自身要求寫清楚，而不必假定各個平台的控制機制完全相同。計算服務可能只需要一次任務的臨時權限；稽核人員可能需要在特定委託範圍內查看特定資訊；客服人員可能只需掌握解決某張服務單所需的內容。如果三個角色都獲得同樣寬泛的權限，管理也許更方便，卻會削弱最初採用保密應用的理由。

權限的範圍還需要經得起普通的組織變化：供應商更換帳戶、稽核合約結束，或者採購方替換外包營運商。設計問題不只是「能不能授權」，還包括團隊能否識別受影響的資料，並理解權限變化能做到什麼、做不到什麼。停止未來存取，無法讓接收者忘記已經獲得的明文。因此，即使底層計算保持加密，匯出的報表和螢幕截圖仍然屬於日常隱私管理的範圍。

這也意味著，權限評審不能只發生在首次接入。一個原本只負責展示結果的服務，後來可能增加分析或匯出功能。功能變化未必構成技術故障，卻可能改變實際接觸資料的人和系統。企業需要能夠識別這種業務範圍變化，再決定是否調整授權，而不能僅憑舊版本曾經通過審查就持續放行。

評估當前系統，而不是把路線圖提前兌現

CoFHE當前的Teecryptor文件說明，解密在經過證明的可信執行環境內進行，多方閾值解密則被列為計畫中的替代方案。現有設計和未來路線圖不應混為一談。CoFHE Teecryptor文件

這一限定並不是反對部署存在硬體假設的系統。只要收益值得，企業經常會接受技術依賴。它要求的是比較真實的依賴條件，而不是比較行銷分類。採購方應理解哪些元件必須保持可用、有哪些證據支持其運作，以及必要的服務無法產出結果時將發生什麼。

對招標而言，即使沒有報價外洩，也沒有算術錯誤，結果暫時無法取得仍可能推遲決標。事先約定延期或取消程序，可能比臨時擴大揭露範圍更有價值。但這類程序也有商業成本，例如供應商可能需要更久地預留產能。因此，保密性、可用性和合約時間安排需要一起考慮，而不是由不同團隊分別評估後，再也不核對彼此的假設。

加密計算最有說服力的用途，是讓參與者無需分發全部底層資料，也能完成合作。在資訊揭露本身會造成競爭成本的場景中，這種價值是真實而具體的。當應用能夠說明哪些事實保持隱藏、哪些結論可以被檢驗，以及哪些人仍對變更和例外擁有決定權時，這種價值也更容易被評估。

因此，初期部署應接受一次完整交易和一次現實爭議的檢驗，而不只是展示加密計算能夠運作。如果採購方能夠在不暴露無關報價的情況下解釋有爭議的結果，並在流程停滯時仍遵守原來的揭露限制，技術就服務於一個可以辨認的業務需求。某項具體實作能否做到這些，仍需證據和測試，不能從FHE這個名稱直接推導出來。