Why ZK is Perfect for Offchain Computation with Brevis

Transcript

all right guys welcome back to the rollup today we have a presentation around zik coprocessors and the relationship of brebis and igen welcome to Igan lay unlocked an interactive educational Journey Through the Igan layer ecosystem created by technical Founders and builders for the entire crypto Community a special thank you to our partners all lir polymer authentic skate and lrange for helping to make this happen our goal is to raise the collective knowledge of the igen lair ABS ecosystem and unpack the technical designs of the top teams in space welcome to ig lay unlocked all right guys welcome back to

the rollup today we have a presentation around ZK co-processors and the relationship of brevis and igir what I'm looking forward to today is to understand uh why a code processor needs to be in ABS what advantages there are as well as the security implications so looking forward to kind of diving into the the the technicals of what a co-processor is and then why it makes sense to be an ABS welcome Mo really excited to have you here and let's jump in hey guys uh great to be here uh I'm Mikael I'm co-founder of brevis and uh I'm here to talk about uh you know how do you use breev which is a smart Z co-processor to B to build data driven depths and before we dive into what co-processor does uh let me kind of use

analogy so that everyone can better understand understand what the what are the purposes of ZK coprocessor so let's look at the history of w 2 Evolution um in the last 20 years so if we look at web 2 before 2000 it is really built on this asynchronous based architecture where you have a single web server that does everything so every users's request will come into the web server in a sequential Manner and the request is handled one at a time and This montic Server really does all of these uh you know things in sequence in a sequential manner so request handling Access Control computation data access then return to the user the result of the request uh it was very clear back then

you know as the scale of Internet explode uh this kind of architecture won't really scale because this is really bu built based on this very synchronized and monotic architecture this is why in modern web today we are powering the entire modern web 2 word with this asynchronized space architecture where the web server itself is just acting as a coordinator of a series of specialized bankend Services now all these different users can essentially query this web server and the web server will just turn around and call these specialized Bank backend services with asynchronized function call and these specialized backend

services will do its work and then send the result back to the web server with callback functions and then the web server acting as again a coordinator will assemble the result from different specialized services and return to the user a coherent um requested result so this is how for example Facebook um Twitter uh essentially every web tool service work and this is how it can scale because now you're not limiting to uh the computation resources of a single server instead uh you have the single server to coordinate multiple of the server resources to work for you in a concurent

manner and in a scalable manner so this is how we scale web 2 now if we look at web three today the situation is actually worse than web two before 2000 right now the smart contract platform or the evm mostly are acting as the synchronized web server essentially the smart contract has very very simple computation capability and it it also have very limited data access capability for example you know smart contract can only access the data in one point in time which is the current point in time there's no way for smart contract to actually access historical onchain data such as events transactions and states and because the smart contracts are

running on blockchain which are essentially replicated computer and replicated storage um distributed system you know with extremely high communication overhead so we are actually in a much much worse situation that web 3 today because you know we're actually in a much worse situation than web 2 because the computation resources is even lower than a single server so how can we break this right so you know let's first understand the problem a bit deeper for example if you want to build something very simple such as a Trader loyalty program which is available on every centralized exchanges someone traded a lot in the last months you know um and then uh the the the the

centralized exchange should be giving the user a trading Feit discount in the next month this is very simple and available in every centralized exchange but if we look at all these smart contract power daxes none of them has that particular feature the reason for that is because as I mentioned running this type of datadriven computation on blockchain directly involving involves doing a lot of Merle proofs oning directly and this kind of a extremely complicated the expensive computation makes it invasible to run on Smart contract platform for example if you want to generate a single proof of a single user on Unis swap for a month's worth of trading volume the time it will

take is eight hours and transaction fee uh is 40k so what this means is that on only the smart contract platform that or any smart contract or any deps there's no trust free access and computation on historical uning data available now what brav does here is to introduce this asynchronized architecture to web stre where if you use bravis the you can treat the blockchain as this simple coordination layer for offchain computation resources now instead of doing all the computation on blockchain directly you can migrate very complex and data heavy computation of the blockchain into an offchain

environment and in this oping environment you can do the computation and not only the computation result is done but also you can generate a zero knowledge proof to attach to the fact that this computation is correctly done and then you can take that computation result along with the zerge proof back to the blockchain so that blockchain can run a very simple verification process to verify the computation is correctly done and use that competition result directly in smart contract using this architecture you expand the capability of blocking onchain computation to tap into effectively on limited the computation resources of Ching but at

the same time you're not introducing any additional trust because every computation step is encapsulated in zero proof so that you know every single step of the computation is done correctly as long as you can verify the competition result on chain so there are multiple components uh in brav stack today I'm going to focus on just the the ZK data Cod processor part what ZK data Cod processor does is it you know allows you to do this type of very specialized computation on of Ching that allow therefore allows smart contract to have access to any historical oning data and do computation on that and you can use

these computation result on Ching in a transf fre way now you know using prev ZK coprocessor is very simple from a developer point of view even though it is built on ZK you don't actually have to uh understand anything about Z circuit itself uh the first step you need is is to just specify what kind of historical data you want to read such as story State block information received Beacon change dat which include what is a gas price for example transaction data accounts so all of these data um you know are available for developers to to choose and use for example this very simple code stamp here uh demonstrated you how to um access a users historical traits on Unis

swap um in the last 30 days and then the second step is you know now you have the data available what kind of computation want run on top of these data so we provide a very easy to use data stream based API where you can manipulate the data you get in the first step using their very high level and easy to use API such as map reduce filter Group by sort and zip and you can calculate things like sum you can calculate things like average you can do filtering based on certain criterias you can merge different data together to construct into complex Logics and you know of course we support all the basic Logics and arithmetic computation on top of

these data so for example this three lines of a code allows you to calculate a user's trading volume on Unis swap in the last three months and then finally um you know after uh you compute the result of the computation and also generate a zerge proof so note that this generation of the zerge proof is a transparent done by the brav approver network and you can actually use the data and post the data back to the blockchain um and you know allow the smart contract to directly utilize that data in the business logic so for example to build the exact the same thing of uh uh the Dax trading

volume discount feature using brevis now for example your smart contract will be able to call uh a uh a kind of a stop contract or a proxy contract on chain for uh you know for bris to say I want to get the trading volume for this particular user and then you know breis will uh you know the oping component for br will be able to monitor that transaction and monitor that smart contract and then receive the instruction to do the computation off chain the computation will be done off chain and then you know along with the trading volume a proof will also be posted back to the blockchain uh you know um for the smart contract to record that trading volume and for example we

have been running a bunch of hackathon with Unis Swap and B pancake swap as well for their V4 architecture in this particular case the trading volume can be stored in a V4 um based hook contract which is essentially plug in for the uh Dax and um you know after that all future trade for this particular user in the next month will receive a dynamic fee adjustment based on the trading volume of this user in the prior months so to do this type of a computation uh for a user across minuts of transaction on Unis swap it only cost You2 like 20 cents and you know 24 seconds in terms of latency so you know previous really

production ready and uh um you know um able to be used in production and in fact like we actually integrated with many of the uh top def5 protocols and we'll be launching with some very significant features soon Mo could I ask you a quick question on the the previous slide yeah as you're kind of building this pres this workflow of uh doing some offchain compute and then verifying that that compute uh onchain with a ZK proof I'm it it draws lots of parallels to a ZK rollup where we can we can push transactions um off of a layer one you know call it a layer two and then we can verify those transactions back on the L

L1 uh with a ZK proof and so I'm curious what what kind of similarities or differences are there between brevic offchain computation environment uh and then verifying that with a ZK proof versus like a you know a traditional ZK rollup out there right now like a scroll or ZK sync this is a great question right so like you know uh I think for Zig rup uh they are a way to do offchain computation but um it is a it is a it is done in a way that you split um The W of you essentially have a fork of The Blocking state right so like you have you have your layer one blockchain state then you create a separate parallel word in a layer two blockchain right so the

layer two blocking has its own state has its own persistent State and you know it has on its own user and it's isolated in some way with c one blockchain so it is a way to do offchain Computing but the limitation there is that you still carries a lot of overhead in terms of storage you still carries a lot ofhe in term overhead in terms of the evm the VM construct that you're not getting away from that so like the evm itself and the blockchain itself is still fundamentally limiting um you know how much computation you can run on a Lup for example in grow up you still have the concept of gas fee limit right so the reason you have the gas fee limit is

because for whatever transaction you post on the layer two blockchain a call data or like some data availability uh you know guarantee still need to be met and this is a where you need to store actually a lot of data about the transactions uh in a layer one blockchain or in a DA solution like in da but these places these da um you know uh Solutions and these kind of a uh you know places where you you you store your data availability guarantees are still limiting in terms of the capacity you can actually put right so you know essentially there's no way you can scale the computation in infinite way because in the in the end of day you still need to challenge the uh you know computation

on chain and still need to be able to store all these data uh in a safe place and that is kind of a limiting factor so uh layer to's blockchains are good um to for use cases where you want to actually split the word into two parts where you have a parallel word you have like the entiate separate def5 protocol deped on a different layer tool and you have a different ecosystem but what co-processor here enables is that you know it enables you to leverage a much much much much more powerful computation resources here because it doesn't actually split the uh uh you know uh split the state or split the entire word

into two parallel words right so basically uh what um you know uh Cod processor enables is that it can tap into uh very powerful offchain Computing Computing Computing resources and still after the Computing is done the result will be posted back to the blockchain where it came from so you know for uh rups it's not the case right so rups once you have a rup then you have a bunch of user migrated to there and you have essentially liquidity fragmentation user fragmentation application fragmentation uh but for co-processors you don't have this type of fragmentation you tap into additional resources and you still keep all the state and all the users on in a single

place in a single unified blockchain so this is like you know the difference between rups and the co-processor awesome okay yeah that was very helpful uh feel free to continue yeah so there are many use cases you can uh you know uh use brev uh for um you know uh from a first principle point of view like we know there are a lot of U you know the defi is the first product and Market fit for uh smart contract based BL chain so you know what brav can enable uh is uh something called Data driven Define or intelligent Define so uh what this means is that basically U

you know you can actually uh dynamically change the defi protocols parameter based on individual users historical transactions behavior and also the protocal behavior right so things like trading volume based fee discount is one prime example and also volatility based fee right so if you want to uh you know have a um um if you want to dynamically adjust the fee to a higher tier to protect from loss versus rebalancing uh if the volatility of the market is high you can do that uh kind of based on is proof of historical uh price volatility and you can also run new kind of uh reward and incentive programs uh for LPS today LPS are receiving farming reward

purely based on the Tim length of their liquidity position deposit however that is not optimal for the protocol we have seen and saw we have seen like many evidence on chain there are these kind of a smart LPS who will just like withdraw their liquidity when the market volatility comes so these smart LPS will receive a lot of farming reward and you know incentive in terms of the protocol token but they're not actually providing helpful liquidity when the market needs it so instead of doing this type of time-based uh you know Distribution on ongoing basis what we argue and you know brev enables is that you can do this rospective farming reward distribution

based on the LP's actual uh trading fee contri contribution to the pro to the protocol right so you can actually see okay this particular LP actually you know help the gr when the market is volatile and generates a lot of fee for the protocol and therefore um you know he should be rewarded with more farming reward so instead of like based on the time length of the deposit right so this way we can actually um you know uh encourage and uh benefit a more decentralized LP structure instead of just like relying on these kind of smart LP to with and you know deposit liquidity um based on the market conditions right so there are also many other consumer based application gaming is one very big category of this right

so if you look at all web two games every single one of them has something called liveops which is essentially handholding the entire user life cycle based on their user profile if this user is a high paying user if this user is a you know kind of smaller Caro user um the user's experience in the game will be entirely different but in web stre every single Gamers experiences are more or less the same uh because smart contract cannot differentiate it between different user profiles but with bra you can now generate a trust free proof of user activity historically um you know and also based on their like neighboring uh you know uh uh kind of essentially neighboring applications or relevant

applications behavior and differentiate the users experience directly in the smart contract and um you know there are a lot of other infrastructure use cases such as if you want to auction out your block space how do you ensure that Auctioneer is acting truthfully that it will actually include your block in a certain uh time limit and these kind of things will also benefit from braev uh you know they coprocessing power so now I want to kind of talk about how we actually use and the integrated with icon layer right so in any kind of a off Computing uh space or ZK offchain Computing space uh there are two models you can choose you can choose to use

pure Z which is like you you whenever a uh you know computation uh request comes in you do the computation entirely in ZK this works fine um but also at the same time uh you know um we need to know that this type of model also incurs high cost in certain cases because zero LGE proof U despite it's a um you know amazing progress in the last several years still is a quite uh you know cost uh uh costly kind of computation process wrong now what we introduced in uh brevis which is a very unique thing is that we introduce this kind of optimistic co-processing

with ZK fraud proof so we can allow a proposer to essentially do the computation of Ching without generate ZK proof and submit the computation result on the blockchain as a proposal just like an optimis R up right so and then you know if uh and then a challenge window will be opened and during that challenge window if uh any Watchtower detects that this particular result is wrong then a ZK fraud proof can be generated to challenge the result and correct the wrong result and Slash the PO uh the the initial proposer now the question is like who um what is the uh proposer right so uh you know we can't

use a centralized entity or like a centralized sequencer as a proposer but you know what we feel is actually more reasonable is to essentially provide some level of default security at the proposing stage this is where I layer comes into the picture uh where we use an igen L ABS as the optimistic co-processor proposer so this particular I layer ABS node operators will be able to compute the co-processing result and option computation result up front without actually generating Z proof and they can submit the result to the blockchain now immediately that result is actually secured and guaranteed by a certain

level of proof of stake security right so like no matter how um you know depends on how much like e rake is actually dedicated to the uh previous ABS that level of security is already there but the challenge window is still open for applications uh you know application can choose their own challenge window some application May uh be able to accept the result up front directly but some application may actually want to have a challenge window and during that challenge window uh you can still generate a zero Notch proof fraud proof to actually challenge uh the initial submitted result if the challenge is successful then the corresponding uh you know kind of a

validators or operators who submitted the wrong result will be slashed right so of course you know um we believe that this particular model will actually be used by a very large amount of applications uh because it offers the same level of trust assumptions as a pure uh you know basis solution but also has significant lower cost comparing to Z the only trade-off here is latency but we do see there is a large category of use cases for Z cor processor that are not latency sensitive for example if you want to compute a monthly trading volume for a user then you probably don't you know U

don't don't need to kind of a really Chase for that particular seconds of latency or 10 hours of latency you know as long as the cost is like lower then you probably would actually use this kind of a hybrid model so this is a how we use um ABS as way to lower the cost for ZK coprocessing while maintain the full transar of the entire architecture yeah I mean just briefly back on that slide um um I I I don't I I don't understand quite how the slashing part is going to actually make a difference for this

model right like like like how because what theoretically slashing is going to involve slashing the igen token um wh which I'm just struggling to see how how slashing is going to be enforced or used at all in this model um and there's going to be any sort of kind of cryptoeconomic security here yes so you know uh I guess like just to kind of quickly run through this entire flow here uh so instead of sending everything directly to a ZK proving service the smart contract now will send the compilation result request directly first to an ABS right so the ABS will now generate a

cryptoeconomics uh economically validated result so this is like the proof of stake result the proof of stake result will be posted to the blockchain as just real quick that's like an optimistic uh result because it's cryptoeconomic optimistic result right so that's essentially optimistic result but it's a stronger than a centralized sequencer based optimistic result because it is guaranteed by a crypto Economic Security um you know of the rake the ABS and you know now we will have a challenge window open during that challenge the application will not directly use the result you know it will actually wait for a challenge this result will be essentially put into a quarantine Zone and during that challenge window if some Watchtower sees

that okay wait that result is actually wrong so how do I challenge this well you know the way to challenge that is pretty simple it will just generate a zero proof of the correct combilation result so now the Challenger can then submit a result to the blockchain saying okay look now I have a zero proof uh and also the correct result and the blockchain can verify the result because ZK proof uh can never be wrong you know baring that implementation bugs and you know uh uh and and like cod issues but like in theory you know proof can be can never be wrong and then you essentially have the uh challenge accepted by blockchain and when the challenge is

actually accepted by the blockchain the corresponding um you know uh it it basically means that whatever initially was what what whatever was initially submitted was actually wrong and whoever signed on that initial proposal should be slashed so this is like the how the slashing works so um I I think that makes sense right uh there's like an there's a proposer that proposes a uh a verif solution um to the computation request optimistically um and then there's a challenger that submits a ZK proof and if those contradict then uh the proposer who is proven Wrong by the ZK proof is slashed because they proposed something incorrect that's and you know you

mentioned that like a ZK proof could never be wrong I agree with you in principle but it could be malicious right and so I could maliciously submit something that is going to you know say that the ZK proof uh contradicts the original optimistic solution but maybe maybe I'm I'm not right right maybe I'm submitting something that is malicious and I want to you know try to steal funds or whatever how you know H how if I can submit a ZK proof and it's just taken as truth then the optimistic proposer is slashed you know regardless and my Z my malicious ZK proof is taken as correct but how can we deal with a malicious ZK proof that may or may not be incorrect you know how how can you

verify the correctness of the ZK proof and make sure that in fact the optimistic proof was incorrect and my ZK proof or excuse me the optimistic proof was correct and the ZK proof was incorrect sure uh you know so the question is like how we can essentially verify whether a ZK proof is indeed correct or not so like I guess you know this is a great question that you know we we kind of need to expand a bit on how these computation get binded together right so whenever there's like a a offchain computation let's say there is some function they need to compute offchain and uh for any function there will be input right so you know whenever uh we Define a function let's say you know let's take a very simple example this is a to computer a user trading

volume on chain and you know uh whenever that is like defined there will be two things generated like one is the ZK circuit corresponding to that computation so like basically you know if feed all these users transaction this particular Z circuit will understand and figure out whether these transactions are actually belonging to this particular user and if they are from Unis swab and they you know what is the if so what is the actual kind of trading volume of this particular user right so that's kind of the the offchain circuit part now uh for any ZK proof there will be aover and there will also be a verifier so the verifier is actually U you know concurrently generated based on

the circuit that you want to verify so in this particular case this verifier will be only able to verify the computation result of the user trading volume and that verified contract will be automatically generated and deployed to the blockchain so essentially blockchain itself is now becoming the verifier there is a smart contract that is running the actual verification uh algorithm and process so you know whenever you actually computed something off chain as long as the the corresponding binded verifier on blockchain can actually verify the proof it means the compulation result is correct so this is how essentially ZK when I say like ZK proof can never be

wrong um that's kind of what I mean is that for a common defined computation logic there will be a onetoone binding between the launching verifier contract and the offing computation logic so whenever you actually you know generate that computation logic that can be verified and can only be verified by that particular specific verified contract and uh you know the the the promises of ZK is that the verifying computation cost is constant value no matter how big the offing computation is you know you can do that computation however you want you can generate the AI model if you want but the verifying process of the computation result is the constant cost of around 200k

gas okay so so uh another another kind of observation here is like uh let's say I'm a I'm a challenger uh and I have the capacity to submit you know malicious incorrect or correct ZK proofs y I could spam the network right and kind of pro kind of grind it to a halt with incorrect proofs um is there any Economic Security that Challengers have to commit in order to prevent spam or what and I imagine this is the case is just the cost of gas to submit these proofs is enough of a disincentive to prevent spam you're you're a exactly right like you know because you know if you if you generate some malicious proof or like you know fake proof um first of all the verifier contract can never

actually verify that right so this is different uh you know than the uh uh you know kind of optimistic rup challenge process where you need to run an interactive process to essentially kind of find which which step is actually wrong and that's when the griefing can happen but here you don't have interactive challenge the challenge itself is a proof itself so if you generate a wrong proof you submit it on chain the uh uh you know essentially kind of it will throw an arrow like it will throw an out of gas Arrow um so that will be enough of a deterrence for uh anyone who wants to actually generate fake proofs yeah cool and then we can go yep and you know this particular

architecture is not only for uh lowering cost but it actually enables more features um now what are some of the features that is involed by this is that you know using ZK it is very using pure ZK it is very hard to prove completeness and non-existence for example if you want to prove that okay these setup transactions are all the transactions this particular user um you know had with unit one this is very hard to do in in in ZK because you know how do we do in that case you you essentially need to prove every single transaction in history to be able to confidently prove that okay these are all the set of transactions that this particular user

had with un one but using this kind of a proposer uh and a challenge model it becomes much simpler because now you know as the first step of the proposal um the ABS will just be able to propose a set of transaction and claim that hey look I have this set of transaction and I claim this set is a complete set of uh you know certain criteria of you know matching C crateria matching certain filtering and now if that is actually incorrect the proof you need to generate to dispute that particular you know uh statement is actually much simpler than generating the entire proof right so like let's say you're missing one

particular transaction in that initial set all the pro need to do is to just generate a zero proof showing that hey look I find one additional transaction that matches your filtering criteria or filters and but you know it's not actually included in your initial proposal and it can generate one Z proof for one single transaction and challenge that initial result so this architecture actually makes a lot of use cases feasible such as you know if you want to prove something is a complete set or similarly if you want to prove a user never interacted with with with unit swap right so we can do the same thing you know the the optimistic proposer can

propose and say look this particular user never interacted with un Swap and if this is wrong then the Challenger um Can Only Just generate a single Z proof with a single transaction to dispute that particular claim so you got it um is there one more slide left uh y last one that's one yeah um so this may be like a silly question but uh what why do you like why do you need to be an AVS couldn't you just have your own set of like couldn't you just run your own chain and have your own set of consensus

in a proof of stake manner that allows you to have the same slashing window like what other advantages come with being an ABS that you couldn't get by running like a I don't know like a cosmos chain or like your own L1 um I understand kind of like the Boost shopping Economic Security uh is expensive um like I guess like why do you need to be an AVS and and what demand do you anticipate for uh you know kind of people wanting to uh secure brevis uh yeah I mean this is a this is a great question right so like you know I think this is not only for us generally apply for is generally applicable for everys and you know the I

think I'm going to ask all of them the same question right the key answer yeah you know you should this is is a great question actually so the the key answer for us is actually the cost of capital uh right so like you know uh because what I enables here is that you have like rake services that across multiple different abss and the the result of that is that you essentially have a lower Capital cost expectation for um you know many of the R sckers so for the same level of Economic Security uh because of this uh economic of scale for I lay uh each ABS will be able to pay a bit less than you know just like running their independent uh proof of stake Network so uh that's kind

of like the key reason for us to um use uh icon layer to Bol strap this entire uh you know security network um and uh you know uh that's that's that and uh um in terms of usage uh we do expect a lot of usage coming up uh for example we recently you know Bri is very much ready and did in production already uh we recently launched a VIP um Trader fee rebate program with quanta uh which is one of the the biggest uh uh you know Perpetual Trad Perpetual swap protocol aggregator uh on optimism with like $60 billion trading volume and like millions of transactions and we are already

seeing that there are a lot of users opting um you know uh using breev VIP power features and you know we we already see a lot of U uh users and the Traders are now claiming these fee rebates and they constructing and helping the market to construct a more efficient market structure U because they can essentially have Market maker fee rebate right so you know and uh uh in October and also November we will be launching with many of our Flagship Partners some of them are the biggest D5 protocols in the world um you know with data driven features so we do expect that this type of uh you know uh both like pure ZK and also the

optimistic um you know uh co-processor plustic fraud proof model will be used a lot by different kind of use cases as well uh in terms of the level of uh uh you know crypto Economic Security uh I do think that once we enable slashing there will be a red reduction of the uh um of the of the r amount uh in ter uh in the ABS but it's not a very uh big deal for us because in the end of day uh we uh use ABS as a additional security layer uh but the ZK fraud proof is the last line of defense and the security guarantee there so you know uh we we expect how this would go is that as we

scale out and scale up with more use cases and usage more and more people will opt in and pay fees to use the optimistic um you know co-processor model powered by E layer and once that happens you know we'll actually gradually scale up back in terms of the amount of stake that is dedicated to uh the bravest ABS um so yeah um that's how we see this Vol awesome yeah that makes uh that makes a lot of sense uh Andy did you have a followup there um yeah I mean I think like one thing that that people are are are really curious about with regards to

kind of how how uh you know brevis as an as an AVS will will uh kind of grow um and be able to supply a a a kind of layer of demand for all of this eth yield um and all this eth that's restak I'm curious from your perspective like how you how you plan to uh integrate into different applications and where you see the demand coming from for uh ZK Cod processors as well as just in general like uh the AVS ecosystem yeah definitely so you know um we do think that there will be a very sustainable growth and the Very

sustainable demands uh coming from all fronts uh in the uh d space and you know uh the first categor as I mentioned the first very major category would be um you know data Dr Define and the intelligent Define um and the amount of computation needed on those use cases are very actually very large um you know right now none of that kind of intelligence and the uh you know data driven inside are actually leveraged in many of the defa protocol but they do have a lot of users many of the defa protocols have like a you know millions of monthly active users uh you know uh right now and we do believe many of them will actually be using breev power features and uh you know then the

competition request that uh you know on that front will be uh pretty huge and um you know one analogy we often want to uh like to draw is that uh if you if you treat like blockchain itself as the CPU of web stre now uh What uh you know breis does here is essentially kind of the GPU of web stre right so you know it's a Cod processor for CPU and offload a lot of computation that is inherently not friendly for CPU to do and we do see there are a lot of Demands on that front and not only on Dy but also on infrastructure so you know we do see a lot of kind of these infrastructure project such as da Solutions um that we work with like

folks like zero gravity for example and also U you know things like block space uh trading Solutions uh that is are coming up will also leverage uh uh previous with a very high frequency Manor um so yeah we do see a very strong demand and you know I think right now we are at this very interesting uh you know uh point where BR is very much production ready it's just like we have a a lot of partners that are being uh they're currently building features with breev and will be launching the next few months and you know once we reach that point you know I think um the entire market and the entire ecosystem will start to realize the power of offchain

verifiable computing yep perfect yeah um I think it makes makes perfect sense you know this is almost like Marketplace for verifiable computation uh we have uh applica data driven applications defi applications uh data driven uh infrastructure projects uh that are looking to pay for verifiable compute um this is something like like AI I anticipate is going to continuously uh trans transform into verifiable compute um especially as we have agents acting on our behalf um I think we're going to transition a little bit you know we're gonna transition uh certain sectors of projects like AI from more centralized uh Cloud compute

Services over to verifiable compute um and these applications and and you know AI services and Beyond are going to have to pay for that computation uh they're paying uh The Operators right because uh The Operators are either they either have a cost to submit a ZK proof or they have a cost of capital uh to stake and submit an optimistic proof um and so the op operators here are uh you know they have some cost either cost of capital or cost of generating the proof um and it's important to pay you know for uh to incentivize them to stake or generate those proofs we talked a lot about slashing but I guess you know one question to to kind of take us here home

here is you know what what are some of the uh the uh incentives or or ways that you intend that you know the the the people who are staking uh in The Operators that are submitting these proofs and and proposing Solutions um you know what what kind of I maybe this is too blunt but what kind of API could they expect or generally like you know what is the reward mechanism uh to incentivize uh operators to uh submit these proofs uh and and incentivize stakers to stake in these operators yeah so you know uh I think I think that's also a great question like you know basically to estimate the size of the market you know long term right so you know uh um if if we look at like

the the current uh you know one way to kind of uh evaluate and estimate the market size is look at the some of the yield that is currently being generated by the existing capital on these defa protocols and how much we can boost that and uh you know that's kind of a you know the additional boost of the seod and the additional boost of the revenue will actually flow uh partially will definitely flow into bravest power protocols right so you know just one very very uh particular feature of the trading volume based V discount we believe that one single feature on daxes will actually be able to boost like 20 30% of the tax revenue um you know very easily as we have seen this in many of the uh centralized exchanges right so

this is why every Central exchange need to have that because this is how you actually generate the um you know better Market structure for uninformed outer flow and kind of essentially Harvest more fees from these uninformed outer flows um and you know if we can boost that by 20 30% then what that means that on that particular feature will'll be looking at like close to uh you know 50 million additional Revenue um on just one single exchange and yeah if we add all up it's it's close to like 200 million Revenue easily so you know uh if that will then it's kind of up to speculation in terms

of how much of that Revenue will be uh flow in into um the ZK Cod processor uh or bis who provide that kind of services um then you know we'll have kind of a baseline of the of the yield for for the capital uh you know demands but I guess one way to kind of a look at this entire um you know RIS taking sector is that even though every single AVS right now uh has like large amount of East race sted into uh these AVS but you know uh when the operation when the staty stat is reached um you know each of the ABS will have like you know it's it's not really the the amount of

capital that determines the yield it's really the yield that determines the amount of capital uh you know that is available for these abs right so and we we believe the same thing will happen to braev uh ABS um you know when the fee is turned on uh initially there will be the corresponding amount of a stake that is a you that that the capital the capital should feel reasonable that they should actually stick into abs and this is a free market it's not that we will enforce and force everyone to leave uh to stay in in BR to kind of a stake that minutes of East probably in the beginning that's not actually needed uh which is perfectly fine because again for abs based model we are using in the

ABS as optimistic proposal and as the the use case actually scale up we will actually naturally see more and more Staker join uh the pack and in the end of day we do see I ler as a very very good way to Source low cost capital for proof of stake system and this is why we will continue to use I ler for sure and you know to actually uh you know enable this tradeoff playing for developer to choose between pure ZK uh and you know also crypto economics plus ZK model of course we'll also continue to offer full ZK model which many of our developers and the partners are based on today but uh we are sure as the time passes as long as it's not latency sensitive use

cases they will actually look into uh this type of cryptoeconomics Cl that model more awesome that that sounds great and uh frankly this is one of the earlier episodes in the series that we're we're recording and so still kind of going through the Kinks here I think one of the things that uh we're going to continue to forge ahe on is uh allowing you know Founders and and uh projects on on this series kind of pitch the users on why they should stake uh with this part you know each particular project so I think you did a great job here um and thank you so much for coming on this was a great thank you thank you Andy thank you Robbie it's been great speak to you soon