EVM Resource Pricing Breakout #1

Transcript

all right I think we can get started um I'll give a brief introduction on how this um working group uh started um for the ones that were not at the C of call where I gave the announcement um so like around December Anar and I came together we had discussed this before but I really had a conversation in December at this CCE conference where we both were um I had been looking into uh uh resource pricing mainly on the research side like uh we uh wrote a couple of uh papers with some collaborators and then more recently uh last year in May when vital published uh the latest blog post

on like multi- resource pricing like kind of started thinking about how to implement it like do any more kind of the applied angle not just the research angle and then asgar was thinking a lot about like more shortterm uh pricing changes but also wanted to kind of have a framework to uh maybe do some more principal benchmarking and kind of upgrade like the way we've been doing like short-term pricing changes so that's kind of how this came to be um and I think the plan uh for this group is to have like um kind of a similar Focus right like um uh very applied as

you saw in the outline uh today we're going to discuss like uh show like some of the work that people did around benchmarking already then asgar wanted to like lead this discussion on like shortterm changes which is like something that uh we can Target like in the next available fork or the one after and then in parallel we also want to like uh do a kind of more research uh um uh angle so like today there's going to be one presentation around some initial analysis on a multi-dimensional pricing mechanism and I think it's interesting to couple these um because like I think a lot of the short-term changes that we

will do and the analysis for those can also help with like the more kind of like um this multi-dimensional EIP that is kind of like aspirational for now but we should like work towards it yeah so today is kind of like mostly like sharing like different work going on but um the idea is that um we should try to keep this like uh very concrete and then like um as we progress towards the working group like started also drafting uh a few eips for like the shortterm changes and then like hopefully we get uh to also push the bigger multi-dimensional change later yeah so

um I think we can start with um Mark and presentation that he wanted to share yeah yeah hello um do you see my screen yes okay great so hi everyone I will spend about five minutes discussing the tool Ling we developed at nethermind this tool could be used for gas pricing or might Inspire someone to contribute or create something better there is definitely room for improvement and it still requires a lot of work I'm happy to discuss it further after this breakout so the idea is very simple we can construct any block and measure its

execution time and with enough testing coverage we will better understand the current worst cases scenarios gas pricing issues and the limits of how far we can push the gas limit and where we uh have bottlenecks so for example we can fill a block entirely with a catch or any other operation to consume all the available gas limit in the block so very briefly how it works we have a test generator um where any e could be used we just need to produce a blocks blocks of course we use nethermind uh this test generator creates different um testing uh files with engine API requests and

then we have a tool that sends those requests to different Els gather their results and later produces a report from this execution so using engine API has a few benefits it is as close as possible to production measuring not only the operation itself but also everything surrounding it for example up code execution might be fast but the evm instruction Loop or the Json serialization of engine API request or something else could become neck uh one more benefit it potentially allows testing any given blocks including a combination of up codes on any database so we can use a main

snapshot to Benchmark s a store as load on the main State this is not ready in the tool but it could be used in this way and moreover the engine API can work with any client so including the future ethereum clients it doesn't require changes in the clients disadvantages so this is less accurate than Measuring Up codes in isolation and generalized input limits the use of language specific benchmarking tools like Benchmark net so which are very important for accurate measurements and they are doing a lot of uh important task like warm up required

for some programming languages so uh we have to rep replicate this work in uh the tool tooling and of course building all the test cases is very time consuming and now uh findings so uh some pre compiles might be problematic with gas limit increases e add e pairing and especially modex and they are relatively slow compared to other operations uh we found a few bugs such as issues in serialization in a few clients and the blob Bas V up code was slowly in in one of the client uh those things are

fixed now and this tool highlights differences in gas pricing for example let's take a look at the table on the slide on the same machine and with the same clients the differences are significant this might not be surprising for anyone but it could impact us uh as the gas limit increases on L1 or become problematic for any evm based L2 that want to increase the gas limit significantly so the slowest operation will always be a bottleneck unfortunately sometimes it might be a hidden bottleneck that is not observed uh with real normal transaction the notes okay and just I also want to

briefly mention other work related to gas pricing so nethermind tool has both advantages and disadvantages and requires further development so let's take a look at other Solutions and the gas cost estimator is in my opinion the most comprehensive analyzis currently available uh it measures up codes in isolation so different approach than we have uh and producing very interesting report actually yat Glenn will tell more about it today I also know that flashboot team has started building their own solution I believe it's relatively new uh

sorry okay I will continue uh but it might be interesting to explore it as a test generator combined with um our nether gas benchmarks uh finally there is an approach that has been used for gas pricing uh right now so for example in the recent BLS precompile pricing so this involves using test vectors where each client assesses gas pricing independently and cross verifies results with other clients however this is very time consuming and the test vector format is not 100% standardized and it is kind of difficult to run different client okay so yeah my presentation

focused more on different approaches to benchmarking rather than on sharing results I wanted to open a discussion about the tooling for gas pricing and that's all I wanted to share sure for today thank you for listening thanks Mark um I think we can have this discussion the toing maybe after y presentation one question I had is like uh you presented the tooling but you also did like um some analysis and like some finding like uh on those like are

do you already have plans to kind of like propose some changes or it's kind of like early stage analysis that like may require some like uh more effort or more help from the group as well um yes so first of all a few things were already addressed between the client teams uh and uh secondly the most important finding I I expect that we will uh we will share EIP very soon I don't know within two weeks or something like that uh with our proposal how to adjust uh one of the operation and this is like the the most important finding

from all of them uh yeah so we are we are actually right now addressing the findings and maybe later I will just uh share uh some kind of report from this benchmarking work uh yeah cool thank you yeah Aman yeah uh just wanted to add uh so first thanks marak for the presentation uh so we used uh another mind tests because we wanted to reproduce and and check the numbers uh on our machines and we uh changed the the test itself like The Benchmark to add CPU

profiling on on Basu and it helped actually to uh to improve some of the opcodes that was um that was raised by by the neand report so so thanks for that I think we can proceed with Yas presentation okay sure let me just share some uh presentation with you okay can you see it yes okay so uh our project is a gasc estimator and the the aim is as Malik

pointed out slightly well the approach is slightly different to to what nethermind did so we want to test evm uh implementations in isolation and we want to use uh uh specific language Native Tools in order to actually get how computer ation Al expensive each op code or precompile is so uh the goals for the new future is to to provide an a proposal for the new Gasco schedule but going forward we want to have a tool which allows people to to monitor how things changes or when we propose a new OP code pre compile how to to specify a cost for this PR compile so

um uh the scope that we have we took seven most popular clients all the op codes all current pre compiles and based on that we generated uh 50,000 bite code programs which test op codes and pre compiles under various conditions with various arguments uh in different uh composition and so on and we run it uh for a very very long time I think the whole to run the it takes like two or three weeks and we did it uh multiple times uh and that uh gives us some uh oh okay um the cut of Point uh well we

needed to have some cut of point in order to to come up with uh initial proposal so we took this seven clients and the current versions as of November 24 and we learn all of those benchmarks and uh came up with some reason results for each uh client so in this example this is GFF and it shows you that um this uh it somehow validates but our approach was uh at least gives consistent results right so for each uh for most of the op codes the variety is not uh that big apart from some calls Mike you want a coffee

Matt you're unmuted okay so uh we have this uh low results and then the question is how what we do with the low results uh so we need to normalize them somehow and that's what we did after long discussions and different sles out we figure out is uh we take each client and scale it into the current gas cost by scaling we we defined the scaling as an optimization problem to fit one graph in the best way into another we we made some uh decisions how to do this scaling and what uh What uh well how to

recalculate it and so on the end result is something like this so it's a graph which shows you uh differences between each client implementation for uh each uh uh uh op code and uh precompile and now uh once we of course this is a graphical presentation the uh actual data behind this is more concrete than just some uh colorful dots uh on a graph uh but uh by analyzing this we can um come up to our first point so uh uh propose a new uh gas cost so we have um some numbers here these are not

finalized because I need still need to update it to the latest results but it won't be very much off uh from the current uh things so uh we in fact have two proposals one is something that uh we called conservative so we try to minimize number of changes only to highlight uh op codes which are definitely uh uh under or overpriced so in this case you can see that our calculations pointed out that mul mod is uh underpriced and uh pop and stock operations are overpriced and we can uh

lower the cost the same goes to uh the new T Lo and T stto up codes and so on and we have a similar comparison for the pre compiles as many people pointed out uh previously uh EC recover and point evaluation are hugely underpriced uh in the current scheme um so that's one proposal that we have the second one is more radical that we uh say we don't look at the current gas cost we want to start from clean sheet uh for the arith arithmetic op codes we want to use one and then uh

gradually increase the cost as we find the more computational uh costly up codes uh so as you see the simple op codes are one apart from some that are two and so on and so on this is more radical as most of the op codes will end up having one or two gas cost um er now when you think about the these are or Consequences of such a move if we Lowel the cost of all the op codes and leave the storage cost or State uh cost at the same level we wider the Gap so it becomes less costly to compute

stuff and more costly to uh stall stuff which is probably something we want but it's uh up to discussion uh just one last thing we did the same thing for all the uh PR compiles and we probably will do for the new uh BLS ple compile as well okay so that's uh that's it thanks yes I this is very interesting analysis thanks for sharing for whom is not seen it I think um super interesting uh there is one

question from kandra in the chat asking do the benchmarks that relate to loading from Storage take into account storage growth um now the sto the storage is uh very difficult to Benchmark especially if you want to do it in isolation uh so for any storage cost so in our assumptions all the storage is warm so it's already somewhere in the memory or in the cach and we only want to calculate the computational and operational costs uh for the storage as such the MX and nether mindes uh approach would be

probably better because you have the actual client running though and you measure the the client not the uh not the evm in isolation I see is there a question from someone else um I can make a comment that it could be doable but the effort to prepare the context for such tests that are testing storage up codes uh in a well proper good manner uh it would C cost a lot of a lot of

effort and uh as said it seems that Mark uh Marx approach is a slightly better in that case that makes sense uh yeah I guess I was also wondering about the modifications that need to be done to clients um using Marx one it's basically just a Docker file um so you don't actually modify the clients at all uh with this approach are modifications needed into the clients uh there are few modifications uh and we probably will ask a client implementation team to to include those

modification into the the code base but not big just mostly to to allow some benchmarking um I assume um s called s store and cold um SL load aside uh warm SL load would probably be the same as t- store or t Lo um good uh question uh it might be slightly different uh of trying to find out here but uh yeah

something we can uh figure out later I need to update my uh numbers first of all to the latest results and then we can uh uh analyze this yeah yes maybe you can share in the group uh once you update and then uh we can schedule another we'll definitely do yeah it should happen this week so fairly soon thanks I think we can move maybe to the second uh part where Anar wanted to like

present like discuss like some of the short-term changes related also to this yeah sure one sec can you hear me yes yeah awesome yeah um so for this section like it's I I I have less to to present it's not really about presenting I just wanted to basically um have some questions to to discuss with a group um and uh so I just bring them up I guess one by one and we can we can just talk talk about them um so I think pH um yeah as David was just just saying

right like there's both the questions of like what is our strategy here medium term over the next three four five heart Fox but then also specifically what can we do for um fusaka or um um um glamsterdam um and there specifically uh I think it it on the pricing side uh it seems like um there kind of this this uh just one time pricing effort that um that that um we just talked about with with a with a benchmark seems like a very strong candidate and so there I just wanted to uh talk a little about the different decisions decision Point uh points we we would have and and and and decisions that would have to be made

um so the first one of course would be um uh to me there's like three three three different types of of repricing there's just the the up codes among each other that's in a way like the least controversial right so we Bic just do the the setting of the of the upcode prices to each other um a little bit differently um then we can also like Haron try try to harmonize that with with with pre-compiled um that that is I think I personally think would be quite important actually to have that have like one shared kind of um compute cost across all of those um and then the question is also do we in general just want to allow for more compute in the block right so basically just um what what I would say like from the report

just now the the the more aggressive option basically um do we basically not just relatively make it make the the pricing different but actually basically allow for more more price more more Compu in the block so first of all basically just like be curious how people think about these questions like what should this kind of this initial repricing have as a goal um H how much do we want to go there I guess it makes sense to reprice everything so they're balanced and possibly remove any that are not needed but maybe that's a bit more

radical right and dragon I feel that it depends on the impact of the repricing if we repice all do codes and the difference on the Block size is 5% % or 10% I'm just like giving the numbers uh then maybe it doesn't make sense if the if we can reply some up codes and impact is like 50% we can like double the block size without increasing the gas then maybe it would make sense to reprise it but for that to get the information we need to have like uh to see how much the top is used

how much uh basically sample the data from the trade right so so if I uh can understand that correctly what you're saying is basically we need to get some metrics on given any specific new pricing schedule what would the actual real world impact given today's kind of usage um be like is that is that what you're saying yeah even if something is priced incorrectly uh it will not U if there is no incentive to change it we can live with it if something has the some up code that's not that much used then we have

fine to not change the price um but I'm seeing this in the context the changing price of any up go can be is basically um the big change makes sense Ben um I I'd see the more radical approach as tensible um however we need to bear in mind um that it would potentially increase block size by allowing more transactions through that we need to make sure the the handling was done there but hopefully Co data size fixes

that and and there your concern is basically that it would increase the average CH of blocks right because the the worst case size would not be affected because we wouldn't actually increase the gas limit and so and the call that up price would be unaffected but you're saying basically because compute gets cheaper there's just more room and so the average block size would would go up is that right um yes and also the the maximum block size would go up but however that's being brought down by the change in Petra but we just need to be cognizant of it that's all I see ah basically you're saying if we in addition to making pricing changes we also just increase the gas limit is is is that what you're talking about no no I mean with with the current current gas limit if all the op codes drop in gas price

well most of them drop in gas price assume we'd keep the cold um storage the same say um then there would be you'd be able to put more transactions in the block therefore that would that would increase the block size but hopefully that's been countered so so I'm not worried about the block size increasing I'm worried about hitting any limits for instance we're worried about 36 million gas being the current the current limit um if that makes sense yeah uh but I think so so that was another kind of

point I wanted to talk about like to me it seems Seems like it seems like a good idea that we would focus that we restrict the initial set of changes to only Pure or almost pure compute um operations up codes and pre- compiles um I think uh there is definitely this larger effort that that that that that we should um ALS and parallel run of like basically having a welldefined kind of Now new new new new set of pricing across all types of Dimensions including the storage up codes and including the the the the data and and everything but but to me it feels like an it it might just be a better more defined scope and something we can we can have more

confidence over if we initially only focus on the compute up codes and so the worst case block size would be unaffected the worst case State growth rate would be unaffected these kind of things is that a reasonable assumption or do people do people think that that would not be the right initial scope to F to focus on or it would it would still increase the block size by um allowing more transactions so your current transaction would cost slightly less than gas therefore you'd be able to put an additional transaction in there um however the the current threat we have on block size I think is should be um mitigated by the Petra change to call

data so it should be fine but it's just something to bear in mind yeah there's definitely like basically increased average case load at the very least um okay that's reasonable so sounds like people in general have have an appetite for basically allowing for more not not just basically making sure that we uh we we actually harmonize the prices across the across compute but we also actually can make compute as a as a unit cheaper um so far most proposals that I've seen have focused on on um basically using one gas as the kind of the new um floor um um um guas price but of course that means that there's only

so so far you can go in terms of making compute um um cheaper relative to the other up codes um I was curious if people so there have been these old old ideas around um I don't know ex maybe I think you're on the call right um there was can can you can you remind us um there was these old ideas around having basically like what was the name again some some other unit of gas that's basically like Milly gas or something but it had some nicer ethereum type name no the name was particle gas cost or fractional but yeah you can call it anything right and um I feel like you probably have the the best the context

out of out of all of us like is there do was this like an idea that was more like kind of like someone just put a name on it and that's it or or or did that already have like some some sort of work behind it or how that could look like yeah we we have an EIP for it as well um and the main goal was to have more Precision on the really cheap uh instructions where you would go below one right and the alternative to that I think asess I mentioned the last one um let me try to yeah so 20 45 the alternative to that if you if you want to go below one and if you if you don't

go below one then you can just uh scale up everything else so that's the other option right exactly so basically like that that that's um so so for for those maybe that that haven't heard of this particle fractional I mean right the hopefully the the the intuition is is relatively simple it's just about um tracking basically giving op codes say a gas cost of 0.1 gas or something and you do that by basically having a unit that's more fine grained and that basically accumulates and then once it taks over a full gas basically the actual transaction gas gets gets reduced or some version of this um you can you can have a look at the AP actually I will have a look at the AP I didn't I I I I forgot that that that that was

already in the AP stage that's that's really nice um and so indeed basically I think we have three options here either we basically just accept that we go to one as the cheapest unit and then we just have everything else scaled up from there um and then that means we just have like some sort of modest increase in in compute head room um that that gives us um or we basically use fractional uh gas um to to be able to to have the base be even lower than one um and and then everything else kind of relative to that so that that way we could basically scale compute room up to whatever we feel like however many however much gas we or however much compute we feel like you feel comfortable with in in a block or the third option as as as as Alex was just

saying indeed would be to basically just have everything on comput side be based on like one as the as the lowest um um lowest price but then then basically just like increase the gas limit overall and offset that by making all the non-comp compute operations more expensive in proportion and to me that seems like in a way the most heavy-handed approach because you you need to change all of these other prices as well but I'd be curious basically again that's like me again this call is more like about like when did you come pointing out all these kind of decisions decision points that we have and maybe already starting to collect some some opinions of how people feel like we should go so so here again I would be curious basically just a modest increase larger

increase with fractional or a larger increase by making everything else more expensive how do people feel about this Alex yeah so when we were looking at this um I mean each of them had the in pros and cons um but I think the complexity of execution especially combined with the the new consensus ler is such that the third option I think would be just way too much because you not only have to change the Pices of basically every single instruction but all the different limits and uh everything around um you know transactional block limits and this also uh slips into consensus so I think this last option is probably something

uh not wor doing right that M that matches my intuition as well um is is there something where we feel like maybe we would benefit from some metrics basically saying like hey if we go with the um basically the best we could do in relative in terms of relative pricing of compute based on like one G as the as the lowest uh price and then we look at um how much extra throughput that would get get us and how much physically worst case compute like execution time for the block and and then we see whether that seems reasonable or whether we would want to to to to go beyond that um is that something that that we think should

be more of a metric Sten question or how how do we how would we concretely make make make progress on making that decision for for the upcoming Fox and if no one has a strong opinion then I would just say that like I think I think metrics would be the the way to go and so then we are basically back to um what we what we talked just on the on the earlier Point as well that that I think one one type of metric that would be really valuable to inform a lot of this would just be um well one of course

kind of just uh worse case like how how how much can a compute only block how much how much how much basically uh execution time could it take but then also um how much impact would any any given type of of pricing change have on on real world usage like how much how much more throughput would we be able to have in a in a typical mayet block um so so those I think are in terms on the metric side good kind of follow-ups already um yeah then uh moving to the next point I wanted to touch on basically a big concern that has been raised in the past every time repricings have come up that especially repricings

that touch many op codes or many different types of um operations in the evm has been backwards compatibility uh in the past I think the ethereum main net approach has mostly been we are so Afra unwilling to risk breaking any existing contracts that we would rather basically make uh almost not like rather limit the changes we make to the bare minimum it feels like this comes really into clash with this effort here because um a it's actually not so easy to even get visibility on what exactly the backwards compatibility concerns here are for existing smart contracts that might have hardcoded gas values in some places um that's a pretty thorny effort to analyze well across all main

contracts um and then B also it just really kind of slows down any velocity of change sheet if we basically have to be very careful with this on the other hand of course even just risking breaking any any kind of contracts on Main it as as kind of weird and Edge casy as they might be um is of course not a good look so I would actually be curious here um a for people that have kind of touched that have been confronted with that issue in the past uh maybe around pricing changes um maybe talk a little about like how we've been dealing with this so far and then B how people here in the group think about about to what extent we should basically be focused on limiting backwards compatibility concerns and basically yeah ah okay good

because I was about to say if no one has an opinion then that my my default opinion that I'll set for the group is we don't care at all about back compatibility so if you disagree you should speak up and then um so I think increasing prices is more problematic than decreasing prices um because then you're going to hit unexpected out of gas more often um however historically I mean the prices have been increased several times and that was like where access list came in as like an escape hatch to um allow certain spark contracts to still work so we we have historically broken

things by increasing prices but um I think the risk with decreasing prices is is a lot lower that's reasonable um but I mean I feel like in some sense access list is an counter example because yes we were willing to break something but we paid a very very very large extra cost of of making sure that even the small amount of potentially affected contracts would have an skape PCH um by introducing access list which have not had any real world use other than other than that basically since um so I feel like that specifically would be the kind of approach here that that um would would slow us down a lot if if we wanted to be

as careful about it as as that but but you have a good point that of course here the the main impact would be making things cheaper um yeah so I guess I I I take it as that no one in the group is overly worried about backwards compatibility is that is it reasonable if if you wanted to be really spicy you could say that only EO e had lower gas pressure yeah that was actually the last point I wanted to bring up um UF so so we can we can we can jump to that in a sec but uh yeah first dragon uh in general it's inevitable we break gas in the future and we should break it it's not the we

should try to mitigate some breakages but in the end this is not something we can go around I feel there's like two types of the breakages that we can like um basically do with the gas changes one is different gas price uh gas sub code result is like the it's different it's different value push to stack there is nothing that we can do about it the second thing is uh different gas limit sent to the G to the calls I feel that we could uh increase that gas limit by some amount like let's

every gas limit that is set set for sub coal let increase it by two times then any gas um that gets incre any gas for do Cod that got increased will at least mitigate some some breakages on that part but either way it's inevitable yeah I think that personally very much reflects my own opinion on this as well um Tony do you have yes um I agree with that I think we shouldn't be limited by backwards comp compability um the only thing is that we should at

least be aware what things we break and that we can understand the impact right um historically this again in my memory has been has been a relatively hard challenge getting a really good understanding of the entire bread of of of mainnet contracts and how they could possibly be affected in different edge cases um do Tony do you have any specific kind of idea of how to try to have as high a visibility on this as possible or how you would approach this or is it just something that requires more attention more study um I would just look at the transactions for

example if let's say the last year has has had no transaction from a certain contract that uses some upods in a very fancy way then we might um just ignore it but of course that's difficult right because we don't know if very old contracts might be used in the future for a very unique use case unlocking some funds or something but yeah for for 76 to3 at least we basically looked into um a into a specific range um date range and checked all the transactions who would be affected and who not I mean it's it's only relevant if we would increase the cost of op code for

example to something where you could not even um call it a few more times in a transaction I don't know it's difficult but I think just looking into the transactions and checking um if they're using certain up codes or not should be enough yeah that seems reasonable although there is the tricky bit that like so basically naively you could just think well you just take the new pricing schedule and you just rerun the last year transactions and you see if any of them had would have any subs that now run out of gas that did not previously run out of gas or um vice versa um that basically had some sort of hardcoded gas that they sent into those sub calls um

that could be interesting um but they are comp complexities around that because uh of course you can have logic that branches on the exact amount of gas available and so you actually have to um yeah yeah it it basically you have to get an analysis right uh um it's it's it's it's not quite as easy as just rerunning and seeing if anything changes Behavior around um Subs running out of gas but but I think in principle that that is a a reasonable approach to identifying impact um yeah that's right um okay sounds like if there's also some messages in chat I'm not sure if anyone looks like too much for me to all read now so um unless anyone wants to

bring anything up on the call itself then and um yeah the next item that I had was um specifically around EF um maybe if someone from the the EF people a or some or I think we have with several uh on here on the call if you want to talk a little bit maybe about the potential ideas around um limiting some uh some all of those pricing changes to the newly introduced um UF um uh contracts um and then we can maybe could afterwards discuss whether that is a consideration that that that would be we

would uh want to continue exploring so one of the things eoff has on as part of its guiding principles is to reduce gas interest ction which is the ability to say I want to limit this amount of gas that I send to my next call and I want to see how much gas I have remaining um a lot of the contracts that we've seen that have been broken things like when we did the um increase into the storage costs um there were a lot of contracts that hardcoded certain values of the presumption and that since since that breakage has happened that's become an auditor recommendation is never hardcode gas values um but as far

as changing the gas schedule in eof because you don't have any way to react to it um changing it with any we shouldn't be a problem it's on the older the new gas schedules and if it is changing it does become a problem the solution is simple you just increase the amount of gas that you pass into the system um because there's no way to to lock in lesser amounts um and that's for eof contracts you know anything that goes through Legacy contracts as long as they don't limit the gas being passed in if there's a increase or decrease in eof then any changes in eof the solution ultimately would be to just increase the gas in your transaction and things should start working um which was not an option the last time you increased it because you could limit your gas to like

35,000 when you do your call which was something we ran into um but as far as the gas schedule I mean you know the idea that we could tie it as the initial feature of EF is is something I'm resistant to because there's a lot of things that might hold that back um because the idea of gas pricing is barely orthagonal to eof um packaging um we could make these decisions about where we want the prices to be and ship them in a later Fork even as a compatible softw we don't only have to change the version and we can just change the schedule there's also I think a higher level issue which I think was mentioned in the text of the um of one of the radical proposals is that clients are not necessarily tooled up um to do

radical gas schedule changes on this level um and so any proposal that we would do would need to spend time reworking the clients to make sure that they can handle um very radical gas schedules between different forks and if we limit it eof radical is gas schedules within Forks that are different so there's a risk there I'm limiting it into eof so um while there is value in in limiting a change of the eof and it's tooled up for it um it it brings in risk that I think it makes it question whether we should go down that path or not right so yeah so basically like with UF I think that's the this these two aspects there's the aspect of like UF

itself is nicely designed so that in the future basically SCH pricing changes are just very painless um and uh we we don't have to worry about these backward compatibility issues which which I mean I I think is one of the one of the many kind of elegant aspects of of of of of UF um and then there's this kind of the separate question just around um given that and given of course that we could want to incentivize UF adoption in some way is there any reason to explore um only like bringing at least parts of these pricing changes only to EF basically so so so EF would go live in

the next for anyway presumably and then um it could basically have a have have a different pricing schedule a more attractive pricing schedule um I personally my my opinion on that would be that I I just think that in in in a way kind of like making giving giving a one more throughput is is an important enough priority that I would prefer if that is not blocked by kind of whatever however long it takes for the ecosystem to to start moving most of the activity over to yourf so I I would personally prefer if we also bring all kind of Cheaper pricing to to existing um Legacy bite code but I'd be curious if if there's disagreement on that or if people actually think that

maybe limiting some of that that to EF only is could be an attractive option Roman my my personal preference would be for NSN storage related to be agnostic of whether we include this in like for it to be applied to both Legacy and EF contracts and any operation specifics to go in package with ef and to answer the thing the comment

in the chat that you have change is big already I think that should be a separate discussion whether we package anything with the next hard work or uh we start introducing in the hard work after have yeah I agree with I think both both parts of the statement but yeah in particular that's why I think um David also framed it in the beginning as like say this section talking about what we can do in the next two hard fors because uh I think we will have we should have that discussion it's an important discussion and we can have that over the next few months but I think for now basically we just assume that like

whatever the next slot is that opens up for like short-term pricing changes um how what what should our strategy be there and of course maybe there's a little bit more room that or a little bit more we could get done if it's two folks out than if it's one F out but but I think in principle for now I think the best approach is to just assume either of those two FKS um right uh so I I only just now noticed that we're already we close to Running Out of Time Roman if you wanted to say one more thing about this yeah just one quick thing that my personal preference would be uh to to deal with all of the storage up codes and uh Block Level R pricing in whatever the next slot is and and we can tackle

everything else later yeah that seems like one potential reasonable approach again I don't think like today is quite the right call yet to to to make any decisions or even even anything like that but but but yeah that seems like a reasonable strategy and um yeah I just realized that we are already five minutes before the end of the call um there was this entire kind of section on the the more medium-term kind of road map here I feel like maybe we more realistically have to kind of have like another breakout call at some point about this anyway but just to briefly wrap up this section the one thing I just wanted to to last say on on on short-term changes so far we only talked exclusively about um compute uh

repricing which I think is like an important pillar of the things that we can do in the short term um I wanted to briefly talk about if there's basically other things shortterm that people would want to already consider Roman already basically touched on this right now but so the two things that I saw was uh basically um G the gas Sheltering um and um uh basically some simple uh modifications to to storage um and so maybe I don't know I know that from the nether man side there there's been work on on the gas Sheltering so maybe if if if you could very kind of summarize that because that seems like a very reasonable Candidate For an upcoming qu yeah so um gas smuggling is where um so when you're C

see we get refunds by setting things to zero which is a good incentive on the transaction level however the way it works is that also comes off the used gas in the block and um setting something to zero is just an expens for the El as setting it to anything else um so the idea is you'd still get the refund however the refunds wouldn't count against uh wouldn't come off the amount of gas used in the block so um at the moment you can so if we have a uh 30 million gas with refunds you can take it up a block up to 36 million gas

and the idea is we should get rid of the refunds coming off the amount of going back on yeah decreasing the amount of gas used in the block so that the block limit is the block limit if that makes sense rather than because it gets worse as the gas uh block size increases so you know at 60 million gas it'll be 60 over by Six Million gas that you can refund through that's the idea yeah yeah and I personally think that makes like a lot of sense to address I know barab had some kind of work looking into into into the kind of the more kind

theoretical implications of of such an approach and had some I maybe not concerns but the basically some nuances um I'm not sure maybe maybe now is not the time to to go into them so but but I just wanted tole that that that's something that so but we still have to make double check that basically we we have a good grasp on how to best um make sure this is fully addressed but uh I think in principle that that's a reasonable candidate um and then the last thing I want to briefly touch on was the General kind of topic of um State uh re repricing um the one thing that I um have have been focused on that a little bit like T Tony Tony had a Tony and I have a draft EIP almost ready that

that would basically that that that's all about Block Level warming Tony do you want to summarize that in like um yeah I can do so yeah basically um treating um storage slots and addresses as warm if they have been already touched in an earlier transaction so this is kind of the tldr and I've been doing some analysis and it looks like we could gain about 5 to 6% sounds um sounds reasonable I would say it's not that much but um yeah another thing that would be interesting is thinking about which might be more complex but also U more promising which

is multiblock warming kind of keeping a window of warm slot open for a certain amount of blocks and doing so let's say we do have a window of 15 blocks then we have around 15% of efficiency gains so this is then quite significant I would say but yeah the first step might be to just warm on a block level and then move forward yeah and uh um Storm from um The W side had really good uh analysis I think uh on this recently right there's kind of this potential for multiblock um warming a caching basically of of of State um which yes multiblock is a bit of a thoria issue so

I think that should not be on the shortterm uh changes um path but I think I think the the the single blood block warming is is a very reasonable candidate uh pav I'm not sure how how much time do we have uh but I I I don't see how this multi block or like even single block warming increases throughput it just calculates the cost differently but the frut is the same well no it does increase super because uh a transaction that touches state that already um the the transaction before tged now basically gets charged uh I mean that's it depends on how you implement it right whether

you implemented with refunds or you implement it with maybe it's charge on the fly but you can just increase the the gas limit and it will get the same throughput increase instead of counting gas differently in the end you will do the same work on the database it just just have different accounting for it and that's it right yeah unless you mean it will incentivize like huge contracts to like kind of traffic all the all the I mean to to take all the traffic through some like basic contracts that will aggregate everything I'm not sure that's actually

desirable like go but uh yeah I mean this kind of incentivize like big big applications because they'll be cheaper but besides that you have the same database work to do anyway so you just modified the like accounting but didn't improve anything yeah I mean I think actually this is reasonable and like as you said at the beginning unfortunately like we're just literally out of time so we can't really get into this anymore um I I I I do think that like there's an interesting conversation here because yes what you're doing is by just expressing the underlying cost for the system a bit better that you're just

incentivizing now more behavior that is now cheaper priced and so then over time the mix changes and you basically do have more throughput but indeed depending on how you do it you wouldn't immediately have throughput using the existing U mix so so that there's some Nuance there um so I don't but yeah we out of time so we we'd have to have another call to to go into this and then also the longer term kind of uh things that David wanted to talk about more maybe last thing K if you you want to say something uh yeah I was just going to say what I wrote in the chat the tldr is uh maybe possibly we could consider pricing for ZK proving as well um there are some upcodes which are cheap in the CPU but

are harder to prove uh create a ZK proof for like Kat track for example um I think there's a EIP out that vitalic made so I don't remember the number that like 10x Catra to to account for something like this yeah I mean again out of time and this is I think a really important conversation because I don't think that's it's obvious at all that we should do it but it would be an opinionated thing and would have a lot of benefits but also would be quite costly so this is something we need to have that conversation though before we ship any uh pricing changes right if we touch pricing here anyway we need to have it embedded into in like a long-term strategy and that includes uh the the ZK strategy for L1 I agree with

that R of time there David do you want to like close close us out um sorry that I show your like uh time shot for that no no I think this was like an interesting much needed conversation yeah yeah and I think like the ZK proving related changes they kind of fit into the midterm changes that we can discuss uh in next call yeah so thanks everyone for joining today we'll probably schedule the next call to like follow up on like uh various topics discussed today and then go more deeper into the midterm changes yeah sounds good and in terms of takeaways the one thing that I remembered was that like I think it would be really nice if

we would have tooling of like assuming this different pricing schedule how much impact would today's main throughput how much would that basically impact today's main throughput I think that would be one thing that would be really nice to have um and then otherwise yeah I think primarily the the value wasn't sinking people but awesome okay then uh bye everyone and uh we'll have to continue this topic exciting thank you thank you byee bye thank you bye