EIPIP Meeting 39

Transcript

welcome to eipip meeting 39 i have shared the agenda in chat and the first item on the agenda is network upgrade version release process and documentation so i found this um this item in eat one dot or specs uh repository in issues section and the issue number is 290. uh generally it has received positive feedbacks and people seems to be in agreement about the version release thing like there should be like version release for network upgrades wondering if people would like to discuss or is there an agreed upon process for it this number one and

number two is like if there is where it can be documented or where people can follow along um yeah let me just check the issue real quick but um i think um yeah this is the full yeah okay so i think we still have like some time before we need to actually do this um just yeah i i suspect the merge is probably the first one we need to figure it out for um [Music] yeah uh yeah i and and i don't know i i personally would like to see how like

the merge spec uh sorry the executable spec comes along before the merge to see if you know we're gonna have that um yeah i i don't know i'm just not sure if it feels like a bit early to like make a final decision on it i'm not sure how others feel yeah i mean i was just wondering like you know if if there is something already in place then people can follow along or if it is they eat one or spec repository that people need to keep an eye on that yeah i think the east one of spank is is the best place um and like in the next few months uh there should be some

updates on that but i don't think it'll be super soon um yeah unless anybody else wants to like own this but i suspect i'm probably the one who's gonna have to to figure this out all right maybe we can revisit it after a couple of weeks if there is any progress or i mean like my best guess would be it should be read me off eat one or spec where we we can follow like find more information if there is any process in place or if there is informal agreement but as to

mention that this is too early to make kind of announce on it so we'll come back on this topic after a few weeks moving on uh the next item on the agenda is eip erc editors in training progress so yesterday william sharp i and matt garnett we had this meeting of in training meeting uh this was the third one in a row we went over more than five proposals and uh after a few discussion nightline added comments on all of them uh so we came across a few um topics or issues we can say that we would like to bring it to uh

attention of daughter audience the number one was eip's merged as final while there is an open pull request for the proposal so this issue was identified for two proposals uh so both the proposals were final and we came across that there was something uh open pull request which was missed earlier or we could have addressed so we were wondering if um if this can be resolved with the help of a feature addition to the existing bar um for that my suggestion was if if there is a pull request to change the status to final the bart makes a quick check into all open pull requests to list if there is any other pull request

for that particular proposal and if so then send a warning message to the editor as well as to water uh with the list stating that this cannot be moved to final because there is or are open pull request that needs to be closed before uh merging this proposal to finals i'm curious to know what do people think in general is that something worth spending uh time and effort and getting it done or is it something that that is very rare and it should be man managed manually by the eip i i think that um i'm gonna be nice if the bot did that check for us but i don't think it's high priority for me i think it's a pretty rare situation um

when it does come up it's usually manageable it's not a big deal um like usually those last minute pull requests are non-normative changes and especially at least for core eips they're usually not normal of changes and so i think that i would say yes added to the to-do list for bot things but as low parity right any other thought on this uh unfortunately i do not see alita on the call so i'm not sure if she would be in a position to add any you know thoughts or how does she find

the issue if not then we can also open it for people interested to contribute maybe all right uh so let's let's consider it uh but but not very high priority task so there was another thing is like checks needed for proposal in the last call so um the concern here was what to do with the review date of a proposal if waiting on author's response so at present our eip one that describes about the last call status change it states that a proposal needs to be there for 14 days no specific instruction of what to be done uh next

if there is some complicated situation or something adds up to a normal scenario say for example suppose an author created a pull request to move the status to last call and receives a comment from an editor or anyone from the community to address something and that author is unavailable for next 13 days or maybe more and then shows up after the last call period has passed so uh there could be two um situation with that one when a pull request is already marched and like you know uh we are waiting for those 14 days and this happens in between and the other situation can be the pull request is still there and it is not merged and

author is unavailable for 14 days so what do people generally think should be next course of action for i'm asking it from a new editor's learning point of view like what should be the normal course of action and if there is something should we document it in the eip1 like we add it there so my current process is when i i generally want the um last call end date to always be two weeks from when it enters last call approximately and so if an author puts up a pr saying i want to move this last call i give some give them some feedback um to addre that i'd like them to address before we move to the last call and then they address it usually

i'll then say oh can you also update the last call date or i'll update it for them either one but the idea generally is that we want things to sit in the last call state for two weeks and so um so yeah just ask the author it usually goes over pretty smoothly i just ask them to update the last call date the times it doesn't go smoothly is when it took a long time to get the last call because there's no editors reading like i feel bad for them because a person like you know puts up a uh pr to last call and then like a week later someone reviews it and then says oh can you update the date for another week and the week passes again and it's like this back and forth um in those

situations i'll usually just update it myself and merge it and apologize for the delay um again the goal is two weeks in last call and ideally any delays to getting to last call are caused by the author not the editors right yeah so yeah my question is like if it is because of the author and and like author is unavailable for some time even after receiving some comments they could not make it to come back and respond to it what would be the next step like should we keep the original date of the last call or whenever he shows up and do that it's it has to be

like restarted oh are you saying like after it's been merged to last call it's been in last call for two weeks oh okay uh so in that situation i'm fine with just you know two weeks the point of the two weeks is to make sure that in theory um people are aware of the eip and have time to submit feedback whether the author listens to that feedback or not is entirely up to the author and so it's on them to do what they want with the feedback that's not really our place to say you have to listen to feedback our place is just to make sure that there's a process in place that gives people an opportunity to provide feedback so my general feeling is you

know if the author really wants to rush through last call and ignore all the feedback they got it's up to them it's their choice we we just we just made sure that the process was in place that there was a way to get feedback that's harmful that clarifies a lot of confusion so if it is like on author to decide whether to address that or not it's fair enough yeah basically the one exception i might make and this is this never come up and i don't think it will come up but like for core eaps in particular um if the authors are non-responsive and the eip does not match what's actually

implemented on mainnet then i might step in and take like a heavier hand again for core eip specifically and only if the eip did not match mainnet spec i don't actually know what i would do in that situation exactly i might just create another eip and say sorry your ap is not mainnet because you didn't update it right and i have actually left some messages for author of some proposal so that is a core proposal but for core proposals which actually does not require the hard work or the upgrade that uh like to undergo is there any other specific requirement

for them to be moved into the final status if the last call period is over i think don't all core aps have to be consensus changes like that's the definition of where ap i see there are a couple of them and number is 26 81 and 33 38 to my understanding they may not require the upgrade but they are still a part of core eips see this is oh these ones um uh yeah uh these ones are tricky and this is kind

of why these ones are have been taking forever to get through unlike most core eips we don't have a good mechanism for getting these actually like coming to consensus among client devs on it so it's a core eap in the sense that this is a consensus thing like clients need to come to consensus on this it's just they happen to come to consensus on it right now as a side effect not as an intentional thing and so alex is trying to make it more official and say look this these are the rules they're very strict rules and you know everybody has to follow them and everybody does follow them right now we're saying that new clients also need to follow these um but there's not we don't have a process

in place for getting feedback from the courthouse to make sure that all the client devs actually agreed to this um and so i don't have a good answer for you like they're called these these ones in particular are complicated and weird maybe tim has some ideas um so i'm on my phone which ones are the actual eips like which which one this is the uh so one of them is limit account nonce to two to the 64 minus one so right now there are no nonces on ethereum that go past that so it's de facto a standard but uh alex is trying to make it official and you know make it so it's you know an actual consensus violation to go above that somehow yeah um

we don't i don't know how we get consensus on that from the core devs because we don't have to actually do anything can we just pull it back thank you oh go ahead i was just saying first you have to convince micah that 2 to the 64 is the right bound and then maybe right core developers so i guess there's that's fair there there are two issues here um i disagree with alex that the right boundaries who's with 64. i think you disagree with me now because i was trying to finalize this like six months ago all right so i gotta disagree with the both of them um and so really what we need is we just need you know core devs to say you know is it two to fifty second or is it two to sixty four like just putting the agenda

can you put it on the agenda for fright or this friday or next friday like the agendas are pretty are pretty empty right now um yeah so yeah if you have a backlog of like things you just need the plus one on i think we can probably if and especially if you put it on the agenda like a couple days at least before you know people can see and comment yeah um i agree i have like zero opinion i i agree if that's yeah if that's the behavior we want like we should get it documented um i don't care what the number is but i think yeah just getting different client teams to to kind of state what they think um and we actually don't really need a hard

fork for that right like it's basically a soft fork because it just kind of makes the balance smaller there's no fork it's just a kind of asserting rules that are in place as an accident like both these rules are satisfied right now and for all history got it and so what happened yeah i guess it would take a lot for somebody to actually break that rule right like daily yeah i don't know not submit enough transactions yeah uh like the gas cost would be insane just imagine like the amount of throughput we have on the network right you get like a million transactions yeah

yeah like most ethereum yeah yeah this is really just something that will help um integrators integrate a little bit having concrete bounds because it makes it easier for them to just know that okay i know this number will never be too big so i don't have to worry about this whole class of problems like overflows and whatnot okay yeah i feel yeah let's just put it on the call and see if there's any like reason not to strictly bound it but i thought there would be one all right i can add it to the agenda maybe uh like as uh as to understand what could be the process for these proposals and then we can like probably discuss it and see if this can be moved to final status

because my review period has already ended and these have been in last call for over a year now yeah i think i think the process is probably to have them on our core des and the reason this is you know six months is just because it was way less important than the past six months of conversation like like but and not that like it's not helpful to have this role but like as we were planning london i guess it's just not the priority and we ran out of time on a bunch of calls so i i i know yeah it's weird like the the last call period might not be two weeks if these things just are not like high priority and there's another really big high priority thing say like in four months if we're

like in the middle of the merge i suspect something like this would also sit for a couple calls at least um yeah yeah sounds good yeah um we wanted to add something light light i'm just looking at these they're hilarious this is two last call eeps fighting it out for the upper bound of the account supply of ether is bound we can come to consensus on the nods bound so if i understand like one has to go

and one has to like move out right couldn't set it better myself okay uh i'll add it to the all core dev agenda and let's see what people there think about it um yeah so moving on um there was this one last item that i wanted to bring um to the attention to the group uh that is related to erc title for math so i don't know if this is the right people to talk all about ercs but because this is related to process so i just i'm looking for some good feedback here so at present uh the title that that is added in an erc even for the new

proposals uh those are variables like some people add it as like erc one two three and then whatever the erc is for and some people do not write that erc one two three part is just eip and then whatever the proposal uh is about i'm wondering if we can have a standardized format so i looked into eips eips.ethereum.org and the first erc that is erc 20 uh i think that was created by italic i suppose yeah fabian and vitalik so in that if we look at it the title states uh specifically that is it it is an erc

and then mention it as token standard so it is written as eip dash 20 and then erc-20 token standard but this is not the case with most of the erc what uh editors think in general should be the general practice uh if we standardize it we can start educating people and let them know like it's a good practice to have in place i don't think that we should prepend erc to the title i will defer to light giant

okay because there is no um you know clear instruction here in the eip1 how it should be written yeah like we don't yeah we don't have core in the core eip titles right yeah that's the part of the cat that's the point of the category like it says that it's an erc in the category it shouldn't repeat that it's an erc in the title and then repeat its number unfortunately a fair number of like really big ercs have done this like i'm looking now erc 721 is erc 721 unfunable token standard it should have just been non-fungible token standard erc 1155 should just been multi-token standard i think we can go

back and replace a number of these with just their titles but some of them don't make so much sense with just the titles they have like erc 777 token standard if we just replace it with token standard it's not quite clear yeah i don't know i think like again just we could probably go in and replace most of these and just try to keep people from doing it anymore do we need the authors plus ones to change that i assume so yeah yeah so i guess that would be helpful to know how many if there's like 50 of them or actually i don't know some of them i would say no the ones that like are actually have good titles like i think

we could do 721 without having author approval because it already says non-fungible token standard that's like really a very non-normative change for 777 i would want to add something that describes it a little bit better so i hopefully you guys can hear me uh so i would i kind of agree with matt there i think that for all of them we should remove the eip number from the title for some of them i cut out we lost you

yeah all right so my next question here would be like is it something that can be done on final um proposals if we get author's permission or can it be done at the greatest level i think most of them can be done like the the ones that aren't the ones that make pretty good sense without the drc in front of it we can just do the ones that are less clear maybe we can ask for authors opinions too to help but it looks like most of them can just be removed i don't see there are too many so if this can be handled i think it's less than ten yeah

one two three six seven seven i think yeah less than ten it can be done um will try to reach out to the author and request the changes i'm not sure changing the title like uh the title of the proposal um more than just removing the erc number uh is that is that something like that acceptable or like because this is already in final status it's fine oh okay okay then we'll try to connect with the authors and see what we can do and we'll try would that make sense if we add a line in eip one stating that do not repeat

like this thing the erc 123 before your title so uh maybe the future proposals that comes up they do not have it added yes i don't yeah i think either eip1 or the template right like in the template we can maybe add a comment beside the title saying like don't put the eip number here right yeah yeah for backlogs we can do it manually reaching out to author but for future i will try to get it documented anywhere eip1 is the best place and the template has been suggested so we'll try to get it done or maybe someone will create a pull request

to do that i will try to do that too okay i think micah added uh i did something on the comment which is uh something to discuss description field in the header header place of summary section um let me pull out that pull request number i think it is by and sick yes so yeah oh michael you're back please go ahead and maybe my internet has been terrible um so the tl dr is that we currently have a simple summary which is intended to be a place where you provide a very very short description of the ip like one sentence long

i usually recommend people think of it like a email subject line or github pull request title or like the kind of short description on a forum thread something like that um alex would like to move that to a description field and put it up in the metadata so that way we can uh render it especially like it has more of a special place and so we can when we have tables and lists of efus and whatnot we can use that kind of more like we integrate it better into places that you know render eips in different ways i i generally agree with this i think it's a good idea and so we're seeing if anyone has any problems with that change i'm on board

amir i like in fact i like the number two format that was suggested here if no one has any problems with it then we i'll tell alex to go ahead and move forward with it sounds like everybody generally likes number two format so we'll probably go with that one all right yeah so that's about it and that yeah the next uh item on the list is a jason rpc api spec progress update i suppose uh

alita wanted to provide some updates but unfortunately i do not see her on the call so we might want to skip the item it seems like this meeting is going to be a little shorter than usual um i am moving on to the next item which is like uh um getting into action items and decisions made from the previous meeting and if people find some other topic that they would like to discuss in today's meeting we can probably pick it up after this one so the action item it says that uh which i will consider a feature update to present eip bot as a task list and ask data to provide her feedback uh yeah

but unfortunately we do not have anything on the call so we maybe keep it open for the next meeting and we'll come back on it um yeah the other bot tracking inactivity period i think it is still there yeah i think we have covered what whatever we added in the agenda for today's meeting anyone wants to bring up anything else well if not then we i i think we can give everyone 30 minutes back we are ending up early thank you all for joining us today and see you all in two weeks thank you see ya

everyone