Verity: Trust-Minimized Data Flows for Smart Contracts - Ryan - zkTLS Day @ Devconnect 2025

Transcript

Hello. Hello. Thank you all for jumping in and learning about ZKTLS. It's an exciting topic. My name is Ryan and I'm the founder of Usher Labs. At Usher Labs, we've been re doing a lot of research into data verification and data storage. I think the last year we did a lot of work on ZKTs because we realized how important this technology could be. And so the quest was how do we build out a framework to support data flows, tamper-roof data flows so that we can build private and fast blockchain oracles. And of course that's powered by ZKTLS. But before I dive into that, a little about us myself. I've had experience at payment startups in

Australia, some publicly listed ones, and founded this company alongside a bunch of data engineers essentially that all have some prior experience in 03 or were totally new. And uh some of the companies we've served were most mostly use cases of ZKTLS or somewhat touched on data in the past. Uh but the quest has sort of led us to our own use case ultimately which is in DeFi. So we're sort of realized okay why we have ZKTs work let's just apply it and so this talk is going to be revolving around that um how we're applying ZKS to our use case but I'll get to that use case at the end. Let's talk about verarity.

severity this framework why does why does it matter right institutions from our perspective hold all user private data there's a lot of zkls solutions that go for you know the the browser extension approach we focused on the APIs right getting permission from played for example so you can tap open API a sorry open banking APIs so a high frequency serverside indexing of real world data from institutions was the mission you can think of this like extract transform load except with verifiability And the result through this framework is to allow blockchains to say you know what happened to this data in the past so that we can do stuff with it right is the data correct where did it come from are these conditions

met so ETL is the is the mission now I've prepared some demo I can skim through a little bit of this who here is a programmer by the way okay perfect so you got you've worked with a terminal um yeah a little bit of a tech heavy demo today but this is just a small introduction to how varity works. It's a simplification of engaging TLS notary. It uses CLIs to engage you know the prover and notary and of course uh verification of proofs.

But what we've done differently is with our prover acts as a proxy and immediately the first thing we do is set up sort of a subscription to a proof and we use a request ID to correlate this async proof to a request for a proof. Um, so you can run this proof of proxy as a, for example, micros service from whatever backend you're operating and it does TLS notary for you. Now, we're using the latest version of TLS Notary. So, shout out to Primis Labs and the TLS Notary team for that heavy lift because it's actually insane, very fast.

And you can see I've just copied the proof, no serverside event metadata into a file. And using CLI, we verify and get Bitcoin price. Pretty simple. But let's move on. Um, for the sake of time, I can show you what uh, you know, redactions look like, but I think it's pretty straightforward and we have public docs for that. I'm going to focus a bit more on like the innovations from our end, like what do we do to TLS notary that actually is new. We like to call this first thing preparation and concurrency. Um, and the quest here was like how do we reduce the time it takes to generate a proof? How do we minimize the time to proof if that was our KPI? Right? And so in this first demo I'm going to show you is actually

an attempt using TLS notaries example for concurrent proof generation. And so here you see you know some code. The code is what it's doing is actually a batch of four proofs done concurrently but staggered one second apart to JSON placeholder you know website. And so the basically four proofs at a time uh they happen one second apart and they it happens over and over again. So how do we get four proofs at a time basically?

And so when I run this eventually uh oh yes I added some uh I started the benchmarks after the prover and notary setup to give some some leeway to to ts notary example. When I run this it yes starts working. Okay. And uh you see the average time to proof by the TLS notary example is roughly about 1.5 seconds for this specific API request. And of course depending on the size of the request it's going to vary time to proof but using this local environment the average is 1.5 using default.

Let's move on. Okay. Now let's run this demo. This demo is this demo is essentially what Varity can do. Um by incorporating this this paradigm of preparation and concurrency and by knowing which endpoints we want to reach uh before we actually execute the the the proof for that particular endpoint. The outcome we get with Varity is oh sorry this is wrong demo.

Okay, let me try zoom in. Hey, skip in. Okay, cool. So, I was just going to pause there and describe it. The f So, the first part of the demo, what I did is I ran Varity without any awareness of what happened prior, right? what no awareness of which domain I'm going to reach and by default because verarity is a microserbased tool there's a little bit more overhead than the default TLS notary so if you're every request that's being received is unknown to where the destination is uh TLS notary is cool but the meat of this innovation comes from

when you know where you're going to be making requests and the objective is that like if you're indexing data from Binance if you're indexing data from Coin Gecko that you're aware of these domains and therefore you can prepare for those domains in advance of e executing the proof and the outcome of this is I'm going to demonstrate that now is that we set up this prover with awareness of this particular placeholder endpoint that we tested against the default TLS notary and when I run it the average proof time is 0.5 seconds right so from 1.5 seconds to 0.5 seconds simply by knowing in advance what the destination end point is. And so for anybody who's indexing the world using

ZKTLS um and doing it in high frequency uh I implore you to check out the framework. Um it's mostly open source. So we're openly sharing this information because uh we're moving mostly into applying this in DeFi and uh know that there's a lot of ZK TLS innovation that could leverage this. Um, okay. See what's going on here. Okay, let's move on to the next innovation. So, the first one was uh decreasing time to to proof. And the second innovation here is how do we actually roll all of these TLS proofs up? Like in our circumstance, we're going to be generating uh like 10 different proofs for 10 different, you

know, PE, you know, Binance accounts, for example, or, you know, we can take 10 proofs from 10 different centralized exchanges and produce one proof of of reserves. How do we do this? Well, we want to roll it up, right? And we to roll it up, shout out to Michael from Brevis who detailed using the recursive approach. We need a ZKVM to roll up or some decentralized compute as an alternative. Uh if we can allow for data to be public, but let's assume we want to focus on private data because that's where the meat is. We need a ZKVM. Well, ZKVMs can actually be quite expensive in operation uh if there's a lot going on that shouldn't that doesn't necessarily need to be there. And in our perspective, TLS proofs by T by TLS notary are

actually comprised of three subproofs. The first is the attestation, the identity, the second is identity, and then the third is transcript. And the transcript is really where all the private data sits. It's the whatever gets sent and received from the server. The identity is where you hit, right? that can be considered private but uh if you're verifying things on chain and the conditions you know predicated on where the data came from that can be public and of course the attestation is a signature and a merkel route that ties everything together in the proof. So our objective here is like how how do we actually destructure the TLS proof so that we can take the private stuff and put it in a ZKVM, generate a ZK proof and then correlate that to some public

stuff that was in the original proofs and the ZK proof and then what we get as an outcome essentially is like a ZK rollup of a bunch of data that we got from the internet endto-end verifiability with you know closing out that goal of extract transform and load because we're incorporating the compute side of things that transformation allows us to, for example, you know, run compute on data that was private. Um, but yeah, this is an alternative architecture. This is the original. This is the one we're using, right? ZK proof and public stuff goes together to a public network that verifies it all together. uh we use the internet computer because it's cool and

it allows us to do compute and generate an MPC sig of what was done. Uh but you can you know incorporate your own ZKVM or use your own decentralized compute. Yeah. So I'm going to show a final demo here. Um and this demo is mostly around just showing you an example of the ZKTLS flow in action. And so if I yeah if you take a look at this code very quickly if I pause it so we can read it uh it's quite straightforward you know we make a request using you know verity TLS prover and then we run it inside of a ZKVM we verify the private facets inside of a ZKVM and then we take that and the

public stuff and put it on a decentralized compute to roll it all together. Now I try eventually. Yeah. Okay. Still looking at code. Okay, cool. Um, so I go ahead here and I and I actually try to generate the ZK proof. And uh, if I sat here and actually ran through the ZKVM proof generation process, you would probably end up. So what I do instead here is I actually just comment out the ZK proof generation because ZK proofs require GPUs, right? in in real life.

So yeah, I mean GPUs are provided by many of the ZK uh I guess proving networks. They're all using GPUs to generate your ZK proofs. So yeah, what I do instead is I use a fixture. It's a saved ZK proof instead to demonstrate that uh you know we've generated this proof in the past and uh we're verifying it alongside the other TLS proof subproofs. Yeah. So that's the outcome here after we verified everything. You see that we made a request to a domain called mock.vverity.ash.o.

So you see it uh sort of works and we get a signature too of the outcome. Okay, let's start to wrap things up. So the use case that we're applying this for is to actually uh expand the depth of a market on a you know on on a DEX like unis swap. How do we you know allow for fiat in a bank account for example to back the depth of a stable coin in in the same that represents the same fiat. Uh the outcome of doing that is you know we have super a lot of depth low spreads for markets like at USDC to pesocoin.

you no one wants to lock up their peso coin but there's a lot of peso in bank accounts so why you know let's make dexes aware of all that all that fiat is the is the mission here for us but other case studies we've actually presented is for example um reducing the cost of accessing data from a network like internet computer they have their own internal oracle mechanics by using zk tls they actually we actually reduce the cycle consumption on their network by 90% and we've shared that in a forum post where in the comments you can see me go back to back with with one of their one of their community members.

That's an example of just the cost reductions of generating a proof on one node instead of having a whole network request the same endpoint. We also presented the graph over in Zurich regard regarding this to their team. Um how there's a bit of a trade-off where if you requesting more you know data you know 10 requests per minute for example it's a lot more efficient uh to use CKTLS. The last thing I want to open up the the stage for, um, I mentioned earlier like this is a research project, so we're open to collaboration. Um, if you're looking for, uh, you know, smaller time to proof or you're looking to roll up a bunch of TLS attestations, we're down to collab. But the final thing that's a bit

of an open road map I think we should all consider is this concept of collusion. And in my opinion, humbly speaking, um, I think cloud provider enforced CES are underrated. I think that if you throw the if you take the notary and you you know isolate specific functions around key generation uh and you know startup and so on inside of the TE and you include a TE attestation inside of the TLS proof itself that indicates which where the signer came from using TLSN extensions. uh then I think we can really solve this concept of collusion because you know we shift that trust over to the cloud provider as opposed to um you know trusting a

network of notaries or something like this. So yeah, here are my contact information. Feel free to reach out and uh hopefully you guys followed but this was quite technical so if you did I give you a pat on the back. Thanks.