本文通過介紹構建 zk 身份系統的四個組件，分析了構建 zk 身份系統原型需要哪些技術
原文：ZK Identity: Why and How (Part 2)（0xparc.org）
作者： gubsheep
翻譯：雙花 (@doublespending)
校對： EthereumCN
是解釋為什麼密碼學的新進展對數字身份原語很重要的系列文章。第一篇文章解釋了 “為什麼”；本文會解釋 “怎麼做”。
在上篇文章，我們討論了為什麼新的加密工具（如 zkSNARKs）對構建下一代數字身份基礎設施至關重要。在本文中，我們將深入了解構建基於 ZK 的身份系統原型要哪些技術？
ZK 身份項目的規模比任何單個組織都要大得多。設定標準、構建基礎設施、迭代身份原語和應用設計的問題將逐漸浮現，而且需要不同利益相關方和各領域專家的貢獻。
鑑於 ZK 身份機制對許多人有著潛在影響並嚴重依賴公共物品（public goods）—— 開源基礎設施、工具、標準和協作，由一個有機、社區驅動的 “生態系統” 自下而上推動而非由一個公司自上而下推動尤為重要；同時，需要特別關注發展的可持續性及激勵的設計。
單一公司在這樣一個動態的生態中取得成功的可能性也越來越小，因為技術棧中在各層次上獨立發展的技術正在快速地變化。相反，我們需要培養和協作出一個由模塊式、敏捷，半獨立，擁有相同願景的團隊組成的生態系統。
0xPARC ZK 身份工作組致力於通用 ZKID ，並邀請積極思考此問題的其他人加入我們，相互切磋。
ZK 身份的組件
ZK 身份工具必須使得數字系統中的參與者能夠對身份和信譽進行聲明。具體來說，這些聲明可以歸結為有關零知識領域的密碼運算（如簽名驗證、密鑰生成、哈希和加密）執行的數學命題。我們可以將這些 “組件” 組合在一起，為更複雜的聲明構建 ZKP ：一個簡單示例可以參閱我們的文章《ZK 群簽名》 (https://0xparc.org/blog/zk-group-sigs)。
一些運算和密碼方案使用 zkSNARKs 實現會比其他技術更加高效。從長遠來看，SNARK 友好的密碼標準將會被目前尚未存在的新型身份提供商所採用。
例如，使用 SNARK 友好密碼體系的公私鑰簽名方案的區塊鏈（或更具表現力的系統，如 [賬戶抽象](https://eips.ethereum.org/EIPS/eip-2938))。
但為了原型驗證並在短期發揮作用，我們的工具需要與現有的加密身份系統進行乾淨的集成—— 例如以太坊目前的 ECDSA 簽名方案，或在其他場景下與配對友好型橢圓曲線相結合的新近加密標準。
我們認為為 ZK 身份應用構建實用工具棧需要在四個方面取得重大進展：ZK 應用的設計模式、加密原語的 ZK 電路實現、電路安全工具以及開發者工具和基礎設施。我們將在後文分別概述這四個方面。
ZK 應用和設計模式
首先，我們的工作成果應該觸及終端用戶，並使得有影響力的生產級應用成為可能。在開發 ZK 工具和組件的同時，我們必須找出使用和組合它們的最佳方法。以下是幾個開放性問題：
• 身份的正確抽像到底是什麼？
它是以太坊地址、以太坊地址集合、多簽、智能合約錢包、ENS 名稱、不同加密方案中的密鑰對、秘密生物特徵、一組證明、還是 [高層級構造](https://eips.ethereum.org/EIPS/eip-2938) 或者是一些完全不同的東西？
•人們所關心的作出的通用身份聲明是什麼？
上述的所有工作為我們提供了一種作出關於身份的可信聲明的語言；現在，我們必須學會如何用這種語言進行表述。例如，直接引用和操作鏈上哈希數據的聲明是否有意義，或者若大多數聲明只是由半可信第三方作出的有效認證的簡單證明，是否會更簡單？在 ZK 證明中作出引用以太坊歷史狀態的聲明是否可行？如果可行，證明工具應該能便捷地獲取哪類歷史聲明？
• 未來 ZK 錢包和身份提供商應該提供哪些工具以及遵循哪些標準？
例如， Metamask 或硬件錢包目前支持用私鑰進行數字簽名，一般建議用戶不要直接操作私鑰。然而，在 SNARK 中進行 ECDSA 簽名驗證要比公鑰生成昂貴得多—— 這意味著希望對其 ETH 地址進行 ZK 證明的用戶必須在慢得多的證明時間（通過有效簽名認證的證明的方式）和較低的安全性（通過將其私鑰明文從錢包複製到 ZK 證明生成程序上的方式）之間進行選擇。
如果錢包軟件最終為 ZK 證明的生成提供原生支持，那麼這個問題將會被部分解決，我們目前正與 Metamask Snaps 團隊進行試驗。
• 支持 ZK 身份的應用需要遵循哪些接口呢？
鏈上和鏈下的應用程序在設計時應該考慮到 ZK 身份系統。例如，有意使用 ZK 身份系統的 NFT 封閉社區可能會在 NFT 智能合約中存儲 token 的密碼累加器及 token 所有者數據，以便用戶更容易生成關於社區成員身份的聲明。有意提供成員證明的群組標準需要被制定出來。
• 誰（或什麼設備和環境）能夠生成 ZK 證明？
落地應用生成證明的位置差異很大，取決於特定 ZK 證明是否能夠在硬件錢包、移動設備、瀏覽器、消費者台式計算機上生成，或者僅能在專用證明服務器上生成。
解答這些問題的最好辦法就是啟動開發！我們希望一個強大的開發者社區在未來幾年內開始形成，並用各種不同的方法來開發應用。
實際上，我們現今能夠利用現有基礎設施來開發幾個 ZK 身份應用。這是一項高附加值的工作，除了交付有意義的應用外，這些項目還將為工具和基礎設施的開發提供信息指引。
以下是一些 ZK 身份的初步生產級應用候選項：
• 隱私空投。許多 DeFi 應用的常見策略是在鏈上發布用戶地址的 Merkle 根，並允許用戶用發佈在樹上的地址調用一個函數來申請空投。Stealthdrop(https://github.com/nalinbhardwaj/stealthdrop) 是 ETHUni 和 0xPARC 社區的一個項目，該項目為其添加了一個隱私層，用戶只需證明擁有與樹中 ETH 地址相對應的私鑰即可申請空投（用空值檢查以防止重複申請）。
• 鏈上快照投票聚合。現今，許多 “DAO” 完全使用鏈下投票機制—— 用戶對投票簽名並將這些簽名發送到中心化服務提供商（即快照）進行統計。這帶來了兩個問題：
第一，投票可能會被中心化機構審查，前面的投票數據可能會丟失或者變得不可用/不可審計。
第二，投票是公開進行的，使得投票系統容易受到共謀攻擊。我們可以使用 ZK 構造進行簽名驗證，將投票結果 “卷疊” 為投票者簽名的單個 ZK 證明，該證明可以無信任地生成並在鏈上提交。部分分散中心化機構權力的適中構造 (即將權力分配給更廣泛的證明人網絡，他們去發布代幣持有者快照的 Merkle 根) 也是可以換取可擴展性的。
• 匿名但可信的證明。這些身份工具可以用於證明你群組成員的身份，而無需透露確切你的身份。
例如，證明你對黑暗森林星球的所有權，並在不透露你身份的情況下加入 NFT 封閉社區；匿名但以大 V 的身份發布帖子，在不透露你賬戶的情況下證明你在推特上至少有 100 多萬粉絲；或者證明你是一個立法機構的成員，並在即將到來的投票中匿名附議。裡面某些應用在我們的文章《ZK 群簽名》中得到更為詳細的討論。
ZK 密碼身份原語的 ZK 電路
技術棧中更進一步，我們需要核心密碼原語的 ZK 電路及背後數學運算的高效，經審計的實現。下面是一些關鍵操作的示例，粗略地按依賴關係進行排序。
• 非原生的有限域算法：zkSNARK 算法基於素數域。例如，snarkjs 的所有值默認模一個 254 位的素數（BabyJubJub prime(https://iden3-docs.readthedocs.io/en/latest/iden3_repos/research/publications/zkproof-standards-workshop-2/baby-jubjub/baby-jubjub.html)）。
然而，密碼操作要求我們對潛在的更大數字進行操作——例如，secp256k1 操作要求我們獲取兩個 256 位數字模第三個 256 位數字結果的乘積。這些電路中涉及的最為昂貴的操作是范圍檢查，而一個約束優化的策略是更加小心地確定何時我們確實需要進行範圍檢查。
• SNARK 友好的哈希函數：哈希函數在用戶必須作出密碼承諾的應用中很有用。在哈希函數無需與現有標準集成的方案中，我們可以選擇設計和實現專門為 SNARK 證明而設的高效哈希函數。這樣的兩個函數包括 MiMC(https://byt3bit.github.io/primesym/mimc/) 和 Poseidon（https://www.poseidon-hash.info/)。
• S NARK 不友好但標準化的哈希函數：在許多應用中，為了兼容現有的系統，我們必須使用 SNARK 不友好的哈希函數（如 SHA256 或 keccak）。
例如，為了證明私鑰與 ETH 地址相對應，我們需要一個 keccak(https://github.com/vocdoni/keccak256-circom) 的 ZK 電路實現。我們還要下很大功夫來實現，優化和審計這些哈希函數。
• 橢圓曲線點加：橢圓曲線密碼學是建立在橢圓曲線群之上的；因此，我們必須為橢圓曲線群定律（點加）構建 ZK 實現。這些運算是昂貴的，而且是 ZK 身份系統的一個性能瓶頸；巧妙地運用 PLONK 以及更好地實現大數算法可能會有助於性能提升。
• ECDSA 密鑰生成和簽名驗證：用於 ECDSA 密鑰生成和簽名檢驗的 ZK 電路的實現將允許我們構建一種與現有基於 ECDSA 的身份系統（如以太坊）兼容的身份聲明語言。構建這些原語需要我們高效地結合橢圓曲線點加和哈希函數的實現 (https://github.com/0xPARC/circom-secp256k1/blob/master/circuits/eth_addr.circom)。
• 橢圓曲線配對：配對友好的橢圓曲線使我們能夠使用雙線性映射—— 支持多項式承諾、BLS 聚合簽名驗證、遞歸 SNARK 驗證、Verkle 樹等。橢圓曲線配對 ZK 電路的高效實現將解鎖大量新型密碼運算。
• 密碼累加器嵌入檢查：一旦我們有用於多項式承諾驗證的 ZK 電路，Verkle 樹嵌入證明就可以在 SNARK 中驗證。Merkle 樹嵌入證明目前是可驗證的，並適用於使用 SNARK 友好哈希函數構建的樹。MPT 嵌入證明使我們能夠在 SNARK 中驗證輕客戶端證明。
在所有這些場景下，驗證累加器嵌入證明使得 SNARK 能夠訪問被捲疊為一個簡潔全局狀態承諾（根）的數據——如果您將要訪問的數據、系統狀態根，以及嵌入證明作為 SNARK 的輸入，那麼驗證者只需驗證你的簡潔證明並檢查根是否正確，而無需檢查整個系統狀態。
• 遞歸 SNARK 驗證：在 zkSNARK 內實現橢圓曲線配對和/或多項式承諾驗證，令遞歸 SNARK 成為可能。這開拓了身份聲明中可編程性和復雜性的一個全新領域。
所有的這些電路將先由 R1CS 編寫（近期考慮 groth16 證明系統），並在不久的將來優化為基於 PLONK 的證明系統。
開發者工具和基礎設施
ZK 電路開發工具是一個重要的課題。目前，ZK 開發者需要相對較高的數學背景及技術經驗，他們必須在相對底層的開發環境進行編碼，並依賴手工或特定腳本來管理文件以及在開發流水線（設計-> 產品）上傳遞電路。此外，現有的開發者工具分散在多個研發團隊、rollup 企業等組織中。
這裡需要特別注意的是，一個健壯的工具棧對於 PLONK 而言尤為重要。PLONK 去除了對每個電路進行可信初始化的需要，大大加快了某些電路編譯和證明生成的過程（歸功於自定義約束），並為遞歸 SNARK 驗證鋪平了道路。
然而，相比 Groth16 ，PLONK 工具目前仍處於開發的初期階段，其驗證者優化程度偏低，高級協議特性尚未在一些系統中實現。此外，在 IR 標準和自定制約束語言設計上仍有很多工作要做。AZTEC、Electric Coin Co、ZK-Garage 等小組正努力地開發這些工具。
除了 PLONK 工具鏈外，下面是 ZK 開發者工具中的一些活躍領域：
• 更高層級的 DS L。當前用於編寫 SNARK 的語言非常底層，需要開發者手工編寫約束。我們對更容易開發，甚至集成了約束優化的生產級高層級 DSL（一個來自 0xPARC 社區成員的原型）感興趣。
另外，值得具備的功能包括用戶定義數據類型/註解以及更好的見證生成系統。更進一步，支持電路測試、驗證或靜態分析自動化的 DSL 將會增加我們對所編寫代碼的信心。
• 更智能的開發環境。編寫、分析和測試電路是一個艱難的過程。開發過程中的語法高亮、編譯時錯誤檢查，使用 AST/witness 分析、註解（即將電路模板標記為 “安全” 或 “不安全”，標記無約束信號）類似 IntelliSense 的工具，以及 shell / REPL 環境能夠快速提升迭代速度。使用了 Kevin Kwok 的 ZKREPL 項目（包含上述若干特徵），ZK 學習小組的效率得到了大大地提升。
• 構建、測試和部署工具；自動化和流水線管理。ZK 開發者目前必須手管理 ptau 文件、密鑰文件、構建配置、構建文件以及發版流程。snarkjs 教程 (https://github.com/iden3/snarkjs) 目前列出了開發者創建和驗證 zkSNARK 必須完成的 26 個步驟，涉及對 20 多個文件的手動操作。
關於如何以可訪問及可審計的方式發布協議參數，目前還沒有被廣泛接受的最佳實踐。開發者必須針對不同的環境手動維護不同版本的電路（即在測試期間關閉一些約束）。ProjectSophon 的 hardhat-circom(https://github.com/projectsophon/hardhat-circom) 和 Weijie Koh 的 circom-helper(https://www.npmjs.com/package/circom-helper) 等工具是大幅簡化工流的第一大步，但仍有許多工作要做。
• 中間層表示的通用標準。不同的團隊使用不同的語言和工具來編寫 ZK 電路：circom 、arkworks、libsnark 等。理想情況下，不同工具鏈編寫的電路應該編譯為通用 IR ，以便生成證明、驗證證明、審計協議設置以及其他通用任務可以與工具鏈無關。
對於 Groth16 來說，IR 取決於普遍認可的密碼參數和 R1CS 表示的一個標準集。對於 PLONK 來說，這個問題有點複雜，因為庫開發者需要弄清楚如何表示自定義約束等等。
作為鑽研該領域的一個例子，Dark Forest 第三方客戶端的開發激發了 Kobi Gurkan 和 gakonst 開發 ark-cirom 的動機，其連接 arkworks 和 circom 的生態。
• 易用且更高效的編譯器和證明器。緩慢的密鑰編譯和證明會延緩開發和測試。優化編譯和證明，並開發這些流程開箱即用的庫（即，在大型服務器上部署遠程驗證器應當簡便！）將節省開發者的時間。ZPrize 是一項旨在加快該工作推進的行業倡議。
• （PLONK 前）共享受信任初始化基礎設施。由於信任初始化協調的困難，目前很難發布生產級 zkSNARK 應用。Zcash、 AZTEC 協議、Tornado 以及 Semaphore 都必須編寫定制的受信任初始化基礎設施。有一些構建可重用的受信任初始化工具的嘗試，但運行這些儀式仍需耗費大量人力。
請注意，長遠來看，由於我們會切換到無需每個電路進行受信任初始化的協議，這可能不會是個問題。
• （PLONK 後）SNARK 遞歸工具。支持遞歸驗證的 SNARK 使我們能夠構建 “可編程” SNARK ，其中 SNARK 代碼可以通過插入其他 SNARK 子模塊的驗證密鑰來 “即時” 修改。
此外，遞歸 SNARK 還允許開發者並行化證明生成。真正地支持這一功能是一個難題，大概會在未來幾年內解決......
審計和驗證
上面列出電路十分複雜而且難以手工驗證。巧妙的約束優化實際上加重了這個問題—深度優化的電路難以理解，如果你正在處理棘手的工作，那麼在實現過程中很容易忽略某個約束。此外，由於 ZK 應用程序的性質，無法判斷 ZK 電路中的 bug 是否已被外部所利用。
編寫讓你確信零知識證明滿足完整性（completeness）的測試相當容易：證明你可以為見證者正確地由輸入生成見證和見證的有效證明。確信零知識證明滿足可靠性（soundness）更加困難。
為此，你必須驗證給定輸入存在著滿足 SNARK 約束系統的見證—惡意證明者無法用一個錯誤的見證（生成一個並不滿足約束的有效證明）瞞天過海。相比可靠性證明更難是，證明電路與規範間等價性，即形式化驗證。
目前，大多數在生產中使用 ZK 電路的團隊採用的方法是委託人工審計，儘管這些審計的質量參差不齊，有能力進行審計的人非常少。我們可以相當肯定像 Tornado.Cash 電路 (總計僅有 100 行 circom 代碼）這樣的應用大概是安全的。
然而，我們的 groth16 的 ECDSA 原型實現依賴於數千行 circom 代碼，有著規模為數十萬或數百萬個約束的電路。更複雜的原語將更難驗證，而 PLONK 的自定義約束將增加額外的複雜度。
我們為 ZK 應用程序安全空間提出了幾種方法。未來，我們將發布一篇博文，對我們所了解的該領域的當前方法進行更深入的概述。
• 建立一個評審員社區。團隊通常難以找到擁有 ZK 應用開發經驗的專家來評審他們的電路和代碼。我們可以鼓勵現有的專注 ZK 的團隊，如 rollup 公司的工程師及應用開發者，來 “有償提供” 評審，同時我們還可以開始一起培訓審計員。
• 建立電路開發和評審的最佳實踐。隨著生態的成熟，我們希望開髮用於構建、註解、歸檔和評審 ZK 電路的最佳實踐。實現該目標的手段各不相同，自然語言規範或形式規範都有助於使電路更為清晰。列舉常見的 bug 和錯誤（並開發一些捕捉它們的基本工具）也會對工程師和評審員有幫助。
• 電路原語正確性的手工證明。對於如哈希函數或 ECDSA 電路的重要原語，可以手寫此類原語的正確性證明，這些證明可被證明檢查者檢查。其他的電路開發者將能夠更有把握地使用這些原語。
• 自動見證唯一性驗證。Ecne 是首個 R1CS 見證唯一性的自動化驗證器。該項目使我們能夠驗證 ZK 電路是否有任何缺失的約束，這是在我們 ZK 系統中建立信心的一個重要步驟。我們希望支持和鼓勵更多類似的工作。
• 基於求解器的形式驗證方法。一些團隊正在探索證明 ZK 電路與形式規範等效的自動化工具。這方面的工作還需要我們開發出一套通用的基準測試，以及一種用於（部分或全部）明確描述 ZK 電路的語言。
免責聲明：作為區塊鏈信息平台，本站所發布文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。本文內容僅用於信息分享，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
