零知識證明是一種密碼學方法，用來證明一項經過仔細界定的陳述有效，同時不披露令該陳述有效的私密資料。這個名稱很容易被理解得太廣。它不表示系統完全不會披露任何東西；證明通常顯示一項已界定陳述符合已界定的核實規則，而應用程式仍可能在證明以外公開輸入、時間、日誌、識別碼或其他中繼資料。
所以較有用的問題是具體的：正在證明甚麼陳述？哪些資料是私密的？哪些是公開的？核實成功究竟確立甚麼？本文先介紹這些詞，再把 SNARK 和 STARK 說明為零知識證明系統的廣義家族。這是教材式解說，並非建議讀者使用、選擇或依賴某一種證明系統。
陳述、見證與已界定的關係
每個證明系統都由一段可評估的關係開始。公開部分常稱為「陳述」。它可以是某個數值符合已公布條件，或一項運算按照聲明規則產生某個輸出。用以說明陳述為何成立的資料，通常稱為「見證」。見證可以是秘密數值、一組輸入，或系統界定的其他私密資料。
陳述和見證的分界很重要。驗證者只能核實已被編碼的關係。若陳述說輸入符合某個條件，接納結果只是在系統規則下確認那個條件；它不會自動說明輸入從哪裏來、有否包括所有相關現實事實，或某人核實後打算怎樣做。那些問題仍各自需要證據、定義和治理。
不少系統用近似程式的「電路」描述關係。這裏的電路，是證明系統可檢查的受約束運算抽象，並不只是普通應用程式。關係如何寫、採用甚麼欄位、施加甚麼限制，會因構造而異。因此，證明關乎一段精確關係，而不是關於現實的含混說法。
這組詞亦說明完整陳述為何不可少。關係若漏掉重要條件，證明仍可對那段不完整關係有效。密碼學可以保障已界定關係的完整性，但不能替人決定哪些現實要求本應寫進關係。
零知識會隱藏甚麼，又不會隱藏甚麼
零知識性質關注的是驗證者從收到或參與證明中得知甚麼。直觀來說，驗證者應能確信陳述有效，卻不從見證取得超出陳述本身所披露的資料。關於交互式證明系統的經典研究，會比較真實驗證者視圖與一個不使用見證的模擬視圖，來形式化這個直覺。
這個性質屬於協議，並不會自動覆蓋周邊應用程式的每一層。系統可刻意公開陳述或公開輸入，也可保留日誌、暴露識別碼，或經網絡傳送中繼資料。證明可限制見證披露，但系統其他部分仍可帶來不同的私隱風險。因此，私隱分析要看完整資訊流，不能只看有沒有零知識證明。
零知識亦不會令驗證者變成完全被動。驗證者會取得足以執行指定檢查的證明材料。協議在自身假設和範圍內，讓這些材料支持接納陳述，但不會以可用形式交出秘密見證。所有刻意公開的資料，都應讓解讀結果的人清楚知道。
證明者與驗證者
「證明者」是持有見證並產生證明的一方或元件；「驗證者」接收公開陳述、適用公開參數和證明資料，再執行系統的核實程序。這是角色，而不是固定類型的人。應用程式可把它們安排為獨立服務、本地元件，或分散環境中的參與者。
產生證明和驗證證明的職能不同。證明者利用見證表明可滿足關係；驗證者檢查證明是否符合關係和核實規則。驗證者收到證明後，不必重做私密計算。所需工作量、證明材料、互動方式和公開設定，會隨構造而改變。
脈絡亦同樣重要。對一項陳述有效的證明，不會自然對另一項陳述有意義。版本、公開輸入、關係定義和驗證材料，都會影響如何理解。證明系統不能判斷某個技術結果是否適合用作法律、科學、機構或社會決定；界定關係和決定解讀方式，仍是應用程式的責任。
完備性、可靠性與接納
兩項基本性質有助說明核實為何有用。「完備性」大意是：對真實陳述持有有效見證的誠實證明者，應可產生被誠實驗證者接納的證明。若沒有完備性，正確的參與者即使已滿足關係，也可能被拒。
「可靠性」或 soundness 則處理相反方向。大意是，證明者不應能令驗證者接納錯誤陳述，除非出現系統界定的有限概率，或在該系統所列假設下。可靠性不是通用的事實核查性質；它適用於形式關係、對手模型和安全定義，並不自行證明輸入收集正確，或未被編碼的現實說法為真。
有些構造還會談「知識可靠性」。在高層次上，這個詞把成功證明與證明者擁有或能產出所需類型見證的概念聯繫起來。它的精確定義具技術性並因構造而異，不能改說成證明者知道讀者可能聯想到的所有背景事實。
完備性和可靠性合起來，令接納在有限意義上成立：正確形成、針對真實關係的證據應被接納；錯誤關係不應只是因為被聲稱便獲接納。它們沒有免除關係必須寫對、實作必須正確，和結果必須放在脈絡中判斷的需要。
在脈絡中理解產生與核實證明
概念上，產生證明由公開陳述、私密見證和連繫兩者的關係開始。證明者進行其證明系統指定的運算，產出證明資料。核實則由公開陳述、所需的驗證材料和證明資料開始；驗證者按協議得出接納或拒絕。
各種系統會就互動性、隨機性、公開參數、密碼學假設和計算表示作不同選擇。有些有設定階段以產生參數；另一些被稱為透明，因為不需要秘密設定參與者。這些設計選擇很重要，但單憑標籤不足以證明一個完整實作已有預期的安全性質。
不論系統如何，四個問題都很有用：公開的是哪一項精確陳述？見證是甚麼？假定或信任哪些驗證材料？接納確立甚麼，又沒有處理甚麼？即使證明連接的是帳本、憑證、資料庫或其他軟件，這些問題都適用。
SNARK 與 STARK 作為兩類證明系統
SNARK 常被展開為「簡潔、非互動式的知識論證」。廣義而言，SNARK 構造嘗試讓證明者產生精簡證明，供驗證者在毋須互動往返下檢查。「論證」在這裏有技術含義：安全性依賴計算假設，而非無條件的數學保證。個別構造在設定模式、假設、證明表示和支援的關係上均可不同。
Pinocchio 等有關可驗證計算的研究，展示一個常見結構：公開材料描述一項運算，工作者為特定輸入產生證明，驗證者再檢查。不過，這個歷史例子不應被視為所有後來稱為 SNARK 的系統之定義。總稱涵蓋相近概念，並非單一一致的實作。
STARK 常被展開為「可擴展、透明的知識論證」。這個名稱通常與強調透明設定模式、並採用不同於常見配對型 SNARK 方法的證明技術之構造有關。早期 STARK 研究討論透明的計算完整性和後量子安全脈絡。這些描述是關於某個構造和它的假設，並不令每個實作可以互換，也不形成普遍結論。
因此，有用的比較必須針對一項特定構造：它的形式假設、設定要求、關係表示、核實環境、實作質素和公開資料。SNARK 和 STARK 是理解概念的地圖，不是對安全、私隱或適合性的自動判斷。
範圍、限制與周邊信任
有效證明只確立其關係所表示的陳述。它不會自行表明底層資料收集公平、來源獲授權、系統外事件發生，或陳述仍然有效。若關係接收了不完整或誤導輸入，核實相對於那些輸入仍可正確。證明保護的是已界定運算，不是結果可被附加的一切解讀。
零知識也不會移除所有私隱考慮。公開輸入可以有揭示性；重複出示可形成關聯；網絡、裝置、帳戶、介面和應用程式中繼資料可存在於證明以外。設計應直接檢查這些渠道，而非把證明當成完整私隱邊界。
實際安全還取決於數學假設、在適用時的參數處理、正確的軟件，以及檢查預期陳述的驗證者。任何一層出現問題，都可能改變結果。正因如此，SNARK 或 STARK 這類簡短標籤應是細心閱讀的起點，而不是最終結論。
解讀一項證明主張時，應辨認陳述、見證、公開輸入、證明者、驗證者和驗證材料，然後把技術上的接納和較廣的信任分開。驗證者可以確認結果符合協議規則，卻仍要評估來源、定義、脈絡和自身政策。這種清楚的區分，說明零知識證明實際證明甚麼，以及它的界線仍在哪裏。
風險披露：本文為 Bitbase（幣貝）學院的科普內容，僅供教育與資訊參考，不構成任何投資、交易、稅務或財務建議。加密資產波動劇烈，請自行評估風險。本文撰寫於 2026 年 8 月，請以官方最新資訊為準。
參考資料
[1] Goldwasser, Micali and Rackoff: The Knowledge Complexity of Interactive Proof Systems people.csail.mit.edu
[2] IACR ePrint 2013/279: Pinocchio eprint.iacr.org
[3] IACR ePrint 2018/046: Scalable, transparent, and post-quantum secure computational integrity eprint.iacr.org
[4] W3C: Verifiable Credentials Data Model v2.0 w3.org
