EVM Resource Pricing Breakout #2

Transcript

okay yeah so uh today we are going to pick up where we left with the uh call number one so to start we'll have um sha give a presentation on uh some research that we've been doing into um coming up with a new uh mechanism that is implementable for uh multi-dimensional fees um and then um we'll go through a few proposals that um came up after our first call this is more for short-term changes some of which uh we discussed in that and then uh we can have a discussion in the end

on like anything else that uh is top of mind I know Anar has um uh some things uh uh to discuss and then we can also open it up for others so yeah uh I'll start with um uh presentation from cha yeah uh thanks d uh with me for one second I going to share my screen e

uh could you see my screen y yep uh so today I'm going to give a talk on the multi-dimensional fee multi-dimensional Fe also the multi-dimensional gas and uh let me start so so basically right now we have a single dimensional gas and basically the gas is a combination or a metric that bundles a various type of resource consumption into just one one dimensional uh number which simplifies the fee calculations and block construction and for gas uh there's uh several uh

resources contained there like the key resource types such as the computation the storage and the bandwidth and so on so basically the gas is a linear combination of these multi-dimensional resources and for the block we have a block limit of uh 30 million gas and and we're using the protocol like EIP 1559 especially for L1 to dyn dynamically adjust the fee so that the target the target of block space going to reach half which is 15 million um but there there's some limitation there so for example if a

block were only use like one type of resource and consuming up to 30 million gas so so the safety uh constraint is that uh for each resource if a block only use that single type of resource and the safety of that type of resource can consume up to 30 million gas but what we have for onedimensional fee mechanism is like the combination of all the resources together going to less or equal than uh 303 gas so basically uh the current model what we have right now is uh linear combination I only uh show like

two Dimension here but in reality there's a multi-dimension if if there's only like data storage and computation these two Dimension and the current uh model or the current constraint is like X1 time data plus X2 times computation is less than than than 30 million than but in reality uh the safety constraint should be the maximum of X Y times data and X to times computation and could also consider the other type of resource and the maximum of these number is less than so which mean which also means the safety limit

for one resource I is over XI so I also draw a a graph here to uh visualize what we have like if you consider the uh blue the the black line uh which basically means that the uh the constraint that we have today and if you look at the uh space under the black line which is a triangle and this is what we can have this is like for for the for each block this is uh what we can have for the block space today but uh we can we can expand the constraint to be this uh this blue

rectangle and like every every single point within the rectangle is also safe so what we have for today is like within the current uh constraint uh a lot of block space cannot be utilized uh which means that within the which means that like we can have the block space within the constraint of the blue rectangle space but what we current have is only within the black rectangle space uh sorry what was X oh so we have X1 and X2 here uh so basically if

you like how you uh so so basically the right now the gas is a linear combination of a lot of resources and the weight of each resource is the X yeah it's also the gas cost and so we have already Implement uh EIP 4844 which is a example of the multidimensional G gas mechanism uh so we introduced a new data

structure called blob and in the 4844 we have two Resource One is the original L1 gas the other is the blob and for either of these two resource uh it have a gas it have a a limit or a Target and for the first we are targeting at 15 million gas for the second we are targ at three blobs per block and for for each resource we have a separate fee mechanism EIP 15 59 mechanism to control these two resources and uh there could be another type of uh another example of multi-dimensional gas uh that we can

discuss here uh for example there's a state growth a state growth uh type of resource and it basically have a long-term constraint which means that it's okay that for each block on the the uh the the state size growth could be large but what we what we have to but but essentially uh what's important is we need to make sure the long-term average of the state growth is within a number uh which is which is a little a little bit different from the transend resources like computation or call data which

means that for this type of constraint or for this type of resource the EIP 1559 may not uh optimal for this one and there's some literature or we can also design some uh simple but separate fee mechanism that targeting at this type of resource and and and yeah and we're going to skip that page and we have a so if we are talking at the multi-dimensional fee mechanism and we want to claim that okay

it's very uh directly that for each resource maybe you can have a single one e559 to control the price or control the contraction of one resource but there's a problem that we have for this type of transaction is that uh right now the transactions have an overall uh gas cap that the user can submit and for each transaction there are different sub calls and for each sub call the user or it's or not the user but like if you write the smart contract to call the sub call you can also specify their own guas limit uh for for the sub call and which is like the reason is that we can

reserve uh gas remain for the following cost of the transaction and with a multi-dimensional pricing each resource would ideally have its own limit within the subc call but what we have for the current evm is that is like we can only have we can only set one number for each sub call so we can only set one gas limit and there there's a approach uh that's proposed by vitalic is supposed that the transaction have a multidimensional limit L1 to LK with the

current remaining gas G1 to GK uh for a sub call with overall limit s and we going to we so what we going to set for the limit of the sub call is just the proportion of um Alpha and for each for each Dimension we can have a limit of alpha times a GI and GI is the remaining gas for this type of resource and and here's one way to deal with the problem but maybe we can also come up with the other solution here and this is the following like a

future research Direction and we also took a little bit uh look at the empirical results because I don't have that much time to run the code so I basically I only get several Point here um but what what I'm doing is like we I analyze the two dimensional scenario so we only consider consider the two dimensional which is the compute and the storage and I'm looking at the Block starting at the block number of uh like 20 million and one which is on October 18th so so in one block we just compute the like the gas usage of this two

Dimension and and we scale the limit so that there's some reaches 30 million to give an example here if one block it have it consume like um like 10 million gas on storage but 5 million gas on compute if we scale it up then we're going to have 20 million gas on storage and 10 million gas on compute and here's the Gap and what I want to show here is like okay if you consider the if you like go up the block size such that the reaches like 30 minutes we can know that there's a

there's a gap between what we have within the current constraint to the uh safety constraint like what we have is the rectangle space but what we can do further is to enlarge the rectangle space to the uh what we can do further is to enlarge this triangle constraint to the rectangle constraint so that you can imagine for uh the future block size if we implement the uh multi-dimensional fee mechanism uh like I ideally the I think the block space can large as uh for example twice as what we have for now and here's what we have done for this um research and

there's also a lot of further research going to be down in the future and especially the empirical part and also we're going to we need to uh come up with a fee mechanism that can really work and our Target is to have a new EIP for this multi-dimensional fee mechanism and uh if anyone is interested in uh we're very happy and open to collaborate on on This research and that's all for today's presentation thanks sha I think this is good like maybe I L just a couple of things like yeah sha has been thinking more about

like uh some concrete mechanism um but also like these ongoing like empirical analysis and Soo you can uh stop presenting in the meantime um these empirical analysis like the idea is like uh first to uh get an idea like we want to try to estimate uh okay if we were to implement a multi-dimensional uh pricing mechanism that works uh what is the uh impact like how much more throughput can we get like uh looking at like some historical set of blocks so yeah we' started looking into this data set but if anyone wants to contribute on this like you can DM showa or like myself and I can also

connect um yeah uh so next up uh we can switch to more shortterm change um I think yasek wanted to uh quickly show uh their uh new proposal for repricing that uh they came up um with after um our last go so okay yeah so uh last time uh we spoke about our methodology how we came up with the numbers now I want to talk more about let me just zoom in a bit uh what the actual proposal um is so um I'm still uh finalizing EIP so I'm going to

show you this uh table here but I think it's even easier to to read from this table so what we have here in this column is the current gas and uh our uh proposal on the right in the in the middle we have something that we discussed in the last meeting as well so the fractional gas uh this is not the our proposal just for you to see what what would be the more uh real uh cost of of uh each of op code so in in general our proposal um aims to lower the computational cost so leaving the storage and call data cost

at the same level and lower all op codes uh and make them more realistic based on our uh benchmarks so as you see more most of the simple op codes they go from whatever they were to one there are few uh exceptions from this LW but this is just because these up codes uh turned out to be more computational complex um for the when we have a dynamic uh cost we also uh propose some new cost so you see for example here the xort be uh slightly cheaper or actually actually quite much uh

cheaper um the kak uh would be slightly cheaper so our benchmarks didn't show that this is actually an easy up Cod if we move uh further down we see this are the all the we turn it all to one and um uh here um when we have all the memory uh operations uh we usually have a cost uh uh memory size plus the memory expansion cost so in most of this cases we leave it very similar to what it is but make it more in line with the other op

codes but we will talk about the memory expansion cost and the accessing address uh warm and hot warm uh and cold atas uh later on um okay so this up codes all go to one uh I'm just looking at some more interesting stuff here um uh the new uh TLO T store op codes there are in fact much cheaper than uh initially anticipated at least according to our Benchmark so so this should put them more in line with other op codes uh the memory copies okay the the log cost now

this was more tricky to um uh estimate what the actual cost is of logs so uh this proposal um takes mostly computational cost of uh logging plus a bit little bit of storage but uh I think I need to Le more analysis on uh locks uh to to be more sure that this is this proposal makes sense now when we go to create on a Surface there's no change but the mem expansion cost will be uh well was uh okay I was

wrong very small changes but uh mostly it's the same the memory expansion cost uh is slightly different which is the same for uh all all the calls so uh the formula is the same but the mem expansion and the address access cost will be lower I show you in a moment but first let's talk about uh C on P so uh e cover even for we reduce everything else e stays at the same uh level um those up codes are not used much anyway

uh but also the same goes for the mode exp uh but I think margin will present more uh in-depth uh uh analysis on this one in um in a moment uh what we can say the ecat is actually more uh expensive than anticipated and the to be fully backwards compatible we actually proposed to leave the cost at the same level uh even for the the actual cost is much higher at the moment um there might be a little bit Lisk involved with this but it's the same as it is at the moment

anyway um okay let's uh talk uh here about the memory expansion cost so uh at the moment what we do we pay for each new slot allocated we pay three gas plus we pay the expansional cost so the more we allocate the more uh we pay uh our proposal is because the analysis show that the memory is actually memory management is cheaper than uh the current cost so uh our proposal is simply to ditch the p slot cost and only leave the expansional

expansional cost uh meaning that the first 22 Slots of memory will be actually free to use and you only pay for the allocation when you exceed it um another uh thing is the address accessing cost and here we uh uh recommend to significantly reduce accessing War uh access cost our analysis showed that this is very well once the adlas is warm uh it's very well cached in most implementations and we can lower it to to Really minimum also meaning that any pre compiles will be

cheaper because you still pay um at the moment you still pay 100 uh uh gas cost for each pre compile we propose it to go uh to five so uh this is the the the initial proposal I will try to finish my EIP soon and I will uh [Music] uh uh share it with you thanks yes um I don't know if there are some comments here maybe we can um Reserve like a few minutes if there are a couple of questions

um I see up Cod SP at zero uh which um uh it's uh zero plus some cost so there will always be some uh cost associated with this um uh log costing but do we need more thinking and analysis on the log as well uh uh the next question I would gener always generally Round Up um yeah it's it's up to us L how we want to to do it see so Mark and the

question yeah so I have a question because we Benchmark it in isolation so for example we took just add op code but we know that EV in evm we will be doing the loop and my question is if we are concerned about this if this is good enough representation of the truth that will be happening on the evm level because if we yeah so so our methodology um uh in essence we try to exclude any any uh factors like you know uh caching warming up of evm or pre uh separation or something so uh when we

benchmarked it we didn't took Just One op Cod and run it through evm we took a series of op codes including some uh random data and then we extended the number of op codes Under the test in order to see how uh much the the execution time increases and this is the the thing that uh is Basis on our um which is the basis of our uh proposal so uh as much as possible we we try to get the true cost of executing uh an OP code okay makes sense

um the warm access cost does that is that both like balance and SS load balance uh account uh code and um yeah well let's see where where we have the anywhere where we see the Adas access cost so uh code copy uh code size code has for example uh um all the calls okay what about um s Lo and um um T no T

Lo uh T load um yeah but doesn't actually uh have the the dynamic cost so it's always uh static 100 volt store for the um s Lo s store um I don't have it here but uh it goes with the same way so the cold access stays the same because it's the storage cast while the warm access uh is significantly lowered because that's the more computational cost

oh and Lucas uh yeah I don't think we can just say that some op codes we can because they are not often used that we can ignore it because that could potentially uh cause open attack vectors right so we potentially need to consider that each op code can be very heavily used in the block and price it based on that we we didn't ignore any of the opods or the compiles we We R the calculation everything uh what I mean some codes uh M less uh for the normal user but we still keep all the security uh in place so they uh this uh proposal

here does reflect the true cost of computation comput uh think this the compiles and then want to go again um the transaction cost at 20 1 uh um that's effectively is it not a warm access cost because it's um it's right up front in the transaction in the two in from so does that count it's it's it's a good uh point I um uh I wouldn't want touch transaction uh cost uh here so I

want to this EIP to focus on EI on op codes only the reason is that the uh transaction makes some addresses warm and you have to pay for making them warm yeah so uh hence the cost of 21,000 we can look at uh what the transaction cost is made of and uh maybe decide to lower some of the elements but that's completely different discussion okay so I mean it sort of comes into access lists cheaping so if you're cheapening access to warm based on access list you're effectively also doing it with

two and oh in that sense um yeah true what is the basine here uh like uh so um the Baseline so we had to descale uh the results and uh What uh I used for the scale was the uh average cost of basic uh arithmetic up codes so from uh 01 to 1

D this was the basis of uh uh the scaling and one more comment from my side uh when I see results from pre compiles they are like very different from what we got in our tooling so uh we need to um I don't know chat about it for example I see that EC pairing will be potentially less expensive and and this this wasn't the case in our benchmarks for example so uh I think it's good that we have two to LS and we we we have to compare the

results together uh yeah definitely we we need to compare the way we came up with this and uh our Benchmark methodology and power it kind of have the same same question and what Mark and H discussed that uh yeah I think we we need to establish what is like the security goal here and I'm sure this is this is pretty well defined so far uh because like what what's yeah what um what ytic

has has showed is like they they kind of try to my understanding they try to kind of readjust the the the the numbers by like kind of self-tuning so they compare what they are and how they differ from each other uh um I what I wanted to do with this is to kind of verify it from the other side that we know what is like the safe safe limit that we aim for and in case we find example that actually crosses this limit it means we need to modify the numbers we have and uh I I'm not sure if we have a

good good way of actually setting up this this limit up front uh because it kind of affects many many many things in the same way we we don't know what is the right or safe limit or cost we can only um uh try it and uh see how it works yeah well I mean it's can we have a number something like none of the blocks should be executed longer than one second for example I think that's that's that's the kind of boundary we want to establish and we can move like modifi numbers

within this boundary uh I think that's much easier to work with than like self-tuning the gas by seeing the other gas numbers because yeah I kind of want to know like what is like the safety safety boundary here and kind of also goes back to the previous presentation when we kind of to be moving like optimized within some like space that we have established for security but before we establish this like the boundaries of this space it's really hard to actually check if this number is is kind of within safety margins or not because we don't have the margin yet so the methodology J mind was using

is uh establishing some Hardware requirements and I think we are using fairly lowlevel Hardware like a Intel Nook I don't know if 10 gen or something and and then uh creating a block filling it all with uh op code or a pre-compile executing this this block and measuring megag per second on this machine so and then we kind of aimed that think at least at 60 megag per second or more uh on this machine so that's kind of was our ballpark of doing stuff interesting so it looks there is a couple of interesting things to follow

up like one is maybe like uh doing this exercise of like uh establishing the safe limits at least have like uh some logic that uh we um we have as reference we agree as reference um yeah and then the other thing I was thinking I maybe it's also good thing to follow up after the call like the comment on oh like for um um for pre-compiled now we have like two tools and we can do some comparison I think this is really good actually cool I think this was great so Yas thanks um and yeah really excited uh

for the progress um yeah so um I think next we had Marin wanted to uh talk about their uh modx uh proposal yes sir let me uh share the screen uh okay so I would like to present uh uh EIP 788 uh 3 so modex modex the gas cost increase uh right now U modex is priced according to aad

2565 and unfortunately Le there underpriced underpriced scenarios for its resour resource consumption and by modifying modex pricing in this EAP these scenarios are covered and we are doing it with minimal impact on real world usages our our Target here is to make all mod scenarios at least as fast as e recover precompile so all the worst performant edge cases will be performing at least as fast as e recover so uh we have this EC recover as uh as our

reference uh and on on this machine it was performing at about 60 m per second and as you can see there is a lot of modex scenarios which are performing uh way uh slower I would like to focus right now on the modex one of mod common cases it's a case from mainnet and uh 200 is current minimal price for using modex precompile and in the scenarios it's performing more than twice too slow according to uh to EC recover so at this point we we know that we need to

increase minimal uh minimal price and there are also other cases but I will talk more about them later current modex pricing formula uh is is a function of multiplication complexity and iteration count multiplication complexity is uh is just uh depends on base length and modulus length and iteration count depends on uh exponent uh our propos proposal is to change the just just do three changes to this pricing Formula First is to increase minimal price from 200 to

500 and uh second one is to increase uh exponent uh cost uh only for the cases where exponent leg length is bigger than 22 and the first third modification uh is uh to like right right now uh the multiplication complexity is just square root of of word and we want to keep it but only if uh if max length is um equal equal or lower than 32 bytes

and if it's bigger than 32 bytes then we are doubling the cost and thanks to that modifications uh like all the cases are are performing uh better or similar to e recover and uh we also did uh net benchmarks uh our reference on on is still e recover and on this machine it's performing at 50 meg per second there are in current pricing formula there are under pric scenarios we are performing uh below it uh but there are also also scenarios

that are performant enough and this these are scenarios like uh cases where all parameters are lower or equal 32 bytes so we can consider them as real world scenarios and thanks to this changes in pricing formula we are adjusting uh the the worst cases and I can say that this red rectangles are uh on in historical usages on mayet it's less it's about 0.21% of all usages so uh really not much and we are adjusting price of it

and uh price of uh uh of of this common cases is untouched it's like one group of common cases second group is this ones which I told at the very beginning so uh where the minimal price is is just minimal cost is just too low so we can we can do nothing like nothing other than just to increase it and this to modifications are affecting only 0.31% of historical usages uh so it's our proposal and there is also another approach to to modex for

pricing it's modex modex evm ification uh it's uh like proposal from vital it's like like 7666 is about indentity promile which is removing identity precompile and putting into the contract a short piece of evm code with the same functionality and as vitalic writes in the future we can do the same with modex so someday eum will drop modex we compy and probably EV Evy it and we need to decide if you want to go straight for it so for final solution or postpone it and for now just

make mod rep pricing appropriate so using uh our EIP and for example uh 7823 so set uper BS for modex uh and uh that's all from me there are any questions thanks foring yeah we can take a few questions there I I think for um Che Ching modex to a Smart contract we need evm Max otherwise the cost would be like a 100 or a thousand F more um might be

incorrect I assume I assume that'll take longer uh yes I just uh I know that s such proposal is uh it was proposed by by vital but probably it's like uh we are not ready for it so it is why we prepared the this APAP are there any more questions so there's a good question from Tony in the chat that uh would 200 to 500 increase in base would it affect

uh most most of mod XP or not because it's a bit confusing uh yes I I uh didn't I don't have calculation for it but uh it's uh like big part it will be about 40 to 50% of all usages but if we want to perform uh as fast as e recover it just uh there is no other way than than to increase it so uh to be clear all the cases uh uh which are which at least one parameter is

bigger than 52 bytes it's just only 0.3% of historical usages but the ones with minimal pricing it's a lot so I need to do calculation for it but it will be uh yeah about 40 50% of all uses okay thanks again Mar yeah okay and now I think uh Tony wanted to share something I don't know if presentation or just like um heads up on his new proposal yeah thank you everyone I just wanted to quickly use the

opportunity to um share um this recent e research post on block Lev warming with all of you let me post it into the no right and it's not only Block Level warming but there is also a second post on Block Level access lists and first for Block Level warming the idea is to um keep a set of accessed storage slots over the whole block and basically the first person that accesses a certain storage slot has to pay and everyone else gets the warm cost without doing any refunds at the end um you can also see on Eve magicians there is also a threat on the whole

topic um there are some problems for example the one of the concerns that were raised um is around parallelization um another one that was raised on Eve magicians is around um block Lev warming acting as an disincentive for Access lists and then the question is um how to best um approach the whole thing because there are a lot of um yeah cross interactions with access lists and as soon as we do something like blocks block access lists where the block Builder or yeah the block Builder has to put all the access all the storage slot slot that he's

about to access in that block into the block header then the question arises if we if it wouldn't be smarter to directly add the values too and yeah so I just wanted to bring that up and um happy to discuss that a little further thanks Tony yeah it's a really good proposal um is there any question so so if someone wants to um think about that the main challenges are

parallelization and how to make it um aligned with access lists because the problem with block L warming and access lists right now might be that you have less incentives to put something on your access list because the chances that this slot is already warm um when it comes to your execution are higher and then of course you would pay for the access list and already have a have a warm slot so uh to be honest if we have paralyzation I don't care that much about access list because I can already amortize that cost and accesses don't

give me much uh for uh speeding up the block uh but yeah if it messes with paralyzation it's really really bad in my opinion and um maybe one question how does this uh work with Witnesses like verical Witnesses or any others because those will be like in a block right so potentially does it solve something does it uh make it harder easier yes I understood it so for me I like thinking of the work Witnesses are just like block access lists on on steroids so it's just um in addition to

the to the to the storage slot you would also add the value and yeah there are some arguments for doing so I think the average storage slot is only around 8 kilo uh eight bytes or something so there are arguments to directly add the values too if we want to do Block Level access lists where the proposer the Builder has to um specify all to be accessed slots up front Ana yeah I just wanted to say uh yeah with with the ACC list as well there is um there there was this e draft from a bit over a year ago that I put in chat

from the count obstruction group people as well that actually never was turned into proper EIP um but I personally kind of like at least a part of their design where they they basically try to avoid this issue with the access lists by by um exactly by basically making them the mechanism for that and then you do Eco refunds and uh and that way basically you actually instead of dis instead of ending up disincentivizing access list the mechanism ends up incentivizing access list usage which is actually quite quite nice yeah some yeah something that gets us closer to that um scenario would be very beneficial because if we the more

addresses we get into the access list um the more it will be pre-warmed for all and yeah so there are also some ideas I think Peter um mentioned some ideas um mon research I'm not sure if he's in the call I guess not um about processing them not on a transaction level but maybe um after the whole execution processing um some refunds for exess lists um post execution that sounded very interesting but yeah I still have to get my head around it thanks Tony yeah and I think asgar

has some thought on like estimating gains from repricing like something we also discuss in the multi-dimensional case like getting an idea of like how much gains uh we can get are also in the research post so it's basically like um imagine we only have warm costs then it's around 36% so we pay 36% of our gas for warming um storage slots and I think around 20% of those is for Unique storage slots or let's say half of it right so um half of our storage slots are only used by single

address sorry single transaction yeah right because for Savings of course you would only get savings where there's actual overlap because um otherwise you still have to warm them at some point um I think long term we can we can in general also like consider like what how could we more cleverly treat state where basically you kind of if if if say everything every access is declared somehow statically with access lists or some other way of of of attaching metadata to the block then you can basically start loading them all from disk at the beginning of the transaction and if you do that in a clever way maybe the in right ordering

you can basically keep loading while you already execute and then as long as somehow basically you only ever access them after they already were loaded basically if you if you if you find a good way to Bally balance that that you you access them not at a faster rate and then you're loading them then in a way you basically never block and wait for for for for storage and then you can basically use that time for for actual computer or or whatever else you'd want to do in the block which would be quite nice but but you need like a more sophisticated mechanism for that yeah I agree and also it it it's very beneficial for paration so I would say the more we get into access lists and even better if we enforce them um the better for par say and also

I think danr had some very high numbers um of the um efficiency gains we could get there because of um parallelizing um yeah discrets and also execution right yeah I mean this greet you can't really like you can't paralyze in that sense right but but basically yeah you could basically get more compute in if you if you basically have transactions that in parallel would want to do some some compute um and you can you can make it so that you you you basically spend as much of your time as possible actively loading things from dis so yeah there's definitely a lot of improvements we can do um I mean you you can parize in a a

different way thinking about it in that the SSD can do you know 16 or 32 parallel loads but the issue so you can convert storage load latency into um throughput but the issue we have with the evm is you don't know what the next one is until you run the next instruction until you run the next instruction so with access list you could load all the data in parallel whereas at the moment we have to load the data sequentially there's an interesting Nuance yet I mean I think we're running up on the end of the call but this is an interesting it's interesting topic and I think in general like having having maybe a more focused breakout or

something at some point or on like more just storage access and feralization what not would be really interesting but like the Nuance there being that like access list themselves give the benefit also to the Builder but you can basically get the benefit only to verifying notes if you want to by by just having the Builder afterwards create a full access list for the entire block right and then it doesn't even have to be like a stateless witness where it comes with a data just the access lists and then that way anyone else receiving the block can basically start loading and then then it's not sequential loads where you basically always have to wait you can basically do the the entire loads for the for the for the complete Block in parallel at the maximum possible throughput from your dis um which in principle under the

right circumstances could give you a big boost right and it and kind of if we leave away the values um this um access list um Still Remains quite small so I think on average um if you kind of naively sum up addresses having 20 bytes um storage slots having 32 bytes then we end up at around 40 kilobytes per block if you put all addresses All Storage Keys into into it so it's not that big I'm not sure how much bigger it would be if we add the value here yeah so my point would be but yeah we would be doing something here but that we would throw away when we do

Witnesses and Witnesses give us like no storage SL cost at all on the access so I don't really see it's a stop Gap solution that I don't really see worth investing in um I think it's time to wrap up um thanks uh everyone for joining uh there is a few things that came up that uh we may want to follow up um I think we can send uh some follow up in the channel and then we can also work at around scheduling the next go like in the channel as we make progress on these but yeah and thanks again

everyone thanks everyone byebye thank you thank you thank Youk you bye bye