了解 zCloak 的 zk-SBT 解决方案,通过 Web3 KYC 进行深入研究

研究 zCloak 的 zk-SBT 解决方案,通过 Web3 KYC 深入了解。

前言

在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测试网上。我们即将于八月在各大以太坊生态主网进行合约部署。如需了解最新进展,请关注我们的社交媒体渠道。