ZK Paris: Panel on Scaling with Tracy, Zac W, grjte, Marcello B, and Toghrul
5 Aug 2023 · 25:49
Tracy Livengood moderates a zkParis panel on blockchain scaling with Zac Williamson, grjte, Marcello Bardus, and Toghrul Maharramov, presented by Geometry and ZKValidator. The panelists, who each work on zero-knowledge infrastructure and tooling, discuss how their projects approach scaling blockchains using zero-knowledge proofs and rollups. The session was recorded live at the July 2023 zkParis event.
Speakers
Topics
Transcript
okay so last but certainly not least we have our panel on scaling with moderator Tracy livinggood from Pluto and panelists Zach Williamson from Aztec gershta from polygon Marcelo bardess from Herodotus and togrel marahamov from scroll cool Hello thank you hello uh Hello nice to meet everyone I'm Tracy um cool so today I thought we could maybe spend a bit of time focused on the prover role in scaling I think a lot of ink and has been spilled on the sequencer but not a lot of conversation happens about the lonely prover that
tends to sit in the back room on some AWS server so maybe we could talk a little bit about that role and some of the challenges and interesting pieces there and then open up for questions toward the end um but before we start maybe we could go through a round of introductions um briefly I'm Tracy I'm the co-founder of Pluto we're a company working on making snarks just generally more accessible for application developers um and maybe we just go through everyone hey everyone I'm Zach I'm the CEO of Aztec and yeah our gig is privacy making uh web3 private hello everyone my name is talk roll I do research at scroll we're building a ztvm bay CK roll up
hello uh my name is Marcelo I'm a co-founder for autotus and we are making on-chain data accessible for summer contracts I'm Garza I am the engineering lead at polygon Maiden we're a ZK rollup focused on improved scalability and privacy and extending the functionality of the um the EDM awesome so maybe the first place we could start is on Hardware so I think uh the previous classically like a hard problem it takes a lot of compute to to generate proofs for the Roll-Ups and today the Roll-Ups are probably the largest consumer or generator of ZK proofs in the world so they're they're focused the most on accelerating these proofs and cost them money to generate them
um maybe you guys could share just like for those of you that are you know generating a lot of proofs like what are you doing for Hardware do you have a strategy um how are you thinking about it I can I can start because I think my answer is going to be the easiest one because um when you're Focus what because the focus of our of what we're doing is privacy um a lot of the improving has to be done client-side in order to prevent secrets from leaking uh which limits the hardware you're using to whatever Quality Hardware new users running so that's very much the bottleneck for us um and it limits things like using custom silicon um uh so the best the best that we we can work on with our execution Department really is web GPU
um so yeah for us kind of it's all about the the the proving system and the and the abstraction is that you place between the proving system and the developer watching the circuit that's where we we can move the needle fortunately for us a lot of proving has to be done by the previous we can't really Outsource it to anyone uh we currently use a GPU approver we're exploring Asics but we're not really sure if A6 is the right path just because of them being a bit of a centralization vector versus gpus where you can get in any store yeah um I think it really depends how the program is going to look like
because in the case of Asics or if we go through the direction of gpus like definitely the way how we prove things is gonna it's gonna differ differ a lot um we have explored GPU implementation somewhat we're actually looking at um similar to what Zach said web GPU options and we have a metal implementation um inside of Winterfell to speed things up so we're leading in on consumer Hardware because we do offer client-side proving as one of the parts of our system cool makes sense all right feel free to like go in any direction you want with this it doesn't have to be too structured um uh yeah I think that's an interesting segue into decentralization so uh the deeper you go on Hardware if
you have an Asic that a consumer maybe doesn't have in their household uh it means you need specialized Hardware to generate the proofs and and maybe you can't get anyone else to to play that role how do you think about the trade-offs between that and decentralization I could stop are we all going to have like prover Asics in our phones and it's the problem is not going to be a problem yeah no um that would be nice but I guess there are some interesting trade-offs that you can make when it comes to decentralization and proving because When It ultimately when it comes to the resource costs of your approval like the physical like cash amount that your previous costs to run Germany for blockchain Network these costs aren't
that significant relative to the economic value going through a network or at least if they are you've kind of got a bigger problem than your Tech stack because they ought not to be um so like for example like look let's say you want to scale ethereum um and you're going to use the ZK VM then uh that the cost of your easy key of improvement might be very large but you're comparing that against the cost of every single ethereal node across the entire world running the same computation which means I guess what I'm trying to get at is that parallelism is a very very powerful um tool to speed up privers and so when it comes to that and that can ductile nicely decentralization because you don't necessarily need just one prover to make your blog you can split your block up proof circuit up into multiple
sub-circuits and kind of have a kind of a tree-like structure where you have a basic unit of compute that every prover is Computing and then you and then you use recursion to kind of aggregate those those proofs together what you lose there is latency so for for so I think what the real trade of space um is not really between like the the decentralization and um and the centralization of your freezers it's it's between the like how the the the latency of the communication costs between your previous and the quality of the decentralization you get as a result um anyway yeah yeah just to follow up on that I at least from our perspective decentralization of proofers is not
important from the perspective or redundancy it's also important for redundancy but it's more to increase the throughput of the protocol because let's say if you prove the block sequentially then currently our proof of times are longer than our block times and therefore if we continue doing that sequentially your finality times are just going to get longer and longer and therefore it's much easier to just assign proving duties of different blocks the different approvers and do that in parallel and then have them post the proofs on chain aggregate them and then verify the aggregated proof on chain and therefore decentralization is more of a way to increase the throughput of the protocol so you can say it in a
similar way that how Celestia does it but the dash light nodes basically the more sampling nodes you have in the network the larger the blocks can be and the same thing here the more approvers we have in the network as assuming no other bottlenecks the higher the fruit can be maybe to add on that I think there are two main ways we can look at like split improving so you can either aggregate on chain and all these proofs and also you can aggregate them off chain and create the three leg structure but that also leads us to another problem which is basically how we are orchestrate that proving that's also another question like should we select one leader and that leader says you prove this you prove this and you prove that or we go for a fully on chain approach and we
just merge the truths together onto actually the results yeah I think that's been an often topic or like a small topic of discussion in decentralization is you know how do you choose a leader how do you choose who's going to actually be in charge of generating proof for a given transaction set of transactions or block um what have you guys thought about in terms of decentralizing that role and and having an economically viable game that gets played I can tell you what you definitely shouldn't do you shouldn't use proof of work style it's just we're not going back to mining it's not even that it's like at least in mining you have some form of Randomness so essentially your probability of winning the puzzle is a relatively proportional to your hash rate in the network whereas
in here the most efficient prover always wins and therefore it basically has a significant centralizing Vector long term I think there are other structures that people have explored a versus like a race to the you know fastest proof versus like a steak based uh uh leadership election have you thought about the the trade-off at all we spent quite a lot of stuff thinking about it because it's a serious problem um that the whether you um sticking doesn't help because if you just request State because because what you're really because you're if you're using stake then who would the stakers said the block produces and you just get a secondary market for proving and you
really don't want a winner takes all economic market for proving because that will then lead you to just having one prover that that runs your entire network or producing child network and even if the proof is not doesn't have to be trusted because they can only either make the proof or not it has it has a huge centralization it allows an infrastructure risk because if that previous goes offline you've got problems if that proofer is forced to go offline uh because they're running on AWS and Amazon gets coffee and they're like you're violating on terms of service then you've got a problem oh sorry sorry uh so yeah I think it's very important that the network has an economic model which should send devices at least two previous and and one way you can do that is basically is again through
parallelism because if if you if you break up the the work that is needs to be approved into into a large number of blocks and they're all getting constructed in parallel then at the very least say if you have 512 compute units then the best period needs to be 512 times faster than the second best private for them to get all of the capture all the economic value so you get some effect useful effects there maybe you could go a little deeper on that so uh you you talked about splitting into 512 different provers each one needing to maybe prove a single transaction and then how did this come back together yeah so to give an example with with Aztec although it I'm not sure how applicable it is to the zkvm is that you um you have a roll-up circuit that
Aggregates to user transactions and then you take another circuit which Aggregates to roll-up proofs and then you take another second which Aggregates two of those in this tree-like structure so where it's always Two by Two by Two by Two open so you get to just a single proof that verifies everything and that means that there's basically just a lot of parallel compute that's up for grabs so even if you don't even if at the protocol level you don't just Define who is making those proofs um assuming an efficient market a secondary Market will turn up um to service the block producers and the hope is that uh you will get more than one prefer although I do think it needs more refinements because it's not just about how fast the prover is it's
also about their the the costs for them to make the proof and the marginal advantages that they have over other approvers so it's it's yeah there's it is a tricky very tricky problem but I feel like that's where staking might help actually so let's say if your goal is to incentivize as many approvers as possible what you can do is require them to stake a certain amount and then if a proof is not submitted within a certain period of time let's say five minutes ten minutes you slash them or you slash a portion of their money and and therefore no one is incentive there's no incentive to run just one Brewer because you're unable to submit all those proofs in time so it kind of incentivizes decentralization wouldn't wouldn't a
secondary Market sort of cause a problem so imagine imagine develop an asset so imagine your network privilege was running on gpus and I make an asset check which is way faster and way more cost effective then I can basically just act as a secondary Market or I can just basically go to all your approvals and go I'll do your prefer cheap you know you take some margin and we're all happy oh you could uh you could do that potentially if you have enough uh compute to be able to do that for everyone you can potentially do that but it's unlikely the the proofer market is going to control all the slots it's likely that some of those loads are still going to go to other s so it's the same thing as liquid staking even if like a Lido has a significant control over the network it
doesn't have 100 control and I think the same would be true here what's the thing is what what is the what is what is directly connecting a sticker to being a Proverbs and why can't they just pay somebody else to do that you could potentially uh do what ethereum does and basically embed the signature into the proof and therefore the only person who could submit the proof is the one who has the signing key to the address that you register on Jane wins taking um yeah fair enough that could work a slot leader for the proof generation
essentially um cool maybe we could shift a little bit I actually I want to hmm a question on so yeah I'm curious to hear sort of told girl like um I've seen work from scroll on like the roller Network um a lot of I think l2s today are focused mostly on the sequencer problem they're talking less about fraud proofs and less about the prover seems like Scrolls put some time into the roller Network and they're thinking there um how do you prioritize between those things or like uh vaguely how do you prioritize between those things we don't actually prioritize we work on both in parallel it's just we write less about sequencers because we're less convinced than what path we're going to
take in terms of sequencing but and therefore we just don't talk about it that much uh so in terms of the proofer as I mentioned before it's needed not because for uh because redundancy is important or something that's important as well but it's a pressing issue because we somehow have to paralyze the proving and the easiest way to do it is by decentralizing the network and allowing multiple people to participate and submit proofs in parallel and maybe for gershdi I'm curious to hear about and sorry if I pronounce your name poorly but it's a difficult one um so Maiden is kind of a new take uh on on some of these challenges it's it's not
an evm based roll-up and and you I think it's been a bit of a ground up rethink um what about that excites you and what do you think are some of the cool new opportunities that Maiden opens up um I think Maiden has leaned really hard in on parallelism and the opportunity is there to scale computation so we are doing the same model that Zach was talking about of doing transaction proofs and then batching them together and then that aggregating the batch proofs into blackproofs but we've also um we've adopted this uh note based model instead of having a strict account model where I send you a note and you have to actually consume that note so it's two
transactions for me to send you some amount of money and what that means is that you can do that Pro proof locally yourself I can do that proof locally myself and that opens up a lot of opportunities for parallelism it also opens up a lot of opportunities for privacy enhanced privacy and so that's something that I think has been a really big thing rethink that modern's leaned into and another thing I guess I would add is that we're looking at reducing State bloat as well um and one way to do that is to let users maintain their own State locally so shared State still has to be on chain and we still have to have all of that for data availability but if you want to keep your state private you can keep your state off chain and you have to be able to provide it when you do a new
proof to update your state but that means that the state on the Chain doesn't actually have to grow at the same speed at the same rate as it currently does got it that makes sense you can have just the commitments on chain maybe but the the full in any shared State yeah it still has to be cool yeah Biden's an interesting programming model I think it's pretty exciting um cool I don't know how much time we have is 10 15 minutes or we have 10 minutes okay let's do maybe one more question and then we can ask the audience um so let's maybe think a bit about the future um uh L1 today if you look at Main and ethereum I think all of the teams here
are kind of depending on that infrastructure in some way um it plays a diverse set of roles uh it it you know it verifies proofs from from the Roll-Ups it serves as a data availability layer user applications use it what do we think the role of L1 ends up being if we look forward to year two maybe even five um if if all the Roll-Ups are successful sort of in their Journey composability layer between different l2s so essentially all the Roll-Ups would use it to post data and finalize the state and then compose with one another and also probably some of the tokens are still going to live there because it makes sense if you want to have your token be moved around different l2s it
makes more sense to deploy it on an L1 rather than on a specific L2 yeah we believe that as one will always have a monopoly to basically be used as an exchange for commitments from all these different rollups which eventually will always lead to some delay when it comes to accessing data across all these rollups and that also leads us to a layer where we finally verify all the proofs yeah not not much to add really I mean any Divergence of opinions I think um yeah I think I think everyone will become the canonical store of value because because for the reason you said that it's useful to have comparability between of like the same asset on multiple different Roll-Ups but there's
it's a kind of a um if everyone else is successful it's almost inevitable that basically the everyone will just become the the point where the role is finalized and data is posted all of that might even go to another layer because um because like the economics will mean there'll it'll be somewhat too expensive for individuals which is like because they're not competing against other individuals they're competing against Roll-Ups submitting batches of thousands and tens of thousands of transactions yeah Roll-Ups will own the block space for sure they have a lot of valuable I think they already use up a significant percentage of course with 4844 that percentage is going to decrease but if we assume they're going forward uh more Roll-Ups are gonna pop up and more are going to start posting batches
and settling on the L1 you'll have more proof verification more use of storage for like storing State withdrawal trees Etc so the use is just going to go and grow the percentage relative to like the user so awesome maybe we could open up for questions at this point um thank you all for your um so my question is what is a layer two and do they exist today I'm sorry we can all at this point I'm very sorry roll up stance real yeah we're they're all silver and no no they're not all right should we go into the whole
social consensus thing or should we go with the l2b definition so l2b defines it as a layer that uses the underlying layer for correctness without relying on the honest majority assumption I I think it's not a complete definition because there are certain things that are missing there so for example there was an argument a few weeks ago whether um protocols that require an honest majority assumption for uh liveness should they consider it to be healthier or not and I I have I'm over nipping in the I think it's fine for for the liveness to rely
on honest majority assumption as long as the correctness doesn't rely on it so yeah we still don't really have a generally agreed upon definition sadly Patrick McCory is not in the crowd he might have probably expanded on it I do have a more in my Arsenal if we need we can keep going um we're in the back over here so if hypothetical scenario here if gnosis pay takes off and starts dominating block space over all the l2s because it has so many transactions
being processed through it then what is the role of l2s versus having alt l1s like nurses chain connected with trustless Bridges but there's no such thing as a trustless bridge um I have more of a question just following up what you said that there's no such as a trustless bridge um why isn't there such thing as a trustless bridge because an L2 to an L1 bridge is this trustless bridge it's oh sorry it's trust minimized so the way I like to explain it is this way so you have your teeth on ethereum you
run a full node doesn't matter what the network does they can never steal money from you because if even the majority proposes an invalid block stealing your money your node will always just reject it now let's say that a roll update uses let's say froppers for now CK is great so we're not gonna slander ZK here uh for proofs and for some reason the incentives are broken so no one's following the chain uh and somebody submits an invalid state and nobody challenges it and you would somebody and that person just steals your money and you run an ethereum full node but your money is still stolen so essentially you're making an additional
assumption that there's someone running an L2 node capable of submitting a challenge in time in case somebody tries to steal your money and the same is true with ZK but the assumption is a bit weaker you need to assume that the uh zero knowledge proof system that is used is actually correct and doesn't have any vulnerabilities that allow you to steal money so that's why my argument is that there's no such thing as a trustless bridge yeah I'm going to keep harping on this a bit more um actually if you do run a full node you can get Eclipse attacked and which you believe that you do have some funds but uh actually you don't so what is your response to that but uh Eclipse it uh so the assumption that you have at least
one honest connection is the core assumption you need to make some assumptions when you're on a full node that for example the signature scheme is running correctly and no one can fake the signature or the hash functions are running correctly so trustless doesn't mean that there are no assumptions it just means that there's a base level of assumptions that you can like not get away without having and anything else on top of that means that you're adding an additional assumption which means that it's no longer trustless it's trust minimized or trusted if it's a strong assumption so if we if we look at like running a node as the base layer of a trust assumption that you do need to have a honest Party In the Mix how is that different from a bridge that also
requires a harness body to be in the mix but now you have two honest parties to trust which is more than one honest party say again so now you have two honest parties to trust one on the peer-to-peer Network side and one on the if you were talking about fraud proofs on on the Challenger side whereas if you run a full node you're just one one on a have one owner's party to trust which is on the peer-to-peer side so it's by definition you have more assumptions here maybe my math is broken but um it's entirely on chain right it's just one person who has to submit this fraud proof as aware yeah but that doesn't have to be the same person as who's running the P2P
Network so it's those are two separate tasks so those are two separate assumptions that you're making I'm just gonna stop now maybe we could catch up afterward on how to define an L2 any other questions in the audience all right I think we can wrap up you everyone has survived the day congratulations thank you [Applause]