Wait, It's All Resource Pricing?

Transcript

me um oh yes

so hello everyone good morning uh my name's john and i'm here to talk about blockchain resource pricing as soon as my slides advance okay so a little bit about me my name is john adler i'm the co-founder of celestia labs and we're building celestia a general purpose data availability layer uh and an optimally scalable universal blockchain there's a lot of buzzwords and some of them will be explained over the course of this uh over the over

the course of this talk uh so don't panic too much about about these buzzer words yet uh i'm also the co-founder of fuel labs uh and we're building fuel uh and we're leading the r d and optimistic roll-ups and we're also building the most scalable optimistic roll-up on ethereum uh our fuel v1 optimistic roll-up actually launched on mainnet last year and our upcoming fuel v2 will be very exciting keep your eyes posted or keep your ears posted for announcements on that previously i was at consensus i did layer two scalability research on things like plasma state channels side chains that kind of stuff and while i was there i created the optimistic roll-up design paradigm

and i did various you know e2 work and so on so a bit about celestia because i'm here on behalf of celestia it's a new layer when blockchain essentially what it does is it orders data and makes it available it doesn't actually execute transactions so it doesn't hold things like the state of applications it doesn't execute decentralized exchange things it doesn't have arbitrage opportunities mev and all this stuff it essentially acts like a decentralized time snapping server for zeros and ones and once you have this timestamping server any application can build on top of this ordered data so you can build things

like roll-ups you can build cosmos zones or sidechains with shared security anything that you can or individual applications you can build any any one of these things on top of this shared security order data okay so enough about me and my projects let's talk about the meat of this talk which is blockchain resources first of all we'll talk about the pricing part of it shortly so first of all what's a blockchain this seems like it's going to be like blockchain 101 but it's important that we go over things from first principles so that we're all on the same page so blockchain is essentially a state machine replication process

or let's just say a decentralized blockchain as we use them today is this you know state machine replication process there are obviously other blockchains like git for instance technically a blockchain doesn't do state machine replication but for with the way we think about blockchains like bitcoin and ethereum uh you essentially have a bunch of nodes everywhere in the world you know 100 1000 10 000 nodes and they all independently execute transactions to arrive at the state of some virtual machine so let's kind of like this you have some state at transaction i plus one is equal to some function f on the state at transaction i along with transaction i

uh and what is this f this f this function is a state transition function and that's essentially describing the virtual machine if you if you will off the blockchain so in bitcoin there's this utxo thing in ethereum you have the evm and essentially you start with the current state you apply a transaction and you get the new state and then you do this for the next transaction then the next transaction and so on uh so we agree that if we all agree on an ordering of the transactions and we all agree that you know these are the exact same transactions the exact same zeros and ones in the exact same order assuming f is deterministic we should all arrive at the same state s hence why it's called you know state machine replication because all

the nodes they'll replicate the state across themselves okay uh now this f it does stuff right you do stuff on your computer it moves electrons around on your chips it does work and this work comes in various flavors and what are these resources that can be consumed while doing this work so you could have you can your node could download transaction data which uses up some network bandwidth right in bitcoin blocks are one to four megabytes in size every 10

minutes so you would have to download that much amount of data essentially so that doesn't network bandwidth and ethereum blocks are quite a bit smaller but they come more frequently i think they're around 5 to 10 kilobytes but they might come every 12 to 15 seconds uh give or take depending on you know depending on the proof of work uh so similarly you just have to download that transaction data so that you can execute it so that you can get you know the current state first you need the data before you can execute it in addition to that full nodes will store transaction data so once they've downloaded the transactions once they've executed them they can just store this data they can store the zeros and ones they don't have

to read from them again they just store it on their hard drive it doesn't require fast latency random access reads or anything you can just dump it on a hard drive you can even dump it on a tape if you wanted to it'll still work okay uh now once you have the transactions before you store them i said you have to execute them so executing them takes up some cpu time right if you do an addition that addition in the virtual machine needs to be executed by your cpu when you do gas accounting in your vm it does some subtraction and then it does a comparison all these things are executions or instructions that are executed by your cpu these are resources right it takes electricity it wears and you know there's some wear and tear

on your cpu there's real resources being consumed to perform these operations uh you also have memory read and write uh so let's say you have you know i want to copy a thousand bytes of memory in my vm to another you know from one location to another you probably don't want that to be free right you probably want to scale you want to scale some pricing based on the amount of bytes copied or the amount of data that's been read or written from to memory uh because of course if you allowed someone to copy a thousand bytes for free or you know ten thousand bytes for free uh and it would cost the same as one byte then they could just dos your system essentially so you know memory reading and writing is actually finite resources right memories

has ram has finite capacity uh there's a finite amount of bandwidth and you want to limit this there's also storage reading read and write so this is from the state right generally you don't put state and memory you put in the storage uh we'll cover a bit later why this is especially for ethereum uh and storage you need to do random access reads and writes into storage and this is different than history where it's just like an append only log where you just add more history to your like more transaction data storage and state is usually random access so this one here you can't put a hard drive you basically have to put it on some sort of ssd at either one of those fancy new nvme ssds and not sata

and then especially if you're doing something like a theorem for those full sync and this is of course much more expensive right ssd capacity and bandwidth and latency is much more expensive than something like you know tape the capacity of some tape which is extremely cheap now the important thing to note is that these resources that we've just discussed are actually orthogonal right you could imagine some chain that's doesn't execute transactions which i guess we just talked about in the previous slides but all it does is just order them in that case it wouldn't use much cpu but it would use potentially exactly the same bandwidth to store transactions and to download them as

another blockchain that downloaded exactly the same data but executed transactions so these resources aren't actually necessarily tightly coupled they're orthogonal and this is where things get tricky and this is why we have this talk and blockchain resource pricing okay so in a blockchain system you need to meter these resources that we just discussed and you can use this thing that we can just call a gas uh this which is what it's u which is what we name it in ethereum but really just some sort of weight some sort of waiting scheme and the reason you need to meter resources is to prevent denial of service vectors

you don't want someone to create a block that will take a million years to execute especially not if you're say that in some proof of stake bs bft system or you have you know a validator just vote on a block proof of work is a bit different because you know if a block can't be validated in time it can be our fund but let's say in a proof of stake system you know your block is finalized if it takes a million years to validate you you still have to validate it you can't just ignore it because your own no it was a bit slow so you know you need some way of metering these resources to prevent denial of service factors so that someone can't create some enormous block and importantly once we've metered these resources we have to put a bound on the resource

consumption for each block and this is this notion of decentralization some the cost to run a full node okay so decentralization let's expand on this i say it's the cost to run a full node but what is what is cost right cost can come in many forms obviously you know the dollar cost but we're here we're concerned with the resource cost and the resource cost obviously translates to a dollar cost so you can denominate them all in dollars but really what we're concerned here is this this resource cost because you want to bound the amount of resources someone must spend to run a full node and that's this notion of decentralization it's not the number of nodes on the

network it's a sanji the cost to run a full node so all these resources that we've discussed before network disk capacity cpu memory bandwidth and capacity random access bandwidth and capacity all these orthogonal resources you essentially you these are parameters that you use to determine the cost to run a full node okay so let's start with a simple not simple this is actually going to be fairly complex uh let's start with uh a case study of bitcoin and how bitcoin does resource pricing before we dive into ethereum because with bitcoin bitcoin actually has some very interesting history around resource pricing

and how some parts of the community don't discuss as much the ethereum community has actually been uh quite a bit better in discussing resource pricing and adjusting resource pricing in blockchain so bitcoin is a more interesting case study because of how poorly the community has represented this topic okay so bitcoin is a bit different than ethereum for its data model it uses utxos so state elements in bitcoin are unspent transaction outputs which you can think kind of like i mean satoshi described it as you know paper bills essentially and if you want to spend your paper bill you have to break it up into change essentially right you can't you can't spend half a bill you actually have to

break it up and stay all the state and bitcoin is represented as utxos they don't have a notion of accounts and their execution model is where you can spend utxos you can create them and you can also impose some restrictions on how to spend utxos uh using stateless i.e pure predicates they don't have this kind of rich state that ethereum has you can basically define some pure praia predicate that's for example you know if you lock some coins behind some hash then you reveal the script of that hash that happens to be you know some 203 multisig and you provide two of three signatures from the provided public keys then okay you can spend your coin however you want so it's completely pure there's no access to state here it's

purely you look at the code you look at the input data and that tells you true or false and it was not it was not true then the transaction is invalid okay so we'll see the slide a lot because it's some it's it means the key of the talk uh but you need to meter resources again to prevent loss factors so how does bitcoin meter resources first and second how does it bound the consumption of the resources in each block and you know we need this notion of gas which might be a bit confusing if all you do is listen to bitcoin maximalists who talk about you know block size uh because bitcoin doesn't have a notion of gas right it just has bytes or does it okay before we before we discuss how bitcoin meters

these things like in the previous slide we have to discuss this thing called segregated witness or segwit because this is actually the key uh the key thing that we're going to use to show how bitcoin does what it does and why is it why the developers have made the decisions that they've made so what's segregated witness first of all this is a classic pre-segwit bitcoin transaction which is technically you can still broadcast such a transaction and have it mined on the bitcoin network uh this does it still works because you know it does with a soft work uh so new transaction looks like this uh you know you have on the uh on the left here you're saying okay i'm

spending this transaction from some previous utxo then you provide the signature or witness data as it's called more generally you provide the signature that says okay i have the right to spend this utxo because i'm the owner of this utxo then you tell uh then you you tell the transaction where my coins are going right so you spend the coin you say you say i'm spending these coins i prove i'm the owner of these coins and i have the right to spend them and then this is where i'm spending them too there's like the general form of a transaction and then you know you can this just shows how the utxo model works that you know each output here can then be spent in a subsequent transaction which is again a bit different than ethereum which is an accounts model okay so how does how does segwit work

now so in segwit instead of attaching the signature data inside the transaction we just say okay the signature data just authorizes the transaction right it's some witness that authorizes the transaction but it doesn't tell us what the transaction does right it just authorizes it doesn't actually tell us anything about the effect of the transaction right the transaction will actually spend some coins and generate some coins that's the effect uh the witness data is just just witness data right once once you know the transaction has been authorized you can discard this data it's completely relevant uh if i recall correctly uh this these witness data uh are essentially committed to in a hash in the coinbase transaction uh

which bitcoin has something along those lines uh so they are committed to in the block as they're not included directly in the transaction and the transactions tree they're committed to in some other place but they are very much in the block okay uh now you see that the sec the segwit transactions contrary to what some people in the bitcoin community might say are actually not smaller than regular transactions right the they're actually basically the same size potentially they're slightly bigger uh because you haven't removed the signature data you haven't removed the witness data you just moved it from one place to another place which has a bunch of benefits which we won't discuss here but these transactions aren't necessarily smaller okay so how does bitcoin meter

it's resources right what's what's the bitcoin notion of gas so pre-segwit you had uh one gas or one weight unit per byte so they would meter things per byte not per instruction executed like in ethereum that would meter just per byte and this to certain extent worked the reason being is that bitcoin again uses these pure predicates so because of that it doesn't have to worry about any halting problem or anything predicates are guaranteed to terminate and you know there's no loops in these predicates so you just basically go through scan them and then your time in the worst case and you always get true or false at the end you don't worry about the whole thing

problem which is great uh so you know one you know just metering based on bytes isn't completely terrible right it gives no it gives a good approximation uh and if we see down here how do we bound the resource consumption pre-segwit uh we bounded the max bitcoin bounded the max block size uh to one million of these weight units so if uh so essentially if you know if you have one weight unit per byte and you have a maximum of one million weight units that's one million bytes or one megabyte so that's where the one megabyte block size limit comes in okay so post segwit what does bitcoin do uh it costs four gas or four weight units

per non witness byte which if you remember from the picture earlier the non-witness byte tells us what the effect of the transaction is it tells us it consumes the state it generates the state or these utxos right because utxo is a state and it cost one gas or one weight unit per witness byte so witness data has been given this discount and in the post segwit world the maximum block weight is four million so if you have only witness data in your block you could have a maximum block size of four megabytes four million bytes if all your data is non-windows data then your maximum block size is one megabyte of course and in between if you have you know half witness data

have non witness data your block size is going to be somewhere between one and four megabytes uh which is a bit suspicious because you know we've been told by some people that bitcoin's block size is one megabyte but it's not it's four megabytes right the block size has been increased from one to four megabyte post segwit uh which seems like it would hurt decentralization if you remember decentralizations you know this cost to run a full node this seems to increase network bandwidth right it seems to increase disk storage you've now quadrupled the rate at which uh the the history of the chain will increase uh and you've quadrupled the network bandwidth required to run a full node that seems a bit suspicious right so why do we choose four not

we why did the bitcoin developers choose four why not million or something right uh and what is what are the s4 what does forex discount really mean so uh let's pretend let's put them in this example we have four million wade units right because we use a post we're using post tag with bitcoin and you have an equal number of non-windows and witness bytes and hopefully my math is right here uh but this isn't an equal amount of weight units right if you have the same number of bytes of non-windows and witness data in your block and the block is full uh they're not going to have an equal amount of weight units of course because witness data has a discount so you would have uh 3.2 million wage units of non-winners data

and 0.8 million units of witness data which together should add up to 4 million right because witness data is four times cheaper than regular data or non-witness data so now let's consider in this example here let's say we have some fancy moon math right you some fancy zk snarks or whatever and you say okay let's make the witness data completely free it costs nothing for witness data right then you've increased your uh your the amount of data you can fit in the not the total amount of weight but you can increase the amount of non-witness data in the block from 3.2 million before to 4 million which gives us only a 25 increase in the throughput of our chain even

though we've done all this hard work to remove this witness data right which is a bit suspicious because you know we've done all this all this hard work we removed his witness data witness data takes up half the number of bytes in our block uh why is it only a 25 increase in throughput right uh you know previously bitcoin used to be metered only by bytes if you remove half the bytes in our block because again we have an equal number of non-widgets and witness data you'd expect to have maybe double the throughput why is only 25 well it's only 25 because the param the discount a 4x was chosen right if the discount was 1x in other words it was the same cost then okay you you would in fact double your block size uh

double your throughput but because of the uh because of the 4x it's only a quarter so 25 percent uh so it's a bit suspicious right there's something fishy going on here uh compared to how bitcoin is previously metered and how it is currently metered uh so why was the discount chosen i guess not four in particular but why was a discount given uh we'll cover why forex i think in a subsequent slide but why was a discount given to witness data and this is going to be very important uh so for those of you who are listening at home and recording or something in a podcast form where you're not actually listening to you're not actually watching the slides i'll read out the slides uh here and apologies for everyone who's

actually here in person uh but these are tweets from peter wiley uh one of the bitcoin core developers explaining on twitter why why a discount for witness data was given not forex but just why discount period was given so the rationale is that i'm reading the tweets here the rationale is that witness data can be discounted because it has far lower long-term costs to the network it does not enter the utxoset in particular it's not arbitrarily changing the luggage charging their luggage differently it's charging differently for checked and carry on luggage john aside this this this is a bit this is a bit of an interesting analogy uh so second tweet

uh segwit transactions and pre-segwit transactions that do the same thing are approximately the same size some sometimes slightly less sometimes slightly more segwit discounting rectifies the fact that bytes are not the only metric for measuring network impact so here he's he's telling us kind of the intuition that we built up over the past few slides that just raw bytes themselves aren't exactly necessarily a good way of measuring and metering resources and he's explaining why and the first slide which is that witness data the signature data doesn't enter the utxo set it doesn't enter the state and if you remember one of our resources was random access storage on a ssd because that's where we put the state of our chain state as in like

account balances or the utxo set okay another two tweets by the same person first one the whole idea of the discount is that block size isn't the best way to measure the cost a block has on the ecosystem segwit is a block size increase as it increases the network or sorry the bandwidth storage costs segwit is not a block size increase as it doesn't increase the max utxo ops per block secondly segwit changes the metric from size to weight which i believe and hopefully the rest of the ecosystem agreed with is a better way of constraining resource usage so all this aligns well with what uh what you know the intuitions we've built up over the past few slides which is that yes you've increased the

block size from block size limit from one to four megabytes this does take up more network bandwidth it does take out more disk storage for history but it doesn't increase the uh the rate at which the utxo set grows okay so why did they do this uh and the reason is because of what they think be a social consensus and via potentially you know some experimentation it depends on what they think the bottleneck is so from pre-segway to sagwett when the block size will increase from one megabyte to four megabytes uh if the network bandwidth like if downloading block data

was the bottleneck would they have done this the answer is no obviously either the network bandwidth was the bottleneck they wouldn't have increased the cost the resource consumption of the network bandwidth right so the network isn't the bottleneck okay so is the disk capacity just like the store transaction history is that the bottleneck well also no because if this was the bottleneck well you probably don't want to quadruple the rate at which history grows uh was the cpu cost of bottleneck right just verifying signatures and performing you know and validating validating the predicates was that the bottleneck well also no because you know you potentially quadrupled the amount of signatures you have to verify uh so you know probably your signatures

aren't your bottleneck your cpu cost is in the bottleneck is the memory bandwidth no inc and capacity the bottleneck um bitcoin doesn't have you know complex memory usage and copying bytes and stuff so no just just by virtue of it being bitcoin not because of the segwit so is this consumption of random access random ass access disk bandwidth and capacity is that the bottleneck and the answer is yes right and as as the cordov told us in the previous slides they want to bound the rate at which state grows right that's their bottleneck and this random access disk capacity right that's you put the you put your state on an ssd

you do some random access into the state and that's what they want to bound that's the bottleneck okay so uh some takeaways what do we learn from bitcoin and segwit uh bitcoin's bottleneck is the state growth rate and this is agreed upon via social coordination it's not some magic thing that exists because of math it's not governed by math right it's some social construct ethereum has some has similar social coordination stuff and the agreed-upon rate at which the state should grow is one million bytes of non-witness data per block and if we notice post-segwit since the block size since the block weight limit is four million

and each non-witness byte costs four weight units i hope we agree that pre-segwit and post-segwit the maximum amount of non-witness data you can put on a block is unchanged right they've been given a discount to witness data to signatures but they did not give a discount for regular non-witness data because you know those are state changing that state-changing bytes essentially that has remained the same it's still the same one million bytes of non-what is native per block so you know post segwit we haven't actually increased the rate at which state grows it stays exactly the same because the stake growth is what they've decided is the bottleneck right and you you uh you don't want to uh you don't want to increase the load

on the bottleneck you can increase the load elsewhere but you don't want to increase the resource load on the bottleneck because then you're hurting decentralization you know you make it more expensive to run a full node so we also note something interesting here which is that to scale you have to target the bottleneck just like how uh just like how you don't want to target the bottleneck unless you unless you want to hurt decentralization but also to scale you need to make resource consumption on the bottleneck more more efficient essentially you have to reduce it in some way it could be because you just straight up reduce it it could be because of increased efficiencies and so on uh but specifically you need to target the bottleneck to achieve scalability and that's why uh you know even if we

remove the cost of you know cpu signature verification of the of the witness data you only increase the uh the amount of transaction through but by 25 because that isn't the bottleneck it's only a minor incremental improvement okay so bitcoin does have a concept of gas contrary to popular belief and it's just they call it weight units uh and there's no really formal reason for why the discount was given for a parameter four right the having a discount we hopefully we see from previous slides is a good idea right because it allows us to not increase the load on the bottleneck but why four wind up eight or sixteen or like a thousand

there's actually not a formal reason here this is the this is like the dirty secret of the blockchain world those basically just you run some experiments you think about it a bit four seems reasonable it's a good conservative start but that's about it uh they could have chosen eight or 16. bitcoin would still work okay uh and another thing to note here and this is important as we head into the the next the next blockchain which is that the weight units here need to meter all resources right there's like five different resources resource types that we talked about and these weight units need to meet all of them previously before wade units it was just bytes pre-segwit bytes were very inaccurate right because they didn't distinguish between witness data which doesn't enter the

state anonymous data which does affect the state and which does affect state growth right bytes were very inaccurate so okay weight units are a bit better uh but there's still a bit it's still a bit tricky because if you want to do anything more flexible than a bitcoin currently has uh you now have all the other orthogonal resources other than stage usage right you have network bandwidth you have disk storage for history you have cpu time you have memory all these things are all metered by weight units right so this is a bit tricky here okay let's look at our next blockchain or the one we're all here for ethereum how does ethereum deal with resource pricing okay ethereum uses a different

uh data model than bitcoin hopefully we're more familiar with this one it's accounts and storage right you have this big ass state tree the patrician merkle tree it has this leaves it has accounts which have a balance they have a nonce uh and then they can also have contract code and their contracts they can also have storage right so the storage could be things like token balances for a token contract and its execution model rather than pure predicates it uses uh some touring complete stuff with obviously some gas limit to prevent uh to prevent infinite loops and it has this rich storage right so contrast can read and write state that isn't uh that isn't explicitly declared in the

transaction in a bitcoin transaction in the utxo world you have to tell the transaction essentially tells you exactly how the state will be modified and ethereum the state of the chain can be modified arbitrarily during transaction execution and the transaction body itself tells you nothing you have to actually run the transaction okay so again we first need to meter resources and then we need to bound the consumption of these resources for each ethereum has to do this too all blockchains have to do this well maybe not you know the centralized scam chains but you get the idea okay uh so how does ethereum meter resource consumption it meters it with gas obviously and transactions have a 21 000 base cost

they additionally cost 16 gas per byte for the data that you put in the transaction and they cost some variable amount of gas per instruction executed during transactions execution now could transactions well okay before i ask this question i say we have to we can bound the resource consumption of each block to i think is 12 and a half million uh gas per block today this could increase or decrease in the future uh maybe with you know once gas per year maybe it'll increase more i don't know uh but you know i think right now it's about 12 and a half million gas per block okay so if we uh the transactions have a 21 000

base cost so every time you send the transaction you have to pay a minimum of 21 000 gas even if all the transaction does is send ether from one person to another and it doesn't execute anything else so if you just remove this cost and said okay transactions have a zero base cost it costs absolutely nothing to send uh would that be would that be a dos vector would that allow someone to create infinitely sized blocks so show of hands who thinks this would allow someone to create a huge block with no block size limit okay no one's raising their hand who doesn't think that okay also no one raises their hand okay no one knows that's good uh there's actually a trick question the

reason the true question is that i didn't write this here on the slide but ethereum simultaneously bounds its block size limit not just gas consumed for block but also block size uh so you also have to fit i think the limit is 40 kilobytes don't call me on this but your block also has has to be less than 12 less than or equal to 12 and a half million gas and last one or equal to i think it's for 40 kilobytes maybe four kilobytes i don't remember so there's a four there somewhere and there's some kilobytes uh so even if our base cost was completely removed even if there was zero base cost uh you wouldn't be able to create an infinite infinitely sized block with infinite transactions you'll still be bound by that you know that block size limit in bytes

uh so why is the base cost important it's actually important at the mempool level uh and you want to avoid denial of service attacks at the mempool level if a transaction didn't have a base cost people could flood the mempool with what seemed to be completely valid transactions and all they're doing is sending a simple ether from an empty account to some some rather random account and of course since the base cost is zero and they're sending say zero ether then you know that transaction's perfectly valid there's nothing wrong with this transaction uh so you'd be able to flood the memphis so the base cost really is a denial service prevention mechanism for the mempool because you at least need to have some ether in your

account to pay for this to pay for the base cost at least so there's like a it's useful for this thing called standardness rules which apply not validity in the block but they apply you can call them validity in the mempool okay that was a tricky question uh moving on the uh accounts uh so this gas here accounts for all resources all resource consumption right and again we there's five different resource types and accounts for it all with a single unit what you see from when we were looking at bitcoin accounting for resource consumption with a single unit this is a bit ugly and because of that there have been many erps to reprice the

cost of opcodes and call data and other stuff and in fact just skimming through the core eips that have been accepted and implemented i think about half of them maybe more were just about repricing gas so it's a very tricky thing but fortunately the ethereum community has been very forward and very open in uh repricing and repricing these things to close loss factors and stuff uh so it's much more flexible than the bitcoin community which took me years and years and years to do like a single single adjustment in uh in in how they meter uh meter resource consumption okay so why was 12 and a half million gas per block chosen why not 20 million why not 200 million why not three second

block times you know no relation to any chain that is running today okay so why 12 and a half million for ethereum right which again our notion of decentralization here which is the cost to run a full node so there's two reasons why 12 and a half million was chosen the first is the validation rate uh which is that go ethereum can currently validate about 50 to 100 mega gas per second on a regular laptop i tested this at home uh and generally you want to validate blocks about 50 to 100 times as fast as they're produced so that when you're doing a full sync you can catch up in a reasonable reasonable amount of time so you know you take 100 divided by 100 multiplied by 12 second block times whoa what a coincidence is 12 and a half

million gas per block all right so if you increased the gas per block uh or you decrease say the block time then you'd be hurting this validation rate you wouldn't be able to validate blocks as fast uh which means that a full sync would take longer and longer and longer and potentially you know if the chain is has a huge gas limit you have a regular laptop it could take you years to catch up to the head that's of course not very decentralized right the second thing is we want to bound the state growth rate uh the ethereum state is currently about 90 gigabytes bitcoin state is currently about four gigabytes and the higher the block has limit the faster the state growth rate so we want to bound this to some smaller

number probably smaller than what it currently is unfortunately so what are some takeaways for ethereum so ethereum gas has been decent at metering everything except for state growth like we saw in the previous slide ethereum state is about 90 gigabytes this is not very good and this is really the hard bottleneck we you know the validation rate we can be a bit flexible for now but the stake growth rate for ethereum has really been the hard bottleneck so what are some some solutions to this can we again because the scale we need to target the bottleneck okay maybe you can do state rent right you can charge people over time for the state they use you can do state expiry you can make state just kind of poof disappear after some time you can do

statelessness which i think piper was just talking about uh two talks ago here uh check out his talk if you're interested in the stateless ethereum stuff that's going on uh nowadays uh you could also do simpler stuff you could just make storage operations more expensive which there have been several eips to do this or you could make call data cheaper right if you make it cheaper then people are going to use more call data less storage okay uh now what are some challenges in pricing the state right i said okay you just you know make storage drops more expensive it's not really that simple uh the problem is that storage you pay for two different things one is you pay for the short term cost

of actually you know doing a state read or inserting an element into the state right you say okay alice transfers coins to bob bob doesn't have any coins so let's make bob a new account essentially right uh that's the short term cost but you also have to think about the long term cost of state since everything is stored since the state is stored in a merkle tree the more leaves you have in the smoke tree the bigger it is and the more it costs you to go to both store it and to go descend to descend it to get to the leaf and this is much harder to kind of this doesn't have an immediate impact right it's like you don't immediately see this cost but it grows over time uh so paying for these two completely different things with a single unit is very messy and this is presumably why

we've seen so many issues with you know the theorem state size is huge uh and when you add sales last year you also have to do things like pay for witness data because eventually you need to you know provide witness data to show okay i have the state element so the gas metering also has to account for this which is a bit tricky because if you've been following the stateless ethereum thing you know they've been trying to use things like vocal trees and whatnot because otherwise witnesses could be very big and are you paying enough for them and so on okay so let's now cover evm roll-ups let's let's take a let's take you know the evm go ethereum and let's put it into a roll-up and let's see how does this how did this price resources okay so i roll up post data on chain for

data availability it actually does the execution off-chain uh and it also all the state growth and stuff that you know we've been we've been complaining about on ethereum all the state growth is moved off-chain that's pretty good right uh but you still need a full node you still need to run a full node for the roll up in order to verify the rob is correct and be able to produce new blocks uh and you need to run a full node for the main chain because obviously just just running a full node for the roll-up is kind of relevant if you don't know the main chain is posting uh its blocks to is valid right so we need to run two two full nodes uh which is more than one full node right so if you don't do things right you could actually decrease decentralization of the schemes and you know we want to

scale but we want to keep decentralization if you're willing to give up decentralization just go use you know something that should much that shall not be named uh so how do how do these evm roll ups work right uh similar data model to ethereum because you just take the evm and put it in a rollup now it accounts for storage with during complete execution again a roll-up is not magic i roll up as a blockchain and like all are the like all decentralized blockchains you need to meter its resources and you need to bound the amount of resources you used per block okay how does an evm roll meter resources so here's where things get interesting unlike ethereum proper an evm roll-up has

two ways of metering resources two ways of metering two independent resources which is good the first is that you have to pay for the bytes of data availability that you put on ethereum and you pay for this on ethereum the second thing is the roll-up presumably is going to have some limited gas limit you know some finite gas limit and you have to pay to use that right it's a scarce resource you have to pay to use this so you need to pay for off-chain computation state growth and all this other stuff and you can pay this in some form of gas on the roll-up uh so again there's two different different ways of metering and paying for two different independent resources so first is

the bytes the data availability you just meter in bytes and you pay for bytes and this is great because you've essentially now paid for a resource exactly in the one resource and you have one unit for that one resource type this is great and then this gas accounts for everything else this isn't worse than we had before it's presumably a bit better because you don't now have to also pay for bytes in addition to everything else so we're we're getting somewhere okay uh and you also bound the resource consumption for of each block so to bound the resource consumption we have to say what's the bottleneck of our vm roll-ups okay so you know we present we pretend we have some

evm roll up why do we choose some gas limit x per roll of block i haven't said what x is but we're going to determine the parameter in this slide but why x why not 2 x 1 20 x right why do we choose this parameter here right okay so you have an evm roll up it just takes go ethereum puts it in a rollup right go ethereum has not changed it can validate 50 to 100 million mega gas per second on a laptop just like before we want to validate blocks at the same rate just like before because we keep decentralization right we don't want to hurt decentralization so you want to validate blocks 50 to 100 times as fast as they're produced to again catch up to the tip of the roll-up uh so this gives us an x of 12 and a half

million gas per block which is the same as ethereum right so roll-ups don't actually scale ethereum uh because again you've moved execution off chain but people still need to run a full node i mean sure you pay for bytes on your on ethereum but you know you still you still need to bound the block size limit off of the roadblock otherwise you lose decentralization and similarly for state growth well ethereum state is currently 90 gigabytes you probably don't want that on your roll-up too because that's a problem that's a mistake that should never have happened so to stop your roll up from having such a large state so fast you probably might want x to be even less than 12 and a half million and maybe you might also want to tweak the gas cost of things like asteroid slo to

be much much higher maybe 10 times higher maybe 100 times higher so that you don't encounter the stake growth bottleneck okay and i want to emphasize here is don't believe everything you see about rollups online you see a post like this that say okay i have an east transfer it takes 12 bytes on a roll up uh therefore you get 105x scalability by just putting your each transfer in an optimistic roll up that's not all how this works right these kinds of tables only account for the layer one bytes but as we saw in previous slides we can't just account for that we need to account for the gas used in the layer two in the roll-up uh so you don't get this 100x you know scalability you don't get a 100x cost decrease by just having an evm optimistic roll-up

you can't only account for the layer one gas cost of bytes you also have to account for the actual cost of the gas in the roll-up so some takeaways uh you do still need to run a full node for the roll-up to be secure and decentralized you can't avoid this right if you're willing to live with fraud proofs or you're willing to you know trust as one honest person uh don't use the roll up use the layer one blockchain that makes the same trust assumption and that has a one trillion gas limit it'll be just as secure right if we really want to scale ethereum and we want to be secure and decentralized and stick to our values that we've been preaching to all these other coins well you should probably run a full node for your you should be able to run a full node

for your roll up okay so therefore a single evm roll up doesn't provide scalability to the evm it can provide scalability potentially to something worse than the evm but multiple roll-ups in parallel could so it's a form of sharding very good like this this is good you might lose some composability and charting but i mean that's already pretty good right and it's important that users and specifically transaction fees need to pay for both of these things they need to pay for data availability and they need to pay for execution uh so it's not all bad uh i might it might seem like i'm negative on robs but this isn't all bad like we separated paying for bytes and paying for everything else and we pay for bytes with bytes which is pretty good

we're getting somewhere uh so how would we scale with row ups if we want to scale the drops well i mean the sharding route that i talked about earlier which is you know you run multiple of them and multiple of them in parallel but you could also do things like have a fundamentally more efficient fundamentally more scalable virtual machine and this is what fuel lab is building with fuel v2 we're building uh the most scalable optimistic roll-up on ethereum uh where we're building ethereum style smart contracts so for the user this looks just like ethereum style smart contracts but built on top of the utxo data model so you can leverage parallelism uh feel free to reach out to me after the talk if you want to know more about this thing okay so now let's talk about blockchains

the data layer 12 minutes left uh what happens what happens we have a different blockchain contract that just a blockchain is a data layer it doesn't execute transactions it just orders data this is actually the true realization of satoshi's vision tm and satoshi in his paper describes in the bitcoin design paper he describes what a blockchain does which says we need a way for the payee to know that the previous owner did not sign any earlier transactions for our purposes the earliest transaction is the one that counts and he says here and there's an important part the only way to confirm the absence of a transaction is to be aware of all transactions so what you're describing here is it says

okay if we have a timestamping server and if we if people know all the transactions that ever occurred they would just take the first valid one and ignore all the subsequent ones so why is it that we got from here to bitcoin where an invalid transaction can't be included in a block that makes no sense how do we how do we jump to that uh the paradigm of bitcoin and ethereum of saying you cannot include an invalid transaction in the block it actually doesn't match at all what satoshi was describing here what satoshi was saying here was if we know all transactions including the invalid ones users can just pick the first one and say this is the valid one and ignore the rest we don't actually need the blockchain to exclude them users can okay so let's pretend we have a blockchain all it does

is order data make it available so what is data model well nothing right it doesn't execute transactions there's no state what's this execution model again nothing and this is what we describe as general purpose in quotes which is that the data layer can be used without being encumbered by a very heavy virtual machine that everyone has to validate all you do is you just look at the data and it's available and it's ordered and it's time stamped okay so again you have the meter based on resources you have to bound the consumption of resources so again the blockchain this general purpose data availability blockchain doesn't execute transactions all it does is order zeros and ones bytes right so okay you only have one resource being consumed

it's bytes right you download them and you store them and that's it well that's fantastic because we know how to meter bytes you just meter one gas per byte or one unit of something per byte and you're done and how do we bound the max resource consumption in our block well it's also simple it's just the maximum size and bytes oh that's so good right we don't have to deal with gas we don't have to tweak the gas costs of individual up codes and instructions we just say let's per byte and we're done uh so the base chain is only used for data availability in this paradigm and we can meter stuff in bytes and we can meet our bytes and bytes which is good and we essentially punt all the state growth all the execution and everything

two layer twos two roll ups right just like how you doing a roll up on ethereum today right and they can meter their execution they can meter their state growth flexibly it's up to them they can use some concept of gas but this base data availability chain doesn't care about this right and you can have separate fee markets and separate ways of pricing uh these two independent resources right data availability in the base chain and execution on the roll-up or multiple roll-ups so let's do a brief case study on e2 or serenity uh post merge or i don't know when they when they change it from the docking to the merge but i prefer the docking uh post merge and post data only shards right

which is the current plan for e2 uh is this a general purpose data availability chain like i described in the previous slides no is not and the reason is that to use these data shards in e2 you have to fully validate the evm post merge right the post the merge is essentially taking the proof of stake consensus and merging in the evm as it currently is on ethereum so if you wanted to use these data shards you would have to also validate the evm which as we've seen from previous slides is very heavy because of past mistakes around gas pricing right so this would only really serve as a data availability layer for ethereum only applications for applications that run in the evm but we live in a multichain world there

are other trains that are running that are innovating outside the evm just like how ethereum is innovating outside of bitcoin right we shouldn't be maximum list here and we might not want to fully validate the super heavy evm to make use of this highly scalable data availability layer so there is a need for a data availability layer that is general purpose that is not tied to a heavy virtual machine okay uh now one other interesting thing this is like segue to a different point one interesting thing around uh data availability in particular is we don't actually have to download every single byte to guarantee that a block is available and this is where things are

really interesting to execute a transaction you need to fully download all the transaction data and fully execute it you can't do things partially for data availability we actually have a very clever way of not having to download every block so my co-founder at celestia labs mustafa albassam co-authored a paper with vitelli buterin on fraud and data availability proofs a couple years ago that essentially demonstrates this technique or he formalized this technique called data availability sampling nowadays back then i think it's called data availability proofs but there's data availability sampling which allows you to verify that a block is available without downloading the whole block which actually means it could be cheaper than one byte per byte or like one gas

unit per byte for data availability only and the kind of very naive short description here is that the naive uh the naive way you would you would try to verify a block is available is download random chunks from it uh this doesn't work because someone could hide a single chunk and then you'd be tricked so what you do is you use a razor coating this essentially adds some redundancy so like say you extend you extend some you extend some block to twice its size and as long as you can recover half of this extended data then you can recover the whole data and this kind of error correcting thing has been used in various you know media encoding things like cd-roms and all this other stuff because

it's good right it means that even if you lose some parts of the data as long as you have half of the data you can still recover everything as it was originally which is obviously very powerful if your media is subject to you know scratches and stuff like that right so it's been used for decades uh so the intuition here is that every time you sample you have 50 chance of being tricked uh and 50 chance of being right so you know if you sample 100 times then your chance of being tricked is essentially zero because it's half to the power of n just like just speed course you can uh you can you'll find various write-ups and stuff about data availability sampling but it's key to uh data availability layers and this includes uh sharding okay so what are the takeaways around

a general purpose data availability layer it seems like a good idea right it makes gas metering substantially cheaper uh it's substantially more flexible than the world computer model and there is a need for such a system uh in this multi-chain world and because of data availability sampling we can actually verify the data is available without downloading at all which you can't do if you had execution baked into the base layer all right this only works if your chain is like a data availability only chain okay so wrapping up two more slides just in time the tldr of resource pricing all decentralized blockchains have a finite capacity for resources this is like the notion of decentralization we all come together

and we socially coordinate and say okay this blockchain will consume this much resources it would cost as much to run a full node so all blockchains need to meter those resources in some way no exception decentralized blockchains uh and both data availability and execution must be metered you can't have a roll up and just only meter the data availability part you can't do you can't do that right let's not decentralize it's not secure you need to meter both of them and uh resource pricing especially around things like state growth and these long-term effects that aren't uh immediately apparent is actually non-trivial it's very tricky it's still a work in progress and the ethereum ecosystem has done a good job of exploring uh like in getting close slowly but surely you know there's it's

been a tumultuous new winding path but they're getting close to having a much better model of how to price execution and stickers and stuff uh so what's the future of blockchain resource pricing in my opinion this last slide uh so if we separate data availability which again thanks to data availability sampling could have some linear cost and it's much easier to optimize because you're doing one thing you separate data availability from execution an execution happens at layer two this is just strictly better than the status quo of doing data availability and execution all on a single layer and all under a single metering scheme to separate them right layer one provides data availability and ordering and time stamping layer 2 provides

execution on top of this order data through the form of roll ups and the best part about this is you can have separate fee markets for each right and you don't have to worry necessarily about having a common metering you just have separate fee markets the fee markets will price these resources accordingly okay so if you want to contact me uh i'm on twitter at j adler zero and you can follow my projects last year at uh org so that's the end of slides we have two minutes left so maybe questions maybe not depending on what the organizers choose thanks john from the uh wonderful talk

uh just wondering what's your take on the state growth of the chains like finance polygon and what not yeah which is wondering you know they don't seem to care that much uh about resource metering right and uh i'm just wondering you know what's your take on the next months uh given the state growth of these evm compliant blockchains uh sure so uh for the record i only know some of these things through secondhand information uh but i will say from what i've heard a lot of these chains that essentially run go ethereum and just dramatically increase the gas limit it's very hard to run a full node for so they can choose and they do choose to essentially forego decentralization

completely and say users can't run a full node on any reasonable end user machine but in exchange for that we get massive transaction through but increase which they can do and they'll they will encounter a lot of problems that are in the go ethereum code base uh because of their they're gonna have huge state and you know you know the chain will reorg non-stop i think some of those trains experience like a huge number of reorgs so they'll just have problems you know they can make the choice it's their choice to make but they will experience problems all right okay i think that's it for time but thanks for having me oh there's one more yeah uh so thank you so much john it was a beautiful talk and

i uh this is eric wall here speaking and i completely agree with the things this year just said i just had a minor nitpick on on what you said about the bitcoin and whether or not it increases the block size uh or whether or not it actually increases the capacity to increase the utxo set with the segwit up and if you move witness data to a separate to a separate component you do fit in more more of the stuff in the baseblock so if you take out the witness data and you put it in a separate component which you meter differently wouldn't that allow you to have more uh utxo set updating transactions in the

in the one megabyte byte base block than you would have before because in the previous before segwit you had to put all the all of the witness data in the base block so it would limit the amount of uh utxo set updating uh transactions in the base block so don't you think that you could squeeze more utex oset updating transactions in the base block uh now after segregated witness um that was uh just a minor nitpick that i think oh with that said i do think the conclusions that you've come to in this talk are absolutely beautiful and and i really respect the work that you've done on celestia and and fuel as well really seems like a promising roll-up thanks for the comment uh your question

is actually correct i hadn't considered that i hadn't considered that too deeply i'm not you know the biggest uh i'm not too deeply involved in bitcoin but i think you are correct uh that moving witness data completely outside uh completely outside that you know one megabyte limit means you could fit more utxo ops in that one megabyte you are correct i think in that uh that being said it's presumably a very small increase uh like much smaller than that 4x but yeah it would be it would be a minor increase yeah true true thank you you