zkTLS in Practice: Lessons for Application Developers - 0xWildhare - zkTLS Day @ Devconnect 2025

Transcript

Uh hi everybody. I'm Steve uh Zerox Wild Hair on all my socials. Um I am going to talk to you today about um well how awesome TLS Notary and the work that they have done is and some of the other challenges you're going to come across if you're an app developer who wants to incorporate verified data into your application. Uh, this picture is unrelated. Um, but I saw this guy across the street yesterday and took a picture and I didn't don't still don't know what those are, but uh it looks a little bit like my PFP, so maybe we're brothers. Um, so now you guys also know that kangaroo donkeys are

a thing. Uh, let's start by just, you know, laying out the terminology I'm going to be using. So, um, app developer, you know, theoretically that's you. This, uh, talk is sort of geared for an app developer. You're building an app. Um, your app depends on some kind of verified data coming from a user and their account on a target platform. So, the target platform could be a government website that has some sort of citizenship data on it. It could be uh a bank with financial information. It could be Uber with your transportation information, GrubHub with, you know,

information about what you're eating. Whatever the uh whatever your app does, whatever verified data you need to bring into that app that exists on some other platform, your app's going to request that the user and a notary. And we're going to get into in a little bit who that notary is or can be. uh you enter into a MPC session and then a request is generated. That request needs to match what this target server is expecting. Right? We send that the weird little shaped arrow is because uh one of the neat properties is uh even though the NPC generates this request, it comes from the user's IP

address. um the target platform returns the information and then the user has it they can choose to send that to the application where it's ultimately verified. So uh you know I I think uh average app developer is just interested in the information right the developer wants the verified data uh can I have the data please and zkls answers yes but uh it's a little complicated uh so let's you know sort of talk about the parts here um the notoriization this is what pls notary is essentially solved

for us. Um, I'm not going to talk a whole lot about that part. Um, we've got the inputs going into the request. Like I said, the uh the request has to be identical to what the target uh platform expects to get from their own app. Um, otherwise they're not going to return the data that you want. And then there's a response that comes from that target platform. And that target platform is designed for that platform's app and their use case, not your use case.

Uh this I I took this right off the TLS notary website. This should be familiar. Uh pretty much every talk today has used some version of this. Uh sort of like a pop quiz here. Let's go back over the terminology, right? The prover, that's the user. The server, that is our target platform. Uh the notary is the notary, and the verifier is the app. Um most app developers probably I think they don't want to run the notary. Uh they just want verified data. If you're an app developer and you want to run the notary on your backend, that simplifies

a lot of things. That gives you cryptographic guarantees that the data that you're getting from that target platform is true. So there's some advantages to doing that, but it's also, you know, some increased level of difficulty. Um, so the easy answer, right, is a restaking network. Um, [snorts] if you're not running the notary yourself as the app developer, uh, the next best, uh, solution is economic security as opposed to cryptographic security. Um, and that's what restaking networks provide. There is a ton of

capital that wants to provide services right now and not a ton of services for them to provide. Uh so that economic security is very cheap, very abundant right now. Um now I say easy um there's a lot that goes into building a restaking network. Um myself and others have done talks on this. Uh that is not the subject of today's talk. Um but personally like if I'm your user um I'm much happier uh giving my data to a distributed network of validators who will never see unencrypted data than some large company

that uh has every incentive to scrape and sell as much of my data as they can. Uh so these target platforms, right, they could make this real simple for us and just sign their data. You know, if it's uh GrubHub, they could put a GrubHub signature on the data and you could use that however you want. They're not going to do that. You could be building an app that's a GrubHub competitor, right? So that's not going to happen. Um the good news is we can just liberate the data.

TLS notary is permissionless. We as long as you have the users's cooperation, you can get that data from that website or that target platform. Uh they're not necessarily going to make that easy on us. Actually, sometimes they're going to make that really really hard. If you want to read a really great blog about one instance of that being hard, this uh pixel melt blog is is great. Um they bought a book an ebook on Amazon but didn't want to use a Amazon ebook reader and it just goes through the challenges of reverse engineering that

API and actually processing that data into something usable. It's a great read. Uh, if you don't want to write that down right now, just hit me up after. I'll give you the URL. So, uh, I've said a couple times, right, the request going to the target platform, it has to be identical to what that target platform expects from their own app. Otherwise, it will be flagged as suspicious activity. They're going to cut you off. It's going to cause problems for your users.

uh at a minimum it'll be these popups that you get about suspicious act or emails that you get suspicious activity on your account. Um so the reverse engineer that's figuring out how to formulate this request and get all the pieces of this puzzle in they've got they've got a difficult job. Um please don't ask me too much about that. This sort of like uh dark arts to me. I know the very basics but it involves a lot of like uh sniffing traffic with specialized tools and jailbroken devices uh etc. One thing I do have some experience with uh they need burner accounts and even just the act of

creating burner accounts on many of these platforms uh that's suspicious activity right the platforms don't want you know they're fighting bots they're fighting scammers they're uh probably not aware of this type of activ activity yet uh but if they were you know in many cases they'd put in efforts to prevent specifically this as well. Uh so you got your work cut out for you creating the uh correct request. One problem that is already solved by TLS notary, the request comes from the user's IP address, which is just great, right?

Like if the request comes from uh AWS server, uh that's going to immediately get flagged as a bot, right? They're going to reject that. They're going to say, "Hey, suspicious activity." Or even if you're using residential IPs and they're getting repeated requests for the same account from different IPs in different places of the world, likely to get flagged, right? Um, they know the tricks and they they want to prevent their users being taken advantage of and they want to protect what they consider to be, you know, their data. Um, another nice thing, notorized result delivered to the user's device. They can choose

what to do with it. Uh, simple redaction is baked in. Um, talk about some of the, uh, limitations of that in a moment. Um, and again, the notary has cryptographic guarantees. So, if that's a rester, uh, and you're signing off that this, you know, this piece of information came from this server, you have cryptographic guarantees that you're not going to get slashed. So bottom line is MPC is the best way to scale a ZKTLS network. That response um many times it's uh it it includes a bunch of information you don't necessarily need. It will include

uh sensitive user data, private data. It will uh frequently be very large. Uh, for example, the user or the Uber just a simple profile request from Uber. The response includes the information about all of the nearby drivers. So, it's absolutely huge and has a bunch of stuff in it that you probably don't want as a app developer. So I've I've been a little uh I guess I've been using uh MPC TLS to describe uh what TLS notary team has delivered.

Uh there's been some debate in the space. So is that ZK? Is it not ZK? You know I think the proverse sees unencrypted data. That is zero knowledge. That fits the definition. But here I'm specifically talking about adding a ZKVM to process the response. So you have a hash commitment on the original response. You can put some transforms into the uh into the ZK VM so that we can omit all of the unnecessary data. Uh instead of redacting the data, you can just leave it out. Right? As uh Thomas mentioned earlier, uh sometimes redaction like if it's your sex, male, female are

different numbers of letters. So you can still leak data through the redaction. If it's completely omitted, then you don't have that problem. This also enables range proof. So I don't have to tell you how old I am. I can just prove that I'm over 18 or whatever. and we can make the result a very simple usable format for for the developer. Uh this is sort of like the reverse engineering. It's going to customize to each platform. Each platform is going to have its own um reverse engineering on the input and its own transformations on the output. be some, you know, knobs,

switches, you know, range proofs, things you can set, but pretty much all custom. So, in summary, um, the TLS notary team did an amazing job. Um, you know, as as developers, there's a whole new like range of information available, whole new, you know, range of apps that can be built. Um there's still some hard parts. Um right now our solutions include a TE based notary. Um we have reverse engineering available for many uh uh popular platforms and some TEbased transformations on the so

secured by TE not CK of the response data. um coming you know soon TM we've got what we've been calling uh internally the big enchilada which is a uh restaking networkbased uh notary um network and uh zka transformation on all of the response data. Uh so we're super excited to see what is going to be built with this technology.

It it does it should be a major unlock. You know, now there is way way way more data. All of the data is available for your app. So what are you going to build? Thank you. Uh there's my information. Please contact me or uh talk to me after. Um, we have time for questions. 30 seconds. 30 seconds for questions. Quick one. All right. Thank you.