前言

在 Web3 中，很多问题需要被重新考虑。比如如何在 Web3 环境中完成 KYC、如何在验证用户身份属性需求与用户隐私保护需求之间取得平衡、以及如何真正实现个人数据主权？zCloak 一直在积极探索这些问题的解决方案——我们很高兴地推出 zk-SBT，一个将重新定义 Web3 KYC 流程的开创性解决方案。

现有问题

传统 KCY 流程有诸多问题，举例来讲，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 形式，可以同时保证用户隐私和良好的互操作性。