EVM Resource Pricing Breakout #6

Transcript

Puja feel free to move over to the live stream as well. Cool. Yeah. So the first um presentation is uh from Maria. This is like overflow from like the uh breakout call number five two weeks ago. Um she's going to present about this proposal uh multi-dimensional gas metering uh that we put together and um we also started some testing. Dano has been like doing some uh great work on it. So perhaps not today uh but like in a followup um he can also like show some early result.

I'm pretty excited about this proposal because uh in some analysis that Maria did previously like it shows like we can significantly increase throughput. So uh it would be pretty cool for you guys to like um take a look and uh see like what would it take to implement this. Yeah. So I'll just leave the floor to Maria if you want to present. >> Thank you. Thank you. So I will just share my screen and then we can start. Okay. Can you all see this?

Okay. Um, so I have limited access to the chat. So if there are questions, please just you are welcome to interrupt me and um and I will answer them. Um, and also this was a presentation that was adapted from a talk I did at um, ETCC. Um and so we can maybe skip some of the of the parts but I will try just to give you an overview um fast and then we can have some time for for discussions.

Okay. So um I think the key point of this proposal is that so we since the beginning we have been using gas as um uh we have been using gas as fulfilling let's say two main functions in in the EVM. So the first one is um having a way to charge for resource uh consumption. So how much should users charge by the work they are asking the network to do?

Um and uh this function is what we'll be referring to as transaction pricing. But there's another function which is control resource abuse. So this is more related to users will submit transactions uh a block will be built and we want to make sure that that block does not go over some safety limits across a set of resources. Um and uh we also use gas for this um function and this is what we call block metering. So we are metering resource usage and we are trying to make sure that we don't go

above certain safety limits. And the point of this proposal is that for a long time we have been thinking of these two functions as the same thing or we've been using the same concepts to address them and they are actually different and we can use different functions and different ways of measuring um consumption to answer these two functions and um this proposal is essentially focusing just on the metering part. So trying to uh control resource abuse and we are leaving the part of pricing completely unchanged.

Um and so what is the actual proposal? So the idea is we introduce a new variable called gas metered and this is a variable that lives at a block level and during uh transaction execution we are metering the gas along a set of resources. Um here I'm I'm just using a general notation so we are assuming n resources. Um and this new variable gas metered is the maximum of the gas consumption across the various resources.

Um and so this is how this new variable is defined. But then we also keep the gas used and so gas used is simply the old formula where we just sum the total gas across the different resources. And so um on the transaction level everything remains the same. So we still have a single gas limit. The transaction fee still uses the same formula. So the gas used um and both the gas limit and the gas used are used to check the out of gas validity condition at transaction level. So everything for the user remains the same.

But now at block level uh we use the gas meters and so when we are seeing how full a block is to check against the gas limits then we use the gas meter. So we use the max function and also when we are doing the updates on uh the base fee um from EIP559 we also use this gas meter. the the max function and to understand why this makes sense. So let's start um with an example. So assuming we have a block with these two transactions and we are only interested in two resources for for simplicity. We are interested in state growth and

compute. Um and here we have transaction one uses 8 million units for state growth and 10 million units for compute. and the second 12 million units for state and 6 million for compute. Um so at transaction level again everything remains the same. So the gas used on transaction one is 80 million and the base fee or the component of transaction fees that um um are allocated let's say to the base fee would be the 8 million times the base fee set for the block. And on transaction two we also use 18 million gas and the the base fee is the same.

However at block level um now we are summing across the two resources. So for state growth we do uh the 8 + 12 so we get 20 million. Um and for compute we do the 10 million plus the 6 million and we get 16. And now the gas metered is just the max across the two resources. And so we get a a max of 20 million. And this means that with a 36 million gas limit, we get the block utilization of 55%.

And this leads to a slight increase in the base fee of the next block. Okay, so this is just an example to sort of have a sense of the mechanics of it. But why should we even do this? Okay. So I think there's two benefits to to this proposal in isolation. So the first one is a better alignment between the block utilization. So how full the block is and actually the function of resource abuse prevention which we call the block block metering function. And as a consequence of this we also get a more efficient block backing. And so what do I mean by a better alignment? So um

initially the way that um the gas model was set up um was using these um idea of we have this set of resources and we have some safety limits for these resources. So for instance for compute um blocks cannot take more than 3 seconds to execute under some default hardware specs. Um and this means that at block limit execution should take um at most three these three seconds. Um and for state growth we say okay blocks cannot increase state by more than a certain level of a certain number of bytes. And so this means that when we are at block

limits we shouldn't see state increasing by more than these safety limits. Okay. Um and then what we what was done was um some analysis of um how much each operation would spend let's say or would lead um on each of these um limits. So execution how much it would take in seconds and for state code how much would it increase in states um and then we can do this conversion of translating from the resources to the gas units.

Okay. And um as you all are aware um even if all of this is perfect which we know it's not because there's some initial analysis um was not um done with a like a very in-depth benchmark um and also there's we know that there's some discrepancy between different um operations. So this is not standardized yet. Um but assuming this was standardized, this is how the the the logic uh would work.

Um and so going back to an example. So for instance in this example with a block with these two with these two transactions um where we have one only uses compute, the other only uses state. um with the current model our um gas consumption or the gas used would be the 36 million units. So we would already be with these two transactions at block limit. However, if we think about it actually we are only using half of each resource, right? Like if if the 30 million units is the third the 3 seconds then if we are only using compute uh for uh 18 million units then we are just

using half of that time. Um and so actually using a max would be a much better a a most a more faithful interpretation of how to go from the safety limits to the actual um block utilization which is what we are trying to do here. And because of this we also get a better efficiency because when we were setting the the gas cost and the the block limits and and and and everything because we are not metering resources independently we always have to assume the worst case scenario right we all always have to assume okay the block is only using computer the block is only

using state in that case what would be the the mappings we should be doing uh but but this is only a factor or a feature of the actual metering that we are using now because if we are using the max we would actually not able we would not need to assume a worst case scenario and so um in this case um we would actually be able to more efficiently pack the the the blocks and actually fit more transactions and this is the analysis that um the vid was referring to at the beginning where we just did a simulation of historical transactions and using um so what was the resource contribution of

each um of the blocks let's say so we we we picked blocks we split them into the different resources assuming a mapping between uh gas costs and the resource allocation um and then we saw more or less uh what what was the contribution of each resource and as you can see there's three resources that dominate so we have states, we have compute and we have state access. So these are the ones that are dominating at the moment. Um so a a note here on bandwidth which is the the block size. Here we are not considering blobs and call data. Okay, we are only cons actually we are considering call data but we are not considering blobs. So that's why the

bandwidth actually is not a big um component here. But so we have these three resources and they more or less use around 20% of of gas on the average block. And so this already tells you that there's some more efficient packing we could be doing. Um and when we actually do a simulation where we do a sample of historical transactions and assume that we have infinite demand um and we can pack as many transactions as we want using the different um multi-dimensional model. So here we have a set of two-dimensional models the the uh then we have a three-dimensional

which is state compute and others and then we have a four dimension which is state compute access and others. Um we can see that we get a nice increase in throughput assuming again infinite demand and that we are just we are not doing a lot of optimization in block building. we are just sampling transactions and adding them to the block until the block doesn't allow for more transactions. So we there could be more gains if we were to pack them more efficiently. Um but so you you can see here the results that we get a nice a nice skating in in throughput under the four fourthdimensional model.

Um if you want to read more about the proposal, I linked here uh the empirical analysis and also the proposal itself. We still don't have an EIP. So this is just a general proposal and uh we are now working towards um the analysis needed to do the the final um EIP and in terms of of next steps. So something that um David also said at the beginning. So a big um effort now is uh this major benchmark which I think it's it's a nice thing to to discuss here uh because I I think this is actually something that can pull together a lot uh of efforts that different uh teams

are are doing at the moment which is having a more standardized um benchmark of how the different operations use across the different resources. So we have a pretty good benchmark for compute but then we also need for state and for the other um resources and so we are currently working with Dano. Um and also uh the stateless team is working starting to work on a benchmark focused on states which is one of the I think the more nuanced ones. Um and so this is something that we are uh essentially working on. uh and this would be a major

input to the EIP because it will give us um what would be for each operation the breakdown between the gas for each resource and again it's an opportunity to do a more um uh uh so to pull together all the repricings we are doing and making sure that we have a uniform and standardized um allocation of pricings across different resources. Um and then we also have to do some prototyping still there.

I think there was an analysis um from the G team looking at the actual overhead of the GA accounting at the moment which and they said it was I think it was like 8% of execution time if I recall correctly. Um and so adding multi-dimensional uh gas might add more overhead. So it's important to understand that and see if it's if it's feasible. Um also there might be some optimizations we can do. Um and also this can also be um an an interesting point which is can we future proof these for future repricings down the line. Maybe um there's some changes we can do in how we define the the limits across the different resources

that make it a bit more futurep proof. If you want just to adjust the relative costs of of of the resources, maybe it's just you adjust a parameter and and and that's it. All the all the costs for that resource that get updated automatically. Um so there's there's some some some things that we can maybe um do here. And this is the end of the presentation. Um I know it was a bit uh fast because I I think we still have tons of other presentations to go through. Uh but I'm curious to hear any comments or questions or uh things that come to mind. Um yeah, so I'll open the floor and just Yeah, just put your hand up if

you have any comments. >> Yep. Ben. Yeah. Hi. Uh, can you hear me? >> Yes. >> Yeah. Hi. Thank you very much for this uh, excellent presentation. Um, I I have a question. There seems to be an assumption you're making and tell me if I'm understanding this correctly. There's an assumption here that uh, the usage level of any single resource sort of doesn't affect the safety limit of the other resources. So for example, if you take compute and state growth, then the safety level of the state growth in that particular block is sort of

independent of how much compute there was in the block. But of course the the amount the state growth operations can be interled with like the ordering of the operations can be interled with the compute operations and so I was wondering if you uh if first of all if I'm understanding correctly if and if you have any other comments on that because it seems to be a >> Yeah. Thank you. >> Yeah. Yeah. Yeah. So I I I think it's a fair question for sure. The way I see it is is true that certain operations have a mixture of costs. So you you have some operations that will both use compute

and state and state access for in state growth and and state access for instance. And so here is where I think the the the the benchmark is important. So if we say okay these operations take this time to run and then they affect state growth on this level um then you can clearly separate the two right you can put the cost to compute for that operation and the cost for state for that operation. I think where things may get a bit tricky is for instance you could think of state growth actually will have an impact on state access. So your the cost of state access depends on

the size of your current states. And so this could mean that in fact we may need to have some sort of more dynamic limit where a state grows your limit kind of goes down. But this doesn't mean that um you cannot differentiate for each operation what resources each operation is using. It's just maybe we have to have a smarter way of setting the limits. Um but I I think for most of them this should be feasible. I think state is the one that may get a bit more complicated but um let me know if you have like any

combination of resources that were thinking of that could be an issue and yeah I think it's it's still something we we we should um make sure we are thinking correctly. >> Okay. Thank you. >> Yeah. If you have like any any like if any combination comes to mind just pop me a message and I'll I'll I'll like to to think more about it. >> Yep. Um Francis, >> hi. Um is my understanding correct that with this new model, we need to configure a ga individual gas cost for

each of the like metering groups, >> right? So what happens now is we had a single gas cost per op codes, right? And now we will get um an a cost per op code and per resource. Okay. Um a a thing here is that most of the op codes are simple compute ones. >> Mhm. >> Um so if we were only looking at the op codes, it's around like 100 parameters.

And with this change, we would add more 50. So it would be 150 more or less just because most of the up codes zero on the other dimensions is just compute and then you have a few that have more than compute. Got it. Um so like for example for sore and s load you will have a kind of like a compute access potentially if that's a group and state um >> and state. Yeah.

>> Right. >> And memory as well. >> Okay. Okay. Like the the I guess the second question is that I saw that there's like a benchmarking effort that is going on here trying to like find the right configuration for each of those. Um, is this I I guess how accurate can this be and will it make the kind of like the future changes like kind of like hard >> I'm not sure I understand your question.

Sorry. >> Okay. Like for example for access it's heavily dependent on like for example the underlying database and uh hardware you use etc. So >> how can I how do you like define a correct amount for that? >> Got it. Got it. Got it. Got it. So on the hardware I think we will use the specs from I'm not I don't remember the name but there's an AIP that sets the hardware requirements for the different roles in the network. So we will just use that as the standard specification in terms of hardware. Um the question you asked the board about state is

actually a bit more nuanced and um this is something that also the stateless team are um thinking about and so the idea would be in my mind the should have a benchmark where we use the current state. So we have a sense of with the status we have right now what is the cost in IO. Uh but I think also it would be nice to have like a more future looking one that says okay if like if we uh have a certain limit of state growth per day what would this look like in one year, two years, five years and this is

again something that the stateless team can do because they have been working on these bloat net where they are artificially increasing um state and having like these these this um database with a huge state that then we can use to sort of do these sort of more aggressive benchmarks. And so I I think to me on the state question that's the that's the that would be the the right approach. But of course I think like having proper benchmarks will be key to make sure that this works. Um so yeah this this will be a big part of of of our work going

forward and yeah I think this group is like the perfect group to to discuss these things because a lot of different teams are already working on on similar things. Yeah, and maybe I want to add one more thing which is actually like having these benchmarks um is not only useful for this EIP like if even if this EIP is not in let's say that we want to do the repricing correctly right so the repricing should be done uh with this with this benchmark because like um uh today's costs even if there is like just one parameter of like how much an op code cost like there is an underlying

assumption for example for s store like there is an underlying assumption around like uh uh those underlying dimensions and um in fact like I think these benchmarks will be useful even to calibrate the repricing EIP on those op codes that are not compute only right because uh I think most of the exercise from YASK was around like benchmarking compute um yeah So I feel that um um we are just making it more explicit into the protocol. So um the increasing complexity like when uh this EIP goes in will not be that oh now we need to do benchmarks for like the other resources.

I think we will need to do them anyways if we want to push the performance. Um it will be that okay some of these parameters are explicitly in the protocol now versus just like uh putting like basically the uh the raw sum of like the costs uh of an op code if that if that makes sense. And um as Maria said like uh the since as you see like also in the table like uh most costs are zero because like most op codes are compute only like um the complexity does not seem to go up that

much like we will be going from like around 100 like uh um parameters to like 130 or 150 Um >> yeah, got it. Uh that makes sense. So, um if if there no other people has a question, I have one followup. Um for I believe the kind of like the this is kind of like a intermediate step towards like multi-dimensional gas market.

>> Is that? >> Yeah. Correct. >> Okay. Cool. Uh, and in that case I'm curious about the actually let me think about it a little bit. Um, >> oh sorry what what was the the question? >> I think >> sorry I need to think about the question a little bit. So if I move on >> but but but I can actually say something on that. So for sure this is a middle step between what we have right now and the full dimensional pricing thing. So again go going back to this idea of the two of the two functions right um but I

think the benefit of thinking of them independently is that solving for the for the transaction pricing is actually more complex from a user perspective. Um so because now you you you you get into the the question of okay do we let the user set individual fees or do we have some sort of mechanism to set them um automatically and if so what should be that mechanism so I think there's a lot of open questions on this part while for me the the resource abuse is a bit simpler and it already gives us some nice benefit um And so I think there's a benefit in

separating these two things and solving one of the sides that could be better and then have some time to think about the second part. >> Yeah. And maybe um I think this is actually an important point, right? like um essentially like one of the reasons I'm excited about uh this midtering is because essentially it's like one intermediate step towards like uh this like end game 1559 right that like also Vitalik has been talking about for like two three years and like before we stumble on this proposal like we're like

okay how can we make that work it seems very complicated like it seems that this is an intermediate step where like the complexity is not that much but still I mean like there is a lot of implementation details to figure out. Uh so maybe like I just want to prompt if there is like just a vibe check from other core dev on the call like uh uh how do you see like um uh this proposal like do you think um we are kind of on the right track by doing this benchmark? like do you see any other complications that could arise later that we can maybe like work on um to kind of uh make sure that uh we make

it uh ready for uh be implemented. Yeah. If you have any thoughts on that please uh share any question. Okay, it seems we don't people are generally uh not too much concerned. So I guess that's good news. All right. Yeah. So >> I will stop I'll stop sharing then.

Thank you. >> Oh, Angar has uh some question. Yeah. Yeah, maybe well question SL comment maybe or maybe curious about your kind thoughts there. Obviously that mine is also more a researcher perspective and I I I also I mean I already talked with with with you too about this like I really like this kind of this this general um uh multi-dimension metering as like an intermediate step um approach where I'm a little more on the side of treating it more as for now an exploration and less immediately like work towards a specific EIP is maybe just that um I'm still open to like the specific empirical results of like around um because because

obviously like many dimensions in in principle right now are still um comp competitive with each other, right? If if you map and bound and then that will change with the slot restructuring with EPBS um uh or whatever we will do there and whatnot. So, so I'm not it feels like the the the the details of how to ship that and how much it would immediately benefit are still a bit up in the air. It's more to me one of those things that I I see and I immediately feel like yes, this is the direction we want to generally go in. So it feels useful to experiment with as soon as possible basically like but not necessarily like with a high urgency towards specifically shipping it. I think that kind of is still TBD when and how exactly that that will bring the biggest value but it will also then be

like a requirement for many future things we want to do. So I don't know that's at least my take but I'd be curious whether you generally agree or whether you do think that you already have more of a specific clear understanding of it as a standalone feature. I don't know. I'd be curious. Yeah. >> Yeah. So, I I I think we we wanted to move as close as possible to an EIP just because I think it will help us to find things that maybe we are not thinking about now just by doing the exploration.

Um, and I think there's a there's a benefit in that in terms of the standalone benefits of this proposal in my mind is really this decoupling of um so we know that we want users to pay for the resources they use and that's why we use a sum for pricing. Um but for resource abuse we actually we only care about the bottleneck resource right like in any block we we we only need to ensure that we don't go over the limits of each resource and I think by introducing these marks function we are

actually making the protocol behave in a more accurate way when we are thinking about resource abuse and I think this allows us to better tune and repric the the operations in the VVM. And in my mind, this is the biggest benefit. And since we are already doing so much repricing and we are already doing all this work, I think we do a a an additional step and go into a design that actually makes a more faithful um representation of how we should meter the APM. So this is my kind of my view on it and why I would rather do it

sooner than later. But at the end of the day, it's like I I will not be the one implementing and during the final decision. So it's always there's always the IPs that seem more urgent than than others. But in my mind, this is kind of like the the the core benefit of of it when we think it in a standalone way. >> Yeah, maybe on my end like I agree with Maria. I think we can have a simple and clean uh EIP for multi-dimensional gas metering. Um and then uh yeah on what you were saying as I also agree in the sense like we are not married to it right in the sense like if doing these benchmarks uh and like um uh testing it we uncover that like okay there is

something related but is not exactly like the implementation we were thinking. uh then maybe there is like some other different or smaller uh changes that um uh uh come up and we can consider uh I think that's uh also okay right yeah no that that makes sense um okay I was really just curious I don't think I disagree with any of this I but it just sounds that that then you may be already more confident in it already as a kind of short-term standalone feature, which is is good. Yeah, I'm I'm I'm very open

to that. Just just wanted to check. Perfect. Thanks. Thank you. All right. Yeah, thanks, Maria. And um yeah, I think we can move on. Um charts um a few uh um things that he wanted to discuss. Um, Charles, uh, I'll maybe let you kind of structure this, uh, more convenient for you. >> Uh, sure. Should I share my screen or >> Yeah.

and let me know if you need any support. >> Oh, uh yeah. Uh let me pull up the links. Um, so I just had several uh kind of a hajup paji assortment of EIPs that I wanted to present to the working group.

Um, so I guess I'll just get into them. I've shared the first one here. It's um EIP792.3. Um, let me see if I can share my screen. There we go. Um, so this is kind of a proposal to fix memory pricing because memory pricing is quadratic. Um there there's a few problems with that.

One is it's um well for reasons that um Maria actually went into which is >> can everybody hear me by the way? >> Oh okay great. Um so as Marie pointed out we have uh gas for two reasons. One is for like metering right having people pay for the resources they use and the other is to like prevent resource abuse.

Um, so the theme of these EIPs actually is kind of like um or that I've started to like uh get the sense from talking to client teams is that we actually kind of want to have like explicit hard limits. So for uh quadratic memory, it's like actually kind of hard to figure out um for a given gas limit like how much memory you can actually allocate on the client. And uh there's various blog posts about this. You can like either do a simulation or like solve it analytically, but it's like really not super easy. So, the first thing um that we want to do is kind of have an

explicit limit. And that's in here somewhere. I think I just set it to like 60 32 GB. Um maybe some of the concepts are um the other thing that we want to do with memory is there there there were a couple proposals to kind of make memory not quadratic in the past. Um they usually involve allocating like a fixed amount of memory. And the reason I propose this EIP is because um we actually want page memory like virtual memory.

So that makes it much easier for compilers to implement more data structures. Um for example, on like normal computers, they've got the stack and the heap. And the reason they're able to do that is because they like grow in different directions. Um because memory is like paged. So like the operating system like gives you pages on demand. So you can actually access memory at like 2 to the 48 or whatever without like actually allocating that much and like um blowing up your computer. Um so basically the idea about the CIP is that it allocates it there there's a page table in the um

in the client implementation. So instead of having a continuous block of memory that you like keep on expanding um basically when the program touches a fresh page the client allocates that on demand and it keeps it in kind of a um a hash table of sorts. So I'll go right into the reference implementation. so there's two ways to implement it. One is you actually implement the memory as like a bunch of 4 kilobyte pages. Um and um

it's like a a map from like memory addresses or like sorry page addresses actually to like 4 kilobyte chunks. And then if you do like an M load and it crosses a page boundary then you have to like do the read of two pages and then fuse them together. Um and then the other way which is allowed by this EIP is that you actually just call Malik or Map and uh for most operating systems this actually does uh the same thing or similar thing. Um basically it gives you a region of memory um but it doesn't um eagerly allocate it. uh the pages get allocated on demand. So the pricing in this EIP is kind of based on uh a bunch of benchmarks I did on my laptop.

which maybe I should actually include the the code here in the EIP or in in the ETH nutrition thread. Um but basically I uh created various data structures and like benchmarks at times like you know access them or update them uh at different um kind of sizes and since um modern machines usually have like hierarchical memory. So there's like kind of um phase transitions, you can think of it like that where like the cost to um access you know some pointer in a 6 megabyte range is much much

faster than the cost to access some random pointer in a 32 GB range. Um, so the idea the CIP is supposed to like um threshing um the memory. Um, based on feedback I've gotten on the CIP, I think the maybe the most contentious part is that there's actually for gas costing purposes, there's another data structure which is an LRU cache. It's the least recently used like 512 pages.

and it's not really necessary. Um, but basically the idea is if you try to access, meaning read or write a page that isn't in the LRU fashion, um, then you get hit with an extra cost. And the reason I added it is because the implementation is not that complicated. You add like one more data structure and a few more lines in the gas casting um formula. Uh but it enables something which is like otherwise you have to price each page access as if it's an LRU miss. Um, I mean CPUs have like kind of LUS either

the L1 or C and then the T will be um there's caching in the page table. Wait. Um, so you have to cost it at the worst everything like six gas or 10 gas or something. My reference gas unit was like a shot 256 computation benefits are uh explicit hard limit for memory usage so that you

can Oh, by the way, the memory Oh, I'm getting choppy. I have some issue with my Is this the sound microphone? okay. I'll just kind of wrap up this one. So, the main global limit rather

than a message call limit. Um, so that you don't need to know anything about the how the call stack is shaped. Uh, maybe the connection. Uh, should I try changing the connection? Okay, let me try. Sure. >> Hello.

>> It's awesome. better. >> Yeah. Yeah, this is much better. >> Oh, okay. Great. Uh, okay. So, to recap, the benefits are uh transaction global hard limit. So, first of all, it's a transaction global limit. So, you don't need to know anything about how what possible shapes there are for the call stack in order to reason about the limit of memory that a client needs. And it's like 100 megabytes or something. Um so you know exactly when you're going to om and you don't need to do any simulation or formula or anything. Um the other benefits are for it allows users to use a lot more memory like right now uh basically users are

stuck in like 80s era memory basically um for practical purposes like you can extend the memory like maybe uh a few kilobytes before it starts costing an unreasonable amount of gas. Um and then lastly for compilers it allows us and for users too to be honest it allows us to implement much more interesting data structures than uh when you need to start allocating memory from zero and like stop after 4 or 16 kilobytes.

right any questions about this or discussion topics? Deno So what sort of um backwards compatibility has gone into looking into this? One of my concerns looking at this is that low youth contracts on the order of like you know 10 bytes are going to be charged 100 gas almost immediately um for their subcontract calls before uh before they even get access to one of their bytes. And since solidity famously writes to the beginning of memory each time, every subcontract call is going to be hit by an extra 100 gas in this.

>> Yeah, that's a really good question. Um, there's kind of two backwards compatibility things. Um I think so one is that uh the semantics of M size kind of change but um or there's a question about like what M size means but you can just kind of keep the existing semantics which is it's the word higher than the highest pointer touched. Um, as for small contracts which only touch one page, um, I was thinking that maybe we could just roll it into the cost of, uh, a message call, which is 100 gas, and that is supposed to kind of cover the cost of allocating, um, a bunch of things, including memory.

So, but do we have um analysis to show that it'll always be cheaper because if if we roll it in, I'd want to make sure that we don't just um >> you know put it down the curve. Um I don't want to make gas more expensive on the lower end to make it possible for paging. That's kind of counterproductive built. >> Yeah. Yeah. Um that's interesting. So I think for the first page like the zero page we can always make it cheaper and then um that's a really good point. I can do some analysis to see about like the pages in the medium range like from 4096 to probably 16,000 it might be cheaper in the in the quadratic memory

um regime. >> and I guess another general comment I have about this is I think we're overfitting on cache size design with the 4096 page size. Um, is that going to translate well to ZK handling of memory? Um, have the ZK teams had a chance to look at this? >> No, I haven't asked the ZK teams about it. Um, do you uh maybe I'll connect with you and see if there's some good teams to reach out to. It'd probably be Kev from the ZK EVM team at the EF now that they've got a dedicated ZK team. He would know a lot about the ergonomics.

>> Okay, perfect. That would be really great. Um, if I could chat with him. >> Um, the last backwards compatibility issue was brought up to me by Yakim. He um basically pointed out that in the current EVM or yeah the current regime like uh users might use reading a really large memory address to be like some kind of cheap way to revert or exceptional halt. um like you might read the pointer at 2 to

32 to try to revert um and then after this EIP that wouldn't revert anymore but I think in general my philosophy about this is that you can't really cater to um people who are using like non-standard ways of trying to make things revert um because otherwise like no changes will ever happen. Um, yeah. So, that's my thought on that. >> What if we made the page size bigger and we charge for expansion into the pages?

That way, the absurdly large numbers, if they fit into like one page that's too large or two to the 32, would still cause a massive cost explosion, just on the order of billions instead of quintilians. Uh I'm not sure I'm following the page size bigger and what? >> So right now you charge flat rate when you allocate a page. Um I think when I when I pitched the temperature check my idea was that we would um row into each page. You'd still be charged for each bite you go into the page just at a certain the page size if you go over two gigabytes um we reset that based as though you're growing from zero on that 2 gigabyte boundary. So that way if people were still using two to the 32 to

burn all gas um allocating that much memory or even to traditional numbers that you know were less than whatever the typical explosion rate is um then they could still get that behavior and we would still preserve the paging behavior. We just need a you know have our page size be like eight bytes out instead of um two bytes out. >> I'm still not understanding. So is the idea to charge more for pages over 2 gigabytes? >> So you wouldn't allocate the whole page at once. The page would be like the existing memory structure. But if you access an address greater than say two um two to the you know you know

greater than two gigabytes then you would get a second page and that would be the second page um and you would allocate the whole page. for that page you would allocate from that zero basis. So basically we would create multiple of these growing memory charges but if you use a big enough prefix on it you get a new page to work with if you work with it correctly. So that would also open up the possibility of using things like having your prefixes be addresses of contracts and you could grow into those top 20 bytes of your page and then you would still have the same linear growth of bite charge per actual bite used rather than charging them up front for four for 4K of memory at once.

>> I see. So, the idea is for each page to basically be much larger, like kind of equivalent to the current EVM memory size, and each of those grows quadratically, >> right? Well, they grow linearly within their page, but quadratically with how many pages you have, >> right? I mean, I'm not sure. So, it sounds like you could still like touch the address at 2 to the 32 and not necessarily revert.

>> It depends on how big the page size is. like two 256 would definitely do it. We could make the page sizes two to the 64. So 2 to the 32 would still trigger a revert. I mean my my feeling about this is that the most reasonable thing to do is to do something that's easier to reason about for the developer. Um, I know there is this issue about Hyram's law, but um, >> yeah, I'm I'm concerned that the ALU and the sudden charge of thrash is also

going to confuse developers, too. >> Um, maybe. I mean, I think that's straightforward enough because it's a familiar model um, from how real memory works. Um but I mean there's a lot of ways that you can break backwards compatibility by like increasing limits. For example, like uh if the code size limit is increased, then you maybe somebody was uh using deployment of a contract larger than 24 kilobytes to trigger an

exceptional halt >> or something. And this is where we used to task people from its salon to go look at the historical contracts and say, "Well, who's actually done that?" However, we fired that guy because of the reor. So, it's probably something that other groups might be toolled up to to do a historical check to see what's actually happened in these instances so we can see if people truly depend on it or if it's just a hypothetical.

I mean may you know that the two to the 32 reference what numbers do they use? Do they even do that? Is is an answer we could get by looking back at history and using history as our guide. And the Heimer's law would only apply if people have actually done it or have code in place to do it. >> Right? I mean the thing is there are much more efficient ways to exceptionally hold >> right >> namely code finite amounts of gas. However, that's another thing we need to consider.

>> Um, if you don't Yes. efficient to um Did my mic just change? Can you hear me? >> Uh, no. Yes. Yeah, you broke up for a bit. >> Okay. Um, if you want to burn a finite amount of gas, the cheapest way to do that rather than burning a loop is just allocate a large amount of memory. Um, but the question is, are people actually doing that? I don't think you know burning memory is something that we've seen apart from trying to trigger a revert and you're right just calling the revert or calling the uh FF op code or the fe whatever the invalid op code are better ways to trigger reverts.

>> Yeah. And I I've seen people do a branching revert uh by like using return data copy with the condition um crafted in a way so that if the condition is like false then return data copy like gets an out of bound. Um but I don't think that using accessing a high memory pointer to get an exceptional halt is any better. It's like always worse than using >> one of the existing methods. >> But to burn a million gas, it's super easy.

>> Yes. And to burn a specific amount of gas, uh uh this not in anything I'm presenting today, but I think that we should have a an EVM native way to do that because it's quite a common use case. >> Yeah, looks like we're at time. Yeah, I don't know yet guys. Uh maybe we can start to wrap up but this is like interesting conversation. Maybe you can continue offline and then I know we have a couple of topics uh which will overflow into the next call but yeah thanks everyone for joining. Um yeah and let's continue the discussion in the group. Thank you.

>> Okay thanks. [Music] mature yet. Um, but I'll share them in the group so that uh people can take a look at them offline. >> Awesome. Thanks, What's up?