zkTLS — 可验证互联网的基石

  • zkPass
  • 发布于 2024-12-18 16:38
  • 阅读 36

本文介绍了zkTLS作为可验证互联网的基石,强调了其在保护用户隐私、确保数据真实性以及促进Web2与Web3之间的连接方面的重要性。文章详细阐述了传统TLS的局限性,并通过zkTLS的三个模型(TEE、MPC和Proxy)展示了如何安全地交换私有数据,最终推动了多个行业的数字化转型。

zkTLS — 可验证互联网的基石

可验证网络代表了互联网的新范式,使用户能够以去中心化的方式验证网络数据的来源和真实性。其核心是 zkTLS 基础设施,这是一种突破性的机制,用于加密验证通过 HTTPS 交换的任何数据——释放了可验证网络的真正潜力。

1. 要塞

当今的互联网类似于一张庞大的“要塞”网络——各种由中心化实体控制的在线平台。这些要塞决定规则,并决定信息是否可以在平台之间流动。为了访问服务,用户往往必须将个人数据交给这些平台,即使其中涉及敏感的私人信息。

然而,这些数据的命运大多是不透明的。平台可能会在没有明确披露或明确同意的情况下,将用户数据分享给监管机构或第三方。这些第三方如何使用数据更难以追踪。许多人亲身经历过此类泄露的烦人结果——未经请求的推销电话往往是个人数据被滥用的直接结果。

区块链技术在建立数据所有权方面具有固有优势,但链上数据的数量仍然有限,相较于传统互联网系统。去中心化应用(dApps)在访问现实世界数据时面临重大障碍,因为数据孤岛严重限制了它们的发展潜力,并限制了区块链创新的范围。

预言机作为加密世界与现实世界之间的桥梁,使去中心化技术得以重要推动。

2. 预言机

在区块链系统中,预言机是将外部数据带入区块链智能合约的服务。由于区块链本身无法访问链外数据,预言机充当区块链与外部世界之间的桥梁,使智能合约能够根据外部信息执行操作。

预言机的主要功能包括:

  • 数据传输:将外部数据(如金融市场价格、天气信息或体育结果)传输到区块链。
  • 数据验证:确保传输的数据准确可靠。
  • 触发智能合约:根据外部数据的变化激活智能合约的执行。

2.1 公共数据预言机

公共数据指的是可以自由访问并可用于使用的信息。

加密生态系统已通过 ChainlinkPyth NetworkSupraUMATellorRedstone 等预言机成功地桥接了 Web2 公共数据。公共数据对于通过提供透明度和实现自动化来推动区块链上的 DeFi 至关重要。没有这些数据源,去中心化金融的能力将受到极大限制。

由于数据源是公共的,这一类预言机称为 公共数据预言机

然而,它们仅代表潜力的一小部分:

在 Web3 中,私有数据仍然难以访问,给消费者应用程序和现实用例的发展与采用带来重大障碍。我们认为未来的互联网应该超越 DeFi 在金融等领域的主导地位,并使更多有影响力的应用得以实现。

2.2 私有数据预言机

私有数据指需要授权才能访问的受保护信息。

将私有数据视为你生活的个人日记——它是专为你量身定制的。这包括识别你身份或揭示你生活亲密细节的数据,例如你的社会安全号码、银行账户信息、健康记录或其他独特的个人信息。虽然公共数据驱动着信息决策、透明以及研究,但私有数据——在遵循尊重和法律保护的情况下处理——可以释放个性化服务的潜力,同时保护个人隐私。

在数十年的 Web2 发展中,私有数据已经成为我们时代的新 数字石油

真正的改变者在于如何释放私有数据——这些丰富、敏感的信息。当安全地访问(使用赋予用户控制权、信任和隐私的加密方法)时,私有数据有潜力彻底改变下一波消费者应用的浪潮。

zkTLS 是解锁私有数据的钥匙。

3. TLS

要理解 zkTLS,我们首先需要探讨 TLS 协议——互联网的基础性技术,绝大多数人每天都在使用,常常是毫无意识的。

还记得互联网的“要塞”吗?连接用户与这些要塞的路径主要基于 HTTPS 协议(超文本传输安全协议)。虽然你可能不熟悉技术细节,但你肯定在浏览器的地址栏中输入过类似 https://www.123.com 的内容。那就是 HTTPS——一种使你的浏览器能够与互联网平台交互的协议。

TLS 是什么?

TLS(传输层安全性)是 HTTPS 的核心部分,在 OSI 协议模型中运行在一层更深的位置。TLS 通过加密、身份验证和完整性保护确保数据传输过程中的机密性和完整性,以防止数据盗窃或篡改。它是支撑当今互联网的基础和成熟的技术之一。

你无需深入技术细节即可理解其作用——这类似于在通往要塞的路径上部署岗哨。当它们的密码(握手)匹配时,它们确保你与要塞之间的信息安全传递。

传统 TLS 的局限性

TLS 本质上是一种双方协议,旨在建立客户端与服务器之间的安全连接。在传统 TLS 中,只有这两方之间的数据的完整性和隐私得到保证。然而,这些类似要塞的服务器高度受到保护,通常不愿与第三方共享用户数据,导致数据孤岛的形成。

即使数据源愿意向第三方提供其数据资产,标准的双方 TLS 协议也很难向他人提供这些数据的完整性和真实性的证明。简单地将服务器的 HTTPS 响应转发给第三方并不令人信服,因为客户端可以轻易在本地篡改数据。此外,完全转发此类回应会将其完全暴露给第三方,危及用户隐私——这是任何用户都不想要的。

挑战

因此,关键挑战在于找到一种方法,以证明任何第三方的数据的 完整性和真实性,同时保护 隐私。实现这一点需要克服技术和信任方面的障碍,这正是 zkTLS 介入并提供解决方案的地方。

3.1 RFC9421

RFC9421 试图解决这一挑战,但在实施上面临重要障碍。该方案需要对多个参与方进行协调,包括权威机构的证书颁发和对客户端及数据源服务器的同步修改。这种广泛各方的参与使得现实世界的部署极为具有挑战性。

RFC 9421 的逻辑局限性

从逻辑上讲,RFC 9421 的设计哲学与现有数据交互系统的实际需求并不一致,使其显得有些冗余。数据源没有义务向第三方证明数据的来源。其责任仅限于直接请求者,确保所提供数据的完整性和真实性。

如果第三方需要验证数据来源,那完全是他们自己的需求,与数据源无关。当用户从数据源检索信息并选择将其“转发”给第三方时,这这是用户的个人选择。数据源不被要求支持这种间接关系,更不要说承担额外费用来为其提供证明。

缺乏采用和前景黯淡

迄今为止,没有任何大公司宣布支持 RFC 9421,也没有公司暗示将来会采纳该计划。该协议的应用前景极其有限。实际上,我们悲观地认为,在我们这一生中,它不太可能真正获得现实世界的采用。

3.2 OAuth

下一个挑战是 OAuth,这是一个建立良好并且成熟的解决方案。你无需深入其技术细节,因为你在使用 Google 账户登录其他网站时,可能已亲历过 OAuth 的实际应用。

OAuth 如何满足数据验证需求

当第三方需要验证数据的来源时,OAuth 在很大程度上可以满足这些需求:

  • 授权和验证:OAuth 允许数据源授权第三方直接访问数据,确保数据来源的可信度。
  • 简单和高效:凭借高度成熟的生态系统,OAuth 得到广泛支持并提供良好的兼容性,使其相比引入新的协议而言采用成本低得多。
  • 商业化潜力:除了处理验证问题,OAuth 还使数据源能够收费,创造收入机会。

OAuth 的局限性

然而,OAuth 也并非没有缺陷。除了需要身份提供者支持它之外,数据源所需的适应和修改,以及与其相关的高服务费用,受支持的数据源范围有限尤其突显其最大瓶颈:

根据 StatistaWebsiteSetup 的权威数据,目前只有数万款应用和网站支持 OAuth。同时,数十亿个有价值的私有数据源要么不支持 OAuth,要么对此并不感兴趣。

那么,是否存在一种解决方案:

  1. 能与绝大多数 Web2 数据源兼容,
  2. 可不需要数据源方面的适应或修改,
  3. 确保数据的 隐私完整性真实性

这种解决方案正是 zkTLS 所旨在提供的——一种创新协议,克服这些局限性,释放私有数据的潜力,而无需数据源的参与或损害隐私。

3.3 MPC-TLS

成立于 2013 年的非营利项目 TLSNotary 引入了一种新颖的方法来解决这一问题:MPC-TLS。该方法使用 安全的多方计算(MPC) 在 TLS 连接中添加验证者。通过 MPC 提供的加密保障,验证者可以在无需外部信任及完全暴露数据的情况下验证 TLS 记录。

我们相信,TLSNotary 的最大贡献在于其成功地设计和开源了使用 MPC 技术引入第三方 公证人/验证者 的概念,特别是使用 Garbled Circuits。这一创新为随后的 zkTLS 开发奠定了基础,推动了保护隐私和可验证数据解决方案的可能性。

4. zkTLS

zkTLS(零知识传输层安全)是一个多方协议(通常涉及三个方),建立了 Web2 私有数据与 Web3 生态系统之间的门户。zkTLS 是一个混合协议,将 ZKP(零知识证明)TLS 加密系统 集成,使数据在 Web2 和 Web3 之间安全传输的同时保持隐私。它允许用户安全地从任何网站提取数据,而不会泄漏不必要的信息。

zkTLS 的关键组成部分

顾名思义,zkTLS 集成并兼容两种主要技术:

  1. TLS(传输层安全性)

TLS 是一种加密协议,为互联网的安全网页通信奠定基础。它被广泛用于安全浏览数据和加密在浏览器与网络服务器之间传输的信息。

  1. ZK(零知识证明)

ZKP 使证明者能够向验证者证明信息的有效性,而无需揭示信息的实际内容,确保数据隐私。

构建 zkTLS 协议:两个基本步骤

1. 建立一个具有公证安全性和完整性的 TLS 会话

这涉及创建一个以标准 TLS 要求为基础的多方 TLS 会话协议,同时启用公证。多方 TLS 会话可以采用以下方法构筑:

  • 可信执行环境(TEE)
  • 安全多方计算(MPC)
  • 基于代理的模型

2. 为 TLS 会话生成零知识证明

这一步通过将 TLS 会话转换为零知识证明来确保数据隐私。这可以通过多种零知识算法实现,包括 交互式非交互式零知识证明

基于参与者和 ZK 类型的分类

zkTLS 的区别可以大致根据以下几点分类:

  • 在 TLS 会话中涉及的各方,和
  • 适用的零知识证明类型。

这一框架允许实现的灵活性,同时保持安全性、隐私和互操作性的核心原则。

4.1 TEE 模型

4.1.1 介绍

可信执行环境(TEE)并不是一种新技术;它在传统计算中已经存在了几十年。TEE 是现代 CPU 的一个专门的、几乎防篡改的组件,设计用于在 enclave 内安全地执行敏感计算,确保其处理的数据和代码的完整性和保密性。TEE 可以保护敏感操作,例如用户身份验证、数据解密或加密签名,即使系统的其他部分被攻陷。这种隔离使无人监管的计算变得安全,不会将敏感信息暴露给服务提供商或外部方,使其成为隐私重要的过程中理想的选择。

在基于 TEE 的模型中,证明者将从服务器获取的原始数据值传递给 TEE。TEE 在 enclave 内验证消息内容、执行身份验证并对信息进行加密(创建网络证明),随后直接将其传输到请求验证的第三方协议。这种模型确保了网站响应的真实性。

在基于 TEE 的 zkTLS 设置中,TEE 安全地运行协议,提供 TLS 会话执行及其内容的证明。在这里,验证者就是 TEE 本身,这意味着系统的信任模型依赖于 TEE 厂商或服务提供商的声誉以及 TEE 对物理或旁路攻击的抵抗能力。对于愿意接受 TEE 固有信任和安全风险的用户来说,zkTLS 的这一方法是高效的,具有极小的计算和网络开销。

4.1.2 信任假设

  • 依赖于硬件提供者的信任。
  • 接受潜在旁路攻击带来的风险。

4.1.3 优势

  • 无需第三方公证人或代理来验证数据。
  • 网络开销最小。

4.1.4 缺点

  • 对硬件的高度依赖,降低灵活性并使系统暴露于硬件特定的漏洞。
  • 在不同设备上的可用性受限,这可能阻碍采用。

4.1.5 关键采用者

Town Crier: 由 IC3 于2017年创建,并于2018年被Chainlink收购,Town Crier 是第一个由 TEE 支持的预言机。像 Town Crier 这样的程序运行在 enclave 内,确保:

  • 完整性:攻击者无法篡改 enclave 内的代码,保证了预言机的诚实性。
  • 保密性:攻击者无法访问 enclave 内的内容。

Clique: 一种名为 TEE-TLS 的协议,使客户能够通过智能合约安全且可验证地直接调用离线 TLS 会话, 进行全链条的交互。对于密钥和 OAuth Token等敏感数据,确保了整个过程的完全隐私。

4.1.6 总结

TEE 是加密领域中一个相对欠发达的领域,大部分研究仍处于实验阶段。对硬件的重度依赖为客户端应用程序的大规模采用带来了挑战。这种依赖,加上设备的兼容性有限,可能限制其更广泛的应用。

4.2 MPC 模型

4.2.1 介绍

为了证明 TLS 会话,客户端公证人 连接,双方一起使用 安全多方计算(MPC) 生成一个共享公钥,然后将其发送给 服务器。此密钥在 TLS 握手期间用于创建 预主密钥,随后生成 会话密钥

会话密钥随后分割为两个部分:一部分由客户端持有,另一部分由公证人持有。实际上,公证人与客户端联合组成一个单一的“超级客户端”,遵循标准 TLS 协议与服务器进行加密通信。

从服务器的角度,这一过程是完全透明的,无需修改或适应——这一重要优点避免了对服务器施加额外的需求。

在会话结束时,客户端 创建对明文数据的经过身份验证的承诺。公证人 验证此承诺,然后在未见到实际数据的情况下签名。一旦这一步完成,客户端可以生成一个 ZK 证明,仅泄露必要的信息。

4.2.2 信任假设

  • 假设证明者不与第三方公证人/验证者串通。

4.2.3 优势

  • 不存在被服务器封锁 IP 的风险:服务器与其所认知的单一客户端连接,因此避免了封锁特定 IP 地址的可能性。

4.2.4 缺点

  • 延迟敏感性MPC 的执行时间对网络延迟非常敏感。即使是轻微的延迟增加,也可能对 MPC 完成所需的总时间产生显著影响,从而导致证明生成的不一致性。
  • 数据大小限制:在 MPC 期间,计算工作量和交换数据的体量随着待证明数据的大小显著增加。
  • 高性能开销:这主要是由于 Garbled Circuit 中的 真值表。每个应用数据块必须使用真值表进行加密,极大地增加了计算和带宽需求。
  • 固定成本:对于单个 TLS 会话,有固定成本 20MB
  • 附加成本:每输出 1KB 数据需额外 8MB;每输入 1KB 数据需额外 32KB
  • 示例:对于典型的 1KB 请求100KB 响应,证明者需要大约 32MB 的上传,这使该方法在常规使用中显得不切实际。

4.2.5 关键采用者

TLSNotary(前面介绍过的)和 DECO 代表了在推动基于 TLS 的验证方面的重要里程碑。

IC3 的学生和教职员工于2020年创建的 DECO 建立在 TLSNotary基础上。同年被 Chainlink 收购。

DECO 通过整合 零知识证明(ZKP),特别是 zk-SNARKs(如其 研究论文 所述),增强了 TLSNotary 的方法。此项添加使用户能够证明通过 TLS 访问的特定数据源于指定网站。

独特的是,DECO 还允许用户使用 ZKPs 对数据做出选择性声明——证明数据的陈述而无需揭示数据本身。这确保了基础信息的机密性,同时提供其真实性的密码保障。

4.2.6 总结

该模型的资源需求不切实际,严重限制了其在现实场景中的应用。然而,在服务器阻止来自不同 IP 地址的同一账户的多次请求的情况下,这一模型可有效解决这一挑战。

4.3 代理模型

4.3.1 介绍

zkTLS 中的 代理模型 利用浏览器的代理功能。客户在打开网站时,通过 HTTPS 代理发送请求,而不是直接发送到网站。

代理 充当客户端与服务器之间的中介,验证期间通信中交换的加密数据。它并不充当中间人(MitM),因为它只能访问加密数据。

会话完成后,客户端共享一部分会话密钥,仅解密请求中的 非敏感部分。然后客户端为响应数据生成 ZKP,使代理和其他方能够在不暴露敏感信息的情况下验证 TLS 会话的内容。

代理 提供了加密请求和响应的证明,以及指示每个数据片段是否源自浏览器或网站的信息。这有效证明了加密数据是浏览器还是服务器发送的。随后,浏览器为解密响应生成一个 ZK 证明

4.3.2 信任假设

  • 假设证明者不与第三方代理串通。

4.3.3 优势

  • 与 MPC 模型相比,延迟更低,更适合大规模实时客户端应用程序。

4.3.4 缺点

  1. 潜在瓶颈:过载代理服务器可能导致性能问题。
  2. 代理被禁用的风险:服务器可能会封锁通过代理转发的请求。
  3. 高性能 ZK 挑战
  • 在客户端实现高性能 ZK 电路(例如使用 Circom)在处理大尺寸输入时的挑战。
  • 网站响应通常超过 2KB,保守估计需进行 8 次 AES 解密。即使只需 1 次 AES 解密,使用 Circom 进行的测试显示大约需要 5 秒 的证明时间,这将严重影响客户端的用户体验。

4.3.5 关键采用者

Reclaim 协议,由最初的 Questbook 团队于 2023 年开发,支持该模型。该协议使用 HTTP 代理 观察握手和数据传输。具体来说,它验证:

  1. 握手是否使用正确的域名完成。
  2. 访问请求中是否访问了正确的网址。
  3. 获取的响应是否加密。

加密响应随后由在客户端完全运行的 zk-SNARK 电路处理。 AES/ChaCha20 在 ZK 电路中进行解密,并对解密后的 HTML 页面进行搜索。

4.3.6 总结

大多数服务器不阻止不同 IP 的访问,使得该方法具有相对广泛的应用潜力。为了更好地与客户端应用程序兼容,低开销的代理模型需要 内存高效的 ZK 算法,考虑到浏览器的严格内存限制。

4.4 混合模式

4.4.1 介绍

丰富的客户端和数据源意味着没有单一模型能够做到实规模商业采用所需的广泛兼容性。这一挑战催生了 混合模式,可被视为 “高性能” MPC 模型“内存高效” 代理模型 的结合。

混合模式的关键特性包括:

  1. 动态模式切换

根据数据源的各种特性(例如网络环境和服务器策略),通过动态切换模型以确保最大兼容性和最佳客户端体验。

  1. ZK 工程平衡
  • 从交互式零知识证明中结合 内存效率(处理浏览器严格内存限制的大请求)。
  • 包含非交互式零知识证明的 公开可验证性(无需实时验证者可用即可进行链上验证)。

4.4.2 信任假设

  • 继承了现有模型(MPC 和代理)的安全假设。

4.4.3 优势

  • 灵活和适应性强:能够在各种数据源之间动态切换,增强了兼容性。
  • 增强客户端体验:通过针对不同场景调整方法,以确保最佳的用户体验。

4.4.4 缺点

  • 高工程复杂性:实施在技术上要求高,需要较长的开发时间线。

4.4.5 关键采用者

zkPassMPC 模型代理模型 两者中开创了创新:

2022 年 — 优化 MPC 模型

  1. 通过优化通信时间、Garbler/Evaluator 过程、OT 哈希函数和内存复制操作,实现了超过 3 倍的效率提升
  2. 引入了一种新的 AES128 证明方法,将块计数减少了 300 倍,并将 Garbler/Evaluator 执行时间提高了 10 倍
  3. 关键改进:
  • Silent OT: 显著降低了 OT 操作的离线网络通信。
  • Stacked GC:最小化了 Garbled Circuits 的大小,减少了在线通信和执行时间。

这些优化显著缩短了整个 MPC 过程的运行时间。

2023 年 — 推进混合模型

  • 引入 VOLEitH 技术,带来 ZK 算法的革命。
  • 将 VOLE-ZK 协议转变为 非交互格式,使其能够在浏览器和设备中实现快速高效的证明生成。
  • 解决传统 SNARK 的关键限制(高计算和内存需求)及 VOLE-ZK(缺乏公开可验证性)。

4.4.6 总结

混合模式在 代理模型MPC 模型 之间无缝切换,使协议能够根据不同的网络环境和服务器策略进行改进,而无须牺牲效率或安全性。代理模型在最大限度保持加密开销的同时提供高性能,而在服务器阻止来自多个 IP 地址的请求的情况下,由 MPC 模型接管以确保隐私和安全。这使得其成为 zkTLS 应用的最佳实践,平衡通信效率与客户端计算资源。

5. 用例

在数字时代,可验证数据无处不在,涵盖了 Web3 领域,如 DeFi、DAO 和 NFT,也涵盖了 Web2 领域,如银行、电子商务、教育、医疗保健、物联网设备和社交网络。zkTLS 正在为更加安全、私密和可靠的数字生态系统铺平道路。在这一框架中,隐私和安全不再是奢侈品,而是所有人的基本权利。

5.1 总体目标

可验证数据可以被分为四个关键目标:

  1. 凭证:向任何第三方证明私有数据。
  2. 数据完整性:提升数据的准确性和可靠性。
  3. 数据可移植性:无缝地在平台之间传输私有数据。
  4. 数据资产:将数据作为资产进行货币化。

5.1.1 凭证

  • 扩展空投标准:zkTLS 将空投的资格扩展到超越链上活动,结合用户在传统互联网平台上的行为,克服了常规空投的限制。
  • 抵抗 Sybil 攻击:有效对抗机器人和 Sybil 攻击,允许项目奖励忠实社区用户,而非机会主义获利者。
  • 链上信用评分:解决链上借贷中全面信用评分缺乏的问题,降低抵押要求,使基于风险的利率模型成为可能。
  • 动态定价模型:电子商务平台可以利用可验证的购买历史提供定制的折扣,吸引高价值客户并促进良性竞争。
  • 自动化验证:取代传统的手动验证方法,如截图验证,在验证招聘过程中的申请人信息时,提高庭产效率。

5.1.2 数据完整性

  • 数据质量控制:在 AI 时代,高质量数据至关重要。zkTLS 简化操作,同时为训练模型保证数据集的完整性。
  • 人类证明:使用可验证数据区分人类与机器人,增强平台安全性。
  • 自主性证明:可验证的数据可以确认某一观点是否源自特定的 AI 代理。
  • 筛选虚假评论:zkTLS 验证评论者确实使用过产品,从而打击恶意评论,增强平台的信誉。
  • DePIN 收入验证:改善去中心化能源交易或碳信用发放的透明度和信任,而不依赖中心化提供者。

5.1.3 数据可移植性

  • 拼车数据迁移:zkTLS 允许将拼车历史从平台 A 无缝转移到平台 B,使新用户立即获得信誉和折扣。
  • 社交图谱导入:社交媒体平台可以使用 zkTLS 从其他网络导入用户的社交关系。
  • 声誉可移动性:新平台可以整合用户从其他生态系统累计的声誉和关注者,加速采用。

5.1.4 数据资产

  • 私有数据池:随着公共数据集的耗竭,AI 开发者需要多样化和个性化的数据。zkTLS 允许验证私有数据集的真实性,而不损害隐私。
  • 数据货币化:zkTLS 使安全数据共享成为可能,为个人化的优惠和折扣创造双赢场景。

5.2 应用场景

可验证数据使各种领域的用例成为可能,包括:

  1. zkKYC:身份验证,但不泄露敏感的个人信息。
  2. 金融(DeFi 与 CeFi):将 Web2 财务信息集成至 Web3 生态系统。
  3. 治理和投票:保护隐私的治理与投票解决方案。
  4. 游戏:为玩家和开发者提供多维度的数据。
  5. 医疗和健康:患者和服务提供商之间的安全私密互动。
  6. 社交网络:增强数据管理和合规性。
  7. 教育和研究:为学生和机构提供安全且私密的凭证验证。
  8. 经历验证:用于招聘的可验证背景审查。

5.2.1 zkKYC

  • 租户验证:物业经理可以在不接触敏感信息的情况下验证租户身份和信用。
  • 游戏年龄验证:确保符合年龄限制,而不暴露个人数据。
  • 社交媒体真实性:减少假账户,同时保持用户隐私。
  • 临时经济凭证:有效验证自由职业者的身份和资格。

5.2.2 金融(DeFi 与 CeFi)

  • 安全认证:zkTLS 为 DeFi 平台提供保护私密的认证,减少欺诈并增强信任。
  • 信用验证:借贷平台可以在不暴露敏感数据的情况下验证借款人的信用状况,使高信用用户获得更低的利率。
  • 索赔处理:保险公司可以安全且私密地验证索赔。
  • 透明捐赠:慈善机构可以在不妨碍隐私的情况下验证捐赠人身份和追踪捐赠。
  • 众筹:安全验证项目创作者和支持者,从而增强信任。

5.2.3 治理与投票

  • 保护隐私的投票:投票者可以在不透露身份的情况下证明合格。
  • 安全公共服务访问:公民可以在不泄露个人详细信息的情况下验证居住或公民身份以获取服务。
  • 简化移民流程:通过隐私保护的身份验证简化签证处理。
  • 股东投票:实现股东决策的安全和匿名。

5.2.4 游戏

  • 选择性数据共享:玩家可以展示成就,同时保护私密细节。
  • 通用游戏通行证:zkTLS 让玩家在多个游戏中无缝登录,同时保持对身份数据的控制。
  • 成就可迁移性:让玩家在生态系统间显示成就,形成统一的游戏声誉。

5.2.5 医疗和健康

  • 安全健康记录访问:使患者和提供商之间的隐私保护互动成为可能。
  • 远程医疗:为虚拟咨询验证身份,同时保障数据安全。
  • 临床试验:在确保研究透明度的同时保护参与者数据。
  • 全球护理协调:促进跨境健康数据共享的安全。

5.2.6 社交网络

  • 去中心化应用:zkTLS 通过让用户选择性披露个人信息增强用户信任。
  • 私密消息传递:提供详细的隐私控件,例如隐藏在线状态或已读回执。

5.2.7 教育和研究

  • 凭证验证:简化和安全验证学术成就。
  • 学术诚信:防止在线考试中的作弊,并促进安全的研究合作。
  • 基于区块链的凭证:确保跨国教育和研究合规数据保护规定的顺利实施。

5.2.8 经历验证

  • 就业验证:雇主可以在不暴露敏感信息的前提下确认候选人的凭证。
  • 透明招聘:在工作平台上实现互相透明的同时保护隐私。

5.2.9 AI 数据标注

  • 安全的数据标注:zkTLS 确保标注数据集是可靠且私密的,保护贡献者的敏感信息。
  • 协作策展:使标注数据集的汇聚成为可能,而无须直接共享数据,促进安全合作。
  • 公平奖励:验证数据质量,以公平补偿贡献者,同时保持隐私。
  • 高质量模型:确保训练数据的完整性,减少偏见,提升 AI 性能。

6. 结论

在 Web2 时代,大多数数据已经被聚合,现在只需要重新分配。zkTLS 使这一切成为可能,通过 无信任选择性分发 提供服务。

作为 可验证网络 的核心基础设施,zkTLS 在 Web2 和 Web3 之间架起了桥梁。它为链上数据的繁荣播下了种子,并打开了前所未有的应用大门。zkTLS 正在重新塑造各行业,并重新定义数字时代的信任。

zkPass 链接:

网站 | 推特 | Discord | Medium | Github | 门户

  • 原文链接: medium.com/zkpass/zktls-...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
zkPass
zkPass
江湖只有他的大名,没有他的介绍。