EOF Implementers Call #43

Transcript

so this is uh e implementers call number 43 24th of April 2024 um so our agenda is client updates compiler updates spec updates test updates and a list of other items um so client updates Basu is um been contributing to some of the tests um using Basu as a basis to validate the tests um some bugs and Bas who were found in the process fix those as we get them that's why we write tests um next up uh Marius you want to talk about gu sure um yeah so uh we I've um I'm I'm passing all the EF validation

tests and I have still a lot of e spec tests failing um but I think I over the last week I fixed around maybe 20 or 30 bucks that we had in the implementation and um yeah so far it's kind of progressing okayish I would say um yeah just just cracking on with the with the validation stuff um and it's been sometimes kind of hard to understand what the tests do um so the tests in um the test report have except for the name they don't

really have any explanations to them um and so sometimes it was like I don't know most of the time it's just spent reading the Rob bite code and trying to understand what the test tries to do so if we want to Port them or if we're porting them it would be really nice we could have like a um like a good description for each test case what it tries to achieve um so that it's it's easier to to see what what the bu is in your implementation if you if you fail it um otherwise I think the test coverage at least for the validation is kind of

okay there were [Music] some one one thing that I found was um I could often I would make a lot of tests pass with some buggy implementation and there was maybe there was one test um that would fail and I would like realize it and then fix the implementation and and then all of the other tests would would be passed as well so um and then there was one time where I uh uh where I fixed something in a wrong

way but it passed every test so um the the case was if um if a subsection um if a sub subsection is truncated um but also the um so we have this rule that the data size has to match the data length if you want to deploy um but what I implemented is that it matches the data length of

the contract that deploys it um so the the the outer container basically and that pass the test but it's but it's kind of wrong so I realized at some point it's it's just wrong and and fix it anyway there are there are some but it's also very hard to make it t to create a test that tests this exact um thing anyway that's could you share what you did have that briefly passed yes um I'll share it in the chat because because it's I have to dig it up

again uh and it's hard to hard to hard to reasonable yep that's that's understandable but if you get tests that you think that are interesting um please share them we can always add them to the Corpus I think those are valuable even if even if it's stuff that you fixed okay um marus went on mute um Dion anything from evm one going once going twice doesn't look like it yeah uh we have

merged you have create and TX Crate by now and we have one pending fix for the rule about unreachable code sections and otherwise we are yeah up to the current spec yeah okay no nethermind no ethereum JS no um uh Aragon so I think next is compilers um Daniel Charles who wants to go first yeah I mean I can start yeah I mean I'm basically here because ipsilon told me it would be good since you have

this schedule for uh considered for inclusion now to join these calls again we still implementation wise have the implementation of the Shanghai version of VF and now am wondering what the guarantees are of the Nega specification actually happening which would mean that we can allocate time to update the implementation to that version and that's basically a date from us memorized okay um Charles anything from Viper no uh same uh status so what level of guarantees do the two of you need before you can start

implementing what what changes need to be set in stone that won't change um who's asking um I'm asking for one I'd like to know what's what should be um Implement what what should be considered absolutely Frozen and what could be discussed to be changed if anything what what can we do to unblock compiler progress and if that's putting a lockdown on the spec maybe we need to do that and what that

lockdown looks like um I I think that implement in E for from the compiler's point of view is actually kind of complicated like maybe more complicated than the evm implementation um because it just like works very differently um because you have to like basically completely redo how functions are compiled um so it's not so I mean if if somebody needs the compiler

to implement it then like uh what we would need to be guaranteed is basically like the container format and some of the basic uh CF the basically the the sub routine and call and and jump instructions but if nobody needs it we're just going to kind of put off productionizing it until you know like the day before the fork or you know some reasonable time for to allow for testing I mean I would have quite a different perspective there I mean we have implemented the part for the Shanghai version of thef and that's sitting there not merged but I mean in a state that can be revived for us it

would be some effort to accommodate the contract viation changes that's not entirely trivial but also that's I mean that's significant effort but I mean what we really want is is a prognosis of the likelihood of actually there being consensus of actually doing UF at some specific point in time which then you would be very happy to provide an implementation for whichever version then what we really need in the specification is the DN and swap uh up codes that's what helps us the most the other stuff iterations on those I mean not much of that is optional and it's well specified as it is but I mean minor changes around that we can accommodate because the code doesn't change that

much depending on how the container format actually looks and stuff like that but yeah the most important thing for us is to actually know that we can assume that in some particular hard Fork there will be eof and we're happy to way before that spend effort in providing an implementation okay that's that's that's good to hear um one of the reasons that I you know I do want to unblock the compilers is there's um there's been question raised about you know what's going to be the net size differences what's going to be the actual operational gas differences if any is it going to be like you know double 20% 1% is it going to be noise um those are questions that really um are not

answered well without an actual implementation of compilers so that's that's that's my interest in trying to unblock and and get things progressing um we have good data from the previous version of e that increased our metrics in both gas cost and code size uh I don't think that the changes in creation and the code interection changes will have much of an effect on any of that okay do you have benchmarks for those go ahead yes benchmarks handy I could reference or should I try and recreate some myself uh I mean we did provide some data back then I can look that up we can revive the brand and do it again okay yeah that's but that's relative to the

version of UF at that point in time so it's not actually the current specification but and more importantly it's not the veral version of it but that would I mean that would be a starting point I'd be I'd be happy with that to begin with yeah yeah I mean we also have some data from the the Shanghai version and it's like the we actually had code size regressions uh um because code sharing isn't the the and Viper has I think always had very good code size and um the issue here is that code sharing is not as good after EF um and

because of the code sharing restrictions which is that shared code basically needs to be put in sub routines you end up with uh more code size versus gas tradeoffs than um like in EIP 2315 world where you have the global code section right but isn't that why we introduced the changes in the stack height validation so where it's a range instead of a fixed value which allows you to then outline for various ranges yes it's better but there's still a gas versus Cod sign trade-off because the lower gas is to jump within a section so if you want to outline it then you need

a CF um instead of jumping okay I can just say that even with the previous stack validation version we had Cod improvements with that they will be even better Okay cool so yeah that's you know just an open question and uh is there anything I can do to help unblock you on these let me know um anything else for compilers before we move on to spec okay I'm looking at the agenda um I see

spec items and other items there's some other items which are in Spec items um the first spec item we need to finalize on was changing uh discuss the version without the regular State change um number 78 um pulling TX create out possibly from this revision um adding a nit code validation discussing return data zero padding and some issues with ext cost and M retain gas and I thought I put in a request for um I must not have put it in the right place to discuss the IP 7676 which was allowing address space expansion um do we want to talk about

testing or do we want to talk about spec first there's a lot of things for spec that could consume the rest of the hour should we start with testing yes yeah so testing um Demetri and Hugo and Mario you're from the testing team right the three of you or is hugu Epsilon I can't remember yeah Dimitri and myself okay um how's how's the testing on eof do you have any updates any requests any blockers I check the group chat I just posted the link to the pr

okay let me uh get my browser window ready so we can share this let's share screen all right so this is um call E evm so is it this one or am I on the right is this the correct one you posted or is there another one I should be showing yeah yeah this one is basically the same logic as test that was using when you fill in F script it will generate fixtures and it will check against the exceptions uh error

codes provided by e one par to okay so is this parsing the validation tests or all the tests EF pars this is just doing the EF pars tests on E Okay cool so this is something clients would need to implement um evm 1's interfaces or is this just relying on evm one it currently works with even one and in

the future we integrate other parsel as well okay and yeah so since it's a python whenever you develop the test you might need another accept and you just add that exception in python inam as you go Okay and like if you need any help um this how this all works just uh ping me and we can work through it so I can I can teach how to use a p SCP now compared to the Json test we used to have yeah yeah I've got it I think I'm starting to understand the P scripts for these got a couple of I've got um tests for the data load operations and some

tests that I submitted for 7676 and draft that I need to update some of the um do some reviewer comments on um in this pull request there is a example test script file where you can see how the test is designed and to generate it you use the same field command as with any other PPT test but yeah it will require to have erf Parts executable uh installed in the past of the system to verify the exception and other than that yeah python script allows quite um flexible way of designing your code you can like get quite sophisticated script but uh not necess

like you don't have to it's better when the test is readable and small and simple but uh it allows us to do many many things cool um ipsilon you have your hand up yeah um this eof pass it's it's a tool that we we did uh like for this older version when we were fing eof validation I think that was running by Martin fer and uh I don't even I couldn't actually find what the spec was exactly I think we communicated mostly on Discord and stuff and I think many other projects actually implemented this similar tool um I know has some issues

with like the user experience of that because it's really follows like very specific kind of way of accepting inputs I guess we can change that because the the old father I think it's not operational right now or maybe we should kind of make it operational again I think there's some discussion here yeah I think we should definitely make it operational again at at one point and I think the the original way is to accept stuff from standard in right yeah yeah it follows exactly this I just couldn't find where the the fer actually was it was part of go evm lab

or something else I I don't remember Martin had written it he would know okay so that's that's comforting to hear it's using the interface that we probably already have scrolled away somewhere yeah it's kind of use the same one and that's why it's a bit R in some cases because sometimes it doesn't report anything because just waits for the input so uh but I think if if the made it work somehow I think it's good starting point for now okay so um I wrote like I I extended our version of this tool to have just like you can also pass in um Hax or you can

pass in a file name or a name Tool folder and it will run all of the tests in the folder um so the GU evm tool um or it's called EF Dum now um uh supports like four different ways of running tests basically um yeah I don't know if any other clients would want to implement this same thing for convenience yeah we can we can implement the same just like I think we need it would be nice to have some like like graph specification what exactly is expected of I I can obviously copy your code I mean your kind of

convention but do you think it's enough just uh I just wonder like if how we can evolve this later like if we want to change something how to communicate the change and so for example we can change something in the command line interface but then maybe the the execution spec test will be surprised about this and right I think it would be best to write down some spec for it okay I think one thing we're going to want is definitely a batch mode um because even get's going to hit the um startup penalty because it's a really quick function so it'll be much more efficient

to do it in batch that that I think that's kind of what the standard in stuff was yep yep that solves that quite easily um one one thing that I've I've kind of noticed is in our Shanghai version um we actually verified the errors now because it's broken we only verify that um the uh that there is an error um is there some spec for the error numbers no there is no spec for the

error numbers what matters is that it passes or fails and that that's where it gets kind of tricky um where like if you submit a test with two separate errors um you're saying which era you have to test for first which provides some restriction on the implementations so that's one of my concerns with specifying a specific error but the error could be informative in saying I'm trying to trip this problem and could help us write better tests so that only that error trips because I remember um it was the B 12 128 uh Basu had a bu where there was one test case that tripped two errors and there was one test case that only tripped one of those errors and the second error was hidden by that so there was no test case that

tripped only the grouping error um so that's you know why we want test case that that fail one way invariably yeah and I I kind of have the feeling that some of the errors that I'm or some of the tests that I'm passing uh is because there are two errors being thrown one of them is is the correct one and um yeah and apparently at some point there were error code specified okay but maybe not anymore we do

testing we could probably build these air codes organically through testing so we have a list of exceptions for EF maybe we can make that the canonical list um at least for testing I can share the link to the file um and we can grow it as need as needed uh so if you see that file that I sent just in the in the chat uh at the bottom we have EF exceptions and maybe we can use this as the guideline okay and um would we need to emit those

exceptions or have some sort of mapping from our output to say this is the exception how's that being handled in test so the exception is being written into the UF test uh fixture format okay uh in in a string and so it has no number and what you would expect is if you scroll a little bit down to the bottom H there you go so you have the class EF exception so what you will see is EF exception Dot and the name of the exception uh so we have default exception right now because um some exceptions are not mapped yet but ideally we shouldn't have something like default exception we should have a specific exception for every single test

and yeah ideally no test should fail with two different uh exceptions if it's almost always possible to make the to design the test so that it only hits one exception uh they're very rare cases but where it's impossible maybe if we find one of those then we can decide what to do but I think we should try to design every single test case so it only it is only possible to hit one exception okay there's no flag for for version yet because it's all in one fork so we can we can skate around that for a little

bit okay any other testing oh go ahead oh yeah we can version the exceptions also if if you guys want we can so we have this um um um folder where we are storing everything that is related to version number one uh maybe we can just create the Exceptions there and and if there's version when when there's a version two we can just uh create another list of exceptions if necessary but yeah okay uh also to respond to Mars it doesn't have to be a string we can just easily change this to integer

errors the the names are only for only just to to easily identify which which exception it is okay um one question I have are there any places where there are holes and tests where um you might appreciate help from the client teams implementing some of these tests or informing what tests need to be done I don't have a concrete answer to that because I haven't looked at the spec changes to be honest um um I don't know if Dimitri has any

info but I think we will be able to maybe find find more uh coverage issues the more we Implement stuff because right now yes it's very early to tell okay um ion's get a hand raised yeah yeah I I I sent one request kind of like testing how testing how to write test to execution spec test and uh I just think need some guidance what are the next steps I think the current status is so I picked like Swap and dup and as an example I think the current issue for the PO request is just doesn't it doesn't pass all of the Python lter

requirements not sure I should fix these or like yeah it would be nice if if you can take a look and give me some like feedback it doesn't have to be right now but and if if that process kind of improves I I'm happy to contribute more test I'm not sure that's that's expected maybe you want to like have it fully under your control but uh definitely we can put some resources into this yeah I I I can take a look um so the your yeah I can see your PR um so back to question for Dan know do you need a review on 522 which is the tests for EIP

7676 if so I can I can try to do both both of them today Demetri put a review on it I mean if you want to give a second review I was gonna his his changes SED reasonable so I'll go ahead and Implement those both basically um readability recommendations um but I I was able to get it past the lunter sounds good okay any other tests questions comments before we move on from the test subject all right let's go through some

of these spec issues um I'll go through them in order unless there is an objection um discuss version without a regular State change I think this is one we had discussed last week and um this is the changes I think it is where we would take out the Creator contract and replace it with the creation transaction semantics where we just combine um the call data is the eof container and the call data what that in here this is just getting rid of the create

Legacy create so the first one is getting rid of the uh ISC portion any concerns can we go ahead and move to finalize that okay hearing no objection and it's been out for verion and can you the IP yeah we published like with the same spec basically that is in this PR this is PR to meas spec and separately there is an AP now and yeah this is the same idea of putting both container and and call data it's call data into

Data of the transaction um here is yeah um okay and this this this coalesces all of the changes we discussed in it it's uh yeah it would be good to review but basically yeah I think it's what we discussed mostly we also uh discussed within the team another option of putting the Constructor arguments into a data section instead but yeah given that in this version We the tooling wouldn't need to change and can be used as is to deploy

e and and another concern that we had is forward compatibility with possible future special transaction type uh that will have like separate field for call data and then Constructor arguments definitely go into call data in those uh init code executions and then so what we have now should also be similar like so take Constructor arguments from call data not from data section uh so those are two arguments in favor of um doing this concatenation into in transaction data well there's one more that in this version uh the init code and non- init

code um has the same semantics um in the version where it would be concatenated and uh considered part of data then a compilers would need to know that they are in it code compilation context and then then behave slightly differently AKA get the constractor arguments from data as opposed from call data um so I think these were like the strongest arguments uh in favor of the version We proposed in the newp okay just a second I need to go deal with the plumber real quick um any other questions or concerns I'll have my headphones

on e e sorry about that I'm

back um so what was the opinion of the Epsilon team is this okay to move forward or do we need to take more consideration of the Alternatives I think the the big alternative is just to introduce because what it's kind of uh decouples the new transaction type from from from all of this um so like the the big alternative to actually have the the new transaction type and then you can nicely split these two two buffers like in it code container goes one one way and the the code data goes

into other place and yeah I think that we can it's mostly I think the the the main decision point is do we skip do do we skip this new transaction type um in the first deployment of youf on not and if we do this is the solution to how to deploy contracts without new transaction typ okay so from a practicality perspective I think skipping the transaction type as a requirement um will help get EF over the line um it's already big and we need need to look at things to cut and make things work within the existing system so that's that's that's just my opinion

on it um we can always come back later and add the extra transaction type um and I think this solution as far as working with a new transaction type isn't too much overhead um to support um and it might be good enough that we might not need the transaction type until we support things like TX create where we need to allow smart contract wallet to create arbitrary um contracts but until we um until we settle on a account abstraction format that's going to be brought into the protocol um I think we actually need to wait until it's decided to see what that looks like before we get to committed to a specific solution with a new transaction type I mean

it's I I kind of want to go forward with this as is but if ipsilon still has concerns we should probably discuss it for for another while make sure that we're okay with it uh no I I don't think so I mean like my opinion is kind of also slightly into kind of U like delaying this new transaction type together with TX create right is kind of a pack that goes together and they mostly depend on each other and having this new transaction types um enables kind of also nicer solution to this and I think we can we can kind of swap the solutions later as well in the sense that dicate this kind of hacky hacky concatenation with the

kind of nicer form but uh I'm not sure the others from from the team agree what uh I think that's was more or less the also like sentiment on our side okay um so since this is a new EIP doesn't even have a number I don't think we can finalize it but let's put it on the schedule again for next week for um final find bring up your your concerns and let's try and get a decision on this next week we definitely need a decision before um our meeting in the middle of May so yes to quickly confirm on that the version with the concatenation is also easier for

us okay all right but does it enable the decision about the TX create and new transaction type I mean so what allows us we can do at least like Po request to the spec with the updates like this you think it make sense yeah we can so is the mega speec the canical spec now or is it the eips sorry we we kind kind of we're talking time is is the Mega spec the

kinetical spec or is it the eips at this point at what point do we switch over to the eips being a greater source of Truth than the meas speec I think meas spec is still the main spec for now but we haven't merged this change this this particular change yet and TX so this is going to be updated I guess soon okay so I guess we could merge it in the meas spec if people are okay with that being canical but that also opened up other questions does this open up TX removing TX create from the current meas speec and the TX create init code transaction um is that something we can move forward

with with these changes is that or something we should work on Marius prefers measp speec so let's work with megas spec being canical and eips are artifacts we create to implement it the changes so that's that's what you would prefer Marius uh yes yes okay so we'll go with the measp being canical and pulling out eips as we finalize stuff um so I guess we can go ahead and merge because we discussed uh 78 last week there are concerns that are noted but I think for expediency we should probably move forward with that um that also unlocks eoff version without TX create in a nit code

um again the concerns with how we would do smart contract wallets are noted and those um are probably best solved when we get the AA solution that we're going to protocol put in the protocol um okay the next on the list was init code mode and require validation of return contract and this I think um will solve some of the test case problems that Marius might have run into with truncated innate codes um this would require us um to make sure that you know we have

return or stops in non AIT code mode and we have return contract in a nit code mode for each um section which shouldn't be too difficult to change from what we have and the biggest value add here is when we have eof create or return contract create point to a subc container that's um when we can do the size checks and I don't think that's coded in here um so return contract can have truncated data eof create cannot so that might be one thing we

might want to add to 86 yeah um by the way one thing this should all be up to date with the latest reviews um one thing that I didn't say in the spec but um it's kind of a maybe implementation detail that people worry about is that uh I think one concern is that it forces a dependency between code and um what is this container validation um but there actually isn't like you can decouple the validation you just um have a while you're doing container Val validation you do the basically while you're doing each of

code and container validation you create lists of you know init code containers you I mean you you assign Flags to every single container and then at the end when you've done all of it then you just check that there's two two match and that should be very cheap yeah that was that was my assessment of it too it can still be done linearly in order it's just a question of how you store the data yeah I mean it can be out of order actually there's no there's no strict dependency between the two right right there's lots of flexibility okay so that was stuff we were asked to review any concerns comments or should we go ahead and move forward with this change with the caveat

on the uh data truncation validation okay we discussed it last week no objections were raised so I think we should move forward with it um get go ahead and get that one merged when we get the fixes um return data zero padding and this is the return data load return data copy operations within eof um this is a request from the compiler teams um this is pretty common in conferences to say that these will bounce check is the only op code that'll bounce check um so any comments on this or should we move forward and write tests to verify

it this is one that will absolutely need tests to verify the behavior is is like a early feature of it one drawback that P found or brought up is that it's like the only op code which changes behavior in eof the others are all like new OP codes and then we deprecate all codes um EIP 7676 also proposes a change to balance for a dress Bas extension rather than trimming it will fail so there's there's another one that's

that's gaining it as well these are there two that will just change behaviors um in the way they handle exceptions yeah based on that notion our conclusion yesterday was that when the semantics are changed in in this manner we should probably prefer to have a brand new instruction a brand new upod for it okay um one analogous thing I noticed is in um I don't remember when this was Paris maybe is difficulty got changed to pre some hash right pre Grand yeah yeah

yeah and that's like a hash instead of a number and it has some like it's like still a single stack item but it has like some different characteristics like it it'll take the full 32 bytes instead of you know just a few bites I think in this in this case it doesn't really affect evm so evm just gets this like 32 byes of data under the same kind of like field in the trans action it gets in at least like from my perspective so it just yeah it just this instruction just ask it to to take this 32 bytes from

somewhere okay so it didn't have any um exception yeah the semantic is mostly take this 32 bytes whatever it means and put it on the stock um so so I think it's slightly I mean yeah we can argue that like depending on level when you when you put the boundary on the VM or stuff but uh yeah I don't know yeah yeah it's not the same it was just the kind of like the closest analogy I could find yeah yeah this one as a kind of example but I think it's slightly different but for with with the difficulty I think the thing that pushed that over the edge is there were contracts depending upon the behavior

that there was random data coming in not really random data but unpredictable data is being used to Su seed prngs for lotto contracts so because it crossed layers I think that's what pushed it over the edge of changing the behavior to be report on a different one um yes yes also otherwise you would get like n null value for for this for this up code after the merge right so that's also I think it's even worse that so it kind of fixes some issue with the transition to proof of stake okay um there was one more there was one more argument for data balance it's a slight argument U using a new up Cod for

it um together with the call 2.0 Balan is the only other op code in EF which does external account handling and if it also gets a new OP code then it can be grouped uh with the callop codes and you would be would be easy to check um if if if a contract is handling external accounts or not um with a simple range as opposed to you know looking at um random Ops but this this isn't like a strong argument right um so that is a good objection to 90 I don't think we can go

ahead and go ahead and close it that I think that's a valid arguments um so if we really need this Behavior we would need to have new OP codes and it will make the compilers logic simpler because they can just reuse their existing return data copy and return data load checks um return data loads new in eof do we want to have that zeroic padded or do we want to have it match return data copies Behavior currently it is zero P already okay so it'll they'll be different between the two of them but it's a new OP no it's not zero P at already not zero paded yeah it does right now it does the same thing as

return data copy which is like the argument is by analogy by the way I mean personally I don't I think it's like fine actually to like change op codes like like when you're emiting euf it's not like you will accidentally issue the wrong because like the semantics of all the instructions are different so you like just need to make sure that the Cen is different for everything I mean we already established a year ago that no compiler relies on the weird behavior of return CAC copy anyway so changing it in that regard has zero effect so I also think the changing it behavior in place without a new OP code is same a

choice I mean compilers may not rely on it but other conts May yeah other cont need to be aware of eof anyways yeah like euf is like all the op codes are new and it's just like some of them happen to have the same meaning as before but when it comes to return data copy would I do kind of hear epsilon's argument because it's just a subtle spec change it's not like we're changing the full nature of it um which I think is easier to see that you're getting right and just a little subtle change like that I could see tripping things up yeah that's more less because like from

the implementation point of view it doesn't make any difference I you can implement it whatever it's it's the same stuff and I think we'll make effort to to test this properly I think what what we what we mean is that uh for for any anyone outside of kind of core development and stuff it's at least if you have any kind of disassembly or tooling that just reads by up codes and try to analyze it it will be kind of obvious that this is something new here with the new number and it's not the old one so yeah it's that's mostly I think the argument but uh I think we don't have issue with implementing in other ones but I understand like we want

this these both changes right we just discussing how to exactly roll it out yeah I mean if it is a new OP code like uh like what do we call it like return data copy return data copy too return data copy zero because it's zero pads but is is the only issue that is the name or yeah I mean I just don't yeah like okay like if you put throw it into a disassembler you're just call it the same that's can assign the sameon the different output isn't that just as

isn't that just as confusing nobody expects the behavior a copy anyway so I think changing it either way doesn't have an effect it's just a cleaner semantics that is better for optimization that's the entire effect of it so I don't think it's worthwhile to consider doing it separately or at the same op code and just doing it the same up code keeping the name is the simplest and obvious choice to do that so I don't think there's consensus on moving forward or cancelling 90 so I think we should table it and discuss it next week so we can discuss the last two items on the list um and these relate to the cost of EXT call um there was a chart put up by

team ipsilon earlier today in the chat it showed there was a discrepancy between EXT call and call having to do with 2300 being added or subtracted or removed uh um so was there a call for a change here this um I just made one if we want if we want exactly the same behavior as Legacy costs for this case uh I think we need to change this back by changing the constant we we use and yeah I can I can propose to and maybe will be a bit more obvious

what's what's actually being changed exactly as a diff uh well I think we want to be exactly the same right doesn't really this numbers are kind of arbitrary so let's use the the number we actually uh used in the Legacy okay so the proposal will be to make these two numbers the same but these sections can be different and that's okay um yeah the other sections are different by Design and yeah this one's different by accident let's fix the accident yes okay um so let's move to finalize that next week there will be a PR I think number 95 will have it and I think the other

related issue increase the calls men retained gas yeah this is this is kind of more arbitrary um because just notice like the the retained gas is like five 5,000 right so it's kind of on the edge of sometimes you you are able to update the storage with this sometimes you not depending on like the condition of the storage if it was accessed or not and it kind of feels weird but it's I think not critical issue but maybe people has some opinions about it like what's should be enabled with this or not uh but we can keep it for later it's kind of invitation to to discussion actually so okay so no call

for action on that um and this is a change from the 164th retention to like a newer number 20,000 yeah yeah let's discuss it over over Discord I don't think there's an action to move on next week my concern is that's kind of a large gas number um for people that like to bring their um gas estimate to be as close to in line with Poss POS what's actually going to be executed this will cause some ergonomic issues but we can discuss later um yeah and I and I do like that it's being talked against something like we need to be able to perform this action

so that's why we need this number so that if we have to change schedules in the future and we come back and have to redefine this number because the gas schedule will change whoever's changing it will have some Benchmark to say this is the space we were trying to preserve um okay we could Define it as like maximum Sor time 1.5 okay um so to summarize adopt 7876 um and 86 table 90

and discuss 9495 next week um again i' like to thank everyone to call in who called in I'd like to thank uh especially solidity for calling in it's been while since you've se you it's great to see you again um yeah and we'll speak again next week um if you have issues or need help with testing just bring it up in the evm channel lots of people will help there all right see you right see you thanks regarding next week I think that's the first my is the day off in the most of the European countries so maybe it's a good to move it okay there's uh European holiday we'll discuss moving it in Discord then

there'll be at least 48 hours notice if we move it okay so probably Tuesday there's no other opt Tuesday fine to me yeah all right we'll discuss moving get after ACD tomorrow all right thanks everyone thanks see you thanks thank you bye