EOF Implementers Call #48

Transcript

um welcome to eof implementers call number 48 um got a short official agenda but we also got some request items from Mario on the testing side um so we'll start with client updates compiler updates we got four spec updates to go through and then testing updates and other updates if you have anything you want to add it to the agenda please add to the chat and we will work through it at the end on a time available basis um so I guess the first question is client updates um let's go ahead and start with uh Peter from evm one do you have any updates from mm1 not not nothing substantial we are still uh uh doing some final polishes on

the creation transaction PR for even one and also we've got a tentative implementation of the return data copy modification and also we've got the the change to the validation to include in it cold mod validation in in progress or in review uh not sure Andre do you have anything to add not really that POS summary y so that's it okay umed never mind um so we don't really have any update uh on this on on this front but I think that uh we will you can start hearing that we have uh fully

implemented all of the uh eips once we finalize the spec I think this is what is going to be like okay but now it's the time to finalize the implementation because the spec is finalized then we will start working on finalizing the implementation because like we have an implementation now we're just not sure how much it differs from the current spec and we are not sure how to get the current spec so like once we have the final spec we can have uh we can just press the button okay now it's time to look into spec and make sure that it is uh implemented correctly in our side yeah so I think this is probably

something we mention in every um every meeting there's there's two main specs floating around this Epsilon eof is What's called the Omnibus spec and uhp D 7692 is the EIP spec [Music] um so those are the two main specs to work off of the Omnibus has everything in there um you can just read right through it and find all the rules right the 7692 works from um the various eips pie them together as a meas spec and you have to know which EIP to look for which specific rules there's you know some some weirdness with it but they're all

there they're all referenced so um right oh yeah spectr in the resource section oh yeah that's the obvious part yeah so here's here's all the specs okay yes so so I understand that the specs are are there and you can like reference them but like um like they're not finalized yet that's that's my the main thing so we want to have that like final final thing where we can say okay now we need to start comparing and resolving any discrepancies and then mentation um but yeah where where to find the spec maybe maybe is obvious but if the Spec's finalized is is is the question because this is what I keep getting when I trying to push nether

mind to say as a team to say and in ACD calls like we want eof in Prague or any Fork that is upcoming before veral uh they say but is the spec finalized but the spec is not finalized this is this is always the push back that we me and Aman are receiving and we obviously want UF we we understand the benefits but the this is the pushback so once we have that push back resolved this is where we can move forward okay so I would say that the broad Strokes of the spec are finalized what's being covered is finalized what we're negotiating over is little fine things like whether return copy data is zero padded whether we're

going to have return stop in the final uh init code um really fine grain things are there but the broad huge strokes and the spec list that we're negotiating over keeps getting shorter and shorter and they're really the in the weed stuff perfect perfect great uh so so I can I can report on that so that's a good thing right so the things that are changing are the things you find in testing like all the other specs that were final there were always Corner cases discovered in testing that they went over up until basically they for the test net and the stage we're in right now right right right gotcha okay thank you that's great okay um so that's never mind do we have anyone from gu on the

call I don't see anyone but we have someone from reth uh Dron yeah finally here sorry for the long pause yeah basically coming back to UF after like month or so uh I removed T create to code and just implementing uh New Creation from the Creator section I'm at that point right now and um from fundry side um we tried to to build like to use testing around it but I think the create it that creation of the contract is blocking one so I'm focusing on that to unblock

fundry to be used inside UF basically cool um when it comes to getting compilers working with eof that's going to be very helpful yeah yeah it's my top priority to be honest yeah cool um Basu I do Gary and Justin have anything they want to say or do you want let to let me lead with it okay um Basu is um right now we're writing contributing tests to the to the east specification using Basu as as the reference um and we're getting those you we got some some nice PRS queued up for Mario and them alter review um we did find one um interesting Corner case we

had coded it wrong from the spec but um we might want to keep the way that we initially coded it and that was when you're doing an EXT delegate called to a legacy contract that specified um but it's implied um when you do it to uh an eoa or an empty account that it should work but it feels like it should fail because then we can distinguish between account EAS and Legacy accounts so that's a p discussion on Discord to possibly change it that EXT delegate only works to other eof accounts rather than exe delegate fails on Legacy so that's one one corner case where we're discussing in Discord not on this week's list we'll see if we get it on next

week's list if there's any if that actually gets proposed as a change um don't have ethereum Js um I think that's it for all the client clients any other clients I forgot okay for compiler updates Charles already said in chat there's no Viper updates um is there anyone from solidity that wants to speak to their implementation we have cam from solidity and Ric was working right so maybe yeah so basically I'm working on um on I'm making all the test um pass and

uh and it's going well I think it should be ready in a week or two uh now I'm fixing some my minor minor things related to related to another ronning functions yeah it's going well okay um so with that I think we can go to spec update um so we got four of them and three main groups may I have a suggestion to start from the e EXT call the last one the return codes while we have Tam on the sorry on the call 117 there's no text associated with it

okay so go ahead let's go ahead and talk about uh number 117 extend EXT return codes detect account without code right um who's better revers to give an intro to this um no we don't have p on wasn't prepared to to give an intro here but uh the issue is with is a suggestion from from the solidity team to um sorry um was this the case where when you were calling a contract solidity wants to make sure that it has a

contract and it's not that it's an MP account or EA yes so previously this was accomplished by a next code size call and right now there is no way to distinguish between a call to a contract which succeeded but didn't return any return data and a call to an EA or an empty account this and uh correct me if I'm wrong but the solidity team um proposed to make a new return code for such a case but then um uh I think there's arguments against this which have been also mentioned on

the previous call um so yeah so maybe I'll argue for like for the Sol because for like to be honest this is not like something essential to the working of cost because basically like a sanity check that you have like uh if the contract doesn't have any called it doesn't make sense to call it like like from the programmer pers you just think you're just calling some function and like uh it's not fading is kind of often unexpected and undesired people are often surprised by it which is basically where the compiler just inserts an extra

check for it and it was possible to check it in before E now it won't be possible anyway it won't really break anything but it's like kind of now inconsistent between like uh nonf and you have compiled contract uh and like uh I don't see like strong reasons like not to provide this sanity trck I mean would be end of the end of the world but like just having like return code from create sorry from from call would like both be kind of cheaper than what we have already so like a separate check with an if and X code sides and it doesn't seem like complicate things much so we would argue

for keeping it mostly because it doesn't seem like harmful to have it like seems like I'm upside to still keep it from our side so you want EXT code size return again you want something like EXT code size returned uh I mean we don't really care about the size we just care about whether the code was there or not I mean there's an argument like for example someone could like deploy like a contract contain just a stop or something like that wouldn't be functional and it would be also not working and yeah but like the biggest use case of it was basically preventing like to P mistakes it's like of the same kind like someone like typing just the

wrong address like someone like using under s contract that doesn't exist or like that was supposed to be deployed or but like failed to deploy or something okay so you don't care if it's an eoa you care that it's contract is really what you're caring about EA or empty really doesn't matter from your perspective yeah exactly like I mean we don't even like specific about EA but more like whether there was like something to execute or not because like with this like account exraction propos so basically you could have a transaction like for just the from the transaction substitute some code and from our perspective it be just find you like okay like we called something there we succeeded we don't care it's like

permanent contract we care like whatever something could be called there okay um I mean recently I think the the arguments against this were account obstruction in some way is kind of I think makes this obsolete in way but I don't recall the the exact argument and the other one was that we're actually removing the

ability to distinguish between um like like in the topic that was mentioned just before about this ex delegate call but isn't it like possible to distinguish but just going to like Legacy contract like non ef1 and then checking it and then returning something true so it's like not like it's like possible just like more expensive and you want to check before the call not after the call right I think works right not really like for us like like checking after the call is even better because we don't

have to check explicitly so it's it's cheaper for us because one we discussed briefly in um Africa was changing the return codes to have different return codes for calling a contract and um calling a non-contract yeah I mean it doesn't you don't really need to do it it it's actually better to do it after because if you get return data then you don't need to do the check but I mean I I think we've like kind of already gone over all of this like uh I think I already presented the you know from Viper perspective it's very similar right we do it as a sanity check but it's like not actually that important

and if we want to ban code introspection then we should like do it properly and ban it I think uh Pav's suggestion which is just to ban calls you know a call to anything that starts with ef sorry that doesn't start with the EF prefix should just fail and you don't care if it's a legacy contract or an eoa and I think that just solves all the problems and I think that we should like write down all the discussion points so that we have them like recorded and we don't have to like rehash everything okay so the two first big arguments was

this is code introspection and we're Banning it so it'll be gone another one is a account abstraction we moving EAS to have code so you won't be able to detect detect it anyway but what was was there a third one I was missing um I'm not sure it's kind of part of the first one but it's like you shouldn't be able to call till Legacy anything anything that doesn't start with the eof prefix right yeah it's just like more consistent if you can't call EAS because EAS don't start with the EF z00 prefix I mean you should be able to call

Legacy right except ex delegate call or you want to b or call there should be a way to transfer still without execution right right because if we ban those calls we can't transfer to Legacy accounts we can't transfer to EAS at all and that sounds like a problem if you can't send ether to non eoas that is a problem and we should have a payout code and there is a way which is that you do the um create a contract and then self-destruct so if we didn't have if if

things stay they were today would this be problematic for solidity would we just be losing a safety check or is it something that solidity um would really want want us to require to find a solution to uh you mean uh just not providing anything or right just not providing anything let them make the mistake um I mean we could technically leave with that but just like we prefer not to have to I mean this kind of breaks expectations right um the the self-destruct hack don't

forget we ban self-destruct in the EA E Yeah e yeah yeah so there is no roundabout self-destruct method you can still use like Sentinel things but yeah maybe that's like uh maybe we shouldn't b s yeah I mean mean that's a tangent the big problem with self-destruct we got rid of and that it clears up memory but um the movement at the time when was first ban was we just want to ban it across all the evm and it's possibly going to be ban in Legacy this is before we we nerfed it back in the last hard

Fork um just one thing pay op code has been pushed back upon by a lot of CLI teams so I'm not sure it's really a good alternative which has been pushed back by G uh when um just C I think they pushed back on the testing requirements but they didn't uh push back on the concept of it well they were doing testing stuff and they found Corner cases and I think that's why they said it wasn't ready to be pushed into pectra I don't think that's actually what Marius said I think Marius said that he found that there were a lot of edge cases but he didn't comment whether you know right we need to cover the edge

cases before it becomes acceptable yeah and he didn't even say what the edge cases were um I think to my recollection the only client team that actually pushed back was like Aragon and their argument was that it's confusing to be able to send ether to a contract without transferring execution context but you can do that with self struct so it's like I don't think it's actually ever been properly discussed so what I'm worried about once we finalize the spec for eof is for client teams that are not joining these

meetings to suddenly realize that this is spec out and ready to be implemented and included in the next fork and now they need to look at the spec and they will have a lot of objections to whatever we have put there um and that's the frustrating part because we throw these meetings we invite them to come and they don't come and they come at the last moment and say we have to change everything yep I agree so unless there's a technical error with it or some sort of a security issue I would say if they're not here to discuss it then they've lost their opportunity because we've made very we've made a lot of accommodations to tr get him

here so um collectively what do we think what do we want to do there are several options which one do we want to work with or move forward Alex yeah I think we don't have actually enough data to know how frequently e is being being sent um to users from from contracts um a lot of the at some point a lot of the defi stuff was more working with uh wrapped eat and then now a lot of it is is working with

the you know the Stak eat uh versions um but at some point then some defi started to move back to to support e natively um so it's I don't think there's good data to know know but where I'm trying to get to is um there's this sentence here you know if you just been um calling like EAS then you cannot send it to them I don't think that's actually fully true because um we could still have like a dedicated uh Legacy contract uh a pass through contract to uh accomplish that yeah udx someone else's contract

and if you're comfortable with the contract and we'll send forward all the eth and you can still get it out of the system yeah I think the only downside of that is really um if the recipient depends on the sender address then none of this works so maybe it's not a good idea but generally I'm kind of worried about this alternative where you basically you have to check for the highest bit set to see if it's a failure or not right that's the new proposal well the high the the number eight

bit yeah which is quite a few instructions I mean it can be a comparison it can be shifting Etc but you know it's it's more than it's more than what we have right now I mean you know right now it's is it's double negation but with the before euf but with the EF we it's basically just an e zero would be the check and now with this we do need um yeah we do need comparison or shifting so it' be a net add of um

two op codes really per call so if it's less than and then you know it actually could I mean if we do it in order we could do an our jumpy so if it was um we could do EXT call our jump v um and

then code code error error I mean you don't need in the current design you don't need the E zero it's just X coal and R jump ey for the error oh yeah you don't even need is zero so ring four bytes so what would be a success from code or what we have to check out yeah that's like just two extra points right or two extra instructions well two two instructions about three

bytes the push the immediate and the GTE we don't have GTE so it's push equal GT so 127 no we just have greater than yeah oh it's signed greater is what I'm thinking of yeah SLT so I mean true to be said even with these

two up codes extra up codes it's still much less compared to what the compilers do right now you know checking for xcode size Etc but it it definitely increases the complexity of of the the call compared to what we proposed so far with UF it's it's also like I mean like I think I'm fairly neutral whether code introspection is a goal of e but if banning code introspection is a goal then like this doesn't do it because like you might as well provide an Isa op code right so the introspection I think what they really don't want us to do

what the request is we don't you know mess with the code and like rewrite it and create a jit on the Fly I don't think that asking do you have a contract um is that big of a concession so we could you know EXT code size would be sufficient just restoring that um because we don't want to do the hash because the hash is um even size as a moving Target yeah but the code hash gives too much information the size might leak information that it's a eof versus a non eof which is probably fine um we're going to need to figure that out anyway yeah and like everything I've heard from the account abstraction people is

like there shouldn't be any way of distinguishing EAS but that's yeah that's just what I understand from other people but that also allows us to distinguish from an empty account and a non-empty account which might be valuable too you don't want to call into an empty account you might want to send e to an empty account but you wouldn't want to call the code in an empty account if you know it's empty then that would be valuable here's a completely alternative solution having a flag on the input side of the call seeing whether it uh it accepts success if there was no

execution taking place so then if it if it reaches an EA then it would just um signal an error um my perspective is that calling an empty account is not that big of a deal um let it call the empty account and yeah that that that's even that's better than

being able to dis distinguish between EAS and notas yeah and in my opinion also it should be uh it should it should depends on the on the implementation of the contract which is called and if it doesn't return any data then you cannot distinguish it was a contract or not and uh so it's a matter of the implementation of the contract interface but this request mostly is coming from um solidity because it it does take the distinction into account right now and without this without any support for this solidity will have to change um

you know how they how they operate with EAS and maybe that's a good thing or maybe that's a bad thing but yeah I mean Camille what's this is a soft soft request As I understood cam yeah exactly I like actually we kind of bothered a lot by the fact that this would be different between like UF and non UF and we kind of even considered like whether we might just drop in for non UF but kind of that's a breaking change and we like in the end conclusion we we do see some value in this check because like usually it is unintended so that's why you argue for keeping it but I mean we could leave without it like I said but I still don't see I mean the create the call proposal from Alex also SS perfectly fine so

yeah argue for you okay um should we time box this and think about it for a week based on these notes and come back next week because we still got other issues on the agenda to discuss hearing no objection um we will time box this and return to it next week and see um what our opinions are um going back to the top of the spec updates list the first one is return data load and return data copy whether or not we zero pad or we enforce on Boundary errors um what was the current

thinking on this where are we at on it I think mostly in favor so all the final call for objections and then we um give summarize we change return data copy only in eof to not have boundary failures and we change return data load which is an eof only instruction to not have boundary errors right all right so if there's no objections I guess we can merge it all

right next one is eof there's a couple related to the question of how we handle init mode and runtime mode which is a fairly recent Edition um and how we handle things like return stop and whether we do the create contract in runtime mode um who was advocating for this change well I I I tossed but I I think uh it hasn't been really um not not not many folks were in um were in favor or of either change and Andre also brought up some um I think like

consistency issues with it so unless anyone is really excited about these Alternatives and I would just drop them and keep things as they are and just leave with the validate eof which um needs to accept an extra argument which is the runtime or unit code okay from basis uh experience on that can you can run it where it's unknown but also we're always going to know what state it's in it's going to come in in a nit code mode if it's coming from a create transaction and if it's in the state tree it's going to be in runtime mode but we're not supposed to validate it in runtime mode because it's supposed

to have been cleared through a nit code so I guess the testing implication is is everything in testing in nit code mode or is it unknown mode or do we add uh flag on it to say it's runtime or it I guess we're inclined to do the last the letter to add the flag right Andre add the flag okay yeah we discussed in the flag last time um second thoughts now maybe at least in unit test in medium one we don't have many tests for init code mode so like mostly tests uh check the runtime mode

containers and maybe we could have that as default or even like explicit only option and then if you want to test in it code mode you would need to wrap it into UF create so I'm still thinking yeah what would be better um yeah these are two options like either explicit flag or requiring everything to start with one time maybe if we're going to require one mode I would require an in code mode because that's what the spe that's how we're going to run into it yeah that's the problem is that then every test case must end with return contract to be valid and even with we uh test some uh

relative jumps for example and some other validation it will always require this return contract which is kind of annoying so it would be runtime mode unless there's a flag that says a nit code mode either that or it's just always runtime mode and if you want to test init code mode then just R it rep the case you have create okay what does Mario think about this I didn't get the last part so a flag or what was the other option so one is to always have all our validation and runtime mode mod um and if you need to test it in N code mode you wrap it in an eof create um that is a bit different from you're always going to start in the

NIT code mode and code um but it's just a flag and you you swap into it pretty easily the alternative was to add a flag and everything's presumed to be runtime mode unless we see the init code mode flag and then we flip our validators over to a nit code mode so some tests would have a flag some tests wouldn't so I think the advantage of the flag is that we can also do other things when we transform the test into a state test so for example if the flag is there and it says that it is in it code then we can simply switch the stat test to be a transaction creation uh contract um that would be much easier if we have the flag in my

opinion okay so let's do the flag presumed runtime mode and if there's a flag we're actually in a nit code mode okay all right good and that takes us to testing I think um yeah and Mario's got some things he wants to talk about yeah so um well first of all status um I've been reviewing a lot of the PRS and merg some of them I've also so made some comments on some of them and they're basically just minor things but overall I think that the Destin code

is is very good um and yeah they just there are still a lot of them to review I will get to them later this week um I don't know if you guys have any comments on the reviews or comments on how we are merging in the code or anything related to the PRS um but yeah um so I would like to know if we could keep some of these um requests that are being made during the reviews if we could get like a coding standards um a best practices document so um we can say well read the best practices document follow this and your code review will be shorter if you follow all of

these course things like don't use uh hard-coded addresses don't use hard-coded slots um name things for readability I think those are the big three things that hit so far yeah s sorry about the that last uh the review so the things that we we are working on a like a refactor because we had this idea of we want to be able to run the test in a live doet so we the the only change is going to be that we are not um going to use a hardcore addresses also there was an issue with rollups because we were using ZX 100 for every single uh smart contract that we wanted to use

for testing and now it it's become a problem because the rollups use this address for their Break compiles um these are another reasons we are going to refactor uh many if not all of the tests uh to to do some like pre-allocation Dynamic uh addresses um so at the end of the day I'm going to refactor them manually uh the EF tests I mean um I'm just checking that there is no like breaking uh pattern in any of the of the reviews um I think after we're done with this refactor I can write the document um definitely but it's not um it's not

setting in stone we don't have like a like a document that says this is the way that you have to write this but we we we will work on it definitely okay yeah I think that'll be helpful especially when we get to the world where um eels is the reference implementation and you need to have e tests before it can become CFI so absolutely yeah I agree all right yeah thanks for the for the did you want to talk about the versioning yeah definitely so um we had this idea just an hour ago so it's very uh very green I would say it's not uh final so wanted to suggest that since we

have like uh at least features that are being currently being worked on which is EF and bural which have not been included in at devnet um we wanted to make like a special uh tagging format so for example for eof it would be like uh we would have EF at and a version uh version string um what this would do would be to uh be able to do like pre-release formats where you can where we can package all the EF test automatically for you and we have pre-releases in the main in in main which will be accompanied by the latest Eva tests and we can do this very very very easily and

very fast so every time that you guys want to release something we can just simply tag it uh with this eof prefix and we automatically fill the tests um and package them uh for for us to for for us to distribute um uh that's one thing the other thing thing is that um it would be maybe easier if we create a separate change log for EF because we are going to keep a separate versioning um version number for EF and a different version number for something that is actually in Main and is actually being released for a devnet once EF makes it into makes into a devet we can then simply just reference the EF change log and we can

join EF tests into the main release but until then I think it's it's important for us to just keep a separate change look um it's not completely necessary but I think it would make uh it would make it very easy uh for us to make a EF release and just point out the difference between the previous test and the current tests uh that are being released um and um yeah and for the last Point um I was um I was working on um filling the pictures for UF and I found out that um there's a conflict between the current Fork definition that we have which is that we require for example the request hash um for for for the header

to be filled correctly and this was not the case with EV ev1 because ev1 doesn't Implement EIP 6110 so what we were thinking to do is just create a Nea fork for the ev1 tool when we pass the fork to the ev1 tool it will receive PR but in our internal testing and and the tests that we write it will be called EF so basically just it will be seamless for the ev1 tool but for us it will just serve the purpose of making the clear distinction between what is implemented in the eof tests and versus what is not in this case EIP 6110 and EIP

7002 um I think it will make things easier uh for us when writing tests and it's a fairly simple change to make in our in our framework um this is yeah this is just a suggestion um I don't know I want to hear uh feedback and comments what do you guys think about this do you guys like uh that we have one version for Main and one version for spef specifically for EF or is is that not a great approach for for you I have ideas but I want to hear some of

the other client team's opinions first is there going to be any issues with that for w or for ev1 or nethermind okay so I like go ahead Ahmed go ahead oh I I sorry I wasn't following um very sorry uh what was the question um how do we feel about um having different tests maintained for eof versus Prague until it's scheduled into a

fork uh that's fine but if it's scheduled for Prague then probably the same format is preferred we can we can agree on the format with Mario so yeah I think the when that time comes what will happen is that we will introduce EF into the other eips and it will simply be switch into the main release so now when you see the main release when that happens okay you will see EIP 7 70002 6110 Z and also eof inside everything inside of the same fixture package so a copy it's a copy of the main release but e only e actually

so without 6110 without 7,2 without anything else because the was request cash was the the example problem in this case yeah okay gotcha gotcha yeah that's fine for no problem but for eof tests aren't we not going to we're not going to test deposits and requests in an eof test are we um maybe until we make it into the devet so once devet uh so once EF makes it into the Tabet we can start to think about interactions between euf and these kinds of eaps unless we have unless we have like a concern that maybe there's a big

interaction that we have to test beforehand maybe we can think about it also putting that EIP into the ef ef releases that's a discussion I think but the alternative is before then clients could just put in empty with empty deposits empty with drawals and the uh empty tree request hash um just St those out in their T responses but then they'd have to mess with t yeah so my my my idea was that the euf tests they don't include the rquest cash at all in the header so just imagine canun plus evf and nothing else okay so my thought on this is this is

probably solving what's going to become a more generic problem is stuff that's coming into tests that isn't scheduled for fork in general um and eof could possibly be the lead for that you know we could get verical tests ready before being scheduled um we could get um yeah we could get any of the other smaller changes that we're going to want to model that they they start with eels before they become CFI um so if we can get a general solution and not just an eof solution so that what's scheduled for devet and forks is one set of releases and everything else has its own naming convention for example 7702 tests that's not scheduled yet but it's going to need to have tests um for the clients you know are we going to give it a name

or do we go by the aggregate um EIP number which I think is another question do we want to call them eof or do we want to call them 7692 um to make it clear which version of which aggregate of it is um I personally am favor of calling it EF um EIP 7692 um that would set the standard that stuff that wants to have its own custom build has an eof number that it's tracking against um and that also brings up another proposal of um we could have these Forks named Prague plus um 7692 um to make it clear that we're testing Prague plus the additions of this um which I know um gu has an easier

time turning on random small hard Forks but I think Basu for a subset of those we could make those work so that would you know make it easier for tests to make it clear that the fork is prod plus 7692 that also makes it clear what the base that they're building off of is for things like request hash so technically would be Cancun plus 76 92 yeah exactly yeah I I I'm um I don't I don't mind any any type of naming over the other one um but I think the if the EIP is more clear the EIP number is more clear that that's that's fine by me I mean this is actually like kind of

really interesting right because uh it means that like features for the evm can be like worked on without worrying about when they're going to be scheduled in and then like maybe when all the tests are passing for all the clients and they get scheduled in for a fork yeah exactly we we were thinking about more General solution for this because that this is going to happen over and over again even um we were we were also thinking about for example rollups if they want to come on and Implement something we want them to come to the execution spectors to implement that thing because it will be very easy then to just migrate into main net if something needs to be migrated to main net um but yeah definitely just this is EF is the is the primary EF and Merc are

the primary example right now but I think this is being thought of uh in more more General way we want the general solution for this and if we require a rip or an EIP number that encourages them to go down the standardization path too that's a good point yes so what does this mean for the tests that are in there today do we need to rech CH the de Target Fork to something do we need to um put version numbers in our eips I'm working on a um on a PR so I will try I will make another Fork

internally in the framework which will be called EIP and the number of the EF and all of the EF tests will point to that fork um okay yeah and I think should be a very simple change I will try to get it today I will uh send you guys the pr just just to make sure we're on the same page I have a question uh which is like how do eips interact with each other so for example if some EIP I think pay is a good example but it could be like anything um you know Fubar instruction like uh how does that get tested in conjunction with

e so we have right now if if both of them are included in a devnet um we simply add the um crossover tests in one of the of the folders um so for example well it's not a good example because we have the request the request is a separate EIP so the crossover testing between EIP 6110 and 70002 it was made into the into the other EIP so the crossover testing was there but generally what we do is just just simply add another python file with the crossover testing for for for those two AP that's eips that are relevant to each

other in the cas case of EF if there's any other EIP that is potentially going into bra that potentially disrupts EF I think we can just migrate the tests um and implement the this other EIP and also write crossover tests inside of the EF folder for the time being yes was that clear yeah sounds cool thanks okay okay just writing down what the proposal would be all

right any other comments about this anything else we want to discuss in our last four minutes any other issues um I think it's worth uh discussing Peter's uh 118 proposal in more detail but it doesn't have to be today unless there's time constraints or scheduling constraints so looking at that my my biggest concern um has to be the code address Generation Um because when you do create and you go into runtime um you're never going to have

contract deployed to that address and you might have left over um storage from the runtime so if we go in runtime mode we need to either put safety features on it such as um all that stores will be reverted or s store causes a revert on the first level um and we would need to track what 7702 does on that but I think my biggest thing I don't like about it is we lose the known space contract ordering and some people might still depend on that that when you deploy a contract with the notes that you want a contract to show up at a certain address when you're done I know at one point some developer tools had that hardcoded which was fun to deal with um when I was working at hadera um but they think they

they've recently moved away to take the return value of the cont contract but it's some things that some places have built as an assumption um we can discuss it next week but I just want to put out there that those are my major concerns with 118 is it's such a significant variation from the model that it would break too many expectations so we can put it on next week's agenda right any

other comments if not I'd like to thank everyone for coming thank everyone for participating in the process it works better when everyone is here and talking and I think this is a very productive meeting so like to thank everyone for see everyone in a couple of weeks thank you see thank you you bye byee