EIPIP Meeting 23

Transcript

all right I think we're live hello everyone and welcome to EIP meeting number 23 um we have a few agenda topics today um the first two were ones that like client put in um so instead of us uh going to those first until light client shows up we'll skip them and then we'll we'll have them at the end regardless of if he's here for anyone to comment on so we'll start with EIP repo cleanup item number three um what's that one about uh so in the uh in the previous meeting we decided that we should

continue the task of EIP repo cleanup that we were doing earlier now that uh the new bot has already done I mean already taken care of a major part like um uh if any iip is old either redundant is mentioned there or it is closed after certain period of time but we realize that eips ethereum.org they have this list of eips and they are still in the same status even though the issue is closed on issue and PR are closed on GitHub the status are not getting changed for eips and uh uh I was uh doing a quick U uh analysis of uh what

are the eips and statuses so I'm going to share a sheet in the chat so it basically a list all the eips that mean those are present in e. ethereum.org and it list a total of 312 eips so in the sheet if you can go to tab number two pivot table two um uh you may be able to find the uh list of eips divided on categories and if we give it a look we see that there are 229 draft status eips there out of 312 so it's a major chunk and uh we uh

caders are trying to reach out to authors of these eips and see if they are still interested in either pursuing it the EIP if it is like valid and if it is not valid anymore we would request them to change it to the status of withdrawn so in the tab EIP status change reach December 2020 I have listed some of the uh I mean like I have populated with some of the um eips where we already have reached out to the authors and have requested them to change the status uh depending upon the conversation that we

had um unfortunately it's not a very big success so far like even if we have asked them to change it it is still in the same status for a while so I was wondering what could be the right Next Step to you know move forward and we should be able to move all the eips in the uh right status my first strategy has been to wait for the six Monon timer to tick through all of them and then just Mass close them all or mass with stagnant them all should that's still like what four months away I think

five yeah we can be proactive if we want or just leave them stagnant it's kind of whatever if someone wants to take that initiative upon themselves they can for sure um and contact authors but whether or not it's like really necessary um I'm not sure I would say if we have author's agreement to Market as abandoned I'm personally okay with just doing the uh the actual PR to do that as long as we have you know credible belief that the author actually agrees like normally the normal process would be the author sets to abandon but like I'm okay if the

author says like if you contact the author on Discord like yeah yeah Market is abandoned like I'm personally okay with using that as agreement I don't know about others yeah actually I was coming to that point like you know we are reaching out to authors I mean like I have been reaching them to um uh for for some or the other task and uh during the discussion for some of the eips comes out that it is not valid anymore I was wondering if it is okay for me or Brent or any body who is in touch with that author to just create a PO request by that you know U we can we are also giving the opportunity an

author I mean first of all we are creating the P request because we have data we have reached out to the author and we have their permission but in case of you know verification of that if we create a PO request we give like um uh say 14 days time for author to respond back if he does not want it to be withdrawn or he has changed his mind or something like that uh then he can you know uh mention that as a comment and after that we would like to mark that as withdrawn the only concern that I found there was if any of the caters are taking that step they would be added as a contributor I'm not sure if it is like you know U ethically very much right but if an EIP editor is willing to take that

I I think that should be okay yeah or we could just say that uh you don't have to be a contributor to um to do a PR for someone else which really do you have to be added as a contributor if you do a PR for someone else's thep or is that just more like common like that's what commonly happens you do not have to be a contributor to do anything or to open any PRS there no there's no tech technical restrictions I should say I don't know if there's social ones right so I was thinking I mean I'm not sure or maybe uh you can help me understand this part like if if I if I go ahead and

create a PR for any EIP which I have information that Authur has mentioned that he's not willing to pursue it anymore uh I I I my understanding is like I would be added as like contributor to that once that PR is accepted but that PR is accepted at the state of withdraw so in my mind it should be fine just wanted to raise it as like ethical concern yeah yeah go ahead James like if if an if an author yeah if you do a PR then an editor still is going to be the one that has to merge it so there's which is which makes that totally fine if if an if an EIP I just want to go through like the different cases where I

think this would make sense like if an if an EIP author if you talk with them and they say yeah I'd like to withdraw the CIP or make it withdrawn then you making the pr for them um and then just mentioning that that the author said that it could be like that the author could always refute that that happen so it's not really that big of an issue if if someone was doing it wrongly because the author could just come back and say wait no never mind that wasn't the case um and or if the author says uh like to whatever really status that makes sense but if you get if an author replies and says I'm just not really working on this

anymore then I don't really think that counts is withdrawn that to me sounds more like stagnant it should just default to going to stagnant when the time goes out right yeah they could get their opinion though and just say I want to withdraw it and that's all we're giving them the opportunity for yeah yeah and so if they say that but like even so if if I talk to someone and then I hear from them that I don't think that default means that they we can make their we can withdraw oh yeah of course like they have to say that they want that they allow us to like explicitly say that they're okay with us moving their EIP to withdraw and it shouldn't be like assumed

or or something like that yeah that sounds good and then um just to make sure I'm clear on this um Pua what you're saying as far as being a contributor you would do a PR uh that would attach your name to the EIP but not like actually write it down as a contributor to the EIP right like as an author or anything yes yes okay I think what she's probably referring to is in GitHub they have little contributor tag that shows up on people who have successfully gotten a commit somewhere in the commit history oh okay a GitHub feature that's fine your name okay yeah I'm I'm personally I'm good with all that so if if there is a general

agreement on this I may have a list of eips for which we have already requested the author to change it or they they have agreed somehow but maybe in in absence of bandwidth or higher priority job or something like that the EIP theps has not been created yet so I can go ahead and do that and adding a note to the author so if you have like a disagreement with this uh uh please respond back within 14 days or something is that fair I think it's reasonable I think also so for a lot of these authors having worked with some of them before I suspect if you just create the pr and

send them a link and say hey do you mind clicking approve on this uh they will be more likely to do that than go and create the pr themselves because cing approve is marginally easier than actually going through the effort of creating the pr itself and so if you just create the pr for them and then send them a link on Discord or get her wherever you're contacting them and say hey do you mind just clicking approve on this I suspect most of them will be willing to do that since it takes like 10 seconds so sounds good to me so I will try to go ahead and that would let us kind of speed things up a little bit so we don't have to wait two weeks for them to decline because said they'll probably do it right away and then we can just merge it

immediately so I see sure okay um uh let's see do we go on to the next one or do we have any other uh comments like Cent said he's not build the mix meeting so we can go back to one and two if you want or we can still into the end okay let's do one and two just a second had to sneeze glad I put it on mute um let's do item number one handling retroactive changes if you click on that it goes to a issue in the eth 1.0 specs um where he said there was no desent and

moving EIP 2681 forward during allore devs number 101 the problem is what does that mean with the separation of EIP as at Network upgrades final doesn't mean main net typically this isn't a major issue because we can use the upgrade tracker and once it's scheduled it an upgrade it is recorded during that transition but EIP 2681 sets a limit on countenances retroactively from Genesis huh my guess is that a modification should be made to the yellow paper so my yeah go ahead my feeling on this is that there's there's a whole set of these cips that Lake client and a would like to push through and I fully support um I don't think that we need a super

formal process for this set at least and I'm tend to be hesitant to generate super formalize processes until they're needed um in this case I'd say we just you know make Mark the PR is or Mark the EIP is final and we're done like uh updating yellow paper we should probably do as well um and you know anyone can submit a PR to the yellow paper to do that and I don't think that would run into any trouble um but I don't know if we need a formal process here like I say just merge to final like any other EIP update the yellow paper like any other e or EIP and that's it like we're done basically with it might be as easy as

just having a list of the active eips on mainnet in a in like a table on eth1 specs repo so you merge it you add it to that list anyone who's wanting to make a client would just look through all those VIPs oh yeah that's one yes uh the caveat there is that you cannot actually write a client from IPS alone because we do not have the original set of spec on anywhere other than yellow paper yeah so you use the at yellower Yer plus the list that's right but the yellow paper should already have the whole list integrated into it in theory it's like if you have the yellow paper

you don't need the IPS and if you don't have yellow paper the IPS don't do any good which is an unfortunate situation at least it's supposed to the in theory the yellow paper is supposed to be updated every time there's a core protocol change I don't honestly know how good we as a community have been at that um I don't know if anyone else does well like pretty much all the pre- compiles that have been added since I don't think are in the L paper you'd have to go to eips for those um no some of them have been added really yeah there's been someone keeping up with it uh just a community member's been adding them and they've been getting merged every once in a while but they're not I don't I can't say it's completely up to date but it does have a good number of

the pre- compiles okay so it um I guess my take is it shouldn't be required to update the yellow paper for it to go to final if that's anything being suggested which I not sure if it is um but it should be encouraged if someone's willing to do that I guess and then um final doesn't mean main net um but have we changed that rule yet or have we just said that I believe it's actually e represents the final standard final EIP exists in state of finality and should only be updated corrector that's what final means so has nothing

to do with M anything anymore okay then yeah um let's just do it to find we have stated that in the sense that we removed all the terminology yeah got it okay so now what people are worried about are getting okay I see the concern now more so um yeah for now I I like what Micah's idea that he originally said I think we should go with that do lead into another discussion possibly better suited elsewhere but it would be nice if the we had team or a group or a something that makes sure there is one canonical source

of the eth1 spec um I personally am one of the people in the mediumsized group Who hat the yellow paper um but at least it is a single Consolidated place that has the current ethereum definition U it'd be nice if there was confidence that that was actually true I guess here is the current state of ethereum defined somewhere again whether that's yellow paper or purple paper or green paper fuchsia paper or some spec repo like E1 specs similar to how ip2 does it maybe within Wiki or something like any of these would be fine with me but it would be nice if there was a single source of truth that defines what it means to be a client that being said

I am way overworked and I think all of us are so I do not volunteer just to add here like uh in the last meeting even light plant also mentioned this as a suggestion like uh we have spec of x2 in x2. Spec repo the current spec of our clients could we have something listed here in uh F1 for ethereum 1. chain um this sounds like a really interesting thing to do starting with this next Berlin hard fork and working backwards um so that would fall into the eth 1.0 specs repo uh which generally

falls under james' stuff but uh James what's your load like right now oh no that that makes sense okay so is that something go ahead doing the like putting all the hard Forks up and retroactively like putting in Berlin and then putting in all the other hard forks and these are the eips and the block numbers which would when they came in like that that's stuff I was already planning on what I don't really understand yet is what's the best version of how to keep if if we did keep something like Micah is saying on eth1 specs what's the best way to do that that would allow it to be most likely kept up to date and easiest to be used I do not have an answer to that yeah

that's a whole another thing I think this is the yeah the canonical problem I mean a sufficiently uh specific specification is called code and so by definition just the GU repo is arguably the eth1 1.0 spe yeah yes or maybe NE mindus I don't know take your back so something and so that's like what I just don't know yet is like what a what a list of eips that are supposed to be on Main net be sort of enough or would a link it or um would the yellow paper like the yellow paper should stay probably where

the yellow paper is because people expect it to be there there's some like other things that probably specs is like the networking protocol stuff like the eth eth 64 e65 e67 those things could probably fit too I think as a user who has uh unhappily had to read the yellow paper many times over the thing that I want that I always end up going to the yellow paper for and then when I get there I'm like oh I wonder if this is actually up to date and it makes me nervous is I want a reference like like for example gas costs how much do things cost in gas today like I don't actually know if the

yellow paper reflects reality right now it might it might be close maybe it's mostly right I don't know and there's no place I can go to get an authoritative answer to that other other than digging through like the G or nethermind repo and trying to find their gas accounting methods and maybe hoping they have like a constants list somewhere in the repository like those are the types of things that I really would like to see um similarly data structures for the for like the structure of a block it's like I can go to the yellow paper and try to parse that out of the mathematical notation or I can you know try to go on stack exchange and try to find someone who has defined what a block is but that's probably out of date by now and so now I need to find another

one and so I end up like trying to put together all these different pieces of sources of Truth where okay here's the yellow paper but it's out of dat the stack Overflow has slightly more update or easier to read information but it's out of date and then the nethermind repo you know defines blocks but they're kind of spread out over 17 different files and so all I wanted to do was figure out what does what is the shape of a block like an rlp uncoded block show me that there's currently nowhere to go this authoritative it would be nice if there was an authoritative place that I could felt like I could trust that is a up to date and B human readable yellow paper kind of half meets the up to date and does not meet human readable in my opinion and then all the other sources

don't meet the upto-date or don't meet human readable um again I do not have time for this I re recogniz this is potentially a very large task and so I do not want to put it on anybody um one potential place is the eth wiki it is the third place that I go to look I don't know who's maintaining that but it has some good info but it's not always accurate like it's not updated maintainership is up in the air right now many times yeah maintainers ship's up in the air right now okay I could I could certainly coordinate and help make sure everything stays consistent I would need someone to help do a lot of the heavy lifting of actually getting all the work and the like the the information Ren in I see

this is a good Bounty project so we pay someone to do lot of work yeah so we pay someone to do it and James is the project manager of It kind of yep because I I have enough knowledge of all the little pieces that I could keep them together as far as what's supposed to get done and how it's supposed to fit together and we could Bounty off the rest or find someone who wants to spend three months let's add that to the agenda for the new year or maybe even for next meeting to spesh it out just a tiny bit more but maybe for the new year to figure out funding and maybe have like an EIP editor fund that the cat h herters control yeah because it it's that sounds

like a good resource for developers yeah that's like pretty good I I I know I I've personally needed this class of information you know dozens of times doing building daps or trying to write eips and whatnot and it's surprisingly hard to come by reliable info so I would love it yeah okay sounds good um in that case um if we are are we done with this topic that got a little bit off T onto tangent but that's good because we're going to bring it back in the next few meetings about this um but the decision made was basically that you move things to final

and that there's not a requirement for the yellow paper to be updated but um there's going there's plans to both James to do an E 1.0 specs repo list of eips per per Fork eventually and there's also a uh potential plan to have someone update the yellow paper or to make another source of Truth and bulk in the new year did that sound right everybody y okay next agenda item implementation section in the EIP repo um so this we we can maybe uh speed through this one if you don't mind yeah go ahead um so AIC uh took

[Music] a politically correct approach to this problem and started with an issue and filed it and got some responses and then then I forgot about it and then I went and took a more let's say bold approach to this exact same problem and I just submitted a PR to make this change uh no one said no to it after two weeks and light client said okay and so I merged it okay I later realized just now that I forgotten this issue was created um and I don't know if that was I probably should have let him do it the politically correct way rather than the Bold way uh but yeah so it's already done basically

oh okay we can revert it if there's discussion desire to but it's I I'm fine that it went through personally yeah just let just let them know it should go through and I remember we talked about it a while ago as well it's still the same it shouldn't be there and in general I'm in favor of removing a lot of the stuff that was kind of put in to assuage people and to trying to do something that doesn't make sense anymore okay that sounds good okay I'll uh update that that issue and close it okay sounds

good um oh man item number four is missing everything's broken the world's over um never mind we're going to go to number five um single source of Truth for EIP what was was this one about um I can't handle this chaos sorry about that that's okay I'm just playing okay uh so a few meetings back we uh we discussed that there are too many sources for eips like we have EIP read me GitHub and then eips do e.org and then ethereum.org

EIP so um Brent volum here to uh get this information at one place I think he left some messages on this card uh he was like proposing to have a Google do to list all of the following sources of EIP Truth uh where we find like duplicates are available I'm not sure he is in the meeting today to explain that further but yeah if anyone has any thought oh thanks joining BR sorry I'm late all right please take it over um so are we talking about the uh um the

uh single source of Truth free IPS is that the Cent yes that's it okay cool yeah I um I put I posted on the peeps of and Eeps the proposal to create a a Google doc to to coordinate uh and list all of the single sources of or all the non all the sources of truth that are have lots of duplicates and then some proposed Solutions and list of issues and build consensus make sure there's consensus around the fixes and and and then once we have that set out then we can push forward to making that happen but anyway if everyone's on board with that or then I'll go ahead and push forward with that and get get involved uh listing all the issues and proposing Solutions and stuff like that so if if

anyone has any other additional sources of Truth or any other ideas so uh yeah so that's the plan anyway that sounds good to me okay yeah I'll be creating that document and um start listing the issues and proposing Solutions and well I'll see if like we can pull everyone that's involved on board um one question I did have is uh the the guy uh is it Jason uh the the guy that works with the foundation that's responsible for that site what's his name is I'm pulling up my notes Here uh sorry I'm kind of ready for this Sam Sam Sam Richards Sam Richards C can

someone contact me his Skype ID or something like that because I'd like to make sure he's um on board with that and and and pull him in since he's sounds I think he's one of the key figures and stuff like that yeah sure uh I have his telegram let me give you his Telegram and I think Sam also joined our cat H herder Discord so possibly you can get his contact oh sweet yeah okay yeah he's he's pretty active on Discord yeah let let me yeah just do Discord actually I won't even send the telegram because he's more active on Discord I think yeah yeah Discord should work perfect all right uh anything else on that nope that's all thanks so much all right EIP status blog and EIP editor roles and responsibilities blog

um uh I sorry I wasn't here last time so I'm out of the loop on this item um so uh this is like U coming from a few meetings back when we were discussing about the eips onboarding I guess Edon was supposed to submit a Blog on what are the you know roles and responsibilities that were agreed upon here uh and the other blog was uh the EIP status blog so um I I haven't heard about the first point part the EIP editor roles and responsibility but uh Edson submitted the second blog uh that is uh for EIP status the question that we were uh trying to get

answered to last time was um is cat heren medium the best place to publish that blog or should it go to uh somewhere else and uh he was supposed to reach out to James because James was not there yesterday I mean in in the earlier meeting but today I'm not sure Eden is not here so yeah that was the question that should we publish it on cat herder medium blog or somewhere else my perspective is we should do cat Herter's blog because we've been doing all the EIP IP stuff so we're kind of associated with it in that way and I don't know of a better blog for that yeah I I'd agree with that it may

make sense to someday take that and like distill it into some place on like the VIP repo or something too all right I just have shared the blog in chat I mean the link that is submitted to the caters medium it is not published yet uh it was just a thought uh suggested by light client that because this is of like you know U might need higher visibility or something so we should first check out the James because he's the uh Network coordinator right now so yeah if we are fine then we can go ahead and it in C's blog and if people have any thoughts and suggestions on any correction is needed feel free to

uh leave a comment there and we can we can get more visibility on it like through a tweet or something like that too right or like so make sure bring stuff like that up and we can see if there are other ways to get better visibility sure okay great um number seven is review action items from the previous meeting um unless oh do we have anything else on the blog stuff um I guess we should wait for Edson to make a final decision yeah I'm f m yep okay um so the decision items um so wait we're going over are we going over

action items yeah action items the only one is Edson will contact James to decide where to publish the EIP status blog um so that's just one we're waiting on so that'll be rolled over to the next um meeting um okay was there any other uh stuff for the EIP meetings um also what's two weeks from now is that a holiday uh no it's not technically a holiday is there anyone who won't be here for that you get holidays it's 30th December so it's like end of December so everyone's off

randomly for their for stuff but I guess people are traveling less depending on where in the world you are so um I mean I'm fine to make it next I mean like next meeting if it happens on December 30th so if people are there we can suddenly plan it yeah I can make I can make it I I I don't have a personal life so I can be [Laughter] there Echoes sentiments okay well yeah then that means there's I think what is three or four is a quorum for these kind of meetings so um we'll we'll go ahead and have that in two weeks on December 30th at 1500 UTC yeah 1500

UTC um anything else from anybody before we close the meeting uh did someone have the Sam Richards contact I'm not seeing that yet did I miss that or uh it's on Discord in the cat Herter's Discord I one of the members of the cat okay I got that I you cool thanks okay if there's nothing else what was that Micah congratulations to us congratulations to us we're down to 28 open pull requests in the A's repo down from like 500 so wow wow down to two pages very manageable that is awesome great job uh especially especially to you Micah you kind of did the bulk of

that I feel like if not like client too no all all credit goes to the bot oh the bot did it all right well good good job bot yeah the robot all the hard work here okay with bot I just got one question in my mind I know I mean it's not a question new question for people like bot has already closed my earlier um uh hard Fork retrospective that we did as informational so I I think it would be a good time to move it to EIP I mean like f1. spec reposit now yep yeah I agree I'll do that okay you can make a folder for

them yeah I'll do that I got all right sounds great all right thanks everybody see you all in two weeks bye have a good day yep thank you thank you thank you everyone byebye