技术栈拓展：综述zkTLS的原理以及潜在应用场景

技术栈拓展：综述zkTLS的原理以及潜在应用场景

原文作者：@Web3_Mario

最近一直在寻找新的项目方向，在做产品设计的时候遇到了一个之前没有接触过的技术栈，所以做了一下研究，并将学习心得做一下整理，与诸君分享。总的来讲，zkTLS 是一种结合零知识证明（ZKP）和 TLS（传输层安全协议）的新型技术，在Web3赛道中主要用于在链上虚拟机环境中，可以在无需信任第三方的情况下验证其所提供的链下 HTTPS 数据的真实性，这里的真实性包含三个方面，数据源确实来源于某个 HTTPS 资源、返回的数据没有经过篡改、数据的实效性可以得到保证。通过这种密码学实现机制，使链上智能合约获得可信访问链下Web2 HTTPS 资源的能力，打破数据孤岛。

什么是 TLS 协议？

为了能够比较深刻的理解 zkTLS 技术的价值，有必要将 TLS 协议做一下简单的综述。首先 TLS（传输层安全协议）用于在网络通信中提供加密、认证和数据完整性，确保客户端（如浏览器）和服务器（如网站）之间的数据安全传输。对于非网络开发方向的小伙伴可能会发现，在访问网站时，有些域名是以 https 作为前缀，有些则以 http 作为前缀。而在访问后者时，主流浏览器都会提示不安全。而前者则容易遇到“您的链接不是私密链接”或者 HTTPS 证书错误的提示。而这种提示的原因就在于 TLS 协议的可用性。

具体来讲，所谓 HTTPS 协议就是在 HTTP 协议的基础上利用 TLS 协议保证了信息传输的隐私性和完整性，并使得服务器端的真实性变得可验证。我们知道，HTTP 协议是一种明文传输的网络协议，且该协议不能对服务器端的真实性做验证，这就产生了几个安全性问题：

1. 你和服务器端传输的信息可能被第三方监听，从而造成隐私泄漏；

2. 你无法验证服务器端的真实性，即你的请求是否被其他恶意节点劫持，并返回恶意信息；

3. 你无法验证返回的信息的完整性，即是否有可能由于网络原因造成数据丢失；

而 TLS 协议正是为了解决这些问题而被设计的。在这里做个解释，有些小伙伴可能知道 SSL 协议，其实 TLS 协议就是基于 SSL 3.1 版本开发的，只是由于一些商业相关的问题，换了一个名字，但其实是一脉相承。所以有些时候在一些语境下，两个词是可以互换的。

而 TLS 协议解决上述问题的主要思路是：

1. 加密通信：使用对称加密（AES、ChaCha 20）保护数据，防止窃听。

2. 身份认证：通过第三方颁发给指定机构的数字证书（如 X.509 证书）来验证服务器的身份，防止中间人攻击（MITM）。

3. 数据完整性：使用 HMAC（哈希消息认证码）或 AEAD（认证加密）确保数据未被篡改。

我们简单来讲解一下基于 TLS 协议的 HTTPS 协议在数据交互过程中的技术细节，整个过程共分为两个阶段，首先是握手阶段（Handshake），即客户端与服务器端协商安全参数并建立加密会话。其次是数据传输阶段，即使用会话密钥进行加密通信。具体的过程共分为四个步骤：

1. 客户端发送 ClientHello：

客户端（如浏览器）向服务器发送 ClientHello 消息，内容包括：

  • 支持的 TLS 版本（如 TLS 1.3）

  • 支持的加密算法（Cipher Suites，如 AES-GCM、ChaCha 20）

  • 随机数（Client Random）（用于密钥生成）

  • 密钥共享参数（如 ECDHE 公钥）

  • SNI（服务器名称指示）（可选，用于支持多域名 HTTPS）

其目的是让服务器知道客户端的加密能力，并准备安全参数。

2. 服务器发送 ServerHello：

服务器响应 ServerHello 消息，内容包括：

  • 选择的加密算法

  • 服务器随机数（Server Random）

  • 服务器的证书（X.509 证书）

  • 服务器的密钥共享参数（如 ECDHE 公钥）

  • Finished 消息（用来确认握手完成）

其目的是让客户端知道服务器的身份，并确认安全参数。

3. 客户端验证服务器：

客户端执行以下操作：

  • 验证服务器证书：确保证书由受信任的 CA（证书颁发机构）签发，同时验证证书是否过期或被撤销；

  • 计算共享密钥：使用自己和服务器的 ECDHE 公钥计算出 会话密钥（Session Key），该密钥用于后续通信的对称加密（如 AES-GCM）。

  • 发送 Finished 消息：证明握手数据完整性，防止中间人攻击（MITM）。

其目的是确保服务器可信，并生成会话密钥。

4. 开始加密通信：

客户端和服务器现在使用协商好的会话密钥进行加密通信。

  • 采用 对称加密（如 AES-GCM、ChaCha 20）加密数据，提高速度和安全性。

  • 数据完整性保护：使用 AEAD（如 AES-GCM）防止篡改。

所以经过这四步操作后，就可以有效解决 HTTP 协议的问题。然而这种广泛应用在Web2网络中的基础技术，却为Web3应用开发造成了困扰，特别是在链上智能合约希望访问某些链下数据时，由于数据可用性的问题，链上虚拟机不会开放为外部数据的调用能力，以确保所有数据的可回溯性，进而保证共识机制的安全性。

然而经过一系列迭代后，开发者发现 DApp 对于链外数据还是有需求的，于是一系列预言机 Oracle 项目便出现了，例如 Chainlink 和 Pyth 等。他们通过充当链上数据与链下数据的中继桥，来打破这种数据孤岛的现象。同时为了保证中继数据的可用性，这些 Oracle 普遍通过 PoS 共识机制来实现，即让中继节点的作恶成本高于收益，使其从经济效益上不会向链上提供错误信息。例如我们希望在智能合约中访问 BTC 在 Binance、Coinbase 等中心化交易所的加权价格，则需要依仗这些 Oracle 将数据在链下访问加总，并传输到链上智能合约中存储起来，才可以使用。

zkTLS 解决了什么问题？

然而人们发现，这种基于 Oracle 的数据获取方案，存在两个问题：

1. 成本过高：我们知道为了保证 Oracle 传递到链上的数据是真实数据，没有经过篡改，需要由 PoS 共识机制保证，然而 PoS 共识机制的安全性是建立在质押资金量的基础上的，这就为维护带来了成本。而且通常情况下，PoS 共识机制中存在大量的数据交互冗余，因为当数据集合需要在网络中大量重复传输、计算、汇总，才可以通过共识，这也垫高了数据使用成本。所以通常情况下，Oracle 项目为了获客，只会免费维护一些最主流的数据，例如 BTC 等主流资产的价格。而对于专属需求，则需要通过为之付费。这就阻碍了应用创新，特别是一些长尾、定制化的需求。

2. 效率过低：通常情况下，PoS 机制的共识需要一定的时间，这就造成了链上数据的滞后性，这对于一些高频访问的使用场景是不利的，因为链上获得的数据与真实的链下数据存在较大的延迟。

为了解决上述问题，zkTLS 技术便应运而生，它的主要思路是通过引入 ZKP 零知识证明算法，让链上智能合约作为第三方，可以直接验证某个节点提供的数据，确实是访问了某个 HTTPS 资源后返回的数据，且未经篡改，这样就可以避免传统 Oracle 因共识算法导致的高昂的使用成本。

有小伙伴可能会问，为什么不直接为链上 VM 环境中内置Web2 API 调用的能力。答案是不可以的，因为链上环境中之所以需要保持一个封闭数据的原因是要保证所有数据的可追溯性，即在共识过程中，所有节点对于某一数据或某一执行结果的准确性有统一的评估逻辑，或者说是一种客观的验证逻辑。这保证了在完全去信任的环境下，大多数善意节点可以依赖自己冗余的数据判断直接结果的真伪。但是由于Web2数据，你很难构建其这种统一的评估逻辑，因为可能由于某些网络延迟原因，不同节点访问Web2 HTTPS 资源所获得的结果是不一样的，这就为共识增添了困难，特别是针对一些高频数据领域。除此之外，另一个关键问题在于，HTTPS 协议依赖的 TLS 协议的安全性，依赖于客户端生成的随机数（Client Random）（用于密钥生成）和密钥共享参数，实现与服务器端针对加密密钥的协商，但我们知道链上环境是公开透明的，如果让智能合约维护随机数和密钥共享参数，则关键数据将会被暴露，从而使数据隐私性被损害。

那么 zkTLS 则采用了另一种手段，其构想在于，通过密码学的保护，替代掉传统 Oracle 基于共识机制为数据带来可用性的高昂成本。类似于L2中的 ZK-Rollup 对 OP-Rollup 的优化。具体来讲，通过引入 ZKP 零知识证明，并对链下中继节点请求某 HTTPS 得到的资源、相关的 CA 证书验证信息、时序证明以及基于 HMAC 或 AEAD 的数据完整性证明进行计算生成 Proof，并在链上维护必要的验证信息以及验证算法，使得智能合约在不暴露关键信息的同时，可以验证数据的真实性、实效性、及数据源的可靠性。具体的算法细节在这里不做讨论，感兴趣的小伙伴可以自行深入研究。

这种技术方案最大的好处就是降低了Web2 HTTPS 资源的达成可用性的成本。这就激发了很多新需求，特别是在降低长尾资产的链上价格获取、利用Web2世界中的权威网站做链上 KYC，从而优化 DID、Web3 Game 的技术架构设计等方面。当然我们可以发现，zkTLS 对现有Web3企业的冲击也是存在的，特别是针对当前主流的预言机项目。所以为了应对这种冲击，例如 Chainlink、Pyth 等该行业巨头积极跟进相关方向的研究，试图在技术迭代过程中依旧占据主导地位，同时也会催生新的商业模式，例如从原来的按时间收费向按用量收费转换、Compute as a service 等。当然这里的难点与大多数 ZK 项目一样，还是在于如何降低计算成本，使之具有商业化价值。

综上所述，小伙伴们在做产品设计的时候，也可以关注 zkTLS 的发展动态，并在适当的方面整合这个技术栈，或许可以在业务创新、以及技术架构性方面，找到一些新方向。

最新发布

热点资讯

标签