EOF Implementers Call #33

Transcript

o call um let's see you know what happened in the past week and where we go next um so as usual probably should start with some updates and I think I always start with Dano who's on the top of the list so Deno please go ahead sure um so I for the Basu uh Mega eof implementation we took the existing um EF tests which are container validation tests that are in the current reference tests and wir them in to our EV M tool can run them via CLI and also put in the hook so it can be run as part of our standard CI um if we turn CI on on that Branch or if we merge into main so the reference tests and they all passed for

container validation for the Bas of implementation um I also started bringing in um some of the bits I was working on for create three and return contract I'm not done with that um trying to get some good test cases to uh to run with that that a couple of the things I ran into there um some of the old test cases I had were before we had the rule that all subcontainers must validate so like a subc container holding just z00 obviously doesn't validate because it's not eof um so I had to update my test for that and I think some of the other um reference tests I was using have a similar situation where the subcontainers don't validate so I think I need to um and

just as far as implementation of of create three and of return contract I need to go through the spec again line by line and make sure that I have um all particulars implemented and then we can start writing test cases um another side distraction I have is attempting to get retest death to compile under Mac um I'm giving up on that um I'm going to just get an old laptop I have put a current version of auntu on there and just run retest that generation there and just you know copy between the systems um it's either that or get a cloud instance um and the laptop's free so that's uh my plan there and that's the stateus the basic awesome yeah always compilation on

on Mac always comes up uh all right let's move on to um Dragon if you want to go next uh don't have a lot to report basically I started checking out how the implementation is going to look like I didn't have I didn't spend a lot of time on it but from today I'll be basically working full-time on it so next week I hope that we'll we have a little bit of progress there awesome that's that's really great to hear let us know um on a side note we did had some plans

to experimented implementing some of the evm X instructions in rvm um for some tests but you know that that is certainly easier if UF is there so at this point I'm going to wait for you to to get like the Baseline you have work done um nice thank you yeah side note finished but yeah let us know um yeah whatever you find out as as you keep going next week uh all right Charles do you want to go next uh from Viper uh charge can can you hear

us he sent the message yeah he can't talk okay oh that's set to here with the veth hope everything is good um all right let's move on to ipsilon on First on on implementation updates if uh uh anyone volunteers um oh yeah Char said no updates but some people are waiting for spec updates from Char um yeah please confirm if if anybody is waiting for that um yeah there's the exchange of code PR pending

uh addressing the feedback and this is to the EAP 666 63 all right um since you okay um yeah you were unmuted you could just give the update on the spec and then we can finish with the implementation update okay uh so I think EAP 7 748 880 which is uh data instructions and 7069 which is re revised uh call instructions are updated and much with the meas

speec and um EAP 3540 the B the base EAP for e is um needs some sections the ones towards the end of the AP template needs to work on I I'm not sure what to put there to be honest it's about um oh sorry I I was I got confused um so 3540 I think is p is blocked on reviews I have updated it according to the feedback from Andre and it was the create EIP um that I have um I need help with with the last sections like

security backwards compatibility and whatnot and also it's it's up for review um I don't think it's public yet but if anyone wants to review just just let us yeah sorry go ahead I just want to mention that there's also a a few editorial changes done to the mega spec so um I would suggest that you just just go through the last comments on on the EF repo and see what what has been updated um sounds good uh I wanted to mention the security cons erations in the EIP is is always like this um

problematic section which gets filled out last and nobody knows what to fill out because it hasn't been analyzed yet by the time people try to track um but maybe that's something especially the fact of the create EIP maybe we should come back to that during the discussion section yeah I think so that's a special case because it's it's like a the entry points to the whole thing so I think it deserves some discussion um sounds good any more spec updates from you oh I don't think so that's all thank you um Andre or pav do you want to talk about implementation

updates St validation and creation implementations uh mostly working on that but also we started to uh finish up the logic of EX code copy X code hash when called from Legacy to eof uh because that was one piece that's not implemented yet also I expect this to be finished soon it's not too complicated uh that's all I think thank you it was a bit hard to

hear um all right before we get into the spec discussions uh last week we agreed to try out a focus week and we said that we wanted to focus on validation um validation tests um so maybe it's time to take a take a review how we what kind of progress we made uh regarding those um I think from ipsilon side we wanted to look into the test Suite if anything needs to be updated and Dano from your side you wanted to confirm just run the test and see if anything uh anything is missing or or failing um did did we made any progress

on the validation so a lot of the work that I did for that is reflected on the Readiness page um I enumerated for the eips that I we had tests for and there's a lot of eips we don't have tests for and I assessed basus Readiness to those eips I didn't have time to check into the ones we failed to figure out if it's a Basu issue or if the test does not actually reflect the EIP um but that's um I'm trying to you know because that involves going back to and that's where I'm stuck with the retest at to to reassess those I would need to be able to regenerate the tests with the correct values um when I if I did come to that conclusion so I'm a bit backed up on getting the testing

infrastructure that's kind of the obstacle there um but the existing um the existing uh eof container validation tests um appear to be uh correct they do need to be extended to cover uh subcontainers and also I think we need to develop some tests that address worst case scenarios um for example maximum containers of maximum size um maximum container depth um th those sorts of things where um we would want to test the edges of our implementations and make sure that they function correctly they function efficiently and if they break they break consistently in the same way per spec so that's where I've I've got on

the validation front right there um I did need to take some time off to finish implementing some of the features that um weren't done yet um create three create four and return data contract and I still haven't gotten exchange because I'm still waiting on the spec but that's the progress so I got on validation yeah I see the the list in the uh Readiness Matrix and there you say uh for each of them like execution validation 558 test container validation 54 tests this is just the sum of the test or the test Bas is passing it's just the sum of the test that's the sum

of the tests and then and the Readiness the number test that Bas passes so in the chart it's passing total oh I see it gives an enumeration of where where the tests are at that constitute it okay for the container it seems like um I mean 3540 it seems to be like a significant number of them are not passing yet um let me bring up that got some tabs open um.com epon E spec impation Matrix so which one you

talking about the container 3540 yeah um I haven't had a chance to dive into which ones are failing there and figure out which ones are um because of spec changing underneath it because I think some of those are old uh Andre you want to chime in you're muted or50 tests so it's really hard to hear you that yeah the sound is

robotic yeah maybe reconnect so looking at some of the tests I think some of them have to do with being out of spec because we got create two and create tests and create one and create to don't work for eof we have other plans for that so I think that's where some of these errors are coming in from but again I haven't looked at the test of the failure cases yet yeah yeah um yeah there is some work in to um change this because yeah the previous test was relaying on on this um Legacy um

creates uh but yeah there is um yeah yesterday I submitted a a PO request changing the test in order to um yeah do a different kind of U validation test instead of trying to using to use create um so yeah this um this pquest is um is already there um just we need some reviews and I think also Andre had some other um H po request I I want to check before trying to mer M but yeah the the this um it is already already being worked on cool yeah Andre posted the link uh of

his change which is titled update for Rel relax stack validation I suppose that maybe like an easier PR to to merge and then Hugo your PR probably will be much bigger because it changes the creation tests um what is our expectation on getting these merged and should we wait for it to be merged or should Deno be able to try the pr on Bas to see if what it changes I think um I think this um this

couple of PRS can be emerged uh during this um following week I guess but yes it's also possible that uh Nano can test using this uh PRS directly yeah I could load those in so I'm looking at like this 1337 PR we're moving some of the validation is that the one you were talking about Mario move creation test to validation test I think too many of the tests are being deleted because some of them do provide um functional testing like the 4200 our jump IMAX offset um so I think we need to consider some get rid of and

some we keep um if they're just testing the container because if it's testing execution we need those tests in the execution so yeah yeah there's um yeah currently a lot of them are being removed because yes it is it is only moved in the to check uh validation but yeah I um also Andre commented about for example um our jumps uh there there are some of the test that were valid were testing validation but also yeah execution so yeah maybe it will be good to have a second look there to which one requires execution execution

testing okay I'll take a look at these all look at all the eprs all right let let's see next week have we make progress on the the validation um changes hopefully the easier ones going to be merged but yeah probably the bigger PR from you Hugo going to be more challenging to merge um meanwhile Iman has also joined the call so maybe we should ask Iman to to give an update um from NE mind hi uh is my microphone working I

think yeah it is yep yeah for nether mind we actually found some bugs in our implementations and fixed them and kind of completed in a way our implementation of create three and create 4 and we have some questions one question regarding code section validation so uh in like the previous example this was given in E eips like 4750 see we were iterating over each code section and validating its up codes and right and uh we were discussing yesterday in

the team if we valid if up code if uh code sections that are unreachable so code section that are never called are they considered dead code as well I would like to say yes but I don't know what the current spec says so uh the consensus we reach is that they are considered that code and our implementation reflects that but I checked I think best with implementation and they still iterate over each code section so we were just wanting to

clarify which is the case and yeah that's it sounds like base is wrong there okay perfect and that's most of the updates for us we're still migrating our old test to the new implementation and it's taking longer than expected because technically I am the one implementing e and I have also EIP six other eips to deal with and so yeah time management is has to be done better for myself and yeah that's

it uh are these uh are we missing test cases to to catch this in base or they just weren't uh weren't executed is that a question for me uh I'm not sure who actually it could be to to anyone basically um I think where there is a difference between clients we should get a test case to represent that difference and put it into the standard tests yeah okay because ideally uh we can have code sections

that are never called in the bite code and they should be considered that code because they are just there and never reached since KF has you know the immediates embedded in the B code so we can be sure that if it's not Cod that valid it's not called that validation it will never be called at one time yeah it should be easy to fix I can Rite up a patch for that by the end of week perfect um so from side what I remember is that uh we have implemented this change I think fairly recent and maybe that's why

the test doesn't reflect that yet this PR you you linked actually up updates the test uh the test Comet so I suppose it does have a test um maybe uh it's not like I was directly working on this but I think it's it it's the test might have been updated but maybe they don't end up the main branch I don't know uh is both sound so say it again or or write it

down because the the sound is really bad um in any case Andre I did point out in the meas speec uh where this rule is introduced um so as a action point let's make sure that we do get a test case of this um or at least confirm it if it exist um I suppose you know maybe Andre or Hugo you were the most involved with this side of testing uh can one of you take up this um action point for next

week yeah sure I can take a look thank you uh all right we also have a new Joiner door um I'm not sure which team you are with if you want to do a very quick 30 second intro all right that's fine um all right then I think we did had all the updates [Music] um I guess we should move on to the spec discussion at this point uh unless there's any other uh

implementation or testing related question we want to to answer right now all right Peter do you want to take it off uh related to the uh creat IP maybe that's the biggest discussion to be had okay I can sure um so I don't know what to begin so there's three three sections which I'm not sure how to proceed uh in this specific case which are test cases reference implementation and security considerations uh I think yeah those

three are the main uh pain points for me I don't know if reference implementation are we can we get rid of this point quickly because we won't have something that uh in the AP I think that's that's an optional section now it is do we want to have this yeah just we don't okay remove okay fine it's easy um then move it uh and then security considerations um so I suppose uh we should have

something here um we didn't have much uh in the other eips on the topic so maybe a question to begin with is whether anything has been written down already on this topic for I don't think so so we used to put in uh TBD to be defined at some point the EIP editors were really um strict in not letting that to be merged as a traft um if that's the case we could just put you

know the the Alors are not aware of any risk but it has to be thoroughly reviewed something like that okay but nothing has been really um discussed before not yet so if you do have concerns now about certain aspects that is something I had one actually which is that uh since create 3 and for introduced validation of e at deploy time if so my thought is that if there's if there's some validation missing and some invalid goes goes through it will stay on

chain like a recurring worry worry from my side I don't know if we we have considered this ever and I also don't know if it fits yeah yeah we I think we we have uh just like looking from the all the IPS actually uh because I think it's specific to the to the code validation one um however the security considerations there refers back to the 3540

um but I think we can note it somewhere uh there isn't much there I think it it's most fit into like the main twos two APS I don't think it needs to be kind of it's it's not so much related to the create instructions but uh yeah I don't know I think we can add another like action item to to check if G has been written anywhere I think in like in the end this is not so much different that um like some other like consensus issues

like on in the same fashion you can you can anticipate that like if if balance computation is is wrong and like the play wrong balance would end up in the state so I think it's not so much different than this um although it's some kind of a new new new new door to to kind of break so yeah we can we can definitely note this somewhere um um I we validate on create 4 only and then this create three can can make more copies of

of potentially invalid you but if if create 3 validates all the subcontainers infinitely deep then there shouldn't be invalid a we in any valid we container no I mean right but if there's if there's some validation rule that's not that's that has a bug and makes um great for let it slip through and then create free can can spawn more of these contracts is this yeah I think the the question is more or less that how much are we confident that the spec doesn't have any

back door where you can somehow sneak in the euf container that will be invalid and and uh I think we can put it up to the point to kind of prove some of the properties but uh um yeah that's that's mostly the concern right so like to make sure there's no way to somehow put it there no maybe maybe I Mis phrase the problem like let's imagine that we have a create for contract that that we have a we we make the deployment with create four and the contract that's being deployed has a create three and it has some UF container

that has has a problem in general some some it's invalid but create 4 didn't pick it up and then in order to to rectify this I mean we can we can fix create 4 but we also need to make the creit free somehow you know the the to make it right moving forward the cre free cannot ever deploy those contracts so we need to somehow um reintroduce the validation and create threee or something like that if we were to do validation on

create 3es um suppose that could be covered by the per by in Cod charge that was introduced for uh Shanghai you me the EAP 3 3860 not the one yeah the one that shut down on it Cod the 48k they also introduced a per bite charge for create and create two which I don't think we we reflecting create three and create four right now mind I haven't been that deep in the

spec Rec I think we do but I'm not sure so if we do do it for create three if we do charge per bite for a create three then doing the validation isn't going to cause any performance issues right we just okay anyway this was that was my only thought that I had in in this in this area so thanks for the input and then the test cases would would

anyone care to assist here may just know can I have posted this this this document in the in our one of the E channels and just um take a look and review it I guess that's the easier part than than going for this on the call this cases are optional yeah but I think we usually had them in in other eips we Happ here well the test cases in the

IPS are just notional I mean there's way more tests than you should enumerate in the IP exactly that's that's was my point yeah so they shouldn't be like exhaustive because they would basically be re re reiterating all the rules that we have enumerated in this P okay I think I think you get the point so yeah anyhow with with this draft I would appreciate review and and

uh and I don't know what else do we want to do before we um open a you to add it yeah maybe we could we could consider targeting opening the pr on Friday or so um I think by the goal should be that we have the draft merged by the next call so that we can start referring to it by number and we can always you know we can always update it with with changes yeah so it doesn't need to be like super polished right it can be yeah exactly okay okay I'm off on Friday but

yeah but yeah we can uh we can open the pr on Monday yeah we can we can also open it tomorrow um maybe to the group here if you have a chance just re review it um tonight um but you know there's always a chance to review it on the IPS request as well um all right Peter do you have any other spec questions you wanted to discuss not to create I think I'm

good um okay anybody else has any any spec questions we should discuss now okay good then um I think what's what's important to discuss however is uh I think we don't have enough data yet you know whether this weekly Focus works or not so we should definitely try it again for next week and then decide um it it feels like the validation had like a good start just looking at you know what needs to be fixed what passes

I would suggest that we keep validation as the next weekly Focus again um with aim to to get much closer to completion um are there any other suggestions or are we are we good with this um yeah Andre okay just thumbs up all right any other comments because otherwise I think we can we can take it a short call um and by next week as we discussed in

the last few minutes we should have the last remaining EIP as a draft ready and hopefully make good progress and validation so maybe next week going to and hopefully as Dragon said you are going to work like crazy on implementing it so I think next week uh it may be a good time to discuss some of the potential um you know future testing ideas um you know maybe having some kind of a plan for the introp which was brought up before um but yeah let's see how we get there um by next week and U Pavo you have your hands up yeah um just want to like kind of have a summary of the the relax tag

validation um like to to my understanding but I might be wrong like this has been merged in evm one and in the in the spec and only test are not uh test are in progress right or I'm missing one okay not much I didn't have a chance to dive into the evm code the evm 1 code but isn't there a way to take some of your existing tests and spit out um reference test outputs from them to do very soon I have an idea for this um so I think um the current status

is more or less you can yes spin out like the J some test out of it but they are in this like final state test format so I think what you were complaining about that there's no way to like figure out what's what's in the test exactly because you only get the the state hash uh this is not like production ready feature but I think we might use that and there are some adjustments to so yeah that's the current status but we can work on like improvements uh if there's anything needed or I guess Andre mentioned that he has some idea how to improve that

so yeah so I would table mostly yeah I would table the filler Generation Um because I'm able to I've figured out how to get traces out of evm one now so I can just do a trace differential which so answers most of the questions um it's only if we get some of like the intrinsic cost differences that'll that will matter and I think there's a way to dump the final state from a ev1 trace but I think I have enough without with with just the final hash I can generate what I need in the middle and typically especially when it comes to like getting an operation wrong that's going to come out you know in bright orange on the tests um if I get an operation wrong and we're doing stuff different okay but I'm always for like

improve me improving like Tex testing experience so if any ideas uh how to exactly do it long term I'm I'm open to listening oh just go ahead all right if no other

comments um do we agree with the the focus of still the validation tests and um yeah the the creation IP uh for next week and then we can see where we are or is there anything else we also should focus on that sounds good yeah because my plan is to um get more tests generating from the reference tests look through these PRS get my creates working and try and get it closer to parody with evm one and nethermind um Amon can you share what Fork the nethermind stuff is on in the Discord so I could add that to my

differential test testing uh can I share what exactly what branch is the current e implementation on nether mind in okay I will share it in the Discord yeah share in Discord and I'll see if I can get that building in and differential testing between what we have sure um I'm man also maybe uh you can update the Readiness Matrix for nethermind because you have you guys to have a lot of stuff nailed down already sounds good he confirmed in

chat oh I didn't start scrolling thanks okay great all right I think we can call it a short meeting today and uh yeah let's get on uh with these new Focus areas it was a great call thank you everyone and see you next week bye thank bye bye record