Skip to main content

zkTLS

Overview​

At ZKP2P, we make heavy use of zkTLS techniques to prove authenticity of data while preserving user privacy. zkTLS enables us to port any data from the web served through TLS1.2 and TLS1.3 to smart contracts. In particular, there are 2 techniques: TLSNotary (MPC-TLS) and TLSProxy (a proxy-based approach using third-party zkTLS proof providers).

TLSNotary​

Notary​

The Notary runs the 2PC-TLS protocol with the Buyer and attests the transcript to make the data portable. In V3, buyer-generated proofs are submitted to the Attestation Service, which validates the proof, signs a PaymentAttestation, and returns the payload used by the on-chain verifier. Currently, ZKP2P provides a hosted Notary to its users via the ZKP2P extension.

Generating proof of payment for ZKP2P using TLSN​

zkTLS 1

Simplified 2PC-TLS protocol between the Prover and the Verifier (Notary)​

zkTLS 2

WebSocket Proxy​

Since a web browser can't make TCP connection, we need to use a WebSocket proxy server. ZKP2P provides a hosted WebSocket proxy to all its users via the ZKP2P extension. The proxy only forwards encrypted data from the Prover to the server and returns the encrypted response returned from the server back to the Prover. If the proxy fails the user can always run their proxy to forward the request to the server.

Decentralization of Notaries​

Note that, the seller is trusting the Notary to not collude with the Buyer and generate fake proof of payment. The buyer is also trusting the Notary to not censor it. Currently ZKP2P runs both the Notary and websocket proxy. But we are committed to the decentralization roadmap and are developing solutions for both the collusion and censorship problems in a decentralized way. One solution that we are working on currently is the Optimistic Notarization flow.

Optimistic Notarization with a network of Notaries​

zkTLS 3

Arbitration​

  • Optimistic notarization works because seller is incentivized to initiate arbitration if they find a discrepancy

  • Arbitration involves getting majority stake to disagree with initial notarization

    • For on/off-ramping, proving that seller didn't receive off-chain payment

  • If found guilty, the malicious notary is slashed

  • Slashed amount is used to compensate seller and the network

  • Arbitration is still inefficient

    • But slashing deters the notary from acting maliciously

    • Similar to optimistic rollups, don't expect arbitration to happen in 99% of the cases

  • Privacy of data is maintained from notaries due to 2PC-TLS protocol

References​

To understand why we are building with TLSN and the Optimistic Notarization flow please watch our ZK11 talk

To understand TLSNotary, please go through their docs

TLSN Docs

TLSProxy​

note

The proxy-TLS provider flow described below was used in the legacy V2 protocol. It is retained here for historical context. The current V3 production flow validates payments off-chain via the Attestation Service (Buyer TEE Verification and Seller Autopilot).

Unlike TLSNotary, the proxy approach relies on the Notary being in between the Prover (buyer) and the Server. Privacy is still preserved as only encrypted ciphertext is sent from the Prover to the Notary (Witness Proxy), and the prover is the only party that holds the symmetric TLS keys. This approach is significantly more efficient as it removes the need to generate the TLS session keys using 2PC Garbled Circuits.

However, it is not as censorship resistant as the MPC-TLS approach due to the introduction of network topology assumptions. In particular, the server API call is from the Notary (Proxy), not from the prover's home computer, therefore, servers could censor the proxy if its hosted in a datacenter.

Additionally, there is a possibility of a Prover MITM (man-in-the-middle) attack to change packets enroute if they are able to gain access to the port in the datacenter where the Notary (Proxy) is hosted. This is because the Prover holds the TLS keys.

The proxy-based zkTLS proof providers used in V2 had undergone multiple independent audits, which is why the approach was considered production ready at the time.

Additionally, ZKP2P is built to be generic so we can plug in any primitive as they become mature.