EVM Resource Pricing Breakout #3

Transcript

[Music] Today we start with some more research topics and then we walk through uh some um EIP proposal and some uh discussion on shorter term changes. So the first on the agenda is Maria who's going to give an update um on empirical analysis of uh historical op code um usage for the multi-dimensional pricing research we're doing here.

Hello. Hi. Thank you. Uh so I will just uh share my screen and start right away. Okay. Um, let me know if you can see these slides, but I'm assuming everyone can. Um, so, um, I'm going to give you a quick overview of, um, this analysis we've started to do. Um, this is by no means complete. So, there's, uh, still some work to do here, but I I just want to give you an overview of what we are doing and then, um, some next steps.

Okay. So first what what problem are we trying to to solve here? Um as you must be aware um we have uh very different uh proposals coming um that in some way try to uh make changes to how the EVM is metering us um and these can be both updating specific uh op codes uh costs uh but also um a more uh long-term um research on using a multi-dimensional metering Um and in this um context there's a um a key question that we need to to answer which is um how do these proposals and

these changes to how we um meter gas and um how we decide what is the maximum um gas of of a block. how this impacts both throughput in terms of transactions but also the block uh utilization and um if you want to to to have more details on on what we are doing here I'm linking below the project proposal so you can you can check that out um but um a first focus will be um on these uh understanding this question from an empirical perspective and What does this mean? So, and this is the the first part

of our approach. Um um sorry, I was checking the chats. If there's any questions, if there are any questions, just just let me know. Um okay, but so the first part is a more empirical analysis where we are just looking at historical uh data and we are checking for uh blocks on Ethereum. uh what op codes were used and their costs and how um the block looks in terms of of of utilization. Um and then uh and this is more important for uh the multi-dimensional uh metering uh changes. So a a key part here is we have uh general costs by op

code but we need to split that costs into its different resources. So for instance uh memory um CPU or compute um history growth state growth and so on so forth. Um and so this involves for each op code we need to split that bundle into uh specific concrete gas costs per resource. Um and then once we have that we can simply estimate um the difference in gas utilization for different different metering regimes. So for instance using the the status quo that we have right now where we just add everything up um or we can make some

changes and using for instance a multi-dimensional approach where uh we consider resources in an isolation and um and limit them independently. Um then for part two so part two is to have a more ide have a more um robust simulation framework where um we can test different metering schedules um on hypothetical usage of the EVM. So not just looking at historical data but using uh being able to uh design scenarios. So for instance, say imagine that we have a certain number of um it transfers coming in and

then uh some transactions that are swapped in unis swap for instance. And you you you can design these tests of um of load on on the AVM and see um how the uh block utilization and the throughput would react under different metering regimes. Um and so the first step is of course we need to design these these scenarios. we need needed also to design the block building simulation. So deciding um assuming a certain man pool how would the block be built um and then um how would the maximum uh limit be be defined and this then enters in the gas metering schedule and then we can test

different gas metering schedules and here we can be a bit more generic. Um we can even test things like changing specific op codes. How does that impact block utilization? Um so not just doing this separation by resource type but also changing the the the cost of op codes themselves. And uh for this presentation I'm just going to focus on part one and uh show you some um um initial results on this. Okay. So um what have we done so far? So we we we've been working mostly on collecting and processing this data. Um so we started with uh getting a certain

range of blocks and then getting all the transactions for for each block and um and then we are using uh an RPC call for the debug trace. So essentially for each transaction it returns uh what would be the uh full debug trace. So all the op codes used uh and their and their uh gas um costs. Um this step is takes a long time because for each transaction we are doing an RPC call and for some transactions they are actually quite large so they have a lot of op codes um and they even don't fit in in in the memory in my PC. So for for some of them

I even had to skip them because um they were really really large. Um and then once we have this raw data we essentially need to do some some processing here to get accurate cost by by our code. And what do I mean by this? So when we uh get um uh a trace a debug trace uh we get something like this. So we have the operation which is the the op code. um we have what is the the the available gas up until the that point. Um so for instance um here we can see that uh we started with um 62,3 uh 92 and then this push operation uh spent uh three and so now we only have

uh less than three uh less uh three less than we had before. Um so we have 62 389 um gas units left. Um and so we can use this this essentially we could use this gas cost column to extract the gas cost per op code. But then there's a catch for some op codes. Uh I' I've noticed that this gas cost is not um accurate. So we need to do some calculations um on the gas um column to actually get the uh correct cost. Um and this uh depends on case by case. So depends on on on on the depth of the operation and the and the

op code being used. So um and this is still something we are we are cleaning up. So I I haven't completely um worked out all the all the all the uh cleanup we need to do here. Um, so there's still some some some mistakes there. And if you uh ever work with these and um or you are interested in working with these um just reach out. Um I've been um looking into this data now for a couple of weeks. Um so I'm happy to collaborate there and and share my code if if if you want to if you want to to look into this.

Um and so until the when we get to this uh point we have uh for a certain number of blocks um we can see for each op code uh how much gas was spent. So this is just um a sum over all the op codes and this is in log scale. So um um it's actually the differences are are a bit bigger but because we are in log scale it it seems a bit less uh different but um you can have a sense here of which op codes use more gas. Uh yes yes storm is saying nested call gas accounting is hard. Yeah I I've been I've been feeling that.

Um yeah so it's it's not just a call but also static call or delegate call and then depending on if you use if you enter a new depth or not the accounting is different. So that's those those are kind of the the quirks that um we need to to clean up here. Um okay so once we have this then the next step is uh so we already have the overall cost per op codes but now we need to do a mapping that for each op code uh gives us a formula of how to split that among the different um uh resources and for that so I shared uh a message in the channel um about this um

so I've started to do this in these spreadsheets um where some of OP codes were kind of obvious because they only use compute. So you can just assign the entire cost there. But then there are a few that have uh a multitude of of of resources and and some of them you even have to do some sort of um um assumption here. So it's it's it's not obvious um from the initial uh documentation which resource uh accounted for that cost. Um and so we kind of have to do some some some guesses here. Um and for this I also wanted to do a shout out to

Tyler from Offchain Labs. He's been also working on on these and he shared some information with me that I used them to complete this table. And um I have a first estimation here, but this is um not uh the like end goal source of truth. So this is definitely something that I want to continue to link look into and to confirm to see if this is uh correct and makes sense. Um but yeah, this this was also um one of the steps that that we had to to to go through. Um and finally once we have the uh op code costs and also this mapping that splits for each op code and their cost what is the cost by resource we can

apply these this mapping um and then aggregate by transaction and what we get at the end is something like this um where we can have for each block what is the total gas used in that block and also we can have a split by resource um and and you can see here that once we do a split by resource the the as expected the overall um uh uh gas usage for each resource it's it's slightly lower. Um I I should account I should warn that um again I'm still working on some quirks in the data. So there's still some gas here that isn't accounted uh and assigned um let's say and so uh in the

end this doesn't um add up completely but it already gives us a sense of um the of the different of the changes um when we go from uh the current regime to a multi-dimensional um access is state access rights exactly so it's the Merkel reads and those uh is is that that resource um uh yeah so I'm at the moment I'm not using the memory fields um because uh the files were already pretty large

um but I'm assuming I'm I'm thinking that I might have to use them to actually isolate the memory expansion costs from the the resources. So, it's something that I I'll have to to to look into at some point, but for now, I I just made some assumptions on what would be the memory usage by OP code. Um, but that's by that is by no means the most accurate way. Um, okay. So, if you are curious and want to see the code, I'm you can check it here. I'm also happy to um explain it and and if someone wants to look in into this in more detail, I'm I'm happy to to to have a chat and and collaborate.

Um another thing I wanted to point out is so a key part of this is going from the breakdown into op codes into the total cost. So kind of like reproducing the transaction gas cost. And by doing these exercises where I found some of the errors that I later corrected and I'm still seeing that there's some errors that are not completely um not completely um uh correct. Um and uh for this essentially uh in theory we could estimate all of these things. Um so we have the total cost which we can get from um um from uh shatus which is a a data um um the data that is provided

from the ETH panda ops team. Um we can compute the op code cost as I was showing you before. Um and then for the input data costs um we we can also get this from Shatus canonical execution data. And finally the gas refund. So this one is is a bit harder. Um so for this what I did was I had the other four components. So I just did the difference between them to get the gas refund. Um and um this is where I noticed like some gas refunds were negative which is not possible. So we are definitely missing some things and some of them were higher than 20% which is also not uh possible

because gas refunds have have a limit on um 1/5if of the total transaction cost. And so this is this is the point where um I I've noticed and this is around so far in my analysis like 6% of transactions are showing these weird um refunds and so it's those that I need to to clean up. Uh and before I go to next steps I see we have more message here. Um okay some tooling. K thank you Joseph.

I'll definitely look into that. And then what client I've been So I think it was Aragon client. Yeah, it was the one from uh Shatu um for the traces. It was Aragon. Yes. So Shatu was for getting the transaction from the block to the transactions and then um the other ones um uh the other one was was edibar. Uh then draw some settings cards. Um yeah. So I I def I yeah maybe we can I can check this after. Um but definitely um yeah I'll I'll I'll I'll check this these these um tips there on on how to

fix this. Thank you. Um okay. So just um for next steps um is the the first one is to continue to improve on the gas resource mapping. So a a big thing is like trying to isolate the memory expansion costs. So a lot of of of uh op codes would be fairly easy to split if we were able to isolate the memory expansion costs. And so if if I have some way using the trace data um to isolate these then a lot of the op codes would be much more uh accurate. Um the second one is like how do we split the increasing costs? Um so I'm assuming they initially were not just for

compute. Um there there must be some other costs that were so there must be some other logic there to to get that number. So, um, this is an open question to me that I'm not sure. Um, and then also again reviewing these splits and, um, and see if if if it makes sense or if I'm I'm missing anything. Um, and then as I was telling you, the idea of investigating some issues that I found with the single op codes. Um, so for instance, one of them was create and create two that they have some costs that seem to be too low. Um and I I need to kind of investigate why why that is happening in some transactions and then others where the refund uh the estimated

refund would much higher than 20%. So it must mean that we are missing um some costs. Um and finally um then once this is all cleared up I can just run the the the code and using more blocks as well and test different resource combinations for metering and then compute resulting block utilization. Um thank you. So if you have any idea on how to tackle these issues I described uh please reach out. Um and um yeah, thank you for your attention. If you have also any questions, just let me know.

Hi. Yeah, thanks Mario. Um I'm going to move to next uh presentation. Um yeah, just a reminder that we are targeting like around 7 minutes uh for a presentation. I know in this one there were a lot of questions in the meantime, so that's okay. I'll also take that into account. Uh but u yeah. So next up uh we have Evo. Um he's going to talk about like um how we can uh potentially like take into account prover cost uh when um pricing like some hash functions in particular. Um yeah I think this is very interesting work like relevant for L1 potentially also for L2 gas pricing.

Yeah. Hi everyone. Uh I hope you can hear like hear me and see my screen. So uh like essentially what uh what I have been doing uh or uh what I have been doing is to like estimate what is the like actual approving cost of the like hash functions uh like in like in Ethereum. So let's say like on a high level like what is the issue is that let's say the the cast estimates for like different up codes and pre-ompiles they're like essentially based on uh based on native execution speed. So like how fast the transactions can be executed like natively on on a computer. But uh if you would to execute the like similar

transactions or if you if you will try to to prove similar transactions like in in like CK based systems then like there is actually like a a lot bigger mismatch and so for example particularly for for hash functions and like mostly the issue with the hash functions is that the the native execution speed is is very fast but uh like in in in CK it is not and in CK because like there's the mismatch between like different fields and uh there is actually like a lot a lot to do. So the the the brewing overhead there is a lot bigger. So I started um uh I started my work on uh like uh I started my work based on EIP 7667. So this is a this is an EIP like

essentially like only to let's say to modify the cast cost of like hash functions but like actually like this issue is like it is also like relevant for like different top codes. uh so let's say for pairing like pairing or let's say elliptic curve uh pre-ompiles and also like some other uh some other outputs uh I would say like additional motivation like for like for it is like is uh is based on like roll-ups so it it's it's based on let's say native roll-ups so through the execute pre-ompile and so the execute pre-ompile uh essentially like what uh what it would introduce is is a way like for for for a rollup to become native. So a rollup can like essentially collect the

transactions like can sequence it like as they wish and then they just post the transactions with the like pre like pre transaction state root and post transactions state root and then like L1 can just like verify if this transaction is correct and then we would have like we can omit like essentially all kind of uh let's say the L2 overhead so for the proving or like for for for running the L2 themselves. Uh so in in the current uh let's say in the current proposal uh like essentially like to to my understanding is that let's say this execute pre-ompile it will base or like it's its cost will be based on the let's say gas gas usage of the transaction which are verified and like on on a lower level they they they would actually be u uh proven and then

they would be like separately like verified by like other validators. So like not not all the validator validators would uh re-execute like all all of these native rollup transactions and uh like there's also like I would say an a benefit for LJUs. So LJ can can then let's say if the gas cost of the hash functions like it is aligned with brewing cost then like they can lose the limits on let's say this arbitrary limits what they have on the number of hash function calls what can be what can be called inside the transaction.

So in in addition to like what I have done so there is a lot of I would say like parallel work. So like the just I would say I think it was yesterday uh corner like released some results about like some other up codes and like there's the ed proofs and so on and u some work is also done by a layer. So let's see if there's something in the chat. Um uh so what I did is uh uh I I looked only at the like hash functions and so I sampled some like uh some sample range uh from the uh from Ethereum. So it's it's like 670 blocks and uh I like it's not that much. So it's like about like 2

hours of transactions. Uh but like essentially like the the range is small uh because I I I wanted to prove like these blocks and it is somewhat timeconum time consuming and expensive. But when I like when I traced like all of these blocks and like all of the transactions within the blocks. So what I saw is that like actually uh the like hash function like you like usage gas wise like it's not that big. So the the biggest uh usage was for ketchup. So ketchup uses like about 0.59% of the total gas in the transactions and everything else it like it's basically like I would say a rounding error. Like in my sample I didn't have like any plqf pre-ompile codes. uh but uh when I'm looking at like some some more

historical data then there is like then there are like some some calls but uh like not very much so I I was essentially able to identify a single uh smart contract like which calls the black to uh pre-ompile um I also I I ran the SP1 prover on on on these blocks. So SP1 it's a it is a let's say a proving system by saxin labs um and like it uses let's say a modification of of rest um and u yeah so like essentially like it proves the execution of like of rest execution client and I run it like using the GPU back end so like there is a big

difference actually like if you use GPUs and CPUs and so what I was able to see is that um uh like with SP1 so the average cas gas per millisecond. It's like 64 gas per millisecond and like it distributes quite nicely but there are like some obvious like outlier outliers. I I also uh so my first like hypothesis was that I I'm able to like distinguish like what's the proving overhead like for this let's say average blocks uh like from the sample blocks I I had and u uh so like when I measured then like the brewing overhead was uh 0.4%.

So like if like if I would like let's say prove the blocks uh with proing the ketchup code and without proving ketchup code then like with proing the with the ketchup codes so it was like 0.4% slower. So the overhead isn't like very big but like we have to consider that the ketchup usage like usage on average was quite quite small. So instead uh I I I took an like uh alternative approach. So uh I I I I ran a local dev net uh like on my machine and I'm sorry on the on the brewing machine and so I constructed blocks like which are like full of this like hash functions. So I would I was targeting 30 million gas and u so I I want to see

like what's the like let's say the the brewer perform performance on these let's say age case blocks and uh like when we compare uh is that for example for kak when on average let's say on average block the the the brewing speed is like 64 cast per millisecond then like a block full of kak is 30 like 23 and similarly for shot uh for rimd like actually uh what like what I saw is that like ripe MD like let's say it is underpriced in the context of proving performance but like the issue is that the RIP MD like itself it is like it's very like highly priced so and RIP MD like itself being like quite uh easy like easy functions what to prove uh the biggest issue what I

what I saw was with Blake 2f uh so with blackf um so the the the problem is with QF is like essentially that like I'm able to modify the internal number of rounds inside the pre-ompile or inside the black tof call and I I can like set it up like to like arbitrary like high value. So because the let's say the internal round cost like it's like it's one cast per round and like when I set it to like 29 million rounds then essentially I wasn't able to prove the like I wasn't able to to run end to end prover and uh so I I only ran like one small part of the prover so the the core part and uh like there I saw that like essentially the overhead overhead is

like 20 times and like based on that u u I I proposed like some different changes to to EIP 7667 uh like to be more aligned to like what is the actual brewing performance. One one more issue what I saw was that like for Ketchup to Kak op code is that like the dynamic as cost like it depends on the on the length of 32 byt words but like actually let's say internally ketchup works on 136 byt partitions and uh so brewing wise like it doesn't like it doesn't make a big difference when like the if the input is like 32 bytes 64 bytes or like 136 bytes. So the brewing cost is the same. So for example if like if you

would be to uh let's say uh change like how the dynamic cost of ketchup 2 I'm sorry ketchup will be uh computed then like actually we like we are able to run uh or like use ketchup in like more efficient manner. So for example, we can build wider Merkel trees and uh this would like instead allow us to do let's say less hashing and uh like maybe even if you would increase the ketchup gas cost then like the the actual number of ketchup calls will be less. So it will be uh um offset by that. And finally, I also looked at like some like real life transactions like which like which used the most gas and like what is the like

possible uh impact on like these transactions. And so for example when I was looking at like different contracts and the different transactions I can see that the uh for example the the biggest gas user like within the sample the range is for example unis swap router. Uh but it doesn't like it doesn't relatively use like that much of gas. Uh so it's like it's still uh uh like it's still like at one like 1%. So not particularly uh I'm sorry it doesn't use a lot of gas for hashing. So like even if we would increase the gas cost by by three like for ketchup then uh the impact uh relative impact like wouldn't be that big. And I also looked at like different transactions by different senders and so on. So like all of this

data like is available at the at the blog post what I posted on the on the telegram channel and that's it uh uh from my presentation. Uh I'll have a look at the questions. Um uh so let's see uh the first well first one um I can see are there like any new new questions about my presentation? Yeah, I can maybe ask a question Evo like um I remember in the group chat there was a discussion around the fact that um the repricing um proposal from Yask uh will already take care of like some of uh the

adjustment uh of cost like um yeah do you think that um like we should edit that or like um that would be sufficient or this is like something uh else that like can be entirely proposed. Uh so I I I I had to look at the the EIP. So like essentially like to my understanding like for example like for Ketchup it was that like the let's say the ketchup um let's say static and dynamic cost like will be essentially the same but let's say the base let's say uh a cost of u let's say the the base cost of one gas like it will be uh

like decreased like by three. So like essentially let's say the the relative cost of like ketchup against like other op codes like it would increase by three times. So it would uh I think like it would align uh or like it aligns a bit but uh like another issue was that like it also like decreased the relative cost of ripe MD for example. So like it would like it could make RIP MD uh uh let's say um uh RIPMD more expensive to prove because like right now the the like RIMD pre-ompile it is uh let's say it is like it's not objectively uh priced right now.

So it it would help for for ketchup and shot but not for ripen and lake too. Got it. And I think there is a question from Gary then we can go to the next if you have like any comment on that in the chat. Uh let's see. Uh okay. Uh so yeah so it like uh so right now like right now it is uh so that it it is like a layer to your concern but like there's still I would say like there there is a a discussion of like snarkifying like L1

uh and then like if like if like if that will be the goal or or like let's say longterm long-term target then like uh let's say aligning the proving cost with the with the gas cost like it would be important And for particularly for the like uh like as I as I described for the execute pre-ompile so the execute pre-ompile uh like when I was reading the the proposal it was like its gas cost what would be based on the let's say gas usage of the transaction itself. So like then it means that the u the proving cost and the gas cost will be would mean would need to be aligned.

uh and uh yes the L2s could have different gas schedule but like it would make uh let's say from like from Lena's point of view so what we're trying to achieve like we we try to achieve like let's say full compatibility with the with the with the like EVM specification so let's say for example if we would have like some different pricing for gas so it would make let's say the developer experience or like already somewhat more difficult so let's say like if we have some uh some some implementations like which assume some cast cost or like which we have like where we have some limits. For example, when we do like the pre-ompile calls, we like for the pre-ompile calls like we can provide like how much cast we provide or like how like how much gas is provided like

to the like to the static call. But uh like in that case we would need to change that and like if let's say if some libraries or like if some some uh tooling like doesn't support that natively then uh like essentially it means that like this tooling needs to take into account some particular specifics of like different LG but like this is this is also being discussed. So there is this um let's say uh like roll up K uh uh proposal which like essentially like is to like is to have let's say a different execution client like which is configurable like better like par got it yeah this is very insightful thanks you know Evo um yeah uh if you can unpresent uh yeah um

um yeah so I'll go Next, I'll um You can see my screen, right? Yep. Yeah. So, I talk about uh EIP762. Um I think this is uh slightly different from like the uh EVM resource pricing but like um it still falls into like the resource pricing bucket for Ethereum.

This is about blobs. Um and I think um yeah I'll give like a quick plug overview on this proposal that we are uh proposing for inclusion in Fusaka. I think for this group like this can also show us like essentially when we start to uncoupling these resources and like come up with like pricing mechanisms for like some specific resources that we need to really understand what like the demand and the consumption for those resources are right like similar to what Evo presentation from before right like who's really using uh those like um hash op codes etc uh so yeah I think that there is kind of like um some connection for uh this group. Hopefully

like this is useful. Yeah. So uh 7762 essentially does a very small change which is increases the mean fee per blob. And um I'm going to argue that we need this simple change uh soon. Um change is very simple. So like there is one parameter change. So the mean base fee goes from one uh to like still a small number but like uh much more in line with what the equilibrium price uh is. And then there is like two small changes which is essentially we need to reset the um excess blob count when we deploy this change to avoid like a spike. Um uh but like this is uh like a simple reset basically as you can see

like a few lines. um it's not going to take too much um uh resources and I'm going to argue that this is like really uh needed. So about two years ago like one year before EIP44844 was deployed I did this analysis is a very in-depth analysis on uh um simulating how the market will look in the future and the main point I discovered is that essentially the price is going to be at one at the minimum for a very long time like my my estimate in this analysis was like 8 to 10 months.

Um and then this is the figure on the left. So like uh the price is zero for like many many time steps and then like on the right the other thing is that whenever uh we hit the uh congestion then like the price is going to spike exponentially like uh and this is can can cause some instability in the system. So already back then I was proposing like to set a higher minimum price. Uh but this was uh like uh opposed and kind of like uh really like hard by like some of the core developers like they were arguing oh it's hard to imagine that blob prices are ever going to be at minimum price uh because people will start deploying things but in reality

uh fees were at zero uh for 10 months and then they are still at zero. is still problematic and and the reality is that there was a misunderstanding on the demand, right? Like essentially the demand for this blob the organic demand only comes from uh uh layer 2 uh chains which are very inelastic to price right and uh essentially the load had to increase. So like what is the problem uh here right? So there there was like this big problem that like when we were like um very overs supplied in terms of blobs from like March 24 to November 24 like uh the price was essentially always at the minimum. Uh and then when when we were during this time already sometimes we were hitting like uh there was some

event like some NFT drop. This was like the uh it descriptions that then quickly went away. And then there were a few others where like um we experienced in this problem that like the the price takes a very long time to spike up and for some time there is a flood of uh blobs and like um uh in the me like uh I believe like some of the issues identified um were like uh at short-term patches now but um my point is that if you look from November to today right like um we have been talking about price price discovery etc. But like what is happening is that the fee still often goes to zero, right? And actually it

goes to zero like every night if you look at the uh bottom left chart. Uh this is like from Monday night. So essentially at night this is like US time. Um uh sorry this is UTC time. uh this goes to zero and then like every day like there is this period of like quite a few minutes where like you need to uh discover uh price again essentially. Um yeah so this is uh not ideal mechanism and recently like um this is I'm going to report some data from the recent AMA like um due to the incidents and due to some other like consideration like there has been some

consensus building that um a higher minimum blob fee u may be needed. Uh so yeah this is like excerpt from Vitalik Asgar also um uh talked about this pointing like to some of uh the proposals um also Dankr which was initially opposed it's it's it seems that um uh now is actually like in favor of this change right like I think the market has shown us that like um the current mechanism is not um ideal and people are realizing this Oh.

Oh, sorry. Yeah. Um, then I want to make like a small plug here. I know this topic is um a bit uh contentious, but like if you look at what happened with its supply since we ship 4844, it's um kind of reverse and we are back to um uh kind of like uh this supply inflation regime. This is because like um essentially like um all the burn that was happening before from L2 transaction is not happening anymore.

Um I'm not going to discuss this in depth today. This is not the main motivation for this change but like I have like some um ideas on why uh for the economic sustainability uh of um um of it um a minimum price makes sense. And this is not for burning more ETH is just to make sure that the people that use the network pay for the cost of the network and not like uh the olders or other people that are not using the network. So if someone is interested in this I'm happy to like uh discuss and follow up. Uh but essentially to summarize uh the proposal is very very simple like

um today we have this min fee equal one which is problematic. The main reason is that there is inefficient price discovery and like uh some um uh flooding of meool. Um there is um pburn like I put it in parenthesis because like this is not the main motivation but like there is some concern uh there as well. And then like um um this is going to be a sustained problem right as we scale blobs like 5x uh in Petra then 5x in Fusaka and then again like essentially we're going to hit again the regime um where like we are very very overs supplied and uh uh blobs are not congested. So like congestion pricing

like doesn't really work when you don't have congestion. Um so uh we can fix it with this simple change. You can think of it as a reserve price right like is a slight improvement of this mechanism. Um ideally like we would like uh a better mechanism and there's some ideas that are already being proposed but this will take a long time to be implemented. These are big changes right like uh like 1559 was like a major change. It took years. So, um, my pitch would be to like we can fix the current one with this simple change and then we can have the time to like really like nail down this um, uh, blob resource pricing mechanism.

Yeah, if there are no questions, uh I think um Yasak can uh give an overview of his new proposal. I'll respond to like the other question in the chat. Yeah. Um, sure. Give me a second. I um I the light screen to show um Okay. Can you see it? I hope you do. Uh uh light. So uh to the mind quickly what we do here is that uh uh we compared the current gas cost to the uh actual CPU time that it takes to

execute uh certain op codes and pre-o compiles. Well in fact all op codes and pre- compiles. uh and the fall by nature this research uh focuses on the computational uh complexity and computational uh time. So we're not taking into account any uh network cost uh state uh uh expansion storage access and so on. Um and we uh had this uh number of number of benchmarks across seven EVM implementations. And uh our research has confirmed uh intuition that many people had that uh uh

EVMS are actually getting more optimized and uh for many op codes it's uh it's actually cheaper to uh calculate stuff. So therefore a loom for uh lowering the cost of it and uh and also uh by doing it we can get a right balance between uh op codes and uh state access cost and memory and uh so on. Um so uh uh we got some uh feedback on this uh and uh the EAP has been simplified uh a lot now uh added a lot

of explanation why we are doing certain things and so on. But uh to summar what what we have here for the most basic op codes we plan to change the cost to base which is uh one. So any um arithmetic uh bit operations it all goes to one plus uh all those stench uh additional op codes and of course all the pushes uh dupes and swaps all goes to one. Um then for the other op codes I need to go come back to this uh table here. uh we said uh a number of other

things to get the right balance between things a number of other things has to change. Uh for example the access cost is um uh okay we we have to split it here between the warm and cold access cost. The cold access cost is something that we don't touch at all because that uh uh involves getting the data from some kind of a storage on a computer. But one cost is might be treated as computational cost because it's a data that is already uh cached in EVM uh somehow and uh uh indeed our research confirms that accessing any one data

that being an account or any storage slot is much cheaper. I think currently is uh priced at 100. we propose to change it to five uh gas. Uh then uh our research and other research as well uh has confirmed that uh the memory access is uh cheaper than currently u uh costed and we uh well the memory expansion cost that requires a bit of explanation. So uh at the moment it's made of two elements you pay for each world that you uh expand and there's uh a kind of a security guard which is expansional uh

cost which prevents from the abuse and overuse. So because that memory is so accessing memory is so cheap what we propose it's actually remove the per world uh cost and leave only exponential uh security gate. We've uh if we go here we've done some analysis it's actually not so bad. uh we can um uh prove that uh lowering the memory expansion cost doesn't really uh bring any any attack vector on the network. Um uh what else?

Ah okay but by by uh changing some uh or lowering some of the formulas for example the access cost and the memory expansion cost then uh uh other op codes which we don't change directly are actually uh affected by uh formula changes. So there are going to be uh lowered as well uh especially things like the calls and calls to pre-ompiles because pre-ompiles are always warm. Uh so calls might uh become cheaper.

Um we propose to change the three of depiles to lower the cost because um the that's what our starch confirms what we don't want to change are all the hashing uh uh pre-ompiles and uh ka cop coach uh because as evil has showed we either increase uh the cost of hashing pre-ompiles or we uh decrease uh everything else as in our proposal and then you still have the right balance.

there's uh I'm not going to go through all of it. Uh but that's uh all the explanations that we have in this uh EIP. So uh and designing uh uh for our decisions. So I do recommend leading it uh uh to everyone. Thanks Yas. Um I think um yeah this is great progress. We should like discuss more in depth. Now it is out. I believe there is also the Ethereum magician uh forum uh post attached to this that uh we can take this discussion to. Yeah. I was curious if um there is any points that people have raised that um are kind

of the most important points of discussion related to this EIP that you want to highlight here. Um the the hashing decompiles were the main ones and therefore after some uh discussions we decided to remove them from uh um from this EIP because our research has uh showed that some of the pre-ompiles might uh in this schema having this u new uh balance some of the pre hashing pre-ompiles might be actually benefit from lower cost but then some security concerns and uh some kind of an abuse concerns of uh the hashing pre comparison. So by leaving

them uh at the current level cost level I think we we achieved the right balance and also we open for any future uh changes. Got it. Thanks. So with the last five minutes we have do um we can go two minutes over since we started. So uh do if uh you are ready to present then uh you have uh the floor. Yeah if I can get the screen. Yeah. Yes. Can you unpreent?

Oh sorry of course. Uh yeah. So what I want to get is a quick temperature check. This isn't a fully out um idea. Uh well it is. I mean the idea is fully fleshed out but the rationale and leg work hasn't been done for it. But one of the things I think we should consider for memory uh charging instead of Ethereum is to go away from the current nonlinear format and go for a page costing format. Um this will simplify the gas schedule for people using on smaller and make higher memory access within u higher higher number higher index memory access usable which would increase the general utility of memory for programs. For example, they could use the higher level memory to use a real fat and not have to worry about

colliding with things. Everything wouldn't be heatbased. So the the high the high level design would be that the high bits would determine the memory. Um if we set the page at 32 bits, the lower 32 bits would be the index within a page and everything above is the page number. Um the gas schedule will be linear within a page. Um something like one bite per gas. So as you grow within a page, you charge more. And then the nonlinear part comes from the number of pages. And that accommodates the need to do stuff like a um like a binary search to find your page when you have to access memory to keep it reasonable. Um reading would be charged access outside of page zero.

Page zero can be kept special to make sure that you know reading different page memories doesn't become excessively um underpriced. If anything will be overpriced if you used you know a thousand different pages which I think is fine. We don't want to encourage too many pages. And uh we would you know if you read across page boundaries you would incur charges for both sides and if you read across an empty page you don't create that page. So that's like the high level gist of where I think we should go with the page gas and that if you use pages beyond page zero which would represent the entire state of what you can do in Ethereum right now. Um you'd have nonlinear access charges um but the growth would be linear and the total size of memory that be kept within a call would be limited by the linear

rate to however many gas per bite. So 15 megga gas 15 megabytes of memory is the maximum you'd be loading and you know we punish you if you use an excessive amount of pages gas-wise. So that's something I want to get a temperature check if it's worth pursuing and getting stats on or if this is too complex and needs a rework. Uh Charles uh can um pretty excited to have or I'm like looking forward to memory getting like better pricing. Um I think that the

quadratic term uh even though it looks nice in terms of like limiting um gas usage or sorry memory usage um the if memory is totally linear actually I think that makes it a lot easier to reason about how much memory and how much gas a transaction can use cuz right now otherwise you need to like do this whole thing where you simulate um recursion in the recursive message calls and stuff like So I think it'll be like I I I actually um did some back of the hand calculations and if you charge something like um 25 to 100 gas per page um an entire transaction can use like 1 to

4 GB of memory which sounds like a lot but it's like the entire EVM is how much clients or sorry users can use um and that's like a hard limit. It's based on the gas the gas limit, right? I think the current ability of a transaction to use gigabytes depends on the fact that we're underprising the first few um bits of memory that we're accessing and exploiting a flaw in the nonlinear model and that we start too low. Yeah. And in other words, like that I don't really see a problem with having the memory limit for a transaction be like 4 GB. that's small for a modern

computer and you just allocate it and you at the start of you know when you start up the node and you will use it. Um there's even a scheme you can use uh with M map where you just like use the upper bits to describe which contract it is and the lower bits to you know represent the page and the memory address and then you can just like m map you know 2 to the 48 bytes or something and um let the operating system decryption So the goal isn't to increase memory

access across different contracts. It's to within a single transaction frame allow page memory. Yeah. My thing about uh linear costing is just that it's simpler to reason about. So should you go for a linear model for everything? I mean how do you yeah sketch it out because my concern is when it comes time to look up and do

different memories memory of pages um how how it's going to be implemented um clients are not going to have a linear access to large number of pages. you're going to have closer to um uh log level access to to getting to to more pages. Uh the the difficulty grows by login. So it's not linear when you go to large number of pages. So that's one concern we need to worry about is scatter attacks on creating thousands of pages, right? I mean, I think thousands of pages. You can also like have a hard cap of like, you know, one megabyte per per contract or something. Um, and the overhead to keep track of the

pages is is not very large. Um, maybe I can do some benchmarks. Would that be helpful? Right. The proposal I have to access it is the square root. Um then the nonlinear is just for for growth to discourage it. It's not necessarily tracked to uh resource usage and we could fine-tune that. Okay. So um it might take a few months but I'll get a more concrete version sketched up once I get access to um some memory uh telemetry from mainet.

Awesome. Thanks, Dano. And thanks everyone for joining and presenting. We are wrapping up now. Um, let's continue in the chat as usual until next time. Thank you.