Learn about Brevis - ETHGlobal Bangkok 2024

[Music] hello everyone my name is Mo uh I'm co-founder of bravas just quick introduction on myself uh you know I did my PhD in computer science in um sold a company in networking security before and uh uh you know started in the blockchain industry uh since 2018 uh let's start so uh braest is a smart Z Cod processor so what is ex C processor well you know we we have seen blockchain Evolution uh for so many years with layer two layer uh layer ones introduced but you know there are still blockchains and these improvements are still not enough in the sense that all of these constructs are still rely on distributed consensus and the blockchain as a construct itself is generally bad at data R and heavy computations so you know uh using just like directly using kind of a a very relevant example right so if you look at every centralized exchanges they all have something like a la Trader loyalty program uh you know which basically works this way uh you traded a lot in this month say like you traded like $10 million this month and in the next month you got a trading fee discount and this is how they actually attract a lot of professional market makers and you know have very efficient price discovery on daxes directly and you know in fact most of the volume and and revenue uh on these centralized exchanges are actually generated by these Traders with special fee arrangement in a very high volume but if we look at every decentralized exchanges you know this type of feature simply does not exist you know why is that well you know it's not because uh you know taxes don't want to implement that it is actually because to implement that the cost is extremely prohibitive so like even if you want to just access a single users historical trades let's say you know in the Unis swap case you know uh if you just want to access like what are the trades that done by this user in the past 30 days let's say there are 10,000 trades the cost to actually compute that you know trades and access that and validate that these user did all these uh swaps and the calculate the total transaction volume or trade volume will cost you four hours of block time fully packed block on ethereum four hours and 20K in transaction fee and the 20K is actually kind of a lower number that we we we got last year this is probably much higher this year so why is that right so if we think about it how we can actually compute a user trading volume today onch directly well you know it's possible but it's extremely expensive first we need to remember all the historical State Route uh on the blockchain directly basically what are the uh you know block headers uh that happening in the past and therefore that we can actually retrieve the corresponding transaction or corresponding event that is generated by this user and uh you know then we need to calculate let's say 10,000 Merle inclusion proof directly on chain which is extremely expensive and then you know we only got you know this only got us the leaf node Leaf node is encoded RP and we need to decode the RP to find the actual trading amount and finally add them up uh onchain directly so this operation needly to say is extremely expensive you know well this is a general problem for all smart contract not only just Unis swap right so if you you you are a smart contract and you want to access historical unch data such as transactions events storage States who held what what token what is the trading volume if this user have use that protocol or not this type of information in smart contract directly there is no good way to do that today so there's no trust free access to historical Laing data and there's no trust free access to data on other blockchains and you know the result is that blockchain as a as a whole is bad at data driven and very complex computation so this is aware a Cod processor is needed you know in this architecture blockchain can just focus on transactional computation which is like basically you know the asset movement and the asset ownership changes and all that but the wise of why these assets get moved and you know this type of data reach and complex computation driven uh you know that is driving a lot of business logic can be offloaded to a co-processor that is offchain not in the blockchain and the co-processor will do the computation and return the result back to the blockchain but the key thing here is that if we use like opting centralized server to do this that's fine it improve a lot of kind of you know efficiency and capacity but we lose the trust free nature of blocking so the important thing about this architecture is that we can do this but we should do this in a way without compromising the transfer nature of blockchain this is why we need to use a z coprocessor to essentially generate a trust Ray proof of this blockchain data that we want we want to access in smart contract and also generate a computation proof on top of these data that you need in the smart contract and then use that ZK proof to verify the onchain easily and inject the result into the smart contract and drive business logic so this is what um you know brv does uh brv is a z coprocessor that can generate ZK proof of arbitrary computation on really any data and therefore it allows smart contracts to utilize these computation results that is based on historical oning data uh directly in the smart contract in a trust freeway so uh integrating bravus into this uh application stack is actually pretty simple so even though it is a ZK build uh you know we actually provide a very easy to use SDK so that developers uh don't actually need to uh know anything about Z circuit writing so there are really three simple steps here the first is that you need to read the data you want to read like you need to specify what type of data you want right so you know for example we support storage State block information receipts which are essentially transaction events and you know Bing States uh transaction itself like whether this transaction is successful or get rejected you know account information like account nons on all these supported blockchains and I'm showing a very simple code stamp and Jun now we will talk a lot more about this but this basically you know enable you to add transaction uh events that is relevant to a users swap event so this is how you can kind of essentially specify okay I'm interested in getting users um you know trade event in the past on uniform and the the second part is to actually do computation on top of these data gathered in the first step so uh for the computation we actually provide some very easy to use data stream apis where you can basically apply map reduce sort filter zip group bu uh based on the data that you gathered in the first step so this uh you know particular example basically shows that how you can you know with you with very very simple code based on our API to calculate a user's trading volume on Unis swap uh in the past right so uh you know it's very easy to use kind of computer apis wise and finally you know what you what you do is that you put you need to put all these data um and you know computation result back to the blockchain where you want to use it right so let's say if you want to implement a trading fee uh you know discount based on trading volume then you know this result this users trading volume result will be pushed back to a uh you know hook contract and the hook contract will have some business logic to check okay what is this user trading volume is this user trading volume higher than you know 10 million then this user is like a you know VIP tier one if this user's trading volume is higher than 100 million this guy's VIP tier three and the corresponding like assign different kind of a tra you know discount uh value for the user right so you know in this example that I'm I'm I'm I'm kind of working through so like this kind of a h contract will be receiving the result from the Z code processor import it's it's very important to note that once the call back is actually received by the application smart contract the entire computation and the data validity of the computation is already ZK proven what basically you know in plain terms what that means is that you know um if you if you gave the blockchain a you know result saying that the user traded like $1 million uh so in the last 30 days you can be sure that this is the case without actually trusting any CER party you know and the other than the blockchain itself right so let's say in the hook example you recorded what is the uh you know users's VIP tier and in the next month whenever user actually do another trade um you know there will be essentially kind of a hook that is looking up into the VIP table and in that VIP table you will see like this user qualifies for a certain discount and this is how a dynamic fee hook can be implemented uh you know by uh you know uh kind of combining the power of the Cod processor and the unisoft hook architecture so uh you know uh Bri is very much production ready um so you know uh to put things into context to prove trading volume of 1,000 transactions on Unis swap uh you know we you know on very very simple cluster of gpus very you know just like consumer grade gpus uh the cost of do doing that is $1.8 and latency is 141 seconds so let's say if you want to do this for the entire group of Unis swap user uh what does that mean right so like you know to put things into you know more detailed context uh Unis swap on monthly basis process about 4 million trades and uh you know BR using this very simple setup uh can handle about 19 million trades proof capacity it means that you know you can handle almost five times of unit capacity and uh you know the monthly proving cost if we want to prove the entirety of Unis swap transaction is just $7,000 comparing to the Unis swap protocol Revenue which is like 14.7 million uh which this is just a tiny tiny fraction of that so basically means that the entire kind of cost profile uh and you know kind of a unit economy here really makes sense if let's say through this type of VIP program the Unis swap the uh you know entire monthly fee or monthly Revenue can be improved even just by 1% the return on investment of this type of feature is 20 times because of the low proving cost so there are many different type of application you can do actually with brev not only just on hooks but because today we're uh in the hook incubator program I will kind of focus a lot more on what type of hook you can Implement right so uh you know hooks are under the category of you know what a use case what we call data driven defi so in defi protocol there are a lot of data as that is accumulated in the in the protocol over time such as LP deposit withdraw swap event liquidations what is like the price movement of different uh uh you know asset uh you know what is the open interest in per protocol so many more right so you can access them all using bravis and then you know do computation on a collection of data you accessed and you know the computation result then can drive uh Dynamic protocol fees and dynamic protocol parameters uh you know this uh is several these are several examples that we think are very uh you know interesting and can be actually applied to specifically Unis swap HKS the trading volume based fee discounting I already talked about it's very simple to implement we have a reference implementation for that so that you can actually can we use that as a basis to build other things another very interesting thing is the lvr compensation based on Market volatility right so you know uh because uh brav can allow uh you to now access a historical price feed essentially like you know the tww uh you know record is now available to access so you know uh you can actually build this type of hook that uh periodically receive leaves um the volatility proof generated by a bravous application and you know um that hook basically can feed that into a dynamic fee hook uh if the volatility is high then the entire pools uh fee can be increased so that like the LPS in these pools will be protected protected more and essentially kind of compensated a little bit more um you know uh to uh reduce the lvr that is exploited based on uh you know on top of them basically so another very interesting thing uh you know we have been looking at and also collaborating with some other teams on is this ritual perspective mining reward based on fee generated in each of the lp position so today if you think about uh you know uh Dax farming reward program it's very simple it is time L based farming reward uh but timel based farming reward is actually pretty harmful because we have observed on ching with very clear evidence that there are smart LPS that are just removing their liquidity whenever the market volatility comes they basically can of monitor the centralized exchanges as soon as centralized exchanges start to show high volatility they will start to remove their liquidity from the uh you know from the market so uh the end result for this is that you're Distributing a lot and even majority of the farming reward to a bunch of LPS that are not actually providing liquidity deps when it is needed most so instead of just Distributing uh farming reward based on the time length of LP deposit what we should be also looking at is looking at what are the fees generated by each of the lp position so and we should put that as part of the farming reward distribution uh you know wait to essentially kind of build this appoc based farming reward distribution mechanism that in dur uh at the end of each EPO we do a retrospective examination of all the lp behavior and you know essentially kind of a you know reward those LP who held the ground and provide liquidity even when the market volatility comes and we we we kind of you know uh make make these guys have higher weight when Distributing farming reward and there are some other ideas such as token holding based the feed discount let's say you are a protocol then you launched a pool on unit swap with a protocol token and ethereum or with a protocol token and stable token and you know uh of course you want your actual user to be uh to easily get the token without actually paying any fee right so one way to do that is to essentially generate the proof showing that a user is a uh legitimate holder of the protocol token and the legitimate user of the protocol that you care about um you know uh using ZK proof generated by bris and you know that ZK proof result will be recorded in the whole contract and uh you know to activate corresponding fee discount when user tries to trade or acquire or sell uh the protocol token because they are actual active users of the protocol so they should be benefited basically from that and uh you know there are many other ideas such as ideal U you know Freight trades based on oning OG setus that is like this is kind of a user gating feature where you can generate a proof showing that hey this user is really kind of a heavy user pre the pre- token launch and therefore they should be eligible to enter the uh you know Market earlier than everyone else to essentially do this Ideo process uh on un swap that will be also be possible and uh you know also for some of ogs uh you can essentially kind of offer them zero free trading for protocal token to make it easier to get prodoc token and have easier price discopy whenever the token is actually list initially listed on Unis Swap and you know user acquisition is also another thing where you can essentially uh say that okay you know I can generate a proof that this user is Big Trader or holder of you know certain token in other protocols or in other pools that is competing with like whatever you guys uh you guys buil and uh you know um with that you can actually kind of Grant fee discount or even additional reward uh when the user you know let's say purchases a uh you know this token in the pool and become a user of Eur protocol and uh there are so many more ideas but you know the the the high level thing here is that you can now uh think about like kind of the data not just in one point of time you can to think about the data uh you know in a much longer time Horizon basically the entire history of blockchain if you want to access any data any user uh that is not even exposed by smart contract call right because we're proving not not we're not proving kind of a function cost we're proving the entire blockchain States and all the transaction that happened in the past so even if there is a let's say a a state variable that is not exposed it's private it's not exposed by any kind of a uh you know public function you can still access that very easily using BR and there are many more ideas that you can and except you know other than hooks there are many other things you can build like such as trust free active liquidity management that you can essentially allow this onchain hatch fund to prove onchain that they're moving their your liquidity or moving your LP position in you know Unis swap or any other taxes or any other protocols uh you know essentially Faithfully B based on a predefined algorithm and arching triggering condition uh so they're not just ually moving things around um and you know uh you can also do uh transfer temporal intent based automation today intent automation is really done in a centralized way that the user specify a intent and a trigger triggering condition and the automation solution will carry out intent whenever the triggering condition is met but you know um it's entirely up to the uh uh you know a uh services to uh you know to kind of Judge whether this triggering conditions matter or not but with brev you can actually directly prove on chain that the predefined triggering condition such as volatility such as price um Target is actually met and therefore making this entire automation protocol uh intended automation protocol trust free and you know you can also do aching identity a lot of aching identity related things such as proof of humanity proof of pro TR OG proof of risk based on uh you know different users uh uh you know behavior and kind of a cluster them um you know together or figuring out common features for a group of users to kind of attack them collectively and from kind of a user from a per uh per protocol or application perspective uh applications perspective uh you can also build user value profiling or U ux personalization based on users historical interaction with your protocol and maybe with other protocol as well and this of course applies to not only just like a ux personalization but also user acquisition uh similar to the uh some of the hook ideas that I mentioned that you can essentially offer uh you know uh a benefit for uh users who have demonstrated uh to be kind of a high engagement and you know uh frequent user for some other relevant or you know partner protocol partner protocols uh you know uh for you and there are many different other applications Arrow you can use braev for um but you know this uh talk is really kind of focusing on um you know the hooks and the uh you know how we can build that so feel free to reach out to our Twitter and also have my telegram here in the slides uh you know feel free to reach out to me directly as well on the high level as a developer if you want to like benefit from this new paradigm of finally you can have a database uh in your inside your D app you need to uh you know write something of course the Z part is not something we can magically pretend it doesn't exist right because all the trust free uh the good property of trust free still depends on the underlying ZK circuit but with our SDK the developer does not need to worry about the lowlevel you know ZK details in instead they can focus more on their intent I will actually show you actual API examples then you immediately understand what I'm talking about like map reduce style data analytic apis on the high level the the workflow is the developers offchain component will run some you know query to the indexer or some RPC endpoints to collect the data points right it could be transaction the receipt like if we talk about specifically the trading volume example uh the trading volume the the amount will be emitted by the events right so actually that exist in the receipt of inside each block in a transaction and then the circuit will kind of work process all these data points and say compute a simple sum all those you know proof data is later passed down to bravis Gateway because remember after you prove this that this piece of data these thousands of transaction receipts are you know valid there's and you do a sum over all the amount you still have one last thing to make sure that all those blocks are not you know faked or forged right uh just a second I think I just can you still see my screen or uh yep we can see it okay yeah I think it just the it access the full screen mod right so um and that's why the brevis service will also take care of all the you know proof aggregation and finally sent the single suent you know ZK proof onchain to the bravis core contract and finally the result will be know using a callback Passover to the uh D app uh specific business logic like Mo mentioned earlier the example could be you receive the trading volume as a result and you can assign different you know uh VIP tiers to the to the address and to we we kind of have the very high performance goal B goal L based SDK and then we realize oh there are more developers familiar with you know typescript and that's why we kind of also add this additional uh a hybrid mode I would say so the the developer will still write the TS uh typescript to kind of do the data preparation part uh but the ZK circuit SDK will still be in goal all the blue boxes will be the the code uh you know the the DF developer need to write now kind of where the the Unis swap uh trading volume basically let's just know keep that as a use case in mind and let's work through as a DF developer what what exactly you need to work on right so the first thing is uh within your typescript you need to say oh I want to initiate or how to start a new proof request you will realize what's actually is the proof is actually another another instance Rong by the developer and inside this proof request is all the meets right so basically we talk about for uni swap particularly the the swap events right there are you know different fields we need to look at say oh this is the say the trading the amount right for each swap the amount we are interested in because finally our uh the the logic requires we sum all the amount from the receipt this basically is uh within each uh receipt or event what are the fields your the developer need to be you know uh cared about and also provided to the appr because the proving itself is more like uh uh the bite coder and then you need to fed the actual receipt all transaction data if it's other use cases uh to to the to the ZK circuit so these are the example all the detail breakdown of you know the the contract address will be the Unis swap usdc pool and the event ID is the swap event and then the field index basically tells which field you are interested and the value is basically based on the the meaning of each field and then you you might ask why we have you know there are there are three events in here there two of them are uh the actually the same event same swap event but different fields inside the event and you might be asking why we need the third one the third one is actually the event is emitted from the the actual usdc rc20 contract it's the transfer event because uh when user interact with Unis swap right they they always go through the route not always but most user will go through the the the swap router and if you look at the event the swap router will be the cender and the recipient of you know is inside the swap event but that actually you know make it a little bit more uh tricky to to know who is when you need to track the actual trading volume you want to attribute to the final the actual user and not the swap rer so that's why the center of usdc actually tells you if the recipient of the swap is the router address the actual sender basically this is the the transaction the user sends in uh usdc and in return gets if right so the the actual sender in the transfer event is the the user address you should attribute this amount to now it's the it's a part you know of course we have fully working example code uh on GitHub the the app circuit part is also kind of uh try to capture the high level intent so the first thing is you need to tell the the brevis underlying system what will be the max maximum number of data points you need to handle right in this case we only care about the receipts then it's up to the DF developer to decide oh do I handle a 100 or thousand or 10,000 of course uh ZK technology being you know still in early state today uh larger data size uh incur uh close to linear uh you know uh cost so basically be prepared to pay more and also maybe also wait more longer for the proof right and then the Define is all the actual you know ZK circuit inside but again with you know brav team and team did all the heavy lifting inside the SDK you will see in next few slides uh the actual compute is very intuitive uh it it closely matches the the classic you know data process of data analytic apis like remember we we talk about the trading volume example right so you will basically write uh like in the map reduce style you will say oh for each receipt what I'm interesting is this you know amount field and if you want to do a simple sum we provide this ready to use know basically essentially A reduced function just sdk. sum and that's it that that's the only code you write so instead of writing any you know Loop by hand or anything more complicated this is all the computation you need to write you know in terms of with with brevis SDK and after this you are done you just wait for you know inside your DF contract to receive the results and here you know to be able to provide more uh examples we have the sdk. M basically to give you the the uh the first uh block numbers but but again these are more like we try to show different ways different computations possible with the SDK it's not strictly required as the minimal if you only look for the minimal example you don't need to worry about the block num right it's just the volumes okay and in the end you will say after your you know uh offchain component compute this result you need to Output that so that your final unchain contract can receive them right so this will be how you decide to encode the final result because you know for the Callback interface to be generic we basically pass in a bites that you require the D app developer to to parse it by the by themselves within the contract and the the simple way is just you know API encode pack to basically con at this you know fixed sze uh field together and then within your smart contract you match the the encoding order and just to Decode by by yeah and I think that's down so basically the offchain component is done and that's it the Now we move on to the onchain contract uh ignore the the boil plates there is only one uh function you need to implement it's also the name is very self-explanatory right it's handle proof result basically after the ZK proof is verified by the bravis call contract the bravis contract will call this handle prooof result of uh your DF contract and say hey here is the result right the the last argument The Bu called that a circuit output is exactly what your brav circuit code output remember we we have this kind of simple encoding uh basically conat this thing field together right and then in your contract you receive this ConEd bites as one argument and you will do something called decode output here because in the circuit we concare this field together and you know the decode is also very simple just to find the right offset and you know pick the field and assign to a value and that's it so after this right after you have the uh decoded the the circuit output you have all the information you need and next step is actually not implemented in inside our example contract is what do you actually do right based on your own business logic to to say for example assign a different tier uh based on the volume or you can do something you know even you know fancier that that's kind of up to each D app the app developer to decide yeah a final notes on unit swap V4 right so if you uh do want to go with the the dynamic fee per Trader based on the trading volume there are kind of a little notes here when the pool was initialized uh you need to pass in the dynamic fee flag and also inside the before swap hook uh remember to you know call the update Dynamic SW fee based on say the trading volume uh give the fee discount all you could just do something directly say it's a inverse of the trading or something you know up to complet it up to your your use case and Imagination yeah yeah I think that's all from my side for the an flow and you know for any developer really want to get hands on with brevis SDK and get the feeling like instead of you know just a simple there are some examples you know inside the unisoft V4 ripples for a dynamic fee but I kind of feel it's very limited if you if your Dynamic decision is purely based on a current you know transaction right that's so for example some example say you you want to do a different fee based on a trade amount but that's actually I wouldn't believe it's a good idea because let's say you give some pre preferable treatment to some amount what will happen next it will actually uh make all the Traders optimize their trading amount to match your your code right because everything is public accounting so I think without um a trust free historical access uh the dynamic fee implementation purely based on or what's currently available inside this trade uh the use case or the the actual you know uh applicability is very limited yeah okay I hope you know uh feel free you know if you run into any issues we went to different hackaton before like at e stver and had many successful projects implementing way more complicated stuff not only limited to unisoft V4 but with the Unis swof V4 hooks we are very excited to see you know people Leverage The Power of this whole trust free historical access and you know G gave the the hooks a kind of a completely new uh applications right yeah that's all from my side [Music]