ZK11: The Role of Decentralized Proving Networks in the Modular Stack - Uma Roy

Transcript

[Music] hello my name is Uma and I'm one of the co-founders of succinct and today I'm going to be talking about the role of decentralized proving in the modular stock so first I'm just going to start with a broad overview of what is the modular stock and then talk about how zero knowledge proofs fit into it so the modular stack is kind of a new new Evolution of blockchain architectures when ethereum initially launched you had the main base layer responsible for execution settlement consensus and data availability when ethereum pivoted to a rollup Centric

scaling road map you can see that now execution is delegated to the rollups and they have choices in what execution environment they want to use and they have choices in how they settle to ethereum and then they leverage ethereum for the rest of the pieces including consent and data availability and the newer blockchains like Celestia take this a step even further where they even parcel out for example settlement and then the base layer is only responsible for consensus and data availability and the main benefit of this modular architecture is that each piece can be really specialized and have advantages from specialization on the component of the stack that they're focused on so the modular stack of today

actually has even more more pieces than what I showed in the previous diagram and so I'll go through them here but from when a user sends a transaction to some sort of network there's actually a bunch of different components that a lot of different teams that are even here are working on so for example the first part of the modular stack is your transaction gets sequenced and ordered and there's a bunch of different companies focused on Specialized networks for sequencing then there is an execution layer where the block of transactions that gets bundled together in a block gets exec Ed and then posted to a DA layer and then finally in blue I've highlighted all the parts that ZK is relevant for which is the block getting proven and then interoperability between these different execution layers

and finally settlement to a base layer like ethereum or maybe even Bitcoin or Celestia now one interesting thing to note uh is that right now a lot of the stacks that I've highlighted in this diagram today are not actually using zero knowledge proofs so for example the op St today is still a work in progress they're working on fraud proofs but today it's just secured by a multisig in most production contexts and then the arbitrum stack is secured by these interactive fraud proofs in practice and polygon cdk is I believe one of the only rollup Stacks using zero knowledge proofs in practice but a lot of chains that are deployed today use arbitrum or op stack but obviously we're here at ZK

Summit so I do think there's an interesting Turning Point around the corner for zero knowledge proofs in the modular stack that I'm going to talk about next so historically if you a rollup team and you wanted to use zero knowledge proofs for interop and settlement you'd have to have a team of cryptographers with a bunch of experience and you'd have to spend years and years building out a ZK evm or some other ZK VM but recently from some work from the succinct team and a few other teams in the space including the RIS zero team and also more recently the last one jolt uh work from the andron team have led to this what I call the ZK VM Revolution where you have these very performant general purpose ZK VMS that

let developers write normal rust code and then put that into their ZK rollup so in particular sp1 which I have on this slide here kind of showed a world where instead of having this team of cryptographers and very Advanced engineering you can just have a few people on your team write your z a ZK implementation of your node in Normal rust and then it can still be very performant and in particular we have this novel pre-compile Centric architecture that lets general purpose ZK be really performant and we have some other Innovations and on the right hand side I have a picture of some code in sp1 that implements a tenderman like client that shows in 40 lines of code you can reuse an existing tenderman rust

implementation and do no Advanced cryptography no specialized knowledge and just have a tenderman like client ready to use with zero knowledge proofs and you can do a very similar thing for taking w a rust evm client and using it in sp1 or some of these other ZK VMS and getting a very performant ZK evm and so this rise of general purpose performant ZK VMS I think will really catalyze DK adoption in the modular stack and make it an option to be used everywhere so again with my previous point I think every rollup will be a ZK rollup in the fullness of time using this maintainable rust code it's just a lot more maintainable it's a lot more

customizable uh you can keep up to date with the latest changes in the evm and the developer time is really unparalleled and because of this because of this new easiness to use DK I think basically it will become the best possible option for people in the modular stack so today if you're using something that is a trust has a lot of trust assumptions obvious viously that doesn't scale very well um it might be really easy to set up but it's very hard to reason about because there's a lot of hidden trust assumptions and then optimistic and economic security systems um are better on the trust assumption Spectrum but especially with optimistic systems they can suffer from slow

finality and sometimes they're kind of difficult to program and then in some ways they don't scale super well because fundamentally for example for interoperability you have to have a bunch of nodes in the system rerun the same computations if you want faster finality and zero knowledge proofs solve a lot of these problems and because it's becoming so easy to use and also performant I think now is kind of like the turning point for how zero knowledge proofs will fully enable this module or sack to all talk to each other so hopefully now I've convinced you that zero knowledge proofs will be an important part of how the modular stack scales and interoperates and now I'll talk more about the shape of the proof supply chain which is going into deeper detail on how Zer knowledge

proofs will actually be used by a rollup in the modular stock so if I'm a rollup that's using zero knowledge proofs how does my how does the proof go from origination of a user user transaction to then being used on chain uh you have a bunch of different rollups that are sending proof requests um to some sort of either proving Network or some other model for how proofs requests get fulfilled then you have a bunch of provs who are working on fulfilling these requests uh there's also an optional proof aggregation step where these fulfilled proofs get aggregated into one bigger proof because onchain verification on ethereum can be somewhat expensive and then finally these proofs get verified

on chain onto whatever settlement layer you want uh they can also be used in a P2P layer for faster interoperability kind of like some of the ideas Justin was talking about earlier today and they're also useful in other contexts uh for example even offchain Although our main focus today especially with the modular stack is primarily for onchain usage so the proof supply chain has these two kind of very simple steps requesting proofs and fulfilling proofs and one big question that I want to talk about here today is what is the final shape of the proof supply chain so here I've kind of highlighted a straw man proof supply chain where you have a bunch of isolated SAS companies building proprietary

Stacks so in the request phase basically you have each roll up team choose a different proof provider who can just be a SAS company and maybe they're running different zkm and then each rollup team will integrate with their own proof provider's API and then the proof Pro provider will be responsible for generating the proof and Landing it on chain so this is kind of a straw man simplistic model for how the proof supply chain could look now one interesting thing with proofs is that they're self verifying so you're not actually trusting your proof provider to provide you with something correct because the proof if it verifies onchain is correct by nature of how Zer knowledge proofs work uh so there's no trust assumptions here but there's kind of un other reasons why this is less

desirable than having an open protocol for the entire proof supply chain so in the rest of the talk I'll be talking about how the proof supply chain can actually be made better by an open protocol uh versus kind of the straw man world that I highlighted in my previous slide and I'll kind of walk through the benefits but at a high level let's start with what the open protocol looks like so in the open protocol version of the world you have a bunch of different rollups and they send a proof request to a pool of proof requests using some sort of standardized API or RPC or interface or whatever you want to call it then you have a bunch of different provs now note from the color scheme here the provs can be from run by different companies run

by different teams and different data centers use different hardware and there is an RPC or API for kind of claiming the proofs and bidding on the proof pricing and then finally once the proofs have been fulfilled there's a relay phase where they get relayed on chain now I think the most compelling uh reason why an open protocol wins is that if you have this open protocol uh that's unified and provides this unified method for different rollups submitting proof requests it results in two things the first thing is that if you have this shared standard then you can start enabling competitive price Discovery amongst a diverse set of proof today in Zer knowledge proof world price Discovery is very difficult so you'll

have different proof providers charging for different circuits and different use cases very different numbers and there's no unified place if you're a team using Z LGE proofs to know how much your proof should cost and at succinct we've even written many different proving services and we don't even know necessarily how to price our proof super well and so having this unified uh standard for sending proof requests and then having this unified standard for how different improvers across different companies can compete on price will result in better end pricing for rollup teams and eventually it will trickle down to their end users I also think that it'll provide a much more compelling developer experience for these rollup teams to integrate with a bunch of different

provs in a world without a unified protocol if you're a rollup team you might have to go talk to five or 10 different different Hardware providers or provare companies and do this individual to figure out hey should I integrate with your API and what's your price and stuff like that uh in this world with the unified protocol you just integrate once with this unified RPC for requesting proofs and then on the other side you have this competitive auction built in for you kind of for free and so the end developer experience for integration is you integrate once and you get this Marketplace for free so the overall developer experience is a lot better another interesting thing about having kind of a network of Prov and

this open protocol is that the network Aggregates demand across all these rollups uh even today we can see that different rollups have very different um activity periods and that activity can be pretty variable over time and so if you have a unified protocol where you have a bunch of different requests being aggregated you're aggregating demand across all the rollups and hopefully smoothening that demand as well and then each prover who is connected to the network has much better resource utilization because they can service the proofs on the network at that time and if you have better resource utilization you have better Hardware utilization rates and then you can also start providing cheaper prices and so the prover Network benefits from economies of scale by

aggregating demand and aggregating supply and hopefully that results in better outcomes for either side and then finally uh we are in crypto so we actually do really care about strong liveness guarantees and censorship resistance and so if you have this unified protocol with permissionless participation of a set of provs then you kind of get a lot of these guarantees for free so for example you can have a bunch of geographically diverse provs participate in the network and you have much stronger liveness guarantees than these closed SAS Services because you have a diversity of companies A diversity of Hardware data centers and stuff like that and of course with all of that comes strong censorship resistance which can be

important for a lot of applications so overall I think the proof supply chain that stands the test of time will be coordinated on this open protocol and hopefully the advantages of the decentralized open protocol will make the end cost of proofs cheaper and have the network be more resilient than an alternative Universe where you have a Walled Garden of these siloed and proprietary proving services and hopefully the developer experience is also better uh for the end users of zero knowledge proofs and I think what this open protocol will let us do is proving now can kind of be this glue between all the components of the modular stack so once the user

transaction goes in it gets sequenced uh it gets executed made available on some da layer then hopefully proving is kind of the glue that takes in those inputs and then allows all these different layers to talk to each other through interoperability and then get settled as well so now that I've hopefully convinced you that Pro markets and an open protocol for proving is interesting let's dive a little more into the mechanism design for actually how the pro market will work so first we have to kind of Define the goals of what our prover Market wants to do and so here I have my opinion to take on what the goals of an efficient pro market should be in rank order so I think the foremost priority

for all the customers we talk today for using Zer knowledge proofs is cost uh Z know proofs today can be very expensive and reducing the cost overhead is generally these teams number one priority next important is latency so low latency proof generation is very important for fast finality for rollups and bridging use cases although we generally find that it lies second to cost and then after that liveness and censorship resistance are also very important um to these end users of zero knowledge proofs and one interesting thing to note is that in many longtail situations liveness can be import as important as safety with zero knowledge proofs generally because the proof is self verifying you don't have to worry about

safety uh or trust assumptions or things like that but for example if a proof system is not live and you're trying to withdraw your money out of a ZK rollup right now and there's some weird longtail situation going on liveness can actually be very very important to an end user as well and of course we always care about censorship resistance so one model of the world um for how mechanism design and how these proof requests get assigned to provs is proof Mining and proof racing so this is kind of maybe the obvious thing that you would do you just say when a proof request comes in in the proof racing world you have provs race to generate and fulfill proofs and the fastest Prov just gets

paid now this approach has some undesirable qualities which is provs are racing against each other and so there's a lot of redundant work uh and I think this makes this impr practical uh when people care about cost because the Redundant work uh ends up leading to higher computational costs which gets end up being pass to the end user in proof mining world it's similar to proof racing but additionally provs have to mine a nons uh with their proof to ensure that the fastest Pro doesn't win so this helps a bit with decentralization where you're ensuring that the fastest person is not always winning uh but again it has similar problems to proof racing where there's still a lot of wasted work and so in a cost in a world where cost is the number

one priority I think proof Mining and proof racing fundamentally won't work out so given that we're not doing proof Mining and proof racing we need another way to figure out once a proof request comes in who actually gets to generate the proof and there's kind of two options uh in this world that have been discussed one is a proof of stake style issuance model and then another one is an auction model and I actually posted a question to Twitter and got some really interesting discussion on that uh I think last week okay so in a p issuance model World basically you have a rollup uh give a fixed and perhaps with some sort of like bonding curve a fixed amount of reward

per ZK proof per block and in an auction model you basically run a competitive auction for each proof request I think a proof of stake issuance uh model for ZK proof pricing works well when your provs aren't that sophisticated so basically any one can run a pro and then the proof cost per block is relatively uniform which is true in many of proof estake networks and it's pretty bad if you have an oligopoly of provs um one interesting thing to note about this proof of stake issuance model is when proofs get cheaper the network doesn't necessarily benefit from the reduced Pro costs because there's a fixed reward per proof in an auction model if you have very

sophisticated approvers who are engaged in this competitive auction per proof then usually you would expect that the pro sophistication is pretty high uh and then the proof cost can actually be quite variable per proof which I think is the world we live in and you might end up with an oligopoly of very sophisticated actors um but the upside is that when provs get more efficient then the network benefits because the they're engaging in a competitive market and so the end Prov costs are lower so my prediction um and I think there's still a lot of research going on as to which model makes the most sense but my prediction is that the endgame ZK Market structure actually looks uh like an auction model world and it actually

might look pretty similar to how block building on ethereum uh looks today where you have a bunch of sophisticated actors in The Block building world you have these very sophisticated Searcher entities and they're engaged in a competitive game to generate proofs with the lowest possible costs and that is kind of my prediction for how things will play out but I know there's a bunch of people doing research on what types of auctions make sense um and auction mechanism design in general and then finally uh I kind of want to talk about putting all these pieces together so hopefully now I've kind of convinced you ZK zero knowledge proofs are important for the modular stack and it's kind of the end game of how everything will interoperate then there will be this like open protocol and Marketplace for how each the rollup

communicates with approvers and finally that there will be a competitive auction model for how these proofs get assigned and priced and so that's kind of what we're building at cinct is this Pro network with all those pieces so I've rederived from first principles how we kind of came to our architecture and I can talk in more specifics about what we're building so our appr Network at a high level will support a variety of open- source ZK VMS and proof systems including sp1 um but it can also support for example other open source ekms like last one jolt that came out and other what other teams are working on and it will provide this unified interface where developers can use these ZK VMS in production hopefully with one API

request and one click and finally it'll have an auction mechanism that will enable this competitive price Discovery amongst a diverse set of provs so let's walk through each of those phases so if you're a developer trying to use uh zerge proofs in general with a zkm using syins network your first step is you deploy your program so you write your program in normal rust code and then you can just deploy it to the network by uploading your program's bite code or for those of you who are more familiar with risk 5 and elf file then if you're a rollup team that wants to request aof so say you've done your sequencing and your da and execution you've aggregated a bunch of transactions and now you actually want

to request approve for that block you'll just send a request to our network uh corresponding to your deployed program and the idea here is is that you can send a request for any open source dkbm and we will also provide this unified payment interface so you have one canonical way that you pay for proofs once the proof requests get sent to the network then that's when the auction starts so you have a bunch of different provs and there is an API uh for claiming proof requests and submitting uh your bid for how much you're willing to generate the proof for and the auction mechanism will price the proofs uh you'll have this sophisticated set of diverse provs and the provs will need to be bonded to be accountable uh

for once they are assigned to proof not uh actually generating it instead of griefing the network finally when the proof gets generated and fulfilled then it can be relay to whatever onchain environment you want to use whether that's ethereum whether that's salana whether that's Celestia wherever else you want to use the proof or you can also use it offchain so this kind of takes all the pieces that I've been talking about throughout and puts them all together so right now it's a synct I think we building our zkv M sp1 but then the easiest way to use sp1 will be our approver Network and this is under active development so if you're a developer wanting to use zero knowledge

proofs you can start by using our ZK VM sp1 uh and then uh once our network is live that's when you can start deploying sp1 programs and getting proofs generated in one click uh if you're aover that wants want to actually generate sp1 proofs or proofs for other ZK VMS uh you can reach out to us to become a development partner for our apis that we're devel developing and start like participating in these like pricing auctions and then if you're a ZK person building a proof system or a new ZK VM and you kind of want to leverage our unified interface for payment and unified interface for proof requests then you can also reach out to us to be added to our networks supported proof systems so yeah all of that's kind of active work we're doing and more details

will be released soon uh soon TM and yeah so you can get in touch with us um through this form or on my Twitter and then also we're hiring for people who want to work on this kind of stuff that's all I have okay here you can just take this microphone here hi everyone Hi Uma thanks a lot we are uh from Bonus technology and we are very enthusiastic about the work you just presented as we are also ourselves uh just recently starting on a very similar let's say project um I was just curious have you guys did any kind of simulations for the economical viability

because keywords that you mentioned is cheaper more resilient and of course that was that that resonates with me personally but if you could just elaborate a bit more from the perspective of simulations and the cost effectiveness of everything um so I think we haven't decid I think the the actual auction mechanism is something that I think there's still a lot of very active research on I think there's even a talk perhaps later to maybe it was earlier today on whether first price auction makes s second price whatever uh so we haven't simulated that I think it's most likely that we'll start with a version that's fairly opinionated with like a limited set of provs um and like a limited set of supported proof systems

and then over time generalize it uh so to answer your question in short we haven't done much simulation it'll start in like a more closed setting and then over time we'll take that feedback loop and use it to develop to do the simulation when it makes sense okay thanks clear amazing talk um how do you think about uh sharding and scheduling the proof generation or the statement itself to a diverse network of participants yeah this is a good question so a lot of um ZK VMS today including sp1 basically take a really long program or statement and then break it up into substatements um for and then

combine them all together for one final proof that can be verified on ethereum there's two models of the world one model is each sub proof gets sent to the network as a separate request and each aggregation step also gets sent as a separate request uh there's another model where you basically just send hey I want to prove for this program and then the prover does all of that aggregation and recursion themselves um I think either model could work with our system because it's pretty flexible although I do think there are benefits to having a very pipelined charting and aggregation that come from just having one prover do everything uh because you just get a lot of like engineering benefits uh from having it in like one Data Center and like being able to talk

to each other very fast so yeah I think either can work and it just depends on like whether what people who are using the network want to do okay we had a few hands the gentleman in the bay shirt yep you have to push the button thanks so much that was great talk uh question why do you think that in action model the price variance is going to be high because that's a little bit counterintuitive like when you do an auction people with few money they get kicked out of the pool pretty quickly and the market discovers the price thanks yeah so per ethereum block for example depending on you know what is in the block your

amount of like the amount of computation in a ZK proof can be pretty different so an isue so you could have something like gas where for example the gas for an ethereum rollup is mapped to a ZK gas uh instead and then it's like a more fixed class and you have some EIP 1559 type mechanism uh that could work but as it stands today usually most rollups gas schedules don't align perfectly with the ZK uh proving costs so today it looks pretty variable just because of that okay the white shirt uh so what do you think will be the

Dynamics of the demand side like you compared to ethereum but in ethereum there is a very clear you know price pull but um in rollups there is no Dynamic so what do you think will be the reward like a bounty system that each each all up will put or like how do you think it will take place yeah I think the role up similar to how like ethereum delegates a lot of Stu their rollups and rollups are free to experiment perhaps some rollups the rollup team will just pay for all the proofs maybe in some other rollups the cost will be passed to the end user in the form of like some part of your transaction fees dedicated to proving um

in Tao I think they're doing a based rollup where there's some like proof Bounty um I think rollups can experiment with different models um and then use like the unified API with whatever way that makes sense for them okay we have time for one more question there you go yep hello hi om uh amazing talk I just have one question how do you ensure privacy of fitnesses in the case of decentralized pro networks yeah it's a really good question so for witness privacy generally you want to generate your

proof client side but I do think there's still a huge role for decentralized pro networks to play in because client side you generate a proof uh that's maybe not that succinct so you have small approver time but High verifier time and then you can use approver Network to basically take that proof and shrink it into something that can be verified on chain already a lot of teams act do something similar to this uh so I think the initial proof will be generate client side and then you dispatch to the appr network and at that point you don't care about witness privacy okay thank you so much Uma [Applause]