# zkTLS AVS

https://www.opacity.network

The collusion problem of MPC-TLS makes it so we need decentralized nodes that act correctly. The use of an AVS is requred to circumvent the collusion problem of MPC-TLS.

We lay out a high level description of a protocol that circumvents the collusion issue of zkTLS.

## Introduction

Building a general purpose verifiable bridge between web2 and web3 is something the founding team of Opacity has been obsessed with for many years now.

There are generally three ways to verifiably port web2 data:

1. zkEmail
2. zkJWT (requires OIDC)
3. zkTLS (eg TLSNotary)

By far zkTLS is the most powerful. It allows for extracting data from any existing https call and do rich ZKPs on the transcript.

Example use cases:

1. Range proof of bank balance,
2. Proof of twitter handle,
3. Proof of KYC for DeFI,
4. Better oracles for price feeds or prediction markets.

The use cases range from net new consumer products to oracles with better trust assumptions. We are trying to build a firehose of web2 data into web3 **WITHOUT** extra trust assumptions. Any web or mobile app is fair game.

## Background on zkTLS

### SSL/TLS

**HTTPS**- HTTP + SSL + TLS

**SSL** - End to end encryption, but is susceptible to a man in the middle attack.

**TLS** - Centralized system that solves the man in the middle problem using a certificate authority. This is how your browser knows it's actually talking to your bank.

---

To understand why zkTLS without trust assumptions is until now unsolved, we must talk about the details of how SSL/TLS work.

**Server** has:
1. Public/Private key pair
2. Public key is signed by Certificate authority

**Client** has:
1. Public/Private key pair

**Steps of SSL/TLS**

1. Client verifies server certificate signature
2. Both sides do a Diffie-Hellman key exchange to find a shared secret (some point on elliptical curve)
3. X-coord of shared secret is HMAC'd to derive a symmetric key (AES or ChaCha20)
4. Both the client and the server use the SAME set of symmetric keys to encrypt/decrypt the transcript

There are two main reasons zkTLS is difficult:

1. Use of a shared secret makes it possible for the client to swap the cipher text. So we **must complicate a normal network request** to trust the provenance,
2. Hashing the shared secret **restricts** the types of MPC we can use.

### Architectures to acheive zkTLS

There are only three architectures to achieve zkTLS:

- ❌**TEE/SGX** - Clique

Offload SSL/TLS to a TEE, and have the enclave sign the request was encrypted/decrypted correctly.

- ❌**Proxy witness** - Reclaim protocol

The client routes the request through a proxy, and the proxy signs a statement of what traffic they saw go b/w client and server. At scale this architecture will be blocked.

- ✅**MPC** - TLSNotary

An MPC node helps the client make the request so no one knows the shared secret until the session is finalized. This approach is undetectable by the target server. We must use garbled circuits and oblivious transfer MPC schemes.

## Collusion problem of MPC-TLS

In the MPC architecture of zkTLS a fundamental issue arises. The client and the MPC node can collude to reconstruct the shared secret, and **forge arbitrary proofs** from the target server.

### A note on N-way MPC-TLS

In a shamir secret sharing MPC scheme it is very efficient to scale the number of parties involved with the MPC. SSS is what is commonly used in MPC-wallets like Lit Procotol. Unfortunately these MPC schemes are not as effective in MPC-TLS.

SSS-MPC is unfortunately unavailable to us because of the use of a cryptographic hash to derive the symmetric key(s) from the shared secret. In a SSS-MPC scheme hashing a value where the pre-image cannot be constructed by anyone has extreme overhead. The request may timeout before the request is actually finalized.

Another way is to extend garbled circuits and oblivious transfer to work with more than two parties. Sadly this scales very poorly, and is extremely complicated to engineer securely. There are a lot of optimizations for 2-party GC/OT that are unavailable for MPC with more parties.

### A note on proof by committee

Another approach is to have the user generate multiple proofs from many nodes before a proof is valid. Unfortunately even this doesn't work in the general case.

To explain why imagine we have a committee of 10 nodes, and we want to prove a bank balance. For the first 6 proofs can be done as normal. After the 6th the user can make a debit card TX to change the balance. So the last 4 disagree with the first 6.

This leads to a situation **where nodes can get slashed even though they did nothing wrong**.

By committee with slashing **ONLY WORKS** if the user can't change the trust value in b/w proofs. Otherwise a malicious user can slash honest nodes.

In the case of a price feed we run into issues because the trust changes too quickly for a proof by committee to work. **This presents significant issues with using zkTLS based oracles.**

## Solution to the collusion problem

Here we present the main innovation of the Opacity team in the zkTLS space. An innovation that allows us to trust arbitrary proofs with a minimal number of proofs.

Fundamentally, it is a subtle shift in perspective. We are confident it's impossible to solve the collusion problem directly within the time contraints of a good user experience. However, if you have a reliable way to detect if someone is trying to collude, then indirectly we can solve the collusion problem.

The solution is simple, and has four parts:

1. Commit and reveal scheme,
2. Random selection of MPC-node,
3. On-chain contract of wallet address to web2 account ID,
4. Verifiable log of attempts.

---

### Prove ownership of a web2 account

A key part of the solution is a mapping between a wallet address and a web2 account. A UUID is most common, but not universal. Twitter uses a large number as their primary ID in the database.

It's standard practice to never change a account ID in a web2 system because it's the primary identifier in the database. This makes it so we can use a committee to prove ownership of a web2 account. As a user, I might generate 6 identical proofs from different nodes in order claim a web2 account.

Having a mapping of web2 accounts to wallet addresses is a essential part of how we solve the collusion problem.

---

### Walkthrough of proof generation

Assume:
- We have a decentralized network of MPC nodes,
- The protocol can randomly select a MPC node for each job.

The protocol to generate a proof is as follows:

1. Commit the claim,
2. MPC node is selected **AFTER** commitment of claim,
3. Prove the generated proof matches the claim.
4. Prove the correct wallet address is presenting the proof (via web2 identity contract)

Lets walk through the example of notarizing a bank balance to help us understand. Say I have $100 in my account, but I am trying to forge a proof that I have $1m in my account using a colluding MPC node.

1. Commit "$1m"
2. Selected MPC-node is **NOT** colluding node
3. ❌

The wrong MPC node was selected, and in the verifiable log we have a failed attempt. Let's say we tried 5 times until we got the colluding node. Our verifiable log of attempts would look like:

1. ❌
2. ❌
3. ❌
4. ❌
5. ✅

Even though the user generated a forged proof, they have left behind a verifiable log of failures. As such, the protocol can reject a proof if it is preceded by a string of failures.

Naturally there is a sybil issue here that is taken care of by the web2 identity contract. Since we have a mapping of web2 accounts to wallet addresses, only 1 wallet address is allowed to present proofs for any web2 account. So a user **CANNOT** rotate wallets until they succeed.

**QED**

### A note on zkTLS Oracles

In many cases an oracle is trying to port public data which is not associated with an account. Say a public price or weather feed.

In this case we no longer have the web2 identity contract, and so we must solve the sybil issue seperately.

We can limit the number of oracles, and have them stake. We can also be a lot stricter with the verifiable log of attempts. The oracle won't have random access ability to forge a proof. They will leave behind a log of failures before they can forge a proof.

### Sourcing randomness

1. Hash onion
2. MPC setup
3. RanDAO (https://github.com/randao/randao)

### Rules for slashing MPC nodes

1. Node has too many failed requests,
2. Doesn't use SGX,
3. User can prove knowledge of MPC-node key share before session finalization,
4. MPC node tried to force user down a malicious path

### Rules for slashing zkTLS Oracle

1. Oracle is offline
2. MPC node can prove knowledge of oracle key share before session finalization.
3. Too many failed requests