EOF Implementers Call #35

Transcript

all right so this is the 21st February eof implementers progress call um guess the standard agenda is we get client updates and then we talk about spec updates and then we open the floor to other issues um if you have open issues that are not spec updates or client updates please put them in chat and then we'll come to them in order um so first on client updates um Basu is in the process of rewriting its stack validator um to comply with the new um stack validator changes with the variable stack height um that was the stuff put in to make solidity more efficient in handling its reverts and some of its returns um so that is um

basis progress there that and we're running through a lot of the um running a lot of the tests that were mentioned last week um reference test those are great tests those are I'm able to shift my mindset from spec implementation to test driven development and looking at what the tests are telling me is wrong which um I think is a more productive development cycle than trying to decipher the spec and figure out all the places in the code it goes so um thank you for all the tests those are awesome um yeah that's it for Basu um next up I see uh next person my line would be ev1 uh we have merged relx stack

validation [Music] and uh um so create three and create four and X code Logic for legacy is mostly waiting for tests update to be merged and we're still working on new calls I think that's it okay um we don't have one from nethermind or gu or re or um Aragon um Charles anything from Viper you posted a bit no updates from Viper Z

is that correct yep okay um and no one from solidity any other spec updates I think I covered everyone I see on the call um Jesse RC um are you presenting an implementor team I'm not I'm just here just here okay cool want to make sure everyone that's here gets uh representative to have things to say so um that's it for client updates kind of a slow week um next week is eth Denver um so I will probably miss this call I'll probably be on bus somewhere

um because I live in Denver of course I'm going to go to the conference not don't have to travel um so I don't know if we have any updates next week and next week is another allore devs call I don't know what the agenda is yet I'll have to look it up um spec updates are there any spec updates EIP 663 is ready 663 that has push in um not push in uh swap in dup in as well as exchange at the moment right Charles yeah that's correct I think there's like a couple off by ones and then um there's some wording changes okay good so I guess we just need to get Asic or one of the yeah Asic doesn't want to review his own PR so he's

waiting for another EIP Editor to admit it through and yeah Peter you came off mute I was wondering if you have something to add no no actually okay cool any other spec updates any other changes any other issues people found out while testing okay think there's not so much has changed it just think the AP process a bit slow we cannot hear you very very very very quiet okay you turn up your mic or

something bit robotic but maybe it's too too much volume now okay how about now better we can understand you go ahead yeah I just wanted to say that but uh I think this not nothing really has changed so much in the spec but uh the documents in the EAP are being slowly updated um so the process is rather slow

because cross dependencies and we need for somebody to to make a decision about some stuff and so on um what are those open issues we need to have decisions made are they things we implementors can do or is that EIP editor issues I think the off by1 in 663 that came up need to be looked at and uh we also got uh the create e merged but it's in draft and now 3540 depends on it and it cannot and the updates cannot be merged because uh create AP is in draft so you

might want to get some initial feedback on the EAP for creates and then push it to review I guess and that would unblock the other stuff so it's a mix of of of so allp stuff all all process problems yeah except for the off by one that Andre brought up but I need to look at this because this is like a recording I'm okay yeah that's okay it's understandable thank you very much for

this cool um so I guess if that is um status and um spec updates I guess it's uh any other issues that anyone's having or experiencing with their um eof any other questions or well if there's um no questions and we're just waiting for implementations and specs I guess we could shorten the call I don't know no need to make people stay Paul yeah only this this this one we discussed I think

today I mean I didn't participate it's about this create three instruction name is this something we should pay attention already or it's something for later um we can discuss it now um you want to give background on what the issue is I think P will be better to explain it sorry I missed the tiny bit U can you repeat the issue which we want discuss what is what is the issue of the create three naming or the call naming so first we like we found we found the naming suboptimal and temporary a while ago but this topic kind of died out and now

someone brought up the issue that create fre has at one point been considered as uh I I didn't look at the details very closely it's like a a different operation altogether um it was there was an AIP proposal but it didn't get merged I think and there are some stock overflow spreads about that and they refer to create free to something completely different than what we uh describe and someone wrot it up on our eug thread so so yeah um I guess the question is whether or

not we want to rename create three and create four um also calls uh 2.0 could could be renamed okay so I found the uh issue with um let me see if I can share this the create three um in EIP let me get my window to not be so obnoxiously large before I share it got Zoom share screen all right yeah so I think this was what you're referencing there is a

proposal 21 to do create three it's like create two except it's got some variation on the um address KN address name um yeah and there's also I think a community library called create three right right so it's kind of an overloaded name um go ahead you know cre3 was was was a temporary name I guess because as it sets or it continues a bad precedent of just you know doing sequels MH one two three four and and you know push two and push three do not are not sequels of of

push so it's kind of it's kind of bad and there's also an sore 2 Community which is doing contract based storage so that's you know another example of using the SQL names um for non-op code items so what were some of the alternative names that you they were proposed um uh I think it would be ideal if I could share screen with some hackmd quickly um but a just posted another alternative I just want to put it in and I'll make a go ahead and share I think everyone's got the share rights yeah

um hold on a second I just I just need one minute just I just done because we had a thread on Discord almost there

almost how do I share your screen with this thing here should be a green button a green button I always miss it because it's green it's kind of just seeing black right now okay interesting should be sharingd it's all black

for me just says lock okay so I cannot ah my screen share is loading that's what it's telling me I'm not sure what that means hold on you see the

Whiteboard yep I see the Whiteboard now this no way maybe it will work it's not working sorry

um is the URL public I could try sharing it um it's probably not because I I for some reason cannot cannot uh I'll just paste it maybe someone from ifon can uh can set the visibility to sensible can you open it I posted it in the in the chat yeah I can't open it up not ethereum.org yeah exactly um Andre can you can you modify it or probably can't modify but I can

share the screen I guess okay try maybe maybe Al will work so I think you need to close the Whiteboard yeah I'm I'm trying to look okay yeah I think I closed it okay thanks this is there we go 10 minutes thanks thanks and okay so I guess these are the options for create three and create four it looks like yeah the first five are for create fre four and the next one are for call these were which I have seen being tossed

around and I collected them over over some time and and so I don't know any I'll take give you a moment to moment to look from them look through them and then let me know what you think I know my favorites but I'm not tied to them so I remember you liked the EXT create was was that the one yeah external create and Factory create um so that way external create could be triggered off of more than just what's

in the transaction a layer or two for example could have a set of predefined contracts that you can build from and maybe those the only ones you can build from so thinking from Layer Two extensibility is what I think external create um object instead of create is an interesting twist I hadn't thought of before could be also yeah go ahead I modified the file but you can see it for some reason because so X create would be accompanied by Factory create correct

that would be yeah I think that's better than the other three options other two options actually mhm so I think in the op code it communicates what the intent is it's intended for factory contracts yeah I think we have to stick to the create name so I would eliminate the the last two names yeah I think this it's a benefit of of being familiar yeah yeah fundamentally different it's just yeah I I think it

doesn't have to be very beautiful but I think with we need to stick with with the create somewhere in in the name yeah yeah I agree Factory create is a bit long and it also can can imply that a factory is created which is not the case but I think it's it's good enough and yeah I'm fine with either TX create or ex EXT create what about int create in internal create instead of factory create right that sounds like in integer yeah does

sound integer in okay so I guess the the first two are the short list okay right and then call two in in that series I guess is the next question yeah if we can if we can handle both when we

are um add it for this I I have I have slight uh preference against the second one which is the very abbreviated one um because it just to too abbreviate and it also doesn't have the familiarity of delegate call and static call spelled out and and the last one kind of looks ecstatic Co just it just sounds like some I don't know Pagan ritual thing oh yeah etic I would I would

ecstatic I I would for the third one I guess yeah I like the third one most to the blue blue square yeah third one's relatively inoffensive there were some there some feedback that alcol means something some in some convention somewhere some light recollection someone pav was that you no definitely not me no okay

sorry okay I guess we have some candidates and we can and we are slightly in favor of the EXT create rather than TX create because it's more generic I'm in favor of lower names so sorry shorter so this l call LD call LS call okay it's um I'm fine with that too two or three are my favorite in that list I think one's too long yeah it's too long it's it's very very long

and V2 is just a less obnoxious version of call2 which is also quite it's about similar I think it's either l call or oh sorry L LD or L delegate call okay any more any more voice or any more pros and cons of the TX create txt create to to voice now um yeah kind of also like this single letter

prefixes including D and S think it's right relatively easy to read and more or less the same length comp and have an LSD call um maybe TX create and VM create because create or factory create can only or what is this we don't even know what we're talking about but Factory create rename to VM create because you can only do it from inside the evm yeah this is also

interesting yeah my concern is it's do implying we're creating the VM itself not necessarily where it can only get with from within how about create three and TX create grade three is the contentious one and we'll just claim victory that's an option ignoring the Collision is always an option no maybe not the best one you could also call it um container uh uh yeah container create yeah but it's also I mean it's always the same case that it's implying that you're creating containers and with

Factory is kind of the word factor is slightly less more like this this just my very subjective sense just because Factory is you know Factory I just I'll just make the note of the VM one EF create is not actually a bad idea because it's clear that we only created from within EOS and it's coming from the object format uh I mean eof create yeah like

e create next internal create I like TX create okay e create and TX create I'm fine with that yeah because it says where you're creating them from when is doing it from an e of container object and the other is from transaction data Maybe TX data create but that's maybe Overkill uh so what was the I'm making notes here but for some reason they do

not show up in Andre's screen he's sharing um oh there you go and what was the other one e create and TX create I mean there's I mean we can have e and TX I think are very direct in saying where they're from even though it doesn't preserve space for future development um that's a hypothetical and I see the advantage of keeping it just as um what it is so there's a strong argument for that I think I think that's the best one that resonates the most this one and and and this one these

two yeah cool drop that into uh the Discord chat let that marinate for a week and then lock it in yeah we can also make a PR right away but yeah make a PR we see we see it as it it presents itself can disp and yep yeah let's lock it in and wait for cries of objection and if there are no cries of objection then we lock it in in a week I'm cool with that okay cool right thank you okay anything else people want to discuss

um if there is none um I guess we could end the meeting early and give everyone 28 minutes back thanks for attending thank you very much by