zkPass技术概述

v1.0 更新日期：2024年5月

这是我们之前的技术概述。如需最新更新，请点击‘ 介绍 zkTLS 的混合模式：zkPass 创新 ’。

zkPass 是一种 oracle 协议，旨在使私人互联网数据在链上可验证。基于 zkTLS，由 3P-TLS 和 Hybrid ZK 技术构成，zkPass 为安全、可验证的数据共享提供工具和应用，确保来自任何 HTTPS 网站的隐私和完整性，而无需使用 OAuth API。

zkPass 允许用户选择性地证明各种类型的数据，例如法律身份、金融记录、医疗信息、社交互动、游戏数据、现实世界资产、工作经验、教育和技能认证。这些零知识证明计算是在本地安全执行的，确保敏感的个人数据不会泄露或上传到第三方。它们可用于 AI、DePIN、DID、贷款以及其他金融和非金融应用。无论在哪种情况下需要信任和隐私，zkPass 都可以提供解决方案。

用户控制私人数据而不泄露敏感个人信息，从而避免不可预测的潜在刑事定罪和罪犯行为。

本文旨在概述 zkPass Oracle 协议的整体架构及其工作原理。

整体结构

符号和定义

• P：证明者（个人）
• V：验证者（企业）
• S：TLS 服务器
• Q：P 初始化的查询
• R：S 回复的数据
• enc_key：TLS 中加密数据的密钥
• mac_key：TLS 中的 MAC 密钥
• t：摘要

概述解决方案

在传统的数据验证和确认过程中，证明者将其信息提交给验证者。验证者检索这些数据并与数据源合作进行身份验证检查。因此，在该模型中，验证者只是作为中介或代理人。

每个参与者在此场景中面临独特的挑战：对于证明者而言，存在披露过多个人信息的风险；对于数据源而言，尽管它是一个可信的数据提供者，但无法提供个性化的验证服务；而对于验证者，他们掌握所有客户的私人数据，获取完全访问权限，这带来了数据泄露的重大潜在风险。

我们提出了一种新的方法，重新定位这三个实体，将证明者置于验证者和数据源之间。证明者不再使用传统的方法，而是直接使用其访问Token从数据源查找和检索其数据，随后为验证者生成零知识证明（ZKP）以供检查。此过程确保验证者无法了解证明者的个人信息。

为了实现该结构，我们结合了 3P-TLS、MPC 和 IZK 技术。

3P-TLS 和 MPC

传输层安全性（TLS）是 HTTPS 的安全协议，几乎所有数据源都支持它。它是一种为客户端/服务器结构设计的双边协议。我们基于椭圆曲线 DH 协议构建了 3P-TLS 协议，并将其与 MPC 和盲传输（OT）结合以防止作弊。

在 3P-TLS 协议中，有三个关键参与者：S，作为受信任的数据源，P，证明者/用户，以及 V，zkPass 节点。P 和 V 共同作为客户端，通过一系列阶段与 S 建立安全通信。

阶段 1：三方握手

第一阶段涉及一个三方握手协议。在这里，P、V 和 S 共同生成会话密钥。P 和 V 各自获得这些密钥的一部分。这是通过使用 Paillier 加密算法来实现的，该算法提供可加性同态。预主密钥被分为两部分，P 和 V 各自收到一半，而 S 保留完整的预主密钥。重要的是，为了防止客户端伪造假网站，在客户端和服务器互致问候后，客户端会要求服务器返回证书。随后的密钥交换阶段还包括服务器的公钥签名，该签名由证书的私钥签署。这使 V 在客户端中也能获取证书和签名以供验证，从而确保对数据源的信任。

阶段 2：密钥交换和 MPC

在步骤 6 和 7 中，P 和 V 参与 MPC 以计算用于数据保护的加密密钥（enc_key）和用于数据完整性的消息认证码密钥（mac_key）。值得注意的是，V 仅拥有 mac_key 的一部分，而没有 enc_key。这确保了 V 无法访问用户的私人信息。相比之下，P 拥有 mac_key 的一部分，授权访问特定身份信息，但无法对其进行篡改。任何篡改都可以通过使用 mac_key 验证消息的真实性来检测。

阶段 3：标准 TLS 和零知识证明准备

步骤 8 和 9 遵循标准 TLS 协议程序处理应用数据。在步骤 10 至 12 中，P 和 V 交换密钥，以为即将到来的零知识证明阶段做好准备。

此时，三方 TLS 协议结束。zkPass 的 MPC 算法在通信时间、Garbler、Evaluator 和 OT 的哈希函数以及内存复制操作方面进行了重大优化。这导致效率提升超过三倍。此外，采用了一种新的 AES128 证明方法，使得区块数减少了 300 倍，同时改善了 Garbler/Evaluator 的执行时间达十倍。具体而言，zkPass 对 OT 操作采用静默 OT，有效减少了 OT 生成中的离线网络通信。在 Garbled Circuits 方面，zkPass 采用堆叠 GC，大幅减小了 Garbled Circuits 的大小，从而减少了在线通信和执行时间。总体优化显著减少了整个 MPC 过程的运行时间。

ZKP — 混合 ZK

zkPass 协议的最后一步涉及客户端生成零知识证明，区块链上的智能合约验证该证明。我们采用了结合了交互式和非交互式 ZK 协议的混合零知识 ZK 方法。

交互式零知识 (IZK) ：

我们利用基于 VOLE 的交互式零知识 (ZK) 协议，我们称之为 VOLE-ZK 23。该协议在认证中起着关键作用，确保数据来自精确的数据源，并保护其不受客户端篡改。VOLE-ZK 23 协议可以描述为一个“承诺和证明”框架。在该设置中，无论是证明者（P）还是验证者（V），共同生成多个 VOLE 实例，每个实例满足线性公式“m = k + w * delta”。P 将该公式的某些组成部分作为承诺，其中 ‘m’ 是承诺，‘w’ 在去随机化后可以转化为见证。

另一方面，V 持有剩余的组成部分（‘k’ 和 ‘delta’）。目标是证明和验证布尔电路的满足性。P 根据 VOLE 实例为每个门建立一个承诺。由于 VOLE 实例之间的相关性是线性的，我们可以通过将所有承诺相加并确认最终结果是否仍符合该相关性来进行批量检查。这种线性关系是我们解决方案成本效益的关键原因，使其不同于其他高次多项式解决方案，如 SNARK。

因此，P 只需向验证者发送两个域元素（‘m’ 的和和 ‘w’ 的和）。为了保护敏感信息，可以创建一个随机线性组合。然后，V 使用其 VOLE 参数（‘k’ 和 ‘delta’）验证相关性。

在这个阶段有五个主要约束：

向量 x = (Q’，R’，mac_key_pv，b) 表示公共信号，而 w = (enc_key，token，Q，R) 是见证。

Dec(enc_key, Q’) = Q, 和 Q = Query(token)

前两个约束与向受信任的数据源发出的 HTTP 请求有关。第一个约束确保请求是使用加密密钥加密的。第二个约束指定请求必须使用用户的访问Token生成，通常在大多数情况下存储在cookies中。这两个约束确认用户使用其个人数据（例如用户名和密码），并遵循在模板中定义的特定 API。

Dec(enc_key, R‘) = R

R’ 表示从受信任数据源接收的响应，使用加密密钥进行加密。因此，这个约束意味着用户必须拥有在三方握手过程中生成的加密密钥以解密响应。这个约束确保用户无法创建伪造的加密密钥。

Verify(mac_key_pv, MAC, R) = 1

R 表示解密后的响应。zkPass 协议必须确保该响应（R）未被用户篡改。为此，应用了该约束。附加的 MAC（消息认证码）数据附加在 R 的结尾，使用 MAC 密钥生成。验证过程使用 HMAC 和 SHA256 哈希函数进行。该验证步骤作为防止用户对响应数据进行未经授权的修改的保护。

b = Assert(R)

最后一个约束表明，R 中包含的数据必须符合模板中列出的特定条件。例如，如果 R 的结构为 JSON 对象，如 {user: xxx、age: 30}，则“年龄”属性的值必须大于 18。简单来说，这个约束确保 R 中的数据符合预先设定的标准。

优化

VOLE 实例和所有门的承诺。在 zkPass 中，我们进行了一些优化，以提高协议的实用性。我们引入了 SoftSpoken，有效地将网络开销降低约 50%，并加速了 VOLE 生成。利用 VOLE 的可加同态性质，我们成功将 XOR 和 INV 门的承诺缩减为零。我们已证明，在实践中，安全只需针对 AND 门的承诺。这一减少显著简化了电路的复杂性，主要集中在 AND 门上，其规模显著小于原始设置。

此外，对于我们特定用例中涉及类似操作的情况，例如服务器记录处理中的 AES 加密和解密，我们可以重用 VOLE 参数。这进一步减少了网络流量，将乘法操作转化为加法操作。我们称之为“多数据信号输入”，类似于 CPU 架构中的 SIMD（单指令、多数据）。

一个潜在的协议限制是节点在证明和验证过程中必须保持在线。然而，这一要求与我们的具体需求无缝对接，对于我们的项目而言并不成问题。

NIZK

随后，我们从交互式零知识 (IZK) 证明转变为非交互式零知识 (NIZK) 证明。此转变的目的是隐藏实际的模板架构，使用户能够选择性地披露证明，以便任何方进行公共验证。为了实现此目的，我们采用了 SNARK（简洁非交互式知识论证）框架，特别是 Circom。

该过程相对简单。一旦客户端成功通过 IZK 验证，节点提供结果的签名。随后，客户端将结果及其相关签名插入 Merkle 树，并在 SBT（选择性区块链树）合约中更新根。

当客户端需要证明结果时，只需提供一个零知识证明，证明结果是 Merkle 树中的一个叶子节点，且已由节点签名。该方法允许有效且安全地验证结果，同时保持隐私和可扩展性。

SBT

该图显示了我们如何构建 zkSBT。我们遵循 ERC998 标准，这是一个可组合的 NFT 标准，并从零开始构建 NFT。值得注意的是，tSBT 和 dSBT 本质上是 NFT 本身。tSBT 代表法律身份、社交网络和金融信息等类别。同时，dSBT 包含用户声称的实际凭证，例如来自政府网站的数字法律身份或银行账户。我们定制了 dSBT 代码以存储额外的信息，称为“声明”。

这些声明分为两种类型：主声明和查询声明。主声明涉及用户从数据源获取其私人数据，例如从政府网站获得的国家、年龄、性别等信息，经过安全的多方计算（MPC）。我们基于这些数据构建声明树，每个节点表示其子节点的哈希。为增强安全性，我们使用从私钥和主声明 ID 派生的随机数，并使用 babyjub 签名，这有助于抵御穷举攻击。随后，我们将主声明树的根哈希存储在 dSBT 中。自然，需要生成并由智能合约验证树的正确性的零知识（ZK）证明。

此时，我们有了主声明。至于查询声明，例如确定用户的年龄是否大于 18，用户只需提供证明其年龄所对应的叶子在树中，并且该叶子的值大于 18。用户可以直接将该证明传递给验证者。验证者可以执行链上函数以验证该证明。

总体结构确保用户的实际私人数据对所有参与方保持隐私。只有数据查询的声明被选择性地披露给特定的验证者。

安全性

首先，让我们识别在协议中的潜在对手：

从客户端的角度来看，主要关注点是使用无效数据绕过节点验证的风险。另一方面，节点的目标可能是未经授权地获取客户端的私人数据。

首先解决后者场景。根据协议设计，节点有效地无法实现该目标。

现在，关于第一个场景，鉴于协议的半诚实性质，只要所有方遵守协议指南，就能维持安全并实现准确结果。

剩下的挑战涉及恶意客户端与恶意节点之间的相互作用。为了减轻恶意节点带来的威胁，我们引入了一个网关，其功能类似于区块链中的 RPC 端点。该网关确保客户端在网络信息上保持不可区分。此外，通过 TLS（传输层安全性）引入随机性，进一步掩盖了基于会话数据的客户端身份。

在我们的去中心化网络中，我们引入了一个新概念，称为“渔夫”，负责向节点发送随机任务。该渔夫有效地识别并揭露任何恶意节点。由于节点无法区分真实客户端和渔夫，任何参与恶意活动的恶意节点都面临失去其抵押资产的风险，而渔夫则会获得奖励。因此，从事此类行为不符合节点的最佳利益。

客户端和渔夫可以通过调解人寻求仲裁，调解人作为任务执行的中介。调解人可以缓存所有通信数据并要求节点披露其 VOLE 参数。这使调解人能够重演整个验证过程，确定哪一方存在过失，并成功结束仲裁过程。值得注意的是，所有这些过程都是自动化的，几乎无需人工干预。

zkPass 官方链接：

网站 | Twitter | Discord | Medium | Github

• 原文链接： medium.com/zkpass/a-tech...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～