Introduction

Ethereum, the backbone of decentralized applications, faces several key challenges beyond transactions per second and low transaction costs. One of them is the limited access that decentralized applications have to real-world data, which limits the possibilities and potential of dApps.

Today, oracles like Chainlink and Pyth play a crucial role in the DeFi ecosystem, primarily by providing reliable price feeds. Without these data feeds, the capabilities of decentralized finance would be significantly restricted.

In addition to these oracles, we also have solutions such as optimistic oracles like UMA and zero-knowledge proof-based data such as zkPassport, PrivadoId, zkEmail, and others, which extend the reach of verifiable data.

However, imagine if users could generate cryptographic proofs for any data they have access to on the internet — specifically through a ‘TLS connection.’ This would revolutionize the way we access and verify data, greatly expanding the potential of both web2 and web3 applications.

TLS

Source: https://images.app.goo.gl/EgRxTDEAHw4ZtS2X9

To understand zkTLS, it’s important to first grasp the role of TLS in web security. TLS is the technology that transforms HTTP into HTTPS, ensuring secure communication over the internet.

It ensures privacy and data integrity between two communicating applications, and without it, sensitive data like login credentials and credit card details would be vulnerable to interception. We will dive deep into the details of how TLS works in a further post.

zkTLS

Now, let's say you can generate proofs to TLS sessions. This would mean that you can basically generate proofs to most of the data sent over the internet. This data could include financial transactions, personal messages, online purchases, access to digital content, login credentials, healthcare data, and much more. This capability would greatly expand the potential applications of both centralized and decentralized systems, making the internet as we know it today more composable.

There have been different approaches to achieve that. Currently, the steps of generating a ZK proof for a TLS session works as following:

1. First, an attestation of the TLS session is created. Currently, this can be done through Multi-Party Computation, a proxy, or a trusted environment.

2. After the attestation is made, a Zero-Knowledge (ZK) proof is generated to verify it, ensuring that sensitive data remains private.

Note: It’s worth mentioning that although we call this zkTLS, the protocol isn’t fully secured by Zero-Knowledge Proofs. At this point, ZK is mainly used to boost the security of Multi-Party Computation or to generate a proof of the attestation verification with privacy. Further in this article, we will discuss the trust assumptions for each approach.

Now, let's explore each of the solutions in more detail.

MP-TLS (Multi Party Computation)

To prove a TLS session, the client (prover) connects with a notary, and together they use Multi-Party Computation (MPC) and Interactive Zero Knowledge(IZK) protocols, specifically Garbled Circuits and Oblivious Transfer, to generate a shared public key that will be sent to the server. This key is used during the TLS handshake to create the Pre-Master Secret and session keys. The session key is now split into two parts — one held by the client and the other by the notary, from here all encryption and decryption with the server are done through MPC and IZK.

At the end of the session, the client creates authenticated commitments to the plaintext, which the notary verifies and then signs without ever seeing the actual data. After this step, the client can generate a zkProof that reveals only the necessary information.

Pros:

• Higher security due to the use of MPC, ensuring that data remains fully private thanks to IZK.

• No risk of the server blocking any specific IP Address

• Possible improvement in efficiency and security with improved cryptographic protocols such as Quicksilver which is a VOLE based Interactive Zero Knowledge Proof protocol.

Cons:

• Latency Sensitivity: The execution time of Multi-Party Computation (MPC) is highly sensitive to latency. Even small increases in latency can significantly impact the overall time required to complete the MPC, leading to inconsistencies in proof generation. Therefore, network speed and the physical distance between the client and the notary are crucial factors that can affect performance.

• Data Size Constraints: The computational workload and the amount of data exchanged during MPC increase significantly with the size of the data being proved. Currently, the TLS Notary implementation by the Privacy Scaling Exploration team supports data sizes up to around 61 KB.

• Currently only works for TLS 1.2

Trust Assumptions:

• Trust that the Prover will not collude with a third party Notary/Verifier.

TLS Proxy

TLS Proxy acts as an intermediary between the client and server, verifying the encrypted data exchanged during their communication. It doesn’t function as a man-in-the-middle (MitM) since it only has access to the encrypted data. After the session is finalized, the client shares part of the session key, which decrypts only non-sensitive parts of the request. The client then provides a Zero-Knowledge Proof for the response data, allowing the proxy and others to verify the content of the TLS session without exposing sensitive information. This approach was first implemented by the Reclaim Protocol team.

Pros:

• Lower latency compared to MP TLS, making it more suitable for real-time applications.

• Simplified setup, as it doesn’t require complex cryptographic protocols.

Cons:

• Less private compared to the MP-TLS approach as the proxy will have access to some data from the TLS session

• Less secure than MP-TLS as it makes network topology assumptions, so not recommended for high-value transactions.

• Potential bottleneck if the proxy server becomes overloaded.

• Risk of the proxy being banned by the server.

Trust Assumptions:

• Trust that the Prover will not collude with a third party Proxy.

Trusted Execution Environment (TEE)

A TEE is a secure area within a processor that ensures the integrity and confidentiality of the data and code running inside it. When used to execute TLS, TEEs can securely run the protocol, providing attestation of the execution and content of the TLS session. This approach is currently implemented by the Clique team.

Pros:

• No need for a third party notary or proxy to attest the data

Cons:

• Dependence on hardware, making it less flexible and potentially vulnerable to hardware-specific attacks.

• Limited availability across different devices, which might restrict adoption.

Trust Assumptions:

• Hardware security and attestation process which could vary.

What are the use cases for zkTLS?

So, after all this, you might be thinking, what are the possible use cases for making data portable? Here are some ideas our team plans on exploring:

• P2P AD Marketplace: We can create a peer-to-peer “Facebook Ads” / “Google Ads” marketplace where participants control their data.

• Proof of Fandom: Some platforms, like Spotify, don’t allow artists to access data from their fan-base. What if users could directly prove their “fandom” and receive perks from the artists?

• Proof of AI: AI is here to stay, and with zkTLS, we can make smart contracts truly smart. By proving API requests to GPT APIs, Claude APIs, Gemini APIs, and other AI services, we can now use these proofs to trigger on-chain actions. This could unlock on-chain gaming NPCs, financial AI agents, AI participation in DAO voting, and much more.

• Proof of Payment: A decentralized peer-to-peer on-ramp and off-ramp method where a person selling their tokens creates a pool and shares a Revolut username. The tokens are locked in a smart contract until someone submits proof of payment in Revolut, allowing the payer to claim the tokens and close the transaction.

• Proof of Finance: One of the challenges we’ve been trying to solve in web3 is undercollateralized loans. Now, with proof of credit scores, bank balances, income, and other financial data, this is no longer just a dream.

Summary

Ethereum’s current limitations in accessing verifiable real-world data restrict the types of applications we can build. However, by proving TLS sessions with zkTLS, it is possible for us to now verify most of the data accessible on the internet.

By leveraging zkTLS, developers can seamlessly integrate zkProof generation into existing Web2 API calls, enhancing Ethereum’s access to various Web2 services. This integration enables secure and private data verification without changing the end-user experience or requiring significant adjustments from developers.

In conclusion, zkTLS isn’t just a technical milestone — it’s a transformative leap toward a more secure and interconnected digital world. By enabling Ethereum to verify and utilize vast amounts of real-world data, zkTLS opens the door to unprecedented applications that could reshape industries and redefine trust in the digital age.

Socials:

Follow us on Twitter: https://x.com/0xZapLab

References:

1. TLS Notary:
   https://docs.tlsnotary.org/

2. Pragmatic Introduction to Secure Multi-Party Computation: https://securecomputation.org/docs/pragmaticmpc.pdf

3. VOLE Based ZK
   https://blog.chain.link/vole-based-zk/#quicksilver_protocol

4. Reclaim Protocol Whitepaper
   https://www.reclaimprotocol.org/whitepaper/

5. Zero Knowledge Using Garbled Circuits
   https://eprint.iacr.org/2013/073.pdf

6. Secure Multi-Party Computation by Brechy
   https://mirror.xyz/privacy-scaling-explorations.eth/v_KNOV_NwQwKV0tb81uBS4m-rbs-qJGvCx7WvwP4sDg