EIPIP Meeting 10

Transcript

alright hello everyone and welcome to eip ip meeting number 10. um let's get started uh the first agenda item is an eip number registry process and i'll go ahead and post the agenda in the zoom chat um i know we've talked about this a little bit uh james is on vacation and some of these items are his so we'll be going through them pretty quickly i think this is one of his items but i know some people in here also had some comments on that so um there is let's see uh the last i heard about it was

there was a possib there was like an idea to have editors keep up with a list of eip numbers and then assign the eip numbers um i know there was a couple of other ideas who else had an idea or remembers any of the arguments from the telegram um i what i remember is that um there was bloat with the eap numbers that um the erp numbers were tied to the issues so we wanted a way to possibly reduce that um and then greg had a point where well yes there's blow but

it was kind of decided early on i think it's in the agenda it's comment getter um and that it let me try to open it i shared the link in the uh chat for they get a comment received from greg colvin oh the the upside is that erp's automatically are numbered unique and sequentially and editors don't have to be involved it's easy to begin any ap issue as it's numbered before needing to make appear if if there's bad actors they can be banned

if necessary um i think like um the current process is fine as in it has a low bar is it low barriers to entry if we were to have people go through any the eip editors it might increase their workload and uh currently um i don't think we have too many ap editors so they might be overwhelmed but just accepting numbers if you were to do it that way um and if we were to like have them do a pr to an existing eap it might also add add another barrier of entry that doesn't currently exist that makes a lot of sense um

i would say that this is probably a like not as big of an issue to tackle it is something we do want to look at but i feel like we're maybe trying to fix a problem that's not a major problem right now because we are using github and if we were to ever move away from github for the eip process then we would need to come up with a numbering thing but until then there's not really a pressing need for it i don't think and so it's almost like we'd be putting more overhead on editors if we were to do this to do at literally any numbering system and um as far as the bloat argument i'm not sure

there's that much bloat like people can spam eip's repo to make the number go up a long time but it's unlimited numbers so yeah any comments on that from anybody personally i agree with the idea of continuing with the eip github issue number because i mean as we mentioned that it is going to be unlimited and if we are seeing it for even a very long very long time there's no no change in the previous and the present system when we are continuing by number and we have the pr number it's very very convenient

to refer in the different calls even before it is actually being merged so suppose we have different pr number plus the plus another number for eip it may kind of create some kind of confusion after a while because we start discussing uh long before it is actually being more yeah good point yeah the other idea with mine is basically to introduce to commission the development of the front end to uh to the eap repo and basically to have every

every potential eib author submit their eaps through this front end but it would definitely add an additional layer of complexity although it would probably solve the numbering problem but again there is not really much of an issue when it comes to numbering right now so i don't know if it's really relevant at this point got it i think if there's a way to automate it i think we could solve it but uh right now if we're having to do it manually through a pr through an eap uh maybe if

we could get the vip bot to do it and that would be better but currently i think it might cause more more complexity more um inconvenience yeah that's just my perspective right now okay it's like we are solving one minor problem and creating a few other major ones that's kind of the consensus i'm hearing from the group today um so yeah we can does anyone else have comments on this otherwise we can move on from it because it sounds like as far as today goes there's not a lot of um strong opinions to continue to work

toward a solution to this today i wouldn't agree with that cool um all right next item uh separation of the eip process from the hard fork coordination process we worked on this a lot last time um i was i was editing the agenda earlier and i forgot to move this one because since james isn't here and we solved a lot of this last time um we'll go over this next meeting just to refresh everyone's memory on the new chart uh that we have um or not new chart but the edited flow i guess the flow chart and some other notes that james put down um and i think that's in the

eips to do link on item six i think it's a hackmd that has yeah the hackmd uh item on um on number six is owned by axic but i think james hancock also works on it um so that should have the latest stuff if you're interested in looking at it but since we don't have axac and james here i think we should wait till they get on the next meeting james is just on vacation he'll be back in next week um and then axic i don't think was [Music] so i think that might solve that um i guess also the next thing we have

to do is define the statuses for the hardware correlation sorry i'm back my internet went down uh do you want me repeat uh just if you could like in a sentence summary or two that'd be great um we should include how to get from one status to the other just to have like a to increase like the scrutiny um slightly and we should also start defining the statuses for hard-fought coordination good idea um let's see and do we want to do any of

that today anybody okay uh we could anyway i think it's only me yeah it only makes sense to do this with teams because he's the hardcore coordinator so he would be probably responsible for setting the status at least for the ethereum mainland deployment edson did you have something uh i was gonna say we should wait till james is here oh okay cool in that case next up we have item four the zips reference especially uh keywords i know some of us have looked at this zips

it's basically a version of the of like bips or peps or eips zcash has one called zips and on the very first section in terminology there are keywords um that are defined like must should should not may required that are defined in rfc 2119 and then it also interestingly enough it says the term network upgrade in this document is to be interpreted as described in zip 200.

and if you go to zip 200 it does expand on different the zip process itself so it's kind of like an active meta eip which is what we've been talking about doing for some of the processes or the sub processes of eip1 so this will be a really cool way to look at how to um our sub processes or our meta eips or our active vips and stuff like that i really like what they did with zip200 and i like that they have different terminologies defined

are there other comments or um other topics within this uh item um i think astm have a section for keywords or terminology are they included as a part of their standards i think a few other um standards like uh bodies have the same lord standard organizations have the same thing a terminology section um i'm not sure if we should convert or apply their specific terminology but we can probably consider adding a terminology section and you're meaning not any ip1 but in

like a sub eip like they have here or any ip1 um we can just have it as a part of all eaps like um somewhere where you define terminology it might help clarify um to someone just looking through what someone means by a specific term that's a good idea so like an example could be like the terminology they have in the zip process eip but put that as part of the template for people who are making new eips is that accurate uh yes okay so i i would also say that it should be required um the use of the keywords

in like um in templates or submissions yeah i think that keywords are important and so whether or not they're hmm as far as if they're required or not i don't know where i am on that issue but i think it is important to at minimum included in the template like you said the reason i say to require it is because it would be it would make life easier for editors to know what exactly is meant when a specification is described yeah yeah that checks out for sure and we do have security considerations

as like a required one so having terminology is another required one wouldn't be the end of the world or when i say that i mean like it wouldn't be a deal um let's see what else uh do we got uh anybody else have uh comments on the zips uh reference uh for keywords or anything else involving the zips okay the next agenda item is number five how to deal with non-normative edits to existing eips ensure the responsiveness of editors on actually merging prs and split eips into multiple

repositories so this is micah i don't think that micah is here so we might not be able to talk too much on this but we can kind of go over each one because there's three different topics within the comment that micah left if you click on agenda item 5 it goes to the comment how to deal with non-normative edits so like wording improvements to existing eips when the authors are non-responsive it looks like there's a few examples of that um that is a good point how how would we deal with um important updates like wording improvements or um

clarifications of something that like is incredibly wrong or a new security consideration if we're deciding that that's required for one of the eips that's been published for a while and we can't contact the author does anyone have ideas on how that could be resolved not a specifically on the resolution part but uh i was uh going to comment on this section like it may be also related to again the increasing the number of pr's like if we if we do these kind of non-normative edits we again have to create a pr here so i mean i also believe that we might find

some other way to get it corrected or may not be increasing the pr number or maybe to a track because as soon as we create a pr it sends an email to the author but it can also be done with the help of eip editors yeah i think the most straightforward solution solutions to eap editors deal with those yeah if there's like consensus among the editors that's an important enough change just make it and there's a history within github that you can go to to see when the changes were made and you can maybe maybe have the editors have a requirement to notate a date or maybe have a section of the eip that's like post eip changes i don't know if we want

a section because that'll imply that you can change your eip in the future which this should really be a rare process um but yeah the simple solution is the ip editors deal with it and i don't have a big problem with that solution personally the other solution that i think uh was proposed sometimes back in in one of the initial meetings of eipip to have a kind of group um which is like subgroup for the these editors because again these non-normative edits may not be a big deal i mean like these are important to make it um provide better clarification but may not be something that all the time we might have to attract editors attention here so if

there could be some kind of subgroups which would be looking into these kind of pull requests and kind of approving that can be another possibility we definitely need that um if there's enough of those eips to warrant that i don't know right now how many of them are and this is like a section of eips that are needing to be edited because of improvements after they've been finalized so not just in draft status and that we can't contact the author i feel like that's more going to be more rare but i could be wrong let's see anybody else have comments on

that one is um is it required if the eip is finalized then would you need to have the author's input just to reword things hmm it's probably a good idea because otherwise people can accuse the hmm that's a good point they could accuse the editors of being malicious or when i say malicious i don't mean like really malicious but like changing up the wording for their own benefit um that would be the only thing i can think of if it comes from the author

and the editors then that's like two sources saying this needs to be changed and that might be enough for a consensus around the change was my thinking personally it would make sense to me that if it's finalized and they don't respond for a certain amount of time and they forfeit their um leverage on that but oh yeah that makes complete sense let's see um anybody else have comments on this one okay the next one that micah put down was how can we improve responsiveness

of editors actually merging prs that's a whole sub topic for that we haven't really touched on much in the eipip meetings which is how do we recruit and incentivize editors we can touch on it a little bit today if we want uh since we're going through the agenda pretty quick does anyone have any off the cuff ideas for either recruitment or incentivization for editors and making sure they merge prs at a fast rate um we can table that towards like future meetings unless we want to deal with it now yeah that might be a good discussion topic all on its own actually um i'd say let's do that

on that there's a lot of teams that are working on um clients right would it be um some kind of onerous to put the responsibility on all the all the companies developing clients to provide or pay for or assign people on their teams to be editors or some i don't just a thought but um the only thing would be that would maybe work for core eips for ercs which is the majority of eips that wouldn't be applicable i don't think or really wanted okay that makes sense thanks um all right anything else on that topic i mean sorry just as an offhand idea sometimes having creating some sort of

achievement type of visualized thing um incentivizes people because they can show it off to people i know it sounds um very uh flat as an idea but it it does tend to work it just has to be based off of objective things and it doesn't have to be super complicated doesn't have to be an nft specifically it could just use um git coins kudos framework that sounds like a good idea i think it's a good idea because it's like it's like reputation points which works really well on reddit

we do not we may not have enough editors to do uh you know this kind of responsibility to take this responsibility at this point of time so maybe we should be focusing on how to onboard more editors to kind of solve the issue in longer so is this primarily oh uh i couldn't hear you elita can you talk again it might be my internet connection but i think you cut out sure um i was wondering if if we're talking about core editors or just specific eip editors

or in other words authors um my internet cut out for a second so i don't know what that was one is in reference to is that for item two for micah's stuff that's right i was trying to imply here the eip editors but in most of the cases the ap editors are also the core eip editors i mean they are looking into core eips so yeah they may be considered as for editors i think that's less of a that's less of something that is assigned as like a core editor that's not even really a term i've heard but more everybody who is an ei well no i i take that back like i'm not a core developer and neither is nick savers but all the other

editors are core developers so that's a good point kind of is a venn diagram of who is responsible for core eips at the protocol level and who is actually editing them so to answer your question when we talk about the responsiveness of editors for that alita i don't know if they're talking about core eips specifically or if they're talking about other types too so mica would be talking about core eips but i think we just need more editors in general yeah and once we get to the point where we're talking about editor

uh more editor involvement and how to recruit and things like that i think that will improve um uh what am i trying to say if we're talking about that kind of stuff i think once we start talking about that in a future meeting we can better coordinate around designations for editors and things like reputation systems or kudos systems or stuff like that um i think it might be beneficial to kind of have a description of what it means to be an editor that would probably help people or help us at least narrow down where we're going to be looking to say advertise

yeah that makes sense we should whatever whatever is implemented to incentivize continued involvement as an editor and increased involvement as an editor should also inherently by design need to incentivize new participation otherwise there's no point in implementing in my opinion good point all right does anyone else have anything okay um for the next one split eips into

multiple repositories as a reviewer i don't want to see or review ercs but i do want to see review core eips a protocol dev may not want to see a review interface eips by splitting core interface and ercs at a separate repos people can subscribe to one or more rather than having to drink the entire fire hose of vips i see their point my first response to that would be separating them into multiple repositories would be a lot of work which wouldn't be impossible to do but for the benefit of people just seeing what they want to see from github notifications we can make our own rss feed and other there already is rss feeds actually for different types of eips and we can

make more of those we can make different custom email notifications we can connect it to maybe discourse forms or things like that so i think there's better ways to solve the what what people want to see and review from a notifications perspective other than splitting it out into multiple repositories but i'm open to hear other ideas that or other um reasons why multiple repos would be a good idea uh i agree with i agree with you as in um we could just it's the he just needs a notification for corey aps and then anyone else could just have a notification for erc eaps for example

um and we do that with rss or email notifications but i'm splitting them out i'm currently the numbers tied to that repo so if we were to split it out the number would we can have overlapping eip numbers um yeah as far as i know we have github github um labels for issues how about we start using them actually yeah we started doing that axa started doing that last year and then we kind of fell off using them for my remembering so yeah we should definitely do that

can you do that for prs2 i'm blanking on if you can i could mark someone more some of those myself but i'm not in aab editors oh no no no i didn't mean like you yourself have you ever done that in the eip repo i mean on a repo in general and github can you make labels on pr's yes okay i just thought it would have had to be issues for a second i don't know why um okay so we actually use labels very actively for open ethereum requests so and issues too and it's very helpful cool yeah that'd be a

labeling system would be very important that's something we should add to the agenda for next time actually kind of a labeling system maybe maybe not for next meeting but for a future meeting um other comments on this uh i would agree that this labeling system would be helpful i i mean adding to it like documentation of these kind of instructions in the eip1 would be very much helpful for newcomers you know or maybe even to existing uh eip editor or crea authors to you know follow these things when we are so when we are done sorting out a kind of a pool of things that we would

want to implement if it is documented there much easier for reference and implementation would be simpler i see okay okay an artem you just posted an example of the labels cool um anybody else have comments on this okay that's all for item number five all of micah's um uh comments um six is to discuss the eip1 brainstorming document um which one is

okay that's a james thing i think that's james's document that's not linked here so we may have to skip this one um yeah let's wait until james comes back great number seven clarifications on how a pre-compile address is decided um we were having problems at a core eip level um on how it's unclear when there's an eip that's a core eip that has to assign a pre-compile addre or an opcode that is assigned a pre-compile address how to assign that um this isn't a hard one to solve as long as the core developers come up with a

system which isn't even that hard because like it just kind of goes in order and the only way that you can make a new pre-compile is to um uh like do it you could put it wherever you want in this huge like list of um addresses within aetherium but deciding like which one goes where is the is the question um i think we just discussed in the core dev meeting where it should go and they said yes or no so i don't really know how big of an issue this is and i think james reflected that in um and the issue in ethereum magicians if

you click on the link and then martin commented that the final state of pre-compile addresses might be good to include in a hard fork meta if any pre-compiles are added and i agree with that um there's some list floating out there of where of the pre-compiles and some of them are updated some of them aren't so that is something to also be looking out for is to get those lists updated but that's outside the scope of this meeting really what do people think of this this is more of a niche technical thing anyway so it might be out of our scope but it was it's a good thing to keep aware

for maybe hard fork meta eips and beyond that i think it's i think it's something that the core devs should just decide as they've been doing already uh anything else on that i don't really think that it's it is an issue because we don't introduce pre-compiles on a daily basis i agree so so i i don't think that we need to develop some kind of system to solve a very minor problem sounds good and then the last item on the agenda is review previous decisions made from

the eip improvement proposal call notes um so decision item 9.1 the eip process flow will be separate from hard fork coordination 9.2.1 rename the status of eip1 active to living 9.2.2 rename inactive to stagnant 9.2.3 no name change for final status 9.3 discussion to be continued on eip number registry process and 9.4 a medium blog to share the final eipip survey report will be published on friday um did 9.4 happen i think that'd be edson

uh yeah um so i think it's actually shared in the agenda um number um three so there i could repeat that again um it was just three different phases that we could work on first is decision making second is clarification and third is onboarding so formal like the specifications are formal and um clarity can be with the process to um participants or within the eips itself um but you can look through that article

be helpful to reference for every meeting yeah but those are all the results from the survey great i like how it's outlined anybody have comments on that okay that's all the decisions made in the summary uh there's that link in item number eight to review the items action items and the um notes from the previous meeting if you're interested uh very well done notes it's like a transcript more than notes and um that's the last item are there any other items that people have to bring up or want to propose for the next

meeting it's all right sorry i did want to um uh comment i was just kind of skimming through the eipip roadmap and i just wanted to um highlight i do like the fact that there's a um it seems there's there's a uh a effort to continue to lower the barrier of entry and i think um one of the biggest blockers for me being a part of any sort of process has been um there's just so much so much information asymmetry and so many things going on all the time that if it's not a low enough barrier and it's not immediately in my face

it's just it's not going to be seen so i think that is a good effort to continue great comment anybody else also what decisions do we make today um one of them is for future meetings to discuss um onboarding um uh eip editors uh in a future meeting um another one that i can think of was potentially or continued discussion on adding a mandatory keyword section to the eip

template and that's the only one i can think of right now was there discussion about labels using labels yeah yeah we should one decision was that we should uh have generous use of labels when in the prs um for eips once things get going another one was for the eip numbers uh oh yeah that it's not a big problem to solve so we can drop that uh yes yeah and a pre-compile address it was again suggested by james so do we want to see

that on the next agenda uh next meeting when james is on on on here but or should we drop that let's wait till james is on again so he can comment on it since that was his item right anybody else okay thanks everybody we will talk to you in two weeks on july 1st have a great day cheers thank you thanks bye thank you bye