EOF Implementers Call #34

Transcript

all right um looks like Alex is out right now um we got some people here so I think it's good enough to start the meeting um I guess our standard first item of discussion is client updates um Dragon you're the first client member that's not me so how about you uh lead lead with your update I just last week I just started looking at how to implement his side RM and it will not be that bad so yeah I'm still at the beginning figure out how to basically integrate all that all of this inside DVM okay um any evm one

updates um we still have several PRS open with different pieces uh mostly finished we're mostly working on tests now so grade three and grade four already I think yeah grade three needs some minor fixes it seems so but also so grade four is ready and uh relax stack validation and I think X code uh logic in Legacy is ready and we're also working on new calls at the moment um yeah that's it okay um for Basu um we got cre three working there is one one bug that I think I found in

in evm 1 I think they're going to fix um but apart from that one difference uh there create three tests and bases create three tests agree so we got progress there um I push that out to our Mega eof I spent some time trying to get um retest death um I wasted all day Thursday trying to get it to work on Apple silicon and then on a failed similarly on a more recent um Intel Mac but I have a decade Old Mac Pro sitting on my desk and weet test compiles fine there I just discovered yesterday so I'll be able to um help get some of the reference tests written for for the client there um what we don't have implemented yet is create for and exchange um I don't know that the

exchange specification has settled completely yet um but probably it's time to start implementing it anyway um uh we don't have solidity on the call so Charles any updates from Viper no updates on M I updated the EIP 663 spec a little bit um and I'm not sure if there's anything outstanding on my end um and I don't know if there's any progress or more thoughts on VQ um I don't know that any clients have got any progress on VQ we've all been heads down on reference tests and

initial implementation um as far as 663 you updated exchange do you consider that in a state that we can just go ahead and implement it yeah I would say so okay yep I think it's it's it's ready it just need to be the pr that Charles open needs to be marched right needed alha Charles PR okay right to that spec cool should also be in sync with the meas spe right um cool so I guess we'll go into spec updates are there um I wasn't expecting to have to lead

the call today I was thinking that Asic might have been here um what's the status of moving the meas spec over to eips I guess is the first question while I looked that up okay second I can handle this uh so there's we have a bunch of PRS open with updates we have an update to the first um e which is 3540 uh which I think there's one pending discussion item which why I would like to handle uh when we are in the spec discussion part and the others are kind of bit waiting on a com on different uh stuff like for example they create free and

four EIP is waiting I think at this point for the editors to approve it there are some bunch of small updates that are trying to get the trying to get the status out of Stant and I think they're also waiting on the the editors and then what else I think yeah I think that's it so so we're kind of we blocked a bit but but there's there's a lot of uh a lot of new updates ready lined up to be merged so we're waiting on action from the EIP editors I mean someone someone confirmed this because I'm not sure how the process goes on on

these um yeah I their process is yeah I have no comment on that can you can you please help me with the um e number or the pr number one again I may be able to pull it up in the next e EIP editing office I didn't quite catch that I mean there's a list of PRS in in the chat the last one actually I think is is axic who's the author yeah that's the one but I think the other one so ones the as as authored there's one the swapan

one but the other I think are brows yeah grade 3 I think we've got some review from editors and addressed the comments and now yeah waiting for another round and I opened like three small ones to change the status so like 3540 is currently in stagnate and I uh yeah Cher picked a couple of small updates from a biger here bigger update and moved it to review back to review this is still not reviewed by editors and also data instructions and jump F also I tried to move them to review but they are now

like also require editor's approval so it's like I will try to pull yeah I will try to pull all of them in the next dip editing of this ser and hopefully itk okay so that sounds like one action item is we need to get a master list of what we need editors to act on and that's next Wednesday or is that today in a few hours hours uh it's Tuesday next Tuesday next Tuesday okay so we'll need to get uh a master list of things that we need editors to act on for them by Tuesday okay I can I can make this

list and what do what do I send it to um if you can yes there is the meeting agenda I I will just post the link over here you can just add it over there okay so that meetings today EIP meeting or wait office hours except from EIP right no in EIP we only talk about the proposals which are into final status but this uh office hour is for the proposal which are in process of getting to fund okay so we could just dump our wish

list into that PR that's perfect yes okay um do you think it makes sense to reflect the the EIP process in this Readiness Matrix what they mean is that I think like P and and and Andre has put a lot of stuff already that is being updated and like to my understanding like many of these are kind of ready for review except it's not Mer but I think uh the other people might be interested like in in reviewing them in in meantime anyway uh but I think it's it's a bit difficult

to track what's going on where um so in the in the implementation Matrix we do have a rle for IPs yeah yeah sure but it's it's only like single like Unicode character right so like if there's a prequest that kind of updated but it's not merged yet it's it's there's no link so I can't see it yeah there's a list of PRS links below but it's I should update it and I will when I do that I think list list would be enough I guess I don't think we it's really picky about like where it goes well but yeah having a current current in progress list of requests would be nice

to um so we have like other people have orientation like where they where these are I'll I'll update the list it's it's a week old it's not terribly old but it's old okay so were there any of these eips that had requests for discussion um I think I we had the vlq request from Charles anything from evm one that needs discussion in terms of spec right did I he right in general anything we need to talk about on this call yeah I would I there's this notion of

um making the header format more liberal because uh in the previous EAP 3540 we had this um that the headers header of the sections was the section kind and then either a single two bytes length or a list which is the number of items and then a bunch of sizes of sections and now we had I think we had a discussion before about this but the the question is whether we want to make it more libero because this is this is the format that applies to all the eof versions starting from version one and then Moving on but uh if if if in the

future we would like to have another header format we would we would need to violate this this this General format liberal in sense that it's not I I mean it's not necessarily just just a list of sizes could be a list of offsets possibly or something else completely yeah to clarify this is is just like a nonfunctional change this is just how we formulated in ap35 40 does doesn't affect the exact container format for now this is like we Des there's a paragraph that describes the how general e format for any possible

future version looks like in general terms and is there's one possible formulation or another one and basically that's what we need to decide I don't think it's like very important decision to be honest okay I mean that's fair enough we can we can just keep the the previous strict format and and not worry about this this is fine just I'm in favor I'm in favor of keeping what we had in AP before I think it's fine but yeah I'm open to changing it too I'm fine with keeping ass this I thought we had this that we decided to to make it um more General but but it's fine I can we can we can roll

back so what changes would be involved in making it more General with the current specification of the header format be compatible with this liberalized format uh second what would be compatible with what so if we made it more liberal like you're proposing and doing some of those things would the current header format be have to change to accommodate these changes no no no no no absolutely not okay so we could do a forward compatible change and we could open it up a bit um after we ship V10 and say Here's how you would extend it but with the current specified version is set yeah so to my understanding is that

we just like rename some like specific like use different terms in the specification in the way that for example the the size the number doesn't mean size it's like any number in the array of numbers and then it can be interpreted differently in the future something think that's comes to my mind uh but I also don't think it's super important I mean if you can do it I I don't see why you can't specify it later right can fine go ahead no go ahead so guess what I'm saying is the the bites that go over the wire can be

the same if we change the speck or if we don't right they'll be the same right yeah okay I think we're more in favor of not worrying and and just uh rolling back and making it as it used to be sotis fine yeah so I guess the subtext is if if we're going to launch a test net like we got the request from EF devops in March now is the wrong time to fundamentally change things like the header format because I would have to rewrite all my tests again for about the fifth time that tests all the header format code is the the V1 header format would not change for for sure okay I have one question regarding the

header uh did you guys thought about adding the size of the header uh what I'm asking is basically when the verle comes we will have maybe different format the where we want to know how much the data we need to read basically how much chunks of work data we want to read so maybe it can be like usable or useful both for the header data and like terminal for the terminal like body size we can get that from the header but from the header maybe it's to be

usable so there is no header is this long code is this long bytes in there um it can be derived from two chunks which might be the same chunk for a low count of code sections the first chunk will get you into the 02 header which includes the length of um the um the code sections the O3 um and from that you can extrapolate to figure out where the subcontainers left their subcontainers that kind of wrecks it because then you have to check you youd start with the first chunk you bounce to where code section three might start and then new bounce to work code section four might start and so there from from up to three bounces you could get the um the full header from from

just three sections and then you can load the code willy-nilly um you know as you need it and you know where the data starts so while there is nothing in the header that would be nice um it's at most um three chunks to get all that necessary information and if you're calling a fairly large contract the three chunks is going to be you know typical just for method dispatch there's going to be like five or six chunks to your typical method dispatch okay either way even with the current format it's easy to extract the the data yeah it can be calculated with minimal hassle then why if the all values all values are

hardcoded basically we know the order how the kind code kind container kind data comes why do we have kinds kind type if it is all hardcoded so that would be um for future extensibility um for one thing the subc container kind is optional right now so we do need to know when we're going after Code section lengths to um go into either subc container or data link so we need to know that and for future extensibility we're saving the space by requiring the kinds so that we could

extra Fe add extra fields in there you know the ordering will be specified but if we have let's say we have another section that has a solidity dispatch table um we could add that to the header um or if other rollups want to add that sort of information um marking them with the header kind allows for that kind of extensibility yeah but you get the same thing with versions with what versions with version yeah version one you bump the version you have different format or maybe extend the format or format with remot field but versions don't like have optionals um in infinite combinations

because containers might be optional um this mythical dispatch table might be optional so we could go to version two but we still the field might be option in version too and we're also trying not yeah we're trying not to bump the version field if necessary my goal with the version field is it only signals Inc compatible changes um in compatible changes like say we're adding a new OP code or are we doing something to the code that previously would have not passed validation with now pass validation that's my definition of a forward compatible change is there's some code that would have been rejected that is no longer rejected um then those I would say would not require a version bump um it's when we do things like take codes away stuff that was valid and make

it invalid where we would have to increase the version number so that's if you know I don't know what the rest of everyone else working on the project is thinking but that's my vision for what the version number represents is we've done something incompatible sounds good to me to be honest thank you yeah like this kind of allows to to have some like future um compatible changes without changing the version which is like adding optional section in in the future is one of the the options that we we have it's not that yeah it's like we increase it by few bites that's nothing and we get yeah understand thank you for

explanation yeah yeah I mean oh that that has been discussed and like some some people proposed like to truly fit it in what we currently need and don't really like make it anyway generic and I don't know how to put it but yeah definitely we could just put every value we need in just in just order and like knowing where where things are um it's kind of like design tradeoff I I I I don't think it's super important and I I don't have like very strong preference which one is better probably will never know until like five years into the future but yeah that's

mostly what the design was for okay I need to drop off I have another meeting I need to call into in about two minutes so um I'll guess I'll need we'll need assign someone else to be co-host to maintain the reporting recording will be continued I'm online so it will go ahead all right cool so yeah I don't know if there's any other requirements we need to go through if you want to move on to Charles's VQ requests um but like I said I'll be dropping off here in about a minute Builder did you have some other

questions about uh calls I think I think they were a bit specific to ev1 and the pr that we have open so not not for this call I think and I think I need to go after ISAC for this okay do we have any further update or any

further discussion Point uh if so people can continue and it will continue recording Charles do you have anything discuss um I mean I don't really have any new information but um oh yeah I think I was out last week but uh the VQ thing I just want to make the case for it again which is um I think it makes the format more forward compatible and it also results in some code savings I think the only question really is I mean there's a couple of details um but we can address those if want to move

forward with that I think the only question is the the the scope which is Dano indicated to me that you know it changes a lot of tests which is really annoying um so that could be a blocker for it if if um time is of the essence here yeah I think we agreed to proceed without this change for now and we added some rational I think to 30 3540 just saying that it's uh we decided that it's out of scope uh but yeah open to getting back to it later at some point now we're

working on tests with the format agreed on uh speaking of tests actually I have an update about tests um we worked on New validation tests we managed to export the cases that we have in unit test in vm1 and now there's uh um a lot of test vectors I've made a PR in test link um so these are tests in a special

new format which it exist before but uh not I don't not sure if any clients so far used it uh not sure if B who looked at it uh um um so in general yeah it's just uh yeah let me share the screen maybe yeah this can be useful thanks for sharing yeah this is just the format that has the bite code and expect it whether it's valid or not and uh inv valid cases have exact error message expected I'm not sure how much this is

useful because I expect so the different implementations will not agree on specific error in some cases uh so I would start maybe just trying to agree on the outcome and then see how many errors are different um uh because yeah at least in parsing I'm sure like parsing can be implemented in different ways and then like you interpret similar situation like the same situation in different uh like different meaning uh then error is different I expect such cases to come up but we can try so this is like what evm one

generates and um yeah there are bunch of these tests um it covers I don't think it covers every possible error and every possible uh validation case but um at least stack validation I think is pretty well covered except I am still to add cases for r r jump V there but yeah so yeah I encourage to try this um otherwise we have uh from the old PR so also I'm not sure exactly what's the status Hugo is not present today but there's

also this PR which uh updates Master Tes Master to the new creation uh spec but it mostly deletes I think some cases some tests because they are not possible with a new um uh new back but still this is kind of the most upto-date version of test on Master this should be merged soon I hope um and separately third test spr is uh the one for creation which we also generated

from uh from uh edm1 unit tests and this are like a separate thing and this should cover these a normal state test and they should cover grade three at least three grade three and grade four actually so yeah this is also possible to try when you get to create gr three you can create four yeah that's all I have about the tests um going back to this uh varing Lenin coding a bit uh so so maybe have

have an option to make slightly progress here uh so I think I like I still mentally try to split these two things like EF container and the the instructions I'm I'm kind of skeptical about the instructions actually because uh like the coding the number at run time like it's it's a bit more complicated than just running to bites and just swapping whatever um and and and secondly this there's not really good fit it seems It's not really good fit for this uh this jump table

um but anyway um uh what I what I did try to do it but I'm not sure I will be able to do it myself entirely is is um this this a actually quick way to to uh to inter in inter uh inspect all of the deployed code in on my net for example so we have at least if you have a running mode we use that to to find the the eof prefix previously um and this runs really quickly I think to to just check all the code I believe shouldn't take more than

minutes so um I have written a script that that can just collect some statistics about uh the jump offset that are currently used in existing contracts so maybe we'll start collecting some data collect ideas what actually data we want to have and how to like store it for later processing I think I think I would just make a like an issue in our repo about it with what I currently have which is like a prototype for now um I don't have a running Noe actually that I can use it

for uh but maybe actually I thought I can I could get it running maybe in in day or two uh unless someone else have it um and uh what else yeah there's there's only one kind of missing missing information that I'm not sure how to get and if it's easily available is you can you can scout existing codes but you don't have information how frequently the codes are used so like the the statistics a bit like not really represent uh the usage on the network uh if you know what I mean um

but maybe it will be good enough at the starting point yeah that's all from my side for now do be drop

up or is there anything else I'm good I think we can wrap up then thank you all yeah bye guys and next thanks everybody thank you byebye