Gas Repricing Breakout #2

Transcript

But I think maybe we can um we can start. Um okay. So um for the ones uh joining this breakout for the first time uh we had a breakout um last week where we started to uh present half of the repricing EIP and now we are going to discuss the other half. uh I shared the agenda on discord uh but anyways I just wanted to give you a quick overview of um what we are uh going to discuss um so uh we will start by so we'll dive right in in the deep dives for each

repric um and uh I will give five minutes to each um presenter Um so I will uh try to if the discussion is taking too long I will interrupt and uh move to the next so that we have enough time to discuss all the IPS um and at the end uh we'll do a wrap-up and some some final comments um on the whole on the as a summary of the two um breakout calls. Um and we should have then also some more time for more general comments from your side. Um so and we will uh start now uh

with uh 7904. So the general compute repricing um and I will be presenting this one. So um these um DCIP what is the motivation? So essentially um based on um our current benchmarks uh we know that uh the compute operations don't have harmonized costs. So we have some operations that are overpriced. So this means that uh because they are too expensive we are actually limiting the throughput that these operations could have. Um and on the other hand we have other operations that are underpriced.

So this means that they are uh too cheap and uh because of this they create a bottleneck. So we cannot continue to increase the gas limit without making these operations um more expensive um and to illustrate a little bit this point. So on the side of the overpriced operations, so the ones where we could be processing more of these operations per block, but because their gas price is too expensive, they are sort of limited by the by the current uh gas limit. And um here I have some some some recent plots that show the um so I I computed this metric that I call

efficiency loss. Um so essentially is based on the benchmarks from YASK which was the the the the data that started this this EIP um we can see um uh how much each operation takes in nanoseconds to execute um and we can compute on these um case of a 4 second execution time. So I'm assuming we have EPBS um how many operations we could fit within those 4 seconds theoretically based on these benchmarks and also we can compute what are the maximum operations that the

given gas price um gives. So at current price uh we and the gas limit of uh 300 million gas um we can compute how many of these operations assuming we don't have any of the other op codes there which is impossible but it's a it's a simplified uh calculation. We can say what is the maximum operations we could fit within that gas limit and for a certain price and um and then we compute the difference. So what I'm doing here is like for instance for uh the current price on the on the block um on top you are seeing each point here on this distribution is a single op code. So we

can say so for instance for for some op codes um their efficiency loss is 10. So this means that um they are they we could have 10 times more of these op codes with um uh so with the theoretical we could have 10 times more but we are being limited by by the current price. Um and then I also show here two two optional prices. So, I'm I'm doing um a price where I'm anchoring on on this gas limit for 4 seconds. Um but I'm uh not doing fractional gas. So, I'm just

rounding things uh to the closest unit. And then with fractional uh gas is the is the third one. And so you you can see like the level of uh efficiency losses per op code that we get under these three scenarios. Um and the plot down is instead of looking at specific op codes we are looking at transactions. So I did a sample of transactions um check their traces see what op codes are there and then I compute these things based on the cost of the op code and the benchmark values. And here we see that the efficiency loss per transaction is much lower than per up code. And the reason is that um a lot of gas on transaction

is also used for state operations instead of pure compute. And for those I'm assuming that they are fully efficient because I don't have the data. So this is also bringing some bias but essentially it's we also know that compute as a size of gas used is relatively small when compared with other um resources like state creation and state access and so on so forth. Um and so also the impact on transaction level is also limited.

Um but so this gives you kind of a sense of of the numbers and for the enterprise the best uh data we have to assess this is the the gas benchmarks that are being is a joint collaboration between the EF and Nethermine team and um essentially they are trying to build these worst case blocks or these worst case scenarios and and then benchmarking them and essentially if we were to target these 300 100 million gas um limit uh at 4 seconds. Then um we could see um that um any OP call that is performing at less than 75 million gas per second

would be a bottleneck. So it should become more expensive and um some of the examples would be the pre-ompiles uh catch and some of the mod operations. Okay. So what is the proposal? So essentially the idea here is we will benchmark all operations and collect their execution time. Um then we need to pick a target for the repricing which we which we call the anchor. Um and essentially here we essentially need to say come glamster how does the block limit look like? So what block limit are we targeting and also um what uh window for the execution time do we get from eps and with these

two things then we can um set this target for repricing and then uh change the operations uh prices accordingly. And um I want to highlight that the current uh EIP uh numbers so the the numbers you see in the EIP so the the actual repricing numbers there they are not final and the reason is that we are still improving on on benchmark so we had a few op codes that are out the pre-ompiles are not included at the moment and we really want to include them and also we need to reconsider the anchor. Essentially we need to figure out what um gas limit we should be targeting for Glamsterdam and what the uh time for execution should we should

we consider and I also wanted to to say that we have some flavors that we can do with this EIP. So one way is we can go with the minimum repricing and uh here we essentially will be only repricing the underpric operation. So we would only make the bottlenecks more expensive and leave everything out. Um what this would mean is that uh we remove the bottleneck so we could scale to our target um gas limit. uh but we wouldn't fix the um the efficiency losses from the cheaper op

codes. So those will still be so we will still be losing some scalability on those specific op codes. Um the the second option is we repric all operations. So both the underpriced and the overpriced but we ignore the rounding error. So we don't do anything about so if an op code should be 0.1 we just assume it is one. So we are not uh changing anything on the internals of of cosmetric all operations and we fix the rounding errors either with 8053 or 8059.

Um and the tradeoff here is on one hand the more you change the more efficiency efficiency case you get. Um but it comes at the cost of fork complexity. So there's a trade-off here and um I think it's something we need to once we have the final benchmark numbers um it's something we need to to to consider. And um I know I'm a bit um uh 2 minutes out. Uh so I will uh skip the comments, but if you want to add anything, please just um use the use the chat and I'll try to to reply. Um and I think now we will move to the next

um presenter uh which is uh Tony is presenting uh block house accounting without refunds. Um Tony when you you want you can can start. >> Yeah. Can you hear me? >> Yes. Yes, we can hear you. >> Perfect. Yeah. Yeah, I haven't pre pres um prepared a presentation or anything but this is regarding EIP7778 and it's a it's a rather simple change.

What we would do is instead of um subtracting the refunds before we um apply the gas used to the gas available in the block, we would just um not do that. So basically when we count the gas used against the block gas limit refunds would not um count towards it. And the rational is that today for example the worst case block when it comes to state churn. So how much state can be updated or changed within a single block. This originates from this refund pricing because with those 25% refunds, you can um yeah um get some extra gas out of the block that you can then use for other

transactions and in the end you can um cycle through and get um 25% more gas into a block. So this is a rather um small change that um yeah should be should be quite manageable. Yeah, I'm happy to receive any feedback or comments uh regarding the EIP. Um but that's essentially all I have to say about it.

>> Yes, I would say we still have lots of time. So yeah, we we we have time for discussion. Yeah, I mean just to briefly say I feel like this year from everyone I talked to so far seems to be the one out of all the repricings to be the the most universally kind of supported one. So it seems to me like I mean we can we can discuss it a bit more but it seems to me like this one I kind of trust will be in the fork. So uh I think it's >> which one the refund?

Yeah, I mean maybe I'm wrong actually. Like if you disagree with the statement all the better then then I curious to hear from >> I totally agree. This seems like an oversight in the gas accounting stuff to begin with like protocol oversight. >> Yep. So I mean I guess coming out of the breakouts for like tomorrow's ACD it feels like that's the one takeaway like this one EP seems to just have pretty universal support. So that's already one good takeaway. >> Uh I have a question for the general repricing EIP. So let's say we tune in uh numbers for Glamsterdam and we do like repricing of all op codes and all

pre-ompiles and we target 300 megagas in Glamsterdam. Two two questions. one what if we want to then target 600 megagas then the up codes would get potentially underpriced uh that's one thing uh though with parallel execution maybe we can work around this with like increasing uh the uh CPU and hardware spec etc. So that's one thing and the other thing what about Zitk VMs if we actually reduce some pricing of some up codes maybe we'll have to increase them in a year or something. So it seems somewhat counter productive to do that without numbers from ZK VMs. So those are my two

questions >> right? So I would uh I will try to give an answer to both and then if more people have uh further comments um please please um add them. So on the first question, I would say this repric will give us a one-time boost. So we are fixing these pricing bugs and it will give us a one time boost in scalability to so it will allow us to increase the the the gas limit to the limit we'll be setting there. Then for further gas limits essentially we would have to take optimizations and hardware improvements and those will will not give you like

the same level of boost you can have with repricing because this is just a a one-time thing. But I would expect that again client optim as clients optimize um and hardware improves we should be able to continue to scale um even though not at the same level. So I think it's important that's why the the the question of what limit to we want to target is also important here on the ZKVMs. I would expect that um once we have the fork where we introduce EKVM we should do a repric then u I don't think it makes sense to do it now uh because we don't yet have ready numbers then you

could ask like why are we doing this uh over overhead if we are if we are going to do another repric once we have zkms and my argument there I think is like we'd still don't know like ZKVMs are not a short shorttime thing and these are clear short-term gains that we can get now and so I think it's worth the the the work that we are putting it for us to be able to have um these gains now rather than once ZKVM arrives. Um yeah I don't know uh Sophia and Andrew if you want to comment on this or if your hands is up

for a different question. >> Uh [clears throat] yeah so I mean I'll reiterate I feel like I say this like uh at least once a week. So the our plan to roll out Zika EVMS is to have first an optional tester client and uh we're uh planning to ship that um at basically right after Glamsterdam goes live because we need um uh the the extra approving time from EPBS to do that. Um uh so there won't be like a ZK EVM fork. Uh um with regards to ZK uh repricing uh I think and I think that this is not

like an outlier view now um amongst my team working on this and this is uh what Vitalik proposed this week that a better approach than uh ZK related repricing is to just eliminate all pre-ompiles and replace them with the EVM code um which will of course be like much more expensive. Um this will also like I mean this is will greatly increase security and um uh really help us scale traditionally if you look at what the bottlenecks have been um just scaling right now uh in terms of edge cases from different clients having different implementations of these um and I think that you know we don't have like a a a obvious candidate for like an HR E

headliner we kind of do for the CL uh given what's involved in the migration of this I think that would be um a great thing to do then. So that that's um that's my current view on that. Uh but oh but also right now I think that it would it's reasonable to say maybe we shouldn't make any pre-ompiles cheaper in Clamster. >> Okay. Um Okay. So I think conscious of time I think we'll need to move to the next presentation. I'm sorry, Andrew Angar and Lucash. I will ask you to just uh comment in the chat. And the next presenter um is Carl. So he's going to present linear EVM memory limits which

is EIP7686. Um Carl, are you there? Can you present? >> Yeah, absolutely. Um see one second. Uh two things. So this came out of uh I built a spreadsheet that I shared in the chat just check tracking where each op code and recompile and everything like transactions are repriced within all the repricing EIPs and what I wasn't particularly happy with was uh things for me memory and memory expansion. There already is an EIP proposed which is this page based linear memory costing um but it ends up being quite complicated and quite

opinionated on exactly how things work with pages and um it's like architecture decisions which aren't like might not necessarily be native to the underlying architecture and might not be available to whatever VM you're using. Um so pfying uh EIP 7686 which is just very simple linear uh EVM memory limits. Um basically the idea is in like currently there's this uh quadratic factor as you expand memory um which makes it rather expensive arguably unnecessarily so uh given how much memory is available on your

computer. So the the idea here is that we can make things a lot cheaper and a lot simpler by just having a linear memory model. It's also not as though the like resource consumption on your own node will go up quadratically as you expand the memory. So effectively this has two components to it. one is instead of this old complicated quadratic system, it switches to this very simple your memory cost is uh just linear in the the memory you're using. And then the second thing is it changes the way we calculate the max gas available for a call. instead of this 63 64s of the

remaining gas or whatever it uh it changes it to this looks complicated but basically the amount of gas remaining for the call. And so this means that at the start of an a transaction you can exe you can allocate all the memory that you could ever need for this uh this transaction. Then at each pull you can sort of subdivide the remaining memory up into what you need. So it it it both linearizes the cost of memory and simplifies the way we uh reason about about memory.

Any questions? Yeah, maybe the um because this linear memory uh this change to linear memory that's that seems logical but I'm not really understanding why this max call gas is introduced but maybe that's more specification maybe let's first move >> yeah so the the problem the problem is is that you need some kind of limit the previous way we were limiting the maximum amount of memory available was just the fact that the quadratic cost of memory just blows up in your face and it becomes very expensive to access crazy amounts of memory. Um the idea here is to uh you have to go into the IP for the

details or I can we can share a sync but the idea here is that we can like have uh limits that are more like concrete just as a function of the amount of compute that you can physically do you know this for every possible call. Yes, this actually makes a lot of sense because I forgot that we can create call frames. So you can actually well yeah okay have more call frames. Yeah. Okay. Makes sense. Thank you. >> Yeah. >> Uh so we analyze this EAP and also a competing somewhat EAP which is 79 to3 linear page base memory. And uh yeah to be honest I think that the the the page

base gives us more flex gives especially the compilers more flexibility. So uh both are fine in terms of like repricing but that one is a bit more more interesting in terms of like other considerations. That's our input. >> Yeah you can you can design architectures around the paging which you could make some slightly more efficient choices. um for for for certain compilers if if that's the direction we want to go to, we can. It's just it it is a lot more complicated um in in in my opinion.

that idea here is just what if we had a a more simple offering and I think you can basically get most of those same gains in in this this alternative model because most of the gains there come by alloc like assuming you allocate a whole page and then in in in in this model like you can just allocate to the equivalent of what would be a page and pay the same amounts Yes, we still have some time. So >> curious about to hear more from Luc about why you like page paging more. I think I if I remember correctly the page

size is 4096 bytes for that EIP which is already far more than 99.9% of transactions actually use. So it feels a little bit like they add a ton of machinery to support these pages. [clears throat] >> You can like separate stack and heap because you can with linear >> stack and wide >> heap. Say that again. You can do you know like Yeah. Yeah. So you can have like you can allocate something >> two pieces of memory far away from each other >> which you can't do >> what >> uh then

>> why is that different with the page based like you will still have to pay like pretty similar cost for the amount of memory you're allocating. No >> no you uh >> you you don't you don't pay between the two with the with a linear model. you you pay for all of the memory. Whereas with the page base, you could >> you pay for the whole page. >> Yes. But you don't pay for the memory between the pages. >> What's the memory between the pages? So if I wanted to allocate a stack at at the bottom that I'm going to use as a stack part of memory and I want to allocate a heap at a really >> far away from that you know so they grow towards each other I'm not paying for

the memory in the middle >> whereas if it's a linear model uh you have to pay that that memory between the two is considered used and you have to pay for it. Yeah, I mean is if we're okay with them not paying for that memory in the pagebased system, that would mean that our linear pricing is just not that reflective of the true cost because that memory is allocated for a page. >> So >> by the basically allows of more dynamic uh address space using virtual addressing, right? So basically what your OS does and uh charges you for actually used memory. I agree that maybe

the page size is too big. Maybe that's the case, right? So maybe we need to tweak tweak that. That's you know I think that's just starting point here and if we like uh know that uh the page size is too big. That's something different and we can tweak it very easily just decrease the page size. Uh I think it was uh more of a hardware thing that they went with 4K because 4K is what more hardware is using, right? And potentially even I've seen I'm not sure if I understand how this would work uh like direct hardware mapping of memory there uh in that in that EIP. So like using hardware more on the bare metal there in terms of like memory layout. Uh but yeah that basically you can you can

allocate things far away from each other in virtual address space while still using very small amount of memory. So if they grow they have a space to grow in the address space. >> Um sorry sorry guys. I know that we are already discussing an EIP that we haven't presented yet. So I think it would be helpful if we can have Charles which is the next presenter talk about that EIP first and then we can continue the discussion. Um Charles, are you uh okay to present? >> Hello. Uh let me show my screen. Uh so uh I did look at EIP7686.

And the reason uh just to follow up on everything that was being discussed, the reason I chose to draft this pagebased thing is because um as Lucas pointed out, um if you have linear memory, uh first of all, can't really where the end of memory is. Uh the way that 7686 sets it up, uh you're basically constrained by whatever the parent call did. Um uh but as a a as a compiler uh which I'm most familiar with but also like as a user in general like want the ability to allocate memory that's very far away from each other.

The classic example of stack versus heap. So stack grows from the top of memory. You just start from like uh the top of memory which in 7923 is pinned at two 2 32 bytes and you start the heap from zero. So you are basically guaranteed that these are never going to collide. Um it it's a very useful abstraction. Whereas if you only have a small amount of memory to work with and you especially don't know where the end of memory is going to be, uh then you can only um grow in one direction and that leads to things like in solidity where uh they only have memory which grows in one direction. What kind of data do you want to put on the heap versus memory

for smart contracts? Well, first of all, we have like a regular programming language that works like a programming language um from the 2020s, not the 1980s. Uh and all modern languages have happened keeping sex separation. Uh is this >> but the environment pretty different >> by by stack I'm referring to the call stack, not the operate stack. >> Oh, I see. Okay. >> Yeah. Yeah. Sorry. uh uh in the future uh in this case stack is all always I'm always talking about the call stack. Um so like uh function frames can grow in a separate place from data.

Um are there any more questions about that? I can go into the EIP. Um so I did some benchmarks on kind of a random computer but maybe representative uh and you see that there's this big um so obviously it's most expensive to allocate a fresh page uh it's kind of and then there's this uh kind of threshold around 32 megabytes which is the size of the L1 cache uh sorry uh one of the caches I guess L3 um where memory access gets a lot random memory access gets a lot more expensive.

Um, there's kind of two ways to address this. Um, what if we give a call frame a free page and grow from there? I I'll respond to that later. Um, so there's kind of two ways to address this uh kind of drop off in performance after 32 megabytes. is to just uh limit the amount of memory that every call frame sorry EVM call frame has to 32 megabytes. Um that's actually totally reasonable and something I want to consider. Um the way I designed it here is there's an LRU cache which tracks the most recently used touched pages.

um which I've gotten feedback from a lot of people that it seems gated. Um but I added in in this draft because it's really only a couple lines and a a single data structure. Um but that's kind of like on the table for cutting out of the AIP. Um what else did I want to discuss here? I think that's the main thing is whether to use this um LRU cache or just simply uh limit the amount of data that a call frame can use megabytes and consider increasing that in the future. Um there's lots of things you can do with

virtual memory. For example, having uh hashts in memory, being able to allocate stuff on the heap and stuff like this. And um there's a lot of things that people uh there's a lot of things that people would like to do uh with smart contracts that they can't do in EVM in Viperility. Um because the a very common use cases is inmemory hashmaps. Um and it's because we don't have stack heap separation. uh there's things that the compiler can do uh to work around this but it's just not very natural and like I stated at the beginning uh only having

memory that not having virtual memory is a restriction from like the 1980s L3 cache will be contended between multiple transactions in parallel bl yes that's true um but I think the 32 megabytes is usually kind of uh I should double check on this. Um 4,96 bytes was used because it's just a very common page size in on machines. Uh it's the size of Linux page and um it could also be like 512 bytes. Um this whole page.

Oh, another thing is implementation complexity. Um there's really a very simple and I would say elegant implementation for this which is that you just map the whole thing the entire 32 uh 32 bytes then you let the operating system take care of the memory allocation and I'm pretty sure this works on all modern systems. I don't know what the page sizes are on Raspberry Pi or whatever. Um but I'm sure we can find like tune it so that it will work on those. Um my co-author uh Joe T also wrote an implementation which doesn't even have doesn't even require

um this data structure for bookkeeping which pages are allocated. It just uses uh the operating systems built-in page allocator and detects when there's a fault to detect if you need to charge the 100 gas or not. So um the implementation is really um a lot simpler than it looks and >> sorry to interrupt but conscious of of time uh we really need to move to the next presentation. So I will ask um for uh people to ask questions in the chat and we will move to the next presentation which is the hard limits for transient storage um which I will um Charles if you can stop um sharing um so

I can share mine. Thank you. Um so I'll quickly go through it. Um so the this is uh um an EIP that um Charles initially uh started and then I I came on on and I'm I'm supporting as well. Um but essentially the motivation is the transient storage operations they currently cost the same as a warm storage access. um even though transient storage is significantly lighter on EVM resources and the consequence of this is that this high cost decentivizes the use of these operations. Um on one hand uh

we don't see devs uh using more of these uh and instead they they they they tend to use state um operations and then leaning on state refunds for um not um spending as much gas and also the implementation of key entrance logs by default um is still um expensive and so this sort of discourages a more wide adoption of of these um safeguards. Um and the proposal is simple. So the idea is to decrease T load cost to five, T store cost to 12 and then limiting the max number of slots per transaction to

prevent those attacks. And um essentially for this to work, we need to implement a new counter per transaction where we track the number of slots allocated. Um there's an alternative design where instead of having a hard limit uh we will um just increase the price of further slot allocations after the max limit. So there's still this this optional design. Um I would um reiterate that I think we still need to benchmark um these costs. Um, so these are still um values that I I personally see as as work in progress. So we still

need to um to make sure they are consistent with the with the rest of of the compute prepricings. Um and on that I think we still have some time for comments. Um I couldn't see the chat so if there are >> Yeah, I have a comment. I have a comment. Uh because uh with my napkin math, it might be off. Uh with this uh limit uh a transaction that is 16 million gas can still allocate 1.6 GBTE through TTOR uh only and without this API actually now I think it can even allocate more

but I'm like not sure if I calculated that correctly. Uh so uh both are kind of probably unacceptable especially with both when we can have eight of those transactions executing in parallel then we allocate uh 12 GB on TTOR as a like worst case scenario which is like potential DOSs attack maybe I don't know >> right >> uh sounds sounds bad >> yeah so I think this is one of those where the parameters need to also be benchmarked. So I think the fact that we are introducing a limit on the number of slots should help there. It's just a question of what should that limit be.

And yeah, I agree that we still need to to um think a bit more carefully and and and and benchmark. I think it should be in megabytes and like tens of megabytes, not not not hundreds or or thousands of megabytes. >> Okay. Um any more comments? We still have one minute. If not, um I will move to the next presentation. Um >> I have one >> there's a um >> yeah you can go >> um I don't get while it said that t load is

different than s load warm cost in our implementation it is one hashmap get so those two should be very similar to not say the same >> that's my comment Okay. Yeah, I think this is something we should be able to see in the benchmarks, right? Um so I think that's why I it's important that we that we do them. Um and um conscious of time will move to the next. So if you have any other um comments, please use the chat. And next we have Tony um is going to present two EIPs. Um so first the increase called data floor costs and then um

increase access list cost. Um Tony I will give the floor to you. >> Perfect. Thank you. Um so let me start with um 7 976 that's the old data flow one and the rational is quite simple. Um with Amsterdam block size will increase because of block access lists and also increasing gas limits will contribute to bigger worst case blocks and we already had impact 7623 which introduced this floor mechanism where essentially 99% of the transactions are unaffected while a few

call data heavy transactions um pay more per bite of call data. And the proposal here is to increase um the gas cost per bite for those affected users um by 33%. So essentially we reduce the worst case block size by the same amount by 33%. And instead of paying 10 bytes for a zero bite and 40 by uh 10 gas for a zero bite and 40 gas for a non-zero g um bite, they would spend 15 and 60 gas. So it would go from 10 to 15 and from 40 to

60. Um I have done an analysis on the EAP. Let me post this in the chat. Um or maybe Maria I've sent it to you maybe you can post it in chat in the meantime and yeah um the goal is just to reduce the worst case block size and it's a rather simple mechanism because everything is already in place and it's just a change in constant. Then going on to the next one which is 7981 which reprices access lists.

And this is a rather interesting topic because after we shipped 7623 the worst case block size didn't consist only of call data anymore but essentially you would use 23 of your gas that is available for access list entries and the rest for call data. And this is because in this case you still pay the lower price for the call data and at the same time you would not pay [clears throat] anything for the data in the access list. And what 7981 does is putting the same price that we put on call data putting that on access lists.

It adds a price on access lists which also makes them unfeasible at least economically. So it's it can be seen as deprecating them and the in quite big. So by shipping that we reduce the size by 21%. And I guess very very few users that are impacted by this one. Yeah, that's essentially all I have. Happy to hear thoughts. >> Um go ahead.

Um yeah, I think this is quite good because it um it m it maintains the original reason for introducing access lists which was for uh repricing which broke some contracts but also there was a there was a suggestion we could use access list for parallelization which never really emerged due to the the pricing being up but that's solved by vals. So we don't we don't need them for that purpose.

So I think it makes a lot of sense. Okay. Um if there are no more comments I think now Asgar, do you want to do the wrap-up? >> Sure. Yeah. I mean, I prepared one slide just because I usually think it's actually nicer to look at something rather than just me talking. So, one sec. Can you see my screen?

>> I can see it. Yes. >> Perfect. Yeah. I mean, this is just my take as a summary and I also like just wanted to briefly go over this and then just actually have at least a few minutes of of of discussion here. Um, just and again, just my take. I personally really just wanted to re reiterate that there's really these two different types of repricing here piece that we discussed. There's the core of repricings which is just about the EVM as it functions today. Just make sure that all the operations have the same kind of cost per second basically of operation that they that they take.

those really to me have the highest promise, the highest potential impact. But I also think and that's something that for me really came out of this last week or last two weeks of of people kind of starting to take a closer look that really both in terms of just the the exact C shape with kind of it being spread across multiple EIPs is something we could revisit um but also people are very concerned about like hey is it realistic that we can benchmark all of these things in time for for Glamadam right I saw this in chat today um I I I'm hearing this quite a bit um I think for one I do think it's worth embracing.

I think if we if we really make this a core priority for the EL for gridam I think we can get a lot of lot done here. Also a lot of the preparatory work has been done now with just like setting up the the benchmarking harnesses this kind of stuff. So I do think we are now it's now a more feasible general exercise. That all said, I do still think that it's worth even within that kind of core group to explore maybe taking some sort of 8020 approach where we try to just like identify um just like which operations maybe if we don't repric everything but we say look look kind of this this middle band of operations that are reasonably priced we just leave alone for now. We revisit maybe an H star or something and we only repric the things that are way too cheap. So like

all of the pre-ompiles whatever but also stay in on the state side, the data side, whatever. basically just only repric the things that really need to be repriced to not block us and then maybe consider repricing a few of the things that are way too expensive so that they're so inefficient that maybe we can we can make them a bit cheaper or something but really kind of not try not have this ambition of repricing everything at once I'm open to that personally um but yeah overall the through line here needs to be that like if unless we completely reject this part of repricing from from Gamsadam the focus over the next months they need to be on benchmarking benchmarking benchmarking and on the F side we're getting ready to support this as much as possible. Um then further points I just wanted to make is um I think it's just

important to stress again like repricings really need to be to also take EPBS and block list into account that has only like I said that that has not been front and center so far because these were also moving targets um but I think again these core repricings play a pretty crucial role in unblocking the potential there especially blossom list in EPBS it's only an optimization because it's it's it's necessary to take take advantage of the fact that you can keep executing ing after you after the PTC deadline but but for block access lists really because block lists don't help with data so unless you make everything else relatively cheaper compared to data then block lists just don't help so basically you kind of need some sort of repricings at least making data more expensive right the minimal version of it would be not repric

everything just repric data but but either way basically like you need some sort of repricing otherwise lists on their own are kind of useless um and then one more really important point I want to stress I know the specific way in which state growth is proposed to be addressed here in the repricings is somewhat contentious, but I just wanted to say like I think we don't really have a choice unless we're willing to accept a state growth rate that's up to say 10 times five five six seven 10 times higher than it was at the beginning of the year when we were at 30 million because even like pre glam we might get to say 100 million and then EPBS gives us double the slot uh span block li with the paralization the refund mechanism

like all of this could easily get us on its own already to 200 plus million that's even before any of the core repricings so if we go to two 300 million gas like I don't think we can just leave state growth at the current prices and just accept a 10 times higher growth rate I think we need to do something anyway in luma dump um but maybe this is worth reconsidering alternative approaches right had a a proposal that I thought was um quite interesting to basically like just scale it scale the the price with with with the death limit and then also under I want to miss the the proposal that time but I think under exceptional circumstances we could consider it even for glums that don't already which which reconsiders adding a fee dimension while trying to keep the complexity as minimum

as possible again I think we kind of need to do something about rep about state growth at least and then last point just keep in mind I think I don't think I need to tell tell you that I think everyone's aware we have a lot of earpiece for glamadam so my feeling is especially if we indeed go ahead with the core rep pricings just my recommendation. Um, there really is a very limited budget here. So, I think basically you realistically from the repricing side, it's probably only possible to do core repricings plus a very small number of of of of um additions. So, maybe the the refund EIP and then maybe I don't know one, two, three of the others, but um we would probably have to reject the majority now and revisit them for for HAR. So that's my summary and yeah I'd be really

curious to get people's stakes and then I think you were first. Uh yeah and just on state growth um we may you might also want to consider it as to what's the state growth between um Amsterdam and HAR um cuz I assume you know if we didn't do anything in Glamdown we'd we'd see the effect of all this repricing and then we'd definitely do something in HA but it's not necessarily what's the state growth for all time.

>> Yeah, I think that's fair. I think we could especially because we would say even with these like gas limit increases from from the benefits we get from Grumsterdum, it would probably we wouldn't like ramp it up right after the fork, right? So it might take a few months afterwards anyway. So maybe this is would actually be a period of just a few months. I still am personally very hesitant to just leave it until H star but okay maybe maybe it's not as impossible as I made it sound but good point Lucas uh so two comments from me one that in my opinion repricings need to take the Zitkkey VMs into account uh maybe you know we don't have very precise numbers from them etc but we need to at least validate that uh we are

not doing something that we will be retracting very soon like if especially if we are like lowering some gas costs that we want to be increasing them very shortly. So that that needs to be taken into account. And uh stage rot we probably need to do something like my approach is I don't know I I don't like it even that much but uh I liked it a bit better than the original one which was just fixed because I don't think we'll jump directly to 300 megas or maybe you can uh correct me if I'm wrong maybe we will be just jumping to 300 mega directly and then that's also fine. Uh Ben also pointed

out that with increasing of those some of those um internally that we are basically pricing new users very high compared to the old users which is uh somewhat uh not uh uh fair for them in some way. Uh so just leaving that here. >> Yeah, good good comments. Um I won't respond just because of time. Uh Andrew >> um yes so on state growth I wanted to say that uh we can mitigate it to some extent with repricing but I think uh strategically we have to address it with

a state expiry either the partial state expiry. I think Giam said had some ideas for vero maybe they can be done in in the binary tree um context and uh or full state expiry I think that required uh address expansion and store at that but um maybe with renew focus we we will find a solution but basically I think uh yeah it's that would be proper solution to state growth Yeah, quick comment there for my side. I would just say like my feeling has been and that's also what I want on the EF side and on on the research, but I think we should do this obviously ecosystem

wide like quarterf. Um my feeling is by H star I want to have a really good understanding of what is our strategy around state growth. I'm not convinced that we need to do something state expiry. I would say probably yes, but I'm not like certain yet because I think ZKVM will change the environment enough like many nodes can just be stateless that maybe it's okay to just accept that the state will just grow a lot and and [clears throat] we're fine with that because only more more specialized nodes require the state. But of course, still builders need the state, RBC providers need the state like block explorers, these kind of entities need the state.

So it's not it's very much not a given that we can just get away with letting the state grow to like multiple terabytes, right? I'm just saying at least it's worth a consideration because CKVM really does change the game quite a bit. But my feeling is probably we'll end up having to do something with like stat expiry, but we really need to like ramp up here and like have a proper strategy so we don't just do these like one time fixes. Um and they they just don't scale, right? You can only make keep making state growth more expensive up to some point. At some point you're just pricing people out. Uh but yeah, so I agree overall. Um, so I'm always I always have trouble pronouncing this. Amian, can you by the way, can you remind me how to exactly pronounce this?

>> No worries. It is Amian. Yeah, I have just one one comment I already shot in the chat related to uh 7904. Um, so like the generally pricing I think in in like in general is good. So we are in favor but uh like in in the current state with the current numbers uh for me it doesn't work. For example we have uh some op codes like even compute op codes like mu mod that go from 8 to uh to three um and it will it will have an impact on on on the worst cases. So it needs as you said

uh as Maria said and you said it needs a lot of benchmarking. Uh um yeah. So this way I I I think we can we can find um uh good numbers that work for each client. I was just wondering how do we plan to do like this work in preparation of 704? uh do we plan to do it like the same way as mod XP for example try to to be sure that we are handling all the worst cases across all the clients then we are sure that you know we are setting the right the right numbers um even for for higher gas limits >> yeah I mean there maybe Maria you can

say something >> yeah yeah so I would say there the current strategy so we are doing this in two steps so First we do um initial benchmarks that are trying to accurately measure what the execution time for each op code is. And this takes into consideration for op codes where their performance depends on the inputs. We need to take that into consideration as well. So uh we can estimate how much for instance for the exponential um the cost scales with with the with the input and so we we also need to benchmark that

accurately and and and and and build that model and the general design is similar to what Yasc um did and this is the first step. So this will give us a first set of pricings and then with this we go and we do the benchmarks the gas benchmarks sorry that we um are already um that are similar to the mod x work. So again two steps. So we first do Yasix style benchmarks to get the first numbers and then we test them against worst case blocks to make sure that we are not

introducing new worst cases. Um Martin do you want to add something to that? Uh yes in the meantime uh we have uh GEF and Nethermind which implemented this EIP in the like current form uh and uh we don't have results yet but we will have in days. So we'll have like a first iteration where we we would be able to compare like the the current state of the clients with the same clients but with uh repricing EIP and uh yeah we'll compare the results and we will see which uh op calls are

too slow which are fine and generally we will uh take a look at at the results and then uh plan the next steps uh depending what we see there. >> Um Luis, do you want to add something? >> Yeah, wanted to add something there. Um, regarding the general repricing EIP, um, I wonder if should not be better, uh, to like push the gas limit, uh, further and make the clients, uh, optimize and force the clients to optimize before making any um, uh, rush decisions on the prices overall. Um, because that might like

come down the current performance might might actually increase. Sorry. uh the performance might increase with the gas limit um increase and so we will be maybe in the better place um going forward to really do a final um revamp of all the pricings um in terms of compute um uh mainly compute that I'm more worried about as as pointed out I was even looking at the difference between ads and mods and uh like having the same cost for both doesn't seem very realistic to me. Um because like the algorithms are

differences are are big. Um and the mods the division is much more complex than than addition. Um but yeah um I think that's my my opinion. which maybe after increasing the gas limit at to some point um then revisiting an overall pricing. >> So just an idea. >> Yeah. One one quick on this from my side because in principle I I do agree like I think we will continue to push on this all the way until the glam dump fork anyway which I mean you know still going to be the next 9 months or so. So I think there will be I I I'm personally really hopeful we can get to 100 million

say before Glam Saddam. What what makes me very excited though about repricings is that it is really the best way to get away from always having to focus on these like worst specific worst cases which are usually actually quite fringe use cases right like with modx we had to focus on what happens if an attacker spams an entire block full of modex. Obviously, no one actually does that as normal use cases, right? It's only a fringe attack case. And often it's like these relatively rarely used pre-ompiles that then draw in all of the engineering focus when with repricings we can just say, okay, look, maybe they're not yet fully optimized engineering wise, but we just don't care. We make them more expensive.

Then that way, they can't be a weakness. They can't be an attack scenario. And that allows us to focus much more on optimizing the actual hot paths, right? I'd much rather have a conversation of percentage- wise where is most of the time spent in the EVM and let's optimize those operations. Let's see if we can squeeze out more more efficiency there. Make make those cheaper um rather than always having to focus on these like actually pretty rarely used cases that only only increase the improve these these theoretical scenarios but don't actually inc improve real world use cases. So I personally am very much looking forward to being able to get get away from this engineering focus that having to always focus on on what happens to be the current worst cases.

Anyway, Ben uh yeah just um picking up on your point about you know AD is a lot less complicated than um divide for instance I think that's where the rebasing or mele gas come from. So in compared to every other op code they're probably one but then if you want to separate them then you might say add is actually 0.1 gas and divide is like.5 gas. Um but with with the without rebasing you know either increasing the gas or everything up or

having fractional gas then I think they they potentially average out at you know one one guess but there but there are proposals to get more precision Right. So I think we are um already over time. Is there any last minute comments or should we wrap up?

Maybe just from my side because of all of tomorrow um we have 40 IPs. it will be a big mess to find structure to get through off all of this anyway or like start the conversation in a productive way. So if either coming out of this repricing breakout specifically around these repricing piece or maybe even in general you have some thoughts some way that you think can help structure tomorrow's conversation do do feel free please to to reach out to me. Um any help appreciate. >> Thank you Ancar. Um okay and with that we'll wrap up. Um, if you have any further comments or things you want to discuss, I'll point to the Discord

channel. I think it's called EVM pricing. And yeah, and we'll speak soon. Thank you so much for for attending. >> Thank you. >> Thank you. Thanks all. >> Thanks everyone. >> Thank you. Bye. Bye. >> Thank you. Bye.