EOF Implementers Call #19

Transcript

hey everyone welcome to the eof implementers call number 19. uh let's just go ahead and get started with some client updates does anybody have anything that they want to share we're looking sure you didn't want to updates or we've implemented non-returning functions on their implications on jumpers this is implemented and on the review now and another thing we've implemented EDM Max Primitives this is not the instructions themselves yet but the

underlying library that does the all these module operations that even Max instructions will do in the end and this is only YouTube oh nice Etc yeah and yeah there are some in progress implementations for rate for foil and blob hash and of Trends in storage those are still in progress sweet I'm in uh from nether by the way can you hear me guys okay I guess loud and clear

perfect from another mind's side we are doing major refactors to our PRS mainly eofbrs and we kind of were focused a lot on our Cancun implementations since I'm kind of taking care of both at least partially the eyepiece so yeah that's our update cool I guess that's probably all of our client updates without Dana so let's jump to compiler updates it's in there

I think I was um there's not too many updates on my end I was talking with uh powerful but we haven't gotten anything inclusive um but we should still be considering call if I and jump fi got it uh anything to discuss in terms of spec updates spec questions then testing I would be interested in testing

you would be interested in doing testing or updates for testing okay but we would need some kind of specification and kind of list of specs that we would want to start I mean isn't this spec kind of just a mega eof spec is that it's like late final spec for all the elf proposals still order of finalized somewhat Oh I thought it was frozen I don't know Andre or if anyone else knows for me please

it's in the yeah this one the mega eof it's pretty much all or nothing right there's no possibilities to have something part of it than in part something not part of it well we like the plan is to roll out everything all together but in principle like slowpan and dump and instructions are kind of separate and so yeah we want to have all of it all together I think testimony wise it doesn't make sense to us separately yeah

I don't know if clients if you have any ideas of you know when if do you want to be ready soon to do testnets like this are you already ready foreign I don't know if Hugo is still working on a PR on guess but I have not I haven't worked on EOS in a while on Guess is there a UF champion not really unless Hugo is still

championing it because if there's no Champion I don't think it's gonna happen before World Cup yeah I mean we need to figure out what the priorities are for the next Fork on all four doves yep yeah so I don't know it seems like you're still a little early for test Nets that was the whole agenda any other

questions comments yeah demo had like a speculated questions to discuss but we would need to use it I guess you know she posted on this course earlier let me attack him we were just on the EIP IP meeting

debating splitting the eaps and erc's out and yeah I said I had to leave to come to this meeting and he was still debating so he might be locked into a battle of the ages so we've gone through the whole agenda

in 10 minutes early five minutes but I think you had a few questions Mike uh what about those stuff that Viper was talking about the new OP codes conditional upcodes I'm not sure do you know Charles I mean I can go over that basically because of the stack validation rules we

can't use our Jump by in places where we used to use Jump by and so we have to introduce uh kind of branches branching guards around every single um so every so a lot of things that look like um you know push to jump high in current evm turn into like is zero our jump I call F hello something something can anyone hear me

yes okay so I'm on my phone so um where are we at basis status yeah if you want to just share what basic note to and then we've kind of already went through the whole agenda nobody had a whole lot of things to talk about but I think that you had a couple questions also some spec related things yeah so so you can just give the whole floor to you face it hasn't been um doing too much on eof right now because we've been busy working on Cancun um uh self-destruct and other other items distracting me there but I did have three questions um one about uh the EXT data load we had

discussed that on the last meeting um was there is that something we can add to the spec or is that something we need to tell the uh the groups that they need to learn to work without yeah I don't think we had any progress on this decision to me personally it seems like it might be useful but it doesn't necessarily have to be in the initial rollout of the OS so we could live without it for sure so we could live

without it but I'm concerned if we don't have it that we're going to get a lot of pushback from the communities we're trying to serve um the the data in smart contract communities is you know it's very important for them to be able to in their contracts get data for external contracts while we can do these methods where you call in um they become you know more expensive and more difficult to use a more friction based so my concern with leaving it to the second version of eof is that's going to prevent uptake of eof I mean it's a pretty big change as it is so it's you know I I think we should strongly consider putting it in now rather than the second um because it's not too much of a spec bump above what we already have so um we don't have people on this call

to to to um to resolve it but I think that we really need to strongly consider getting in the first pass rather than putting off to the second pass or giving Clarity that it's not going to come in at all on the first pass so deferring the decision I think is is something that I don't necessarily think will be good for for adoption but um since we got key people out and it's kind of a um you know the week after ECC I don't expect we'll have any um resolution on that uh my second question was about jump fi call Fi um was there discussion on that I think I was in the middle of uh

explaining about that to Andre when when you jumped on uh should I continue yes please yeah so like I was saying the um where was I yeah so because of the stock quality the the new stack validation rules um unless we're able to relax the stack validation rules we can't use our Jump by in place where we used to use Jump by we must use the sequence which is like zero something something our jumped by call F and that's such a common sequence that um eof code actually ends up being

larger than current evm code probably not more expensive but it's more expensive than if we could um use our Jump by so that's the overview um I don't know if you have some questions about that yeah you say that it's related to stack validation it's because of how stock validation works I'm not sure what's the relation there and yeah hopefully losing enough the condition rules will help the same problem somehow uh sure it speak it has to do with code sharing so we're trying to our Jump by

to a shared code section and um uh because that code section doesn't expect doesn't have it I mean typically there's like a shared revert sequence and it doesn't have any restrictions on where it can be called from so there's no we have no you know kind of invariance on how this section is is jumped to um facilities the same problem I don't really know I don't know if they take the same optimization but anyways

right right so you have to use call F to this shared code section instead of our Jump by and I think this is a general issue actually with stack validation which is that it inhibits code sharing um but I mean we've talked about it on several calls so far and you know call if I you know would solve this particular problem did that answer the question some dog

oops uh that answers my question I just looking at now that I'm on my computer and can see who's on the the participants yeah I do don't think we have the people to get by and put it into the spec I did I I like the the rationale I think it's it's compelling but we don't have enough people to for consensus to come to conclusion any of my questions uh yeah and I I've been talking with Pavel about um how we could relax the stock validation rules um so you know um probably have to wait for people to come back but uh that's that's kind of another possibility instead of adding new OP codes

okay I was also thinking about the issue of op code space and um since uh eip's in eip663 you know we've got new you know larger dupe and off code and potentially some new swap out codes so we could maybe start shaving off some of the deeper ones like Duke nine and up I think are super useful so yeah I viewed dupe and swap as as rich places to shape up shave off some

of the higher ones um I don't think we're at opcoat exhaustion yet I think those are my preference would be that we we go down that path when we're at op code is action exhaustion and I don't think we'll be there in the ofv1 by the way Eamon did that answer your question I don't know if you caught that he says which rules exactly are causing this problem

I'm gonna take that as uh resolve them in this um somebody voices no worries um yeah any other questions or updates wanted to go over kind of a meta question we're targeting Prague with this right is our current next update my my question is what sort of pace and deadlines and goals should we be setting to um

to get to to be in a position where we can be the headliner for Prague before that happens I mean right now it's not really gonna certainly we can't do too much until um Cancun is is at least sitting test Nets and some of that design effort slows down because I think that's what's slowing down some of the teams is it's it's all hands on deck to get devnet 8 ready up and running for uh Cancun but beyond that when do we think we need to have a lockdown spec ready do we think we're talking with enough community members we've got the um we got the data contract people who are interested in talking here we have viper

and solidity I guess the second question is are there other groups we should be approaching again and the third group The third question I think is at some point or the first thing um to get to the final spec what are the remaining issues the remaining areas we need to work on and I don't think we can answer that until we feel like we have all of the feedback from the downstream users of this and I think that's that's where the Shanghai version of this needed to be pulled off the shelf because we ran into problems with that solidity needed out of the process so I guess those are three minute questions I don't expect to be answered now but those are questions I think we should think about for the next meeting yeah those are good questions just to

determine on maybe the first question I think you know if we're targeting Prague and we're targeting Cancun for some time in October maybe early November ship then you know add six eight months to that we're looking at sometime around probably May next year for crawler card Fork so I don't know I mean it's hard because I think that we're getting close to start debating what should go into Prague or what we should be thinking about putting into Prague and it would be it would behoove us a lot to have a pretty solid spec which I think we kind of do at this point it's more just that we need to make sure that

we're you know keeping up with these debates and you know not letting other things level to the surface that might be like less ready [Music] um but yeah I don't know if we start talking about this like I could imagine that this happens the next couple of awkward devs where it gets raised and we definitely want to have something it doesn't have to be like absolutely final but we definitely want to have something that we could be sharing probably this like Mega spec is going to be good and then probably like yeah january-ish um really need to be like pretty much Frozen the point okay that's that's kind of in line with

what I was thinking um whenever they actually start seriously discussing Prague be able to bring forth a basically complete but still room for fixes specification and then lock it down in January that kind of aligns with what my thought is okay um just to speak up I think from the Viper team side there's still um enough open questions that I don't think that the spec should be locked down yet um also on the global code section versus code sections um like yeah basically that creates

semantics and the stack validation or our Jump by issue um I think are questions that need to be resolved before the spec is finalized yeah I don't think the stack is encasedly finalized but I think it is Advanced enough that we should identify the areas that will be worked on and I think those ones that you enumerated are ones we were working on and we need to keep a list of things we're actively working on at some point that it's basically the agenda items right now all right thanks sounds like we're on the same page I guess we can contemplate the other

questions about what do we need to do to get there to discuss for next time unless there's any last comments I guess we can go ahead and close this one off early today thanks a lot for coming feel free to discuss other things in the VM channel on Discord cheers thank you thanks