EOF Implementers Call #15

Transcript

hey everyone uh welcome to the eof implementers call number 15. let's go ahead and get started with some client updates does anybody want to have anybody want to share some of the updates they have had in the last few weeks Simon from Netherlands side from the from nethermite side you are a very quiet Island okay from Netherlands site we prototyped the three call opcodes the call delegate call and static call 222 and uh we fixed some bugs and that is

mostly it to be honest you're under great thanks for the update Dana mostly I've been focusing on the new ram calls and Telethon that came up in uh for Cancun the uh I haven't done the pay but the M Copy and I've been doing some optimizations for call to get ready for call two that experience with deep deep rabbit hole um that it probably went too far in some areas on with with undo lists um yeah I guess my main question with memory copy is um this might be the wrong call for that but what the concern from the testing

team is about why it's not easy to put in but that's not for this call yeah maybe we have a minute to talk about it later we can did we say that Impala was going into Cancun or is it still up in the air it's still up in the air we didn't have enough time to talk about it we spent so much time on I think ssz or we spent too much time on self-destruct is ruining my business right okay yeah if we have a man let's try and mention that this is the eof evm and friends and so anybody who's trying to change the m has to band together you know uh yeah Epsilon do you guys have

anything to mention freezing one we have emerged data of codes implementations that's one update and yeah some other work is in progress like uh call new calls implementations and Target call restriction and grade three great any other client updates any compiler updates in the last few

makes sense uh spec updates questions comments yeah I think there's some update from uh we really try to merge some of that saying EIP PRS I think around the delegate code restriction the the rjm3 um numbers and I think I'll be just trying to do some under specified pieces if I recall correctly power was was working on that

but I think besides that most of the focus has been spent on the uh call stupid now um discussion and maybe also had like an internal discussion regarding the occurred renaming because basically we have all the UF stuff implemented in evm1 as well as M Copy and M Copy based on the new table the M Copy uses the rjm3 of code number and we were wondering if if now we need to I mean change every single UFO code and update the state test in order to unblock any any further work on and copy and anything else

but we agreed that the um the the new opcode structure is is nice so we if you want to do it if you're just wondering if we could delay the work I guess changing all the test is quite a bit of work I've got the table on lists ready to check in so the execution spec but I don't know which buttons to push to get it reviewed emerged it's not terribly clear in that process who is the right person to uh pursue to get a updates uh so I think Sam Wilson is probably yeah one of the main maintainers of that

repo I'm also a maintainer of the specs repo and can review it and Tim also and since like we did discuss it on all four devs and people seemed okay with it I think yeah I don't see a PR in there right now but if you open the pr we'll we'll see it and get to it so then I guess just the question is is like when do we want that to sort of become active and I think relatively soon um I think it'll be a great provider between big eof and mega eof not just a few op codes but the full renaming of stuff so it'll make a good line of the sand between the two generations um One open question there is a request to move create three into the e-block and another sub question from that is do

we put it at um ee or do we move it around so let's create three create four return contract I'm inclined to uh renumber it so create three as EC create four is Ed and return contract is EE and then we reserve EF um for compatibility what do you mean reserve for compatibility because it is already banned in three five four one as the first byte but not as a byte in

general yeah you're right sorry I see does it sound okay with people I don't think I have an opinion on this okay yeah that's sounds fine to me I'll get that updated pushed up before I go camping um let's see one thing I was thinking on this is if

it would be possible to have the table have all of the op codes contiguously as well and maybe have a section for the proposed what do you think about that there are four pages right now there is a pending op codes page there is an all op codes page there is a box page and there is a page listing every proposed op code ever in the history of eips perfect yeah that hasn't shipped once it ships it gets cut from that page sweet yeah I think it would just be cool to have a list of like every op code and then maybe uh you know if there is still contention around two things going for

the same op code have it clear like what what are all the things that have been proposed for this specific off code that's a long list and there's a long list of stuff that's been abandoned which is why I separated it into proposed and there's pending and proposed and pending a stuff that has been talked about recently on all core devs and proposed the only requirement is that you've published and even asked for an option okay yeah and there's a lot of those that we've got yeah a lot of those with the outputs have already been overwritten for the proposed but I haven't updated listed propellers right okay the pending list has no conflicts yeah so I think that in the list of all op codes if we just have the pending ones there as well so we can like kind

of have that overlay to see the overall layout with the pending applied is useful okay so I'll make a fifth page um uh or I'll do another section under pending op codes yeah whatever you think and then we can yes we can see what comes out of it on the pr but I think it'll be fine okay sorry Alex you mentioned not one into make this change around in copy op code for a little while when would be good to

like come with these new OP code organization no I mean it's fine it's just you know it's just quite a bit of work to do the UF um test updates because I think we spent I don't know a really long time and changing all of them from Shanghai to Cancun and now of course we need to change that to to Prague and also dot codes um I think it's going to be I would like two weeks worth of work if anybody's I mean you know it's just an insane amount of test to get

they all of them need to be refilled okay yeah I mean I think probably best then is to like have a note in the mega eof spec that these are the op codes and we can continue moving forward with the op Code table that Daniel's come up with the assumption that this is like where things are moving but not have any kind of further eof work blocked on moving those tests over and that can be done at some later points does that seem okay for everyone or is that too confusing that seems fine

let's plan on doing that other spec questions updates I'm in uh hi I heard in the I think 4844 call that they are thinking of invalidating that the two field in the transaction in the the new transaction format will be will not have a null value or will be invalid if it has a null value so will that affect the new transaction format that we have for eof

so what would the alternative be for create transaction all zeros what there will not be a create transaction for blob transactions okay oh so we're blank Banning creates there that's no creates or blobs that's good I generally think it's positive because we as you all know have to come up with all of these tests for all the different scenarios and so transaction creation is this other annoying scenario we have to then test every other thing as part of so I think with eof the transaction exchanges we need to do we're going to have to do that separately anyways

so it seems okay I mean with the create for design we didn't really create transaction that's that there was a point it would be just you know these extra payloads right somebody wants to create and I mean deploy from an eua then they just use the Legacy create transaction you know before 444 yep perfect [Music] other spec comments questions testing updates do we have anything to

talk about um yeah well for my sad not much I've tried to include evm1 into the execution specters python tests to be able to fill the desk and this proved to be a little bit more complicated than I expected so I couldn't manage to um include even one yet um it's not the matter that it's not possible it's just that I didn't have enough time to um to spare for this so

um I just need to work on it a little bit more and we will should be able to fill test this in even one I I think things would be a little bit easier if there was a get implementation but if we want ebm1 at some point to be able to fill the python test I think it's uh it's worth uh fixing this this uh the interfacing between the python test and Avion one to have to be able to to fill tests in the future um but yeah apart from that not much not much for for myself cool yeah I think for eof it is really

useful to have evm1 as a test filler for the spec test just because I know the Epsilon team is familiar with the attendance it's nice up there kind of the main maintainers of it so yeah if we can get that resolved some point in the future I think it will really help the testing effort yes definitely I don't have a a specific into I think it's just a matter of fixing the types that we are passing through even one because it's complaining about about types so so yeah no not not much to share on

that I I will just keep on trying eventually it would probably be nice if there is a better spec for the T8 and Tool frankly yes definitely because we only have the get implementation to fall away I guess so that's that's an issue um yeah bases try to implement T8 in off of uh making it compatible with the execution little specs so there's somewhat of a working g8n b11r tool there but you got the startup time issues there so you need to compile it to Graw

which is something that I haven't documented very well so basically this this we have eof implemented and I mean I can give it a shot also with it if you guys have some working implementation of dn8 and also EF maybe the December eof set up and you would need to pass in a specific Fork um I'm going to be camping all week so I can't help you there this week um maybe ping me Monday if you're still think it's a good idea to to work big eof but we don't have the new OP codes for Mega eof yet so we don't have create implement it we don't have Creator call yet for Mega eof either

yeah I I think it's it's still just a good option just to try to push through ebm1 I I just need to find the time too to address the issues because we're being crowded let's say um add this for foreign but but yeah I will try to find some diamond and and push through for even one anybody have any other testing related content to discuss hey Zane

hey it's uh been a little while uh I actually just wanted to just double check uh if you're interested in testing out some of the eof functionality is EDM one the best way to go about that actually can anyone here we hear you I was waiting for somebody to jump in and say you should use the power implementation but they didn't um I don't have all the op codes in yet so

um yeah we have jump we have data load um let me put on the list it's um Basin hasn't done create three create four call to return contract um we haven't done those yet but we're up to date on the current uh container format which I think is a bigger issue I think I think our our jump our our jump f is out of spec um so if you want to find test at break and do some differential testing that'd be a great one because you'll find great broken stuff in some of the jump F validation cool cool and yeah so the fork you'll need to use in evm tool

is future eips um or you'll need to set that in Genesis since it's not locked into any particular release site right now it's not even locked into Prague so I think we put it in future eips you mind uh dropping a link going camping this week so I'm like literally gonna start filling up the car I gotta take the boys out so this is like a battery for me I could I'll be more useful on Monday all right sure thanks uh there's also this make this to Do's in the mega spec like whether to 4 bit

call F to non-returning up uh code sections or do we have call F in code sections I mean not returning code sections and the signature of the main one are we gonna have them resolved or they will still be to Do's for the foreseeable future anyone yeah I think the probably for the next

two to four weeks we definitely going to focus on the course 2.0 and probably I'm copy and once those are in like a better shape then we will get back to like degree of changes at least that's my expectation but you know that there may be some small deviations to it I don't really remember what big to-do items we had there I'm not fully sure if the non-returning function of flag was added uh maybe that's what the to-do is referring to because we wanted to we agreed on having the flag and we wanted to edit I'm just

not sure if we actually managed to do okay since all the to-do's are related to the non-returning code sections so I guess you are right other testing related things thank you

did we want to go and circle back to the question about M Copy yeah please do yeah so there was some chatter we had like two minutes to discuss M Copy on all core devs but there's some chatter about concern about increasing the testing surface and how we should only add very few op codes per release and I I'm just wondering what the um with the scope of the concerns is I mean if we're going to do eof we're totally going to be changing a lot of stuff in eof you know it's

um I want to understand you know the impact of that of that statement so we're not overloading testing or if we need to help short testing one proposes how that figures in a side comment to that I think that's one of the motivations of uh why we propose a calls 2.0 now because it's it's useful for UF but it should also be useful outside well in fact it's required for us but should be useful for outside and if we have it in a different Fork than the

surface area for the UF changes is reduced and the UF changes are quite significant anyway but on the University question is uh is like the cost 2.0 changes too big um you know for Cancun but yeah beside comments yeah I mean just the general comment I think people are worried about to changing too much and I don't really see how there's that much

overlap between M Copy and t-store I'm like a bit against this opinion I do understand that the reality is that that people are going to write have to write tests that interact t-store and M Copy just to be sure but there's no overlap and so there's more tests have to be written I feel the Imp copy is so simple though this is not a major concern I think it's simpler than chain ID it's crazily simple yeah I think we mention it again on awkward devs in the week next week yeah um when we'd mentioned our products next

week I'm happy to say the same thing I I think that we should try and do them copy and there's very little overlap between that and the other changes sorry I must have missed this argument so what was the reason against M copying or yeah well I think it was Marius I think maybe tell me if I'm wrong I think it was I think Marius said that he didn't like that there might be some interplay between t-store and M Copy or like the tests that need to be written they're going to have to test both and storing them copy and maybe test them interacting with each other

but I just don't see that there is being that much overlap between the two like they're pretty orthogonal mechanisms I mean I guess one concern might be that it doesn't have enough time to get a good fuzz burn-in on it after everyone locks it in um but how much do we need to get fuzz burn in is like you know a day or two or a week I mean I'm not sure what the metrics on how much fuzzing we need on this yeah I mean I think we're still I mean we're looking at 4K in October probably September October still have a lot of time to be fuzzing testing it or may not uh for test time okay all right so a test net would be uh end of August maybe

September I I think it's relatively low risk but if I'm wrong please educate me I'm open being corrected of my incorrect views on this you're from from I say I think it's it looks simple enough I'm copying um but yeah I I would like to talk to Marius Maybe he has another opinion Maybe something that we're not seeing yeah I don't know yeah sounds good

um if you get a chance to ask him in the next week or so and there's something to post on the evm channel because I do think we'll talk about him copy again on all core devs and it would be good to think about yeah what the other perspective is great any final comments okay then thanks a lot everybody talk to

you again in a couple weeks and see many of you on all four depth next week have a good one