本文介绍了zkTLS作为可验证互联网的基石,强调了其在保护用户隐私、确保数据真实性以及促进Web2与Web3之间的连接方面的重要性。文章详细阐述了传统TLS的局限性,并通过zkTLS的三个模型(TEE、MPC和Proxy)展示了如何安全地交换私有数据,最终推动了多个行业的数字化转型。
可验证网络代表了互联网的新范式,使用户能够以去中心化的方式验证网络数据的来源和真实性。其核心是 zkTLS 基础设施,这是一种突破性的机制,用于加密验证通过 HTTPS 交换的任何数据——释放了可验证网络的真正潜力。
当今的互联网类似于一张庞大的“要塞”网络——各种由中心化实体控制的在线平台。这些要塞决定规则,并决定信息是否可以在平台之间流动。为了访问服务,用户往往必须将个人数据交给这些平台,即使其中涉及敏感的私人信息。
然而,这些数据的命运大多是不透明的。平台可能会在没有明确披露或明确同意的情况下,将用户数据分享给监管机构或第三方。这些第三方如何使用数据更难以追踪。许多人亲身经历过此类泄露的烦人结果——未经请求的推销电话往往是个人数据被滥用的直接结果。
区块链技术在建立数据所有权方面具有固有优势,但链上数据的数量仍然有限,相较于传统互联网系统。去中心化应用(dApps)在访问现实世界数据时面临重大障碍,因为数据孤岛严重限制了它们的发展潜力,并限制了区块链创新的范围。
预言机作为加密世界与现实世界之间的桥梁,使去中心化技术得以重要推动。
在区块链系统中,预言机是将外部数据带入区块链智能合约的服务。由于区块链本身无法访问链外数据,预言机充当区块链与外部世界之间的桥梁,使智能合约能够根据外部信息执行操作。
预言机的主要功能包括:
公共数据指的是可以自由访问并可用于使用的信息。
加密生态系统已通过 Chainlink、Pyth Network、Supra、UMA、Tellor 和 Redstone 等预言机成功地桥接了 Web2 公共数据。公共数据对于通过提供透明度和实现自动化来推动区块链上的 DeFi 至关重要。没有这些数据源,去中心化金融的能力将受到极大限制。
由于数据源是公共的,这一类预言机称为 公共数据预言机。
然而,它们仅代表潜力的一小部分:
在 Web3 中,私有数据仍然难以访问,给消费者应用程序和现实用例的发展与采用带来重大障碍。我们认为未来的互联网应该超越 DeFi 在金融等领域的主导地位,并使更多有影响力的应用得以实现。
私有数据指需要授权才能访问的受保护信息。
将私有数据视为你生活的个人日记——它是专为你量身定制的。这包括识别你身份或揭示你生活亲密细节的数据,例如你的社会安全号码、银行账户信息、健康记录或其他独特的个人信息。虽然公共数据驱动着信息决策、透明以及研究,但私有数据——在遵循尊重和法律保护的情况下处理——可以释放个性化服务的潜力,同时保护个人隐私。
在数十年的 Web2 发展中,私有数据已经成为我们时代的新 数字石油。
真正的改变者在于如何释放私有数据——这些丰富、敏感的信息。当安全地访问(使用赋予用户控制权、信任和隐私的加密方法)时,私有数据有潜力彻底改变下一波消费者应用的浪潮。
zkTLS 是解锁私有数据的钥匙。
要理解 zkTLS,我们首先需要探讨 TLS 协议——互联网的基础性技术,绝大多数人每天都在使用,常常是毫无意识的。
还记得互联网的“要塞”吗?连接用户与这些要塞的路径主要基于 HTTPS 协议(超文本传输安全协议)。虽然你可能不熟悉技术细节,但你肯定在浏览器的地址栏中输入过类似 https://www.123.com 的内容。那就是 HTTPS——一种使你的浏览器能够与互联网平台交互的协议。
TLS 是什么?
TLS(传输层安全性)是 HTTPS 的核心部分,在 OSI 协议模型中运行在一层更深的位置。TLS 通过加密、身份验证和完整性保护确保数据传输过程中的机密性和完整性,以防止数据盗窃或篡改。它是支撑当今互联网的基础和成熟的技术之一。
你无需深入技术细节即可理解其作用——这类似于在通往要塞的路径上部署岗哨。当它们的密码(握手)匹配时,它们确保你与要塞之间的信息安全传递。
传统 TLS 的局限性
TLS 本质上是一种双方协议,旨在建立客户端与服务器之间的安全连接。在传统 TLS 中,只有这两方之间的数据的完整性和隐私得到保证。然而,这些类似要塞的服务器高度受到保护,通常不愿与第三方共享用户数据,导致数据孤岛的形成。
即使数据源愿意向第三方提供其数据资产,标准的双方 TLS 协议也很难向他人提供这些数据的完整性和真实性的证明。简单地将服务器的 HTTPS 响应转发给第三方并不令人信服,因为客户端可以轻易在本地篡改数据。此外,完全转发此类回应会将其完全暴露给第三方,危及用户隐私——这是任何用户都不想要的。
挑战
因此,关键挑战在于找到一种方法,以证明任何第三方的数据的 完整性和真实性,同时保护 隐私。实现这一点需要克服技术和信任方面的障碍,这正是 zkTLS 介入并提供解决方案的地方。
RFC9421 试图解决这一挑战,但在实施上面临重要障碍。该方案需要对多个参与方进行协调,包括权威机构的证书颁发和对客户端及数据源服务器的同步修改。这种广泛各方的参与使得现实世界的部署极为具有挑战性。
RFC 9421 的逻辑局限性
从逻辑上讲,RFC 9421 的设计哲学与现有数据交互系统的实际需求并不一致,使其显得有些冗余。数据源没有义务向第三方证明数据的来源。其责任仅限于直接请求者,确保所提供数据的完整性和真实性。
如果第三方需要验证数据来源,那完全是他们自己的需求,与数据源无关。当用户从数据源检索信息并选择将其“转发”给第三方时,这这是用户的个人选择。数据源不被要求支持这种间接关系,更不要说承担额外费用来为其提供证明。
缺乏采用和前景黯淡
迄今为止,没有任何大公司宣布支持 RFC 9421,也没有公司暗示将来会采纳该计划。该协议的应用前景极其有限。实际上,我们悲观地认为,在我们这一生中,它不太可能真正获得现实世界的采用。
下一个挑战是 OAuth,这是一个建立良好并且成熟的解决方案。你无需深入其技术细节,因为你在使用 Google 账户登录其他网站时,可能已亲历过 OAuth 的实际应用。
OAuth 如何满足数据验证需求
当第三方需要验证数据的来源时,OAuth 在很大程度上可以满足这些需求:
OAuth 的局限性
然而,OAuth 也并非没有缺陷。除了需要身份提供者支持它之外,数据源所需的适应和修改,以及与其相关的高服务费用,受支持的数据源范围有限尤其突显其最大瓶颈:
根据 Statista 和 WebsiteSetup 的权威数据,目前只有数万款应用和网站支持 OAuth。同时,数十亿个有价值的私有数据源要么不支持 OAuth,要么对此并不感兴趣。
那么,是否存在一种解决方案:
这种解决方案正是 zkTLS 所旨在提供的——一种创新协议,克服这些局限性,释放私有数据的潜力,而无需数据源的参与或损害隐私。
成立于 2013 年的非营利项目 TLSNotary 引入了一种新颖的方法来解决这一问题:MPC-TLS。该方法使用 安全的多方计算(MPC) 在 TLS 连接中添加验证者。通过 MPC 提供的加密保障,验证者可以在无需外部信任及完全暴露数据的情况下验证 TLS 记录。
我们相信,TLSNotary 的最大贡献在于其成功地设计和开源了使用 MPC 技术引入第三方 公证人/验证者 的概念,特别是使用 Garbled Circuits。这一创新为随后的 zkTLS 开发奠定了基础,推动了保护隐私和可验证数据解决方案的可能性。
zkTLS(零知识传输层安全)是一个多方协议(通常涉及三个方),建立了 Web2 私有数据与 Web3 生态系统之间的门户。zkTLS 是一个混合协议,将 ZKP(零知识证明) 与 TLS 加密系统 集成,使数据在 Web2 和 Web3 之间安全传输的同时保持隐私。它允许用户安全地从任何网站提取数据,而不会泄漏不必要的信息。
zkTLS 的关键组成部分
顾名思义,zkTLS 集成并兼容两种主要技术:
TLS 是一种加密协议,为互联网的安全网页通信奠定基础。它被广泛用于安全浏览数据和加密在浏览器与网络服务器之间传输的信息。
ZKP 使证明者能够向验证者证明信息的有效性,而无需揭示信息的实际内容,确保数据隐私。
构建 zkTLS 协议:两个基本步骤
1. 建立一个具有公证安全性和完整性的 TLS 会话:
这涉及创建一个以标准 TLS 要求为基础的多方 TLS 会话协议,同时启用公证。多方 TLS 会话可以采用以下方法构筑:
2. 为 TLS 会话生成零知识证明:
这一步通过将 TLS 会话转换为零知识证明来确保数据隐私。这可以通过多种零知识算法实现,包括 交互式 或 非交互式零知识证明。
基于参与者和 ZK 类型的分类
zkTLS 的区别可以大致根据以下几点分类:
这一框架允许实现的灵活性,同时保持安全性、隐私和互操作性的核心原则。
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 内,确保:
Clique: 一种名为 TEE-TLS 的协议,使客户能够通过智能合约安全且可验证地直接调用离线 TLS 会话, 进行全链条的交互。对于密钥和 OAuth Token等敏感数据,确保了整个过程的完全隐私。
4.1.6 总结
TEE 是加密领域中一个相对欠发达的领域,大部分研究仍处于实验阶段。对硬件的重度依赖为客户端应用程序的大规模采用带来了挑战。这种依赖,加上设备的兼容性有限,可能限制其更广泛的应用。
4.2.1 介绍
为了证明 TLS 会话,客户端 与 公证人 连接,双方一起使用 安全多方计算(MPC) 生成一个共享公钥,然后将其发送给 服务器。此密钥在 TLS 握手期间用于创建 预主密钥,随后生成 会话密钥。
会话密钥随后分割为两个部分:一部分由客户端持有,另一部分由公证人持有。实际上,公证人与客户端联合组成一个单一的“超级客户端”,遵循标准 TLS 协议与服务器进行加密通信。
从服务器的角度,这一过程是完全透明的,无需修改或适应——这一重要优点避免了对服务器施加额外的需求。
在会话结束时,客户端 创建对明文数据的经过身份验证的承诺。公证人 验证此承诺,然后在未见到实际数据的情况下签名。一旦这一步完成,客户端可以生成一个 ZK 证明,仅泄露必要的信息。
4.2.2 信任假设
4.2.3 优势
4.2.4 缺点
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.1 介绍
zkTLS 中的 代理模型 利用浏览器的代理功能。客户在打开网站时,通过 HTTPS 代理发送请求,而不是直接发送到网站。
代理 充当客户端与服务器之间的中介,验证期间通信中交换的加密数据。它并不充当中间人(MitM),因为它只能访问加密数据。
会话完成后,客户端共享一部分会话密钥,仅解密请求中的 非敏感部分。然后客户端为响应数据生成 ZKP,使代理和其他方能够在不暴露敏感信息的情况下验证 TLS 会话的内容。
代理 提供了加密请求和响应的证明,以及指示每个数据片段是否源自浏览器或网站的信息。这有效证明了加密数据是浏览器还是服务器发送的。随后,浏览器为解密响应生成一个 ZK 证明。
4.3.2 信任假设
4.3.3 优势
4.3.4 缺点
4.3.5 关键采用者
Reclaim 协议,由最初的 Questbook 团队于 2023 年开发,支持该模型。该协议使用 HTTP 代理 观察握手和数据传输。具体来说,它验证:
加密响应随后由在客户端完全运行的 zk-SNARK 电路处理。 AES/ChaCha20 在 ZK 电路中进行解密,并对解密后的 HTML 页面进行搜索。
4.3.6 总结
大多数服务器不阻止不同 IP 的访问,使得该方法具有相对广泛的应用潜力。为了更好地与客户端应用程序兼容,低开销的代理模型需要 内存高效的 ZK 算法,考虑到浏览器的严格内存限制。
4.4.1 介绍
丰富的客户端和数据源意味着没有单一模型能够做到实规模商业采用所需的广泛兼容性。这一挑战催生了 混合模式,可被视为 “高性能” MPC 模型 和 “内存高效” 代理模型 的结合。
混合模式的关键特性包括:
根据数据源的各种特性(例如网络环境和服务器策略),通过动态切换模型以确保最大兼容性和最佳客户端体验。
4.4.2 信任假设
4.4.3 优势
4.4.4 缺点
4.4.5 关键采用者
zkPass 在 MPC 模型 和 代理模型 两者中开创了创新:
2022 年 — 优化 MPC 模型:
这些优化显著缩短了整个 MPC 过程的运行时间。
2023 年 — 推进混合模型:
4.4.6 总结
混合模式在 代理模型 和 MPC 模型 之间无缝切换,使协议能够根据不同的网络环境和服务器策略进行改进,而无须牺牲效率或安全性。代理模型在最大限度保持加密开销的同时提供高性能,而在服务器阻止来自多个 IP 地址的请求的情况下,由 MPC 模型接管以确保隐私和安全。这使得其成为 zkTLS 应用的最佳实践,平衡通信效率与客户端计算资源。
在数字时代,可验证数据无处不在,涵盖了 Web3 领域,如 DeFi、DAO 和 NFT,也涵盖了 Web2 领域,如银行、电子商务、教育、医疗保健、物联网设备和社交网络。zkTLS 正在为更加安全、私密和可靠的数字生态系统铺平道路。在这一框架中,隐私和安全不再是奢侈品,而是所有人的基本权利。
可验证数据可以被分为四个关键目标:
5.1.1 凭证
5.1.2 数据完整性
5.1.3 数据可移植性
5.1.4 数据资产
可验证数据使各种领域的用例成为可能,包括:
5.2.1 zkKYC
5.2.2 金融(DeFi 与 CeFi)
5.2.3 治理与投票
5.2.4 游戏
5.2.5 医疗和健康
5.2.6 社交网络
5.2.7 教育和研究
5.2.8 经历验证
5.2.9 AI 数据标注
在 Web2 时代,大多数数据已经被聚合,现在只需要重新分配。zkTLS 使这一切成为可能,通过 无信任 和 选择性分发 提供服务。
作为 可验证网络 的核心基础设施,zkTLS 在 Web2 和 Web3 之间架起了桥梁。它为链上数据的繁荣播下了种子,并打开了前所未有的应用大门。zkTLS 正在重新塑造各行业,并重新定义数字时代的信任。
zkPass 链接:
网站 | 推特 | Discord | Medium | Github | 门户
- 原文链接: medium.com/zkpass/zktls-...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!