為什麼僅靠零知識證明不足以保護使用者隱私

零知識證明常被描述成隱私保護的完整答案。在公民科技中，這個承諾尤其有吸引力：一個人可以證明自己有資格參與、是唯一的真實個體、超過某個年齡，或居住在某個司法轄區，而無需公開完整身分證件。

這個承諾是真實的，但範圍也比聽起來更窄。

零知識證明保護的是「證明」本身。它不會自動保護使用者的 IP 位址、瀏覽器指紋、電話號碼、電子郵件、錢包實作、裝置、作業系統，也不會自動保護圍繞證明產生的時間戳和行為訊號。如果這些周邊層沒有被謹慎設計，驗證方仍然可能知道使用者是誰。

本文改寫自 2024 年 9 月向 NGI TrustChain 做的一次簡報。核心觀點很簡單：零知識證明是私密公民參與的重要構件，但使用者隱私是一種全棧屬性。

為什麼公民平台需要身份

並不是所有線上空間都需要身份驗證。有些社群完全可以依靠持久化暱稱和聲譽系統來運作，而不需要正式憑證。

公民參與平台面對的是另一類問題。如果目標是收集有意義的公共意見、抵抗垃圾訊息、減少計算宣傳，或支持「一人一票」流程，系統就需要某種抗女巫攻擊能力。實際場景中，它可能需要確認參與者是真實的人、屬於某個相關社群，或符合某條公民資格規則。

抗女巫攻擊有多種方式，但各有代價：

生物識別系統可以提供唯一性，但會帶來嚴重的隱私和安全風險。
社交圖譜系統在某些場景中有用，但難以規模化，隱私保證也往往較弱。
混合式信任網路適合某些社群，但通常只能提供較弱的唯一性。
政府或機構憑證可以提供更強的保證，但絕不能變成監控層。

這正是自主身份和零知識證明變得有吸引力的地方。它們提供了一種方式：驗證資格，同時不要求使用者暴露超過必要範圍的個人資料。

零知識證明擅長什麼

在一個簡化的憑證流程中，有三方：

簽發方確認某個人的某項事實，並簽發憑證。
持有人保存憑證，並決定何時使用它。
驗證方檢查由該憑證生成的證明。

零知識技術可以讓持有人證明某個具體聲明，而不透露底層憑證。例如，使用者可以證明自己已滿 18 歲，而不透露出生日期；也可以證明自己收到了可信簽發方的憑證，而不公開憑證的完整內容。

多種技術路線可以支持這個模式。BBS+ 憑證支持選擇性披露和不可連結證明。其他方案會把更容易連結的憑證格式「Merkle 化」，再使用 ZK-SNARKs 來提高隱私。通用 zkVM 未來也可能讓既有安全憑證上的事實證明更加容易。

這些工具很有價值，因為它們可以在證明層面提供簽發方不可連結性。換句話說，簽發方不應知道憑證在哪裡被使用，同一憑證的不同使用也不應因為證明本身而被輕易關聯。

這解決了一個重要問題，但並沒有解決所有隱私問題。

威脅模型：從持有人出發

對公民參與來說，隱私模型必須從憑證持有人的角度開始。使用憑證的人必須掌控自己向誰透露什麼。

這要求比今天大多數社交平台更嚴格的威脅模型：

驗證方，也就是請求證明的平台，不應被盲目信任。除非系統讓這種行為變得困難並可審計，否則它可能一直試圖去匿名化使用者。
簽發方被信任來識別持有人並簽發有效憑證，但不應被信任去知道該憑證之後在哪裡、何時、為何被使用。
簽發方和驗證方不應能夠透過合謀來識別使用者。
專有客戶端程式碼、錢包程式碼和驗證方前端都應被視為風險面，除非它們開源、可檢查，並最好經過第三方審計。

這與主流社交媒體模型非常不同。當前模式通常要求使用者相信平台會負責任地收集、保存和保護個人資料。網路平台的歷史已經給了使用者很多懷疑這種信任的理由。

隱私冰山的其餘部分

最常見的錯誤，是把零知識證明當成整個隱私系統。實際上，證明只是一層。

過度披露

即使證明是用零知識方式生成的，驗證方仍可能請求過多、過精確或過稀有的屬性。使用者也許沒有公開完整身分證件，但多個屬性組合起來仍然可能識別出這個人。

例如，在一個小社群中，同時證明精確年齡、城市、職業和會員身份，可能已經足以定位某個人。保護隱私的系統應優先使用粗粒度謂詞，並堅持最小必要披露。

網路後設資料

驗證方可以嘗試透過 IP 位址、瀏覽器指紋、裝置後設資料或請求時間，把證明和使用者關聯起來。如果證明是從同一個瀏覽器工作階段中提交，而該工作階段又包含登入或郵件驗證，那麼證明的數學隱私可能已經不再重要。

零知識預設不會隱藏網路層。傳輸隱私、代理、日誌策略和工作階段隔離同樣重要。

Cookie 和資料經紀商

第三方 Cookie、分析腳本、廣告識別符和購買的資料，都可能削弱證明隱私。如果驗證方在證明流程周圍嵌入追蹤程式碼，它可能把匿名證明和已知網頁身份關聯起來。

對公民平台來說，證明流程應完全避免第三方追蹤器。不能一邊依賴密碼學協議來保護隱私，一邊讓普通網頁基礎設施洩露身份。

電子郵件、電話號碼和帳戶恢復

電子郵件和電話號碼很方便，但也是強身份標識。如果驗證方把它們與零知識證明關聯起來，證明就可能成為更大身份画像的一部分。

這並不意味著公民平台永遠不能使用郵件或電話。它意味著這些標識符應盡可能與證明事件隔離，只在真正必要時使用，並受到清晰的資料保留政策約束。

永久標識符

如果同一個永久標識符出現在證明周圍，零知識證明仍然可能被連結。錢包地址、DID、憑證主體 ID、裝置標識符或穩定帳戶 ID，都可能成為關聯抓手。

需要假名性的系統應使用按關係或按場景生成的標識符，而不是通用標識符。預設情況下，使用者不應在互不相關的公民空間之間攜帶同一條軌跡。

時間關聯

即使標識符被隱藏，時間也可能暴露關係。驗證方可能把證明生成的時刻與另一項請求關聯起來，例如登入事件、通知點擊或頁面載入。

設計者應把時間戳視為敏感資料。批次處理、延遲提交、最小化日誌，以及認證和證明展示之間的隔離，都可以降低關聯風險。

錢包、裝置和供應鏈風險

證明本身可能在密碼學上是正確的，但錢包或客戶端仍可能洩露敏感資料。專有錢包可能傳送遙測。被攻破的 SDK 可能洩露屬性。惡意前端可能請求超過使用者理解範圍的資訊。

開源不能神奇地消除這些風險，但閉源會讓風險更難檢查。對高信任的公民系統而言，開源客戶端、可複現建構、獨立審計和最小遙測都應被視為核心基礎設施。

行為推斷

機器學習可以從看似無害的模式中推斷身份。寫作風格、活動時間、裝置行為、位置模式和互動歷史，都可能縮小匿名集合。

這也是隱私不能被簡化為證明的原因。匿名參與還需要產品、審核和資料保留方面的選擇，避免建立不必要的行為檔案。

更好的可信匿名證明架構

保護隱私的憑證流程，應以「驗證方想知道更多不該知道的資訊」為預設假設。

至少，一個使用零知識證明的公民平台應考慮以下原則：

請求滿足公民要求的最不精確證明。
避免把證明展示與可識別帳戶流程混在一起。
除非用例真正需要，不要把電話、郵箱、錢包地址或永久 DID 綁定到證明事件。
讓第三方 Cookie、分析和追蹤器遠離證明流程。
最小化日誌，尤其是 IP 位址、時間戳和請求後設資料。
需要持續參與時，使用特定場景的假名。
讓驗證方前端、證明請求邏輯、錢包整合和 SDK 開源並可審計。
讓使用者能理解證明請求，知道自己正在證明什麼、沒有透露什麼。
防止簽發方回調或其他能讓簽發方知道憑證在哪裡被使用的機制。

目標不只是匿名證明，而是可信匿名：使用者、審計者和公民社會都能檢查平台的隱私承諾是否符合實際行為。

開放挑戰

仍有許多困難工作。

首先，使用者體驗還不夠好。大多數人無法理解憑證 schema、選擇性披露、證明請求、簽發方不可連結性或關聯攻擊。一個安全產品必須解釋隱私屬性，而不是要求使用者成為密碼學家。

第二，憑證生態是碎片化的。BBS+、SD-JWT、行動駕照、護照晶片、Merkle 化憑證和基於 zkVM 的證明都做出不同取捨。公民平台需要互操作性，但不能退回到隱私最弱的共同標準。

第三，抗女巫攻擊和隱私仍然存在張力。更強的唯一性往往要求更強的身份依據。挑戰在於只驗證必要事項，並防止這種驗證變成通用身份圖譜。

第四，防濫用不應重新製造監控。匿名或假名空間仍需要審核、頻率限制和責任機制。這些機制必須被設計成不會悄悄重新識別所有人。

最後，開源是必要但不充分的。發布程式碼有幫助，但使用者還需要可複現建構、獨立審計、清晰治理，以及部署層面的保證：他們檢查的程式碼就是實際執行的程式碼。

結論

零知識證明非常強大。它們讓人們無需透露底層資料就能證明事實，也能阻止簽發方追蹤憑證的使用地點。

但證明並不是整個隱私系統。驗證方仍可能攻擊周邊層：屬性、後設資料、Cookie、電子郵件、電話號碼、永久標識符、時間、錢包、裝置和行為模式。

對公民科技來說，這一區分非常重要。如果數位身份成為公共參與的一部分，它不能變成另一種監視公民的方式。零知識證明可以成為答案的一部分，但只有當它位於更廣泛的架構中：資料最小化、不可連結、開源可審計，以及使用者控制。

實踐上的結論很清楚：使用零知識，但不要止步於此。