ARK:Zk-SBT：基于zk-SNARK實現的靈魂綁定代幣教程

SBT可以更好的幫助用戶驗證某個屬性，但極易泄漏隱私。使用零知識證明技術來保證用戶數據的安全可能是一個重要的選擇。在這篇文章中，我們將討論ZK如何可能成為增加SBT用戶數據隱私的關鍵技術，以及如何應用零知識靈魂綁定代幣。目錄

1.什么是零知識證明2.ZK證明如何與SBT一起使用？3.什么是zk-SNARK？4.ZKSBT工作原理的解釋4.1.1生成隨機Lambda4.1.2生成證明密鑰和驗證密鑰4.1.3證明和驗證密鑰的共享4.1.4證明的生成4.1.5用戶屬性驗證5.高級示例5.1鏈上與鏈下算法6.zkSBT的實現6.1電路創建6.2設置階段6.2.1密鑰生成6.3證明生成階段6.4驗證程序階段6.4.1項目如何在其SBT中使用Verifier.sol？6.4.1.1風險：防止重放攻擊6.5實現架構7.ZKSBT與CounterPartySoul的可組合性7.1單一方法：SBT發行人承擔責任7.2多重方法：每個項目都承擔責任8.結論1、什么是零知識證明

零知識證明允許一方向另一方證明一個陳述是真實的，而不會透露任何超出陳述本身有效性的信息。證明者必須讓驗證者相信他擁有滿足某種關系的秘密參數的知識，而不向驗證者或其他任何人透露該證人。證人是我們約束條件的有效解決方案。約束是指我們將問題轉換成的多項式方程。問題的每個解決方案都必須符合約束條件的要求。例如，證明用戶的信用分數是3，可以簡單地轉換為約束條件x=3。2、ZK證明如何與SBTs一起使用？

項目可以通過使用ZK證明來驗證靈魂的屬性。還可以通過允許用戶驗證任意的斷言，而不需要給出除聲明本身之外的任何進一步信息。例如，在一個政府文件和其他證明可以加密證明的世界里，有人可以證明這樣一個聲明："我是新加坡公民，年滿18歲，擁有計算機科學的大學學位，還沒有在這個系統中申請賬戶。"還有其他ZK技術；然而，zk-SNARKs是在DarkForestEth、Tornadocash和ZK-Rollups等應用中使用的最突出的ZK技術。3、什么是zk-SNARK？

zk-SNARK是ZK-proof技術的一種實現，它代表零知識簡潔、非交互式知識論證。首字母縮略詞的各個部分具有以下含義：零知識：在交互過程中，除了聲明的有效性之外，驗證者什么都不知道。簡潔：證明簡短且快速驗證。非交互：沒有或僅有少量的交互。對于zk-SNARKs，通常有一個設置階段，在這之后，從證明者到驗證者只有一個消息。此外，SNARKs通常具有所謂的"公共驗證者"屬性，即任何人都可以自己驗證證明。論證：驗證者只針對計算能力有限的證明者進行保護。具有足夠處理能力的證明者可以生成關于不正確語句的證明/論證。這被視為"計算上的健全性"，與"完全健全性"相對。知識性：證明者不可能在不知道某個所謂的證人的情況下構建證明/論證。簡單地說，這基本上意味著證明是一個數據的集合，可以在沒有證明者參與的情況下獨立驗證。4、ZKSBT工作原理的高級解釋

Vitalik：跨鏈證明是實現跨鏈社交恢復錢包的關鍵，ZK-SNARK等是可行選擇:6月20日消息，以太坊聯合創始人VitalikButerin在最新文章《更深入探討錢包和其他用例的跨L2讀取》中指出，實現跨鏈社交恢復錢包的一個可行方案是維護一個存放在特定位置的密鑰庫，以及多個不同位置的錢包，這些錢包可以讀取密鑰庫來更新自身的驗證密鑰視圖或在每次交易驗證過程中。跨鏈證明是實現這個功能的關鍵，需要對其進行深度優化，可能的方案包括零知識證明（ZK-SNARK）、等待Verkle證明或自定義KZG解決方案。

從長遠看，我們需要實現聚合協議，通過生成聚合證明來打包所有用戶提交的操作，以此來降低成本。這可能需要將其集成到ERC-4337生態系統中，可能需要對ERC-4337進行一些修改。同時，為了減少從L2內部讀取L1狀態的延遲，L2應被優化。

錢包不只可以放在L2上，也可以放在與以太坊連接程度較低的系統上，如L3或只同意包含以太坊狀態根的獨立鏈。然而，密鑰庫應放在L1或高安全性的ZK-rollupL2上。盡管這樣會增加復雜性，但從長期來看，可能在L2上設置密鑰庫才是成本更低的方案。在這個過程中，我們也需要致力于提供保護隱私的解決方案，并確保我們的方案可以與隱私保護方案兼容。[2023/6/21 21:50:47]

舉例來說，SBT的用戶是證明者，向用戶發放SBT的項目方是驗證者。假設一個項目正在查看用戶是否具有某個屬性“secret_attribute”。用戶必須證明他們有屬性`secret_attribute`而不會泄露他們的秘密`s`，它用于將屬性`secret_attribute`散列到`hash_attribute`。通常情況下，用戶會通過向項目提供秘密`s`來證明這一點，之后項目可以計算出哈希`hash_attribute`。然而，在zk-SNARK中，用戶可以只提交他們擁有屬性`secret_attribute`的證明，而不透露他們的秘密`s`。我們可以用下面的程序C來描述用戶的情況。

換句話說：該程序接受一個公共哈希值`hash_attribute`和一個秘密值`secret_attribute`，如果`secret_attribute`的SHA-256哈希值等于`hash_attribute`，則返回true。使用函數`C(hash_attribute,secret_attribute)`，用戶需要創建他們擁有`secret_attribute`的證明，而不需要透露`secret_attribute`。這就是zk-SNARKs解決的一般問題。為了實現這個證明和驗證系統，該項目首先要進行以下操作。4.1.1、生成隨機Lambda

Layer2 ZK-ZKVM 項目 Ola 發布第二版技術白皮書:4月9日消息，可編程性隱私和擴容方案 Ola 發布第二版技術白皮書，致力于構建一個集隱私、高性能、可編程性為一體的 Layer2 ZK-ZKVM 平臺，讓用戶真正掌控個人數據所有權與使用權。第二版白皮書強調了如何設計和構建 Ola 中最重要的基礎模塊，高性能的 ZKVM，OlaVM；ZK 友好的智能合約語言，Ola-lang；以及隱私的設計架構。

另外，Ola 已于近期開啟品牌升級計劃，將于 2023 年年內上線測試網，2024 年年初上線主網。據悉，Ola 由 Sin7y Labs 團隊研發，專注于 Layer2 的 ZK- ZKVM 方案。[2023/4/9 13:53:28]

生成lambda是證明的第一步。記下生成器的秘密參數lambda。任何了解此參數的人都可以在不知道秘密“w”的情況下創建評估為真的假證明。因此，運行生成器需要一種非常安全的方法，以確保沒有人在任何地方發現和存儲參數。這就是Zcash團隊在確保參數lambda在此過程中被銷毀的同時生成證明密鑰和驗證密鑰的極其復雜的儀式的基本原理。4.1.2、生成證明密鑰和驗證密鑰

該項目必須生成兩個公開的密鑰--證明密鑰`pk`，和驗證密鑰`vk`。密鑰生成程序G需要一個秘密參數`lambda`和一個程序`C`。這些密鑰是公共參數，只需要為一個給定的程序C生成一次。在大多數情況下，這個程序C是以電路的形式實現的。

用程序C和lambda生成證明密鑰`pk`和驗證密鑰`vk`一個獨立于用戶和項目的受信任的獨立小組可以運行生成器，并以一種沒有人知道lambda的方式創建證明密鑰`pk`和驗證密鑰`vk`。然后，任何信任相關各方的人都可以在未來的互動中使用這些密鑰。4.1.3、證明和驗證密鑰的共享

該項目將與用戶共享證明密鑰`pk`和驗證密鑰`vk`。然后，這些密鑰可以用來生成基于用戶屬性的證明，以及驗證屬性。這里的"共享"一詞用得很寬泛。項目不需要明確披露，但他們可以在前端提供一個功能，允許用戶或交易方進行自己的證明或驗證。

StarkWare：StarkNet用編程語言Cairo語言寫出了ZK-EVM:10月26日消息，零知識證明技術開發公司StarkWare發推表示，StarkNet使用編程語言Cairo語言寫出了ZK-EVM，將于明天邀請以太坊聯合創始人Vitalik Buterin、ZK-STARK合作發明者Eli Ben-Sasson、StarkWare成員Shahar Papini等人進行Twitter Space。[2022/10/26 11:44:52]

項目為用戶生成證明和驗證密鑰4.1.4、證明的生成

然后，用戶需要證明他知道散列到已知散列“hash_attribute”的“secret_attribute”。為此，用戶使用輸入pk、H和s運行證明算法“generate_proof”來創建證明“prf”：H是s使用SHA256的公共哈希。

其中H是哈希密鑰，s是密鑰，pk是證明密鑰

用戶生成證明當項目要檢查用戶是否具有某個屬性時4.1.5、用戶屬性驗證

用戶將生成的證明“prf”提供給運行驗證函數“verify(vk,H,prf)”的項目。

該項目計算`verify(vk,hash_attribute,prf)`，如果證明正確則返回true，否則返回false。該驗證算法也可以在鏈上。如果驗證算法返回true，則項目可以確信用戶具有該屬性，但用戶不需要向驗證項目透露其屬性。

5、高級示例的TL;DR

一個zk-SNARK由三個算法`G`、`P`、`V`組成，定義如下。生成器程序

密鑰生成器"G"接受一個秘密參數"lambda"和一個程序"C"來產生兩個公開可用的密鑰，一個證明密鑰"pk"和一個驗證密鑰"vk"。這些鑰匙是公共參數，對某個程序'C'可以只生成一次。通過對lambda的適當處置，生成算法可以脫離鏈路。然后，生成的證明密鑰和驗證密鑰可以與用戶共享。請注意，程序C也被稱為公共算術電路。證明者程序

Horizen在主網發布zk-SNARK跨鏈協議Zendoo:12月3日消息，Horizen在主網發布zk-SNARK跨鏈協議Zendoo，Zendoo是一種獨特的互操作性協議和擴展解決方案，開發人員可以使用Zendoo構建支持zk-SNARK的自定義區塊鏈，在不影響去中心化的情況下提供大量吞吐量。（Cointelegraph）[2021/12/3 12:47:57]

證明者P接受證明密鑰"pk"、公共輸入"x"和私人見證"w"作為輸入。該算法生成一個證明`prf=P(pk,x,w)`。用戶的證明生成可以通過證明和驗證密鑰及其證人在鏈外完成。建議在鏈下生成證明，因為生成證明的計算成本很高，而且用戶的秘密可能在鏈上被泄露。|證人是由用戶的秘密轉換而來，這對我們的約束來說是一個有效的解決方案。驗證者程序

驗證者V計算“V(vk,x,prf)”，如果證明正確則返回true，否則返回false。因此，如果證明者知道證人`w`滿足`C(x,w)==true`，則此函數返回true。驗證可以在鏈上完成，因為它相對較小，需要輸入證明、秘密的哈希值和驗證密鑰作為公共輸入參數。5.1、鏈上與鏈下算法

鏈下

項目將運行生成器以生成證明密鑰和驗證密鑰。然后任何用戶都可以使用證明密鑰生成鏈下證明。用戶可以通過運行具有以下輸入的證明算法來做到這一點——證明密鑰、公共輸入和私人見證。鏈上

智能合約中的通用驗證算法可以使用證明、秘密哈希和驗證密鑰作為公共輸入參數來運行。然后可以使用驗證算法的結果來觸發其他鏈上活動。下圖顯示了從創建程序到使用zk-SNARK生成和驗證證明的整個過程的摘要。

zk-SNARKs的全部可信設置過程6、zkSBT的實現

我們已經通過一個高級示例來說明zk-SNARKs和SBT如何協同工作。在本節中，我們將通過一個簡單的示例來說明項目如何實施zk-SNARK和SBT以使交易對手能夠驗證靈魂的屬性。假設信用借貸平臺為用戶鑄造了一個SBT，并為用戶分配了信用評分。信用借貸平臺希望允許其他交易對手的項目來驗證用戶評分是否高于某個閾值。我們怎么能創造這個？此應用程序有4個不同的部分。前端、后端、智能合約和電路。電路是與zk證明的生成和驗證相關的主要組件，因此我們將更多地關注這一點。6.1、電路創建

ETH 2.0項目負責人稱階段0預計很快推出 V神明確反對zk-STARKS應用:ETH 2.0項目負責人Danny Ryan近日在reddit上解答ETH 2.0有關進展和功能時表示，ETH 2.0的開發當前集中在“信標鏈”的構建上，這是ETH 2.0的基礎。但是階段1的開發正在逐步進行，該階段引入了用于與信標鏈連接的“分片”的分片鏈，并且階段0發布預計將很快推出。此外，Ryan還表示，團隊的目標是讓整個以太坊社區參與進來，并與盡可能多的客戶建立聯系。

而針對有人提出的量子保護隱私保護技術“ zk-STARKS”的“ Etherium 3.0”的想法，Vitalik Buterin本人在reddit上明確表示不支持。V神稱，目前，希望以太坊的基本結構在ETH 2.0發布后不會改變。（注：zk-STARKS是一種區塊鏈隱私解決方案，該方案能夠將大量信息壓縮成名為starks的小樣本并使用零知識來保護信息的隱私。）（Coinpost）[2020/6/1]

在我們可以使用zk-SNARK之前，我們首先必須將我們的程序規范轉換為電路。對于電路的創建，我們使用的是IDEN3團隊設計的circom2庫。該庫已用于許多其他流行的應用程序，例如TornadoCash和游戲DarkforestEth。例如，電路設計旨在允許用戶鑄造具有信用評分但沒有其他人知道信用評分是什么樣的SBT。然而，用戶仍然可以證明他的信用評分高于閾值并且他是值得信賴的。簡單來說，我們將設計一個簡單的電路，如果用戶的分數高于公共閾值，則返回true，而無需用戶透露他的分數。

https://github.com/SpartanLabsXyz/zk-sbt/blob/master/circuits/demo/circuits.circom在我們的資源庫中，我們還包括了其他針對不同使用情況的電路實例。項目可以考慮不同的電路，以滿足其特定的限制。https://github.com/SpartanLabsXyz/zk-sbt/tree/master/demo/circuits電路設計注意事項zk-SNARKs更難的部分是實施適當的電路約束以確保程序執行。如果電路沒有正確實現，它可能會被利用，并且由于程序的零知識性質，很難檢測到這種利用。|什么是電路？|電路是指確定我們的約束的程序。|zk-SNARKs不能直接應用于任何計算問題。問題首先需要轉換為正確的形式。第一步是將程序轉換為代數電路。|有關更多信息，請查看他們的文檔https://docs.circom.io/background/background/#zero-knowledge-proofs

A-B>0，其中A是用戶的秘密，而B是我們在驗證算法中使用的閾值。6.2、設置階段

首先，信用貸款平臺首先生成一個隨機λ。在我們的例子中，我們使用tau的權力，這是一個多方儀式的可信設置，以分散的方式生成隨機λ。請注意，存在不同的復雜過程來生成這個隨機lambda，這是至關重要，通過保持未知，以防止任何人偽造證明。對于我們的應用程序，我們創建了一個示例腳本`execute.sh`來運行設置過程。6.2.1、密鑰生成

為了創建和檢查證明，我們使用了一個名為SnarkJS的庫，由JordiBaylina和Iden3構建。SnarkJS使用您的電路在JavaScript和Solidity中生成證明和驗證代碼，以及協議參數、證明和驗證密鑰。證明密鑰和驗證密鑰示例：https://github.com/SpartanLabsXyz/zk-sbt/tree/master/circuits/demo6.3、證明生成階段

“證明”是用戶為了證明自己的屬性而生成的。但是，在用戶的輸入屬性可以用作證明之前，必須先將其轉換為見證。使用circom2庫，我們可以通過命令輕松生成見證`節點生成_見證。js電路.wasm../input.json見證.wtns`其中input.json是用戶的輸入，也就是用戶的信用評分。證明的生成可以在客戶端的鏈下完成，它接受程序的輸入、見證人和證明密鑰。使用帶有Groth16協議的snarkjs，我們可以使用`snarkjsgroth16證明電路_0001.zkeywitness.wtnsproof.jsonpublic.json`|Groth16是zkSNARK證明方案的具體實現。在這里閱讀更多。一旦我們生成了證明，我們就可以繼續由用戶驗證證明。6.4、驗證方案階段

對于驗證，我們是在鏈上進行的。使用`snarkjs`庫，用戶可以從提供的驗證密鑰中生成驗證算法。然后，驗證算法可用于使用`snarkjs`庫生成一個solidity智能合約在生成`Verification.sol`后，我們可以使用函數`verifyProof`來證明給定的SBT具有有效屬性。本質上，`verifyProof`是一個接受哈希和證明并返回布爾值的函數。

合約：https://github.com/SpartanLabsXyz/zk-sbt/blob/master/contracts/Verifier.sol6.4.1、項目如何在其SBT中使用

Verifier.sol？項目可以在SBT合約中包含驗證者作為接口，如函數`validateAttribute`所示。這允許任何項目包含鏈上驗證機制，其中所有用戶需要的只是他們的證明，以及驗證其屬性的驗證密鑰。

https://github.com/SpartanLabsXyz/zk-sbt/blob/master/contracts/zkSBT.sol驗證屬性函數中的輸入`a,b,c,inputs`是snarkjsgeneratecall函數生成的參數。`@param_soul`是靈魂的地址。`@paramverifierAddress`是為Verifier.sol合約部署的地址。如果證明有效，該函數返回true，否則返回false6.4.1.1、風險：防止重放攻擊

驗證算法的風險之一是攻擊者如何能夠提交另一個用戶的證明作為他們自己的證明并因此得到驗證。項目必須注意這可能是可能的。一些解決方案正在添加檢查或無效符，以防止攻擊者提交其他用戶的證明。6.5、實現架構

簡而言之，帶有Circom和Snarkjs實現的zk-SNARKs可以用下面的實現來概括。用戶可以在本地創建證明，然后上傳簡短的證明以在智能合約中進行恒定時間驗證，計算成本很高。

整體架構可以在我們的資源庫中查看：https://github.com/SpartanLabsXyz/zk-sbt#architecture有關集成zk-SNARK的步驟的更多信息，您可以參考我們的GitHub，或者更具體地說，是用于生成所有算法和證明的腳本`execute.sh`。https://github.com/SpartanLabsXyz/zk-sbt/blob/master/circuits/execute.sh7、ZKSBT與CounterPartySoul的可組合性

在我們的示例中，我們將發行SBT的項目的角色與可能想要驗證靈魂屬性的交易對手結合起來。但是，對于SBT與其他可能想要驗證用戶SBT屬性的交易對手項目的可組合性，我們必須根據所使用的方法進行一些更改。7.1、單一方法：SBT發行人承擔責任

在SBT中的數據簡單明了的情況下，SBT發行者可能希望生成自己的lambda、證明密鑰和驗證密鑰。然后，他們可以提供一個界面，允許交易對手項目驗證用戶的屬性。優點是這允許輕松采用SBT，因為其他項目可以利用現有的驗證機制，而無需生成和存儲自己的lambda。但是，如果SBT中的數據不同，并且存在幾個旨在證明SBT不同屬性的不同程序C，這可能不可行。7.2、多重方法：每個項目都承擔責任

單個交易對手項目將負責生成lambda、證明密鑰和驗證密鑰，而不是SBT發行者或中心化機構。然后，密鑰和驗證方法將通過項目的應用程序分發給用戶。但是，SBT發行人應提供包含特征的SBT數據結構的清晰文檔，同時保持數據的私密性。這種策略可能適合不想為保護其秘密承擔全部責任的SBT發行人。此外，如果需要SBT中的多個數據證明，則可能需要多個驗證程序，每個程序都有自己的證明和驗證密鑰。此外，該策略消除了對中央機構的依賴，而是將確保證明有效性的責任置于項目本身。然而，這種策略需要每個項目根據被測試的屬性開發自己的生成、證明和驗證算法。8、結論

總之，這篇文章是關于如何使用zk技術使SBT真正私有化以及項目如何在solidity中實現zkSBT的入門讀物。SBT允許將社會身份與去信任的可組合性相結合，如果做得好，可能會改變web3生態系統的未來。信任和所有權的核心方面可以上鏈，以增強智能合約世界中的社會可組合性，這可以為去中心化應用程序打開許多可能性。未來的一個重要研究方向是對不同種類的數據權限的確切限制進行界定，對保持數據隱私的具體技術組合進行研究，以及對可以建立在SBTs之上的產品進行研究，以創造一個“匿名經濟"。

Tags：SBTARKNARQUOsbtc幣還有希望嗎CredmarkTokenariumQUO幣

AVAX