EOF Implementers Call #66

Transcript

this is uh eof implementers call number 66 um it is Wednesday February 5th uh and uh here's our agenda first we're going to start with testing updates go to client computer updates talk about proposed test net plan and then go through specification issues related to that plan um so first uh testing update general e updates anything generally from East we need to worry about Mario hello um I think the most important topic is uh they wanted to chat about or maybe just U highlight it is this PR um I this has been open for quite some time but I just uh um took a look at it again repaced it and

refactored it and I think it's important now because basically it helps us to uh test the container validation in a in a transaction so basically this this converts an EF tests which were only validator via the um consumer of the EF tests in to to validate the container itself now what it does is basically dis wraps the container into a contract creating transaction and uh the nice thing about this is that one we can run run it in as a status and the second one is that we can also now with the deet coming up we can also run it in a live test net so we can basically just send every single UF

test that we have we can convert it into in Contra creating uh test transa sorry content creating transaction and send that to the to the dnet and uh we can see if there's any like uh consensus splits or any any other validation issues that we haven't got uh when only filling the UF tests um so yeah I think this is basically ready there are some things um that I had to modify and some tests that have been left out mainly the the main the main issue is that um some containers are just way too for a init code to be accepted so this have not been converted right now I'm I'm skipping the full test function

because that this is the only way that we have to skip uh things uh but I'm working on a marker um this is going to be a refactoring uh a general East refactoring where we can um so for example say that you have your eof test and some of them can be converting into status via the parameterized function but some others can't right now the entire function has to be disabled for status but what with this marker what we're going to do is just selectively some of the parameterizations just Mark those as non fillable to statest so this is a work in progress this is just an idea and then but at the moment I think we are we should be good to merge this um as soon as I resolve the conflicts in

the in the pr um a review would be fine um just to uh just to basically get uh the thumbs up from you guys guys that this is what we want um and I can explain further but I think if you guys can take a look at the at the implementation as is right now and then come up with questions to me that would be absolutely perfect uh but yeah any any questions about this is was the intention clear um with what I explained yeah are there any arguments we need to do with UV run execute do we need to like list a test subset like we would with the other times run it like T SL Osaka yeah that that would make sense

so basically I I would I would UB run execute Fork Osaka and then um select the folder so test Osaka and that should run every single e test that we have they it would run it as a state test on the on the um on the devet yeah okay um because I think we have I've been fuzzing um four specific builds or relatively relative builds um got G nether mine WTH and Basu all fuzzing so I think we're ready for a test that but I've been having problems getting the curtosis set up locally on my machine it might be because I'm trying to do it locally instead of in the cloud it might also be because um none of the consensus clients are ready

to do fulu without also including pz so that's some of the trickiness I'm running into and it's not set to do a split launch where we would have Osaka on the CL on El but um the neb on El not the neb um Electra so uh the nice thing about execute is that it has a hive mode um so I can I can take a I could take a look again because this was done quite quite a while ago but the nice thing about this mode is that it uh marcks the CL so we don't need any any CL configure to run Fu uh for this and we can just do like a a local run

justtin Hive and you can put every single execution um execution layer client in here it will send all the e of transactions and then you can see consensus splits um on a on a on a on an e level only uh yeah okay I'll have to mess around with that today once I'm done with all my meetings yeah I I haven't taken a look in in in a long time but if you run into issues just let me know I'll try to help you out yep okay all right uh poon do you want to talk about converting Legacy test to e yes

um so I I've been doing this for some time now uh like some time ago months ago actually we removed all the state test that are related to eof execution so the only remaining tests that are in the Oro are related to validation and I think there's still some substantial number of these um but I trying to manually convert them to um to python test and uh and this is manual work because I also want to know what's exactly there and if they make sense at all

considering we have some time before we we going back to in the full devet mode and so recently I tried to measure how how fast this conversion goes on and I think it's not it's not incredible like rough estimate with if I doing it alone I would take another month to to finish maybe half year so now let's see if that actually makes sense to do it this way uh in the in the long tail but uh yeah that's more or less the the status the something that is new is that um It's relatively

easy to to take the bite codes from this um existing Json Legacy tests and move them to python I think that's not a big deal and I have simple script that does that if someone needs it and there's also a draft request on East that's has all of the remaining test converted this it's just they have they are just um the test just have a hex bite code so it's not really clear what it actually testing besides some uh OB fiscated name it has um but if there's no comments I think I will continue doing so um if you

have some concerns or like better ideas or other stuff can discuss now or some other day yeah can you send me the the link to the pr I can take a look today if you if you if you you want yeah yeah but it was mostly like to for my purpose to um to be instead of copying the bite code from from Json I can copy it from one python to to another python test but uh yeah um I think this like big amount of test that are like kind of manual header syntax validation which not very useful

I believe right now but yeah I will send you the the overview it's it also kind of shows how much of these we actually have left okay the checklist is in the file somewhere oh

man a lot of files yeah I mean there's a lot of Legacy tests and they're fairly opaque but many of the files have like one or two tests only so it depends I had to move it into individual files because of pest how pest work so it requires some unique module names or something like that so at least the file names has to be unique yeah uh but yeah that was also a way to remove duplicates that were existing in the Legacy repo by itself and also remove duplicates that were um in the

East already so this is already done and this is more less the overview what is left but uh I see take one one more example at the time or like one sometimes error message or error code and I find all the tests and see how they fit in the other part so so this this was the reason uh you asked me about the duplicated UF containers right yeah yeah I wanted to make sure that actually or I was actually considering because this when you mentioned this wrapping um eof test with uh transaction right um there's one more

kind of test that is called eof state test which is kind of similar thing uh but it mostly is focused on actually executing qf after validation but it partly does the same the same job I think the difference is that we've been using eof state test from the beginning so there's no issue with converting these tests so I sorry I got confused um so the EF uh tests state test that you're referring is this something different that what we have in east or yes or are

you refering the East version to the east version sorry there's kind of a mixture of e eof test and state test which is called eof state test but this is this is what this is this is e right or or this is something else exactly yeah yeah of course okay yeah and you're talking about the test that'll do the E validation and if it's valid we'll try and load a contract and execute it yeah it's it's just it's it's it's quite a similar thing that Mario is trying to do with your test right okay because I think I I don't I

don't know the internals uh but I think it actually also wraps the the U bite code with a transaction and conf but maybe not I was to take a look it was yeah if you can take a look just please um I can just briefly explain the what I think the difference are so basically youf state test what it does is already puts the E container into the pre-state so there's no there's no deploy event happening at any point uh whereas the the ecore test converted to state test it basically just creates a transaction with the deployment of the

of the EF container so it's very slightly different but but I think it's it's it's it's worth to have like this differ differenti in Factor yeah yeah that's fine I mean I I just wanted to make sure you're kind of aware of both these because uh yeah but then besides that I'm completely fine with the approach yeah yeah okay makes sense thanks cool any other um testing updates we need to talk about all right hearing none we'll go to the next item uh client compiler updates

um no real update for Basu um re um nothing okay yeah still the same not seeing not seeing nethermind but they did a bunch of fixes over the weekend to um make themselves fuzzle and they did some refactorings and they're up to date so they're part of the uh fuzz now um GFF I don't see on the call Marius has started working on his patch again bringing in some M but he isn't fully up to all of them U Mary say patches still have some fuzing found bugs in there um uh who am

I GTH NE mind B [Music] E1 no I I don't believe we touched that at all since last call um ejs uh Nimbus Aragon I don't think we have any other reps on the call and I'm haven't been fuzzing any of those okay uh compiler updates so we have some from solidity on you have any updates you want to share okay so from our side uh we are finally done merging the semantic test updates from ADC so we basically have the whole test suits finally running on

E we're also doing uh the final tweaks like moving the VM version to Osaka so that's you have start to Osaka and then we'll be ready to release the release should be like in the uh coming weeks and then people will be able to test the prototype in on that releas like right now it can only be tested on nightly uh we also want now to prepare a list of like breaking changes for the language we come from youf I'm actually working for that right now and then we got our feed back from people on those Stranges and decide what to do about some things things like

those you have create changes but also like smaller language changes and as for what will happen next we like we have uh the low level bite code optimizations that R is working on but after that we want to tackle um the new OP like dup and Swap and to uh find resolve the stack to deep so that people can try it out on their code we want to make optimiz unoptimized compilation work and work and stabilize the assembly output for and that basically will be like uh the first uh stage of the Prototype and then we move to like

further feature so yeah that's it for that okay and this would be like via command line flag that says prototype eof or Dev e or would it be implied with the complete finished one I mean we have like this experimental you have option that you can use to enable it and yeah basically you can test the command compiler or Bas okay that's that's good to know because it kind of flows into the next topic we have to discuss okay um anything else that's some pretty exciting solidity stuff to be

honest all right um Charles isn't on the call are there any other compiler or developer tools people on the call okay hearing none um let's see I will go on to the next part which is the test net plan so as mentioned um we're getting to the part where we need to start shipping it into the test net and I put together and kind of socialized with some people uh the testing group and um people who asked what my thought of what test net going forward would look like um what our plan towards an end game would be um

this is something we'll probably need to talk about on ACD tomorrow or next week um so I want to run it by everyone on this call before I give it to a broader AUD um the first step is what I call Osaka zero which is we ship what we have specified for Petra with no changes um we're almost there um we have the clients ready I just need to get kosis working or we need to get the um uh the final uh kubernetes stuff set up and run but I don't think there's any changes to code we need to do to to start an Osaka zero and we might find some bugs related to contract creation transaction but that's why we run this um so we got Petra six it shouldn't be changing

anymore everything's merged up current with that with four clients that we have so I feel very comfortable with that there and I put some exit criteria um three plus clients pass all eel it's actually four right now um test net that's what we're going to find out 24 our fuzz we're already done with three of the test clients I haven't been running container fuzzing but I need to turn that back on but that's another thing um and then if we do the all those from the same commit I think we can put a bow on test at zero and say we have a success the real works starts happening in this you know it's going to ship as soon as possible um The Next Step I think is oaka one and we mentioned earlier in some of the calls we needed to do some some base level changes that we want to

do to improve the ergonomics so I'm thinking and those that might impact things like compiler layouts and um some some end user tool interactions so my thought is we pack every single one of those into the first test net after test Net Zero and we get them done with and we freeze um major portions of the spec except for features we're going to add and stuff like Osaka 2 later on so the idea is Osaka one would be the stable base that solidity can work off of and have strong assurances we're not going to change it unless there's some existential problem with the with the spec we're not going to move stuff around because we can we only move stuff around because there's a demonstrated typ safety or security bug it would need to be a serious bug for us to consider changing it um so the things on on the

list to clean up um we're going to change the eof create hashing like we've been talking about for the past couple months um and we're also looking at some of the other changes that are in eoff and Epsilon 165 um stack height of the section uh stack ARG order um change the name of an OP code um change the name of a data section and there's also a more involved proposal from here we go uh the power put together um and I I want people to get a chance to read this but I think one curve while going to throw at your pow is we need to

consider large containers so we need to get this logical plan to deal with the idea that we might need to have containers that are larger than 64k um whether it's a 4X container if we just use another header or how we would handle that um that is TBD um that's something that I think we need to put in with this consideration um so we can uncap uh the contract size based on code size limit based on the gas limit rather than based on some arbitrary code size limit but this is what I think we need to these are the sort of things that we need to fix in Osaka uh devet one and this is our one window to change base level things before we close the door and freeze the

spec and also one other thing with create crate 2 is an exceptional Hall um UND do some of that spec changes so again I would say that the uh same exit criteria once we do the changes we need to update eel tests and get all the clients testing eel tests stay since seeking a test net and and fuzz for 24 hours on both kinds of fuzzing um and that's when we would be able to say okay we passed test net one and then we can send out a signal um to to compilers and developer tools that these things are only changing in the event of a security level Bud um so that's what we would uh be looking at let me copy this URL just just came in the browser but this is

solidity um so the after that we would have what I would initially call the soaka 2 we call the soaka two to whatever and the idea here is that we do value added features now the first one does change something in the base layer but I think we put it in something we sever will because we could live without it but we really want it and I think we need to get some feedback from some of the um the tooling teams and some of the other core developers before we commit to to changing that in the base but I think that's the only exception here um everything else here is additive the idea is that if you can Parson run oaka one anything that worked in Osaka one will work in Osaka 2 um unless you know you're not handling one of the the new

features but it's not going to change you know core definitions other than just adding things that wouldn't be that we're not going to change numbers again we're not going to change orders of things if anything is put in it's going to be additive and this I view as the priority order we would we would we would Implement these and test and ship these in this order um so if if it takes long and we're behind on some of these and it comes you know August September and there's pressure to ship because P Das is ready we can just put a bow on it and ship it move everything else out to a future for so the intent here is to make something shippable whenever the call to close the fort comes we close it and we ship it and push everything else out to later so the first two features

are kind of related uh the TX create Return of the TX create transaction we've been talking a lot about that with tole contracts that's going to be the first thing we're going to bring in um and what that opens the door to is to remove the contract creation transaction and this is where we're going to need to speak with um tooling providers um like Foundry and not truffle anymore but hard hat and um and all the other developer tooling people um to make sure that they can handle that that e is going to have a different way to deploy contracts it's going to be an actual transaction getting new transaction type that shouldn't be too scary for them um as long as they know it's coming and want to make sure that they'll they're to get that in a reasonable time rather than relying on the old contract append and

ship uh method that's going to work fine with the current setup but the idea is we want to remove EIP 7698 and keep contract create transaction the way it was or if it starts with ef then the the transactions invalid and won't be shipped without any consideration of parsing so that goes back to the original idea before we had to make this compromise again into Petra that all eof comes in Via a transactions so essentially we've got contract deployment um The Quirk there is we're going to need to be able to uh predeployment last week uh with the changes being proposed for the identity pre-compile I think that opens the door for us to do there what's going to be done in EI in for for for pre-compile contract number four which is to bring uh contract code

that defines what's going in there specifically so it also depends on that in core developers which is why it's listed as a value ad if needed we can cut it if there's push back um but I'm going to push back against the push back if we get that and then after that we get the strictly additive features that I think we should try and get in the first rev uh the metadata section a request from sourcify um EXT code type this is something we need to fix ERC 721s um and also the EXT code address EIP where we can detect the delegate of it this is so opens up and create a safe proxy um and the I think these features I think this this ideally if I had a pick a point where we'd say this is what we should ship at V1 and ship it and if

necessary pressure appeared out to be ready you know return the pressure on the other side of the of the the fork I think this is the point we would flip over and say hey we're ready are you ready um in the standards here I've updated to four clients and I've added a few other things um we need to add transaction funding as well um we need add transaction F make sure we can get the new transaction format and we need at least one or more compilers to produce eof contracts looks like it's going to be solidity looks like they're in a good place to do that um but we need developer tooling before we can come out of a socket test n to of some sort maybe we put in also uh you know a developer a stack like like Foundry or hard hat that would

also support producing these contracts that's something we consider to add to the exit criteria I would like to ship this April May um so when it comes time for protocol BG in um Berlin um we'll basically say that we're we're ready to ship and we're ready to harden it um looking at getting a get together sometime protocol with people who are implementing it's kind of a nice checkpoint um there might be other Gatherings that we might be contacting people um but the idea is that in Berlin blockchain weeks those two weeks is going to be nice mid checkpoint because bur Lin before ECC so it gives us a little little better um The One S in this is at some point for de process is going to make up usaka what I'm proposing is Osaka only

changes and when they want to merge fulu and Osaka together it's pretty good this time because fulu and Osaka do not have changes that rely on each other yet um like when previous works like Denon the withdrawals absolutely needed both sides to work um the same thing with Petra but with fusaka um I think we've got to the point where we're mostly just connected so at some point they're going to want to join it and I think a good point is when we're at Osaka one or Osaka 2 or after um Osaka zero would be a bad one to do the merge um but if we want to start doing merge test Nets that's when we would start doing it it's kind of independent of where we're at and that's where if they want to do a test net where we might cut some items out of scope so we can do

fora test net and add us for later test net there's um some targets of opportunity that I think we should implement but not required for V1 if Osaka drags into 26 knock on with let's hope that doesn't happen um we might want to look at seriously looking into the contract size limit increases and defining that and then also the create delegate op code kind of unrelated eof but I think it's a really neat feature that's um once we see if there's good 7702 uptake that's going to be really useful in the smart contract side side now there's other features that we need to discuss and add or not add but I think it was out of fak scope for a number of reasons um one is the potential of returning ex data of not returning of creating an EXT data copy and ex data size op codes I think we

want to get at least one fork cycle without it to see if we truly need it to see what the pain point is and the same goes with tweaking gas introspection which I completely totally spelled poorly um let me go down there this is what happens when you write things in the middle of the night um we've got some feedback that some clients still might need gas introspection um as an anti-abuse anti-spam measure um but I think we should see what it looks like for at least another cycle before we decide what we're going to do whether we keep the design as is and rely on the Legacy

Bridge or whether we restore gas or the gas in the call op codes or if there's a completely different solution um this is another area where we might need to revisit and that goes with the design decision for how we're implementing gas introspection if we're wrong we just return the op codes um FR I'll I'll tell you uh offline I heard that from um not entirely public uh but it's yeah um and the other thing that we want to look to keep our eye on but it's definitely out of scope for fusaka is the IP 771 native account exraction with eof the account extraction people want to put some custom features inside eof to handle uh some of their specific needs with account exraction specifically um when

you uh um when you do the authorization separate from the execution they want to have a path such that is only available for authorization unless you explicitly expose it um so there some changes some headers to have some different styles of entry points and that's something that we could also use for things like uh Progressive recompiles um so that entry point method is is something that we could definitely add and use um and because it designed on depend on things that are going to need to see how the world develops after it those are definitely out of scope for suuk for fusaka um any comments on this plan any review points any requested revisions I I agree on leaving 7701 out

of scope but I will um it's I find it I think it would be likely that rollups might want to do it um so you know might still be good to consider it um maybe discuss some ideas during this year yep that's that's exactly what I'm thinking is we're still in the design phase for it okay um the only thing that I think is is like a little bit of a weak point in this plan is the removal of the creation transaction it's not exactly value

additive um like maybe it's just hard to explain it in in that sense yeah um it's more aligning it with the um full abstraction and the idea to I mean it's something that yeah it it is is trimmable that we don't have to ship we could the thing is if we're going to um once we ship the contract creation transaction With The Changes supp ports eof uh we're going to have to support that forever even if we turn it off on later Forks so this is on the idea of let's not add it since we haven't added it but once it does get added it's going to be there forever and maybe it's a fine thing maybe it's a fine solution um but it's something I want to have people discuss that the idea that eof only

happens via contract transaction entries to kind of get the full you know everything is on chain field to it rather than having special um interactions with with basically the the system housing the evm um but yeah that's that's good feedback that you know that might not be a necessary step which is why it's a separate line item um but we'll see how I mean honestly I could see going both ways in ACD I could see some people on ACD saying oh yes absolutely get rid of that we don't want you to mess with that transaction logic and other say you know but I but I want to use that I don't want to have to change my developer toly so that's something why iiz further down the road why I want to put it out sooner rather than later that that's the plan okay is there any objection to me

sharing this at ACD either tomorrow or Thursday all right um if you do have a if you do have a concern with it just tell me and um I won't share it but if the subject comes up on tomorrow's call I'm going to whip this out to say here here is the eof plan and if not tomorrow definitely next Thursday wi it's ACDC um to make it clear that this is how we're planning to go forward um because we're probably going to have more pector retrospective um great so given that plan um my thought is we should look at features in order of how soon we need to ship them and how

soon we need to discuss them um so the specification items will be done in in that shipment order um we got 20 minutes I don't know how much we need to talk about the cleanup items one thing that got added overnight um I don't we have enough context to discuss it yet is uh where was here we go um Powell's proposal for how we would change the header um the gft of it is we would encode in the first bit whether it's single value or multivalue and the second change is we

would get rid of all zero length headers Al um yeah I mean this is recent so this is kind of attempt to like um improve the quality of this kind of generic header design but um because Andre have found an issue with this and this is like some details there are some details in the uh like why we have the data section as it is I think uh we should discuss it offline and maybe it's actually not a good idea to to change

anything so yeah I think it's not conclusive that's that's good direction okay right in the end I think when we do no change it is also good so abolutely nothing that we can't ship with and yeah as you said if you need to really consider like this two by sizes I think that's much more important thing

to solve first and then we can like beautify the the like internals of of the encoding okay what um would the impact of going to a variable link bit size have on this very length by size using one of the various VQ or Leb 128 codings I would say it's fine or in general okay this most this is mostly about the

subcontainers right because I guess we can leave with the sh sh functions can you can always scale but adding more functions but if there sub container has wants to be bigger than the two by limit this is kind of undoable if you want to put it inside another container that's right yeah because we can we can just have a 4 by definition or yeah that's how we could figure that out okay okay so that's stuff to Noodle on for the call in two weeks um what else was on the

list typ sections having additional stack instead of total stack let me go to list of items yeah this is this is like quality of life Improvement uh it's it's relative easy to do I don't think there's a lot of test upate needed I mean there will be updated in the bite code but we mostly have kind of like semantic description of the of the what's going on okay um there's also I think um Andre had some concerns about um Ty

malleability um if you could just increase the size of a code section um from if it took only one stack 17 um yeah yeah what was The Proposal so the um the issue is that I I've been reporting is that um you can kind of artificially claim that uh you have multiple inputs and multiple outputs and they somehow canceled out each other so the function can be kind of empty and have only return but you kind of like forward some some number of virtually forward some number of input

and output and is this is bad on like for two reasons why first is kind of consistency we try to avoid some like flexibility in the how would you describe the the E program in the in the in the in the header and like in the all of this information around the code for example we don't allow unreachable instructions we don't allow unreachable subcontainers and so on and and then we require like specific Max St height computed not like the upper bound so we kind of have like strict limits on different things and this is kind of

slipped I think um so that's more as the the the overview I mean there's also like I find it an issue when you want to convert the um convert the stack based uh representation into register based representation of your program and then for the stack based interpreter it's kind of doesn't really matter so much but if you want to convert stack to registers then it's easily to create a function that doesn't do anything but somehow allocates a lot of registers also because we have like 100 28 inputs and outputs within the

limit so that is the concern but uh I think Andre found potentially like useful use case for for this thing so like if so I would put it this way if there's a use case that helps compilers and otherwise they would need to work work around it the spec I think it should stay as it is so I think the job for the next week or two is to find reasonable use case for the current specification now is this something that a a register conversion them could check they could see that there's you know two

used and 16 allocated could they check over the code and see that only two are needed and not create the other six the 14 um yeah eventually but you can always kind of like make it awkward to do that but even if the spec is changed you can always make some other like very very cheap instruction to actually use the so you can put like long um Swap and or something in the function that is single instruction that but like theoretically use all of the inputs and out outputs and doesn't do

much so this argument for the compilation it's not really strong I think if someone wants to mess it up with mess up the like some yeah some some analysis or compation you can always do so to some limit so I think yeah there not like strong strong evidence this is broken um that was my intuition at the beginning and yeah you if if you want to attack it you will find a way to make it the same the same level of yeah the same level of difficulty as it is right now so it's not will not

prevent abuse okay so I would still put it in this like sanity sanity validation rules but if there's definitely usefulness in having this unpatched I think we mostly need to find a reasonable description why this might be useful okay um I think that's yeah that's the only complex thing on this list because we already discussing the in it hash container something we're already fixing um that's got a known solution this is just a name and the um changing the data section index as part

of the proposal for the um container rework so there's not too much other than the max stack height and the malleability issues so what would be needed for this would this be a Amendment to the existing eips yeah I think all of all of this on list except the E create which I'm not fully aware of the solution is then if it's like solid solid one I think all of them is kind of small small changes to the existing KS yeah forf create

probably the same although I'm not really fully familiar what the what is the end solution you come up with right okay so once I once I get Osaka zero off on my list I'll probably pivot into getting some of these encoded and other people are more than willing more than more than welcome to to jump in I guess and guess some these worked on that um okay so I think that covers the fine-tuning questions um TX create we have a impr process EIP for TX create um hasn't been merged yet it's probably got some build

issues like they always do or we need to wait for the blessing from the editor yeah so there's this will merge here in the next day or two um probably but the uh EIP for TX create is posted um yeah just some htl markdown issues this is uh available for review and uh I think it's got the uh the new init code hash calculations um one question I wish zerox was here um we're going to put in one tow hold contract I think is the goal with

this and my question for them would be which variant of the tow hold we want so we can do the other tow holds off of um this this contract and I think what we have specified in here um is we're going to use the marker and we're going to use the TX init code hash and assault and the init data um and we're going to use that as the final salt so anything um that is passed in for the creation of the contract goes into calculating uh the initial address so that from there we can create a set of well-defined total contracts might do things as simple as just have a salt and the and the calling address or do fancy things like noseless like not

noteless salt lless creates that would use a pseudo notes within the contract to help deploy from the various addresses um so that I think is is um the one open question that we would need so let put down my notes I have some thoughts on this um okay the I'm not a fan of the ERC based factories because it's it's not going to be guaranteed to be there the factory I mean MH even though

like it's it's permission list to deploy and it would be Deployable everywhere this um redeploy is present right the tooling cannot assume it to be there and like it adds it can be worked around but it adds complexity and so even though the I think that kind of ERC based Factory is going to exist I just wouldn't make it a part of the eof kind of proposal because it's it's got this sort of flakiness and additional complexity that I I don't think is very nice okay so would you want uh big fancy

pre-compile or would you want a number pre- compiles to decide what the um I think think this PR compile is is fine like it just recovers it's I think it's got sort of the same properties um that current create 2 has right so it just seems fine and it would be like up to applications to do something else and like the current ERC or maybe it's a pre ERC might be fine I just wouldn't make it like an official thing like the way to do things I think this contract should just be the way to do things in general so if you want to use the ERC you would bring in a

library in solidity and not necessarily wired into solidity yeah exactly oh um I did have a bunch of open questions so about some weird interactions um so with this if you go in with a delegate call we only got six minutes so there will be mostly thought processes um should we block delegate call or should we let them do delegate call the reason that's going to impact things is if you delegate call into the precompiled contract actually our current rules prohibit that so you can't es delegate

call into a pre-compiled contract by rule you'll fail so this is actually almost a mood a mood issue but if you did it from Legacy in here um you could still do that and that would change the address part um so the the you would be creating into a different names space depending upon who your delegate delegate calling into another option is we could explicitly allow this delegate call um to be available and that would make your um make your um address a function of your address of the calling contract so there's one possibility there to get a personal name Stace Collision free deployments any thoughts on

that oh wait no this will be fine because it's a predeployment yeah it can be it can be nice it can be useful it's like a nice to have okay so we may be potential for confusion like the different way this behaves with call and delegate call but I don't know if it's grounds to

disallow right maybe put a nice large warning in solidity make sure you know what you're doing or it could be the default I mean that's another thing we might want to consider it's like the same with current factories would create too yep not a new issue okay all right um most my following were I think already has handled is address hashing okay with everyone is total contract okay with everyone do we need another toold variance I don't think we do okay um any other questions for TX create no we don't have much

time just a little bit of a not on the delegate call thing if it was like mandatory to use delegate call that's it's kind of more similar to the way that the create off codes work right so it's nice in that way in that way but it does seem very weird in terms of the the rest of the system that there this done right I mean we almost are able to

to um retire Nick's method for eof okay um we've only got two minutes left so oh go ahead no I'm just saying I love to hear that I think Nick method does need to be retired okay um we only have two minutes left we're not going to address any the rest of them that was the metadata section the EXT code type and also the potential EXT the potential code address op code EXT code address op code um so that would need to need to have a spec um but I'd like to thank everyone for calling in um we're filling up the meeting time hopefully we don't need to go to weekly meetings I don't

think we'll need that but time might happen we might need to call some special ones but I'd like to thank everyone for the work they've been putting in um looks like we're going to be able to shift this this year um if there's another Fork this year so thanks and see everyone in two weeks