前言
在Web3 中，很多問題需要被重新考慮。比如如何在Web3 環境中完成KYC、如何在驗證用戶身份屬性需求與用戶隱私保護需求之間取得平衡、以及如何真正實現個人數據主權？ zCloak 一直在積極探索這些問題的解決方案——我們很高興地推出zk-SBT，一個將重新定義Web3 KYC 流程的開創性解決方案。
現有問題
傳統KYC 流程有諸多問題，舉例來講，Alice 想參加一個需完成年齡驗證的鏈遊。如果遊戲平台需要獨立驗證Alice 的年齡，則需要Alice 上傳她的的身份文件，甚至生物識別數據。對遊戲平台而言，由於受到《通用數據保護條例（GDPR）》等法規的限制，這些操作非常複雜，會產生高昂的成本，且不符合鏈遊的主要業務。對Alice 來說，KYC 流程也是一種負擔，因為每當她訪問需要某種形式的身份驗證的服務時，都需要重複這一流程，而且身份數據洩漏的風險會隨著身份驗證次數的增加而增加。
因此，我們不禁要問，在Web3 中是否有更好的解決方案，可以讓Alice 僅需完成一次KYC 流程並跨平台使用，如此服務提供商也可更加專注於其核心業務的開展，無需分心於身份驗證解決方案的實施和用戶數據的管理。讓我們來探討一下zCloak Network 的解決方案。
zCloak Network 的KYC 解決方案
用戶擁有數據： 在zCloak Network 的zk-SBT 解決方案中，Alice 的數據不會存儲在每個服務提供商的數據庫中，而是存儲在Alice 的設備中——使她能夠擁有自己數據的自主權。當服務要求身份驗證時，Alice 無需共享她的原始數據，取而代之的是，使用她先前被驗證過的數據，這些數據經過可信實體認證並以可驗證數字憑據（VC）的形式存儲。這種方法既能確保Alice 對其數據的控制，又能滿足服務提供商的驗證需求。
需要注意的是，“用戶擁有自己的數據”的前提條件，是數據在用戶本地存儲。存儲在雲端或者區塊鍊網絡上的數據，是人人可見、人人可用的，第三方要使用這些數據，不需要用戶的同意和批准，所以並不算用戶擁有的數據。
“用戶擁有數據”，既是Web3 的核心價值，也是zCloak Network 的技術解決方案與市面上其它的隱私DID/KYC 方案的核心區別所在。
鏈下VC 和鏈上zk-SBT： 為了保護隱私，包含Alice 驗證數據的VC 被存儲在鏈下—— Alice 的設備上。當Alice 需要證明其身份的某個屬性時，就可通過VC 生成一個zk-SBT。這個zk-SBT 存儲在鏈上，可作為KYC 結果的防篡改和可追溯證據，但不會洩露VC 中包含的敏感數據。使用VC的形式作為數據存儲的源頭，既可以通過數字簽名和時間戳保證數據的真實性，又可以在有需要的時候將其轉化為SBT等鏈上常見的token形式，可以同時保證用戶隱私和良好的互操作性。
用於多種身份檢查的用戶端ZK計算： zk-SBT 解決方案允許用戶端計算，以滿足各種身份驗證需求，如年齡、國籍、收入水平、信用積分等。這意味著Alice 的VC 可以被多次重複地用於不同的身份檢查，每次都生成一個新的zk-SBT。在這個過程中，Alice 的數據被”隱身（cloaked）”了，驗證方可以在不訪問Alice 的原始數據的情況下驗證她的屬性。
目前市面上存在的其它的隱私DID/KYC 方案，在驗證方的驗證條件發生變化後，都需要用戶去官方機構那裡重新生成證明，不但費時費事，而且會向官方機構暴露用戶使用自己數據的場景和意圖，會洩露用戶隱私，屬於需要許可的用戶數據使用方法。而zCloak的方案支持數據一次簽發，即可適配各種驗證場景，無需用戶再與官方機構進行任何互動，屬於保護隱私的無需許可的數據使用方法。這也是用戶擁有自己的數據後結合本地零知識證明計算技術帶來的最大優勢。
第一階段: 認證KYC ，簽發VC
在第一階段，我們開始KYC 流程，由可信實體認證用戶身份並簽發可驗證數字憑證（VC）。平台將充當可信實體，使用各種方法（如文件驗證、生物識別驗證和其他身份驗證技術）認證Alice 的身份。
在成功完成KYC 認證後，受信任實體會為Alice 簽發一個VC，該VC 包含Alice 的基本身份信息，包括姓名、年齡、國籍和地址等。為了便於在後續計算中選擇性地披露特定屬性，VC 採用了內置的Merkle 樹數據結構——這種設計允許高效、安全地披露必要的信息，不會損害整個憑證的機密性。
第二階段：ZKP 計算
在第二階段，Alice 的VC 將作為零知識證明（ZKP）計算的輸入，以驗證Alice 的某一特定屬性，如年齡。通過使用基於WASM實現的Polygon Miden VM 的證明邏輯，ZKP 計算在用戶錢包中的zk-STARK VM 中展開。如此就可證明Alice 的年齡足以加入遊戲平台，而無需洩露她的確切年齡。
Miden VM 利用多項式承諾和評估協議等高級加密技術來執行安全計算。這些技術可確保計算正確、安全地進行，而不洩露任何隱私信息。來自VC 的輸入數據將作為ZK 計算的隱私輸入，並在整個過程中都會對外界保密。 ZKP 計算的核心是zkProgram —— 定義計算的邏輯和規則，並指定需要證明的屬性。 zkProgram 從VC 獲取輸入數據，並通過應用必要的計算和轉換，生成一個代表用戶數據屬性的輸出，例如收入高於10,000 美元。 ZK 計算的輸出會附有一個STARK 證明。驗證器將計算輸出、ZK 證明和ZK 程序用於最終的驗證過程。如果一切都匹配，驗證器將生成一個”通過”結果。
zCloak目前已經準備了網頁端的“無代碼”zkProgram開發工具，可以供驗證方根據自己所在國家地區的法律法規要求，對用戶數據進行各種驗證計算。 “無代碼”開發工具可以大大降低zkProgram的開發門檻，即使是沒有編程經驗的人群也可以輕鬆使用，真正為零知識證明技術的普及和推廣做好了準備。
第三階段：創建zk-SBT
在成功完成ZKP 計算和驗證之後，Alice 緊接著就可以在鏈上創建zk-SBT。這涉及到生成一個唯一的token，該token可鏈接回ZKP 計算結果並將其與Alice 的鏈上地址相關聯。 zCloak採用了包括哈希和數字簽名等加密技術來實現這種關聯。
zk-SBT 本身並不包含任何敏感的個人數據。相反，它充當ZKP 計算結果的參考，為已證明的屬性提供可驗證的證據。舉例來講，zk-SBT 不會表明Alice 是28 歲、來自泰國，而是說她是來自亞洲的成年人。通過將zk-SBT 與Alice 的標識符相關聯，它就成了Alice 存儲在區塊鏈上的已驗證屬性的防篡改表示。
存儲在區塊鏈上的zk-SBT 是透明且不可更改的。網絡中的其他參與者可以通過驗證相關的ZKP 計算結果和Alice 的身份來驗證zk-SBT 的真實性和正確性。這確保了KYC 流程的可信和可靠，因為zk-SBT 提供了一個安全、防篡改的已驗證屬性表示。
第四階段：使用zk-SBT
最後一個階段是Dapp 使用Alice 的zk-SBT。第三方Dapp 可以在無需訪問原始數據的情況下，驗證Alice 的身份屬性及其底層VC 的真實性。驗證在鏈上進行，而相關VC 則安全地存儲在鏈下。
zCloak Network 團隊提供了使用zk-SBT 數據的智能合約示例。任何第三方Dapp 都可以通過重複使用這些合約來在其現有產品中添加用戶身份檢查邏輯。我們的想法是盡可能減少對現有智能合約的改動，也就是說，幾乎無需任何修改，Dapp 就可使用用戶身份數據來提供更好的用戶體驗。
zk-SBT 在KYC 場景中的優勢
在KYC 場景中使用zk-SBT 有幾個顯著優勢：
1.隱私保護：zk-SBT 利用ZKP 來提供隱私保護。一個zk-SBT 代表了一個ZKP，這個ZKP 用於證明用戶基於VC 的斷言，因此也就無需透露存儲在VC 上敏感數據。比如，Alice 無需透露她的確切年齡，就能證明她已達到使用遊戲平台的法定年齡。這促進了區塊鏈交互中的隱私性。
2.去中心化和去信任：zk-SBT 體現了Web3 的去中心化和去信任原則。與需要信任的中心化機構中的傳統KYC 流程不同的是，zk-SBT 將信任轉移到了數學證明上，如此既能使Alice 保持對其數據的控制，又能在無需訪問其原始數據的情況下，通過驗證確認證明的真實性。
3.效能： 使用Miden VM 進行計算提高了zk-SBT 的效能。即使有很大的數據量或用戶數量，這項技術也能支持快速、安全和可擴展的計算和驗證。可信設置的摒除，以及鑄造和驗證zk-SBT 流程的簡化，使KYC 流程更高效、更穩健。
4.可重用性：zk-SBT 具有顯著的可重用性。傳統的KYC 流程往往需要在不同平台上重複驗證步驟。 zk-SBT 消除了這種冗餘。 Alice 鑄造的zk-SBT 可跨平台和服務重複使用，堅持”一次完成，隨處使用（do it once, use it everywhere） “的原則。這種可重用性節省了時間和資源，提升了用戶體驗。
總而言之，zk-SBT 利用ZKPs 和zk-STARK VM 來維護隱私、去中心化和去信任，正在改變Web3 時代的KYC 格局。其獨特的可重用性消除了冗餘，提高了效能和用戶體驗。目前，zCloak 的zk-SBT 正在測試中，並已部署在optimismGoerli、baseGoerli 和Linea 測試網上。我們即將於八月在各大以太坊生態主網進行合約部署。如需了解最新進展，請關注我們的社交媒體渠道。
