EVM Resource Pricing Breakout #5

Transcript

I think we can start. Um people may trickle in a little bit more but uh we have all the main interested parties. Yeah. So uh we can start with a couple of updates. Yeah. So the focus is um we discussed with Angar before the call and um we wanted to like maybe focus a little bit more towards like getting ready for Glamsterdam like some of these changes that we've worked on and like discussed. um maybe see uh how we can like um kind of use this call and this working group to like organize ourselves a little bit more so that we have a little bit lead time and we make sure that like these changes are ready for

Amsterdam. Um so we can start with a couple of updates uh and then Asgar also can lead a more in-depth discussion on this point. Um yeah so maybe if uh Marin wanted to start like um he wanted to give an updates on PerfNet. Um yeah I think he gave a very nice presentation at the research call previously but a lot has happened since then including the interop progress. So yeah I'm excited about this. Uh hi do do you hear me?

Yes. Yes. Uh okay. Uh so uh a few words about uh our uh findings in uh in perfet project. So uh as probably no one is surprised modx is our uh bottleneck of the in the whole ethereum. So uh right now we have the the worst client performing at only uh 11 megags per second. Uh and uh uh what we can say here like if we want to push uh gas limit to 60 million before Fusaka uh then uh all clients

espec es especially Argon and G uh would need to improve significantly uh performance otherwise uh we can do it and uh on Fusaka uh we will reprise the modex and the target is to go for 100 million uh gas limit. Uh so we need to perform at at least 53 megs per second and even after repricing uh and g are not there yet. So we have two options or actually three. One is to improve performance in clients if it's

it is possible. Second is to increase uh modex pricing even more. Uh and we can do both as well. Uh so uh but uh achieving this uh level of 33 megapas per second is uh not enough as modex will still be a bottleneck. So uh we need to reprise it wisely and think a few steps ahead. And uh I would like to uh to present like some analyszis of uh of uh next next steps and next bottlenecks. So uh if we

exclude modex uh then our bottlenecks looks like this. So uh even without modex we are not part of the uh 100 million gas limit requirement yet. three client three clients out of five are but neither mind and bezel need to improve a bit. So for bezo uh to to achieve 33 megabits per second uh there is a need to optimize EC and EC recover and for nether mind uh we need to improve eol uh and uh there are no other uh blockers between

100 and 120 millions. So after doing this small optimizations which should be possible because of other clients are performing better in this uh compiles uh it we should be able to to move uh of course if we only take into consideration the computing like not state etc. So focusing only on computing we should be able to go to even 120. But what are the bottlenecks then? As we said for basel never mind is is easy recover and eimol. uh for other clients gref and argon if you uh look at uh

worst cases easy recover easy add more so we have uh like uh bottlenecks on the protocol level not only client specific uh let let's take a look on them one by one so the fastest clients uh on ECAT are gender performing at 58 megastas per second uh needs to uh improve significantly and for nethermind and ref it seems reasonable uh to to point it in in having like 50 megabits per second performance it doesn't seem like impossible to to improve it

is faster than sogon is outperforming other clients uh by a lot and uh it should be quite easy for everyone to achieve at least 50 easy pairing uh nether mind and ref need to improve but generally it looks fast and doesn't even need repricing based on this data maybe we don't uh have uh maybe we need better test cases but basing on on this what we have it doesn't need repricing and recover it's the biggest bottleneck except uh um modex. So the best client is performing

at 58 uh and uh it will be probably challenging to for every client to go to at least 50 but might be possible. So as a summary uh after Fusaka if we repric ModX to not be the bottleneck anymore then we should uh be able to go to 120 megastas and uh it's reasonable uh to [Music] it's probably to able to to go even to 150 mega gas permit without repricing more things. And for sure we will not go further than 170 because it's like the

the fastest clients are performing at this level. So uh we probably need to answer some questions at this point. uh maybe uh the level of uh 120 or 150 uh mega gas mega gas limit is enough or we need to go further I don't know uh are computations a bottleneck at this level or there are other limitations probably uh it's uh it will be stayed at this point um do we really need more gas limit and uh are Apex like uh

multi-dimensional gas metering which is a brilliant brilliant idea and uh will be presented later today uh is it coming uh to the Ethereum if it is then like it will change the the way how we think about limiting blocks so probably further analysis doesn't have sense but uh if we are talking about modex repricing and looking for the best way to to do it then we need to consider uh other steps. So what will happen if we will repric ECU and EC pairing and easy recover what is the next bottleneck? So next uh looks like uh we can target even at 200

uh million limit uh free clients are ready for it and uh let's take a look at them. So uh uh g is ready for 200 and for 250 uh needs to optimize only black uh pre-ompile. Argon is also ready for 200 and for 250 needs to optimize black kac and some client specific op codes. Uh in ref it's only black uh recompile and in bezel it's blank and uh some op codes and I'm not 100% sure that we are

testing bezel uh correct way we added warm up uh but uh uh I I think that uh this uh numbers would be a bit higher for bezos. So uh I'm not uh sure that it is accurate. So uh uh let's take a look one by one at at this uh new new uh bottlenecks. So Blake Blake all clients should be able to achieve uh 66 megabits per second. Katak is even faster.

So uh we should be able to to achieve 200 million casing maybe even 220 and for sure not more than 265 because fastest clients are performing at this level and even 250 will be extremely challenging. So one last step in the future. What if we reprise also black and ketak then uh ref and nethermind is already on the moon. G is starting to the moon uh ready for 300 million gas limit and uh we need to take a closer look at and be but first gaff. So only already ready for

300 million. Uh only two op codes to be optimized for 400 million and for more to 500 million seems like 500 million is achievable. uh in Aragon uh two op codes to be optimized for 250 million and a few more for 300. And in Bezu uh there are like 10 op codes to be optimized for 250 and six more for uh 300 but again I'm not sure if we are testing bezel correctly. Maybe warm up is still not uh not good enough.

Uh so coming back to modex because this is my main focus in this uh presentation right now it's performing at 11 megabas per second so 36 million feels safe but even 45 isn't comfortable before fusaka uh if argon and g optimize then we can go for 60 million if not we can do nothing in fusaka we repric modex and after fusaka 120 million uh will be uh achieved with only small improvements in basmite and potentially 150 seems realistically achievable without other

uh potential next steps would be to repric EC recover and eol uh uh if we will potentially do it in glster then we will be able to go to 200 million and maybe 220. And as a last step, uh if we replace Blake and Katak, then some clients are ready for 500. And 250 to 300 remains realistic uh because there are like uh probably too many blockers at this uh in this area to to go further.

So we want to repric modex and after Usaka the next bottleneck except ModX will be performing at 40 to 50 megabits per second up to 58. So we shouldn't aim uh we shouldn't expect ModX to perform slower like we don't want it to to be a bottleneck after Fusaka. So it's abs absolutely uh minimal requirement for us to to replace modex to perform at 50 55 megabits per second. Uh if we want uh to not have modex as as a bottleneck after

next pricings potential next pricing then we need to aim in uh range 66 to 73. So probably we want modex at 75 plus and if we consider black and category pricing then we need to aim in 100 megs and more. Uh so uh it looks uh like that on this graph. Uh 100 million uh is not realistic with current shape of AP 783 because like no one is achieving the speed. uh 75 megabas per second uh looks achievable but it will require uh improving uh in argon and GF uh being

three times faster which probably uh will be extremely challenging or impossible and even the level of of 55 is is far away. So why uh current pricing uh is like that in HS 7883? So it's focused mostly on on addressing edge case scenarios. Three out of out of four changes uh made to modex pricing are affecting only 0.3% of historical modex calls uh but addressing like worst case scenarios. uh fourth change is bumping mean price from 200 to 500 and has wider effect but all the changes are affecting about 38% of

modex calls according to Tan's report which is linked here I I will paste it on the chat later and uh we even already know affected addresses so uh impact of this AP in current shape is relatively small while pushing performance bottleneck much it's pushing from 11 to 26 six. So a few times uh but there are no more edge cases to cover. What we can do now if we want to to have modex performing faster is to add general cost increase but then it will affect 100% of usages instead of just 38. So uh what we can do potential change is like at the very end of modex

pricing equation result is divided by three. So we can achieve significant cost increase by changing the v var variable from three to two or by not dividing it at all. So in variant one if we divide by two instead of three the cost will be higher by 50%. We will move worst case from 26 to about 39 megabas per second. 100% of MODX calls would be affected and and uh performance still uh wouldn't be fast enough. So not a good option. In variant two uh we will not divide the result at the end at all. So price will be tripled. Uh

current worst case uh will be moved from 26 to about 78. 100% of modex calls would be affected. Yes. And price will be increased by 200%. So so tripled uh after uh such increase uh we could potent potentially revert the previous changes but probably not worth it. Uh as it will uh require additional testing and uh uh it's covering only worst cases without any impact or common reward use cases. So uh so in my opinion if we want to to modify this a a we just need to

add one more change and don't touch uh the previous ones. Uh yeah, so at the at the end we need to answer the question uh do we want to make modex significantly faster for our clients but for the cost of affecting 100% uh of users and calls and tripling the price or maybe we want to make changes as small as possible. So currently only 38% of calls are affected but it will require hard optimizations from graph and probably bezel. So uh if you want to be at at the level of 75 meggaas per second so ready for 200 million uh gas limit and more uh there

are two options we can triple the price and then G and will be there or they need to triple the performance which will be extremely challenging. Uh so that's the open question at the end uh what we want to do. So in my opinion, let's try to optimize modex in GE and argon and in the meantime I will prepare a PR PR draft to triple modex pricing and we will need to decide what to do next. Are there any questions?

Yeah, K. Uh yeah, I have a few questions. Um, is ModX bad for a particular range of input sizes or is it just across the board? Uh, can you repeat? Uh, is ModX bad for a particular range of input sizes? uh it was but uh the the worst cases like edge cases are already addressed and right now uh it's uh we can consider like the common cases which are on network as as the worst

cases or close to worst cases. So uh like there is uh nothing to optimize. We can only change general pricing of it. Uh oh, I was saying that for the is it bad for like 256 bits uh input or is it bad for all of the ranges? like if you was to repric it from what we have uh it's performing similar for uh for or valid ranges it's already like narrow narrowed down a lot because uh if let's say base and modulo is in common cases it's almost always 22

bytes and that's our current worst cases if it's smaller than 32 bytes we are pricing it as 32 bytes. So uh uh there is uh no way to explore it uh by using small basin modula and if it's higher than 52 bytes then we are uh doubling the this part of of equations like so so uh price is uh uh doubled uh so it's also not anymore uh a worst case and for exponent uh above 220 26

uh bits uh uh price is doubled and uh at exactly 32 bytes based modulo and 256 exponent we have edgress for that uh and uh I I would need to check but uh it's probably one of the the worst cases. Okay, I see. Uh, and if you was to repric ModX 3x, do you know how many um contracts would be affected? Like is it used a lot?

Yeah, it will affect every every modex call. So, so um a lot a lot of them all the contracts would be would be affected like it is why uh in the initial like in the current shape of this I aper uh we did it this way to affect uh as small uh actors as possible. uh but uh seems like just this increase uh seems not be enough and if we want to go further then there is like no more edge cases to cover and if we change the general pricing then everyone is affected.

Okay, I see. Um yeah, I had two other questions but I don't want to hook the time. Well, I see no one else has their hands up. Uh Freddy EC add Marlin pairings. Um, is this because most uh clients are using a very old library? Um, I think it's the MTO Labs uh library from like six or something years ago. Seems there is no answer, but maybe plausible.

Oh, Bezu is not using that one. Louis saying so. Uh actually I think guest and um um and like they are using some old closed player library. I have like done some benchmarks like if we if you would replace uh the implementation with crypto and like it gives like approximately three four times faster uh easy pairing and decimal. So I I can share the the spreadsheet for that. I think G uses Ganok right now or at least they recently switched to it. I think so for PLS2 381 but not for PJ 54 I think.

Okay. Yeah. Cool. Um Kev it seems that if there there is any other question maybe you can ask in the group. It seems like a kind of important discussion and yeah we can move um to Yask who also has an update on the repricing EIP. Oh Asgar has something to say. Yeah. Yeah. Just just a very quick comment. I'll put it in chat. I just wanted to make sure that people are aware in general we should keep in mind that basically the way we approach these pricing or these basic benchmarking pricing um considerations before glumadam and after glum dam will be very very different. So before gamadam we kind of in this world now where all the

different op codes and and and pre-ompiles are differently fast on per per gas basically on all the clients and so basically we just now always constantly chase the next bottleneck and remove the next bottleneck and the next bottleneck and try to repric and whatnot and there's always one specific bottleneck and then in glamadam the idea at least is and we can talk about it a bit later in the section properly but the idea would be that we basically make it so that all of the computer operations cost the same per kind of time that they take at least at least at the fork and then of course over time then um start things will diverge again but basically that means that after that fork we will no longer be in the mode of like tackling the next specific bottleneck because all of them will kind

of be equally good or equally bad. So then it will be much more a loop of figuring out where we can push more where we can basically make things faster so that we can make them cheaper again afterwards. So just wanted to as a general kind of comment of like we should realize that what we're doing right now this kind of effort is more like a until glam dump kind of process. That's all. Yeah, makes sense. And then maybe after Yas we can like discuss uh more on this approach and like what's the priority for um yeah um okay guys uh can you see my screen? I hope you can.

Yeah. Um so uh what uh Martin showed was the the scenario if we increase a gas limit with uh especially with the focus on uh uh keeping um uh pre-ompiles safe in terms by compute uh uh enough uh the computation is enough uh to increase the gas limit. Now, uh as a reminder, this uh um EIP comes from a slightly different angle and basically says um what what if rather than increasing a gas limit, we all lower uh computational uh cost of uh well the cost of uh uh

certain op codes. Uh so uh this is specifically focus on op codes plus some uh um pre-o compiles and uh we're not touching mod x because matching eip is much better in uh replacing mod x but we do touch in this EIP uh let me just scroll down um an EC pairing uh the main uh problem with lowering cost of EC pairing as per This uh schema here was uh exactly the performance of uh GE and uh Ericon. Uh but uh as Evo has me mentioned before uh that is a

GNAR uh library uh right here which is provided here we measured it and confirmed this is about four to even five times faster in the worst cases than the existing library used by uh uh G and Ericon. So that removes the bottleneck of lowering cost of ECINK. again in this schema when we lower cost of uh most of the op codes. Um uh and uh as Ansgard mentioned before uh this EIP aims to rebalance the computational cost uh across everything. So the same a unit of

computation will cause the same gas uh in theory because in practice um uh clients differ between uh each other. Uh on matching uh page slides you could already see the difference between clients. Unfortunately I didn't have time to prepare the my take on this. It's not different from malin but as soon as I prepare it I will post it to the group. Um but in the meantime I can show you some uh more in uh another interesting slides what we did on the new pre- compiles. So BLS uh 12 and for the BSL uh 12 we have uh what

seven new pre-ompiles which we measured using the same uh method and uh let's me just state uh jump slate to the conclusions uh and we according to our measurement uh the the gas proposed in the EIP is surprisingly acculate and all our uh measurements actually confirm that with one exception that we might want to lower uh mapping for uh G2 but it's a minor thing. Now having said so I need to go a little bit deeper into details because there's an

uh interesting case of uh MS uh multiplication G1 and G2 multiplication uh which um let me just show you this uh here. So the red uh line is the nominal gas cost what we want to uh charge. The blue lines is the uh actual measured gas cost. So as you can see for EVM1 this matches almost uh exactly as if uh uh the gas schema schedule was made for EVM1. Uh if we oh it jumped around if we

go to Bessu for example we see some variation here but it's not as much different as you would expect. Um uh oh I didn't mention that um uh the x uh axis is the number of pairs uh that uh I'll use for the multiplication in a single core. yeah, you've muted yourself, I think. Oh, sorry. Um uh what was the last time last thing you had miss saying

number number of pairs uh the xaxis? So a number of pass on the x-axxis it looks good for the so the red lines cover the blue lines for the bassu evm1 and if we scroll to the things where it doesn't look nice for example uh rev we can see that uh what we expect as a gas cost uh differs quite a lot especially in a low uh number of uh K pass it's not a huge problem but uh it might be um an issue if you look uh if you've considered some kind of vector attack on

the network. So here's another uh diagram that as you I want to show you uh bear with me for a moment um and let me explain to you. So the numbers on on the y uh axis shows you uh how much the actual computation is was than uh gas cost that we charge uh for uh uh that specific uh pre-ompile. So uh we can see that uh in this ga in this case for them it's fine. It's almost one for anything uh larger than 32, but for

the pearls lower than 32, it might be up to eight times more uh costly to execute it. Um it's not a huge issue in terms of security because those pre-ompiles are expensive anyway and the possible vector of attack um uh is quite low if uh non-existing really. But uh interesting to see that there are actually differences between uh implementations sometimes uh quite uh um substantial as uh as per this case here of Lev. And um and going back to Angard uh note

about having the same gas cost per computational unit. Um as we as we see here clients differ between uh each other. but in general uh we we can confirm uh BLS12 is uh safe to be implemented good to go and the pricing is uh uh actually uh very accurate. Okay. Um any questions?

Thanks Yas. Uh maybe we can segue. Is there any direct question? Uh Kev asked if it's safe even at uh 100. No, it's safe at the moment. So uh 45 or whatever is uh the current limit. If we go to 100, I'm afraid it won't be that much safe anymore. Yeah. Okay. Yeah. I had a question relating to like um maybe like how um do people feel about like such a change for change for Glamsterdam like we haven't done like such a big rebalancing of prices before but maybe this we can

segue into like um Asgar um section because I know he wants to talk about um this thing as well. One sec. I have small technical difficulties. If you give me 30 more seconds. Yep. And then in the meantime, so we are um u taking more time than I was expecting. So there was going to be another presentation from Maria on this new like multi-dimensional gas metering um proposal that we have um which I think is quite interesting for this discussion. But um if um we probably

won't have enough time so maybe we can go on with the discussion and then we move this presentation to the next time so we also have enough time to discuss and to address all the question but yeah let's see after uh answer section terminates. Yeah. Yeah. Could maybe there's someone else I'll put post put the link to I just had two slides literally in my presentation. If someone else could maybe share their screen. Um, yeah, I can try to present this. Yeah, sorry about that.

No worries. No worries. Perfect. Um, yeah, if you could full um, yeah. Um, so, so, so basically, I'm not sure if maybe it's easier to read if you go slideshow. Um yeah, perfect. So basically like the the idea is just I wanted to briefly like talk about Gamsaddam. Um it's not super well prepared. Just just a few thoughts here basically. Uh um and so basically um just just for general context this is just my best guesstimate in terms of governance process for Ethereum. But like I think we have roughly two

guaranteed months for for EIP proposals for for for the Glumpsum process. um there's a good chance that there's still going to be some more time after that but basically um at that point it will already be oh this is coming late into the process maybe we can't fit it in anymore or these kind of things whereas like anything that wants to be properly considered basically will have to be proposed within the next roughly plus minus two two months I would say um and then there would that that would just be the general kind of EIP and then we there would definitely be more time than that for for finalizing any parameters that come come with an EIP but just to give us like a general idea of the timelines here So I think it's already like urgent enough that we should start to really have a concrete plan of like

what are the features we we want to see in Glamster here from the pricing side because it's not that much time. Um and so I yeah I just wanted to briefly like run through the different categories here. Um, so the first first one basically just is like kind of what Jessica already was talking about just now in terms of compute, but basically the general category of I think we really want to ideally not all that has to be in Glamad, but ideally we really want to get to a place where for all of the three major resource types that is compute, that is state um access and that is data. we really homogenize all different types of operations that touch that specific resource so that they all cost the same per amount of effort that they cause, right? So that means for

compute it's just the amount of time and that should be basically like the per second cost should always be the same in terms of gas no matter what kind of compute you use. Um and for compute we are the farthest along. I think we have a good chance of like just EIP basically um being ready and being be be being agreed uh for for Glamadam. I I am a bit worried that as of today we are not necessarily in a in a place that we will have the same true about the other two. we're just as unfortunate because as we want as we need to like this a little bit like already the next point but as we need to basically repric these different uh dimensions relative to each other basically if we have a dimension like state where basically things are

still very much mispriced the different type different ways you can you can you can basically cause stress in terms of loads and reads and rights and whatnot. That just means that we basically have to make everything much more expensive so that we can basically create more headroom for scaling. um whereas if we if we homogenize everything first then we basically only have to have to um repric to the extent necessary. So so basically like one point I want to make is that as of today we are not yet on a track where we will have state repricing ready because no one is yet working on it deeply um for glam. So if we if we think we would want to have a first batch of of of changes um for state ready as well we would really need to very soon start to think hard about like

what what even are we tracking here? what other different way things we we were trying to benchmark. Um, obviously state is just more complex because it's it's not as pure as as compute. Um, but just wanted to flag this maybe in the at the end we can have a quick discussion about like what how we think about this but but yeah I I I really am worried that as of as of right now we're not necessarily on on track to to change anything in dumpster there. Um then uh the third one obviously is uh data. Data is in a way um less problematic. uh it's it's a bit simpler. You don't actually have to do any any benchmarking. Um also David, there's some switching back and forth between the the presentation and emails. I don't know. Um anyway, um in terms of uh data, it's really just about

like making sure that that in principle we we don't have any big oversightes. Um uh yeah, in in in terms of what what contributes to the to basically like the the worst case size of a block. Um um yeah and then the question is just am I overlooking anything by by by even categorizing it in compute state and data. These are usually the three that come up the most but there's of course also like memory and and kind of related questions. So like if if there's anything else kind of urgent that that we also want to track then yeah that that we also need to need need to pay attention to. Um and then this is another major one. Um we probably also really want to like make a change in that changes the relative pricing. So basically like um

also not only look at like that all the different ways to access state are priced according to how much actual time they take for example but also specifically um want to make sure that like how much headroom do we have for for example for data or for state versus for compute and and basically that a a block that only uses compute has the same kind of worst case load as a block that only uses a lot of state or access a lot of data. Um the big problem there is that um with compute we can probably kind of make these changes without many big backwards compatibility questions because most of that is just making things cheaper. Um as we start really changing the ratio

between resources though we we will we will not get around having to just make big changes to pricing that that will potentially impact existing contracts. And so I think we pretty urgently if if any of this is supposed to be in Glamadam then we really urgently need to start having a strategy for like how how we even think about um backwards compatibility and like how how to even analyze mainet for contracts that could potentially break as things become more expensive this kind of thing. Um obviously like a lot of these are kind of weird edge cases because in principle you're not supposed to hardcode hardcode gas limits for for subcodes and whatnot but of course that sometimes in some cases happens. So we really need to have a strategy for this. Um and also why is this even so urgent for glums? Well

because in glam specific specifically with these two headline features that are in discussion right now EPBS/ delayed execution and block lab access lists the relative amount of available resources for all of these three categories will change quite a bit. And if you briefly want to go to the other slide um David um just I was just trying I'm not sure how how correct this is. This is just a sketch of like trying to map out like how does do these two features potentially change like affect all of these dimensions just so you get a feeling for like why does the relative availability of these kind of ch change maybe and so like if you look at EPBS right so basically there's two things you will have a longer window for propagation of the of the payload which just means you can have more data uh bas

right so basically you you could um well either make call data cheaper or we just basically now have more time more way to basically raise the gas limit before data becomes a problem again. Um and then on execute but but EPBS also gives you more room for execution. But interestingly enough now it's a different window like today basically like it kind of doesn't matter. You you can split your time equally between downloading and or executing. You have to be ready by by 4 seconds into the slot right for stations. But with EPBS you would have a different deadline or late execution you would have a different deadline for just having received and verified that you have the payload and having fully executed it. So that means that now you have like this specific extra headroom just for execution that you could not otherwise use for data. So that's the first that's

basically some some a way in which compute basically now could explicitly be cheaper than data because because you have more time for that right. Um and so and and not only compute but also because you have more time for execution it also means more more state access. So in a way data should now in relative terms become more expensive because there's like a tighter constraint on data than than there is on execution rel relative to to what we have before but but all of these these dimensions we have more room now in absolute terms. Um and then block lab's list is even more messy in a sense because it has many different kind of ways in which it impacts performance. I'm again not even sure that this is quite conclusive or like even the right way of approaching it. The way I think about it is like

there's these two different sides of buglab access lists. There's the at least in the current proposal there's the read locations just the locations not the values. What that allows you is you can basically just at the very start of the block already start loading all the values you you that will be accessed during during the block execution. Um two two nice things. One you you basically you can you can start loading them all at the very beginning. you don't have to wait until they are actually hit and you can load them in parallel um which which gives you extra performance uh versus sequentially. So overall just means you will be able to have more state reads specifically but right not not not rights just reads. So that that specific only gives you more reads. Um and then with um um the other the other proposed part of box list is

this is the state. So basically like um you typed out again um noise. Um yeah, sorry for conquering your device here. Um uh uh the the other um uh big one is basically like the the right locations and the values and that basically impacts um the ability gives us the ability to parallelize transaction execution. So it gives us more compute and it also impacts uh state this time because it actually like lets you start uh computing the post execution post block state route at the very top of the of the block already. Um which which also allows you in principle gives us more time more ability to to allow for more writes make rights

cheaper. Um uh the one way in which actually like ble accesses make things worse though is that the that basically now has this extra sidecar to the block which now couples state and data in in a way. So meaning meaning that like every state access now also increases the data size of a block because that value has then to be written into the the access list by the by the minor afterwards by by the by by the by the um block producer. Um and that actually means um that is a counteracting force. So basically like all of these will give us more state access. This actually now gives us state less state access again and we would have to actually like benchmark exactly like where that net or net comes out on um basically just just just again giving you the intuition that

basically like any repricings that we we we want to do and that are that are not just like like that this none of this affects Yasx work, right? Like the the the just making sure that all the different types of compute are homogenized in their price that that is valid either way. But like if we think about how expensive should compute in general be compared to state access like this basically we have to take we have to make sure that we base it on the actual version of Ethereum that will be live in glammadam. So I just want to give you like a feeling for how complex all of this is, but also how if we do not make any relative repricing at all in Lamster, then we actually are in a pretty bad place because then we actually created a lot of extra headroom

for some specific type of consumption, but we can't actually make use of it because now we will be blocked by some bottlenecks of exactly the the the types of resources that we could not make cheaper. So um and and especially like the state side of this is actually quite messy because it's affected in all these different ways. So basically just if we can go back to the other slide. Um, so B basically just wanted to highlight that like there's it's a pretty complex topic and I just think that we kind of at least in terms of like the kinds of general proposals for Glamadam, we probably need to have them out in two maybe I don't know maybe there's a bit more headroom there but like kind of in the next few months and I feel like right now the main one that we will get

is the state repric sorry the compute repricing but I think on these on all these other fronts ideally we should at least some of those we should also kind of get ready for glamadam and um yeah just wanted to highlight basically that problem. Um, just to briefly mention other potential pricing features that's really much more optional in case that's possible. Um, one idea what just to make actually sure that like data and blobs count against the same kind of cap of data. Of course, blobs should have a discount factor because you only need to sample them. You don't have to fully download them, but but basically the idea could be that they actually get to move basically like call data into this blob blob um gas uh limit. And then the other one is this multi-dimensional metering proposal that I'm not sure we'll have time to actually talk about

today. Um but basically that's also a really interesting new proposal by um Maria and Davidida. Um and actually like the multi-dimensional metering would also allow us to have more general targeted caps. So already in Fusaka we will have the um the the total size cap on onto on a block. But but size is really the only thing you can cap today because size is something you can statically analyze. everything else is a runtime value. So in order to have a cap on a runtime like the total amount of I don't know ketchups in a block or whatever if we wanted to have such a cap somewhere um that actually requires as a as a as a prerequisite multi-dimensional metering because you first have to track that specific operation separately from

everything else before you can cap it. So only if you were to decide to ship multi-dimensional metering in gums would would more types of caps even be a potential option. And then the last thing I think Sophia also mentioned it in chat earlier was the idea of potentially already already um having ZKVM aware pricing in Gabam as well. So again, all this just I and and ideally if we have a few minutes to discuss this briefly, I'd be really curious of people's stakes like where do you agree in terms of urgency of things we should ideally try to get into glums and is there maybe some activity that I'm not yet aware of or like how do we how could we try to like coordinate on making progress on this um pre-lamadum? Yeah, that's kind of all from my side.

Yeah, we have eight minutes. So I think uh um yeah maybe to your second uh point um yeah I'm also curious like whether there is any work that we started already that any team started on like benchmarking for state not just for compute. Yeah. So actually in principle I think my understanding is that Guom's team is ramping up to start doing that that kind of work. Exactly. Um, I don't think they have so far been focused on like results that would immediately inform Glamsterdam decisions. Um, but they're definitely a team to to go talk to at least about this. Um,

I'm not actually sure what Gum's team is called. Something something I think it's it's the team that basically previously also worked on Burkel and statelessness and and and so on. Oh, yeah. stateless team makes sense. Yeah, Francis. Yeah. Um, quick question about like benchmarking state. Um, every client, maybe not every client, a lot of clients use different databases, etc., and have very different access patterns like how does this work of like benchmarking state?

Yeah. So this is why state is in general just harder. We kind of need to think harder about what it even means to benchmark. Um in principle you can just benchmark per client, right? It will just be that the results will just be vast much more different across clients because they make different choices. Um so it doesn't always mean that because on state like on compute whenever you have a client that's vastly slower than another client on a specific operation that's usually an indication that that client should increase their performance. on state. It can just be that like a client is just slower on a on a certain type of access pattern because it just that falls out of their different implementation choice and we might just not be able to do anything about it, but we still need to just track it. So, so I think we can

still like the types of the types of of of situations you benchmark would still be the same across all clients, right? Um it's just that the results will then look much more different. or or did did you have a different or do you think it's it even like Yeah. Are there other complications you see? Not other complications. It's just that kind of like it's really hard because everybody is like so different in these situations like unlike compute and stuff. So yeah, just curious like how like we are thinking about it. Um the the second thing I want to kind of like

maybe touch a little bit because uh you mentioned like about the priorities and stuff. Um I feel like you would be really great if we can like because we're already doing this like homogeneous like pricing thing. It would be really great to make things like really really configurable so that um potentially it can be adopted and L2s can price things differently uh based on their kind like different situations and stuff and just try to mention it and see if that will become a priority and if there's anything that we can potentially help like push that forward.

Yeah, that's a very good point. I think with a lot of these changes in general like we are now only now starting to get into the habit of thinking how does this relate to L2s. That's also why I put for example L2 extensibility for specifically this data pricing the data metering change because that would hopefully be something we can make easily extensible for AL2s to use because they have been asking for a way to separate out call data pricing from everything else for a long time now of course. Um, but yeah, there's also other questions of like exa exactly make make pricing more modular in general so that it's easier for L2s to actually just deviate from L1 pricing in general.

That's something that I think is a really really good long-term goal. And then the question is can we already make this first batch of changes be implemented in a way that allows for that or is that something that basically will take more time to to to find a strategy for? Yeah. And maybe one comment here. I think like um we had discussed a bit of this um like potentially having a standard config for this um pricing uh parameters at interop with Francis. We also talked to Mario from G. I think it's in his intuition was like a little bit pushing back saying that like at the moment like all these parameters are in the uh uh compiled code and then if you take them

out into like some config uh it would slow things down significantly. But uh it was just this intuition like we don't have like um uh any like analysis or like u um any like uh measurement of like uh how much slower it would actually be. So I think it would be like something interesting to explore potentially as well. Okay. So seems like the kind of like the thing that might need like uh investigating is like trying to do a PC maybe on rest and guess like some of the clients and see how hard it is to make it configurable and is there any like performance impacts etc.

Uh does that sound right? Yeah that's my understanding or what do you think so say again? Oh no no no. Uh just trying to say that it seems like the current blocker or unknown for making things configurable is mainly about okay we should probably like try to PC it in some of the clients EVM uh implementations and see if it makes things really hard for hard forks or like changing EVM or whatever or and if it makes a little bit difference on the performance side. So if there's no issues, it seems like we can do it potentially alongside with this.

I' I'd be curious. We have a lot of client devs on the call whether people have general comments on the physibility of making pricing either fully modular. I'm not sure if that's even a coherent thing to say because I think pricing is not just a table of values. There's also this logic that like some some operations have like some specific kind of pricing logic. So, I'm not sure how exactly you would make that fully modular, but basically like at least making it more modular, like how how feasible do people think that is or how easy it would would it be? Or maybe it's the kind of thing that we just have to to basically just like try as a pilot project basically to to take.

I could imagine that that's the kind of the part of the code that just many people don't have a strong opinion on because it hasn't been touched that much in the in the past. Yeah. Yeah. And yeah to respond to Francis I think that would be a really nice PC to have like and to answer point I mean the functions uh like those functions have parameters right like what we take out is the parameters themselves right like in the simplest implementation basically um you don't the function we can commit to them we don't need to modularize them right but yeah I mean depends like for example L2s also need the the the way to like handle data a little bit differently to begin with, right? So ideally modular a modular

pricing there would give them that flexibility as well. Okay. Okay. All right. So I think we need to wrap up but um yeah um uh we are overflowing with Maria's presentation on the multi-dimensional gas meeting. So I'll try to set the next call a bit like um earlier maybe um the week after next since I think next there is the uh research call at the same time. Uh yeah, so we can continue the discussion there and u uh I'll try to see if we can make progress on like um the with the stateless team if um maybe invite them um if

there and I think we will also like from the kind of the L1 scaling kind of um um track DF will kind of we'll keep working on this um quite a bit in the next few weeks. So if any anyone from outside the F that also is basically wants to collaborate on on these topics outside of just the the the compute homogenization because that one I think is already the most kind of specific. So any of the other topics there specifically state or something if you want to collaborate on that do reach out to Marius um or Tim or me um or or Davidida um specifically on pricing. I think um I think that that really makes u makes a lot of sense and then but also do do go and read Maria's and and and

David's work on on the multi-dimensional metering that's actually really nice work if I may say so thanksgar yeah we'll link it yeah Maria sent it we'll also send it to the group and then we can start with that one next time yeah and thanks everyone