ZK Podcast: Optimistic vs ZK Rollup with John Adler

Transcript

[Music] welcome to xero knowledge a podcast where we talk about the latest in zero knowledge research and the decentralized web the show is hosted by me anna and me frederick in this episode we chat with john adler about optimistic roll-ups and how they compare to zk roll ups we also chat about his projects lazy ledger and fuel labs but before we start in i want to say thank you to this week's sponsor leased authority lease authority is a security consulting company known for

their dedication to pushing the limits on how to build privacy respecting solutions they are a team of security researchers open source developers privacy advocates and cryptographers specializing security audits design specification reviews and security by design they are well known as an auditing firm they've worked with organizations like the ethereum foundation tesla's foundation or protocol labs as well as their work on zero-knowledge proofs they've implemented the knowledge access passes or zcaps with the distributed storage system tahoe laughs if you are skilled in the area of zero knowledge protocols as well as other advanced cryptography both for scalability and privacy enhancing tech then you should get in touch with them

they're currently expanding their team so email them at jobs leased authority dot com i've also added the link in the show notes so thank you again leased authority now here is our conversation with john adler [Music] so this week i want to welcome john adler who's the co-founder of lazy ledger and fuel labs to the show he's an applied researcher and protocol designer and also a fellow canadian so welcome john thank you for having me welcome welcome and john you've been actually recommended you know people have sort of mentioned your name to me a couple times uh to have you on the show and so i i mean i think one of the ways we can start this

is actually to understand what are you actually working on right now i usually we usually do the background first but i want to hear more about what you're up to right now right so there's kind of two things that i am working on the one being laser ledger and the other being fuel labs so lazy ledger is a new layer one blockchain that is specifically optimized for just data availability and ordering and it doesn't do execution and this is a brand new completely different paradigm to all other blockchains that currently exist and that are proposed and this allows it to be more scalable while good security and decentralization

guarantees the other thing i'm working on is fuel labs which is building an optimistic roll-up called fuel on top of ethereum and it's optimized for performance rather than short-term ease of use so it uses things like the utxo data model and parallelizable verification so that you can get much higher transaction throughput on the same hardware what were you doing before this that would have led to this like how did you discover that these were the problems that you wanted to tackle so funny story is that i initially got into the blockchain space through pushes from my old grad school advisor i was in grad school at uft doing formal

verification research and he kind of got really into this whole bitcoin and ethereum stuff one picture he really likes to show his students is him in front of mount gox in japan you know the day that it happened and there's a guy with a you know sign give us give us a bitcoin or whatever and then he's he's right there uh so that's kind of a picture he likes to show so that's kind of where i got my first taste of crypto then i joined consensus i think two years ago around okay to do layer two scalability research so this is plasma channels and stuff and while doing that research just like a month after i joined mustafa al-bassam had published his paper co-authored with vitalik buterin on fraud and data availability proofs

and that kind of set the entire direction of the research that i was doing you know it showed that data availability was a big problem that fraud proofs were real and this led into the direction of optimistic roll-ups in the aside eventually who was your you sort of mentioned this professor but who was that who who was it uh andreas vanerus okay i don't know if i've if i know him but i was just wondering cause you didn't say his name you just had sort of set up a professor he doesn't do too much novel blockchain consensus protocols research uh his group right now is more involved in like oracle research and cryptoeconomic stuff as opposed to you know the consensus protocol stuff that a lot of professors

publish got it so one of the main things that we're here to talk about today is optimistic roll-ups and this is part of what you do with fuel and i can see how lazy ledger also sort of fits into that story but before we dig into anything super specific i think we should talk about what optimistic roll-ups even are we've mentioned that term on the podcast before but we never really had a good explanation of it so if we just start high level what what is the 30 000 foot view of uh of optimistic roll-ups so the very like a one line or one sentence description of optimistic roll-ups is that it's like zk rollups which i'm sure

most of your listeners are familiar with given the name of this podcast it's like dk roll-ups but instead of using validity proofs or zero knowledge proofs you use fraud proofs that's the one sentence description and of course this over simplifies things and it kind of it's the grossly oversimplified version that is missing critical details that without those details it doesn't work i got it i think we've mentioned fraud proofs before but can we actually define what that is like what in this context is a fraud proof sure so a fraud proof is a proof that something is invalid so a validity proof is a proof that something is valid and a fraud proof is

a proof that something is invalid so the way a fraud proof works is you get a claim and then you wait some time a period until you see a fraud proof and if you don't see a fraud proof within that timeout then you assume it's valid and the fraud proof is that created automatically or is that created by like some agent that's watching someone watching needs to create the fraud proof and so i guess this is why they're called optimistic in that i i think of optimistic in the sense of optimistic updates on like when you used to build websites and there weren't good frameworks for this and you sent off an ajax request and then

you could either update the ui as soon as you sent the ajax request or you could wait for the server response to come back and say yes this was successful you can now update the ui and the optimistic update is you just update it right away assuming the server will you know succeed in its request and so i guess it's the same thing here where you're you execute a transaction and then you just assume that it's going to succeed that's the optimistic part but the server quote unquote which is like the verifiers they might come back with a fraud proof saying no actually this didn't work out and then you have to roll back your assumption or your what you thought was going to happen in

many ways yes that's a good description doesn't it sort of and i know that these have been lumped together i know there are distinctions but like plasma wasn't it sort of working under this principle of like at first declaring it correct and then having some game theory potentially rebut that is this similar yeah so plasma and channels both use fraud proofs i see but optimistic roll-ups are new i mean they're considered sort of a class of their own why because optimistic roll-ups for riders guarantees a certain cost but guarantees nonetheless that channels and plasma can't provide so i can go over them briefly now which is that channels don't have

open participation and they have certain constraints on liquidity right you need things like inbound liquidity to receive a payment plasma is inherently permissioned and you you can't have arbitrary smart contracts running on plasma the reason being is that plasma doesn't use general purpose fraud proofs it uses specifically an exit game around owned assets so if you don't have a concept of ownership for something for example the union swap contract no one owns it in that case plasma doesn't really work very well with optimistic grow ups it has open participation that plasma has the channels don't

it doesn't have the liquidity liquidity constraints that channels have it's permissionless and it uses general purpose fraud proofs so that you can run any smart contract on it potentially was plasma ever designed with the idea of actually running smart contracts on it as well was that originally the idea yeah the original plasma paper i think it described that you could run smart contracts but the original plasma paper didn't really describe a concrete system it was more of a very very high level abstract idea the kind of concrete instantiations of plasma were plasma mvp minimal viable plasma which was only around payment utxos just accounts account balances basically

and then plasma cash which was also based around payments and maybe potentially some predicate scripts around that but none of these were designed around you know the potential of general purpose smart contracts i'm curious to dig into how you achieve these two properties so you mentioned open participation and not needing the liquidity and so to maybe recap for the audience like if you open a channel you sort of say on chain each participant perhaps says i'm going to lock up 10 eth they both lock up 10 eth and then they can both like go plus minus 10 each each in in their off chain transactions and they can send a million transactions off chain

but they have to move within these limits that they've set in the in the beginning and then when they say okay all my transactions are done they settle back on chain and then the actual ending balance is moved and like properly settled so how do you move off chain without actually doing this lock up process and having this you know i have to lock up x with this person in a channel and like this this participation stuff it seems like this on-chain lock-up thing is sort of inherent to how you take things off chain so how do you actually achieve those properties without doing that there's a really easy way and you use what's called a blockchain

you may have heard of this technique uh you know blockchains allows i mean i'm saying i'm saying this partly as a joke but partly because this is actually what you do you know the point of a blockchain is you can order transactions and you prevent double spends blockchains allow open participation and they allow participation that doesn't require capital lock up so we can briefly go over plasma cache in this context and it might make more sense of why you can't do things like uni swap with channels so the way i kind of think about plasma cache and not many people really think about it this way which is curious but you can think of it like a bunch of channels with a particular allowable update so you know channels proceed by

unanimous agreement is how all the channels participant needs to sign off on a new state so imagine you had some channel construction where one of the allowable updates was one of the channel participants could completely give up ownership to a different user that's not even part of the channel you know like you have alice and bob and then alice and bob sign an update that now it's charlie and bob that are in the channel now this doesn't work in reality because alice and bob could also sign a channel update and give it to dave that say now dave and bob are the channel owners so essentially you can kind of double spend this transfer of ownership and the way to prevent double spends is well you just

use a blockchain the off chain has to be a blockchain is that what you mean okay yes yeah so the what happens off chain has to be a blockchain and plasma cache is that it's a blockchain that orders this transfer of channel ownership in these the the plasma cash coins so so in the senses plasma cache is kind of like a you know a bunch of channels and then you just change the ownership surround which wouldn't work with channels usually but if you put these channel ownership transfers into a blockchain which is what the plasma cache chain is then it works so from this we can kind of see why you couldn't really build a uni swap without a blockchain using only channels is because you know you have a union swap this is some shared state if alice and bob are

trading on a uni swap inside a channel and then there's you know they bring in charlie and they say hey charlie here's our latest uni swap well charlie doesn't know that's the latest channel state or it doesn't know that they've also brought in dave uh so you need a blockchain somewhere i think we've covered at least two maybe three zk roll up constructions and in those i don't know if it's all of them but at least two that i can think of uh zk sync and hermes they have some sort of like validator even if it's not the traditional validator that we think of they're kind of these agents that are making sure that whatever's happening in there is somehow correct and and they are like the consensus builder within this other

blockchain yes so i do know that that mostly exists in zk roll ups but actually john are you familiar with zk roll ups that don't have any sort of validator type role i think dk roll ups use provers as opposed to validators in the kind of proof of stake in sense that's fair to say i mean i'm i'm using the word validator here as like just some block producer some checking body that could either be a committee would be validating the the transactions by you know submitting a proof that they're correct yeah yeah the validator for most secure roll-ups would be the

smart contract on ethereum it would actually verify the proof that's true yeah when you talk about a validator on a proof-of-stake system it's it's the same kind of thing right where the validator isn't actually guaranteed to produce something valid that's why you have all these other economic systems in place just like the prover isn't actually you know guaranteed to provide a correct proof and so the it's the smart contract that verifies the proof but in a proof-of-stake sense maybe the the prover is more like a validator i don't know huh confusing terminology yeah okay so but let's go back to your story so like plasma cache it did have then like some sort of group of provers

yeah plasma cache and roll ups would have block producers for the blockchain okay for the seven because they are blockchains yeah yeah so so they do need some block producers and plasma and plasma plasma mvp and plasma cache are both inherently permissioned because of the data availability problem which we can talk later later on in this podcast but roll ups are permissionless which is a very great distinction what implication does that have because in as far as i know the permissioned aspect of plasma and this was you know widely debated once they were you know starting to get popular like oh we can't have this because it's permission and then

other people saying well we can't have it because the only thing you can do is censor people and if you find yourself being censored you can always exit back to the chain and you have this whole sequence of events to prevent any malicious behavior so is it really a problem that they're permissioned or or is it just that it's needlessly cumbersome to have that permission so before we talk about permission and there's a very good question actually we should kind of go over some definitions and then the not too distant future will will probably want to define scalability and scaling as as we contrast you know dk roll-ups and optimistic roll-ups but for now to answer your question is that we should define permissionless and trustless so permissionless is just you know you

don't have to ask for permission so if you have a single operator in a plasma it would be permissioned now roll up if you if anyone could make a state transition on the roll-up this could take the form of you know anyone could be a blog producer or anyone can force some state transition then you know it's it's permissionless and the other facet is trustless trustless i actually wrote a paper on this while i was at consensus a while back to kind of try and formally model the word trustless and i came up with two facets so one is state liveness and the other one is state safety where state liveness is basically you consume your state in finite time and state safety is no one can

consume your state without your authorization so in plain english state liveness is basically you can move your coins your coins can't be frozen and state safety is no one can steal your coins okay and we see that if a system has both state lived us and state safety that it's trustless right as long as you can continue moving your coins and as long as no one can steal their coins then you don't have to trust whoever's operating that system uh and i really wish other other projects and other analyses kind of use this framework because people throw around words allowed to find it unfortunately much too much so to go back to your question is that plasma is permission but it can still be trustless i see right is that you can you can always exit your coins from the plasma

even if the plasma operator censures you now why is that a problem well it's a good thing mind you it's better than having it being trusted like a side chain you have to trust a regular side chain you have to trust that the majority of the block producers on the side chain are honest otherwise your funds can get stolen and plasma you don't have to trust them uh you don't have to trust the plasma operators so it's better than a sidechain but the problem with it being permissioned is that the operator can force people to go back to the main chain and going back to the main chain means potentially it's very costly right as we see on ethereum today with gas prices at a thousand gigaway not too long ago this means that many people if they're forced to go back to

the main chain they just can't afford it and the main chain can't actually take on that capacity right imagine if you have a plasma you know apparently these are supposed to scale to a million transactions per second or some other ridiculous number like that you know you have a bunch of people there you can't really exit them onto the main chain anytime soon so being forced out of the plasma chain is not a good thing yeah you need to put in practical terms it could mean like you have to pay 50 bucks even if you manage to get in exactly and so it's just impractical for anyone to actually try to do that yeah and to kind of give some context in this just to give some numbers for some

intuitions is that you know the paper that introduced the lighting network i think it suggested block sizes around 300 megabytes for bitcoin to be able to handle even a small amount of global users opening and closing channels you know opening and closing channels again you know plasma you can think of plasma cache especially again you can think of it like channels so imagine you know the operator kicks you out of the plasma cache you know have to essentially close all your channels you know other side of bitcoin that would take 300 megabyte blocks to process this uh so as you can see you know bitcoin's limited capacity definitely wouldn't be able to handle you know having an off chain system that suddenly stopped working and having all users have to exit back to the main chain

and you know similarly ethereum would be way too overcrowded right so how do you achieve the permissionless aspect in optimistic roll-ups without having that that this in plasma comes from you have sort of a centralized unit that is the block producer of the quote-unquote plasma blockchain and you know i i think i've seen proposals where you can have multiple operators but it still at best just alleviates the problem slightly still have the same core problem so how do you actually get by without that role in optimistic roll-ups you get by by having data availability and basically all blockchain problems boil down to data availability which

will be a recurring theme in this in the skull uh but in plasma pretend you have two operators right you know alice and bob alice starts and then she creates a plasma block but she doesn't tell bob what's in the plasma block right she tells individual users here are your transactions and the plasma block is valid right uh so there's no reason for anyone to exit because the plasma block is valid there's not a single fraudulent transaction in there but bob doesn't know what's in the plasma block so bob can't make new plasma blocks right so now alice is the only block producer all problems in blockchain boil down to data availability so in a rollup and this is both zk roll up and optimistic roll up all the block data is posted on chain so

this means that anyone can produce a new block they have all the data there the only thing you need is a system to select a leader and you can do this any way you want you could have something like you know first come first serve anyone just produces a block the first person who does it is implicitly the leader it wouldn't be too efficient but it works like it gives you it gives you all the guarantees that you could want you could have something like everyone puts up some bond and then you do some round robin or you do some randomized shuffling with randow you could add vdfs in there so that the randomized shuffling isn't predictable and you can do this all in a smart contract in ethereum so selecting a leader is easy in a blockchain it's basically

just take some group of people and you put them in some order so it's very straightforward and data being available means anyone can be a leader anyone can be a block producer in the roll-up if they want to but then the the trade-off and the the downside of this is you have to put all transactions on chain how do you work around you know how do you compress that or do you do you try to work around it in any way or do you just say you know throw your hands up and accept that the blockchain size will grow indefinitely so there's kind of two two caveats here the first is that we don't necessarily have to use the same transaction model as the base chain yeah we can use a

slightly different transaction model you could basically whatever you want right because you're just putting binary blobs in call data yes but the binary blobs still have to represent state transitions yeah so you can't just do anything you still still need to have sufficient information there so that someone can reconstruct the state of the system and then produce a new block so you can't just do anything you want but that being said you can use a different transaction format for example the initial prototypes for zk roll up use much more compressed transaction just for simple transfers alice to bob with accounts where you know instead of using addresses you just use some index people register for an account and then you just use an

index and this is different than like a blockchain for example where you you know you need a 20 byte address to show that analysis and you can do this in the layer two you can do this in the rollout because we have the fund like an underlying layer one that allows us to send transactions from 20 byte addresses to register you know a four byte index so it'd be difficult to do this on layer one but we can do this on layer two by leveraging layer one so you can do tricks like that uh instead of having you know a 32 byte value you could have a four byte value or even an eight byte value there's not really any reason that you would ever want a 32 byte value like for ether or you know some token or something there's really no reason why

you would need such a so many bytes to represent a value so you can have you know reduced representation of this value and and so on so this allows you to represent state transitions that are different than ethereums using potentially much smaller transactions so that's one potential gain the other potential gain is that you can experiment with different ways of aggregating signatures so in ethereum each transaction needs to have a signature in the zika roll-up the signatures are implicitly in the zk proof in optimistic grow-ups you do need to include signature data but you can do things like bls aggregate signatures today that reduce the cost to something like one maybe two bytes per transaction which is probably even cheaper than a

zk roll ups verifying the zk proof does that answer your question yes you kind of use a bunch of different tricks that you would use if you were to build a token only like a domain specific blockchain that was only for token transfers if you were to like build that from scratch today you would use a lot of these optimizations but instead of building a new blockchain you're doing this as a layer two solution and and sort of embedding that the block data in this format yeah yeah within the existing blockchain yeah so to to go to loop back to your question you're not inherently increasing the size of the history because you can fit more stuff into the same

amount of space that being said even if you do increase the size of the history disproportionately it's not really a problem because history is right once never read as opposed to state which is you know you need random reads into the state just depend only history is very cheap you can even do that on a hard disk and hard disks are you know the diamond doesn't they they cause nothing and the second thing is that storage or history rather is prunable so you don't have to keep all the history around forever on every full node once you have the current state of the system you can just discard the history you can't discard the state of the system because you need the state of the system

to you know produce and verify new blocks so in that sense moving stuff from the state of layer one into the history of layer one means that it becomes more sustainable and cheaper yeah i mean it it becomes harder to sync but really only for the people that will want to try to sink the optimistic roll-up and continue producing blocks have you thought about syncing strategies for them because like in on the base chain we have a bunch of different proposals from you know warp sync to whatever else like there's a bunch of new ones if they ever get implemented that essentially simplified terms try to break up the state into a torrent tree

like a uh a chunk tree that you then just sink those chunks and for the optimistic roll up like block producer that person still needs to go through all of history to create you know their internal states to be able to then produce the next block yeah that actually segues us very nicely into a topic i wanted to discuss which was comparing and contrasting zk and optimistic roll-ups the guarantees they provide and the scalability they provide and it's exactly because of sync strategies and whatnot so if you don't mind then we should cover that topic yeah okay great first before we you know talk about which one is more

scalable or less scalable or the same scalable or anything in between we kind of have to define what scalable is our scalability again we should start by definitions first because otherwise we don't know what we're talking about so james press wrote a thread about this which was prompted by some comments i had made that zka roll ups aren't actually more scalable than optimistic roll-ups contrary to popular belief which we'll cover very shortly why that is and hopefully this doesn't make a lot of your viewers very sad but that's that's the spoiler alert so if you don't like this and skip to the last the last quarter of the podcast uh so you know throughput versus scalability and james press switch wrote

a twitter thread on this so throughput is just transactions per second you have a certain number of transactions and you have a certain period of time and then you know you just divide the two is the ratio and then transactions isn't really the best way of ordering it it should really be worded as some sort of unit of work per time uh because you know just transactions doesn't really tell you anything because the transaction could be very small it could just be a simple transfer or it could be very large it could be doing you know going through 10 d5 protocols to do some flash loans and some of minting of gas tokens then some burning of gas tokens and anything in between so you know just transactions doesn't really tell you anything in the sense of ethereum it should be you know gas per

second in the case of bitcoin it could be like v bytes per second something like that right but you know we can say tps just as shorthand but you know it should be known that it's not just transactions it's some unit of work yeah how to measure that unit of work is actually very tricky so we'll leave that as an exercise for the reader so it's just that's throughput but that's not scalability and unfortunately a lot of projects have described that the scalability and have said our blockchain is scalable because it can do 10 000 transactions per second but again that's not scalability so what's scalability scalability is transaction throughput divided by the cost to run a full node and there's a star next to this fully validating node which we'll cover

shortly because it's not just full validation so what this means is you can increase the throughput of a system by increasing the cost to run a node in other words you know make require more powerful hardware and this will allow this will increase the throughput but it'll keep scalability the same and by cost here do you mean cost like energy cost actually like dollars dollars okay like it cost me a certain amount of money to buy a full node to buy the hardware or to rent it got it right yeah so as an example that takes us to the extreme i'll use selena you know so lana requires you to have a really really powerful computer potentially that gets more powerful every year you know multiple gpus and all that stuff running in parallel

you know a 64 car cpu you know a bunch of bunch of ram and all that stuff uh and sure it achieves potentially high throughput numbers but that's not scalability because the cost to run a node is very high right so it's not any more scalable than ethereum now they have made some optimizations which they should be respected for uh in terms of things like parallel transaction processing which allow you to make use of currently unused resources that you know currently ethereum does not use but that are there just hitting idle so those optimizations are good and they should be respected for them but you know you know requiring a ten thousand dollar computer that's not scalability right that's increased throughput yeah just as you said as well that uh you could do a lot of these

optimizations on ethereum too right like reducing the transaction bit size etc like yeah they're good optimizations and those are the ones that you would make if you built a new blockchain but you can have them anyway like they have access lists for example you can add access lists on ethereum there's nothing inherently stopping you it just hasn't happened yet and adding them will allow some measure of transaction parallelization so now we'll go to the star in the full node which is that you know full node ensures that the blockchain is valid it makes sure you know it fully downloads and validates every single block and then make sure it's all valid the start here is that it also allows you to do something that a light node doesn't really allow you to do it allows you to produce a new block and

you know the original thing is that you had mining nodes and then you had sbv nodes like that's kind of like this satoshi satoshi's vision if you want to call it that that was you know described described in the paper but there's no real concept of a non-mining node it just there was no non-mining node until you know after a while so one of the things a full node allows you to do is produce a new block and this is where things get interesting okay so we'll cover something like let's say it's a sync blockchain i'm pretty sure you guys have heard of things like an of one blockchain or a sync blockchain where you know you just you get a succinct recursive system proof a validity proof that all previous blocks are

valid this doesn't tell you the four choice rule of the of the chain but at least tells you that all the blocks are valid so here's the thing let's say you have a system and you know all your full nodes are just doing that they're just you know verifying this zero knowledge proof do we note that the zero knowledge proof tells us that the chain is valid but it doesn't tell us what the state is right it tells us here you know here's a state route the state route was created through valid transitions with valid signatures and all that but it doesn't tell you what the state is so this node couldn't actually produce a new block is there a way that they are actually writing this somehow separately on chain no it's not on chain it's all distributed it's like a you know the whole stateless

concept is you don't store it on chain you just pass it around off chain and hope for the best yeah so this isn't the zk rob there's you know some hypothetical chain that operated through every block had a recursive zero knowledge proof of its validity uh it's validated in all previous blocks okay what i'm describing is coda or what used to be called coda right so uh you know you have this chain okay so you have your full node you you validate the zero knowledge proof great it's valid but you can't produce a new block so what do you have to do to produce a new block and this is this is a question for you guys you need to download the past data great you have to download the past data and make sure it's available and then what else do you have to do

with it re-execute it yes you have to re-execute it i'm wondering if you've been reading the stuff that we've been writing or if if this was known all along this is no no all along yet okay good yeah so you have to re-execute it right and what this means is that again scalability is you know the throughput divided by the cost to run a full node star where the star is is not a full node that's just validating transactions it's a full node that can produce new blocks uh then we know that the zero knowledge proof doesn't provide any scalability you still have to fully download all previous blocks and you still have to execute every single pass transaction to get to the latest state so that you can produce a new new block so to kind of you know bust some to bust some myths is that you know there's no

such thing as noel on blockchain unfortunately as much as we wish there was in theory you could i mean i'm not sure if they actually attempt to solve it this way but in there you could just pass the current state around and then the zero knowledge proof also proves that this particular state route is the correct one and then with the state in hand like you have to download the state still but you have a proof that this is the correct state route and then you can proceed from there with the transactions that you've been given yeah you could do that but note that that's a stronger assumption than any other blockchain mix right like bitcoin for example and even ethereum they don't assume that you can download the fully full state from any node

they give you the option of reconstructing the state yourself by syncing the chain's history only right and this is a kind of a fundamental assumption of current blockchains right they don't assume that you must be able to fully download the state of the system yeah they only assume that you can you only have access to the history and of course there's reasons for this as i said before is that history is really cheap and state is really expensive and state can potentially be quite large like in ethereum the state is almost as big as the history so you know obviously you can make certain assumptions and you can make certain stronger assumptions than currently exist in blockchains but then that begs the question if you make these assumptions then do you really need the zero knowledge proofs you know one example is

if you make the assumption that there exists someone that is fully validating the system and that has access to the current state why can't you just assume that they'll give you a fraud proof if such a person exists then they should be able to give you a fraud proof at which point you don't need all this complexity of validity proofs because you have this you know mythical person that's validating these tens of thousands of transactions per second that can give you the whole current state they can also construct a fraud proof it's trivial for them to do where they do all that work right so we we see this kind of counter-intuitive result which is that zero knowledge proofs contrary to popular belief don't actually provide any scalability or security advantages over fraud proofs isn't there a proposal for like some joint

zk optimistic roll-up or something where you'd actually make use of the properties of both yes i don't remember the order but i think it was it's used to met the zk proof and then you only verified if it's challenged or something along those lines i don't remember but yeah there's some suggestions around there so to kind of go back to you know this throughput and scalability and zero knowledge boost versus not into this hypothetical blockchain that's supposedly all one but isn't right you do have to be able to fully download all the history and you need to be able to reconstruct the current state and again if you assume that the current state can be given to you by someone in the network that there's someone willing to potentially you know because supposedly you know

using validity proofs means you can have you know a whole bunch of transactions per second uh you know tens of thousands a hundred thousands because there's only one person creating proofs right so if you have this mythical person that has a super computer capable of you know constructing the current state and giving it to you at any time they can just construct fraud proofs and give them to you at any time so there's not really any assumption model under which zero knowledge proofs actually have higher scalability and more security than fraud proofs i mean it's sort of um probabilistic finality versus guaranteed finality and consensus systems like zk is guaranteed finality like once you're given this proof it's correct you know i i assume everything is correct i can proceed from

there in a fraud proof system i have to give it some time how much time is a little bit of like a variable uh that is a very good point so i want to make clear that when i say that zero knowledge proofs aren't more scalable or more secure than fraud proofs that doesn't mean the zero knowledge proofs have no advantages so they do actually advantages and you brought up a very good one which is latency i wouldn't call it to finality but latency to on-chain interactions the reason being is that in an optimistic roll-up you you know you commit to an optimistic role a block and if it's invalid then it can be reverted with a fraud proof within some time out but if it's valid

it can't be reverted so it's guaranteed from the point of view of the on-chain contract to eventually finalize but a user can fully validate the optimistic roll-up off-chain and then see that okay all these blocks are valid they build upon valid blocks then it's immediately final but from the point of view of the unchained contract the unchained contract obviously can't fully validate an optimistic roll-up right otherwise that defeats the whole purpose right then then you might as well just run it in the contract the on-chain contract needs to wait a long period of time and potentially much longer than like a normal peer-to-peer fraud proof because on-chain there might be congestion and stuff so you're correct that zika proofs have a very good advantage that they allow you to have

much lower latency when it comes to on-chain interactions so once you submit a zk raw block then you know it's valid you can immediately withdraw your funds in the case of fungible assets this isn't a very big distinction because the fungible asset can just be withdrawn with the help of a liquidity provider but it is very useful in the case of things like cross-chain interactions and for doing things like withdrawing non-fungible tokens or nfts because you know obviously you can't have a liquidity provider for an nft by definition because it's not functionable so that is one place where zero knowledge proofs are better than fraud proofs which is that you know lower latency for on-chain interactions

they do have higher latency for committing the block for the first time which is you know a disadvantage but that's kind of orthogonal so they have one other advantage and you know i did bust potentially a lot of people's hopes when i when i say that you know zero knowledge proofs don't provide scalability or security or better scalability or security but there's another thing which which they're potentially good at one thing that i kind of glossed over is that when you reconstruct the state of the system so that you can produce a new block you don't actually have to fully execute every single transaction you only have to apply every state transition so imagine you have like a union swap contract maybe this isn't the best example but

you know some trade some trading system right it might have to look up a bunch of prices internally but the end result is you know there's just a movement of tokens from one person to another or from two people between each other you know in the scenario where you want to reconstruct the state of the system of a system that's you know has zero knowledge proofs so in in such a chain to get the the state of the chain you don't actually have to execute every transaction you only need to apply every state transition now if the blockchain only does state transitions like if it only does simple balance transfers then we can see that you know state transition is that's if that's all the work you're doing if all you're doing is just transferring balances

and then clearly using validity proofs doesn't have any advantage over not using validity proofs because all the work is in the state transition but if your system is very complex and allows for complex smart contracts that potentially read a lot of state elements right like it goes in there and reads 100 state elements then does one simple state transition then that is an area where zero knowledge proofs are useful which kind of brings us back to why they're originally created it's to provide a succinct proof of some computation so using it in the sense of you know scalability that has been you know bastardized in the modern zika rollups and

and all this other and like the all of one blockchains and stuff is incorrect but if you use it the way it was originally intended where you provide a succinct proof of some computation happening and that computation could be very large then that is where using validity proofs for scalability as an advantage because that's what they were built for right you can have you know very very large transactions imagine a transaction that consumes a billion gas but only has one small state transition just moves a balance that's all it's doing then of course using validity proofs does provide you scalability unfortunately such a system doesn't really exist nowadays because having you know large general purpose computations inside some zk roll up is just not something that exists today

at least not in an open source publicly reviewable way it may it may in the future there's some advancements being done here there's i think zinc on the zk singh side there's uh cairo from the star wars guys so maybe we'll see some interesting things happening on that front but you know for now at least it doesn't really seem like those exist i want to take a a step back because i i think we've dove into describing i think everything and how this works but i want to take it take a step back and sort of ask the question of where fundamentally does the added scalability come from quote-unquote and its scalability because it seems to me that if we just take plane ethereum it is not

scalable because it is acting on a global state with a bunch of different miners and full nodes across the board have to re-execute all these transactions all the time and it you know causes a bunch of problems but what you do in an optimistic roll-up and to some degree in a ck roll-up up in general is you are kind of creating a secondary system in which you have fewer block producers that can run faster because you've optimized the underlying data structures in how you act on this roll-up but you still fundamentally you know put the transactions on chain you still fundamentally

have to build that state in the roll-up block producers and so aren't you just like sort of creating a secondary blockchain within the call data of the first and the scalability is sort of you're reducing the set of people who are computing that's almost exactly correct except for the number of nodes but everything else that you said is entirely correct that there seems to be something fishy here but the system i described you know the reason that zk roll ups is not more scalable or secure than none optimistic grow up so you know the validity proofs versus fraud proofs is that you still need to fully in the worst case not in every case but in the worst case and unfortunately we have to metric our systems based on the worst

case because blockchains are adversarial environments in the worst case you still need a user to potentially run a full node to reconstruct the state and yeah essentially do full validation if you want to call it that so if you have that system and you know you just put all your transactions in a roll up it doesn't seem like you're getting any scalability and why would you you just have bigger blocks essentially or you have the same size blocks and you have no scalability and the answer is you're correct which is a very bizarre result from you know someone working in the raw space would tell you but you're entirely correct that roll-ups don't provide scalability on their own if you have an evm and you put it inside an optimistic roll-up so you have a you know evm native optimistic roll-up or you know potentially in some hypothetical

scenario zk roll up then that roll-up would still be limited to 15 transactions per second unless you want to increase the cost of running a full mode or unless you want to add your stronger trust assumption unless you say well the users aren't going to run full nodes we trust there's some supercomputer out there that can generate fraud proofs right but if you really want to make that assumption why don't you just do that on ethereum right so you know clearly there's no scalability to be gained here so where do we get scalability so there's two ways and james patrick covered this in his thread which everyone should read if you're in blockchain so the key things that rollups give you is there's two things one it allows you to choose

different execution models that potentially are more scalable one example is what we're doing at fuel instead of using the evm with all its problems we're using a utxo based data model which allows for parallel transaction validation and that doesn't have the same state lookup bottlenecks that ethereum has so this means on the same computer you get more transactions you're gonna get more transaction throughput so that's an increase in scalability so essentially you can think of it like segmenting the block space of ethereum where block space isn't just in bytes it's in you know let's say gas right so if half of ethereum blocks used in your ethereum half of them were for fuel it'll be able to process more than the current

transactions per second assuming we don't raise the current gas limit right because we use a different execution model for fuel yeah uh the other way you get scalability potentially is by creating segmented trust boundaries so the example is you know there's two roll-ups and you only use one roll-up you don't care what happens on the other roll-up right so this means that you know your users of one system could you know get access to the full 15 transactions per second users of the other system could get a full 15 transactions per second and you know assuming most users don't use both systems then now you have 30 transactions per second across both of them and this should sound familiar because that is essentially what charting

provides right the roll-ups are very similar in many ways to shards which should hopefully segue into our next question and yeah it's like this is exactly heterogeneous sharding eg what polka dot does he too is supposed to do eventually but it can't yet this is so weird i didn't realize that i didn't think about it that way yeah let's go into these two discussion because these two still doesn't really want to provide heterogeneous charging it still wants to provide homogeneous sharding where you still have the same execution model on all shards so how do you bring this model into heath 2 and make it even better there okay so there was a

recent post by vitella buterin sometime in early october about just this topic which is a roll-up centric view of serenity unfortunately it's commonly called e2 but i disagree with calling it e2 because that assumes the conclusion it's a separate blockchain that has nothing to do with ethereum except there's a few guys there that also worked on ethereum it should really be called serenity this post described the new roadmap for serenity that was more rollup focused so rather than having sharded execution as they're originally planning for a phase two they say okay let's drop this let's just have sharded data availability which mind you have some problems that we can discuss shortly let's just have sharded data availability

and allow rollups to use this available and order data to just run and the roll-ups can run on for example eth1 or ethereum so we kind of see that roll-ups do as we just discussed do provide some of the same property of the starting right you can run as many rollups as you want the rollups can have different execution models the only constraint is that the execution model must either be expressible in some zero-knowledge proof way or you must be able to construct a fraud proof that can be interpreted in some way in the evm if if not then you know you can't you can really construct a fraud proof so so those are kind of the constraints

and they are actually non-trivial constraints not having access to native code and only having access to the evm are non-trivial constraints but you can still do basically you know all of d5 that you could want all payment transfers utxos accounts anything in between you can basically do anything you want so in this way serenity could provide a large amount of data availability throughput and then roll ups could just run on ethereum and essentially act as shards you could have 64 rollups running just as an example and then you know if a user doesn't want to validate every single rollup because they only use one then they just validate one right and then you can have some way of

having some committees around for the 64 roll ups that again are just leader selection and you can do leader selection in some smart contract on ethereum it's not a it's not inherently complicated in what you've described would you have identical zk roll ups like or do we imagine each one of these having this unique property like for example would there be like many zk sinks many fuel many like would there be all of these no i know it's not zkrull but all of these other roll ups would it would be multiples of them would it be singular i think there would have to be i mean these added scalability as described comes from domain specific optimizations basically saying

we know in this context we only deal with balance transfers so we can make the most optimal thing for balance transfers and then you can make another one that's optimized for nfts or whatever right and so i think that that's where the scalability comes from so you'd have to have domain-specific roll-ups yeah so you have domain-specific roll-ups and you have multiple of them multiple of each one yeah because that's that's the question is is it sort of like do you have to multiply it in the example that you had given you did say that there would be like two roll-ups basically running at the same time so which do the same thing so do we imagine it that way the current imagining of you know the researchers in the space is that there should be multiple roll-ups running now if you're asking multiple roll-ups

of the same kind like let's say multiple fuels or multiple zk syncs yeah or multiple term basis then the answer is is maybe uh there's no reason there's no inherent reason not to especially if they're constrained like let's say you have you know zk sync which it does just as payments right let's say for now in that case having two of them doesn't really affect anything because you don't really need like atomic composability across payments right so you can just have two of them and you don't really lose anything but it eventually provides you with conditional scalability depending on if users use one or both you kind of need composability and payments like in the trade and hotel problem where you want to pay for two things but

conditionally that both succeed yeah if they both interact with smart contracts then yes but i'm saying if it's just like a payment for something that's off chain then it's not really too important for things like trades or for you know more composable interactions then yes of course you would want to put them in the same execution system but if it's just like a payment for something that's off chain then it doesn't really matter where it is just as long as they accept it so we're back to the same sharding methods where you would have problems perhaps interacting with people on the other roll up like if i want to if alice and bob are on two different roll-ups and they want to send money to each other then either alice or bob has to create an account on the other roll-up and can't send directly to between them

which might or might not be a problem like depends on how you shard this and how users interact in reality yeah obviously there needs to be a lot of application development that happens for across roll-up interactions just like there would be for cross-shard interactions just like there would be for cross-chain interactions so yes there needs to be a lot of work done there but it's not impossible and some interesting stuff that's happening at the forefront of this is uh barry whitehat is also kind of pushing this is doing things like public key registries if you want to call it that or you know account registries so that you know all roll ups or all roll ups that conform to some standard can share a common registry of accounts at that point you know account registrations are shared across multiple

of these rollups which means that you know alice can send to bob bob doesn't really need to create an account on the second rollup he just needs to have an account registered on any robot stuff like this but yeah there does need to be a lot of work done fascinating just imagining that starts to get really wild the cross roll up interaction let's talk a little bit about the data availability because i mean i'm also just a quick question before we dig in you already teased there are some problems with charted data availability but even before then i mean there is this proposal on the table i think it's been accepted i i don't really follow the details anymore but to reduce the cost of call data so how much

does the cost of call data actually affect roll-up schemes right now it's actually quite significant because it's 16 gas per byte and if you kind of do the math it ends up being that in a lot of cases is it's cheaper to store something in state and then just doing an s load later than it is to provide you know the pre-image to some hash in call data it's actually a very significant blocker right so that's why that proposal's in i i assume it's going to be accepted and but it's practice at some points so i actually wrote a proposal to decrease the cost of call data then i think there might be some other soft proposals floating around i want to be optimistic and imagine that

it'll be included at some point but the realistic me says that there is opposition from certain ethereum developers such as you know peter from geth that really don't want chain history to grow despite the fact that as i said above you can do things like pruning and whatnot and chain history is actually really cheap so i don't actually think the cost of call data is going to be decreased anytime soon on ethereum unfortunately and part of this is because ethereum doesn't really have any good scheme for doing anything better than just full replication of the data if they had some way of doing you know error correction or error recovery

then potentially you could do better because you wouldn't need full replication of all the history you could you know do partial replication which leads us to our next topic this is flowing so well so i guess next up is what we've teased this data availability yeah let's go into this you've sort of explained the issue of it or the lack of it in certain cases what are you doing about that so this is kind of the singular problem of all blockchain such as data availability and ordering if we have those two then we have everything uh so you know let's kind of do a deeper dive into the problems that it causes so in the form of channels for instance you don't have a globally available ordering

on channel updates so you can't do things like what i described you know alice sends to bob you know alice and bob have a channel and then al signs the channel over to charlie and then you know says i'm no longer part of the channel you can't do that without a global ordering another thing that you know data availability the problems that it causes is things like plasma being permissioned someone can create a plasma block and just not provide the data behind it it could all be valid and they just don't provide it to any one party then no one can create a new plasma block it becomes permissioned another thing is in the case of say ssync blockchain uh you know you have or zika rollup even right in a zika rollup you still need to provide all the transaction data and the reason you need to do this is if

you didn't have this someone could move the state over in this case you know the state the new state is valid because there's a validity proof for it but no one can produce a new block and not only can no one produce a new block which you know maybe you say that's like a philosophical problem right but the issue is no one even knows what their coins are if no one knows what their coins are they can't spend them so effectively by moving to an unknown state that is valid but unknown everyone's coins are burned right so it creates all these problems and the solution the naive solution is well you just download everything right which is obviously a terrible solution because downloading everything means especially if everything is in history

it means that you're doing a whole bunch of work so can we do better and the answer is yes we can which which brings us into to how lazy ledger is doing things and now serenity is doing this potentially charted data availability so kind of a brief two-minute description of the the solution to the data availability problem which is well let's take this data that's erasure coded for those of you who are not familiar with the razor coding it's a way of doing error correction so you have some data and then in the simplest sense is you grow the data to twice as big so if you have say one megabyte of data now you have two megabytes of data plus parity data

like original data plus parity data two megabytes and as long as you can recover one megabyte any one megabyte of this two megabytes then you can recover the original data and by extension you can recompute the parity data all right there's like some more nuances in there and some parameters you can change but that's kind of in the simplest in the simplest sense so if we have such a scheme what you can do is while you just random sample into this parity plus original data every time you do a random sample into there there's a 50 percent chance in this like naive construction just to get some intuitions there's a 50 chance you land on some data that is there that is

available but the block producer like this malicious block producer might be trying to hide more than half of it so that the original data is like completely hidden so very high level intuitions is every time you do a random sample there's a 50 chance you get tricked that's the intuition so if you do multiple samples the chance that your trick decreases exponentially it's 50 then you do another sample now it's 25 and so on if you've been able to sample and it has not shown problems then the likelihood is lower yes then the likelihood that you have been tricked decreases exponentially with the number of samples and you know the exponential decrease is important i understand uh so doing this scheme requires committing to the erasure coded

version of the data and using the 2d scheme the the one i just described here is the 1d but you know just to build some intuitions but the the 2d scheme requires a commitment to square root of the block size amount of data because you need a square number of rows and a square of number of columns because it's two dimensional so in total you need twice the square root of the block size amount of data so there's some overhead here but what this means is once you've done this erasure coding scheme a node can be convinced and the light node can be convinced that the block data is available by doing a fixed number of samples into it because again the every time you do one of these you have a 50

chance of being tricked and that decreases exponentially so the block could be one gigabyte it could be one terabyte it could be one petabyte you only have to do a fixed number of samples the only overhead is square root uh square root of the block size that must be committed to for each block so what this means is we have a way of nodes convincing themselves that data is available by doing sub-linear work they only need to download the square root number of commitments and then they have to do a fixed number of samples so they don't actually have to fully download the block to convince themselves with very very high guarantees a very high likelihood that the block is in fact available okay

which is which is revolutionary it means that you no longer have to fully download blocks you can actually do sublinear work which means blocks can now be made no they can be square they can be squared as much large and is this what lazy ledger does you sort of described it before as like it's an l1 in itself yes so i can cover both lazy ledger and the serenity proposal in this context so lazyledger basically does this and it only does this the only thing it does is it takes data blobs just zeros and ones it doesn't execute them it doesn't interpret them it just puts them in a block erasure codes the block and then pass it around so the only thing you need to do

to ensure a block is valid is actually to ensure it's available because again there's no execution but is it taking when you describe this like it's not taking this information from another blockchain it's in itself doing this yes it's in itself a blockchain but the nice thing is any blockchain can make use of this service for instance you could take you know bitcoin blocks take that one megabyte and just put it on lazy letter as a blob lazy ledger doesn't interpret it as a bitcoin block but it means that some application running on top of lazy ledger say like a bitcoin virtual sidechain full node could read out all these bitcoin blocks from lazyledger and essentially reconstruct the bitcoin blockchain without having to fully download every bitcoin block

interesting yeah so it allows you to have data availability with sublinear cost which means that you can have a large amount of it right the sublinear cost means that you can have a huge amount of it execution always has to be linear right or at least not execution because as we said you can do some tricks with zero knowledge proofs but at least the number of state transitions needs to be linear you can't avoid not executing something but data availability you don't have to fully download something to ensure it's available you only have to do square to it work i'm trying to imagine like how would how would an application interact with it exactly okay so with lazy ledger we have a special optimization called the namespace markel tree

and this is not something that serenity has but contrasts the two systems is that every piece of data in the lazy ledger block is associated with some namespace some application namespace uh and then you know each application essentially just describes its own namespace so like you could have bitcoin for instance it calls itself you know some some virtual bitcoin let's pretend and you know call this off oh i'm namespace 12. right so it goes through and it downloads only the pieces of the lazy ledger block that have namespace 12.

and you can provide efficient merkle proofs into and you know to show that just these pieces of the laser ledger block are are for you know namespace 12. so you don't have to fully download every single lazy ledger block to extract the application messages do you imagine this functioning though in an l2 context as well yeah so it can help with l2s as well you can build things like rollups and optimistic rollups and dk rollups and you know side chains if you even want to and use lazyledger as a shared data availability layer to provide you know shared data availability for all these systems for instance cosmos zones instead of having each cosmos zone you know have to have a very

strong validator set to prevent corruption you just put all the blocks for the zones on lazy ledger and if they're not there then you know they're invalid and if they're there then if something is invalid you can construct a fraud proof or a zk proof so you it'll lazy ledger can be used by any and all other blockchains as the shared data availability there and since it only does data availability it can provide much higher throughput of just data than any other system in the world contrasting with serenity and you know the new roadmap uh the top builder and i think he posted a picture very very recently or he also gave a short talk at the eth online or eath global summit which was uh like a graph and it's showing you know if you just do

sharded data availability or just data availability in general you can get like you know the throughput of 25 000 transactions per second but if you do sharded execution the throughput decreases to like 1 000 transactions per second so that shows that if you just do data availability and you don't do any execution you can have much higher throughput off the critical thing that you need and the critical thing that you need is data availability and ordering once the data is available once it's ordering you can build any application you want on top of that you just read out the data from the right namespaces i find this uh fascinating because i mean i have my own internal worldview and everything but to me you're you're

literally just describing polkadot where namespaces are another name for parachains and like it's what's the exact same construction this it feels that's a relay chain and so it's sort of uh coming to the same thing from two completely different angles kind of thing yeah i mean ultimately all these charted blockchains try to solve data availability in some way or another right while also providing things like guarantees around execution but ultimately what they really want to try to do is to increase the data availability throughput uh so the answer you know are are there similarities the answer is yes of course there's similarities between

you know lazy ledger and all charted blockchains yeah also beacon chained is that what i don't know if that's still there but like was the beacon chain also supposed to act a bit like this lazy ledger construction not exactly so the beacon chain is responsible only for shuffling the validator set it doesn't really do much with the shards that being said one issue with the serenity design of sharded data availability is higher overheads and more brittleness in the consensus mechanism but specifically the higher overheads is the current surrounding design is basically one big block you segment it into 64 smaller blocks and then each of these smaller blocks you do the erasure coding like i described

to get you know the square root number of commitments and so on and you do some sampling but the trick is as i described earlier the overhead for each block is square root in the block size and the number of samples you need to do is constant right but it's per you have to do a number of samples per erasure coded data so if you take one big block and segment it into 64 smaller blocks you're now increasing your overhead 64 times and you're not really gaining anything like ultimately you still need to do data availability tracking and every single node needs to check the availability of every shard in this example all the data in across all the blocks needs to be checked for availability so in that

sense there's not really an advantage of splitting up one big block into 64 smaller blocks you're just increasingly overhead you might as well just have one big block and just do a razor coating over the whole thing interesting i hate to sort of wrap up here because i feel like we could probably continue to chat about these like the comparison between these systems and get into the nuance even deeper but i want to say thank you so much for coming on the show and and sort of taking us on this journey through like fuel's work on optimistic roll-ups it's comparison to zk roll ups like how kind of it's it's turning the eth1 construction into a sort of semi-sharded environment and lazy ledger this is really and data the data availability problem this is really interesting yeah thanks very much no problem thank

you for having me yeah and to our listeners thanks for listening thanks for listening