DAPPCON 2024: I Like Big Blocks And I Cannot Lie - Anton Wahrstätter

Transcript

hi everyone I'm super happy to be here to talk about a topic I'm actually very passionate about which is Big Blocks but to be honest I was a much bigger fan of bigger blocks back in the days when when Bitcoin had the discussions on Big Blocks so I was in the big block Camp not in the correct right camp but I was for the Big Blocks and over the years getting more and more into the into the depths of the protocol I would say I turned into a small blocker by now still the the title is of my talk is I Like Big Blocks and I cannot lie um I will come to that later you will see why um Big Blocks but yeah let's don't waste any time and get into it so on the side

you can see the agenda I want to talk about I'm basically starting with the components with the variables that make a block big which is the block size starting with the block size and then we have the gas limit um call data and the blops and then I want to quickly go through a practical example why Big Blocks might be an issue and finally I want to um outline two proposals that are currently um one of them is considered for the next hard Falk for pectra the other one is yeah a little more in the future and was just proposed a few weeks ago and I want to quickly um highlight them here but from the beginning so if you look at ephr scan this is kind of a a quite um

present screenshot I took from Osan we can see that the block size has steadily been incre uh steadily increased and especially in at the end of 2023 we saw this big spike and block size which was mainly caused by rollups and blop uh not blob inscriptions but inscriptions so people just posting some arbitrary data doesn't matter if it's a rollup or some user people posted arbitrary data um to etherium L1 and they used call data for that now with shipping the tenun hard for this um the block size Cal down we are currently at a level of 100 kilobytes per block which is I would say quite healthy but you can already see we were at almost um 200 um um yeah 200k

bytes as you can see here in the chart before um getting deep into it let's quick summarize what actually contributes to a big block and first we have of course the gas limit the more um call data you can fit into a block so you need a lot of um for example if you increase the G the gas limit you can fit more C data into your block which then also increases the block size second the call data cost itself the cheaper the call data the more call data you can put within your gas limit which also contributes to a bigger block and finally since 4844 we have blobs and blops also contribute to bigger block blocks I assume here now that blocks

blops are part of the block which is technically not true but still if you look at it from a networking perspective um I just count the blops here into the block size but yeah forgive me for that inaccuracy this is kind of the same but in a little bit more visual representation you can see before we did for 844 the two main contributors to big blocks were basically the gas limit and cheap call data so both of them on two access and then we have 4844 which kind of added six blocks on maximum um to the current block size and finally on the right hand side this is what I will talk

about a little later my talk which is basically an idea of shrinking down the elite in order to make room for mop blops but this is then part of The Proposal section let's first look at the the history of the gas limit you can see this chart shows you the gas used per day so kind of the summed up gas per day from the beginning since aerum launched until um quite recently and the important part in this chart is this section so this is kind of everything that happened after the L London hard frog so the London hard frog introduced EAP 1559 which kind of created this very nice level um very

stable level of daily gas limit used and if you look closely you can see that at some point it got very stable and this is when the merge happened because with the merge we got a constant slot time of 12 seconds which meant that the block um the gas used per day stabilized basically at the Target which is super nice to see because it basically also shows that shows us how nice e one 559 work worked together with the merge and with a constant slot time right this is basically everything I already said the last point is maybe a little uh also important I want to outline that there is that the that the gas limit is not controlled by anyone

except the user or an node Runner the people running nodes so the gas limit is raised by the nodes together so basically um every time we raise the gas limit it's not like um do a hard fork and just raise it it's basically the users deciding we raise the gas limit together and there's currently a community effort you can find it at pumpd gas.org where you can basically opt in to signal that you want to increase the gas limit I'm not for increasing the gas limit but yeah um I think it's super cool to see the community coming together um and coordinating such a such a change the gas limit all also um affects

the maximum possible block size of today what you can see in this chart is on the Y AIS the size of a compressed beacon block so compressed with Snappy compression which is kind of the standard nowadays in etherum on the x-axis you can see different gas limits and what we can see here is today um by just simply calculating the compressed size by using the gas limit divided by the nonzero bytes the cost of the non Z bytes gives you the current maximum possible block size this is still simplified we will come to that later but when we talk about block size so this is very important here when we talk about block size there are different

block sizes first we can talk about the compressed block size which is maxed by taking the gas limit divided by the nonzero bytes nonzero bytes because Snappy compression is very bad at compressing random zerob bytes uh random non-zeroes without Snappy compression the maximum block size is actually above 7 mbes because um you can just take the gas limit divided by the gas cost for zero bytes which is four at the moment so if you do 30 million divided by 4 you arrive at a block size of over 7 megabytes which can be compressed I think to around 0.5 megabytes even lower so this is not a big problem because

Snappy compression is very good at compressing a sequence of zeros and finally a third um size within the protocol is within the engine API which uses some which uses Jason format and there you basically have to twox the block size that you already have just because of some inefficiency of Jason so talking about the block size we always have to be very clear which block size we are actually talking about is it the snappy compress block size is it the block size without Snappy compression or is it the block size with in the engine API that then again doubles next we have call data call data is currently also I would say a widely discussed topic especially there is EAP

for increasing the call data cost and currently the call data cost per nonzero bite is at 16 and you can see on this chart here if we would go lower for example if we would go from 16 call data uh from 16 Gus per non-zero call data BTE to um for example eight then we would essentially double the block size and on the other side the same the same applies when we look at the evolution of call data we can see that um it was steadily increasing but then with more and more rollups posting their data down to L1 using call data we see this

massive Spike here which was also in part um yeah um um there were also some inscriptions I think that also caused this massive Spike that you can see here in the chart and what it shows us um there was a big demand a big demand for posting data to L1 now with having blobs this demand C down a bit we saw still some inscription spamming but not at the levels that were present um as you can see here in the chart finally the last variable that contributes to the block size are blobs and what you can see on this chart is basic is the beacon block in yellow

which is as said at around 100 kilobyte this is the current average block size and with 48 for four we added a maximum of six blops and a target of three blops so on average we will see a picture like this where you have an average size block of 100 kiloby and then you have to add um three times 128 kilobytes in addition so what this tells us is with 4844 we essentially forx the block size because it was around 128 kilobytes and now it's um at 500 kilobytes so even though it of course it's on the road map and it's

great for scaling but we should not forget that this came with the quote unquote cost of increasing the whole it works yeah I said the target is at three the the maximum number of blocks per block is at six and then you have already 6 times 128 which yeah means you would um have 7x um the average block size that we had before 4844 and in if you visualize that it looks like this we saw before we did 4844 it was um we only had a block containing um the CL part and the El part and with for for four there were

these um additional blops and you can already see at the end of this chart which still captures this blob inscription spamming we had you can already see that it's basically the blobs that are responsible for the main um load there or for the for the the main contributors to Big Blocks nowaday the thing about blobs is it's actually quite nice because they are of static size so if we add a new block we we know it's it's exactly 128 kiloby this is not the case for the El and the CL part of the block while the CL part is actually quite small the E part has a high variance and you can see that here

this is a average block that you see on the main net today where the CL part is only 20% of the total and the E part is around 80% the problem is if you look at the max blocks so the biggest blocks that we see today then this looks like this this means 99% of the Big Blocks is caused by a by the very big eel part and the CL part is basically 1% of the whole block this means there is much room in the El part and not that much room in the CL part so this is the question right are blocks too big and I would like to please raise your hands who thinks um

blocks are already too big no one yeah yeah so can I then assume that everyone else thinks like okay blobs are not big and we still have some room yeah okay let's look into this chart so this is basically just comparing ROK blocks with nonre block and what you can see here Al um we could yeah we can see that the size the compressed size so now already talking about Snappy compressed blocks is higher for re blocks than for not reor blocks which might point to Big Blocks having a higher probability of

being reared out we can already see that at the builders certain Builders um they limit transaction so you can try to send that transaction that is over 100 kiloby send it to all those famous Builders you might have hard times getting that transaction in because the Builder is of course concerned that your transaction that is so big might cause a slower propagation which could mean the Builder might lose it all its Arbitrage opportunities all its sandwiches that he had in that block just by including your big transaction so if you want to get such a big transaction on chain then you better pay the Builder well because otherwise the Builder will just discriminate and censor you the thing is there's still so much

room until we actually reach the max block size and this is visualized in this chart here we can see at the very bottom this is um where we are today the average block Which con contains this small line of el and cl part we can almost not um still and also the blop power is very small but we could Max it out until 3.5 megabyte and 3.5 is the current maximum block size within um including blops so we cannot go higher but this is you can see this big gap between the average and the Max and you can already tell right this is this doesn't look very efficient there is also this line about um e 7623 but we can ignore that now I

will I will come to that later next I want to show you this conversation I had with Perry from the devops team um to come to my practical example that I wanted to present you don't have to read everything but it's basically a standard um just a very standard conversation between me and Perry so I'm reaching out to Perry hey Perry I want to build a big block can you help me he's like yeah let's let's do it I sent him over the block and you can see on the up on the lower right side I just put a sign transaction into a text file and sent it over to Perry and you can already see the text file got quite big right so this is how it started and what I tried to do was

basically experimenting right I was like okay why not experiment on theola it's a test Network what what can go wrong yeah something went wrong and what happened this is one month later so basically at the same day we already so we submitted that block we tried to use a g node so we submitted we tried to submit my transaction and Perry was like yeah something strange happened we couldn't submit your transaction then we reached out to Justin from peso and Justin was like receiving the file and he responded something like okay nice transaction. txt that's not suspicious I will submit it so Justin got it into a block and my transaction was basically

propagating through the whole network at some point I think it was then in the evening already there was some Twitter user that was like okay I'm running as Aon Noe and I get some strange errors there the devops team also looked into that and basically there was a huge Chaos on the sapoia network and what happened is summarized in this um graph that Marios um from the G team created what happened is my transaction got included into a block of the Basu client the block was then proposed it was a valid block it was within the 30 million gas it didn't do anything wrong but within the Gaff engine API there was a hardcoded limit of a block size and

this limit declined my block I declined that block and re reok it out again my the the problem was my transaction was paying very well so all all clients except G continuously tried to include my transaction and GFF reok it out again and this caused some some Chaos on zolia and it would have also been possible on mainnet and this was kind of the very scary thing because it's basically a very lowcost attack on the network that would mean that every time a minority client proposes a block it would immediately be Reed out by the majority by G nodes which would mean the the small clients would be punished by a buck that um yeah that sits inside the

the majority client G right and what I actually tried to experiment with was Snappy compression so I looked into how Snappy compression works and basically until that point I think most of the people assumed that the max siiz block is calculated by simply taking the gas limit and dividing it by the call data cost of nonzero bytes again nonzero bytes just because they can be compressed um not that well and zero bytes are much better to compress the thing is it's it's actually it actually looks like this if you want to build a Max siiz block then you should Reserve 71% of the gas for nonzero bites but and then add

29% of the gas for zero bytes and this then gives you kind of this line where you can see that exactly 29% zero bytes you can max out the the bytes you can include into a block while still making sure the snappy compression fails to compress and this is just because of uh of some very sub suboptimal compression that Snappy compression does and finally let me quickly talk about some proposals that want to limit the POS um the max possible block size of today um in order to make some room for increasing the either the gas limit or adding more blobs to to the network

first EAP 7623 is currently considered for inclusion for pectra um EAP 7623 called increased call data cost cost introduces this floor price for call data looks like this and it basically very simplified it it does the following 99% of the transactions use the evm nowadays right so all the pure data availability transactions they moved towards using blops and only 1% of the transactions are still call data transaction quote unquote so they would be not affected um 99% of the transactions all those transactions that

still use the evm would kind of be in the upper part of or in the first side on of this Max condition formula and only 1% of the transactions that are still relying on ethereum layer one for data availability would be in the yeah in the second part in the lower part in this um chart and would and and it would that mean that they would pay not 416 so four gas and 16 gas for the for their call data but they would then pay um it would they would then be 10 and 40 so we would just increase the call data cost for those transaction that rely on data

availability and cannot move to blobs yeah as said it would reduce the maximum possible block size which is super nice so we diffuse this dos Vector 99% of the transactions are unaffected and it's basically only the data availability users that are impacted by this and of and they can move towards block for most of the times anyway finally a very new a proposed by vitalic a few days ago 7706 which proposes to do multi-dimensional um resource pricing just as as we do with blobs already vitalic proposed to move even further and do multi-dimensional gas pricing for

call data the goal is again prevent Big Blocks the problem is is or it's not really a problem but the challenge is here it's a little more complex than just increasing the call data cost so it requires a new transaction type which means we make we need to make sure that it's backwards compatible we already saw with 1559 how hard it is for wallets to implement um new transaction types which might be the same here so this EOP is definitely I would say much closer to the endgame solution than 7623 but it just require some additional analyses right um this is basically everything I've just put some link here

so you can see there's a lot of analyzis on Big Blocks on E research if you Google for 762 if you just look for 7623 which is the EAP number on E reset maybe you add EAP 7623 I'm actually not sure but then you should find all the analyzes um done so far on the topic and yeah that's basically it thank [Applause] you thank you Anon uh any questions please thanks for the talk uh so if Builders are excluding transactions because they are big isn't that clear

evidence that call data is mispriced and if your answer is yes then do you think that with 7623 they would be able to drop such rules that's a good question I would I would definitely agree that call data is mispriced I would say call data is too cheap so last time we the last EAP is it it um I I'm actually not sure when it happened it's definitely um before probably two years 3 years four years ago even even maybe even more years ago when call data was decreased to the prices we have today to 416 and builders are yeah if you if you would now

increase the call data cost of course then we would create more incentives for Builder to again include those transactions I think the question is then more how much do you would would you have to pay the in priority fees because the Builder is just afraid to lose all the Arbitrage opportunities which he cannot revert anymore so for example there are Builders doing centralized exchange decentralized exchange Arbitrage so for the Builder it would be very bad if the centralized exchange Arbitrage transaction works and it goes through but then suddenly his block is reok where the other side of the Arbitrage sits in so Builders would kind of never have a real incentive to include those big transactions in um

only if you really outp pay their Arbitrage profits I think what was the second part of the question ah if 7623 can help there um I think 7623 makes it just um less dangerous so I would say 7623 just make sure that we will not see those 3.5 megabyte blocks um I would say those really maximum size blocks they have no real use case except for being used as as a Dos as a Dos attack and just as an example uh for example starnet they are still posting later um data down to L1 using call data because they use that call data within the evm so they need to

do star clarification and their transactions are around 90 kilobytes a maximum of 100 kilobytes and this might be also a reason because might be also based on um considerations of Builders not including their even bigger transactions any other questions um you had this nice um graph with that compared the two block sizes with RoR probabilities or the other way around um do you know to which extent this is or

the ROK is caused by just propagation because or longer prop propagation because longer bigger size on um compared to like execution that the execution takes longer yeah this is a super good question no I don't know um maybe bigger blocks just contain more computation right that would be the argument and then if you contain if it contains more um computation it also takes longer but I think um there is definitely a a relation between Big Blocks and the a higher probability of getting roked and the thing is those Big Blocks they always have um cascading effects for example if I'm a

validator and I receive a very big block from the Builder I I just sign the header and then the block is propagated then the block takes longer to be downloaded by all the other attests and then attest to it the next thing is let's say my block is not reor and my block makes it onchain then the next proposer might have a harder time deciding should I build on top of this of my block or should I try to re that block out right because also this proposer saw that block later this proposer also saw this block only received let's say 50% of the attestations and is not very strong and then you it's not only the the validator that proposed the big block but also the

next proposer might have some troubles and this is then this cascading effect that we can see in the network if one block is reared out then the next block might also struggle in determining which is the right block to build um on top of but coming back to the question I agree so it's this chart doesn't make it very clear to or doesn't reason very well about the fundamental the very underlying problem there it's just a comparison where one can quite nice see that those block that were eventually reared out are also on average um I would say quite significantly bigger

so if a builder excludes a transaction that's big why are they included blob transactions today if they are so so cheap and so expensive in terms of size yeah that's a super good question and it's actually if you look at the Builders of today so I'm actually currently writing um some analysis on that and Builders are already discriminating blobs not every Builder some Builders are just applying to theet to the rules but there is a builder I will not call him out now but one of the very big Builders you just have to look at the stats is including less blocks than the so the largest Builder includes less blocks than the second largest

Builder which shouldn't be the case on average so Builders are already pointing um at each other like oh have you seen this Builder does include so less blocks is he maybe playing um with with propagation time with latency and that I think it's a big problem that is is already happening today Builders not including blobs because they don't make money from them and it only increases their risk of their own nice juicy block being Reed out we do picks to the rescue right yeah yeah thank you for the amazing uh presentation