Network Design for Protocols Using ZK-Proofs | Norbert Vadas - Independent

[Music] hey everyone good morning my name is Norbert and I'm going to talk about Network design considerations for different protocols who are looking to use zkps um a little bit of background from me um most recent research I've been involved in was um ethereum protocol Fellowship research program with two other fellows on on ZK prover model where we were looking into the selection methods and incentives incentive models of of u z provs and we created a proposal for estc um request for proposal for decentralized pro coordination and then most recently I received a research Grant from Aura protocol and made a research on Note coordination and network design for them um and created a proposal also for how the the network design for ZK Oracle could look like so AA protocol is a nonchain AI protocol and ZK Oracle Network and that's going to be my case study current work I'm research contributor at Aura protocol doing protocol research at Gul lot Network and research contributor also for zero Computing so some initial thoughts um there are very different protocols that are looking to um Implement Z KPS in their um setups and they have very different proving demands and also proof frequency uh that they require stateless protocols for example such as ZK oracles or uh co-processors or we could name a whole lot um they can have different proof demands and proving frequency because for example a verifiable onchain data feed would need a proof every ethereum block on the other hand um um a verifiable automation task would only um need a gen a proof generated upon the trigger condition being met or there could be again ad hoc requests as well ad hoc jobs while for state food protocols like ZK rollups the Dynamics of proving is actually driven by the um block production workflow regardless of the differences there are like the challenges faced and the guarantees required by all these uh Protocols are actually pretty similar I listed here a couple of them and what we are looking at when designing a protocol and that's what I'm going to uh try to break down in my case study as well is to make sure we can check as many of these um as possible so some basic design questions for any dual not protocol could be a ZK orer could be ZK rollup so to separate or to merge that would be the first one do we want to build um or do we want to create two Network participants or merge the two roles into one role and simplify the network through that for for ZK rollups it would look like sequenc approver separation which is similar to proposer Builder separation for um ethereum and um yeah that's that's an important thing as a as a as a starting point also to enshrine or not to enshrine like do we want to use an in protocol prover Network and build it from scratch or do we want to implement an outof protocol proving mechanism um and actually yeah so the trade-offs are external dependency versus higher computer efficiency with the out of protocol proof markets on the other hand very important is to consider what is the cost of a of the higher compute efficiency because if we sacrifice decentralization proof markets being a bit more susceptible to centralization then yeah we need to design carefully and also regarding l2s or ZK rollups um I think tog Ru from Scrolls been talking about this quite a lot last year like do we need sequencers at all if block building is going to be outsourced anyway to specialize Builders similarly to to how it's working on ethereum then how about provs directly working with the build ERS but again it it poses other questions and challenges regarding consensus among provs Etc the key design areas of my research are basically listed here and these are uh the ones I'm going to go through um in my in my case study but just quickly Network participation what monetary requirements what capacity verification what entry and exit criteria are there workload distribution ution and prover selection so do we want a a competition or a competitive environment or more a Cooperative one where uh parallel proving and and multiple parties being rewarded for their um work um is incorporated how much redundancy is optimal and what kind of backup mechanism should we have there if we want to lower um compute waste and and lower redundancy from the economic side it's like reasonable user fees on the one hand sufficient node incentives and also penalties on the other hand and obviously tokenomics is um are very important aspects um I like rating systems I know many people don't but I do think that a properly designed verifiable maybe even cross-chain rating system could be just as important and valuable like the stake or any monetary requirement someone may deposit or provide or I would go even further it in the long run it could even be uh more valuable but so do we need a reputation system at all and what kind of approach do we want to use staking based earning based rating or performance-based rating um how do we manage risks and as at last but not least uh how do we measure Network Health I think like putting Theory into numbers quantifying certain aspects of the design is really important um to get transparent information out and to have certain metrics to to follow the Network Health I created um with um two other fellows I've been working with at the EPF we created a couple of metrics as optimization problems like for decentralization uh we could be looking to minimize resource distribution inequality be it related to CPU or Ram concentration or be it related to State concentration we could look to maximize for example a metric uh like Geographic diversity um regarding liveness I think a reputation core either for validators or the provs they are nodes or the provs they are interacting with I think it it could be um important to to maximize and uh up time and a certain reliability index could be included in there and regarding censorship resistance um I've been thinking quite a lot about maximizing like a non- sensorship index which could be per prover or per node per validator taking into into account the total sensored jobs and applying some kind of censorship penalty and thus decreasing um the overall index of the certain node or prover and then whoever is interacting with the protocol they could know um or they could even um they could even have this Incorporated in their selection mechanisms so going further to the case study um I'm looking to present a proposal I made for Aura protocol um again it's an onchain AI Oracle and a ZK Oracle Network there are there could be two main note types one of them is a standard node the other one is aover node the former one um requiring less Hardware um capacity it's fetching data executing custom logic around that um ensuring that a proof is generated on top of data and computation correctness and also uh submitting that zkp to L1 while the provs would be actually the ones generating the proofs with more substantial Hardware um including gpus Etc and vertical integration is something I think is very important also STC Tao and some other rollups are are uh using this um in their in their or looking to use this in their architecture so any standard node who is also acting as a prover node would be able to vertically integrate and do the proving them eles whenever they are selected for a job so some requirements for Network participation there should definitely be some kind of monetary deposit for the standard nodes not for the approver nodes uh um per se but there will be something else mentioned uh on another slide for them so some kind of deposit in Native tokens to be made for standard nodes to ensure good faith C protection Etc and there have to be some kind of entry and exit mechanisms also to control free riding to control Mass exit uh I think it's important um apologies if we cannot go too deep in in in some of these due to the lack of the time but I'm trying to give a high level overview on on what it would look however for provs there could be a capacity verification or there should be a capacity verification actually upon initial initially joining the network to verify that the prover is indeed able to generate those proofs and um and uh per perform the jobs assigned and there could be periodic random Hardware capacity checks and activity checks as well like um P type of proving job with some time constraints assigned to to the provs randomly uh so that they prove they are still capable and available um to be actively participating in the network the note selection I propose should be on uh based on a verifiable random function the set of standard nodes being selected for some L1 slots like 10 slots or could be one Epoch and they they perform all the jobs uh from for all all um um ZK uh standards ZK Oracle standards the the standard nodes would need to sign a commitment that would be a confirmation of their availability and uh that could also serve as a means for early protection uh sorry early detection of unavailability if they don't sign the commitment or don't return the commitment and to make job distribution fairer I would um exclude any node who's been selected twice consecutively by the selection algorithm I would in exclude that node from the next round to to give space to the others for job distribution I think it's important to assign proportionally to the node's initial deposit it to make sure that sufficient Economic Security is there um for for all the like behind all the all the jobs they are assigned and they are performing and related to redundancy uh I think that's that's a tricky question and uh I think it's a very interesting one do we want a fix fixed redundancy um defined by the protocol like finding a balance between uh sufficient liveness guarantees and uh minimizing resource waste so there could be three or could be five um uh nodes selected for each and every job and then um they compete so to say among each other or there could be customizable redundancy user defined they could consider their priorities whether it's costs whether it's liveness less redundancy would mean lower fees higher redundancy uh obviously higher liveness guarantees but also higher fees so these type of things are I think very important as well and um hence part of my proposal for for Aura protocol um I'm sorry I went the other way related to proof Generation Um ZK Oracle node like uh standard nodes are responsible for generating the proofs they could have two options if vertically integrated they could do self-proving I think that could even be the default option but they could also Outsource um proof generation that could go through like outof protocol relays similar to MF boost to PBS and it's highly likely that such outof protocol relays would uh emerge for example SX proof boost is in the works I think already or starting now which actually serves the purpose of uh facilitating this type of negotiation between nodes in estc case the sequencer and out of protocol um proof Market markets or proving networks also the prover has to sign a commitment submit it to ethereum and uh include the prover Bond so as opposed to the standard nodes locking up a certain deposit continuously provs would just provide a bond as and when um assigned a job and uh this is returned up on successful delivery but also allows for slashing and um yeah the next one I think would be backup mechanisms in case of node failure um I I feel it's really important to differentiate between an ad hoc one where uh any node for some uh reason cannot deliver and then I think in my proposal we would open up the the the job um to the whole network so any any note can jump in and complete the job while while in case of an extended Network failure like significant drop in available active nodes in the network Etc the whole network could go into backup mode and all jobs could be based like could be performed based on an open race and uh until balance is reached and then um the original mechanism could be reinstated some a little bit about economy um in my proposal I propose to to implement a bounty mechanism for users that's what we've been talking around with AA protocol as well and I propose a minimum Bounty balance from which any fees uh related uh to the to the users uh queries could be deducted the Bounty rewards would cover normal stuff like transaction gas costs call data or soon blob fees some gas overhead for communication between standard nodes and the registry contract but more importantly it would also include a service premium uh which could be personage based could be fixed more research is needed around what would be the optimal um the optimal way to to address this and it's also very related to um tokenomics and how much subsidy is needed in the initial phases until proving costs get lower until uh user demand for these types of of Z kco Services increased drastically regarding who defines the Bounty rewards it could be user defined but I think that's suitable more for the test net because it's it would then look similar to a reverse auction and for that uh the whole design would be um would need to be rethought but also um I propose for the for a main naap for example a protocol defined boundary V which gives a whole lot of flexibility and if combined with um uh customizable redundancy it still gives the users the chance to um to um customize their costs or to adjust their costs as per their needs or their priorities Network facing economics on a high level so node incentives would consist of boundary Rewards pay by users and network rewards I think um subsidized by the protocol but this should be decreasing over time similarly to how some other Protocols are uh in in the process of of doing this the reward distribution though is a very interesting aspect in my opinion as well I propose a reort curve for the standard nodes let's say there is a fixed redundancy three nodes competing for each job the re based on the reward curve all three who complete the job Within the time window would be actually rewarded first one getting the most last one getting the smallest rewards but this would um enable a more balanced distribution of rewards and potentially more node operators and higher decentralization could be reached through that as well Prov rewards in that sense are kind of out of the scope of the protocol itself because as it's the responsibility of the standard nodes to get the jobs proven um they settle the payments with the provs directly and um I think last slide uh regarding penalties and and slashing I think uptime failure job completion failure and censoring or front running could be uh those cases where where we apply penalties certain um like job completion I think is job completion failure one of the key aspects it could be based on a base penalty in case of ad hoc failure um it's the base penalty that is applied in case of recurring failure the the penalty is multiplied by the number of failur or or or um failing instances and there would be or should be a force removal from the active node set below 50% of the original state deposit if if the deposit of the node drops below that sensoring and front running since it's ZK Oracle uh Network I think it's important to also uh incorporate something along those lines and for node rating um node up time and job completion rate should be I think the basis for a rating system for standard Oracle nodes and something like aover reliability index could serve the basis for for a rating system for prover nodes and I think we are reaching the time sorry um for being so long thanks a lot for your attention and we can discuss any questions offline thank you