客戶端零知識證明：挑戰和解決方案

原文標題：ZKP on the Client-side: Challenges \& Our Solutions

TLDR

在客戶端構建一個良好的零知識證明系統比看起來要困難得多。然而隨著ZKP發展至今，客戶端生成ZKP並進行鏈上驗證已經成為可能。2024將會是客戶端零知識證明系統走向大眾視野的一年。這篇文章將從技術角度講述為什麼客戶端零知識證明如此困難，和OpenID3是如何解決對應的挑戰的。

包含去中心化社交網絡，全鏈遊戲，隱私身份驗證和隱私KYC/AML，新型DeFi應用在內的Web3個賽道，客戶端零知識證明將提供非常重要的基礎設施。

我是一名OpenID3的密碼工程師。OpenID3作為客戶端零知識證明的先驅之一，希望在這篇博客裡簡單聊聊客戶端零知識證明為何如此困難，同時聊聊OpenID3是如何解決這些問題的。

構建零知識證明系統是種什麼樣的體驗？

我們今天所擁有的 零知識證明系統（ZKP）主要服務於擴展以太坊的擴容。發展至今，確實有一些很棒的客戶端應用，但大多基於其他系統的運行，或由簡單電路組成，或不太關心用戶體驗。

當我參加行業活動時，介紹自己是一名 ZKP 工程師時，最常見的反應是我是否為 zkSync 工作，或我們是否正在構建另一個 zkRollup Layer2。一段時間後，就有點煩人了。這有點像說你住在新加坡，人們就開始問他們是否真的有鞭刑。不管怎樣，我只是想大致描述一下這裡的場景：大多數 ZKP 系統並不是為客戶端應用構建的。

為什麼不呢？有幾個主要的考慮因素，在我深入介紹工程師們考慮的重要方向之前，先介紹幾個ZKP的基礎組成。

1. Prover/Verifier 證明者和驗證者：直白來說就是，證明者程序花費大量運算資源證明一些特定程序和對應的輸入，從而使得驗證者程序可以簡單快速的證明證明者是誠實的。對於大多數 ZKP 系統來說，驗證者通常是智能合約。
2. Circuit \& Witness 電路和見證：證明者擁有的信息稱為見證人，定義好的程序成被稱為電路。給定電路和見證就可以生成證明。
3. Public \& Private Witness 公开见证和私有见证：在構建電路的時候，見證默認是私有的，某些情況下一些信息會被標記成公開的。這些公開的信息有助於驗證人驗證電路或者執行智能合約的邏輯。
4. Application \& Aggregation Proof 應用證明和聚合證明：大多數ZKP都需要聚合。將多個應用證明聚合在一起就生成了聚合證明。聚合證明可以讓驗證者批量驗證ZKP，可以節約Gas Fee和減少鏈上信息污染。

現在，在了解了這些基本概念之後，ZKP 工程師通常會考慮以下幾點：

1. Prover Time \& Memory Consumption 證明者時間和內存消耗
2. Verifier Cost: 驗證者成本。
3. Size 大小：文件和鑰匙大小涉及多個種類，包括：
4. Proof Size 證明大小，通常和Gas Fee正相關
5. Executable Size: 打包後程序大小
6. Parameter Size: 某些ZKP系統需要進行可信設置，可信設置文件大小與電路複雜度正相關。
7. Key Size: 鑰匙大小。一些驗證系統的證明者鑰匙會非常巨大。在OpenID3的早期，我們曾經嘗試使用Halo2構建電路，所生成的證明者鑰匙高達3GB。

客戶端 ZKP

zkRollup證明系統和典型的客戶端證明系統，關注的優先級是不同的。同樣，如果不做出妥協，通常很難實現所有優勢。ZKP在客戶端和伺服器端有著本質的區別。一般來說，zkRollup證明系統運行在伺服器端，可以掉配近乎無限的計算資源和超高速網絡。然而在客戶端，運算資源十分有限，用戶網絡極有可能很不穩定，用戶也不會耐心地等待並不斷刷新網頁。

於是：

• 證明者時間和內存消耗是客戶端 ZKP 的第一要務，而在伺服器端則要寬容得多；
• 文件大小。對於我們編寫的某些電路，可信參數可以大到 20MB，對於某些ZKP系統，其生成的WASM可執行文件可以達到幾百MB。我們無法將這些文件發送給客戶，並期望客戶對下載文件的漫長等待有耐心。任何大於3MB的的可執行文件、密鑰、參數都將難以被用戶接受。
• 鏈上驗證成本。驗證 Rollup 的成本可以由海量用戶分擔，但客戶端 ZKP 證明通常需要每一個去用戶承擔成本。
• 延遲。zkRollup不需要對每個塊進行聚合證明計算，但客戶端ZKP需要在系統能夠完成的情況下儘快進行。用戶不會等待幾天才能在鏈上驗證他們的證明，相反，幾分鐘將是用戶可接受時間的極限。

毫無疑問，構建 Rollup 式的 ZKP 系統是一件非常複雜的事情，但是，構建一個功能性的客戶端 ZKP 系統並不是一件容易的事，實際上對系統功能提出了更苛刻的要求。

ZKP 系統的思考

基於以上思考，我們開始了OpenID3的構建。OpenID3是一套基於ZKP的開放協議，用來在鏈上證明用戶的Web2社交賬戶所有權。OpenID3將在客戶端證明用戶的身份憑證，之後將ZKP發布到一個開放的ZKP聚合器網絡並提交上鏈。期間，用戶所有信息不會離開用戶本地，並且可以便宜高效的在鏈上驗證。應用場景包括：

1. 無許可(Permissionless)和去中心化的安全上鏈用戶的Web2身份。
2. 去中心化，自托管的社交登錄錢包。

早期測試版已經在Linea網絡上驗證了超過400,000個身份信息。

簡單來說，我們已經完成了如下成果：

1. 客戶端將下載一個大小約為 2MB 的 WASM 可執行文件；
2. 客戶端將在大約30秒內生成應用證明；
3. 然後，客戶端會將應用程序證明傳遞給通用聚合器之一並放入隊列中。聚合器將定期被觸發。聚合器將花費大量內存和大約3分鐘來聚合證明並將證明傳遞回客戶端。聚合器還將證明的所有客戶端公共輸入註冊到Merkle 樹中，並將樹根公開為聚合證明的公共見證。
4. 聚合器將在鏈上提交聚合證明，智能合約可以驗證該證明並記錄大約 250,000 Gas 的 Merkle Tree 根。 （等同於從 ETH 到某些 ERC-20 代幣的 Uniswap調用的價格）。目前一份證明包含32-64個用戶證明，驗證的Gas Fee將被這些用戶平攤，從而每個用戶為ZKP驗證付出的Gas Fee基本和一次鏈上的ETH轉帳相當。
5. 用戶可以提交"claim"調用並進行Merkle證明，以使用哈希消息來識別自己的身份，並將被證明ZKP的鏈接到他們的地址。

除了鏈上地址和由用戶提交的身份哈希之外，聚合器、智能合約和我們對用戶身份一無所知。

如何實現以及如何改進

這部分可能有點技術性，需要一些ZKP背景知識。

1. 在客戶端，我們選擇使用Plonky2，這是一個FRI+Plonk使用Goldilock的ZKP系統。它不需要可信設置、快速的證明時間和合理的內存消耗。我們精簡了電路，以滿足驗證驗證身份的最低要求, 編譯後的 WASM blob 大約為 3MB。
2. 在聚合器端，我們首先將Plonky2證明聚合成一個"包裝的"Plonky2 證明，該證明能夠將大量Plonky2證明聚合成一個，驗證正確的電路結構（即用戶正在按照我們的預期執行確切的電路，將公共見證壓縮成Merkle樹以節省空間等）。
3. 在Plonky2 聚合之後，我們在Gnark內部運行 Plonky2 驗證器，它將證明和驗證器鑰匙轉換為鏈上快速可驗證的形式。Gnark 聚合是主要的時間消耗者，大約需要 2 分半鐘。
4. 最後，通過聚合證明，用戶可以使用通用的Plonky2+Gnark驗證器合約，以低廉的成本驗證自己，仅需 211,000 個 Gas，加上鏈上調用存儲的overhead，驗證成本得以被控制在250，000Gas以下。

目前，OpenID3的ZKP端正在進行兩項工作：

• 我們希望通過 GPU 加速等黑魔法來加快 Gnark 聚合時間，目標是不到半分鐘；
• 我們正在對樹狀依賴進行搖動，以進一步最小化可執行文件的大小，最好是低於1MB。

寫在最後

客戶端ZKP是一個探索者太少的領域，我們希望與任何其他團隊合作來標準化我們所採取的流程。

• 框架、DSL 可以圍繞輕鬆組成的 Plonky2 電路進行構建，以進行應用證明。
• 我們還沒有為許多流程引入折疊優化，我們期望通過聚合折疊來實現巨大的性能提升。
• 可以構建聚合器服務或通用鏈上驗證服務，作為 ZKP 未來的關鍵基礎設施，為更大的社區帶來安全性、去中心化和出色的開發者體驗。