EVM Resource Pricing Breakout #4

Transcript

Yeah. So I guess we can start. Um since Dan could not make it um I'm going to propose that um we start uh with Anskar he wanted to give um some thoughts on the E road map like especially focusing on Glsterdam and then um uh we can have a discussion from there. Uh and then there were a few minor things that people wanted to talk about. I know Yas may have a small update uh on his repricing. Um I also thought maybe it's worth to have a small discussion on the uh exponential gas limit uh increase proposal from Dunkrad.

So I think we can have those later as well. So today it was more discussion forum less presentation. Yeah. Uh, hey, I mean I I really just very basically briefly I also don't don't really have a presentation. I can I can maybe one sec if I share um share my screen I can just briefly. So we had the the research call um a few weeks ago um where we talked talked um mostly about other topics but I already gave gave a bit of a sneak peek of the of the second research call which will be next week actually and probably be quite interesting to attend for for people here. Um and just as like a

categorization of um of basically like this specific topic of um kind of execution throughput scaling and how that intersects with the road map and I just wanted to talk about like for 5 minutes right now just to set a little bit of the scene of like because obviously the the upcoming glam hack for hard will be the first fork where a lot of these this um repressing work and the other kind of work streams um will actually be able to go into the protocol. Um, and so basically, um, you know, that's kind of the the short-term execution layer box. And so within that, that was just that was just that the one slide and this is really the only slide I have. Basically, that's just the slide from the from that from that call from from a couple weeks ago. Um just to give you a rough idea basically um um so so

basically I think the wig glamadam will shape up is that um on the uh e side basically we will have some subset of these of these features and maybe one or two of the features that are not listed here but basically just features that help enable um higher execution throughput um and then on the CL side we'll we'll continue to do some more pas improvements and that will basically be Um and so in particular right like the the the most important candidates there to have in mind will be um delayed execution I think um and well block level access list and parallelization which more looks like it might just be

one combined feature because um if we actually do um access lists kind of on a transaction level then you can basically run uh transactions in parallel which is which is quite nice. So, so those are basically like the main kind of headliner um features that that are being prepared for for Glam Sadam. Um outside outside of kind of narrow pricing um now basically uh one big kind of deviation from how we've done this of course in the past and a lot of lot of people on the call here are already more on the engineering side anyway and and so basically probably that that's not news for you but obviously now now I think with these upcoming kind of scaling changes it's a lot less kind of

going through just the instrument of new features in in in hardfox and a lot more about just like performance performance engineering. So even before Glumsdam obviously now we're running these these performance dev nets or starting to to prepare to run them. Um so I think a lot of a lot of kind of like work on scaling will also just be about taking the existing protocol and just run it at a faster pace um with with with the gas limit as is. Um and so basically I think you should really think of it as these two pillars. So there's like the new features but then there's also just like take the existing thing and just make it run faster.

Um and and so then the basically the goal of the rep of of pricing to me basically is is to like to support both of these buckets. And so on the feature side like there's also just like separate features. So for example the the repricing we've talked in the past is mostly about uh increasing compute throughput right so basically basically just like harmonizing um how comput is priced. So right now basically some some things are too too expensive some things are too cheap just me metering them in real conditions and basically just repricing things relative to each other that just means that you can have somewhat higher compute throughput overall because you basically your worst cases get better right so that's in a way a scaling feature in itself that just makes compute scaling like this scales compute scaling by by by some

percent. um there's but but I think it's important that we basically like now that we are kind of working on repricing we're also preparing to support um the overall kind of like general scaling more and and in particular what I would say is if if we expect the chain in a year to run at maybe five times the speed that it runs today um then the question becomes like basically we will hit specific bottlenecks and like repricing will be one important tool in the toolbox to just like in the short-term uh deal with bottlenecks, right? So basically the way you deal with bottlenecks is you basically short-term just contain them and then long-term you you you remove them, right? Containing them can be very simple fixes. So for example with the um

the size of blocks that's one immediate limit that we are running into right now with the with the early devets. And so they are like very simple fixes even simpler than repricing just like for example a cap on maximum block size, right? Um there are some um some questions on the on the uh pricing side that we should look into. Meaning like how how low can you have the cap uh relative to the maximum that a block could be uh could have size before the fee market starts to break down, right? And like basically like how how carefully should you be with with a problematic fix like that. So that is a fee market question there. Um but of course you also like you you you can't limit every dimension in in in in simplest way as that. Sometimes what you

basically what you instead need to do is you need to just like make pragmatic short-term pricing changes of different dimensions relative to each other. So you might it might be that we like that we are realizing hey state access is the main bottleneck right now and everything else we could push farther but because of state access in the worst case block we can't push farther. You probably can't really introduce a cap of maximum state locations touched in a block or something that's that that would be very blunt mechanism. What you want to do instead would be to just like say double the cost of all of the state accesses, leave everything else the same, of course, make everything else cheaper, whatever, like same outcome. Um, and then keep pushing the gas limit, right?

So basically like the repricing there would have this uh role of short-term just getting rid of the bottleneck um so that you can can keep pushing there and then in the medium term of course we look into how can we overall just make state access more efficient both in terms of implementation but also in terms of protocol changes right so basically it's always this interplay of shortterm just contain the the problem so so we can push in the other um dimensions and then address it and basically then once it's addressed make it cheaper again and these kind of things. So that's what I assume the interplay will be in the future between um and these other scaling features. Um and then the one important aspect there and that's why like it's it's important

I think that we talk a little bit about Glam Sadam or just this general fork scheduling is just that we have this mismatch unfortunately where a lot of even even simple relative pricing changes if we want to make state accesses double like twice as expensive compared to everything else because it's the bottleneck just as an example right that has like a almost a year of lead time maybe six months if we get lucky with a with a hardwork timing but that's a very different lead time from a performance dev net. Right? So basically like anytime we run into this ideally we would want to understand what the bottlenecks are as early in the process as possible so we can make sure we address it. So for example I think one big question for the repricing effort today I think should be how can we say

we have another two months or so two three months to make decisions on what features go into glumadam. How can we within those three months understand what dimensions currently are the main bottlenecks for scaling and how can we basically like have repricing changes in glamadam if if we figure out that we need them that can unblock us there right and so how can we basically like play this game of of being of of relatively early on understanding what bottlenecks to get to to to like preemptively get rid of and there's not that much of a cost to getting it wrong if we make something more expensive it turns out we actually found other ways to addressing it or it's not the bottleneck after all that's fine then for a while it's just a bit too expensive on mainet if we get it wrong the other way around though that's just

we're just hard stuck right so if on in glam say we fail to make a specific dimension more expensive and that's just the main bottleneck and we don't have any fix for it we basically have to wait for the next hard until we can keep scaling the other one right so I think that's I would basically just that that's kind of the only message that I wanted my section basically it's just that like repricing is not just a self contain painted topic where we can play with like multi-dimensional gas and these ideas and maybe like this compute repricing it. I think we should also prepare to like have the pricing work be very actively supportive of the overall scaling efforts. That's kind of the only thing. Sorry I that I didn't have specific slides for this but but yeah I think this is great.

Do we want to like briefly I mean given that we don't really have any presentations today more like discussion we can do we want to have like a discussion on this specifically before we move on or yeah yeah yeah maybe I can start with one question in my mind like since um essentially now like this role of like uh uh repricing is kind of like uh becoming potentially more dynamic right we want to use it as a tool to like help with like uh potentially like performance bottlenecks etc. Like one thing that I was discussing with Dano offline was uh this idea about like having uh some sort of like standard config for like uh gas costs that that is kind of standard across multiple

client like um is this something that kind of could help uh given like the scenario you're sharing where like uh potentially like uh these updates to costs are much more frequent. Um and also maybe with shorter lead time. Yeah. So basically I I think that's like a really really good question. I don't know. I I I would defer to to to E clients and if we have any on the call maybe that would be a good question actually. I do think preparing for a world where we might want to change this more frequently and we're basically changing the gas cost is is a relatively like is a very very low effort thing to do in a hard and even to do it

relatively late into the hard planning cycle. I think that would be very valuable if there's a way we could go get to a world where we could even do it in between hard folks where it's some sort of onchain parameter or something that's probably unrealistic. But anyway, like I I would be curious about how how EL clients think about making it easier to change pricing in the future. So the um on the RE side um not exactly changing the actual costs but right now the RE team is working on some RPC methods for uh basically being able to provide um a list of costs per op code and then it reperforming traces that give you data on how much things would have costed in

a block or in a transaction. So if we are thinking about new price schedules, um this could be a source of good data for figuring out, okay, what would the effect of this price change actually have been um in historical blocks? And this is a naive question, but would would I be right in assuming that that would that work also would make it then easier to change pricing in general because you already have code paths that deal with dynamically different prices or something. I think I think that's a lot harder um because uh the way that the RPC methods are designed, they have like very segmented codebase that's like

for tracing and they can just add a bunch of stuff easily into the tracer. Um and they've been sort of developing that capability and my understanding is that's a pretty separate code path than the actual um use prices, but I'm I'm not sure. Okay. Okay. That's but that's good context. So basically the main value there what we're saying is would be in us being getting quicker at understanding what the impact would be of different prices. Yeah. So let's say we come up with like five different ideas for um possible price schedules. We could you know maybe within like less than a day get like a feedback loop of what the effect would have been with historical blocks.

I see that makes sense. How do we This is actually an interesting question. How does it intersect with like say if we if we run like a performance devet and we realize that I don't know we really struggle to move beyond 100 million gas or something and then it turns out okay but it's really just because we run all the different worst cases. Some blocks that are really heavy on compute some blocks that are really heavy on state access. And every time these really heavy state access blocks they just slow the network down so much we just can't go to 150 million. Um how do we get like what would it mean to get data on say if we make state access more expensive what kind of data would we want to inform us on whether that would have successfully resolved the problem?

Um well I mean if we use like real historical blocks that's probably less about the worst case and more about um the expected case or the mean case. And then if we do it on these performance test nets then that could inform the worst case. Um, and then I think the place it would be most revealing is if um there's maybe like a nonobvious um it it's not exactly obvious like which op codes or like the exact distribution of op codes were used and it's really expensive to trace every individual op code. So, we can just easily swap out a different pricing schedule and be like, okay, well, if we tweaked this, then would this worst case

be toned down significantly um without affecting the other cases that we care about. Makes sense. And then that is then I guess I guess still a separate question. But if if say we alternatively would want to just quick as quickly as possible just take just spin up an entire new devet that just uses a different pricing schedule. You're saying basically that would be more complicated because that's just separate completely separate from these tracing um code paths and also just overall a more involved change.

Yeah, I don't know. I I don't know exactly but I think like somebody mentioned creating a standard config for that. That sounds like a really good idea. Yeah, I think at least again I feel like it's unfortunately this is really more more of an engineering question. I feel out of my depth, but I I it feels like having a having a standard config would be very useful and I could imagine that also separately separate from the L1 use cases. I think also L2s would be very happy about basically that way it being easier for them to just run different schedules. Yeah, I can push the

conversation forward on this since we were already discussing with D as well. Um yeah, maybe like related to like the other thing um uh you were saying uh Ansgar like um about like uh the repricing effort for Glamsterdam, right? Uh yeah, one thing I was thinking is um so we have this proposal from uh YASK, right? Um but this is like essentially like uh this um very broad repricing right looking at like most op codes. Uh but you were starting to talk about oh uh maybe like uh we can have an effort where like

within the next two three months as we finalize changes for Gsterdam we um try to like identify priorities like maybe also one question for the group is like uh how do people feel about like uh uh the repricing proposal as is like versus like prioritizing uh specific um maybe a subset of op codes maybe Yas if you want to talk to this I'm sure you got kind of feedback and discussions on this already um yeah let uh let me just quickly demand what the proposal is if I can share my screen

uh uh yeah can you see it okay Great. Uh so uh the general pricing uh proposal looks at all the op codes, all the pre-ompiles and say uh why don't we start from scratch and base the gas cost on some evidence rather than um uh analysis of what the op code could be. Uh so uh and by having such an uh uh motivation to do it, we came up with uh a number of research and then with this proposal which simply says for most of

the simple op codes we want to uh change the price to the base cost which is one. And then for anything which is uh more complicated computationally complicated then we uh uh adequately increase that uh cost. Uh this proposal also simplifies some uh memory cost formula. Uh it makes the warm addresses cost uh cheaper and um and so on. So uh in essence the idea is very simple.

So we just uh replace everything starting from one. The effect on the network is moderately uh analyzed and we can we know more or less what we can expect. uh the effect of the um E teams how to implement it might be more complicated as as we said uh before we don't really know how easy it is for the client teams to have um uh a new gas schedule.

Um okay so uh that's uh uh uh reminder of what it is uh from some updates on this front uh we are doing um some what if analysis. So basically to show how this change will affect uh a most uh popular transactions so swaps transa uh transfers and so on. Um and uh few other uh analysis of that salt. Uh when it's ready, unfortunately, we're not ready yet, but when it's ready, we will show you though. Uh two uh questions uh well uh le uh about the

actual uh uh gas proposal. So in this uh proposal we uh aim to latically uh make easy pelling uh cheapo. Um now Julie B has laced uh quite lightly an issue that uh most of the implementations are very uh well written uh performant and this reflects what most implementations uh are actually spending time on but two implementations namely GE and Ediggon which use the same

uh ECING implementations are definitely standing out. So, and much worse than uh than the list of uh clients. So, around five times uh was and the question that we have do we aim at the worst case scenario or at the typical scenarios? I I summarize it in the in here. Maybe I make it slightly bigger. But if we have such a discrepancy between client, we can go with the worst case scenario. So basically base the cascus on the slowest

implementation uh somewhere in between. So use either average or median or in the best case scenarios. All of those approaches have some uh pros and cons. We usually tend to go with the median which gave us the best results. But in case of EC pairing the difference between a median and uh the two worst uh clients GE and elegon is so big that it might in some effects uh affect network security. So uh uh at the moment we are devising uh this um pre-ompile also uh P debacheski from

Ipsilon team has laced a good question I'm not sure how deep you want to go into this but he he he laced a question uh are we sure that uh we always take the most expensive uh scenario when it comes to uh some simple arithmetic uh op codes. And to show you uh the actual problem and differences between clients, I can show you this uh um uh nice uh graphs here. And uh what we see here is the a diff code execution time independence of the

size of arguments. So the div takes two arguments and we can see by increasing uh this is a case of argon by increasing uh size of first argument as expected the execution time goes slightly up but not that much up. It's uh starts from four and ends on 5.2. So defense is not that big. The size of second argument doesn't matter that much. So this is elegant implementation. When we move to nethermind, we see that div is uh almost linear because the difference between best and worst case is not that

big. But then we move to GEF and the same op code gives you very different uh results and uh we can see that g imple g implementation have somehow like two paths depending on the actual value. So you can either go into the fast path which is about uh five milliseconds or you can end up with a slow path which is 11 milliseconds. defense is big and this might uh cause some underpricing depending on which uh uh value we used as a as

um outcome of uh our analysis. Sorry for the being that uh that technically deep on this one but uh it just to show that there are some sub to uh uh things that we still need to consider. I don't expect huge changes in arithmetic op codes but as it goes for the easy pairing we probably need to seriously revise our um gas price and go with network security rather than uh average cost. Okay. Uh that's um that's it. Uh

do we have uh any questions on this? Thanks for the overview, Yas. Yeah, I think there is um some interesting questions in the chat if you can see it. Um uh a good uh question. Uh measuring uh M gas is always difficult because it uh I'm looking at the first question from Dan. Uh measuring gas from MG gas it's always difficult because it uh obviously depends on your uh um uh PC that you measure it on on your machine. Uh but uh from what I remember

uh the slowest and the worst case for the EC pairing after the replicing on GU it was about 40 million gas per second which is uh uh too low for the network security and the fast clients are like uh 150 200 million uh and uh yeah what what inputs we used for uh EC pairing or other pre-ompiles it's uh all the inputs that we found from the

actual testing EIP and so on which give us the worst typical and best uh scenarios and uh usually we use uh the worst case scenarios. I think we always use the worst case scenarios. Um um okay. Uh what next? Uh yeah, sorry I put some comments in chat.

That wasn't really questions. Bit long. Yeah, exactly. Yeah, I'm I'm just looking for for the comments. Uh yeah, I I was just curious maybe the rounding one is the most pragmatic one like with the with these benchmarks I saw because I when I look at these kind of underlying results, it was usually like just rounded. So like 1.3 kind of um gas was then rounded down to one and and I I'm I'm just wondering like my my feeling is we kind of need to always round up um basically so if something basically if the true price of something should be 1.3 then then we should price it at two not at one just because otherwise basically that that one becomes too cheap and then basically we it it just drags down the worst case kind of gas per seconds that we that we get to for everything. It It's

It's actually a very good idea. Uh we went with the standard uh lounging just because but uh rather than uh doing that, we always go to the ceiling. It's um it's not a bad idea. We can run uh some analysis and see what the effect it will take. How many of these uh up codes will uh uh will go up? I guess this more complicated will actually change from from base one to to two. Uh but yeah, I I can prepare a scenario like this and uh show it here.

Yeah, that would be um and of course I mean hopefully not not much changes because if if a lot changes then then we we need to think about whether we really want to do that. Um but yeah. Yeah. Yeah. Let's let's see uh dark short changes. I I would prepare the compilation uh chart and uh then we can discuss I mean also dependent on having the actual changes but it might be worth like setting a rounding threshold of like 1.3 or 1.2 like I think if something's the real cost is 1.1 then rounding up seems a bit insane. I had this uh chart somewhere I don't remember well exactly but uh yeah I I will post a link when I find it.

Okay. Thanks with the with the actual various uh stom is saying that uh it would be helpful to have a table that just uh m gas uh for each up code. Um yeah, I um I wanted to avoid it uh just because it's always refers to your actual uh

machine that you run the MG gas on. But uh I think we now we are in position to to have for the reference such an uh calculation MG gas calculation. It would be very good actually. So I will add it to to the proposal as well. I'd be curious if you like you already talked about it um a bit um what do you have any further thoughts on this on this question of how to deal with the fact that different clients have different behavior? I feel like in the past we were always so far away from the

bottlenecks or like the efficient frontier that it didn't matter as we tried to really push how do we should do should we focus on harmonizing client behavior should we f like I don't know how do you do you have any further thoughts on on this topic uh so uh I think we have to make a distinction here for the most of the op codes the implementations are slightly different but they are so close together but it actually doesn't matter. Uh even if some op goes it's under or over it is by such a small factor that it really doesn't matter. The problem comes when we have

uh a thing like easy padding and we have really big differences and it might open even some vector of attack on the network just because in the worst case uh mask will be will be uh mcast per second will be less than uh the block size which uh obviously it's not uh uh what we want uh how to deal with that? Uh we have uh three options really going back to this uh worst case best case average. If we go with the worst case scenario, so we price it uh accordingly

to the slowest implementation then uh we have the network security. What we don't have is some kind of a incentive to improve implementations. If we go with the best case scenario and we place it on the fastest implementation uh of course uh we someh somehow punish the slowest uh clients but obviously at the at the risk of uh network stability. uh average or medium approach goes somewhere in the middle. How to do it uh deal with that in the future? I I

don't know. It's probably case by case scenario which we have to review and uh and decide what to do about it. So uh in the case of uh EC pairing I'm uh I'm um aligning with uh the worst case scenario. Now just because the potential vector of attack might be too uh too propable. Yeah, thanks. That's uh and I I feel

like this will probably come up in many pages, right? Like now we're looking at it for op codes and for for pre-ompiles I guess in this case but um I mean you could imagine the same thing with anything right like different database layouts that lead to to like one client having much worse performance on some specific kind of aspect or different sync behavior or different like we'll run into this like once we start pushing and basically all of these different areas of client performance will start to hit the hit the limits. there will always be one client like hopefully in many areas all clients will have similar kind of performance but there will always be the one client that is just worse than everyone else at a specific thing and so the question is how do we in general how do we in general approach

this so I feel like we shouldn't have a like a pricing specific strategy for this we should we should just overall figure this out um overall We used the median uh approach uh and which I think worked for almost all of the cases that we had. EC padding is more an exception. Uh uh and we need to look closer closer to it.

Yeah, it's a good question that Storm has in chat like u because I mean just because again like we'll run into this all the time. So I think treating the kind of this this the specific case is just like a little bit of a of an example of how to deal with these things. So like okay we have clients that are slower than everyone else like what are these clients doing to address this? It's a very good question. Yeah. So uh uh and also that brings the question are we proactive or reactive? Do we just want to measure and go with that or do we want to be more proactive and uh somehow force clients to to improve the implementation and optimize things.

I think like so far it there hasn't really been good data on the per client performance especially not at the op code level and merely just just publishing a table of how fast each client is for each op code would do a huge amount of just awareness um for pointing out um where the bottleneck is for each client and that could create a really good feedback loop for pointing clients where to go um for sort of like the community gathering awareness of where these bottlenecks are and acting appropriately.

Um it's it's very tempting. Uh uh, of course all all of this data is available and uh but we uh uh wanted to avoid direct client comparison not because we want to hide this data but we wanted to avoid uh uh uh some unnecessary battles between clients saying my client is better than your client and so on. It's it's completely pointless. But uh um in this case I I I do agree that it will actually help with rising the awareness of different implementations. And uh in our report uh

that we published earlier, we highlighted uh some issues with uh specific op codes in specific uh [Music] um uh clients. And we know that uh some clients have already acted on it and uh I can show you an example of uh uh of what we actually said. So uh in here uh when we have some kind of sum summary I left a client implement. Oh maybe I make it slightly bigger. I uh made some uh client implementation notes. For

example, saying that uh Bessu and Athelium uh ajs have some push uh issues, push implementation issues and uh things like this and some clients have already acted on this uh data and then uh they improve it. So uh uh yeah sometimes compelling clients is actually helpful. So uh I I guess more uh more work for me to to create such a comparison for the each op code and uh uh pre-ompile.

Yeah. And I I agree with with Storm that like you know we are I think we all on the same team here. So like I don't I mean obviously it's it's on us to set the right the constructive atmosphere and like actually be mature about this. But I I think in principle being like hey look this client has some issues here. Let's just together help them figure out what is the issue. Maybe it's like sometimes these these things are hard to address, right? Like if it's a pre-ompile and the the library and that language for some reason is less efficient and it's really hard to fix like you know maybe we we have to accept that that bottleneck will exist for a while like it's not doesn't mean they are doing a bad job or anything. So I think but I I do think transparency is

just super valuable in this. I I agree. Uh just in the in the beginning we we thought that we don't really want to point fingers. It's very easy and as you said there are lots of factors that uh are actually driving uh specific performance. Yeah. And it's very easy to judge just based on the outcome of it. Yeah, I agree. I do think by the way because like I I really feel like the repricing here it's we in a way like this topic is ahead of most of the other topics. Um and I think so so so it's it's a really good example like here we can practice building these feedback

loops making sure that this data doesn't just exist and then no one looks at it but that there's a feedback loop where that now goes to the clients the clients work on improving their worst cases and so on right so like because I think what we will have to then also do soon and so for this is super valuable is to look how to generalize this type of approach right like I would love for someone to do the same work on sync performance right like figuring out okay How how does that is that impacted instead of pure by different op codes how is it impacted by the rate of state change right or the the the state size or what whatever all the factors that that that impact that and then also understanding okay this this of course sync would be a topic where there would be a lot of difference

in client behavior or say like I don't know state accesses all all these kind of different different ways I think we basically we need to have the same approach metrics of different client performance understanding where the differences come from address them price for the worst case but like at the same time help them improve the worst case. I really feel like we need to have get that flywheel going basically everywhere. Maybe this would be a good topic um kind of like in the like later in the year when we have the um the interop uh

meeting. I guess we don't really we try to not not have too many kind of too much talk about the details of these event these these these events kind of on public calls but like you know like once there's another one upcoming that that that could be a good a good topic like a good yeah area to make progress on. Um okay so uh so maybe closing on this uh general pricing I um uh will uh try to finish the what if scenario uh showing how these changes would affect typical transactions add some mass analysis and uh uh maybe

client comparisons sounds good and David you asked when you when you introduce the uh um the question. Oh, sorry Sophia, do you want to say something? Yeah, I was just going to make a suggestion on Scarface and something you said in the chat that it may make sense to this to if to separate it into one EIP for I think the op codes and then one for the pre-ompiles. Um my hope for this is that it's really non-controversial and I think that for all the op code pricing it looks like that to me. uh meaning doesn't give differ greatly between clients and uh is largely unlikely to change in the

future. For example, doesn't intersect with ZK related repricing. Uh so the pre-ompiles seem to me uh to be outliers in that sense. Uh I I'm not sure how these ones in particular um uh you know how ZK proving uh works with them but um uh you know they're I think that you it's possible that's a factor for example. Yeah. Yeah, I mean I think ZK is just in general a big topic we have to kind of figure out how we think about this. I I am not um I'm not super hopeful that we'll have

benchmarking um for that in time for Glamsterdam. Um although I think that that's something I hope to discuss in Berlin interop. Um but I think that you like it is clearer which op codes are likely to be affected right by proving right uh rather than um just the interpreter cost dominating proving costs and you know so I think for example the compute ones here uh are you know I I can't see why those would be affected at I guess there's more question on my side

is related to the first thing that Sophia and Asgar mentioned which is like Yas whether you've considered uh splitting it um splitting it into like uh a few categories of op codes like a few EIPs um yeah because it seems like it's a really well thought uh EIP and exercise and there is general agreement that uh we should do it but uh um it seems you didn't get too much um like feedback even in the forum etc. I wonder if like people are a bit overwhelmed this uh slash as you were saying like u we don't have a super streamlined way to change

uh um like we don't have the standard config uh yet. So uh like people may be a little bit um I don't know if scared off is the right term but like uh colder to engage with this since it's so big. um a it's it's not a bad idea. So usually we we say smaller is better because a smaller chunk of work is easier to consume by anyone. There's uh one issue I see with this all of these changes come from the same uh research and they are part of the same proposal uh lip placing proposal. Now if we say

let's say split it into five um uh EIPs and only implement three of them for whatever reason the remaining two groups of op codes or pre-ompiles are not in sync with the rest. So what we really gain from uh splitting into multiple EIPs uh just uh just more uh chaos really yeah I guess one way to look at it is that um the compute op codes it's like basically the relative cost between them is also important right uh but I think

uh the way Asgard was putting it which is also how I think about it is like okay if you can separate like some um group of op codes that are kind of orthogonal to like compute right I don't know if state access is a good example but uh then essentially um maybe it's okay uh that um there is um those changes that go later like if the relative cost are not that important.

Um maybe maybe you are right. Uh I'm not sure Lily. I'm I'm happy with both uh approaches. It just uh uh I'm I'm worried whether the it's it's going to be implemented uh at all if we start splitting it. Or maybe it is easier. I'm not sure what you guys think. It feels like we should, you know, it's the kind of decision we can only make once. Like once we split it, it's weird to like re re merge it together or split it a different way. So maybe we don't split it for now because I Yeah, I do I do get your points that like if if it comes from the same methodology like

yeah, it kind of belongs together. I I think the only reason to split it is if uh you know we're likely to have great debate about some parts of it and not others. Um so that's you know for example why you mentioned pre-ompiles because it you know potentially has an issue with um different you know significantly different implementations and you know because we're making them cheaper if they are more expensive to prove or you know we we have an idea they might be more expensive to prove then it might be a better idea to just leave them at the current cost uh until we have uh proving benchmarks. So that's why I suggest that generally I I think that uh

consolidation is better. But that's okay quick quick general philosophical or like kind of approach question like I feel like we should just normalize pricing changes and frequent pricing changes and I didn't build out the infrastructure so that it becomes almost trivial to just feed in a new kind of file with with different prices every hard because then it wouldn't be a big deal right like we just make it cheaper and glamadam and then by the time we want zkms we're like ah interesting actually this specific pre-ompiler is a bottleneck we want this to be more expensive again and then it was it was cheaper for 6 months and then 6 months later it becomes three times as expensive. And to me that's fine. Um, of course, yeah, if it basically feels like we only make these changes once every 5 years, then it it's much more pressure

to get them right. Um, I think there's a couple things about that. So one, I think that uh to the extent that we can predict it is better for the changes to only be monotonic, right? So the things I I see that uh potentially not being that case for are um for example like potentially these pre-ompiles or hash functions, right? That might be uh cheaper to traditionally compute and more expensive to prove. I also just kind of like disagree that we're likely to want to change most of these things uh in the future. You know, I think that most of what's in this proposal, I honestly don't expect we would like ever change again.

um uh the ZK stuff. Yeah, it's possible um you know the implementations change and and so we changed those multiple times. But most of this I I don't think you know even the like the memory ones I think the only thing that's been discussed is you know potentially we make like fresh rights uh more expensive um those of course they don't significantly change in this. So yeah, I mean that that's the other thing is I sort of differ in the opinion that we're likely to be changing these that many times in the future and and for most of them.

It just feels like sometimes I was just responding to what Storm said in the chat that I mean I'm just sort of assuming from a um DevX standpoint that um yeah developers have like intuition about uh um developers or compiler engineers or language engineers I guess have an intuition about cost that um better not to um not to break extremely not that they're dependent on the specific gas cost, but um you know that seesawing could be bad.

I think I think I disagree with this. Uh like yeah or rather yeah I'm with Storm in the sense that like it seems like a nice to have where like maybe in like in the long term we should probably try to focus more on this. I think right now we're coming out of this phase of like being barely ever daring to touch anything about the the system and I feel like that's been holding us back in the past. So I think it would actually be beneficial for a while to just be willing to just make changes and see their effects and then over time like try to become a bit more predictable again. And it's not like the minutiae of oh okay this op code is now three gas instead of two gas. It it's it yes I understand there are go gasol contracts on mainet but maybe maybe that is okay

maybe this is the cost we have to pay here like basically if we want to start being innovative here we have to just be okay with gas golfing being no longer permanently optimal on mainet yeah I agree that in in principle and I agree with storm that that that should be a hard requirement but I I I think that like we should be able to look forward at what would likely change and based our plans now on that and that if you know if we don't have any reason to think that something would likely change like say the cost of of the computer op code say couldn't poss um then you know uh you know I don't know we could base decisions in that and

what I project forward in this I think the majority of it is unlikely to change yeah well we're running up at the end of the hour anyway but Yeah, like the one last thing that I would say there is maybe maybe we should approach a different way and just start getting better at giving much more explicit guidance. Like if we ship a feature and we like a hard and we make an a pre-ompile cheaper, it should be very clear for developers and compiler people and everyone like there should be a clear resource where we say look this one we basically make cheaper now but we we are still like there's still zk benchmarks pending. This could become much more expensive again in the future.

basically make sure to not overly rely on that specific price or something. There's also probably a point to be made that if I'm mainly making this argument about the pre-ompiles, I imagine what I'm saying about Devax is probably a lot less true for them than the codes, right? So, um, you know, given that they're relatively expensive anyway, makes sense. Okay. Yeah. Then uh I think kind of coming out of this specific EIP discussion, I I I would just say like again from from kind of tying it back into what I said at the very beginning of the call, I think the way I would think about this that the the goal of

like EIP7904 is basically to just overall make compute more efficient. to basically make it so that everything that just takes some milliseconds on on on a on a node to run now is harmonized that it all kind of takes costs the same amount of gas per millisecond or so that it takes kind of that that's at least the intuition. Um and so we we can overall kind of crank up gas more and and and and be be more happy that the worst cases are not so bad. um and that but that that we should in our head clearly distinguish this from the second category of repricing that I think we haven't really done much in the past only once or twice about state but we we we will probably do much more which will be just like okay look right now the scaling bottleneck is this category so

let's just make this entire category more expensive so that we can overall crank up the gas and not be held back by this one specific category and I think we should separately prepare for a world where ideally we would want to do this every single hard fork and we probably ideally would want to wait until as late in the process as possible so that just having the general infrastructure built out that we can swap in a specific kind of like config file and that just works seamlessly and is low effort for people. I think that would be like really really valuable to help as a as a supportive thing for overall kind of scaling effort.

But yeah, I hope this wasn't too much. I always have a bad feeling when I leave a call and I talk too much. But um I think that was a good call. I think it was productive. Yeah, we have a few things to follow up and then there is a few topics we can pick up uh in the next call. Yeah. So, thanks everyone for participating. Thanks, David. Thank you. Thanks. This Thanks.