EOF Implementers Call #49

Transcript

i' like to welcome everyone to e Implement call number 49 um nothing out of the ordinary on the agenda if you have anything you'd like add it please add in comments we're going to start with client updates compiler updates spec updates uh two categories of spec changes and uh testing update and other items um did we get clarity on the solidity return data changes last week before we go much further um someone could write what if we need to do anything about that in the comments so it's there when we get there um but first for client updates um ahed do you have anything for another

mind nothing from our side now okay um Andrew's next Andrew is next on my list uh do you have anything for um evm one yeah we have merged creation transaction support and also uh so also the change to xit calls to be add space expansion ready so this uh aborting on high bit set of the address and also we merged return data copy out of balance uh 0.

change yeah and yeah in code mode validation still not narge cool um I'm next alphabetically um Bas is just in addition writing the tests we're discovering some spec issues um things that are intuitively say one thing and spec says another um as I'm runting them and that's something that come in the spec updates um so that's most it another thing I'm starting to merge from the mega eof Branch into Basu proper um it's kind of a tangent that would impact uh testing but I'm not merging it directly into Prague I'm creating a a

fork inside Basu called Prague e until we get clarity on exactly where it's Landing um but for reference tests when you say Prague and reference test it's going to use prag EF but when you use it elsewhere like in a Genesis file or uh the evm tool doing traces when you say Prague it means Prague is spec if you want eof you need to do Prague eof um that's kind of something similar going on with the uh test and that they have a Cancun EIP 7692 Target that's that's coming in now so that's kind of lining up with that um see Marius anything from gu um not really still cracking on um I

think I have roughly 60 tests that are failing of of the thousands um and I'm going through every one of them and try to fix them um yeah but it seems like most of them are duplicates so should be maybe by the end of the week uh um um have something that passes most of the tests yeah since we can parametrically create tests we can hit the same bug hundreds of times with two lines of code so that's to be expected it's one of the

great things about the python tests um I don't see anyone from RE here don't see anyone from ethereum JS here or Aragon correct me if I'm wrong I guess e kind evm one it's for Aragon 3 um there any clients I missed if not compiler updates Charles do you have anything this week for Viper uh no but I've been working a lot on stack scheduling um which is like for existing evm and um yeah I have a lot of I I I was

wondering if there's like some kind of Shuffle instruction that is more General than uh swap or exchange what do you mean by Shuffle uh it's a generic instruction that takes like I don't know I just came up with it really um but there's like some things that are like not necessarily unsolvable but there's some stack scheduling problems that are like NP hard and um if you can just Shuffle so like it it's an you take you have like a one bite immediate that says how many items you want to shuffle and then a list of the items

that um you want to change in sorry how do you Shuffle do you like Shuffle randomly or no no no no no no it basically you have a starting stack layout and you have a Target stack lout and right now like we generate like individual swap instructions and e would like have more options like more swap dup exchange instructions but like what might be even better is just like a straight up Shuffle thing where start layout and the target layout Shuffle eight and then You' have eight bytes that would have the numbers one through eight in a new order and that's what you would change it to yeah

okay um and then that has like kind of easy costing because it's just like the number of items that are shuffled I think three times the number of items that are shuffled um I was also thinking about um the EIP 663 instructions and wondering if there's any performance implications once we want to like um compile to jit compile them or ahead of time compile them to native code um but yeah that's just things I'm thinking about and maybe somebody from Ipson or anybody else has has has thoughts about that ipsilon any

thoughts if you're doing register mapping I expect the dupes and swaps and exchanges to be fairly transparent but if you're targeting a stack machine it's same issues well the thing is like the kind of goal is to turn um evm code to like native code through like lvm or something right and the more things that are accessible from swaps the more kind of problems you have actually I don't I don't know if it's a concern in practice but like theoretically the compiler has to do more work has to do like register color ING with more

um stack items and I'm not sure if I think maybe these are just optimized out so at runtime but I'm not sure so it's definitely increases compilation overhead by an unknown amount um maybe negligible but um maybe not and there may be a runtime cost so I think I think go ahead uh yeah I mean this is also part of a problem about the gas schedule right so like I think a lot of things should be Revisited in eof because the gas pricing

is the way it is because of well the way the evm currently is and like things like pop um swap can be really like one gas or something like they shouldn't be really much more expensive so since um dupin and swap in take immediates you know a compiler could statically figure out how much trouble it's in so that is you know I don't think we have a solution for it today but that is one thing I want to point out why doing a stack based dup in and swap in would have been a compiler disaster I'm not a disaster but it would be you know we couldn't do it order end have to do it at execution time or do

Escape analysis so at least with in with it's an immediate you know in one pass how much trouble you're in yeah but like register coloring is like NP complete MH so like uh for the people on the call who are like not familiar with compiler um Theory I guess um like normally you have like all these like theoretical virtual variables right um which in our case are basically like stack items and then you have to like allocate them to physical registers at runtime and there's like an there's like heris to do that but um yeah to do it optimally is like NP

complete and I think the more register spilling you have like more register kind of um traffic you have the harder it is for LM or whatever compiler that you're doing because like the nature of the algorithm is just like kind of combinatorial yeah I think that's why people aren't fans of blocking jit compilers why they want aot or mixed mode compilers for the jvm but the you know once we Sol storage we can actually worry about those performance issues um then solidity is not on the call all right so if solidity is not

here that should be it for comp tyers um spec updates uh my first question did we get a resolution last week I thought we timed out on the discussion with solidity and what they wanted with uh EXT call return codes and detectability was there any action needed on our part or was the conclusion that um it's just bad and we'll just deal with it we made notes in the in the issue I mean you made notes yeah I made supp to here did we have a resolution were they okay with the status quo of what's an eof did they require changes well kind said that that's at least I

got an impression that it's more of a nice to them that they're they'll manage without yeah so I'm inclined to table this with no action unless lity raises again um they still have time if they come back in a meeting or two to get us to change on it but I'm inclined to if they're okay with it stick with it um who just came off mute if you have something to say please contribute U me no I'm probably watch

okay so we'll leave there and if they want action we invite them to come back and um make a very specific request yeah yeah yeah like a stronger one that sounds good okay um couple of changes that we need to clarify uh the first one has to do with um init code mode runtime mode this was a discussion on Discord um right now the specification actually I have it here um um the specification of whether your init code or runtime code is driven by the contents of the instructions um which creates a corner case when your only exit is a reverse statement and it could be

both um and also have creation transactions run and runtime mode um so I think we uh decided no on both of these and we're just doing a final pass on this um allow return stop oh yeah sorry this is a different discussion but we're not going to allow return stop in in creation you need to revert or return a contract and uh that's been merged and closed on that proposal and also run the creation transaction creation transaction in runtime mode and I think the issue there um is just gets too weird with Legacy

yeah and it's like the storage and value transfer problems and also that it sort of replicates 7702 in a way yeah okay one item that was discussed uh on Discord and merged pretty quickly because there wasn't much descent but I want to put it on the call to make sure everyone gets it um the uh that's not the link I had 124 eof EA so EXT delegate call um we wanted to make sure it couldn't call Legacy code and the way Basu initially coded it and ev1 coded it was to only

allow exe delegate call other eof contracts um what was unclear in the spec and has now been explicitly specified is how to handle eoa contracts eoas um that don't have contracts and empty accounts um is it bite code of zero length Legacy account or Legacy contract or is it no contract um one interpretation is only you know real contracts but I think what we decided to revise it to was the more restrictive one just for safety and that exd delegate call will only succeed if the target is an eof contract so if you delegate call out to an empty account or an EA account it will fail as though

it's calling a Legacy account um I need to update the tests for this this got finalized this morning um tests currently have it wrong but this should be easy to fix and um I don't think those tests have emerged yet and Basu currently has it wrong per this spec and it'll be easy to fix is there any revert data no it just fails without revert data it fails with this hold on yeah the soal light failure which is coincident coincides with the revert status code but there's no revert data so a a one status code I think that could be clarified because it says the C

frame reverts but revert can have revert data the status code is same as when the callif frame revers if it where to rever right I think this is specified slide the difference in thep so it's kind of piggy back on the like call that failure it's the same as the faure somehow yeah think I'm sure this is like the best description but it kind of matches what we have implemented yeah yeah I believe I probably need a re

read it uh P do you mind sending me the link off fine how far up is the Eva um is the EIP commitment I'm looking in the wrong Discord much is the initial gas cost for delegate call 100 is this the worm Co cost yeah I think it's it's 100 for the for the worm one yeah and

it's and and that is charged in this case obviously yeah so you need to fetch the account that's true uh but it's kind of true for everything else yeah so even if if there's a Code you need to fetch it and Yeah the code can just exit in the first instruction so but it's still going to be subject to um address warming yeah yes yes yes yes yes if it's cold then it's going to charge I think

we we we need to to treat it as like fetch account and I think that's more L consistent with all the gas costs okay I think that's implicit currently in the in the costing so we don't need to do a special case for that all right so I think that's it for spec updates um we're getting to size object go ahead can I can I quickly describe it so right now we have um for container size for subcontainers we have a size limit which is implied by the header format which is

64k and on the other hand we have no such thing for the top level container whatever that means uh we have the AIP 3860 Max in ital size of 48k but that is not validated as part of the eof validate and as such there's no you know it's not part of the validation test and so forth and the problem is that there's um as far as I can see uh it is that it leaves the evm implementations assuming what the maximum top level container size might be both in terms of how many buit that container takes and also what what is

declared in the header so we don't know if it's you know we should assume it's Max init code size or 64k same as subc container whether it is the whatever number we can maxed out by just putting the biggest code sections and biggest containers into the header you know make the header declared the container as big as possible or any other arbitrary value um and we had a sub bug in evm one where we overflown because um like the offsets that we have been parsing from the header were over overflowing because they were expected to not exceed

64k and the The Proposal is to to have a validation rule for the top level container to not exceed Max code size I me just align with whatever is um the init code size uh maximum so then the EDM implementation can don't don't need to figure out what that is it's just it's just specked out by the validation rules and if Max unit code size would go up then it would go up uh together for for I don't know for some future update and then all the tests you know

if if the size is exceeded then the test is just you know a failure I mean it test that the validation fails and if if the size is lower than this limit it's it's fine there's no um guess work involved what do you think I support it personally um when I wrote the test I deliberately went at those um levels to try and tickle the bug and um at the time there was no size checking Bas who had it I took it out can put it back in I'm totally okay with validating in it code and runtime code size at container validation time any other opinions just my

opinion and just to to make it complete I think we should validate both the the size of the by string that's being ingested and also the declared size so you know whenever the sizes which are pared exceed the the limit then it should fail yes like you know it declares I don't 200 subcontainers subc container sections and then the 2011 goes over the limit per declared size and then it's a failure what do you mean I'm not sure so like a truncated container for a

return contract um if it's declaring that the minimum size is greater than 24K then it fails container validation rather than runtime validation okay yeah I think I Mak sense yeah it's fine just wonder if it doesn't break solidity uh but I need to track with someone um because what I noticed is that they they organize test in a way that they kind of inject additional code to the test and then if the the test Target is already or close to the Limit it just do

above the limit I think we had examples of these um already with some like big contracts that we try to yeah but maybe rather can comment on this but I think I would agree to to put it in unless this like big reason not to I mean we can have it twice the max liit codes size so that's also an option at least as far I just I think it's it just like usability issue that like if we strictly start to checking this at the frent of evm that's like cons I mean

you would need to some other flag or maybe some something to to bypass it if that's needed uh mhm yeah but I think it's it makes sense to put the limit MH I mean we can also put the limit for whatever can be really crammed into a container like calculate how many huge code sections you can have and just sum everything up and and then you know just calculate that and have this as a limit I mean my main main premise is that to we have AIT you know cannot go arbitrarily large

or up to some undefined amount which makes overose right without size metering we could go up to 64 Megs I think so we need to do size metering somewhere 64 Max from which 1024 full size code sections yeah um oh the containers are 256 limited but and then so the containers can take up to 16 megabytes I don't know code or code section and the containers oh that's right because you can have containers of maximum size yeah yeah we need to

enforce it as part of validation before we get too deep into it yeah definitely but but yeah like I think maxed init code size is more practical or twice that amount it's just something more tangible than um trying to figure out what's the maximum we can we can declare so you want the test the test double init code size not maximum possible or you want the code to allow it yeah sorry I don't understand when you say double the maxit code sizes you want test to test the double maximum init code size or do you want the internal parsing to be able to handle up to that much the L the latter so the validation rule say is that the declared

and actual size of the total container cannot exceed two times Maxim code size so just other reference points so to speak any container greater than twice the net code size is invalid by rule yes and any container which contains a you know the declared sections which go over that limit is also invalid at the top level containers is limited oh the declared size okay declared one so by rule and we and we let the um we let the uh storage system and other systems enforce the 24K and 48k Rule

right I mean we can't just supplant the init code size Rule and runtime rule right now we do but for the cre transaction creation transactions so it size is checked in return contract yeah that's for the deployed code size including the expanded data section that's right yep but the in size is only checked in the creation transaction create transaction is going to enforce the 48k rule as well right yes but you don't really you know that's

not part of the validation so then validation is kind of kind of so validation only could handle up to 96k right so that would be twice twice the maal size one right but there's no way to get containers of that size in right but I mean the the pr is the the validation is kind of decoupled right now we have tests for the validation only right so there's no common point of reference of how big the uh input to where validation routine can be okay so implementation is going to be

prepared for 60k and the other one might be for something different okay I think we need specs written up for this then um before we can go deeper into it all right do it it sounds I mean because I mean if if it's adopted we would need specs anyway so so but that that sounds reasonable that for validation any container over certain sizes by rule invalid don't even attempt to parse it and we can change that value um as as blockchain Tech improves yeah I think that actually be fine I can write this down so that people can read it and Andre think you're thinking about validation of Genesis accounts maybe it makes sense

to apply the same size so right Genesis is also subject to the 24K limit right oh yeah right so it's it wouldn't work then this like validation limit should at least includeing your code limit right so yeah this argument doesn't apply maybe okay so we'll we'll discuss it next week with a br up spec on that and then we can move to finalize it and there's a question from Mario uh so the 64k limit uh it is kind of implied by the header format and but it only applies to

the subcontainers because we have two two bytes for the subc container size that's and there's a couple of things playing into that um Charles's VQ proposal would allow us to um not have that limit to have un uh arbitrarily large code sections um but right now the init code and deploy code limits pre prevent that from being an issue and I think a bigger issue um that I didn't mention on the verical call but I need to raise it is vertical limits code sizes 64k right now um which is going to be the bigger limiting factor going

forward than anything else in the world MH but that does not concern init code also which needs to be you validated we could do a bit for VQ in the header um there's more than just header size um there's also we need op codes that do VQ too um otherwise you're going to be limited to a jump range of 32 I mean you're R to jump limited with jump range of 32k you can't jump from the beginning to the end um without having a will help in between so we would need V qop codes as well yeah I

agree but I think that's something we can rev we can address in future additions to EA well it's like excuse me some way of um future proofing without making changes to the format right now yeah okay so um another proposal at the bottom this was talking about um something we were talking about on chat yesterday and today per spec right now a subc

container could be both a deploy container and a runtime container if it only contained revert invalid and didn't have a return contract or a stop or a return and by the current specification eof create M uh return contract could reference the same container um we need a this does not seem like a good solution right now so there we need to do probably one of two things and I guess we need to figure out which one we want to do one is we can require every subc container to have a stop or return a return contract one of those three operations if it doesn't have any of those the subc container would be invalid by rule and rejected the other option is to disallow eof and return eof create and return contract from referencing the same

container and letting the use context Drive whether it's a nit code or um deploy container um any preference on which options people would prefer are good question about the parenthesis note at the bottom of of the comment we're seeing option two would still allow containers that only have revert but only if either we allow that sub containers or it's a top container um I guess a top level container could have nothing but revert no if it can yeah if it only

referenced by one UF grade or like several UF grades but not return return contact it's still going to have a revert ah right sorry this was just like a weaker rule okay got you yeah yeah I think yeah I'm more in favor of the second one I think okay yeah I mean uh it's totally valid to have like signaling contracts which will never but okay that was my question is there utility in contracts that only revert and hearing that there is so we should probably keep them yeah uh but I don't actually understand why

is this a testing issue in the harness it will be uh we need to test all Corner cases and this is going to be one that we would need to test shortly yeah my should so implementation will be a bit simpler I'm still prototyping this but I expect it to be simplified I mean I don't think it's a very common use case but I think that I mean youf create and return contract both referencing a valid uh revert a reverting container seems valid they're just sharing the revert code it makes the code more complicated

and less deterministic though is is the counterargument sure we could save space but um I now that I think of it I do see value in reverting contract because you could have on one chain that will do stuff and another chain it always reverts so you could like lock up your um Solution on a different chain and always have it revert yeah I mean there's like erc's that just um but yeah I still don't understand why you can't have eof create and return contract reference the reverting contract or in

container we can it would be more code and more testing surface sorry what is the more code because like you have to oh I see what you're saying because like normally you only allow one or the other so yeah so you need to know which which kind of it is yeah by this OS create oriented contract and for each kind you need to validate in different mode so for this reverse container you would need to validate it kind of twice to make sure it kind of fits the buff bu bu context

that's I think I don't think there's a dependency right like you don't need to know what kind of container it is before you validate it you just like analyze it and figure out whether it's runtime or AIT code you would need to know how it's used yeah the testing gets gets hairy I understand I think yeah even if you validate and figure out which kind it is then you need to have three kinds so you need called R time and this third one which allows both yeah like two bit Flags right so yeah I would yeah this is mostly the complicated yeah I would want to validate by an an rather than validate by a pair of flags I mean it just doesn't really seem like

a problem to me but if if whoever's in charge of like testing it says it's a problem I I believe you so second is preferred any arguments for the first I think was pretty compelling what was presented for Y2 is better okay I think we should have finalized this next week then yeah we have option two kind of penetrated a bit right because it kind of did this and the option one is kind of new think I think it it might actually e to to to the Implement option one just kind of

localize uh but I think I would go with two as well I'm sorry could you repeat that again I my son's trumpet practicing was like bluring out my ears well the option two is more less into direction we currently exploring from different slightly different angles so I kind of like it more we don't have to put restriction on these additional instructions and like yeah the option one kind of puts puts restriction sign the instructions in the container right for the obvious reason why it's

why why you can't have un revert other the instruction okay I think this is another item we need um Cod it up and then finalized next week any other spec issues before we go to testing all right um let's go to testing

updates uh Mario do you have any updates for us anything you want us to be aware of any changes yeah so um first of all I would like to share some information that Dan uh he had to run right now but he wanted to share some information regarding e EIP versioning so U I'm not the expert on this topic so I will just try to relate the information that he gave me um basically um I I think there was signaled uh a couple meetings ago that it was uh there was uh we that you guys wanted to add versioning into the EF

eips um so we are planning on actually using this uh version in our testing framework to be able to first of all um see if there's anything any any tests that are out of out of date immediately when we fill the tests um so the first thing that we have to have is the EIP is actually having some version information um so for this um so Dan gave me two things that we have to have and the first one is the possibility of adding a change log uh section into the EF eips H in this is within eim eips um so the first thing is uh the

first question is whether this could be allowed in an EIP and if you guys are willing to add this uh CH change log information into the EIP um the idea is that uh we inside of the test framework also code a u a a EIP version for each of the tests um that we are writing and then we on runtime when we try to fill it we we try to fill the test we fetch the information from the EIP repository and we compare it to the to our local version in the tests and if there's a m much or there's an increase of a major or minor version in the EIP that means

that our tests are out of date and we should throw a warning somewhere this is just to make sure that we are actually feeling what the specification says um so yeah um that's one thing and on our side on T side for work we will um all we We'll add basically all of this uh tooling that we requir to pars um the EIP is we will make sure that um the the warnings are there but but yeah the first two requirements is is whether one this is is this possible in the eips and second if you guys are um are okay with adding manually adding and increasing

the version uh in this change lck in the eips um for us to use so I just wanted to bring up in start the discussion if if if you guys guys have any input a question the change lck would just need to start from some 0.1 or one 1.0 we don't need to fill in the entire yeah absolutely exactly so at at least I mean we can have a starting point uh for the for haap which could be like version one version zero whatever and we'll just match that to the current implemented tests or update them if they are out of the out out of uh out of date but yeah

the starting point can be anything we'll just copy it over to the tests yep does the version need to be in the Preamble header that's up up for discussion I think I don't I don't think then or anyone else has specified anything where this thing should be placed it's up to the EIP editors e if we have it in the Preamble it would

definitely be much easier for us to parse it instead of going into the sections and trying to figure out which section is change lck um so yeah definitely having it in the brand will make everything everyone's lives easier also the change log I think it was just like a stop Gap solution because we don't really need the change log for for for for testing side it's just um we just need the version if we want to see the changes we just got to the uh GitHub and that's it we just compare so yeah basically the chain L is just for us to have something to parse but if the version is in the Preamble I would rather have that and just add a number and um for the EIP editors just to bump this number whenever they F they have uh

there there there's some testing changes that need to be added or or modified um if they are unsure I would suggest that if you are unsure just mump it and we will take a look because it will warn Us in the testing side that there was a bump in the version we will take a look at the changes and and we will figure out if there's anything to be added and if so we will just update tests yeah I think um this is probably for the EIP editors but if we go to versioning and versioning exists that it should be enforced by tooling that any change involves a change to the version field it doesn't care um which of the three steps it does but it does you know

requires at least a patch update and make it put you know the rules in there um but adding a change log section I think is valuable you just add another top level section I don't think they care what top level sections are as long as it has the subset um those could be trimmed off as needed when we get to final and release but okay yeah I think we should do it but just my opion thank you and also uh if you guys have

any questions I think reaching out to them is uh uh he's available to respond any of your questions he also made another suggestion which is just basically adding so we have this evm tools that we used to fill we have have the even one and we have the Basu um flavors um to add a flag into this tooling to also return the versions that are currently implemented this is I I think this is this is not uh absolutely necessary on our side because U uh we will definitely just uh when we are writing the test and feeling them we will uh run into errors if there's something out of date but um if there's

a possibility that you guys add a flag just to return the versions that you have currently implemented it will it will make our lives a little bit easier um to make this comparison a little bit more automatic so for example if we are filling the fixtures and there's something failing in in the CI um and we have some way to compare what is currently implemented in the filler in the in the evm tool with what we have on the on the test versioning um we will automatically know that the reason why the T are failing is because there's something out of date with our evm filling tool again I don't think this is completely necessary um but I just want to throw out the idea to to um yeah just

just to get a a feeling if this is possible or not so like a separate informational flag like d-dip Dash versions exactly exactly exactly like that the the uh that downside is that uh whenever you are pushing a PR uh to update the EIP implementation in your in your uh client you will also have to make it like a recurrent thing to just make sure that you update this this output information right so it's basically more work for the client Dev I mean for Dev Dev for Dev versions it might be a little out of date because of the high frequency of changes but when it comes to like release theps it should be

fairly easy to maintain those versions and make sure they're static and pay attention to the um because that's another check if you put the version in the um the tested thep version and the test fixtures um then our reference tests could catch those and we could say hey this is testing a newer version of it should we update and we could catch it a little easier on our side for the published versions yeah we also we already have some information of the EAP Implement which is the comit hash we we already have the fixtures but this will give more more clarity because if you look at a hash you don't really know which verion it is but we if you look at a numb releas it to figure out okay I'm out of date or the tests are out of date

or yeah okay any other testing concerns questions details yeah I have I have another another thing uh so we um let me just share my screen um if that's possible um I don't think it's possible do I need like special permission I can just share the link I try sharing let me see oh I gu

now I always miss it that's always the solution there you go okay okay okay so here it is so um we made some modifications into the execution spe uh test framework and me just um go into the file that we added it's basically just a CI Improvement um let me see where am I okay the other Branch so yeah uh right now in main we added a configs um uh folder which now contains a feature uh information um so previously we only had like the stable uh feature and the development feature and both of these

mean like stable is just the the canum fork which is SC the release fork and we have the develop which is spr and currently it it it signals that the desks are being filled for def zero at this very moment but now we also have the opportunity to add more in this case UF so we now have have the EIP 7692 feature which is EF and we specified some of the uh um some of the configuration that we are using for this uh to F it F this these pictures um so what does this mean is that we have defined a special fork for for eof only and this Fork is called uh when we are

filling only this pictures um on the on the background it basically this Fork only B basically it just passes bra uh to the evm filling tool so there's no changes there but for us it means that we only F the tests that are marked for euf so now in our test uh directory we have um we have two two different uh configurations so if you go to the to the prac test and to the E of test we have a general mod mod modifier variable that is called EF Fork name and this one signals which Fork is going to be used internally in our test for the filling of the E of uh e of tests which is this in this case um what

this gives us is that the ability that we can currently fill um and make releases only for e and I will show you how does that looks like it's um right here so basically we we can tag um commits in our repository in two ways so the first one is uh the the usual one we have the version and one point whatever and that means that we are going to release all the pictures so a stable um develop and also e but we also can like do pre-releases which is tagging as EIP 7692 which is the name of the feature in this case EF um and add a version uh which is this version is specific to

this feature uh so when we do this um the CI will automatically in the background um let me see we automatically in the background go in and actually compile at the moment we need a tool which is at this point evm one um but we could use any other uh tool as as as we need um but yeah at at the moment it's E1 it compiles that and it fills all the fixtures uh and packages them in a nice U tar file that you guys can consume um so this is very quick um we we just push that and the pre-releases is already drafted for us so we can uh speed up a little bit the um the cycle of releases that we have

for EF specifically this already in main um I tried to do it uh today before the meeting but uh there's actually a new fail failure for evm ev1 so it was not possible so that's downside so since we don't have execution in our tests uh so we we need uh some filling Tool uh for for for for the fixture fields and in this case we the only the only one that we are exporting is even one and sadly is is failing at the moment because we our tests probably are out of date um so yeah if this was not the case we would be able to just fill all the fixtures with whichever evm tool that we that we can use and I think this will make the release uh a little bit

quicker um yeah so would possible to release would it be possible to release just the ones that fill and instead of having an error break it just ship all the ones that did validate that's a great idea okay definitely I think we don't have flag uh for filling to not on on on a failure but I think it should be fair straightforward just to add that flag pass it onto onto onto the feature um yeah I think should be definitely doable uh let me write it down yeah but then you need to make sure that you noted that there was some failures this it will just mean some of

the test will be missing and you might just miss it but this would be only for Dev mode stuff like 7692 when it goes full production and it's done yeah yeah know mandating also I also noted some some issues with the current Main and uh yeah we're kind of working on fixing this in in BM1 I'm not sure this is the same errors uh um yeah I think that should be done in in a couple of days yeah definitely I I I would rather not have like a single um evm tool be like the bottle leg for the rest of the

Implement implementation so um I will try to get Bess also working for this um it should be pretty straightforward and we can switch between implementations um just to make sure this is the downside of not having actual execution in our tests um but yeah and yeah one last thing is just basically the at the end of the day what you guys should do to um to consume the latest release for EF is just come into the um into the releases and you will have to manually parse for the latest so you will see here basically the latest one but below you will find the EF at and sorry EIP

7692 at something and you will you can fetch the latest fixtures like that yep cool beans so we're really good I think okay so we're about two minutes over time um anything that needs to be brought up that's worth extending the meeting all right if not um feel free to bring it up in next week's meeting if there's nothing urgent I'd like to thank everyone for showing up and everyone for participating another a good call thank you for your time thank you very much you bye thank you