InfoFi: ZKTLS and ZKVM Powered Social Leaderboard - Michael Dong - zkTLS Day @ Devconnect 2025

Transcript

Hello. Okay, awesome. Uh, do do we have a clicker or something or no? Okay, that's fine. Um, hi everyone. This is uh Michael. Uh, I'm a founder and CEO of Brevis. Uh, today, you know, on Zik TS day. I'm going to basically go through a demo uh that we we worked on to power the first uh kao uh you know social leaderboard uh with uh out kind of leaking uh your private information such as wallet addresses. So um you know but before I dive into uh you know the demo itself just want to kind of give you a quick introduction of what we do at BIVvis right so like you know um BIVIS is trying to build what we call the

infinite comput layer for web 3 um you know it is a smart verifiable computing platform powered by ZK so you know blockchains as we know are often advertised as water computers but in reality it cannot run faster than a single server and it's also extremely expensive. Now the fundamental reason for that um is okay so sorry uh so you know uh you might think okay wait that's not the case because like we have done all this work in the last 10 years to actually improve the scalability of the layer 1 blockchain and layer two blockchains you know uh we should be able to just run any kind of computation on them. Well, unfortunately that is not the case. Um, you know, something as simple as a trading fee, uh, you know, kind of discount program based on the

user's trading volume is not possible to be, you know, kind of implementing DAX today until very recently. Now, the fundamental reason for that is that today's consensus is actually built on this paradigm of symbol computing where let's say you have two nodes and want to convince each other the result of a certain computation. You know what you do here is that let's say Alice here basically compute the the result of the multiplication equation and she's trying to convince Bob the result is actually done correct the reality is actually correct. Now how does Bob do this here is Bob is actually going to run the same kind of computation again. So you know the entire kind of a blockchain consensus today is built on this

paradigm of recmp computation based verification. What this means is that let's say you have like a swap transaction in your you know kind of a smart contract which is very simple to compute if you're running a single node but the problem here is that uh you know now you're actually computing this on millions of nodes that is kind of running Ethereum consensus layer today and this is a fundamentally why the kind of a blockchain um computation are still very expensive and cannot really kind of scale beyond a a uh uh a single server capability.

So the solution that we introduce here is something called verifiable computing. Verifiable computing is a different kind of computing paradigm where you have different rows in the entire computing system. In this case, Alice, let's call her the prover. And uh uh you know, she is not only just computing the result of the equation, but also generating something called a zk proof. And you know, she can just send a zk proof, which is a magical piece of since you guys are all here in ZKTs today. I assume you know the kind of a background of this that a verifier can you know spend a tiny amount of verification computation to actually kind of verify the result is done correctly. And uh we with this kind of a new paradigm we decoupled the computation from the verification

process. So Zika has been around for quite a long time. The reason it has been brought to the main stage recently is because of the gap between the orange bar and the the uh the the sorry the blue bar here shrink a lot. you know before this uh you know recent kind of a movement on ZK development this kind of a gap between the original computation and the computation needed to compute the proof itself is like a million times but with the recent development of the kind of ZK proving technology we now shrink this kind of a gap between this and you know kind of the proof generation and the original computation to two to three orders of magnitude which is like very much kind of feasible

as a scaling solution. So the nice thing of course about DK is that no matter how complex your original computation is the once you generate the proof the verification cost of this remains roughly the same. So um you know what we are building here is this kind of a verifiable computing platform where can you can offload some very complex computation away from blockchain to the smart uh to kind of a brevis and inside of a brevis you can generate a zk proof and say submit the zk proof back to the blockchain. So the smart contracts or other validators in the blockchain can easily verify the proof and consume the result as if the entire complex computation happened on the blockchain directly.

So you know previous is not theoretical um we are powering a numerous kind of a you know top tier uh pro project and protocols such as metam mask pancake swap unis swap beef uh erad opening euro and all these. So these are not kind of vanity stuff. They are real in production use cases that are running live today. So today in zika day I want to highlight a specific use case that we did uh with um Kaido. So in as you how many of you guys know what Kaido is? Do I need to kind of explain Kaido? Okay.

Well you know turns out that a lot of people actually don't know. So uh so Kaido is this kind of a social you know kind of in what people call infoy platform that you know tracks what is uh you know the users kind of influence level on Twitter. Uh so it has different kind of leaderboard in different subcategory of the crypto uh space like a zk you know different project and stuff like that. So um you know the the idea here is that uh because we need to kind of help the project to raise awareness in the entire crypto community. So you know the project can build their own leaderboard and monitor who are actually contributing the loudest social voice and then you know reward these kind of user uh properly

when they actually launch uh the token right so uh you know right now however uh you know oh sorry before kind of we integrated with uh Kao very recently the only way to kind of track users voices by analyzing their social account activity and nothing house. So this is a kind of a you know as you can imagine in the age of AI you can have a many kind of a you know garbage kind of a social content that is generated by AI and kind of essentially pollute the system right so uh so we want to have they want to basically have a way to essentially generate some level of attestation of like okay this user or this kind of a

social profile is actually attached to some real user that are using onching applications and using kind of a meaningful you know um uh interactions with the protocol itself. However, they tried to push this but they've actually failed because you know um they start to realize that first of all people don't want to gave them their uh Binance account API access and second is even on for onchain data stuff like people don't want to even kind of associate their main wallet with their social profile right so you know so that's kind of the challenge they they face when they kind of first encounter this and when they

talk to us and we say okay look you know it seems that a zigg TLS is the right solution here so uh and also of course like for onchain stuff you don't really need zls but for offchain stuff you actually need that so we talked to them and we start to kind of work together and build this new um you know user profile attestation system that allows user to attest to certain behavior these projects themselves are interested in kind of a knowing right so let's Say you're launching a DeFi project. Well, you know, uh and uh you have a bunch of yappers that are yapping about this kind of a project and you want to essentially gave higher weight for some kind of a

social u you know community uh who actually used a lot of D5 protocols before or um who actually held a lot of D5 tokens there in their centralized exchange account. So this is precisely what we built. Um on the purely onchain side, uh we used our ZKVM to essentially build this kind of onchain attestation platform that allows users to generate a privacy preserving attestation about their onchain behavior and onching user profile. something like okay I have actually used the unis swap allowed in the past like 30 days or I have held a certain token after airdrop without

actually directly dumping it right so it becomes very useful for many projects and u you know for the offchain part which is uh the part that you actually need to kind of connect with uh you know your centralized exchange account this is where the ziki ts component come in we work with our partner premise uh to actually kind of implement this feature. But a challenge with like just Ziki TLS protocol is that you know it is a great to it is great tool to actually pull data uh raw data from like kind of a let's say binance.com uh you know if you want to pull your trading history data you can easily get that but what you know for many users they don't want to

even share their trading history directly with kind of the external party right they want to essentially generate a test station showing that okay I'm a holder I'm a holder of the certain token um you know uh and my holding kind of amount um you know time weighted holding kind of amount is a bigger than a certain kind kind of threshold they want to kind of generate this kind of a test station. Now this is where the ziki VM component comes into play where you can essentially use this kind of a you know uh zikks proof to actually recursively verify the proof firstly in a zkm and then use zkm to write a very general and flexible program to process and compute on these data and once you can compute

on these data you can essentially uh you know generate a u a proof showing the end to end result of uh your entire kind of a user profile. So I'm going to show you a demo here um which is a recorded demo since I know the internet here is not so good. So the idea here is that you know once you kind of start to do the verification there's a plug-in that is installed on you oh we you really cannot see this right. So, but yeah, so like there's a plug-in that is installed on um you know uh the user's browser and this this plugin is where the ZKTS happens and uh you know in this particular case um you know you get the user's kind of a trading history right

so this is kind of a trading volume attestation and uh then the next thing what do you what you do next is that you got you want kind of have this data and send it to a ZKVM to do proving right so this is actually a tricky part because you don't want to kind of leak users data to external approver as well. So this is where we actually partner with some of the TE providers to run the entire ZKVM competition process also in T. So uh you know this way what you can with this what you can do is that you can basically now you know generate a end to end privacy preserving proof showing that okay for for example this time you know um this particular user didn't have

enough trading volume and therefore the end result is just like a true and false attestation in this case is false but you don't actually need to leak your entire kind of a trading history and stuff. Now you know after you made a bunch of trade in your Binance account uh what you can now do is to do the verification uh you know to do the testation again and um you know uh after this this step is a raw data and this step is where you you do the kind of a real uh you do the z VM based computation and now the attachation result changes from false to true right so uh this is kind of a very very simple example and this data actually gets sent back to you know uh title without actually revealing what is that the

user's UID or everything but just to say okay this particular user with this social profile actually controls a Binance account with uh you know this and this and that kind of user profile. So for this particular uh demo, what I want to kind of show is really that you know ZKTS protocols and ZKTs solutions are most useful when combined with ZKVMs. Um and ZKVMs can essentially kind of run arbitrary computation on top of these data and generate useful insight um that is kind of a you know arbitrarily kind of attachable to different applications need.

So uh that's pretty much it. Uh but just to kind of quickly go through this whole thing that there are so many different use cases for brevis as well. Um you know we power next generation decentralized exchange user experiences. Um you know uh we are building ZK powered peraxis with some of the leading perpetual swap exchanges. uh we're helping kind of a decentralized uh uh stable tokens to grow by building this kind of a transparent uh trust-free and the compliant uh reward distribution system and um you know uh so many more.

So uh we believe that in 10 years like 99% of the computation for blockchain application are going to um happen in the offshin world and verified hopefully by zk proof and hopefully by brevis itself. So very quickly just to kind of introduce what is actually inside this magic box. So we have this kind of a pickle zk VM which is the the right now the world fastest ZKVM available and on top of that we have a bunch of things called co-processors to support specific kind of application need as you can see like when we work with zkr solutions like premise we essentially use them as a co-processor that can be recursively

verified and plugged in into the virtual machine system and uh yeah the rest of stuff uh you know is not quite relevant to ZikTS but uh uh yeah that's uh uh that's uh the that's it that's my talk thank you [applause] any questions I think I have a time for one question all right thank you guys again oh sorry >> hey uh very interesting um approach to using ZKTLS. I a question regarding the Brevis uh ZKVM runtime. Um you mentioned

it's programmable in Rust. Is it using a risk vb based architecture or is it a WM? What's the approach there? >> Yeah. So like uh you know previous pico ZKVM is a risk 5 compatible uh zkm with a bunch of function level compiles. So like you know we basically accelerate certain kind of operations like a catch hash and all these stuff. Uh so yeah so it's uh um you know yeah in short it's a risk five compatible one >> and 32 or 64bit >> sorry >> is it like 32 bit or 64 >> right now it's uh 32 bits and uh you know we're kind of extending this to 64 to support things like uh you know support things like uh you know go runtime and stuff. Yeah.

All right. Thank you.