The biggest benefit of zkTLS is that it reduces the cost of achieving the availability of Web2 HTTPS resources.

Author: @Web3_Mario

Abstract: Recently, I have been looking for new project directions and encountered a technology stack that I had not previously engaged with while doing product design. Therefore, I conducted some research and organized my learning insights to share with everyone.

In general, zkTLS is a new technology that combines Zero-Knowledge Proofs (ZKP) and TLS (Transport Layer Security Protocol). It is mainly used in the Web3 space to verify the authenticity of off-chain HTTPS data provided without the need to trust a third party in an on-chain virtual machine environment. The authenticity here includes three aspects: the data source indeed comes from a certain HTTPS resource, the returned data has not been tampered with, and the timeliness of the data can be guaranteed.

Through this cryptographic implementation mechanism, on-chain smart contracts gain the ability to access off-chain Web2 HTTPS resources reliably, breaking data silos.

What is the TLS Protocol

To deeply understand the value of zkTLS technology, it is necessary to provide a brief overview of the TLS protocol. First, TLS (Transport Layer Security) is used to provide encryption, authentication, and data integrity in network communications, ensuring secure data transmission between clients (such as browsers) and servers (such as websites). For those not in network development, you may notice that some domain names have "https" as a prefix while others have "http." When accessing the latter, mainstream browsers will prompt that it is not secure. The former may encounter messages like "Your connection is not private" or HTTPS certificate errors. The reason for these prompts lies in the availability of the TLS protocol.

Specifically, the so-called HTTPS protocol is built on top of the HTTP protocol, utilizing the TLS protocol to ensure the privacy and integrity of information transmission, making the authenticity of the server verifiable. We know that the HTTP protocol is a plaintext transmission network protocol, and it cannot verify the authenticity of the server, leading to several security issues:

1. The information you transmit with the server may be intercepted by a third party, resulting in privacy leaks;

2. You cannot verify the authenticity of the server, meaning your request may be hijacked by malicious nodes, returning malicious information;

3. You cannot verify the integrity of the returned information, meaning data loss may occur due to network issues;

The TLS protocol was designed to address these issues. To clarify, some may know the SSL protocol; in fact, the TLS protocol is developed based on SSL version 3.1. Due to some commercial-related issues, it was renamed, but it is essentially the same lineage. Therefore, in some contexts, the two terms can be used interchangeably.

The main ideas of the TLS protocol in solving the above issues are:

1. Encrypted communication: Using symmetric encryption (AES, ChaCha20) to protect data and prevent eavesdropping.

2. Identity authentication: Verifying the server's identity through digital certificates (such as X.509 certificates) issued by third parties to prevent man-in-the-middle attacks (MITM).

3. Data integrity: Using HMAC (Hash-based Message Authentication Code) or AEAD (Authenticated Encryption) to ensure that data has not been tampered with.

Let’s briefly explain the technical details of the HTTPS protocol based on the TLS protocol during data exchange. The entire process is divided into two phases: first, the handshake phase, where the client and server negotiate security parameters and establish an encrypted session; second, the data transmission phase, where encrypted communication is conducted using the session key. The specific process consists of four steps:

1. Client sends ClientHello:

The client (such as a browser) sends a ClientHello message to the server, which includes:

• Supported TLS version (e.g., TLS 1.3)
• Supported encryption algorithms (Cipher Suites, such as AES-GCM, ChaCha20)
• Random number (Client Random) (used for key generation)
• Key exchange parameters (e.g., ECDHE public key)
• SNI (Server Name Indication) (optional, used to support multiple domain HTTPS)

The purpose is to inform the server of the client's encryption capabilities and prepare security parameters.

2. Server sends ServerHello:

The server responds with a ServerHello message, which includes:

• Selected encryption algorithm
• Server random number (Server Random)
• Server's certificate (X.509 certificate)
• Server's key exchange parameters (e.g., ECDHE public key)
• Finished message (to confirm the handshake is complete)

The purpose is to inform the client of the server's identity and confirm security parameters.

3. Client verifies the server:

The client performs the following actions:

• Verifies the server certificate: Ensures the certificate is issued by a trusted CA (Certificate Authority) and checks if the certificate is expired or revoked;
• Computes the shared key: Uses its own and the server's ECDHE public key to compute the session key, which is used for subsequent symmetric encryption (e.g., AES-GCM).
• Sends Finished message: Proves the integrity of the handshake data to prevent man-in-the-middle attacks (MITM).

The purpose is to ensure the server is trustworthy and generate the session key.

4. Start encrypted communication:

The client and server now use the negotiated session key for encrypted communication.

• Symmetric encryption (e.g., AES-GCM, ChaCha20) is used to encrypt data, improving speed and security.
• Data integrity protection: Using AEAD (e.g., AES-GCM) to prevent tampering.

After these four steps, the issues of the HTTP protocol can be effectively resolved. However, this widely used foundational technology in the Web2 network has caused difficulties for Web3 application development, especially when on-chain smart contracts wish to access certain off-chain data. Due to data availability issues, on-chain virtual machines do not open the capability for external data calls to ensure the traceability of all data, thereby guaranteeing the security of the consensus mechanism.

However, after a series of iterations, developers found that DApps still have a demand for off-chain data, leading to the emergence of a series of oracle projects, such as Chainlink and Pyth. They act as a relay bridge between on-chain and off-chain data to break this data silo phenomenon. To ensure the availability of relay data, these oracles generally implement a PoS consensus mechanism, making the cost of malicious behavior for relay nodes higher than the benefits, thus economically disincentivizing them from providing incorrect information on-chain. For example, if we want to access the weighted price of BTC on centralized exchanges like Binance and Coinbase in a smart contract, we need to rely on these oracles to aggregate the data accessed off-chain and transmit it to the on-chain smart contract for storage.

What Problems Does zkTLS Solve

However, it has been found that this oracle-based data acquisition scheme has two problems:

1. High cost: To ensure that the data transmitted to the chain by the oracle is authentic and has not been tampered with, it needs to be guaranteed by the PoS consensus mechanism. However, the security of the PoS consensus mechanism is based on the amount of staked funds, which incurs maintenance costs. Additionally, there is often a lot of redundant data interaction in PoS consensus mechanisms because data sets need to be repeatedly transmitted, computed, and aggregated in the network to achieve consensus, which raises data usage costs. Therefore, oracle projects typically only maintain some of the most mainstream data, such as the price of BTC, for free. For specialized needs, payment is required. This hinders application innovation, especially for long-tail and customized demands.

2. Low efficiency: Generally, PoS consensus requires a certain amount of time, leading to latency in on-chain data, which is unfavorable for high-frequency access scenarios, as the data obtained on-chain has a significant delay compared to the real off-chain data.

To address these issues, zkTLS technology has emerged. Its main idea is to introduce the ZKP zero-knowledge proof algorithm, allowing on-chain smart contracts to directly verify that the data provided by a certain node indeed comes from accessing a specific HTTPS resource and has not been tampered with, thus avoiding the high usage costs caused by traditional oracles due to consensus algorithms.

Some may ask why not directly embed the capability to call Web2 APIs in the on-chain VM environment. The answer is no, because the on-chain environment needs to maintain a closed data structure to ensure the traceability of all data. In the consensus process, all nodes have a unified evaluation logic for the accuracy of a certain data or execution result, or an objective verification logic. This ensures that in a completely trustless environment, most benevolent nodes can rely on their redundant data to judge the authenticity of direct results. However, due to Web2 data, it is difficult to construct such a unified evaluation logic, as different nodes may obtain different results when accessing Web2 HTTPS resources due to network latency, complicating consensus, especially for high-frequency data fields. Additionally, another key issue is that the security of the TLS protocol, which HTTPS relies on, depends on the random number generated by the client (Client Random) (used for key generation) and key exchange parameters. If smart contracts were to maintain random numbers and key exchange parameters, critical data would be exposed, compromising data privacy.

zkTLS adopts another approach, aiming to replace the high costs of traditional oracles based on consensus mechanisms for data availability through cryptographic protection. This is similar to how ZK-Rollup optimizes OP-Rollup in L2. Specifically, by introducing ZKP zero-knowledge proofs and computing proof based on the resources obtained from a certain HTTPS request, related CA certificate verification information, temporal proof, and data integrity proof based on HMAC or AEAD, necessary verification information and algorithms are maintained on-chain, allowing smart contracts to verify the authenticity, timeliness, and reliability of the data source without exposing critical information. The specific algorithm details will not be discussed here; interested parties can delve deeper into the research.

The greatest benefit of this technical solution is that it reduces the cost of achieving the availability of Web2 HTTPS resources. This has sparked many new demands, especially in reducing the on-chain price acquisition of long-tail assets, utilizing authoritative websites in the Web2 world for on-chain KYC, thereby optimizing the technical architecture design of DID and Web3 games, among other aspects. Of course, we can see that zkTLS also poses a challenge to existing Web3 enterprises, particularly to current mainstream oracle projects. Therefore, to respond to this challenge, industry giants like Chainlink and Pyth are actively following up on related research directions, attempting to maintain a dominant position during the technological iteration process, while also giving rise to new business models, such as transitioning from time-based charging to usage-based charging, Compute as a Service, etc. Of course, the difficulty here, as with most ZK projects, lies in how to reduce computational costs to make it commercially viable.

In summary, when designing products, you can also pay attention to the development dynamics of zkTLS and integrate this technology stack in appropriate areas. You may find new directions for business innovation and technical architecture.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。