TPS:DAOrayaki：實現可用ZK身份需要在四方面取得重大進展

原文作者:?gubsheep

原文標題:?ZKIdentity:WhyandHow(Part2)

關于為什么密碼學的新進展可能對數字身份基元很重要。上一篇DAOrayaki介紹了“DAOrayaki｜為什么Web3需要ZK身份？”；這篇文章介紹“如何實現”。

在上一篇文章中，我們討論了為什么新的加密工具，如zkSNARK，將對構建下一代數字身份基礎設施至關重要。在這篇文章中，我們將深入到細節中——為了建立基于ZK的概念驗證的身份系統，需要進行哪些技術工作？

ZK身份的“大項目”比任何一個組織都要大得多。制定標準、建立基礎設施、迭代身份基元和應用設計問題將逐漸發生，并需要各種不同的利益相關者和專業領域的投入。鑒于ZK身份機制有可能影響到許多人，并且在很大程度上依賴于公共物品——開源基礎設施、工具化、標準、協調——因此，重要的是，這項工作要從一個有機的、社區驅動的“生態系統”中自下而上地產生，而不是從一個公司自上而下地產生，并且要特別注意可持續發展和激勵設計。

在這樣一個動態的生態系統中，一個孤立的公司也越來越不可能成功，因為在堆棧的各個層面獨立開發的技術正在迅速變化。相反，我們將需要培養和協調一個由模塊化、快速發展和半獨立的團隊組成的生態系統，共享一個共同的整體愿景。

ZK身份識別工具必須使數字系統的參與者能夠提出關于身份和名譽的聲明。具體來說，在零知識中，這些聲明可以歸結為執行簽名驗證、密鑰生成、散列和加密等加密操作的數學陳述。我們可以把這些“構件”組合在一起，為更復雜的要求建立零知識證明：舉個栗子，請看我們關于ZK群簽名的文章。

一些操作和加密方案可以在zkSNARK中比其他方案更有效地實現。從長遠來看，SNARK友好的加密標準可能會被今天還不存在的新身份提供者所采用——例如，基于SNARK友好的加密技術的公鑰/私鑰簽名方案的區塊鏈。但是，為了證明概念并在短期內發揮作用，我們的工具需要與現有的加密身份系統很好地整合——例如，以太坊目前的ECDSA簽名方案，或者，圍繞配對友好的橢圓曲線形成的更多最新加密標準。

我們相信，為ZK身份應用建立一個可用的工具棧需要在四個方面取得重大進展。ZK應用設計模式，實現ZK電路的加密基元，電路安全工具，以及開發者工具和基礎設施。我們在下面總結了每個領域。

首先，我們工作的產出應該是觸及終端用戶并賦能有影響力的生產級應用。在開發ZK工具和構件的同時，我們必須弄清楚使用和組成它們的最佳方式。這里有幾個開放的問題：

身份的正確抽象含義是什么？它是一個以太坊地址，一個以太坊地址的集合，一個多簽，一個智能合約錢包，一個ENS名稱，一個不同的加密方案中的密鑰對，一個秘密的生物識別，一組證明，一種更高層次的構建，或是完全不同的東西？

QiDao團隊將Stablecoin MAI添加至Polygon網絡Aave V3的提案已獲通過:8月29日消息，Polygon 原生 Stablecoin 協議 QiDao Protocol 團隊于 Aave 社區發起將 QiDao 推出的 Stablecoin MAI 添加到 Polygon 上的 Aave V3 的提案已獲通過，該提案建議風險參數設置為 75% 的貸款利率、80% 的清算門檻、10% 的儲備系數、每條鏈 200 萬美元的初始債務上限。[2022/8/29 12:54:58]

哪些是人們關心的常見身份聲明？所有上述工作給了我們一種語言，用于提出關于身份的可信的聲明；現在，我們必須學習如何真正用這種語言說話。例如，直接引用和操作鏈上存儲的散列數據的聲明是否有用，或者如果大多數聲明只是由半可信的第三方提供的有效證明，是否會更容易？在ZK證明中引用歷史上的以太坊狀態的聲明是否實用——如果是這樣，證明工具應該使哪類歷史聲明容易獲得？

未來的ZK錢包和身份供應商應該有哪些工具和標準？例如，Metamask或硬件錢包目前支持用私鑰進行數字簽名，一般建議私鑰不應該由用戶直接操弄。然而，ECDSA簽名驗證在SNARK中的執行成本比公鑰生成要高得多——這意味著希望對其以太坊地址進行ZK證明的用戶將不得不在更慢的證明時間和更低的安全性之間做出選擇。如果錢包軟件最終提供對ZK證明生成的本地支持，這個問題可以得到部分解決，我們目前正在與MetamaskSnaps團隊進行實驗。

支持ZK身份的應用程序需要遵照哪些接口？鏈上和鏈下的應用程序將需要在設計時考慮到ZK身份系統。例如，希望使用ZK身份系統的NFT門卡社區可能希望在NFT智能合約中也存儲一個代幣和代幣所有者數據的加密累加器，以便用戶更容易生成關于社區成員身份的聲明。我們需要為希望進行成員資格驗證的團體開發標準。

誰可以生成ZK證明？可行的應用各不相同，這取決于某些ZK證明是否可以在硬件錢包、移動設備、瀏覽器、消費者臺式電腦上生成，或者只在專用證明服務器上生成。

回答這些問題的最好方法就是開始建設！我們希望在未來幾年內開始形成一個強大的開發者社區，用各種不同的方法來構建應用程序。

事實上，一些ZK-Identity應用程序可以在今天用現有的基礎設施狀態建立。這是很有意義的工作——除了提供有用的應用，這些項目還將為工具和基礎設施的發展提供參考。以下是一些ZK身份認證的初步生產應用的候選項目。

隱私空投。許多DeFi應用的一個常見策略是在鏈上發布用戶地址的Merkle樹根，并允許用戶通過調用樹上發布的地址的函數來申請空投。Stealthdrop是來自ETHUni和0xPARC社區的一個項目，它在此基礎上增加了一個隱私層，允許用戶從任何地址領取空投，只需證明他們擁有與樹上的以太坊地址相對應的某個私鑰的證據。

Busy為B2C/C2C行業提供DAO解決方案，創造一個公平的全球市場:4月29日17:00，Busy CTO Robert Michalek做客MXC抹茶社區并分享了DAO 平臺相關內容。

Robert Michalek 表示：Busy旨在將服務與去中心化金融聯系起來。目前，Busy的階段性產品是自由職業領域，自由職業者的中心化解決方案正面臨高收費等諸多問題。而區塊鏈能夠以去中心化的方式緩解問題，用戶將成為生態系統的一部分，并將被納入未來的發展中。Busy能為個人自由職業者提供解決方案，創造一個公平的全球市場，未來也會有更多的 DAO 平臺建立在 Busy 引擎上。

據資料顯示，Busy DAO 是一個基于區塊鏈技術、DeFi、Staking以及NFT等元素的B2C/C2C行業解決方案。[2021/4/29 21:11:21]

鏈上快照投票匯總。今天，許多“DAO”完全使用鏈下投票機制，用戶簽署投票并將這些簽名發送到中央服務提供商進行統計。這帶來了兩個問題：首先，投票可能被中心機構審查，過去的投票數據可能會丟失或不可用/不可審計。第二，投票是公開進行的，使投票系統容易受到共謀的影響。我們可以使用簽名驗證的ZK結構，將投票結果“卷起來”，形成一個單一的選民簽名的ZK證明，可以無需信任地生成和提交上鏈。如果犧牲一些可擴展性，也可以將權力從中心機構部分分配給中間結構。

匿名但可信的證明。這些身份證明工具可用于證明在一個群體中的成員身份，而不透露你的確切身份——例如，證明黑暗森林星球的所有權，并加入一個NFT門卡社區，而不透露你的身份；作為一個匿名但受歡迎的Twitter用戶發一個帖子，證明你有至少100萬以上的Twitter粉絲，而不透露你的賬戶；或證明你是一個立法機構的成員，在即將進行的投票中匿名示意共識。其中一些應用在我們的ZK群簽名文章里有更多討論。

在堆棧中再深入一層，我們需要高效的、經過審計的ZK電路的實現，用于核心密碼基元和它們的數學運算。下面是一些關鍵操作的舉例，按非常粗略的依賴性從上往下排序。

非原生域運算：zkSNARK的運算是在素數域中進行的——例如，snarkjs默認的所有信號都是以254位的BabyJubJub素數為模。然而，加密操作要求我們對可能大得多的數字進行操作——例如，secp256k1操作要求我們對兩個256位數字的乘積取模于第三個256位數字。這些電路中涉及的最昂貴的操作是范圍檢查，約束優化的一個策略是更加謹慎地確定我們何時需要精確地執行范圍檢查。

適合SNARK的散列函數：散列函數在用戶必須做出加密承諾的應用中非常有用。在散列函數不需要與現有標準集成的方案中，我們可以選擇設計和實現專門為在SNARK證明中有效而設計的散列函數。兩個這樣的函數包括MiMC和Poseidon。

MakerDAO發起每月MIP等治理投票:據官方博客消息，治理促進者已代表MakerDAO風險小組將一項治理投票納入投票系統。內容包括：1.每月MIP治理投票；2.將YFI-A添加到清算2.0框架中；3. 多項Community Greenlight投票，包括詢問域團隊是否應優先考慮將以下資產包含在Maker協議中，包括MCO2、rETH、1INCH、bBADGER、SLP-DAI-USDC、UNI-V2-DAI-PAX以及UNI-V2-GUSD-DAI。[2021/4/20 20:38:00]

對SNARK不友好但標準化的散列函數：在許多應用中，為了與現有系統兼容，我們必須使用對SNARK不友好的散列函數。例如，為了證明一個以太坊地址所對應的私鑰的知識，我們需要一個ZK電路來實現keccak。我們需要做大量工作，以實現、優化和審計這些散列函數。

橢圓曲線加點：橢圓曲線密碼學是建立在橢圓曲線群上的；因此，我們必須為橢圓曲線群法則建立ZK實現。這些操作很昂貴，這是ZK身份系統的一個性能瓶頸；巧妙地使用PLONK和更好地實現BigNum運算可能有助于提高性能。

ECDSA密鑰生成和簽名驗證：用于ECDSA密鑰生成和簽名驗證的ZK電路實現將使我們能夠建立一種與現有基于ECDSA的身份系統兼容的身份聲明語言。構建這些基元需要我們以有效的方式將橢圓曲線點加法和散列函數合并實施。

橢圓曲線配對：適合配對的橢圓曲線使我們能夠獲得雙線性映射，實現多項式承諾、BLS聚合簽名驗證、遞歸SNARK驗證、VerkleTrees等等。橢圓曲線配對的ZK電路的高效實現將實現大量新的加密操作。

加密累加器包含檢查：一旦我們有了用于多項式承諾驗證的ZK電路，Verkle樹包含證明就可以在SNARK中得到驗證。Merkle樹包含證明今天是可以驗證的，而且對于用SNARK友好的散列函數構建的樹來說是實用的。MPT包含證明使我們能夠在SNARK中驗證輕型客戶證明。在所有這些情況下，累加器包含證明驗證允許SNARK訪問被rollup進全局系統狀態的簡潔承諾的數據，如果你提供你要訪問的數據、系統狀態根和包含證明作為SNARK的輸入，那么驗證者只需要驗證你的簡潔證明并檢查根是否正確，而不是全部系統狀態。

遞歸SNARK驗證：遞歸SNARK是通過在zkSNARK內部實施橢圓曲線配對和/或多項式承諾驗證而實現的。這開啟了身份聲明中可編程性和復雜性的一個新維度。

所有這些的電路都可以首先為R1CS編寫，并在不久的將來為基于PLONK的證明系統進一步優化。

ZK電路工程的開發工具化是一個重要的話題。目前，ZK開發人員需要相對較高的數學背景和技術水平，他們必須在相對較底層的開發環境中進行編寫，依靠人工或臨時腳本來管理文件，并將電路通過開發管道從設計轉化為生產。此外，已經完成的開發工具化的工作分散在多個研發團隊、rollup公司等。

MakerDAO發起是否應優先考慮在Maker協議包含某些資產等治理投票:金色財經報道，據官方博客消息，MakerDAO治理促進者已代表MakerDAO風險小組將一項治理投票納入投票系統。投票內容如下：1. 詢問域團隊是否應優先考慮將以下資產包含在Maker協議中，包括SNX、sUSD、aAAVE、aWETH等；2.增加ETH-A的最大債務上限；3.增加WBTC-A的最大債務上限；4.增加ETH-B Vault類型的Dust參數；5.增加大多數Vault類型的Dust參數；6. 每月MIP治理投票；7.Optimism DAI橋。[2021/3/16 18:47:24]

這里要特別指出的是，專門針對PLONK的強大工具棧的重要性。PLONK消除了對每個電路做可信設置這一步驟，由于自定義約束條件，大大加快了某些電路的編譯和證明生成，并為遞歸SNARK驗證鋪平了道路。然而，PLONK的工具化目前處于比Groth16工具化更早的發展階段，因為證明器的優化程度要低得多，對高級協議功能的支持還沒有在某些系統中實現。此外，在IR的標準和定制約束語言的設計方面還有很多工作要做。像AZTEC、ElectricCoinCo、iden3、ZK-Garage等團體都在努力建設這些工具。

除了PLONK工具鏈之外，以下是ZK開發工具化的幾個活躍的工作領域。

更高級的領域特定語言。目前用于編寫SNARK的語言是非常低級的，需要開發者手動編寫約束條件。我們對生產級的高級DSL感興趣，它們更容易開發），甚至可以智能地執行約束優化。額外的好處包括用戶定義的數據類型/注釋，以及更好的證人生成系統。再往下看，能夠實現測試、驗證或電路靜態分析自動化的DSL可能會增加我們對自己編寫的代碼的信心。

更智能的開發環境。編寫、分析和測試電路是一個困難的過程。語法高亮，在開發過程中檢測編譯時的錯誤，類似IntelliSense的工具使用的包括AST/見證分析、注釋，以及shell/REPL環境的組合，可能會迅速提高迭代速度。ZK學習小組的參與者被KevinKwok的ZKREPL項目大大加快了速度，該項目包含了以上描述的一些功能。

構建、測試和部署工具；自動化和管道管理。目前，ZK的開發者必須手動管理pau文件、key文件、構建配置、構建文件和發布分發過程。snarkjs教程目前列出了開發人員必須執行的26個步驟，以創建和驗證一個zkSNARK，涉及對20多個文件的手動操作。對于如何以可訪問和可審計的方式發布協議參數，還沒有被廣泛接受的最佳實踐。必須為不同的環境手動維護不同版本的電路。像ProjectSophon的hardhat-circom和WeijieKoh的circom-helper這樣的工具是偉大的第一步，有助于大幅簡化工作流程，但還有很多工作要做。

MakerDAO提高USDC與DAI互換上限至10億美金:MakerDAO宣布通過執行投票，提高穩定幣USDC與DAI互換模塊額度上限到10億美金，同時暫停抵押USDC借DAI窗口。[2021/3/5 18:17:47]

中間表征的共同標準。不同的團隊使用不同的語言和工具來編寫ZK電路：circom,arkworks,libsnark等等。用不同的工具鏈編寫的電路最好能編譯成一個共同的中間表征，這樣，生成證明、驗證證明、審計協議設置和其他常見的任務就可以與工具鏈無關了。對于Groth16來說，一個IR取決于一套標準的商定的加密參數和R1CS表征。對于PLONK來說，這個問題要復雜一些，因為庫的開發者需要弄清楚如何表示自定義的約束等等。作為工作在這個問題領域的一個例子，黑暗森林第三方客戶端的開發促使KobiGurkan和gakonst編寫了ark-circom，將arkworks和circom的生態系統連接了起來。

更容易使用和更有效的編譯器和證明器。緩慢的關鍵編譯和證明拖慢了開發和測試。優化編譯和證明，并使這些過程的庫易于開箱即用將節省開發人員的時間。ZPrize是一個旨在加速這項工作和更多工作的行業倡議。

共享的可信設置基礎設施。生產級的zkSNARK應用程序現在很難啟動，因為協調可信設置的難度很大。ZCash、AZTEC協議、Tornado和Semaphore都不得不編寫定制的可信設置基礎設施。在建立更多可重復使用的可信設置工具化上面已經有一些嘗試，但運行這些儀式仍然是非常耗費人力的。但是請注意，隨著我們轉向不需要每個電路的可信設置的協議，長期來說這可能不會成為一個問題。

用于處理SNARK遞歸的工具。支持遞歸驗證的SNARK使我們能夠建立“可編程的”SNARK，其中SNARK代碼可以通過插入驗證密鑰到其他SNARK子模塊而被“迅捷”修改。此外，遞歸SNARK還允許開發者將證明生成并行化。在實踐中支持這種功能是一個困難的問題，可能會在未來幾年內努力解決......

上面列出的電路很復雜，而且極難手工驗證。巧妙的約束優化實際上使問題更加復雜——高度優化的電路很難推理，而且如果你在做一些棘手的事情，很容易在實現過程中漏掉一個約束條件。此外，由于ZK應用的性質，可能無法判斷ZK電路中的錯誤是否已經被人利用了。

編寫讓你對完整性有信心的測試是相當容易的：證明你可以從輸入中正確地生成證人和證人的有效證明。要獲得對健全性的信心則比較困難。要做到這一點，你必須驗證有一個唯一的證人滿足SNARK對給定輸入的約束系統——一個惡意的驗證者不能用一個有問題的證人來代替，從而產生一個由于缺少約束而產生的有效證明。比這更難的是證明電路與規范的等價性，即形式驗證。

目前，大多數在生產中使用ZK電路的團隊所采取的方法是委托人工審核，盡管這些審核的質量并不穩定，而且能夠進行審核的人的總數也非常少。我們可以合理地確定，像Tornado.Cash這樣的應用程序可能是安全的。然而，我們的概念驗證groth16ECDSA的實現依賴于數千行的circom代碼，電路大小為數十萬或數百萬的約束。更復雜的基元將更難驗證，而PLONK的自定義約束將增加額外的復雜性。

我們為ZK應用安全空間提出了一些方法。在未來，我們將發表一篇文章，對我們所知道的這個領域的現有方法進行更深入的概述。

建立一個審核者社區。團隊往往很難找到具有ZK應用開發專業知識的專家來審閱他們的電路和代碼。我們可以鼓勵現有的專注于ZK的團隊，如rollup公司的工程師以及應用開發人員，來”交換”審核者，我們也可以共同開始培訓審核者。

建立電路工程和審核的最佳實踐。隨著生態系統的成熟，我們將希望為構建、注釋、記錄和審核ZK電路制定最佳實踐。這可以在不同程度上進行，自然語言的規范或正式規范都有助于使電路更加清晰。列舉常見的缺陷和錯誤也可以幫助工程師和審核者。

對電路基元的正確性進行手動證明。對于重要的基元，例如散列函數或ECDSA電路，也許可以為這些基元手動寫出正確性證明，用證明檢查器來檢查。然后，其他電路構建者將能夠以更大的信心使用這些基元。

自動化的證人唯一性驗證。Ecne是第一個自動化的R1CS證人唯一性驗證器。這個項目使我們能夠驗證ZK電路是否有任何缺失的約束，這是在建立ZK系統的信心方面邁出的重要一步。我們希望能支持和鼓勵更多類似方向的工作。

基于求解器的形式驗證方法。一些團隊正在探索證明ZK電路與形式化規范的等價性的自動方法。這一領域的工作也需要我們開發一套通用的基準，以及一種用于指定ZK電路的語言。

參考

ZK群簽名：https://0xparc.org/blog/zk-group-sigs

配對友好：https://electriccoin.co/blog/new-snark-curve/

賬戶抽象：https://eips.ethereum.org/EIPS/eip-2938

簽名方案：https://www.secg.org/sec2-v2.pdf

更高層次的構建：https://eips.ethereum.org/EIPS/eip-2938

MetamaskSnaps：https://docs.metamask.io/guide/snaps.html

Stealthdrop：https://github.com/nalinbhardwaj/stealthdrop

共謀：https://twitter.com/vitalikbuterin/status/1329012998585733120

ZK群簽名文章：https://0xparc.org/blog/zk-group-sigs

BabyJubJub素數：https://iden3-docs.readthedocs.io/en/latest/iden3_repos/research/publications/zkproof-standards-workshop-2/baby-jubjub/baby-jubjub.html

MiMC：https://byt3bit.github.io/primesym/mimc/

Poseidon：https://www.poseidon-hash.info/

keccak：https://github.com/vocdoni/keccak256-circom

https://github.com/0xPARC/circom-secp256k1/blob/master/circuits/secp256k1.circom

合并實施：https://github.com/0xPARC/circom-secp256k1/blob/master/circuits/eth_addr.circom

數學背景：https://www.notion.so/Prerequisite-Understanding-Questions-cc6898f0fad04d9fbc7b8d33c34a865d

https://github.com/iden3/circom

AZTEC：https://medium.com/aztec-protocol/the-hunting-of-the-snark-3-3-c0a6e17c6d92

ElectricCoinCo：https://zcash.github.io/halo2/concepts/arithmetization.html

iden3：https://iden3.io/

ZK-Garage：https://github.com/ZK-Garage

概念驗證：https://github.com/agajews/circom-dsl

約束優化：https://akosba.github.io/papers/xjsnark.pdf

ZKREPL：https://zkrepl.dev/

hardhat-circom：https://github.com/projectsophon/hardhat-circom

circom-helper：https://www.npmjs.com/package/circom-helper

circom：https://github.com/iden3/circom

arkworks：https://github.com/arkworks-rs

libsnark：https://github.com/scipr-lab/libsnark

ZCash：https://electriccoin.co/blog/completion-of-the-sapling-mpc/

AZTEC協議：https://github.com/AztecProtocol/Setup

Tornado：https://github.com/tornadocash/trusted-setup-server

Semaphore：https://github.com/appliedzkp/semaphore-phase2-setup

電路：https://github.com/tornadocash/tornado-core/tree/master/circuits

Ecne：https://github.com/franklynwang/EcneProject

Tags：ARKCOMNARTPSMochi.MarketHypercomicLunariumtps幣圈

比特幣交易