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