Building Online Trust, On-Chain - Maciej Kalka - zkTLS Day @ Devconnect 2025 (Buenos Aires)

Transcript

Yep, we're good to start. So, my name is Mache uh or Machek. It it goes both ways in Polish. Uh and I represent Vlayer Labs. Uh and let me start with quick intro actually because we often refer when speaking about Vlayer, we refer to TLS notary and we refer to standing on the shoulders of giants. So the green timeline is the timeline of TLS notary which has started back in 2013 on Bitcoin forum is in a way older than Ethereum.

Uh and here are we in 2024 Ver was founded as a company to bring with a mission to bring a web to data uh onchain. So what we started with was a more general approach to to getting web to data onchain and then through reiterations we ended up with with using TLS notary and ZKTLS um to to do so. Uh so a quick memory memory [snorts] run. We first met TLS notary in uh April 2024.

Uh that was in uh in Amsterdam. A cool place like a a little a little workshop room. We spend their whole week hacking talking about use cases. Uh few companies were built here actually. So, Opacity Her was there. Uh, Sahin ZKP2P. So, yeah, that that was a great place to be. Uh, then we had the chance to invite Thomas with the presentation with a talk and and Henrik with a talk uh to Warso where we are headquartered.

uh and it's not only talks we we also produced uh some resources together with TLS notary so there's a v layer playbook on web proofs a verifiable data report available on on our site but also a white paper and I think it's the only white paper format thing about TLS notary the only one available on archive uh it gets cited from time to time. Uh people are reading it. I think it's also cool that it somehow gets the the hands of of TLS notary to the to the academics. My background was academics.

So I really wanted to push for for something like that. Uh but it's not only like meetings, workshops, writing stuff is cool but at the end of the day it it comes down to building and what we believe we are building is is the online trust both onchain and and offchain. And just to recap quickly, I know Thomas presentation was was very detailed on various modes of of TLS notary, but essentially TLS notary uh web proofs zkls web proofs can be generated in two modes. one with designated verifier

where verifier uh runs MPC protocol together with the with the client and that's essentially a trustless mode but the verifier has to be involved in the MPC computational process or with outsourced notary who signs the transcript. So the notary who participates in a TLS session signs the transcript and then the transcript with the signature can be delivered to any third party verifier can be reused many times uh with different verifiers.

Uh and when talking about onchain proving this stuff, bringing this stuff onchain, we will be mainly focusing on on this direction with a third party uh notary. Yeah, because when web proofs or ZTLS meet the blockchain, this way is pretty much unfeasible because the blockchain has the computational limitations and cannot participate in this MPC action directly.

I really hope one day it will be possible to do this directly onchain and put the verifier onchain and run the the protocol uh without any additional trust uh issues guarantees security assumptions. uh but for now the best we can do is use external verifier and use this signed transcript signed attested transcript uh onchain. So what we want to do we want to ideally verify this uh signed attestation offchain and somehow bring the information about the signed

transcript that it's correct and it has correct data uh onchain. So then it's publicly available and can be used in in onchain use cases. So for triggering your smart contracts in in some way let's say. So how to do that? That's a good question. And the question you need need to ask yourself before doing that is how much do you care about security because there are like at least five models of doing uh web proofs onchain of doing ZKTLS onchain and each comes with their own security guarantees and security

assumptions. Uh so let's go through that. The first naive way is just trust notary. So if we trust notary uh then we can simply get the signed at the station deliver it to verifier verifier will sign will verify the transcript will verify the the notary's fingerprint uh we'll sign that it's all all good and put it on on the blockchain. So that is a fully permissioned solution because we as a blockchain verifier need to trust some offchain entity either notary

or or the verifier who is offchain. So that doesn't really work until the permission solution is good enough for you. I'd say it might be good enough for some PC's or for some early stage projects where you can for example roll out your own notary. So you will be signing the data for your clients could be good enough but for general model uh for for general use of web proofs onchain uh I don't believe it's a it's a good idea to do that. So uh because we essentially have the single point of failure which is an offchain entity and we don't want to have that like at all.

So what we proposed at Vlayer uh almost two years ago is running offchain verifier in ZK prover and this could be somehow confusing because we end up getting many provers and many verifiers but let me break it up for you quickly. So we go with uh ZKTLS protocol with a notary. We generate a signed attestation and what we do then is we deliver the atestation to the verifier running in ZK prover and the verifier verifies the the atestation. So we end up with a TLS transcript signed by notary and a zk

proof that the proof was verified correctly. You cannot forge that. What you need to do for that is run the for example TLS notary verifier in ZK which is quite expensive computationally to say at least but it's doable uh so ZK has came a long way even in the last two years when we were exploring that direction and I must say it's doable and and people are using this uh because it significantly reduces the trust assumptions that we that we have in the system because what we are building here is a this kind of multi-seek two out of

two because we have a notary we have a verifier running in ZK uh and even though notary can collude with client we need this like two signatures so there is no chance that uh forged proof will be verified correctly because of TLS notary guarantees and there is no chance that verifier was will misbehave because it runs in ZK so if he misbehaves we won't get a a proof of correct verification uh so I'd say like the only way to uh the only way to to to break this up is client colluding with a notary in a

way that client steals the notary server and runs it on on his own. Uh so if we are able to identify the client and and say yeah if you steal the notary server we know uh who you are uh such scenario is uh is pretty much uh very reasonable here and how we do it at at V layer right now. So we start with generating a web proof with TLS notary protocol and you can do it either server side we've got API endpoint uh for server side you can use you can notoriize public data you can notoriize

the data if you have OF so anything you can do via normal API you can do probably with with v layer uh or you can go the client side uh route through a browser extension ion or uh native mobile applications and that's what we call vouch. So vouch is a app built on top of v layer protocol which is essentially a data source catalog um with browser extension and and mobile apps uh which can notoriize all your private data across different data sources. So we have like couple hundreds of data sources right now ready for all

your use cases. Proof of address, proof of identity, proof of historical uh activity. Um and you can swiftly integrate this with the rest of the machinery which is generating the zk proof with another API endpoint we call compress web proof. So once you have a web proof obtained either server side or client side, you throw this web proof at our ZKVM, you generate compressed web proof and then you can verify the proof either offchain with another endpoint or with solidity smart contracts. uh for those right now

we're using the the risk zero verifiers which are deployed over several EVM compatible chains or you can roll out your own verifier which will be compatible uh with simply verifying the graph 16 proof that's something that we are getting extra here it's this kind of standardization that what we end up verifying on train is not some attestation with uh some some weird cryptographic commitments to unpack. Uh but we end up with with a with a growth 16 proof to to unpack on train. So two years ago we implemented our own

verifiers. Right now uh the the risk zero verifiers spread around in in many chains are are good for that. Um okay so that's that simplifies that that here here we are with v layer and with web proofs and with proving uh web to data onchain now few ways of how to even improve that how to make it more ballet proof and one way is using hardware enclaves.

So we can either run a notary in a trusted execution enclave and verifier in trusted execution enclave. Uh this will not result in zk proof. That's a that's a typo. This will result in a te at a stationation of course. Uh and I believe that's that's a great setup to have because the we all know how te is work. So, so the the hardware security guarantees are are quite hard these days. Um, I believe that's a setup which also gives us this standardization because TEA test stations can be standardized like are standard and and then the

things we verify on chain have some standard format and I believe that's the uh newest newest version of ZKP2P protocol. I don't know if Sahin is already there. But he could surely confirm later. Uh that's the way how ZKP2Pv3 works. So they they spin out notaries in trusted execution in environments and then the the verification be before the proof reaches a smart contract. It happens in TE. So they have a unified unified format of the uh of the verified data.

Uh it of course brings some questions. What if T got hack gets hacked and then we are you know what it's it's bad but those attacks are pretty hard and most of the attacks listed here on this slide are for SGX. Now we have TDX which is which appears to be more secure. Um, so I'd say if you compare the the security guarantees to uh to the to the attack possibilities, attack vectors, it's it's a great hardening of the protocol after all. Um, so especially with TDX around and

especially given the fact that the proof of concepts has already proven that it's fully doable. Um yeah another variant with te is spinning out the verifier in zk instead of te. So we get this two out of two multiscake and we are running notaries in T and then verification in ZK we we put the ZK proof on train that's actually the road map for V layer so we have a grantee who develops the notary servers in TES uh so we should have this kind of setup for onchain proving uh very very soon and what we believe it it should be like the

state-of-the-art for for onchain proving uh using ZKTLS then this section should be called a dream because all of those previous systems involved one notary uh and what if we could have two and a verifier in ZK and what if we could have three or four running at the same time the TLS session uh with the with the client that would be magnificent. I mean we would have like the the chance of hacking multiple notaries running in multiple tees let's

say uh I think I have this schema yeah right there so it will be almost zero but unfortunately uh running the the protocol like TLS notary so MPCTLS protocol with multiple notaries without timing out the the session or most importantly the handshake. It seems impossible. Uh I don't know if Shank from Primus disagrees because I know these guys uh worked hard on on on making this as fast as possible. Uh there was some effort from MPC magicians in Tacio uh to to make it happen, but I believe their

conclusion was as well that it might not be possible to do this on a standard machine on let's say 16 GB RAM MacBook uh without timing out the the TLS handshake which is very very timesensitive uh and it's becoming even like I guess it it will become even more time uh um time out timeout sensitive but if we could have one day yeah that would be great because that's that's hard hardly imaginable to to be breakable

and now as we have some time left I will I will show you some ways is towards the centralization of uh of such protocols because everything we discuss right now is centralized in a way. We could spin out notary and verifier in different places. We could spin out verifier locally but it will be centralized. There will be like single notary or even in like scenario we run at vlayer. So we are running go distributed notaries but we run them all. So how how can we decentralize such such system?

Uh one way of doing that was done specifically for web two web three markets uh like ZKP2P does and I don't so maybe short uh short remark before we start none of those proposals are are live. So you could hear you could you could process h and and guess why why there are they are not live anywhere. Uh but these are like great proposals and and great food for thought to to think about the centralization of the protocols. So the first proposition is from uh ZKP2P not general purpose but

specifically for web two web three markets and we called it optimistic notoriization. So once we have incentivized counterparty and uh a notary network with trusted notary majority with some transaction value clarity and important assumption regarding all notaries networks. So data immutability uh I will explain this in a moment. then we can perform uh in a way optimistic notoriization. So what would happen? We will have a network of notaries

where a notary will be picked randomly. Uh the proof will be generated. It will be pushed on chain but the transaction will be insured by the stake of the of the notary who signed it. and then we will proceed to uh dispute settlement period. So in a period of time a majority of of notaries could vote if the transaction signed by notary B was right or wasn't right. If and if it wasn't right then the majority of notaries would need to prove that indeed this transaction was different. So

that's why we need data immutability here because if the data changes dynamically different proofs at different time steps will give a different result. So that's fair fairly reasonable for the transactional data because once transaction is made the transaction amount is not changing anymore. So we can notoriize it multiple times to get the same value. But other than that in in like general purpose way this wouldn't work. So it such approach with dispute settlement optimistic notoriization and ensuring the transactions will not work if the data will be will be changing.

So another proposal uh was from opacity network uh and what they proposed was to be able to identify the clients and the notaries joining the network by using their valuable web two account. So this might be Twitter account, this might be some some other social media account. But to make notaries and clients identifiable, uh I already mentioned that that when we when the user is known, the security assumptions uh are are much better. So this combined with verifiable time timestamping again

trusted majority and obligatory TE usage by notaries this creates like a better environment and general purpose environment for creating a notary network. And one other uh proposition was coming from reclaim protocol again the centralized uh the centralized notary network or how do they call it proxy network. Uh so on top of honest majority uh they add up the network assumption of proxy TLS mode that what that's what's uh Thomas

probably already mentioned we need to assume that proxy connects directly to the server but what I like uh very much about reclaim proposition is how do they approach economic rationality Because in the notary network they propose to run a mixed quantile auction which somehow turns the notary network into a market. I don't know guys if you know boundless but they in a way did that to to ZK proving uh and had they they had this like a little white paper where everything could be turned into a market. Uh so

reclaim was was a little bit earlier with with that proposition and I think it's great like it it should be adjusted at some points but it's a great starting point to get some economic rationality among the network of notaries and how the notary could be chosen from the uh from the network. What we don't like in this proposal is again this data immutability uh because we want to have a general purpose uh protocol not the one that serves only data which doesn't change in time. So we want to have a network of notaries who could notarize the data which is time dependent which is

changing. So we wrapped this up some time ago. Uh I think that like a big picture not not much has changed here. We wrapped this up in a blog post. Uh you can find it at at Vlayer blog where we listed what are the security assumptions what we didn't say which model is the best because they are all different. uh and since it's been almost a year and I think none of them are in in in production I think there is a still a room for adjustments to running this decentralized notaries scenario uh there is a still room for a protocol

which will do that I don't know who will be first but but surely that will be that will be something something big that's that's surely going to happen for onchain proof And to wrap this up, uh I have a clear message for all of you. So study web proofs, study ZKTLS. Uh learn, build, and play. Uh join us in the second room, play with the workshops. It's it's really great to see your private data being reusable uh being verifiable uh being brought onchain or or being brought to web to uh places that that it

it didn't uh it hasn't been before. uh I really believe yeah it's very exciting and and it will transform Ethereum ecosystem eventually but we are approaching the point here in late 2025 where the technology is ready for users to play to build to experiment uh you no longer need to you know know all all the infrastructure details I wouldn't say ZKTLS has became commodity.

I believe we will discuss this little later today. Uh but I think the tech is ready. So, so you can just build what we call the the online trust and either hop on to one of the use cases that are there or try building your own your new use case, your new market, uh finding your your new way to use verifiable data. That's it from me. Thank you guys. [applause] Oh, hi. So, I I really like the talk.

Um, I'm very curious. So, for web proofs, um, they often not they they come in variable length, right? because like JSON the JSON payload response is typically variable length by nature you know you deal a little with list and stuff and I'm curious because like for ZK circuits they're often like fixed size and I'm curious like how like how your like proof system deals with that. So what we do in uh in ZK in in ZKVM let's say risk zero that that we are using is that it we verify the TLS notary proof which consists of uh certificate chain then the you know all

the all the inputs and the everything inside is encoded in a TLS notary way. So this can be either a hash commitment or some encoding commitment and this is what we unwrap in ZK. So we got with encoding commitment we go bit by bit through the whole transcript. With hash commitment it's fairly simpler because we have a full hash of a transcript or or transcript like slashed among the way but with with couple hashes. Uh so that's how we do that.

Oh okay. >> That's how we do that. I'm happy to show you like more how does how does it look in ZKVM in terms of cycles like step by step. Uh how does it break down the the verification here? >> Okay. And one more question. So let's say like I want to create a web proof of like a Instagram post. It's like hey like I want to get a web proof of somebody's photo. How long does it take? Do you know? I'd say in browser extension we have a rough estimation of 15 to 20 seconds per proof. uh that proving time depends on a network

request size not the response size and the requests are usually quite small like I'd say two to 8 kilobytes is the is the is the spread here uh so this 15 to 20 seconds on standard bandwidth it's [snorts] a reasonable estimation on mobile it's a bit lower actually Uh so so you can you can get it even faster. I don't know precise benchmark for Instagram post but for some Instagram stats it works in like 15 seconds.

>> Just just on simple like comments we have something new about decentralized testers using like combinations of the or something like that. So you can update that. [laughter] >> Okay. Okay. Happy to hear more. Thank you. Thank you for the beautiful overview of um the many different approaches towards the problem. I love it very much. Um you mentioned the like fian 2 having the note tree in the TE and the fur via in CK is kind of the immediate road map for flayer right now. I'm curious what are the like challenges that you are currently overcoming to I guess reach that uh version of uh well TLS yeah

ZKLS. >> So there are a couple angles. So for the ZK proving part we we using uh a ZKVM which is not ideal in a sense because it would be preferable to do this on device. So, so on device proving is is one thing especially for mobile I'd say like but that's a far far on the road map. Uh for for the ZK part in ZKVM it runs pretty pretty swiftly. We we with a EC ECDS pre-ompile it's yeah like couple million of of cycles there. So it looks

good on this side. on the T side uh we really wanted to implement TDX not SGX so the most of the PC's of of running uh notary was about SGX uh so that's quite challenging but we have a dedicated team at leaps who are our grantee who are exploring the TDX space specifically and and they should be shipping this in like upcoming quarter so that's that's how it looks like for We know it's fully doable. It's just a matter of engineering effort there.

>> Thank you then.