Experiments in Building ZK Applications [EN] [Ethereum Protocol Day]

Transcript

[Music] Hi guys, I'm going to talk about experiments in verifiable computing. So this basically summarizes the research uh that we have been doing in the past uh two years or so. Um so for some context in Ezekiel we built a transpiler between onyx files to uh z circuits. Um but it turns out that zero knowledge proofs are not like the

big picture. Um the design and solution space is quite large and sometimes you might not need zero knowledge properties. Sometimes you only need soundness and completeness. Um, and so I'm going to talk about what this actually entails. So really when we are talking about ZK, we are talking about this complexity class called interactive proof systems. So this was introduced by this guy called Babai uh back in 1987 or something called interactive proof systems and it fundamentally deals with this

problem. If I have like a prover and a verifier they are trying to play a game and the prover wants to convince the verifier of a fact. So how do we do this? Okay, so there are few rules in this game. The prover has infinite computational uh capacity as well as computational power, but they cannot be trusted. And so the verifier now needs to check whether this prover is actually telling lies to this verifier. And so we kind of want to construct things in a way where you can prove efficiently.

So we can essentially start this challenge response um uh game where essentially the the verifier ask some questions and the f will answer them. So this makes sense right? Um so for example the prover says I know the mala hot pot recipe. The verifier would say I don't I don't need to know the recipe but you can try and prove it to me. So, we can do a few games. So, the first round could be a new ingredient test. So, the verifier adds like kimchi into the broth and

asks, "What's wrong with the broth?" Aha. It tastes more sour than usual. You must have added kimchi. And he might ask another question like, "What stage of cooking is this? at early simmer mid or ready and the prover say ah early simmer the flavor is still weak and you can essentially ask more questions and you can have more rounds and if the prover is basically successful in answering the questions it means they probably know the secret recipe and so in a way zero knowledge truths A

special case of this call like challenge and response scheme and how it's made non-interactive is through this process called viat shami heruristics and so there are bunch of number theoretic ways that allows you to make this challenge process in a noninteractive fashion by essentially encoding the challenge in a hash function. And so once you have this process, you are able to essentially design systems in this format where you have a prover and a verifier and you want to achieve something out of this.

And so just a fun fact, essentially everyone who's doing ZK and stuff, they are essentially trying to build businesses in this space. So it hinges on the fact that there are class of problems called interactive proofs and and the next other thing is that this kind of problems are valuable for people. So the design space in this case is when trust me bro is not enough and when you can construct things as a pro or verify a game and so this basically is what we have been doing for the past two years with ZK and also uh TESS as well as MPCs and so for the past two years we have we

actually had a different approach to I guess a lot of other companies companies in the space. We are focused on actual end use cases and so we are trying not to over complicate. So I think you might have seen many infrastructure projects who are going on the infra but then I guess like everyone is on ZK VMs right now. So we are mostly focused on the use case and the infrastructure that we have evolves as the design space evol uh changes and so we kind of want to get the destination you can't get the destination by a will.

Uh you can't just build like parts by parts to to build a better car. You have to start with like maybe a skateboard, build a scooter, a motorcycle, then a car. But you need to have an objective. And so this summarizes what we did in the past two years. So this is the first experiment that I want to talk about and it's on autonomous worlds. So how many of you here knows about this? Okay, I guess like this part. Um, okay. So there was this narrative. I'm not there's this metaverse stuff in autonomous worlds and so essentially people were trying to build

games on the blockchain and so the initial idea here was that if people are going to build games in the blockchain is it going to be very valuable. So it turns out it's not that valuable. So uh yeah and so most of the games I think have not much usage and I think the narrative has since died but the problem is that gaming has not died. So maybe everyone was building bad games. So uh yeah so essent essentially I think like the problem with this space was that people were teorcrafting more than building like games that people actually wanted to play.

But the interesting thing about this was that it actually helped with the initial development of our proving class stuff. Uh so there's this application called crypto idol.te. So it's a onchain karaoke game. Um but this basically allows us to test our uh zero knowledge through flow as well as improving class stuff. And so I kind of want to talk about an interesting idea that emerged out of this. It's like this idea of design fiction and speculative design. So when when I think of things like metaverse, autonomous world and super intelligence right now in hindsight, they might not be the end goal, but they are in effect an exercise in what the

future could be. So normally if you're trying to design something, you start with a present state and a future. You have a very defined problem space, but you can't think of what else could possibly happen. But if you add a catalyst like metavverse, autonomous worlds, super intelligence, very speculative ideas, it kind of extends what the future could possibly be. And so essentially what we are embarking right now is a form of practical science fiction. So we want to explore the speculative futures of artifacts. So you have actual objects to deal with and you can ask what is and also LRM have been making prototyping way much easier.

And so I think the biggest lesson from autonomous walls here was that we want to suspend disbelief first. F AF though try to experiment as much as possible re-evaluate and maybe something useful actually emerges and this also informs like the design philosophy that we have for the subsequent experiments. So experiment two is bit tensor. So has anyone used bit tensor or has heard of it?

I guess no. Okay. So, Vid Sensor is basically a substrate based chain and the goal is to essentially use AI inference as part of consensus. So, initially I thought it was a scam because it looked like a pyramid scheme from the outset. Um, but it turns out that the incentive mechanism was fairly useful in helping us improve our engineering quality. So, this is how it it basically works. you have a bit tensor root chain I think it's called fininny and so it will basically emit a certain amount of emissions each block and every subnet has like a particular function so they

might be specialized in some form of inference um like calculating uh a proof of training generative AI and stuff so it doesn't matter what the subnet actually does but it has to stick some power onto the bit sensor root chain to get some emissions And so they can be dregistered if the subnet has not enough usage. And so once the subnet is up, people can choose to mine on that subnet by essentially uh allocating uh AI GPUs into the subnet to mine fast uh to mine the uh the inferences.

So the miners can also be dregistered if they don't produce proofs fast enough. So if they get dregistered here, they lose their money. So as you can see when the private medial structure seems to kind of emerge. So basically you have the foundation giving out the tokens and essentially the miners are playing a game where I can run inferences of proof faster than you and therefore I will take your take your lunch. And so the miners will then submit the proofs to and all the inferences to like the validators and they will typically get a a reward after this.

So, so we suspended our disbelief and partnered with inference labs. Uh, so the use cases for inference labs has evolved but it ended up becoming a marketplace for verifiable AI inferences. So one of which is reward calculations for other subnetss. So if you want to prove uh all the various inferences like how do they amount to you can essentially use this chain. And also the other thing is restaking strategies. Um and so they have been they have been building a uh a marketplace for this AI inference and they also built it on is equal and certain so far and so there's some you interesting usage right now. So

we have around like 284 million fruits produced. Um and what is interesting about this uh experiment is that there is an incentive for people to make the system much faster. And as a result, we actually learned some things on how we can build the proof systems faster. And it turns out that most of the problems are not uh a difference in terms of like what proof systems to use. There's a lot of knowledge should be gained by essentially improving the engineering quality of the code.

Uh so these are some of the of the challenges that we did. So that's like Ezekiel optimization challenge. Yes. Ended about uh 76 uh days ago. And that's like a admission and a prize pool. And so we actually used games like this to also then improve like the quality of the codebase and also to find some optimizations. And there were a bunch of like small things that adds up over time. And now we are able to break these proofs quite quickly. So for example like the reward calculation proofs I think take less than I think less than 20 seconds right now and the smaller ones takes like a subsecond proofs um yeah but we don't really like show this numbers uh because

like the proofs are also like dependent on the circuit but we are able to get like subsecond proofs quite quickly on certain certain formulations. So the next experiment that I will be talking about is this thing called Cox. So it started out as an experiment in Eve Denver this year. So it stands for cleverly optimized and computed swaps. So I I think everyone who works in crypto or does DI does not care about actually really care about DeFi. People just want to press one button and make money on chain. And so that was like the teases like no one cares about this.

What's the closest thing we can do to press one button and make money? Um, no one really cares about intense D5 stuff here. People just want to make money. That's like the key point. And so, how can we design the one pool to rule them all? And so, this essentially uh led to this thinking around verifiable parameter management. uh you might start seeing designs like this emerge, things like fluid finance as well as oiler swap where essentially they're combining AMMs and lending protocols into a single pool.

Um and so uh we basically worked with balancer finance for this and so the experiment is actually still alive and it seems quite interesting. Uh so the idea here is to essentially combine lending as well as AMMS into a single pool but because there's so many moving parts you kind of need to then ensure that the moving parts are not going to break and that's where like verifiable AI actually comes into play and so this is how the scheme works. Um we essentially use balancer vaults and this concept of a booster tokens. Um so so what a boostered tokens means is that essentially like if you have a AMM pool with that's a USDC and ETH uh you don't need all the ETH and USDC to be utilized

for a swap at any single point in time. So you have a concentrated liquidity position you don't need 100% of it. So the remaining portions can essentially be put into a and so you can actually they'll earn even more yield uh instead of just like LP positions and so you kind of want to do some kind of optimization on this front. Then the next other thing that we can also deal with is dynamic fees. uh how can we essentially pre reduce like impermanent loss as well as like prevent toxic flows or can we even like rebalance the portfolio like for example if you have even USDC if the market is trending up you don't want to be back holding USDC

you want to be biased towards ETH uh so this requires some form of artificial intelligence and so this is what we have been building so we are mostly focused on dynamic fees at the moment Um, so this is like the experiment that we did. Um, and it seems to be quite successful. So this is like the unincentivized pool. So in so I just took it last night. So we had about 49% APR for LPS versus with static fees is 34%.

Um so we we managed to find a class of models using sigmoid functions that are able to do dynamic fees quite well and they respond to volatility. So some learnings about this uh good quant models like finding dynamic fees rebalancing stuff is actually really hard to find and so this where the z stuff might actually be sort of useful. Uh you don't want to share that strategy because it's rare. Um, and it turns out that volatility adaptive models are actually better than static fee models.

So that's also kind of interesting to us. So it means there some kind of memory associated with the optimal uh fee that you want to charge and it's not a single one uh markoff time instance in more technical terms. And in this particular experiment, we also shift from a ZK solution to also include TEES and MPCs. So this is where we started to also like maybe divergent into thinking maybe it's not so much about ZK. There's a spectrum of problems that we want to solve. So we need MPC and TE to pull the data off chain uh in a verifiable manner. And sometimes you also do need TDS for higher frequency

requirements like less than 30 seconds or even subsecond. And so if you want to see like the pools uh I can if I can share the slides you can click on those links. So they are live right now and they and if you want to earn some LP yields if you don't think RV and E would deviate too much you can basically LP this position. So it's mostly profitable when the price is not moving up and down between RB and E. So it's like more or less less you basically would be able to earn yield on that front.

Um then the experiment that uh we are also looking into and also collaborating with some partners is uh the concept of drug design. So this might be quite left field for most people um but uh it's possible to essentially design uh drug drugs with some something like AI right now. And so the problem that you essentially want to solve is this thing called protein lian affinity. So uh so given a particular protein and a lian you can more or less understand how strong like this chemical would interact with that lian. So, so you have things like hydrogen bonds, you have like co uh also

maybe coalent bonds and also like um like vendor walls attractions and and depending on the kind of protein structure that you get, you kind of have a guess on how strong this interaction would be. And so you can essentially then build an AI model that classifies the strengths of this interaction. Uh so this is how the scheme might potentially work and you can create a a decentralized marketplace around this. So for example, I'm a I'm a pharmaceutical company. I might need a particular drug interaction.

And so some other research companies might have a particular protein or molecule that they do not want to share but they can prove to that pharmaceutical company that they have the protein. So what the pharma company can do is pass like the uh the researcher a particular ZKML model and they can essentially calculate the protein like an affinity and produce a score and a proof. So they can then give the pharma company this affinity score the proof and if they accept the proof and it verifies like it means that you probably have the drug and you can create another series of negotiations around this. uh so this is also I think like some other emerging use cases which

we are uh beginning to explore and there are also a bunch of experiments that we have been doing in terms of um uh checking whether there's any hardware failures so so I have not added a slide in um but in future I can talk more about that um yeah but this essentially concludes kind of the experiments that we have been doing the things we are trying to do in future and I think the design space is much rather than just blockchains alone. There's like a possibility of just changing the way markets work in general.

Um, any questions? Uh, so this is the link to the Discord. If you want to ask me any questions or you want to use the library or any technical stuff, I'm there to answer. Are there any questions, guys, or or am I like too confusing? [Music] Hello. >> Can you explain me in specific like how one of these uh let's see demand uh how they demand your solution >> more interesting how people find this tech solutions interesting for their

product. Uh as in the demand side uh yeah it's basically me going around and asking people talking to people. Uh yeah it's it's quite manual like do things that do not scale. So yeah most of like the use cases turns out to be very much businessoriented. So it's not so much about consumers in this case. So we are talking to uh companies and and also having like uh contractual agreements. So uh yeah so the sales cycle for us right now has been mostly business focused.

>> So my question is more like what is being protected or is there something need to be protected by using your tech? >> Oh yes. So for example back to the yeah back to like this balancer finance use case. So you have like a vault uh everyone can actually be interacting with it or even like proving the parameters. So right now like the weights are still owned by us but um but essentially we we'll decentralize it and pass it to balancer and so you kind of want everyone to be able to run like this verifiable strategy and so there can also be a a market for how who can run and who should be able to run it as

fast as possible. Uh yeah so the threat vector in this case is that anyone can if if no if if don't have this verifiable element to it anyone can commit a value and so this is like the risk of something like a if so at one point a had bad debts so I think was due to like curve or something so essentially the guy took the funds like yeah Roman took the funds and and essentially convert the USDC to buy a mansion and so there was like bad debts and so you kind of need you kind of want to reduce counterparty risk on chain because you can't trust people all the time. Uh but fortunately I think like Roman paid off the bad debts and like Ave is fine but there was like a chance

that a could have imploded due to bad debts. Um, so there are problems like this, like things like bad debts or even like like higher risk scenarios in terms of like drugs or even like in defense applications where you kind of want to have uh a receipt of something to show that something was done properly. Yeah. So you can think of any kind of higher risk use case with some form of compute that is required. Therefore you need verification. [Music] Hello. Uh I would like to ask from the

perspective of finance and economics. I see that I'm very interested in this one about the balancer. Uh when we talk about portfolio optimization uh does it um the balancing will will um allocate the percentage of Bitcoin USDC USDT in your portfolio. Is it the function minus or just another functions? >> Uh so the rebalancing approach is quite interesting because if you so you can so balancer has this ability to set cool weights. So for example, you can set it as 2080 and and it could be dynamic. So if you gradually interpolate the the

weights uh it essentially in incentivizes arbitragees to then shift the weights. So for example, let's say I start at 50% USDC, 50% E. I can shift it to 5149 and it creates an arbitrage opportunity. Yeah. And at the moment like the pool changes the weight. So arbitrage chargers can come in and then swap to earn the profit off. So essentially like using arbitrage chargers as a way of um of rebalancing for you. >> So it is very similar to program trading.

>> Uh yes and we also essentially utilizing game theory to help you rebalance through arbitrage mechanisms. >> It sounds good. >> Yeah. So it is like so so the arbitrage stuff is done by quantm. So it's another team we are working with. So they used to be like qu in like high frequency trading firms and also uh our team like Danty and I do qu stuff at some point in our careers. So we essentially just applying our strategies here.

Um yeah for yeah most of the strategies we found out they're quite simple. So we're not using like very large language models. They are essentially like onedimensional time series where you use things like less. So um yeah, not too complicated. The more complicated the model is, the more likely it will eventually fail. And so we're trying to prevent that scenario. Uh I [Music] Twitter

this coin. Uh, [Music] CPA. [Music] Yeah. >> Uh sometimes