Use ZK Coprocessor to Build Data-Driven dApps Without Writing a Single Line of ZK Circuit | Junda

[Music] hello yeah it's s yeah thank you for coming uh I'm jinda from brevis today I will talk about what is brevis and why do we need one and if you ever heard about someone Ming ZK co-processor what the dam it is and how it can help the etherum ecosystem right so without further ado let's start imagine you have your amazing D app and you want to keep your loyal users happy naturally you want to have some program to kind of give them a rebate for the trading fees right like basically you know it's kind of already there in every single Central exchanges right you you are a VIP Trader you get a discount in the trading fees of course today it didn't exist on on Dex say some user like a big will have done many many trades like 10,000 swaps on your D app uh over like a month by the end of the month you say okay maybe I want to show some appreciation to this big user so to keep him stay or keep him or her stay within your app right instead of being kind of attracted by other API higher API projects there could be a lot of money in play here because if you ever look at like unisoft or pancake or any other like uh def5 protocols the fee uh revenue is actually pretty astonishingly high and on the other side the project does have the incentive to say uh maybe we don't really need that because from the protocol level it never treat big wheels and normal user differently can you do that in theory yes because ethereum is supposed to be a tur complete machine right but only in theory if you really think through what you can do I think uh uh two talks uh earlier uh the the researcher from um chain light he talks about how to access the historical data on chain is no no single Feit and it's very prohibitively prohibitively expensive first you have to remember all the historical State roots and that's only the beginning you have to compute the entire moral tree for every single Swap right it it could be in one of like 100 transaction within that block and for every single transaction it happened is it has its own merco tree from the leaf up like 10 levels higher to the state route and that's not all that's not all if you look into the data there's something called rlp encoding it's one of the smart people from eum Foundation you know in the early days say there are so many different encoding method why don't have why don't we add one more right so rlp encoding not never never intended to optimize for efficiency if you ever look at something it actually has many many zeros in there it takes a lot of space but you know it actually works for etherum specific use case just when you say okay I have got all these you know obstacles solved the last thing how do you even compute the aggregated trading volume you say okay maybe I have to get some number for every single Swap and sum over 10,000 transactions if you ever write something like offchain it's nothing right like even you can today you can go to Dune or graph ask similar questions like that but if you ever try to do it within your D app within your smart contract the short answer is just forget about it the the limitation comes you know not from the pure guas perspective the first thing is there's no trust free access so unless you say I'm willing to spend like 3 million guests just to verify one single transaction happens last year or last even last month and the second problem we have we are facing is uh even you say I get every problem technical challenges solved my app works perfectly on ethereum what about all the other evm compatible chains what if you want to have a Omni chain application that aggregate users liquidity across different blockchains you are facing the the same problem again but in even in the you know in the EXP finantial way if you are ever want to run on three chains you actually have to consider uh three different pairs the last thing even with sum calculating a sum over 10,000 transaction is already close to impossible to be to do onchain many use cases actually want to do even more complex than that actually we actually have a partner at actively kind of calculating a user score based on transaction behaviors you know uh which protocols the user is interacting with right so this data all kinds of data just like a traditional web 2 uh company or web2 product will do a very detail user profiling based on the user interactions with different protocols like how the user you know uh like to interact with or does the user prefer to go with defi more or like play game f all those informations today actually is available on the blockchain and there are offchain solutions that c essentially a centralized database say oh I can tell you what this user is like but up until now there's never a trust free way to say you can reliably trust freely using this information you know within your smart contract that's where the co-processor concept comes in it's just like you know GPU everyone I I assume everyone here knows GPU is you know a natural co-processor for CPU back in the in the days right when Nvidia first was founded it actually was questionable people are asking why do we need a separate co-processor for some specific task wouldn't CPU be good enough today no one would ever even you know consider that as a valid question right of course we see the value from a co-processor so here our belief is ethereum being ethereum right to foster a a very vibrant and prosper ecosystem it also needs a co-processor that's based on zero knowledge so for all the transactional computation all the you know High uh critical data you want to save and you can afford to save within the ethereum state you you should still do that but for all the computation data analytical demand like the data reach and complex computation you offload to the Cod processor to the ZK Cod processor without compromising any of the trust free assumptions so that's where bravis comes in in short bravis gives every D app developer the ability to run arbitrary computation over any historical unchain data again it doesn't limit to ethereum right it's Omni chain any chain we already support you can leverage the trust free data proof and it generate a very easy to verify a testation is basically we call ZK proof onchain So within your smart contract later I will actually show you the the actual solidity code it's literally two lines you know I'm actually joking the the lines of code you are writing may be even shorter than the topic of this talk yeah so on the high level only three parts as a as a developer you need to worry about to to leveraging the power of brevis first you go your normal query route right you can ask graph you can ask D you can ask any RPC endpoint to get the raw transaction data or storage value or like receipt like which actually includes the event in there right then there is a a piece of uh special circuit code that's the developer will write using our SDK and the last step is the final unchain within your smart contract you will get a call back after this whole ZK result has been verified by the brevis call contract said yeah this is the correct proof the Callback will notify your app contract say here is the result you were looking for like one of the example we gave earlier is uh the Callback can pass you a ZK tested verify the result of the trading volume of this user and naturally you say Okay based on the trading volume I can do different things this is a more detailed breakdown with you know components the green parts will be written by the uh DF developer on the right side is the brav system we have the onchain contract and also the offchain part that does the ZK proving the call Flow is actually pretty simple with the what the DF uh developer need to worry about is simply what result is of interest and then how do I get it right is it from the receipt is it from the transaction or it's from the storage after that literally you just pass on to the previous SDK and call a single API called proof underneath of course there are magic happens we also use like parallel GPU to accelerate to reduce the uh you know latency but from the developer perspective what you you can expect next is a call back to your unchain contract say hey this is the result you were looking for and go ahead use it whatever way you like yeah the data preparation as I mentioned earlier is ethereum has three kind of different call like like the data types where of Interest one is the receipt the which includes the event like you if you ever look at the D5 protocol you know you can see how much money goes in about how much uh you know a different token a swap token the user received is mostly you know saved from the event so that's why you need receipt and the storage like the erc20 balance that's one of the typical example of the storage like the user score example I gave earlier uh some project might be interested oh is this user an OG for like ape right or any other nft projects and or how how many like certain RC token this user is holding the last one is a transaction which actually I will show you later in a very simple example the Second Step the component the developer need to write is a ZK circuit right which actually sounds scary and does you know before we scare many developers away right uh how do you figure out the prime field and all the curves but the good news is you do not you do not need to even though in the end the pro the the final code you are shipping is actually a ZK circuit but we actually have done the hard work to hiding all the complexity underneath and only provide a very intuitive and easy to use apis like like down to the bottom only two apis you need to implement the first one is called allocate and the second one is called Define we later I will go through a concrete example to show you what should be in this function but you know from the high level take way is even for someone who didn't have a craphy PhD degree they can write a ZK circuit using bravis SDK and remember we focus heavily on data analytic so we know that only provide the pr primitive basic apis are not enough so we look at all the um Partners requirements oh some are looking at more historical Trend some are looking at abnormally from the transaction so it's all fits very neatly into this traditional data analyzing pipeline so that's why we actually provide a data stream apis that's look very similar to the map reduce right basically you start from the raw data you kind of have the map to uh set up the first stage and get intermediate results and in the final reduced side uh in the reduced phase you get whatever the final actual result your interest is yeah so on the high level it's map reduce and you know if I ever do some summary over all the a transaction volume is simply a sum yeah this is the Callback function I mentioned earlier within your smart contract you only need to implement handle the proof uh result which actually gets called only by the bravis call contract now let's go through a very straightforward simple example for many applic ations they want to make sure this is not a new account like mostly for security concerns so simply put we want to have a cheap way to prove this account has exist for a long time right so the allocate function basically return what are the datas are you your app is interested in because here we are only interested in the first ever transaction from this address so we don't care about any receipts we don't care about any storage so we only care about one single transaction and in your app circuit code right again you are writing actual ZK circuit without writing any single line of circuit code calling the brevis SDK API you only need to say give me the first ever transaction and I just need to verify the Nots in this transaction is zero right simple as that because that's the ethereum guarantee the first ever transaction from address is not with not zero and at the same time you say let me also remember the block number so the condition is this transaction must have non zero and the result is the address and the block number yeah after you write your uh app circuit code you will call SDK proof which sends the thing and ask the bravis back and to do the hard work for you and in the end submit the proof onchain within your onchain smart contract code you will receive something called circuit output remember we say your result has two parts one is the address the other is the block number so that's why you see the decode output actually return the transaction basically the TX from is the from address and the block number now it's up to you to decide what do you want to do with that right maybe you say oh if the block number is old enough for this address I consider it like uh old enough address lower risk that's pretty much it you know I wish I can have more code to show you but that that's just as simple as it if you want to learn more scan this QR code also we have very fully detailed document um you know on docs. bravit do. network and also remember to come into our boost uh starting from 29 I think on the next venue right we will have you know if you ever run into any questions we also have our uh engineering team there to help you okay that's all for my talk thank you