Ethereum Cat Herders EIPIP, 11 Aug 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: EIPIP Meeting 39

Description

Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/82

A

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.

A

So I found this um this item in eat, one dot or specs uh repository in issues section, and the issue number is 290.

A

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.

B

um Yeah, let me just check the issue real quick, but um I think um yeah.

C

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 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.

C

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.

B

How others feel.

A

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.

C

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.

A

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.

A

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.

A

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.

A

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.

A

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?

A

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.

D

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.

A

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.

A

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.

A

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.

A

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.

A

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.

D

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.

D

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.

D

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.

D

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.

A

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.

D

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.

D

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.

A

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.

D

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.

D

Your ap is not mainnet, because you didn't update it.

A

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.

A

Is there any other specific requirement for them to be moved into the final status? If the last call period is over.

D

I think don't all core aps have to be consensus. Changes like that's the definition of where ap.

A

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.

D

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.

D

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.

D

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.

C

um So I'm on my phone, which ones are the actual eips like which, which one this.

D

Is the uh so one of them is limit account nonce to two to the 64 minus one. So right.

A

Now there are no nonces.

D

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.

E

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.

D

E

D

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.

E

Think you disagree with me now because.

D

E

Trying to finalize this, like six months ago,.

D

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.

C

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.

B

C

And comment yeah. um I agree. I have like zero opinion. I I agree.

A

C

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.

D

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.

A

Rules are satisfied right now.

D

A

D

C

So what happened.

D

C

I guess it would take a lot for somebody to actually break that rule right like daily.

D

Yeah, I don't know not.

C

Submit enough transactions.

D

Yeah, uh like the gas cost, would be insane just.

C

D

C

Amount of throughput we have on the network right, you get like a million transactions yeah yeah.

D

Like most ethereum.

C

D

Yeah, this is really just something that will help um integrators integrate a little bit having concrete.

A

D

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.

C

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.

A

All right, I can.

C

A

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.

C

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.

C

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.

A

Yeah yeah sounds good.

A

Yeah, um we wanted to add something light light.

E

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.

E

Supply of ether is bound. We can come to consensus on the nods bound.

A

So if I understand like one has to go, and one has to like move out right.

E

Couldn't set it better myself.

A

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.

A

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.

A

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.

E

I don't think that we should prepend erc to the title.

C

I will defer to light giant.

A

Okay, because there is no, um you know clear instruction here in the eip1, how it should be written.

C

E

C

Yeah, we don't have core in the core eip titles right, yeah,.

E

That's the part of the cat, that's the point of the category like it.

C

E

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.

E

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.

C

Do we need the authors plus ones to change that? I assume so.

E

C

So I guess that would be helpful to know how many, if there's like 50 of them or.

E

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.

A

E

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.

D

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.

D

E

A

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.

E

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.

A

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.

A

It's fine, oh okay! Okay, then we'll try to connect with the authors and see what we can do and.

D

A

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.

A

C

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.

A

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.

A

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.

D

A

So yeah, oh michael you're, back, please go ahead.

D

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.

D

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.

D

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,.

A

I'm on board amir, I like in fact I like the number two format that was suggested here.

D

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.

A

All right yeah, so that's about it and that yeah.

A

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.

A

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.

A

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.

A

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.

B

Thank you see ya,.

E