零知識到底用在哪裏：zkLogin、協處理器與身份檢查

2026-08-12

理解零知識系統，最有效的方式是把每個證明都對應到一個具體聲明。證明可以隱藏憑證欄位、證明鏈下計算的結果，或證明某項身份規則已經滿足，而不公開底層文件。它不會令每個組件自動變成無需信任，也不會把一次登入變成通用身份。本文依據 2026 年 8 月 10 日查閱的資料，沿着零知識證明、zkLogin、ZK 協處理器和身份檢查的邊界展開。

零知識證明到底隱藏了甚麼

零知識證明是一種讓證明者說服驗證者相信某個聲明為真，同時隱藏選定見證資料的方法。聲明可以是簽名令牌包含某種關係、程式產生了某個結果，或憑證滿足某項規則。證明本身不是聲明，而是關於公開輸入與私有輸入之間關係的證據，並且這項關係由指定電路或程式定義。

這一區分很重要，因為私隱是有選擇的。驗證者可能看到布爾結果、公開承諾、網絡標識、程式標識或時間戳，卻看不到私有輸入。年齡門檻證明可以隱藏出生日期，但它本身不能證明底層憑證由誰簽發、簽發者是否可靠，或驗證者是否使用了正確政策。

因此，實際問題不是某個產品是否使用 ZK，而是哪些資料公開、哪些資料私有、誰生成見證、哪些密鑰或設置參數需要信任，以及誰驗證結果。系統即使使用了可靠證明，仍可能依賴 OAuth 提供商、鹽服務、索引器、資料可用性層、憑證簽發者，或一個選擇了薄弱規則的應用。

zkLogin 如何把網頁登入綁定到地址

搜尋 zkLogin 解釋的讀者，應先理解身份綁定，而不是先把它當成錢包。Sui 的 zkLogin 使用 OpenID Connect 登入取得簽名 JSON Web Token。應用還會生成短期臨時密鑰對。令牌中的 nonce 由臨時公鑰、隨機數和過期 epoch 構成，因此後續交易會話會與這次登入流程相綁定。

Sui 文件把鹽服務和證明服務描述為不同的後端角色。鹽值與簽發者、應用受眾和 subject 聲明一起參與地址種子推導。只要鹽值保持私密，就可以把 OAuth 標識與鏈上地址解關聯。證明服務接收令牌及相關輸入並生成 Groth16 證明，檢查提供商簽名、nonce 構造、聲明值和地址推導之間的關係。

地址和會話密鑰有不同的生命周期。只要底層簽發者、受眾、subject 和用戶鹽值不變，地址可以保持穩定。臨時密鑰則會在指定 epoch 過期。用戶重新登入後，可以為同一個地址生成新的會話密鑰和證明。驗證者會在執行交易前檢查證明和臨時簽名。這是特定於協議的流程，並不意味着每種社交登入都會產生自託管身份。

信任邊界可以從細節中看出來。OAuth 提供商負責認證賬戶並簽署令牌。應用負責前端和臨時密鑰。鹽服務在其設計允許的情況下可能看到敏感輸入，證明服務會處理令牌和證明輸入。Sui 說明這些服務在自己的視圖中可能把身份與鹽值關聯起來，雖然 JWT 不會發布到鏈上。因此，私隱結果取決於這些假設，也取決於用戶鹽值和會話密鑰是否受到保護。

ZK 協處理器計算甚麼

理解 zk coprocessor 這個詞，最好把它當成架構問題。協處理器把資料量大或計算量大的任務移到應用鏈之外，然後返回結果以及證明，說明任務使用了經認證的輸入並執行了聲明的計算。在純 ZK 設計中，驗證合約可以檢查證明並使用結果，而不必重複完整計算。

Brevis 文件用三個階段說明這種模式：資料訪問、應用計算和結果使用。應用請求歷史鏈上資料，鏈下證明者運行自定義邏輯，然後把結果與證明提交給鏈上驗證。相同結構可以支援歷史活動門檻、成員資格規則、獎勵計算或風險標記。證明不會自動證明資料源適當，而是證明系統實際編碼並證明的關係。

這和單純向索引器索取答案不同。未經證明的索引器回應要求合約或用戶信任提供資料和計算的一方。ZK 協處理器可以把結果與經認證的鏈上資料及電路綁定，從而減少這類信任。但電路、資料承諾、證明系統、驗證器和更新流程都會成為需要審查的新組件。

協處理器也不是一個固定的產品功能。Brevis 區分純 ZK 模式與 coChain 或樂觀模式，兩者在延遲、成本和挑戰機制上不同。RISC Zero 則把可驗證計算更一般地描述為：程式輸出帶有可檢查的收據，驗證者無需重跑原始計算或看到私有輸入。這些資料說明了概念，但每個部署仍需要單獨確認聲明、輸入認證和失敗處理。

身份檢查的證明邊界在哪裏

身份檢查可以被表示為關於憑證的聲明，而不是關於某個人的魔法證明。驗證者可以詢問簽發者是否簽署了憑證、憑證是否仍在有效期內、主體是否超過年齡門檻，或文件標識是否出現在撤銷列表中。ZK 電路可以隱藏聲明不需要的欄位，同時只公開應用所需的最小結果。

因此，所謂 zero knowledge identity verification 應拆分為簽發者、持有者和驗證者角色。W3C 可驗證憑證模型把憑證描述為簽發者提出的聲明，由主體或持有者持有，再以可檢查真實性和完整性的機制提交給驗證者。W3C DID 描述標識符和驗證方法，但標準本身不會因為存在 DID 或憑證格式，就保證現實中的人、組織或文件真實。

以年齡檢查為例，證明可以顯示經過簽名的出生日期早於政策截止日，卻不公開日期。它不能自行判斷簽發者是否可靠地檢查過文件、憑證是否屬於當前持有者、政策截止日是否適用於某個司法管轄區，或憑證是否已經撤銷。這些分別屬於簽發者、綁定、政策和生命周期問題。

制裁、居住地、資歷和賬戶唯一性也有相同邊界。電路可以編碼簽發者屬於批准集合且聲明滿足規則的謂詞，但它不能自動修復薄弱的簽發者註冊表、被盜憑證、被攻破的錢包、錯誤的源記錄或不完整的撤銷資料。結果為真，只表示編碼的謂詞針對所提供輸入通過驗證，並不表示輸入背後的所有現實事實都為真。

私隱是設計選擇，不是證明輸出

ZK 可以減少披露，但私隱取決於完整流程。驗證者仍可能觀察公開地址、時間、網絡、應用受眾、證明頻率，或某項政策曾被嘗試這一事實。如果應用重複使用標識符或公開承諾，多次提交可能可以關聯。元資料可能比電路隱藏的私有見證透露更多信息。

zkLogin 通過鹽值和 OpenID 聲明展示了這一點。鹽值幫助把 OAuth 標識與鏈上地址解關聯，但遺失鹽值可能導致地址無法恢復，暴露鹽值則可能讓 subject 聲明可以被關聯。OAuth 提供商、前端、鹽服務、證明服務和驗證者看到的流程片段不同。私隱審查應當畫出這些視圖，而不是把證明當作一個隱私開關。

對協處理器而言，私隱還取決於原始資料和見證在哪裏處理。證明可以讓鏈上驗證者在看不到私有輸入的情況下檢查結果，但鏈下證明者或資料提供者可能在計算時看到它們。應用還可能公開結果、查詢標識、區塊範圍或承諾。如果需要對證明者也保持機密，可能還需要私有證明、安全執行或加密計算，而不只是公開的 ZK 驗證器。

最小披露原則很有用：只證明應用所需的謂詞，使用有明確目的的受眾或域分隔符，按照協議預期輪換會話材料，並記錄保存和關聯風險。這些控制不會消除信任，但能讓剩餘的信任和披露路徑可以被審查。

信任模型必須點名哪些角色

先寫清楚聲明和公開輸入。準確記錄驗證者接受甚麼、哪些資料被承諾、鏈上狀態或憑證如何認證，以及哪個軟件或電路版本生成證明。如果合約可以消費結果，還要記錄驗證器代碼、升級權限、緊急路徑和過期資料處理方式。

然後點名參與者。zkLogin 包括 OpenID 提供商、應用、臨時密鑰持有者、鹽服務、證明服務和 Sui 驗證者。協處理器還要加入資料源、索引器或輕客戶端、證明者、驗證器以及任何挑戰或質押機制。身份檢查還要加入簽發者、持有者、錢包或展示層、驗證者和撤銷或狀態服務。圖中缺少角色本身就是風險信號。

接着把正確性與可用性和恢復分開。有效證明可能不能及時到達。提供商可能輪換密鑰。鹽服務可能不可用。憑證可能過期。鏈重組或最終性規則可能改變輸入集合。協處理器的樂觀路徑可能依賴挑戰窗口內有人誠實地提出挑戰。這些是運營屬性，不是數學證明會自動修復的失敗。

最後審查設置和升級假設。Sui 記錄了 zkLogin 的 Groth16 通用參考字符串儀式。其他系統可能使用透明證明系統、zkVM 收據、可信設置、委員會、質押層或組合方案。應詢問誰可以改變電路、驗證器、簽發者註冊表、提供商列表、資料源或政策。證明即使能正確驗證昨天的政策，也可能不適合今天的政策。