How to Decentralize Proof Generation?

Transcript

pull the microphone down for my stream oh yeah thanks that's good have I OB okay um so hi everyone thanks for coming I'm Norbert from gvulot um we are building decentralized Cloud for ZK um but first of all I'd like to talk about how to decentralize proof generation from a conceptual perspective like protocol design perspective by the way I'm doing protocol design at K lot and also involved in product uh okay so basically let's take a quick General outlook on uh on like the past

one and a half years in 2023 the major discussions uh I remember a couple of them actually uh at ECC uh last summer major discussions were around censor Pro separation uh also the pr decentralization of L tools and like whether they should enshrine or not enshrine uh Prov networks that means should they build their own in-house prer Network to decentralize their proving activities or should they go with a third party Pro Outsource Pro now with um third party proving obviously it saves a whole lot of complexity because the go to market is much faster but then

depending on who you choose you may introduce some external dependencies it may introduce depending on the design considerations of of the choosen provider it may introduce some likeness or sensorship risks Etc on the other hand if you go with in protocol Pro networks it brings a lot of uh like kind of tradeoffs you don't have the external dependency but then depending on uh when your approver is allocated a job uh they are sitting in Idol basically so the hardware utilization is definitely not optimal there and they like in protocol Prov networks would have created a whole bunch of fragmentation meaning that node

operators would have operated a bunch of different notes on different networks of the l2s had they built their approver networks in house now the reason why I'm talking in past tense is because in 2024 uh it became clear that basically the industry leans towards outsourced proof generation now that brings a couple of other challenges one of them is is for example uh it it brings about a new type of fragmentation actually uh fragmentation of uh the Prov infrastructure landscape because currently like there is a big bucket so-called Prov networks or or proof markets and most of the providers are

just thrown into the bucket uh and and it's kind of challenging to to to see who is focusing on what even though there are actually pretty different um focuses in in like in the landscape and it's challenging to find which is the most suitable solution uh for any project that is looking to Outsource proof generation now there is one um one uh solution that is being uh like getting started to be discussed uh which is ZK boost it's it's been announced I think this week but uh uh there have been talks and coordination around that for the past two months I think the main goal of ZK boost is to create a

standardized API for for proof proof Outsourcing where any proof provider can plug in from from one side but then uh any project with ckp demand can plug in from the other side and like any proving option would be made available through this standardized API anyway U that's just a a side topic it's it's good to see that abstraction like abstracting your very the complexities of proof Outsourcing is being discussed uh about more and more it's been lacking in in the uh in the past months now let's come back to decentralization which is the the main topic of uh of my talk today why does it matter so much from

our perspective um since proving is a conf heavy task it's really susceptible to centralization uh and we don't want to replicate the same thing what what we've seen with traditional Cloud comput so centralization impacts other risks as well um so it's not an issue in itself obviously it may introduce liveness risks it may introduce risks of one dominant entity uh starting to control cost structures uh it may introduce sensorship etc etc so it's definitely um the need decentralization focused mechanism design principles uh to address these consciously when when

designing uh Prov networks or like any proving solution uh that our source is proving now i' I've listed a couple of design considerations related to to decentralized prover networks let let's just run through them and on the next slide we're going to particularly talk about the workload allocation mechanism more because that's that's that's a key element I think so participation is is U is the first thing you want obviously if you if you target decentralization permissionless entry is is very much is needed for like as a solid basis but then if you don't carefully match the

workload allocation mechanism um then it actually can spoil whatever you have wanton with permission entry permissionless entry it can spoil it on the other side we'll talk about that um in detail in the next slide but for example um capacity verification that's something that is I think a very interesting topic because there are different approaches to what type of Hardware to allow to join aover medor um some teams are building improver networks allowing any type of Hardware from very specialized one to Consumer break where it's it's it it adds a whole lot of complexity to how do you want to

distribute workloads and very often the trade-off there is that you need to select an allocation mechanism uh that is more prone to centralization we we'll talk about that why in case of uh in case you have like very uh you have let's say a clearly defined minimum Hardware requirement in that case you can obviously proper proof of capacity verification and proof of availability type of verification you can make sure that you can like the network can offer u a standard top performance across all the active Pro Set now reputation systems is something I like a lot uh but I haven't seen an optimal

solution yet that either that doesn't either favor new joiners or favor the old guys uh around the park because um like there are it's super hard to to define or to create a mechanism that is fair and inclusive so for example uh what I've been thinking a lot about recently is whether kind of like a constant capacity and availability verification could serve as like reputation may not be the best word in this sense but like let's use that reputation on actual merits on reputation on like continuous merits something like that which could be kind

of neutral as long as you have the capacity and you are available you are considered reputable meaning uh constantly being allocated jobs or something like that but that's just a side note then we've got the question of Economic Security um usually uh it's staking or uh in in the recent months re taking based yes well until a mess slashing even happens uh raking um is is uh is a good option uh and then if that may happen at any point then uh teams may may rethink uh strategies it's no secret I'm I'm a bit

skeptical about reaking but that's just my private though not give a lot uh and uh yeah i' I've been thinking a lot about whether there are alternatives to staking in that sense because staking would serve the purpose to uh for provs to uh you know to act honestly uh and you know to have skill in the game what if we consider a constant capacity and availability verification meaning whenever they are not busy with jobs allocated to them and they'd have some either time we bombard them with mandatorily execute like executable uh jobs that uh that so that even in the either times or in the

time in between allocated jobs we know constantly they are uh they are constantly like they are continuously available and the reason why I'm thinking about this is because in case of aover node it's not like a validator where uh you spin up a pretty uh modest Hardware you can run the validator and you need additional stake in many cases po Hardware costs tens of thousands of dollars anyway and just to buy that have that available and keep that running is is a a pretty heavy uh cost element or skin in the game so to say so we've been thinking quite a lot about alternatives to act taking where uh with combined kind of proof of work to the you know to

uh like ZK mining just trying to make a quick parallelism here but not again not the main topic of the talk but these are things um have been thinking about in this topic and then another thing is can we positively incentivize honest Behavior so like instead of saying hey if you act dishonestly we we'll slash you instead of that how could we build positive incentives to remain honest I think that's always a much better motivation motivation um and of course in terms of economics and like in the General sense absolutely um any prover node in any prover Network or any PR Network out

there um working in a decentralized way has to ensure in their economics that nobody can earn money uh like they can only earn money acting honestly and they definitely lose money if they act dishonestly whether it be future profits whether it's slashing it there can be different approaches but yeah just as a general principle and then obviously fallback mechanisms what if there is a Prov failure how do we handle that is that is that b into the protocol or does an auction or uh does an auction need to be restarted in case uh the the Prov who with the with the vinning bond vinning bid U actually uh

failed to generate the proof so these are different uh different considerations now okay now a little bit about specifically about workload allocation mechanisms um I think it's as I mentioned permissionless entry is really important to ensure and to allow proper decentralization but the workload allocation mechanism is needed to maintain that decentralization long term because some of the the workload allocation mechanisms out there are actually heavily prone to centralization one of these is auctions

um they are always or most of the time they are looked at uh as the key mechanism to drive down costs um I think there are other ways if planning proper economics uh and having the full flexibility to plan economics uh in in a certain way that could allow uh a protocol to provide cheap enough proving without the tradeoffs that auctions come with I'll talk about that a little bit later um again but like what's the problem with what's my problem with options is that the richest entities could easily create Monopoly by just undering everybody else and there have been some really nice approaches

for example lrange recently published a paper on double auctions U it's really nice I see um it's really nice on the other hand um the the um on in the double auction the bidder side where the proving uh like proof providers are uh submitting uh the bits in in that case the ranking of those proof providers is also mainly like the key factor is how much do they charge for proofing so even if you have sophisticatedly designed auctions at the end of the day cost the cost element for the which um Prov nodes

are willing to generate proofs is still a dominant fact which still allows for uh Monopoly now uh and like it's very easy to create Monopoly in that environment not necessarily will it be created but it's easy and we've seen uh this type of like Prov undercutting uh in in some protocols already order gr based mechanisms are very similar in a sense that they can like creating a monopoly there is uh again quite easy on the other hand it's vice versa because the richest entities can simply absorb demand at any price if they can afford losing money on proving or doing proving

for uh for like zero profit and the reason why it's important because as soon as there is an entity like one of the largest cloud providers out there who can afford do improving with no profit for you years as soon as competition's out uh there like such entity could create dominance in these B allocation mechanisms now we could in summary we could call uh this like economy like entities with economic wealth could create easily uh monopolies on in auctions or or B W mechanisms now for proof racing that's a different story it's kind of like proof ofer everybody

racing to do job but only the fastest gets reported that's kind of like compute wealth type of monory or compute wealth based Monopoly and obviously it's never going to be the cheapest because of the Redundant or was it depending on where we look at it but the Redundant or wasted computation included in in Pro Racing itself now the state based lotteries are are uh somewhat more neutral on the other hand the richest entities still have um uh um the chance to be dominant because they just need to increase the amount of State they they have by the click of a button and then uh they will have higher chances to be

selected for a certain work clod so the most neutral uh allocation mechanism from the point of like the lowest risk of centralization is is pure Randomness uh and it's not the holy gr either because you need to design other elements of the network inovate that Randomness can properly show its uh strengths uh for example you need if you want to go with Randomness you cannot just simply uh on board any type of Hardware because one will be much more performant than the other and you may not you may be allocating to a hardware that cannot fulfill a job in in the given alloc in the allocated amount of

time so you need other elements of the protocol there to be designed accordingly but still if we look at it and we're talking about how to decentralize proving that's that's the the most neutral and uh workload allocation mechanism that with which you can maintain actually uh your decentralized setup um yes in in this slide um I touch already a little bit upon what we are like what is our approach G Lots approach uh to to decentralize proving but let's look at it from the perspective of l2s how would

Layer Two Solutions design their own prover Network let's let's let's imagine we go back to 2023 and the industry doesn't want to go without Source proving they design their own networks and build them like not just have the sequencer inhouse but a decentralized pro Network inhouse um participation would obvious be permissionless uh if if they want to maximize uh decentralization the vertical delocation uh would probably be Randomness based just like for the validators or for the seeners if they want to maintain decentralization and we've seen this being used you know in most of the l1s when then it's about uh

uh like neutrally selecting uh a certain actor in the network to to do some job um regarding economics obviously promoting honest behavior and punishing this honest Behavior would be key and probably the alus would have some buil-in like fallback mechanisms baked into the protocol to make sure that like to ensure liveness of their protocol in case the selected Prov the randomly selected Pro fails now these are characteristics that we can all check uh with gon so we've been designing our CK Cloud to meet the expectations of of l2s

like meet the expectations that l2s would have of their own uh um in protocol Pro networks and I think it's really but they just don't need to build it anymore because there is a solution out there uh so it's it's I think it's very important um from from that point of view so basically uh now I'll I'll talk a little bit about uh about what we are building and how we approach decentralization and and hope this will be uh also useful and try to get it in a practical perspective or in a practical way so our core principles or like our main thought process is that we want to

uh like we build our protocol with decentralization focused Design Elements to ensure that no one can control where proving happens to maximize liveness guarantees to minimize censorship uh to make it trustless neutral etc etc we know all these but unfortunately in the past uh I don't know in in the past one or two years maybe uh the the the importance has been forgotten a little bit the importance of decentralization and it's really great to see l2s for example that have been running in a centralized fashion for

years basically many of them opening up building a path toward decentralization even some of them uh already starting initiatives contests whatever out there to actually decentralize their proving at kot we believe in a ziki future where proving is truly fast cheap and decentralized and these are the the principles along which we've been building Z ZK Cloud um as well ZK cloud is basically the first Universal proving layer uh for ZK it allows users to generate proofs for any proof system we're going to talk about that a little bit with dramatically lower

costs the architecture consists of three main elements basically proving layer orchestration layer and compute layer the proving layer is universal uh in a sense that it can support any proov system um you can either use some of the pre- deepy provs on the network or you can deploy your own kind of like bring your own CER B and deploy it on dev lot either way uh this helps us to agregate burlo from across the industry now regarding the orchestration we've got a blockchain based mechanism uh a minim very minimal Cosmos based chain underneath uh basically we don't host smart contract State we have very

minimal operations but it's just needed to manage workload distribution and uh reward distribution uh in in a fair and balanced way and also we needed that because um as I mentioned to you we we needed the full flexibility in designing the economics in a way that we can make proving cheap enough even without applying an auction but going with Randomness and focusing on decentralization asms we've got know the network level orchestration uh uh in ZK Cloud that increases also the overall Hardware utilization on one side and decreases the cost of proving further

and we've got the execution guarantees like fullback mechanisms you can add additional redundancy to your crewing job if you want uh Etc and it's a it's a decentralized compute layer underneath it's permissionless you can uh run GPU CPU provs or pling custom Hardware as well as as they become available um I'm not I'm sorry I can't see that pardon one minute oh I'm sorry in that case uh I'm talking too much sorry let me then jump here yes introducing Fire Starter we've been some we've been

facing some delays but hopefully in the coming uh days actually early next week we are finally launching Fire Starter it's an end to an implementation of of the ZK Cloud we've got a decentralized infrastructure for proving behind but we run the validator set in a permissioned fashion that's the only difference it's scalable it supports any proof system we've got some of the available provs listed there ZK EVMS and ZK VMS uh both um Prov run in containers on a Linux VM that's a big Improvement compared to our devet uh and we go with a pay as you go pricing model so you don't waste anymore money for either time you only pay for

what you use and uh yeah it's very ideal for pars like for example risk zeros segment proving or SX proof tree construction and like one maybe yeah one last thing 249s in our GPU nodes 64 cores and 400 GS of ram that's what you get for 84 cents an hour uh is proving with us if you extrapolate it to a monthly figure that's probably a bit more expressive it will cost like 600 bucks per month for 249 and the rest of the thing that's the user cost uh if if you as a user want to do proing heav lot same thing for CPU

nodes 96 CES 700 gigs of RAM that's the minimum specs in our in our uh protocol 61 cents per hour or 440 bucks a month that's what you will pay obviously you only pay for what you use so when you submit the proof request to devot you actually Define how many CPU cores you want to be allocated to your job how many uh how much RAM how many gpus uh and the compute time with in which uh you expect with the allocated Hardware resource es your job will be completed and last but not least if you want to run aover note on our incentivized Network U scan the scan the uh QR code

here are the more detailed specs for for GPU and CPU note you can bring your own Hardware or you can rent a cover lo as well you get the same incentives in both case um yes so I think that's it from from my end um if you want to learn more visit our website or visit our docs and uh yeah let me know if you'd like to try out that work CH more thank you very much no from Jal big Applause please okay but this is you know the end of