ZK11: 2PC is for P2P: A TLSN-Based On/Off-Ramping Protocol - Sachin Kumar

Transcript

Um hi everyone. I'm Sachin from the ZK P2P team. We have very limited time, so let's get started. So, ZK P2P is a trust-minimized fiat-to-crypto on-off-ramp protocol. It has a rather simple construction. You have the seller which locks their assets in the escrow contract and also provide an auction identifier. Uh the buyer then sends an auction payment to that identifier and then generates a proof of the payment and sends that to the verify contract. Uh if the proof verifies, then the verify contract unlocks the assets to the buyer. Uh currently, we use payment confirmation emails and the ZK email library to generate proof of payment.

And we have integrated with three payment services and done over 50K in volume over the last 4 months since our launch. Uh but one question that we keep getting asked is when Euro. And trust me, we have looked at several payment emails for a potential Euro integration, but one blocker that we have hit consistently with uh the Euro integration as well as other integrations is that payment emails aren't data rich. Uh for example, this is a screenshot of a Wise payment confirmation email uh for a transaction that I sent to Richard. You can see that there's the amount, there's currency, but there's no unique identifier of the receiver.

Instead, you have Richard's name, which is not enough to generate the proof of payment. Uh same is true for PayPal as well. Uh in contrast, it turns out that websites and APIs are very data rich. So, this is a screenshot of the transaction details page on the Wise website uh for a transaction that I sent to Richard. Again, you see the name and uh the amount on the page itself, but you look if you look under the hood, you see an API response with a ton of transaction-related data, including a unique identifier for the receiver. Now, the question is can we generate uh a proof of this API response?

Uh for that, we'll need to understand like dive deeper into TLS. Uh, TLS secures all the connection on the internet today. It is generally called the S in HTTPS. And you have two parties in TLS, the client and the server. The client sends the request encrypted using the client secret key to the server. The server responds uh, the response with encrypted using the server secret key. Now, let's say if you want to forward this encrypted response to a third party verifier uh, to convince them about the authenticity of the server response. Unfortunately, you can't do that because TLS uses symmetric keys, which means the client also has access to the server secret key and they can forge any arbitrary response using it.

So, there was a solution proposed uh, to generate TLS proofs uh, a few years ago and that uses 2PC. So, we'll quickly understand 2PC. 2PC stands for two-party computation. It's a special uh, specific case of multi-party computation. In 2PC, you have two parties. Both have their own private inputs, which they feed into the 2PC circuit to compute the output. Uh, there are multiple approaches to implement 2PC including garbled circuits uh, and FHE. So, coming back to the problem at hand, uh, in order to prevent the prover from forging valid responses from the server, we what we can do is essentially compute the TLS session keys inside a two-party computation such that both the prover

and the verifier only have a share of the client secret key and not the whole secret key. That means the prover can no longer uh, forge a valid response from the server. And because neither of them have the whole secret key again for sending an encrypted request to the server, they need to come together and perform a 2PC encryption, uh, forward the encrypted request to the server. The server responds with another encrypted response, which the prover forwards to the verifier essentially committing to the encrypted response. Now that the TLS session is over, the verifier can reveal their share of the secret key to the prover, and the prover can use that to decrypt the server response,

and then generate a a ZK-SNARK of valid encryption and decryption and send that to the verifier. If the proof verifies, then the verifier is convinced about the authenticity of the response. This protocol is called the 2PC TLS protocol. It is an interactive protocol, and for the purpose of this talk, it can largely be considered as a as a black box. So, as I said, like the 2PC TLS protocol is an interactive protocol. So, in the cases where you have a non-interactive verifier, for example, a smart contract deployed on chain in in the case of ZKP2P, you have to outsource this 2PC TLS verification to a third-party verifier called the notary.

The prover and the notary run the 2PC TLS protocol, and at the end of the 2PC TLS verification, the notary returns an attestation on the transcript of on the session transcript, which the prover can then forward to the verifier. The verifier just verifies the signature of the notary on that like essentially verifies the attestation, and if that passes, then the verifier is convinced about the authenticity of the response. This flow has been implemented by the TLS notary team. So, now we have a protocol to generate TLS proofs, and that means we can use that in ZKP2P to generate proof of payment. And in our case, the buyer would be the prover, and

they would run the 2PC TLS verification along with the notary. But as always, there's a catch. Because we are outsourcing the 2PC TLS verification to a third party, the the notary the notary can a malicious notary could collude with the prover and generate a fake proof of payment, one that did not actually happen. Uh and that's obviously bad. And to solve that, one solution is to make the seller be the notary. And a rational seller would not obviously collude with the prover because it's their assets that are at stake.

But then that introduces another attack by a malicious seller. After they receive the auction payment, they can essentially turn like shut down the notary and refuse to notarize the request. That means the prover will no longer be able to generate a proof of payment and unlock their assets. So, also like there's no way to prove that the seller is offline, so we cannot punish them for that. So, the only way out is to introduce a fallback notary. And because we do not like centralized servers, we will have to like because centralized servers could collude, uh we will have to introduce a decentralized network of notaries with an honest majority trust assumption.

But the UX in that case is very bad because essentially you'll have to run the 2PC TLS uh verification protocol with a majority of the nodes majority of the notaries in the network, and for that the prover would have to remain online for a very long duration, run the 2PC TLS verification with each one of them, which is very bandwidth intensive and very costly. So, to solve all of the problems that I described before, a collusion, censorship, as well as uh bad UX, we came up with the optimistic notarization flow.

Uh in this flow, first of all, the seller is no longer the notary. Instead, you have a dedicated network of operators acting uh as the notary, and each one of them has a stake on the network. So, any one of these uh notaries is randomly selected for the notarization, and we optimistically assume that uh the notarization is correct, there was no collusion, and unlock the assets. First of all, there is no more censorship because let's say if the chosen notary refuses to notarize, you can always just request another notary.

Um also this is uh good UX because essentially we're running the 2PC TLS verification with just a single notary, and that is uh cheap. Uh also optimistic notarization works because we have this another party, the seller, which is incentivized to initiate the arbitration process if they find a discrepancy. An arbitration would involve uh getting a majority uh of the stake in the network to disagree with the initial notarization. So, for on-off ramping, that would mean the seller proving that uh the seller did not receive the off-chain payment that the buyer claims to have sent.

If the initial notarization is found to be wrong, and then that particular malicious notary is slashed, and the slashing amount is used to compensate both the seller and the network. Now, arbitration is still very inefficient, but what we have done by like introducing optimistic notarization is essentially uh increased an economic slashing which deters the notary from acting maliciously in the first place. So, that would This is very similar to This is very similar to optimistic rollups, and we expect arbitration to not happen in 99% of the cases. And there is precedence for that. For example, uh till date, there has only been one fraud

proof submitted on all optimistic rollups, and that too was on the proof of work folks, and not not on the mainnet. Uh finally, the privacy of data is maintained uh from the notaries due to the 2PC TLS protocol. So, the optimistic notarization flow can be generalized to an optimistic oracle network for private data. It works in a P2P setting where you have this other party constantly checking whether the optimistic notarization happened correctly. And this allows us as a team to go beyond on-off-ramping. It allows us to build on-chain P2P marketplaces to trade all sorts of web2 private data.

Uh the network could potentially be bootstrapped using EigenLayer. Uh finally, coming back to the original question, when you do? Soon. We are in the final stages. Sorry. We are in the final stages of our Wise integration using TLSN. Uh we will also be releasing the ZK P2P extension along with the launch. Uh In the initial launch, we will be using a centralized notary. Centralized notary and uh uh All that all everything that I've proposed is essentially like down the line, maybe somewhere a year down the line.

Also, we have an in-person demo, so reach out to me if you need an in-person demo. Finally, uh thanks to the TLS notary team uh for building TLSN. Also, shout-out to PSE for sponsoring us, the ZK email team, as well as uh the TLS notary team. And thanks to all of you for listening. Great. I think we have a couple of minutes for questions. Yeah, go ahead. Yep. So, um if you have a question, there are some mics on the chairs. You just press the on button and we should get you.

One, two. Uh yeah, cool. Um so, correct me if I'm wrong, but you using this TLSN, you are querying Wise's API and you are finding uh user ID of the people who are sending you money and you are making some proofs based on that data. And so, what happens when the what happens in the protocol when the either API structure is changed, the JSON is changed and it's not being able to parse using some rejects that you have pre-written.

So, and drastic I'll change to it and what happens when the key of TLS key of the party of when the TLS key of Wise is expired when they're renewing it, the public key. So, yeah, that's a very good question. Like changing of templates is was a major problem in ZK email. For example, earlier we were using emails to generate the proof of payment and it's highly likely that a template of an email changes compared to what we are proposing right now, which is using TLS and now APIs are generally backwards compatible as in whenever an API changes that like you like Wise would generally

give like a maybe 6-month duration. They will make you aware of like the change and whenever they introduce like a new API like a V3 API over a V2 API, the V2 API is not um I mean, it's not put out of production immediately. Uh it's not deprecated immediately. You have like a good enough timeline to uh this is essentially update to the to the new API. So, that I think answers the first question. Is this What was the second question again? The second question is when Wise renews the public key.

Yeah, so if if Wise renews their So, what like during the 2PC TLS verification, we are verifying the two things. One is like that the session have happened correctly and the second is was the session was with Wise and not with let's say Wise fakewise.com. And there we are verifying the TLS uh key of Wise and I believe TLS keys don't change very regularly. Like once you are essentially like you generate a TLS key, there's a like it stays the same for for a very long duration. And if it is changed, it I mean I believe you're made aware of that, but I'll look into it. Yeah.

And a quick follow-up, you mentioned that API You would be notified if the API of vice is changed. So you are using a public API, it's not scraping of the API which is used on the original page. For wise we are using a public API. There could be also like for example if you let's say if we integrate with a banking website, then we will have to scrape let's say if the bank does not have API then we'll have to scrape the HTML response. And that has a higher likelihood of changing on the fly, right? Compared to an API.

Oh yeah, cool. Thank you. Great, thank you. If you just turn that mic off on the little button, that'd be great. Um I think that is all have we we have time for, but if you have any more questions, if you just find uh Sachin afterwards, that would be great. So uh lovely, thank you very much.