zkAcademy #2: Misconceptions About zkRollups with Aleo Presented by Union Build
1 Nov 2023 · 50:07
The Rollup's zkAcademy series, presented by Union Build, features Alex Pruden of Aleo addressing common misconceptions about zk-rollups. He walks through Aleo's application runtime environment, how it lets software compile, execute, and finalize state autonomously while preserving security and trustlessness, and what that model means for developers building privacy-preserving onchain applications.
Speakers
Topics
Transcript
[Music] [Music] [Applause] hey everybody uh it's a pleasure to be here today on the rollup my name is Alex Pruden and uh I'm going to be talking a little bit about the economics of ZK today and in particular the economics of uh of ZK rollups um since I think this is a relevant question for everyone
interested in scaling blockchains I know a lot of folks are really excited about zero cryptography I personally work at a project called Alo which is a ZK layer one that's you know doing smart contracts in a privacy preserving manner using ZK as well so ZK is a really popular topic these days but I I think the economics of it you know a lot of people kind of focus on the cryptography and the moon maath and the magic which I think is all very interesting personally but I think you know for this technology to be relevant of course it needs to solve an economic problem or at least we have to consider the economics of it so that's what this talk is going to be about today hopefully this is enlightening for everybody again I am Alex I'm the CEO of a project called Alo but before Alo I worked at a16z crypto I
was one of the first Partners on the uh on the crypto fund there and in general I've considered myself a member of the crypto Community since I got interested in the space in 2016 when I was still in the Army working in the Middle East um and I really was interested in ZK in particular because I think it holds a lot of Promise uh for you know solving real world problems not only in web 3 but beyond which is why I ended up I ended up at Alo so I guess maybe just some more context for this talk in terms of my background in ZK so I run a ZK layer one I run a group called The ZK Study Club with Anna Rose who is the host of the ZK podcast for that in that uh Study Club we talked to a lot of ZK
researchers about about the newest latest and greatest Moon maath um so that's that's what I do there and then in addition to that I run an initiative called Z prize uh which is an O open uh public uh initiative around accelerating zero knowledge cryptography through Hardware acceleration in particular so I am thankful to have gotten a lot of experience in the space over the last couple years thankful to have worked directly with many of uh the leading cryptographers here so I have a pretty in-depth understanding of how things work under the hood and hopefully you know the goal of this talk is to again talk about some a little bit less cryptography like but more my my masters was in business I'm not a cryptography Masters but you know I do I had more of like a business uh I had I went to get
an MBA so this is more about kind of the economics we consider like building a business and using these for real world use cases so okay I'm going to just go ahead and jump into it uh okay so here's our agenda I think it's important to start out by talking about okay so we're talking about ZK but this is the rollup and I think there's a lot of folks including myself who work in blockchain with blockchain technology with cryptocurrencies so I think it's it's important just to start off with the defining what this is mainly so we can get on the same page for comparisons later on because ZK rollups in particular or ZK scaling Solutions generally often are uh you know kind of set in the context of a layer one blockchain upon which they are adding scalability right or some feature right so I think it's important to just kind
of understand first off just or acknowledge what makes blockchains different than like aw like you know like a ledger that a bank maintains for a programming environment that I can access through like AWS an AWS server right um to be clear there are plenty of applications for ZK in those contexts but they're very different and the assumptions underlying them are very different than what we consider for blockchain so I think that's what we're going to talk about first the second is just kind of talking about what is zero knowledge cryptography again I just told you I have an MBA I've been working with a lot of ZK cryptographers for a while so I'm pretty sure I can give a pretty satisfactory answer from a technical level but for the purposes of this talk we're not going to technically get into what ZK cryptography is and how it works
or polinomial commitments or any of that we're just going to talk about at a very high level in particular around the interacting parties and the costs associated with both the proving side and the verifying side and that leads us directly into the economics of ZK rollups right since we have to account for those costs right and those those costs have are are part of this broader economic system right which we can then look to to understand like where the constraints will be and how do we expand that bottleneck right lastly we're going to compare the L2 and the L1 in terms of the actual cost denominated in a number of different dimensions and we'll kind of just decide maybe just leave as an open question you know this approach and kind of where to go from here so um I guess maybe the last thing I'll just
actually no I'll just jump in I'll just jump right into it that's enough front matter okay so what is a blockchain uh a blockchain as I Define it is a network of distributed noes which processed client transactions trustless um so what are the Key Properties um again I just said one of them trustless so I can operate a node I don't have to count on whoever else is operating nodes to uh follow the rules why do I not have to count on any individual to follow the rules well that's because collectively via the process of consensus in bitcoin's case proof of work in ethereum's coin case proof of stake in you know Alo the blockchain I work On's case it's it's a variant of proof of stake called narw bullshark we we all collectively run this algorithm and we know that if anyone is doing something
malicious or mis behaving in some way then collectively the broader group will kind of excommunicate them or punish them somehow in the case of slashing right so there's like an incentive to follow the rules that doesn't mean that rules can't be broken it just means there's a strong incentive to follow the rules so that's why I don't have to really worry about whether or not everyone is following the rules because I assume there's some collective punishment or Collective incentive for everyone to do so so the implication of that is that everything is trustless the second implication is as a client I can interact with the network interact permissionless right if I'm a client if I'm running a metamask wallet let's say you know I'm the client effectively and there's a node out there that's a server and if the node says hey I don't like
Alex uh he's a jerk I don't want to process his transaction I can just go to another node and submit my transaction maybe maybe it's my mom who runs this other node and my mom's like Oh I love Alex he's a nice guy you know I ra I I raised him and I have a vested interest in processing his transaction right so the point is that as a client I can't just be blocked from processing a transaction by a single party unlike and again it's like maybe this is a hammer over the head but I guess like it's just important to call out that this is very different than like the banking system right uh where they're like okay hey I don't like Alex I decided Alex is no longer allowed to have an account at my bank Alex is now locked out of his
account there's really no way to get it back unless I convince that person who's the gatekeeper to give me permission so this is what blockchains are really why they're special right and I think it's just important to keep this in the back of our head as we're discussing the added assumptions that we bake in here when it comes to rollups right and other scaling Solutions okay so in order to like contextualize ZK rollups a little bit let's talk about what zero knowledge cryptography is for the purposes of this talk again I I promise a very high level Elementary School overview and this is what you're going to get okay Z ZK cryptography discusses aover and a verifier there these two parties right approver wants to make a claim about a statement's truth to a verifier right so it's like I claim X is true and the
verifier either accepts that it's true or rejects right and the the whole Magic of zero knowledge cryptography is that the prover is basically able to do this without revealing to the verifier anything about the statement being proven that is strictly speaking the definition of zero knowledge which is the last bullet that I highlighted down there there's two other properties that we care about which are kind of basically implied in any real world ZK system that's used in practice today but just to you know for completeness of this talk I'll run through them every every interaction between approver and a verifier is supposed to be sound which is to say that the verifier should not accept you know we should not accept accept two accepts should not accept a false statement except with the ex version of accept with negligible
probability just ignore the negligible probability part that's what cryptographers say when they mean like statistically speaking it's impossible right so verifier statistically speaking will never admit a false proof right so they that you can never convince the verifier under these under a proper zero knowledge scheme that a statement is true when it is in fact false next the statement is we say is complete which is to say that theover can like any one of a class of statements like any uh you know any string in a language that's actually too complicated I promis Elementary School any statement in a family of statements in the complete family of all possible statements can be proven right so just really about saying the prover is unconstrained they can prove whatever they want within this
giant context right okay so that's what zero knowledge cryptography is now I think the main reason I wanted to pull up the slide is again just to highlight the fact that there are two pieces here there's aover and there is a verifier right there's not like aover doesn't exist in isolation a verifier doesn't exist in isolation a zero knowledge system inherently contains these two parts and it's both of these parts that we have to analyze when considering the economics of a ZK rollup okay uh okay cool and then I I think it's by the way that definition I just gave you is from a 1980s paper right 1982 paper um the gmr paper which you know this was these these were basically invented uh of course ZK has come a long way since 1982 I probably don't have to
convince any of you that um but the idea here is the main Innovation that has come since is that there's this concept of a cinct proof right this is actually for those of you who want to know what ZK snark stands for ZK snark actually stands for a zero knowledge synct argument of knowledge right um and the succinct here is doing a lot of work typically it means either the proof is small relative to the whole statement being proven or it means that the time for the verifier to check the proof is short relative to the time it took theover to communicate that whole proof to the verifier right these are kind of fuzzy in terms of like they're strict definitions and this fuzziness is what permits basically this
entire galaxy of different zero knowledge proof constructions uh snarks as we typically refer to them in blockchains are really referring to a specific category of zero knowledge proofs of ZK snarks that use polom commitment schemes and you know not going to like go and disambiguate or get too deep in the weeds there but the long story short is snarks as we typically refer to them in blockchains use these polinomial commitment schemes as a key building block and the nice feature about them is succinct in this case for the ZK snarks and by the way let me to find like where you would see these this is like ZK snarks as in used as as in used in um zcash first and foremost I mean they were really the Pioneer for ZK
proofs in blockchains and then you know later constructions like we have Aztec we have tornado cash um you know several of the rollups ZK stin uses a vanilla we'll call it snark approach right the and succinctness defined in this vanilla snark here you can actually see for those of you who aren't familiar with uh uh computational or algorithmic complexity terminology this o parenthesis terminology is really about how a uh a value scales uh you know as you increase uh as you increase the end right so let me uh let me let me try and not make a self referential definition right so here we have algorithm Pro complexity so you have o of n log n so if n is the size of the statement being
proven the scale at which that proof uh the proof time grows is basically the factor n Times log of n right so that's kind of how people you know um computer scientists talk about how things scale up so you can mostly just ignore everything I just said if you're not interested the point is that the traditional flavors of ZK snarks uh that we see mostly in blockchains use this special type of commitment scheme which means o of one complexity for the verifier and O of one proof size right what does that mean in human terms that means that no matter how gigantic the statement is that I give you as a verifier using this scheme that proof is always the same size I mean literally the transcript could be the size of the
Galaxy like it could take up that much paper but the proof like the the statement being proven could be that big but the proof is always going to be the same size no matter what right so that's a really nice feature right in terms of size right and then the second is no matter how giant that proof it will take the same amount of time for the verifier to check it right so no matter how big it gets the verifier time and the proof size is always constant right so we're talking about the economics of rollups and the economics of proofs generally we have to remember that like in there's economics implies like a dollar or a currency you know there's some kind of like economic or financial value but there's the economics can also be
defined in terms of computation right and that even that computation can be broken down into memory consumption and actual computation as well as storage right and why would storage matter well storage matters particularly in the context of blockchains back to how we first defined it right because if a blockchain node operator has to store four million terabytes of storage I don't even know what that would be exabyte or something I think right like that's obviously going to that's not within reach of the average person right my laptop has a few terabytes so it's not running a exabyte large blockchain right which means now that there's basically a gatekeeper in the center of this whole thing right so that's why we care about size right um okay so I kind of talked about the First Column a little bit if you ever see the
terminology over on this uh on the I think the sixth uh line down is Groth 16 this is kind of the most vanilla of the vanilla version of snarks this was pioneered by zcash and uh gr 16 is kind of like you know was was was uh is what a lot of people refer to when they talk talk about these like early types of snarks although plon and Marlin two other proof systems that update Gro 16 which allow for Universal computation instead of a single statement are in this family as well uh okay in the interest of moving on we could probably come back to this slide during Q&A but I want to make sure we keep we keep moving here um but there's also Starks right so many people have heard of starks mainly because of the company named starkware uh which the authors of the paper which
describes Starks which stand for scalable transparent arguments of knowledge which so ZK Stark stands for zero knowledge scalable transparent argument of knowledge so if you notice there's actually a little bit of a difference uh the in ZK snarks the S stood for succinct in ZK Starks the S stands for scalable again it's a slightly fuzzier definition but you can kind of see why over here right so what's the advantage of a ZK snark I don't I'm not going to explain the difference between log and polylog but the short answer is generally speaking Stark proving is faster so Starks you can use to prove a statement faster than you would the equivalent statement with a just a vanilla or gr 16 style snark right
that's the advantage now why is this called scalable instead of succinct well because compared to the Vanilla family of snarks uh you know Starks actually do not have a constant time verifier or a constant time or a constant size proof right and you can actually see in practice the uh the size estimate for a transaction here you can see this is a single trans action compared to the single transaction just ignore the proven key because that's it's on the client side we can ignore that for the for the moment but the the single transaction size is 200 bytes for for a regular ZK snark and it's 45 kilobytes for a ZK Stark right so and that by the way scales up uh as you can see like here these two numbers the same here
these two numbers are you know one is much larger than the other that scales up Al be it logarithmically but it scales up the more transactions you kind of pack or the bigger the statement gets basically right and in addition the verifier time is also not constant right so the verifier time takes a little bit longer and it scales up as the statement Grows Right Now what's the advantage of this scheme well again it's the slightly faster appr it also doesn't require what's called a trusted setup is a whole other probably topic for another day um in short I think trusted setups are a little bit overemphasized in terms of a potential uh vulnerability and this this chart I pulled from a great repo by the way for anyone who's on GitHub awesome zero knowledge uh maintained by the matter Labs team great resource that's
where I pulled this chart from okay um but moving on here okay so now we kind of have an understanding of like how this works and okay so now what's a ZK rollup I meant to put in a slide here about what defining a ZK rollup is but maybe like let me just verbally describe what a rollup is okay so in ethereum We have basically the world and the history of the world separated into blocks right and each block represents a 15-second time in a r right and inside that 15-second time interval different things can happen that the way that things happen is via users sending transactions I send someone some usdc someone else interacts with Unis swap someone's trading some nfts so these State these are called State Transitions and these State transitions are affected by transactions right now what's the
problem with this well the entire ethereum network has to reexecute every single one of these transactions right so because the ethereum network is executing every single one of these transactions you can see how pretty quickly you hit a scalability bottle deck and so anyone who's lived through like 2017 or 2020 times when crypto is like really happening uh the gas costs in ethereum just absolutely launched through the roof right and that's partially because of this fact that everyone is re-executing all the same transactions and you know and therefore the scale bu constraint okay so rollups were proposed as a solution to this problem by offloading some of the offchain computation right it still requires that so maybe before I talk about the requirements let me just talk about how
it works so a rollup is basically a separate uh it's a separate um system if you will in which I as a client can delegate basically the execution of my transaction not to the network of all the nodes in the L1 but to maybe a small subset of those nodes or a separate subset a separate set of nodes altogether right and then the idea is that that maybe this set of nodes is using some faster Hardware or maybe there's like some other assumptions there and then they basically settle that they do all this computation and then they just post the result of that computation back to the L1 right now the as kind of initially described the advantage of this was that you as the client were able to get all of the
trustless and permissionless properties of the L1 by virtue of the fact that like every single block like the offchain network had to basically settle and prove all of your transactions that were having offchain however this is where we're going to get into the economics it turns out that doing that is actually quite economically challenging or let me state it another way it's not economical right so uh and we'll talk about that talk about that now right because there's the reality is the offchain network to settle these transactions to ethereum in the ZK rollup case so I'm only going to be talking about ZK rollups now which basically describe a situation or a a system in which the proof that I that the offchain network uh processed your
computation correctly is a zero knowledge proof right so it's one of these in the case of like ZK Sync It's a ZK snark in the case of starkware it's a ZK Stark right it's a proof that hey we're at this offchain either one computer or a network of computers process your transaction and now here's the result along with a proof that we did it correctly right so there's a lot of advantages for a ZK rollup over something like an optimistic rollup particularly around you don't have to like go back in spot check whoever did the rollup you know you can basically just trust by virtue of the fact that you can verify the proof yourself that everything was produced correctly but what does that imply in terms of the economic costs there's really two costs here right because there's I said two things right one is that there's data
that's posted about your transaction that gets put back on the ethereum main net that data is usually put inside of the call data section of a block which I'm not going to this isn't a lecture about the structure of ethereum blocks and how that works there's a lot of great resources out there but the tldr is call data is kind of like it's like the cheap you know it's just like some cheap storage bins you buy at Walmart right like it's not really concerning M like application State on ethereum it's just kind of there for extra stuff right and so basically the reason why rups use call data is because call data per BTE is cheaper than putting uh data into storage on ethereum right so if you put it in call data it's different than
putting into storage and it's cheaper right but nonetheless these costs exist every single time there's a state transition on the L2 the L2 operator has to post that data onto the L1 in the call data in the clear which is maybe like an interesting diversion or you know kind of uh kind of stepping back back here this is actually one of the reasons why I think it's a bit of a misnomer to ref refer to zero knowledge rollups as zero knowledge rollups is because what we're really getting from the ZK rollup is the succinctness property right so going uh going to this slide so you're basically batching a bunch of transactions into a single small proof in the case of a ZK snark or even a stark right and so you're taking advantage of the fact that like it's
only constant size or grows very slowly but it's actually because of the fact you need to post all the information about transaction in the call data in the clear the before and after States it actually doesn't give you privacy which is another way of saying zero knowledge again the academic definition of zero knowledge is the verifier learns nothing about the statement being proven other than it's true right so that's like just kind of like a little side note there so call data posting is one cost right the second cost is proof verification right so ethereum the unit of account on ethereum is the is ether what is ether for well ether's there if you want to access the resources of of that Network right and the resources being the collective computational and memory and storage resources of all the computers
around the world that are running this consensus protocol right and so all you know like I said earlier uh the reason why ethereum was kind of running into scalability properties these various times is because or scalability challenges at various times is because you know all these different computers are having to like step through each state transition and then come to consensus one step at a time about the result right so it sounds kind of like overhead that's because it is but you know ZK RS let you get around the actual State transitions but what they don't let you get around is the proof verification now again I said this is not going to be a lecture about ZK but all I'm going to say about ZK in the context of the evm the ethereum virtual machine is that the evm is a very
general purpose World computer as it is often called and you know World computers operate like in binary machine code there's like evm bite code which is kind of you know you can kind of get a sense for like how things work at a low level on on uh on ethereum by just inspecting the bite code on block explore like ether scan but the tldr is like it's just defined to be a very general purpose Global World computer processor right whereas ZK and ZK rollups are kind of defined over these very specific cryptographic settings right which requires emulating that setting inside of this General computer and if you don't understand any of that it's not important the point is that it's expensive right the cryptography that is needed to use some of these like
performance zero knowledge systems is typically not supported in ethereum directly right okay so that's that means that like proof verification is on average very expensive okay and now here's the point right the point is that today in the real world it's actually not the proving time that is the bottleneck for settlement on the L1 it's the verification cost right and it's exactly because of this slide right the proof verification in the case of starkware for example it's 5 million gas keep in mind like a entire ethereum block takes 30 million gas as the gas limit which means a single transaction taking five million gas implies that one sixth of all of the operations of a
world of the world computer in that 15-second time interval are occupied with just this single transaction which is the proof verification itself right so gas of course as I started explaining a second ago ethereum the native unit of account on or sorry eth the native unit on the ethereum network is used to pay those gas fees right so they're very expensive right in the case of saret these are uh this this data is from um uh September I believe of this year I pulled this all from ether scan as well as dune analytics a great uh Analytics tool for um you know for analyzing ethereum and other blockchains um but yeah so the the the point is this right so Stark net in if to settle a stark net proof on the ethereum L1 is $75
in in September prices average right so what does that imply that means you need $75 worth of transactions on the L2 to make it worth it for Stark net to post back to the L1 in fact the number is actually more right because of what I said here because not only are you doing the proof verification you're also posting all the call data for everyone doing transactions and that you have to do every single block and even that's much cheaper those costs can add up a lot too right so the tldr is like the C the actual cost per proof verification is very high even for other blockchains that don't use Starks and Stark the ZK sync proof system uses a little less gas than Stark net but as you can see it's still pretty significant but the up the
the upshot here is that because of this expense it means that Stark net and ZK sync and all rollups basically have this property where they don't settle immediately so keep in mind back to the comparison with the l1s you have this L1 on ethereum which maybe is pretty you know blocks are full lots of people are trading FTS or whatever and to settle immediately you have to pay a high cost right but in the CK rup world there's really no way for you to force necessarily Force settlement immediately right or at least it's not economic for the provider to do so in the long term right because the end of the day every time they settle effectively cost this amount of money right and that's the first chart the second chart is like
okay on average they get enough fee they get enough in fees to settle in this time interval right and so what effectively you end up having then because of this fact the you know which is that verification is more the bottleneck than proving you effectively have this case now where like you can either pay a lot for your transaction to be settled now on the ethereum o1 or you can pay less but you have to wait for it to be settled later right so I think this is one of the interesting like this economic implications of ZK rups that a lot of people aren't aware of and this has nothing to do with Hardware acceleration you could accelerate you know you could literally build a Dyson Sphere around the Sun and put all the gpus in the world around generating faster proof it still won't
change this economics right here right the only thing that changes this is the cost of gas on ethereum and if someone invents an entirely new proof system that we haven't we're no longer aware of right or that we're not currently aware of um okay so in addition to like this reality there's also uh kind of a reality of like what is a ZK rollup in system in light of these economic realities in comparison to an L1 blockchain so like I look at back to this chart like I can send a transaction on L1 right the dream of a rollup is that like anyone can just be aover send the themselves to the or send the proof themselves to the L1 blockchain and settle their transaction immediately the reality is that every single one of the
ZK evm teams every single one of the ZK rollup teams on ethereum all run a centralized Pro right which means like there's an AWS I'm assuming AWS or digital Ocean or gcp instant somewhere with a gigantic CPU bunch of memory and maybe some gpus or fpgas that process your transaction for you back to what is an L1 and L1 is permissionless this is no longer permissionless now right sequencers uh lots of ink has been spilled over how sequencers on rollups are going to be decentralized I'm not going to comment on that because it's outside of the context of this talk it's just to say that like today you rely on a third party for sequencing just like you do on provs right similarly the point of this talk has mainly been been to point out the bottom two or the third and fourth bullet which is that proofs in the dream
scenario are kind of really small and they're cheap to verify in gasms which means you can throw them on the E theum main chain all the time and basically just batch things very cheaply the reality is they're not cheap they're large right and the more people that use the L2 the more call Dat you have to post which Mak makes it very expensive for The Operators right that's why you have settlement times that are much slower like effectively a block time for for Stark net in terms of settlement is 7 hours right of course it takes maybe second to execute the transaction but to settle it on the L1 takes hours right and that's slow even when compared to like ethereum or even Bitcoin right and then lastly I'm not going to touch on this either because it's really outside of the scope of this talk but it is
probably worth pointing out that these ZK rollup constructions that let you emulate the ability of the evm to do General smart contracts typically have to make compromises around the programming model because many of the uh underlying op code of ethereum or pre-m compiles don't exist to make you know a lot of these operations efficient right so in short the compatibility with the evm is limited at best um cool uh further reading uh there's a I I'll maybe post some links uh I'll give uh give the host of the show here some links that they can post and maybe that concludes my talk and uh we can take questions thank you all very much for your attention
awesome Alex that was a doozy thanks for uh thanks for the presentation man and uh yeah I have I've got a couple questions I think uh to start um maybe we could go to the types of ZK proofs and we could clarify the the difference between the succinctness of snarks and the the scalability of starks um so if if we kind of zoom in on the the size estimate for for snarks and for Starks um for Starks we can see how the size estimate for one transaction is 45 kilobytes and then that increases as you
add more transactions whereas for snarks the size estimate stays constant regardless of one transaction or 10,000 transactions to that seems like like the snarks because they aren't increasing the size as you scale the transactions they're actually more scalable than Starks but Starks are the ones with scalable at the beginning of their name so so why why are Starks considered scalable despite the increase in size over the amount of transactions I you know like that's a that's a good question for the marketing team at starkware probably or the authors of the Stark paper um I think like look they I to be fair to that to
them I think scalable in I think I think what they're trying to communicate by scalable means that as you have a bigger statement to prove the proof time is better than snarks right so in that sense you could say it's more scalable I think that assumes that the proof time is the bottleneck which I spent most of this presentation trying to explain to everyone that's actually not in the context of web 3 right um but that I think you hit the nail on the head um like snarks gr 16 style snarks plonc Marlin all have constant proof sizes which is really nice because especially if you look at the like just the size of one transaction like you think about blockchains like an ethereum block you know we're talking maybe a megabyte a
couple megabytes right 45 kilobytes is is large right like this is you know you talk about you know even a batch of a bunch of transactions you're talking 100 kilobytes that's a 20th maybe of a whole block probably a tenth right if you're talking about a normal siiz block and so you know this is a big problem unless you decide to expand the size of each block uh which of course has different scalability implications for the network and security implications got it okay and okay so my my second question maybe we could play MythBusters here because one of the one of the primary value propositions I was told about ZK technology relative to optimistic technology was that it scales with the
amount of transactions and I don't know so I was told that as a Merkel Tree Grows it's easier to prove the validity of transactions SO gas costs actually go down as more there's more throughput is that is a myth or how how does that work gas costs well this is I guess it kind of depend this is like by the way this is a totally fair question and it's it's very difficult to parse this in you know in the Twitter sphere right because like everybody has an approach they've chosen by the way I work at Alo I we have our own approach we haven't talked about here but like whatever right everyone has their angle right I think what you're describing is on average fees
might be lower for an individual user if there are a lot of transactions right if there's a because this is a single cost paid once right so whenever you whenever you want to do a proof verification on startet let's say it's a 75 it's $75 and please like I said no one hold me to this number today this was pulled from some date in September maybe it's different maybe it's 50 bucks maybe it's 100 I don't know whatever um but like 75 bucks is the cost on chain right and so if me and you and 10,000 other people are batched into that proof then the cost per each of us is low right but this cost here is constant for whoever is the rollup operator right and so I
mean maybe the rollup operator is okay to subsidize the cost and lose money but I'm saying from a economic actor perspective you're never going to pay this cost unless you have enough users collectively get you to the threshold of $75 or $37 whatever it may be so I think that's that's probably the clarification is that it's cheaper on a per user basis than the ethereum L1 potentially but again your trade-off is time right if you're willing to wait enough time for 10,000 people to do a transfer then it's cheaper but that's not the same as I can send you usdc right now on the main chain and pay I don't know maybe like you know $10 a fees or $5 a fees but it's right now
right for a payments use case I actually think that's pretty important right you're not going to give me the coffee unless I pay you right now got it okay and quick tangent relative to optimistic rollups which we didn't touch on really at all today do those also scale cost of transactions linearly constant is it still a constant price per proof onto the main chain for optimistic pups yeah so we didn't talk about it and I'm candidly less of an expert on optimistic constructions than ZK but I do know a fair amount my understanding is that like look fundamentally it's the same thing right you're basically you're doing the same thing in either case right now what are
you not doing at the optimistic rollup you're not doing this proof right you have a separate process for basically verifying that the the offchain network was doing the computation correctly right and that process involves like me checking you after the fact and being like hey show me this like let me just double check and make sure you did this line correctly or this line correctly this line correctly and so on a cost per transaction basis like optimistic rups are going to win every time because of this proof verification thing doesn't exist now what's the tradeoff there well this the settlement time the settlement time for optimistic Ro I think arbitrum has a sday settlement window right so actually I mean if you just assume that
you never leave optimism it maybe doesn't matter but assuming that you do want to go back to ethereum and you want that to settle on the main chain that's seven days that you're waiting instead of seven hours that you're waiting right so seven hours is already a long time seven days is an even longer time that's the trade-off so basically what optimistic rups are doing is just pulling you further out on this time scale at maybe a lower cost per transaction right but the tradeoff is the time because you need to give the verifiers time to catch any misbehaving operators understood I I think the Dilemma between speed and cost is very clear between optimistic and ZK rollups I I want to hone in on one more question
I think Annie may have questions as well could you go to the the comparison between ZK syn and Stark net one more time so here we don't see the tradeoff between speed and cost because ZK sync both is cheaper to transact and quicker to transact so what is the tradeoff that ZK Sy is giving up and Stark net is is handling in order to sacrifice the speed and the cost are are they improving on another angle is it is it security or is there a missing tradeoff here it's a it's important to note this a great question it's important to note that like strictly speaking this comparison here isn't exactly Apples to Apples now
why do I say that is because I took the average uh over the course of a month right and I think remember there's both proof verification costs and call data costs right and so potentially the more people that use ZK sync like they you're still having to pay a little bit more in terms of call data if you're just talking about strictly speaking gas costs and by the way there's a great uh I'll find it for you I'll send you guys the link but there's a great article on medium that describes just the gas cost alone for ZK sync uh over over starkman it's about a fifth of the just the gas cost for the proof verification this additional cost here there's probably some nuances around the number of users maybe the architecture
is slightly different so it's not I want to make sure I to be careful here like this isn't exactly an Apples to Apples comparison but I think what it highlights is a there's a basically a a relationship between the proof verification cost and the settlement time as well as the fact that snarks relative to Starks going back here like the proof verification can be constant so the more transactions you're packing into a stark the more expensive it gets to verify in fact right or the Le and vice versa if there's less right so it's kind of just really illustrating that instead of being a strict Apples to Apples uh comparison there I hope that wasn't
confusing yeah no I I think it I think it answers the question um because there there's a direct relationship between transa verification cost and verification settle settlement time yeah that's right and and I think the one thing to note is again like the way the place that Starks beat snarks very clearly is on the proof time right by the way this is why certain zkm constructions actually used both polygon's approach I think it's polygon I think it's just there ZK I think it's just called zkm they use a stark to prove basically all the rollup Transitions and then they use a snark to prove the verification of that Stark
proof so it's kind of like an onion right you have like a stark proof wrapped in a snark proof so you get a faster prover and a constant size uh you know verification time and proof size what's the trade-off well now you're doing two proofs instead of one right so like so you know again this this is why like the point I hopefully the takeaway for this talk is not I definitely did not want anyone to walk away from this being like Starks are better snarks are better bulletproof are better the reality is these things are different on the dimensions I highlighted and it really depends on the use case right in a world in which like for example everyone is just building directly on Cairo on Stark net they don't care about settling to the L1 guess what proving time actually does matter more than
verifying time there because there you don't care right you're not settling so the verification doesn't really matter as much right but if you are building a rollup construction and you're using for like payments you know a long settlement time is bad because again the verification time is large and therefore you know no one's going to settle until there's enough money in the pot effectively to make it worth it right so it just all depends on the setting in the use cases I think I would like people to take away from this got it and I think that's that's what I'm learning and and we're all learning as we kind of like understand and embrace this world where there's thousands of rollups that that we anticipate will come online it's like not one of them is going to win over the other it's not a competitive
landscape they're all unique for individual use cases some of them use snarks there's reasons why that makes sense for certain use cases there are other proving mechanisms and other verifying mechanisms that make sense for other use cases and in this world where there's thousands and thousands of rollups each one of those makes sense and there's a different combination of proving and verification mechanisms with multiple design tradeoffs that will unveil for for certain reasons that that make that specific settlement proving verification combination the most applicable to the use cases that it
It ultimately applies to 100% I I think it's absolutely the way to think about it is not from the like a lot of us in crypto by the way I'm as guilty of this as everyone else we often think about building infrastructure from the ground up to support applications that will eventually touch a user right the reality is like as soon as there's a killer app in crypto but by that I mean like something like everybody's checking on a daily basis like they do a social media website like that's going to introduce a huge demand of a specific character and everybody on the infrastructure side is going to build tailored to that demand so it may just turn out that the killer app is like I don't know like gaming or something right and again as I said maybe they people who play games don't care about
permissionless I you know I kind of think that invalidates the point of blockchains but leaving that aside for a second maybe they just don't care that means that you can just throw out all of the permission list pie it means that like constructions like polygon where it's kind or like a binance chain are kind of Mak sense in that world right because you're like ah okay you know there's like two notes good enough but they can go way faster right and that's like does it make sense I mean it's it's you can just get into philosophical arguments with people about whether or not it makes sense unless there's an application that people want so I think that's you hit the nail on the head these rollups are going to be application specific I think in the long term that said I think it is important
to note that there can't be thousands of rolls I don't think why do why is that the case because ethereum has a gas limit of 30 billion per block this Stark net proof here takes one sixth of a Block's worth of gas so if there were five Stark Nets settling every seven hours then that block every seven hours would just only be Stark net right and so to the extent you imagine more people using this they want sell it more frequently whatever like you can see how this starts to fill things up really quickly this is why by the way a lot of interest has gone into making call data cheaper and looking at offchain what are called Data availability Solutions where you don't have to publish to the blockchain itself right and that in that world assuming those exist you could
scale up to much larger numbers of rollups again though the question is what are the assumptions right because if you have like data Avail data availability over here and you have a blockchain over here and you have a roll up over here at some point you kind of lose what I think makes a blockchain special which is trustless and permissionless again as I just said those applications like what applications those enable I have a list of several but you know I think people the market the world just going to have to decide whether or not those are valuable yeah yeah there there's still this open landscape in my mind of multiple Stark Nets let's say there's seven eight Stark Nets out there there's
10 other there's 10 other rollups out there and they're all publishing to the L1 yeah that will fill up the block but like ethereum can handle it it'll just push gas way way up users are still transacting in this relatively lowcost execution environment and if there's enough transactions and the cost to publish on the L1 is split across enough users then they still pay they still have affordable trans transactions but it means the gas price on ethereum is way way up there's lots of eth getting burned and eth the asset is very bullish and so this there's a lot of I mean I love this topic because there's so many variables right so on that in the way you framed it which I think is a
perfectly valid potential outcome I think it could definitely happen in the way you framed it though that's very bullish for eth right a lot of fees are being burned right but you know if you're a token holder for some L2 like what does that imply for you potentially if there's thousands of rups right like if one is cheaper than the other and they're all the same I just switch right so it kind of like it's kind of funny because that story implies a strong eth tokens price story but a weak L2 rollup token price story whereas you can imagine a different world where there's like one dominant L2 right that just can handle everything and everyone just converges on it right then that dominant L2 maybe can settle to like multiple chains or has a different data availability solution or something like
that right and then eth actually like kind of might be less bullish on eth but you'd be really bullish on that one L2 token right this is why I actually don't like framing things as l1's and l2s because in that world where like let's just say optimism handles 90% of all the transactions is it the L1 or the L2 you know what I mean like it's kind of it just it's like we think of it in terms of these layers but it's actually not really right if you think about it in that world so it's it's a fascinating topic and there's many V I hope you can see there's many variables at play here some are self reinforcing some are counter to each other it's just kind of hard to know exactly what is bullish or not bullish for ethereum or any particular L2 or rooll of approach
that's a that's fun to think about if optimism is selling all the transactions they're the main settlement engine so right they they're the L1 it's like whoever whoever is settling the most transactions ultimately is like the most based and then whoever's got the most order flow is like they're the execution basically right and this really comes down to like this fact there like trustless and permissionless is kind of like I mean it's sort of like a social concept right like we we just it's these are these are social decentralization is a social concept and that's why like it's doesn't have a you know you can consider these things in different angles because there's not like a rigorous technical definition yeah it's I mean we'll we'll see how this landscape evolves with with
regards to demand for for settlement and yeah yeah well well Alex it was an absolute pleasure having you on I I'm sure we could continue this in in so many different directions and and hopefully we we do get another chance to to uh continue the conversation um is there any closing thoughts on your end that that you'd like to share before we uh roll it up um yeah I just I guess I'll just quickly say one thing about like okay just you know uh I haven't talked about Alo at all this um talk but just I mean quickly like the all of this econ considerations and you know is why we decided to build Alo as a separate layer one so it's like separate L1 smart contract platform that uses ZK a because
it's very expensive to do on ethereum as I hope I've convinced you guys there's a lot of considerations B there's also not we kind of glossed over this in the talk but ZK implies zero knowledge right which implies privacy for use cases like identity for example like identity I think could be a killer use case for web 3 in a way that connects web 3 and web 2 you can imagine like a different form of authentication that uses your passport in a trustless way where you just generate a proof about your age about your citizenship about whatever right and that kind of can't work in the model of a transparent blockchain because you're basically just putting your passport up on the on like a b board for every to look at um but you know you kind of need privacy for that use case that's why we kind of built Alo the way
we built so I think there's a whole separate topic of people for that I would ask people to consider is like you know in light of the use cases that we think might be important how important is privacy for different use cases right to the extent we think it is then this zero knowledge property of ZK rollups it's it's you know implied but doesn't exist right it becomes more important right and that's another dimension that we have to consider uh but overall I really appreciate you guys allowing me to uh share with your community here I hope everyone benefited from this talk and got a lot out of both the presentation and the discussion and um look forward to uh continuing the conversation I guess maybe people can find me on Twitter Auden 08 um that's my handle and yeah look forward to continuing the conversation there or at
at at the next crypto conference uh with whoever you know maybe's listened to this so thank you very much thanks Alex