EIPIP Meeting 118

Transcript

[Music] Heat. [Music] Hey. Hey. Hey. Heat. Heat. N. [Music] Hold

[Music] on. [Music] Hold on. Heat. Heat. [Music] Oh hey.

[Music] Oh heat. Heat. Heat. [Music] Welcome to EIP editing office hour.

I'm sorry and I just have to hit the record button. Sorry about that. >> Recording in progress. >> Welcome to EIPIP meeting 118. This is July 16th and this is on Ethereum PM repo issue number 1621. We are joined by editors and some community contributors. On agenda we have open issues and PRs which requires editors attention. We do have call for inputs which people can be made aware of and if anyone has thoughts they would uh go ahead and add it to the issue just to let people know what they think about these particular

issues. After that we have a community project presentation here followed by some discussions and updates along with the EIPS insight monthly EIP status reporting. So um starting with the very first item I have noticed there are two open call for inputs and I would like to invite Sam to maybe talk about issue number 389 and 390 Sam if you are speaking we aren't able to hear video

if there is any microphone issue. Yeah, sure. So, let's proceed with the other item while Sam is taking care of his microphone. On the next item, uh we have u some miscellaneous uh issues and PRs to be looked into. The first one here is issue number 108. I'm going to share the link right here in the chat. It's auto review bot failing on PR 930. I suppose here the requesttor is uh is facing an issue with the error number is error mentioned is no artifacts found.

It seems like either there is no artifacts on the repo or yeah some help is required here. If any editor has thoughts on that or if they can perhaps add any comment at the very least I wanted to bring it to the meeting so people can take a look and see if this can be helped. It seems to be sitting there for quite some time. Um well moving ahead I found another similar issue which is called missing

state updates or optimizable state variable. Here again uh I suppose uh editor may be able to help. Uh this seems like a genuine problem to me not a spam issue. So kindly take a look and if there is any suggestion for the uh initiator of this issue, please feel free to add there. Moving ahead, I have added a bunch of issues which I feel like either it needs to be closed or they are kind of a spam issue. I am unable to hear uh thoughts from uh editor on this. So I just want to bring it up here. Does anyone has any

objection on closing either of them? I don't know Sam if you would like to uh check if your audio is working and if you have any thoughts on any of these issues. >> Uh hopefully my audio is working now but I also didn't hear anything from the last 10 seconds. >> That makes sense. Very well. Uh so we were just talking about the miscellaneous issues and uh the issues those are added here to be closed. So uh for miscellaneous I found that there are two issues which might need editor's attention. One is um issue number 108 and the other one is 931. Both are on the ERC repository. So I just wanted to bring it to editor's attention see if if

there is any response appropriate response for these people. Beyond that we have a bunch of open uh issues which I feel like it should be closed. So uh going one by one do you want me to go with that or we can perhaps take a look at it after the call. It does not require a lot of uh editors input rather than a decision here. Should it be closed or not? >> Uh so the auto review bot one looks fine. Um I think the other ones are probably okay to look at after the call. If there's anything um contentious, I'll I'll message people.

>> Yeah. >> Any thoughts on to be closed list? I think there are five open issues here which all seems to be closed. Um editors if if you think that it should not be closed and it is a genuine one please feel free to uh add a comment uh otherwise I have just flagged them to be closed.

There are next bunch of uh uh proposals which are typo. Uh the first one here is issue sorry PR number 856 any1 objects for this one to be merged. Oh, I'm sorry why I did not copy it. Address and it is 856. Anyone here objects for it to be merging? >> Uh, no, this looks fine.

>> Mhm. Cool. Um, next one is for ERC 5850 which is again I believe it is waiting on editors input like I believe it is just a spelling and someone is trying to fix it and it's pending for quite some time here. accomodate initialize.

Therefore, yep, this looks good to me. All right, the next one is 811 and this is again um this is not waiting on editor but I believe Sam you are one of the authors here so that's why it's pinging you to check 6880 Um yeah this looks fine.

>> Okay. Thank you Luke. >> Uh yeah because sometimes it is it requires author's permission as well. So yeah that is another the case. The next one is 1121. It is waiting on editors. A victor Sam anyone thinks it's fine. We should go ahead and merge it. In fact, we are collecting feedback if we do not merge it. Otherwise, they are good to be merged.

1121 also just typo. Yep, sounds good. 1122 is another one. So, these all are good. Good. Perfect. This is merge as well. Yeah. So these are all bunch of like typo fixes and the last one here is 10 011. This as an editor require permission Victor Sam anyone can approve it and it won't be merged.

Well, uh that brings us to the end of the all typo and miscellaneous issues and PR that we wanted to have uh reviewed by the editors and we can perhaps go back to the cool to the call for input. There are two call for inputs open here. Um Sam, if you would like to maybe give some overview of 389 and 390. >> Can do. Um all right. So for 389 um there's a proposal that is um encoding some data according to protocol buffers. Um and they call out protocol buffers by name but because of the

linking rules they can't hyperlink to it obviously. Um this is basically just asking whether or not we want to allow links to protobuff whether they're hyperlinks or just by mentioning it by name. Um, yeah, that that's pretty much for that one. Um, I'm I guess kind of slightly against it because it's not really a standards body. It's just a library and if we allow links to protocol buffers, we could also allow links to Open Zeppelin and a whole bunch of other things. So, um, yeah.

Yeah. Um then we have um >> 390. I think the link was uh pointing towards a wrong issue. I just have fixed it if you want to refresh it. >> Yeah. Uh 390 is um in relation to the recent problems on test nets. Um, somebody proposed adding a new section to EIP about chain specific considerations like what you need to like the section being like if something's different on a test net or if there's a special consideration that you have to have when you're starting the chain from Genesis like those kind of things. Um, yeah.

uh as I have already added the inclination for these two call for inputs. Um um for 389 one is abstain and one is in favor. For 390 both editors are uh opposing it but there are more editors I would kindly request editors and whoever is interested in this particular uh call for input. Please go ahead and leave your thought on the issue. So editors would be in a position to make appropriate decision about these call for inputs. We generally keep it open for about a month. So that's your time to respond to this and after that it will be closed and will be acted accordingly. Yes, Victor, please go ahead.

>> Yeah, I'd like to comment on the 389 about linking to protocol buffer. Um as uh Sam uh probably know that I always have been very uh advocative uh for en enabling and allowing links to uh to external resources. Um I think in general we should allow a links to resources and even uh that's like my general opinion. Uh the consensus that editors have is like they have to be stable uh uh for at least 10 years. uh and then I think protobuffer at least also uh match that requ criteria. Uh I personally like to even relax the

criteria a little bit more but uh I think based on the consensus of the rule uh I want to uh speak in strong favor for allowing linking to like uh long-term stable libraries. That's my that's a that's my statement. I'm done speaking. >> All right. Thank you, Victor, for sharing that. Um, I wonder if you would like to maybe add briefly. Uh, so at the time of making a decision, we could capture your thought though it is already recorded in this meeting, but it

would be nicer to have it added over there in couple of sentences if possible. Uh, you are speaking if you are still muted. I mean, we can't hear you again. >> Yeah, we can't hear you. >> Sorry. Are you talking to me? >> No, I'm I'm not muted. I'm good. >> Okay. Sorry. Yeah. No, I thought that you were saying something. We saw you unmuting but we were not able to hear anything from you. Uh just wanted to let Victor know that if you could add the comment that would be nice. Yeah.

Cool. Uh with that we are done with the first agenda item. Next is the community project. So uh because we are working towards EIP. We are receiving a request from community to extend their support some different platforms and toolings that they may have built in order to streamline the process with different suggestions and all. So for today we are joined by PSA. He uh suggest he is suggesting a platform that is designed to address critical pain points in the current EIP process. So I would like to invite uh PSA to maybe share his project and uh would love to hear feedbacks from others.

>> Hi everyone. Uh thanks for giving me mic. Um pleasure to be here. So I guess uh some of here maybe Sam knows me a little bit already from constantly crazy ideas posting on the Ethereum GitHub. Some of them are um background in my like security architecture at open zeppelin. Some more like ancient career of mine in telecom industry. Um but generally speaking when I joined the blockchain and I used to work more like in a radio electronics and like completely different field before I was very excited by the community and ability to basically collaborate across

borders in a some very big and permissionless system. Um so for me a lot of my work previously I worked a lot with the Dows and technology around that and um I mean like when I worked at open zeppelin before and currently we're also working a lot on the voting algorithms and researching like game theoretical aspects basically how to you know make all of the agents rationally aligned to collaborate on the one same blockchain technology worldwide. It's um to say like at least my bottom line for all of the work I do and generally trying to elevate that to the kind of like really global u adoption. I think today the blockchain is very well uh known but is

still very less adapted and one of the pain points I see as a developer who has a lot of ideas and a lot of struggles myself developing and trying really trying hard to build an applications on Ethereum which go beyond uh already existing things um is uh you know to just help improve the protocol from a vision And um and in that regard um we came up with this idea of uh bringing a portal which is specifically related uh to the um protocol improvements on the blockchain space in general and not

just for Ethereum and uh we are trying to so I'll post here a link uh but should I post a link here for the documents we have or generally speaking I think people here know the GitHub and they >> yeah please feel free to drop link and if you would like to share your screen to um like demo the project that is also >> sure sure Sure sure let's uh let's do that so I'll start by sharing the link so everyone has access for the big document we're proposing um so basically uh the um idea of ours is that we don't want to go for kind of grants support and trying to live off

public goods. That's generally the philosophy of uh PE Ramade Labs, Pyramid Labs, which uh is my company. Um so we've come up with this project as an idea for um as something more uh that can be sustainable uh in a way as uh maybe as something that would compete in a in some way of understanding with the discourse forum boards which is uh arguably today um or unarguably probably the leader of uh the um blockchain collaboration space I would say. So basically every system would

either have um forum board and ethereum has at least two I know which is already quite uh when I just joined the space it was quite a challenge to understand how they actually align there is a lack of understanding how it's all streamlined um and um also a lot of projects and Ethereum is leading here basically keep all of the EIP work in the um in uh repositories. So you would need to have a technical skills of using GitHub. You would be will need to have an account on GitHub at all to actually contribute to Ethereum. Um which is kind of like you're using like system which is owned by Microsoft like to some extent. Of

course I understand this how industry works. Um but it doesn't mean we should stay there. Um so um what we are proposing is basically to create a forum uh or um like streamlined system where the state machine of EIPs how they're being created how are being there actually requested um is also tied to things like um who are actually using Ethereum what do the users want. Um today the projects do not have things like you would probably have in regular products like NPS scores for Ethereum don't really exist because it's a decentralized system. So what we're

doing here I'm just like so I'll start just like going through the prototype you brought up. So it's a high level overview idea is that we could add here uh not just Ethereum but also rollups and other protocols uh because often times the standards are actually something that unites us together around problems. So like your C20 for example is very widely adapted and so on. uh we would want to add here uh AI like basically like vector database search engine so that you can easily get the information uh of all of the projects and uh that would be an aggregator where you can actually see the profiles of the

authors how they perform uh what is their impact on the protocols because it's one of the um important aspects I think of centralization So for example for me when I was doing this project it was quite actually surprisable that Vitalik is not the most successful uh PR creator on the EIP uh repositories. Um and that would be something interesting to show to community as well and uh explain that also people like Vitalic are getting rejected when they create the EIP and their protocol you know has a push back to authority.

However, there is also an influence course and uh basically you can you know see it like around different uh projects, different tracks. So who is more you know contributing to the so we can clearly see who is contributing to like roll up improvement core proposals. Um that statistics is actually a few months old. We just brought very simple prototypes. So it might be not up to date but I hope you grasp and be with me the whole idea. Uh obviously we can have like a breakdowns. Um so anticipating the question what centralization here means is basically we wanted to understand from all of the authors who actually create any EIP or ERC how many unique authors actually are

getting can get to the um living standard. Um that was very um like basic to the to the final rather like sorry um and that would be like our acceptance rate. Um and centralization would be basically uh what is the amount of the unique uh we have here um some explanations sorry have this so specialization would be like the authors uh with finalized proposals divided by total authors uh while accepting rates would be uh finalized divided by active proposals.

So that would be uh reducing the stagnant and withdrawn. Now for specifically Ethereum the idea is that for every portal we would bring up specific portal uh for every ecosystem we would have specific portal. So say ethereum dip.box which is basically right now is aggregator for all the IPs. Obviously you can search here for uh some um specific numbers.

Uh you can search by statuses. Uh it's just general like website and then the idea is that we would add here a robust state machine for actually creating new APs submitting them. uh we tried here to do this with GitHub but that would require actually Ethereum uh PMS to give us some app access because it's very complicated to do that um from um just regular like uh app token um basically we would have to fork everything and that's quite complicated um but yes so we would have like the um kind of like boiler plates and I've seen that puja you have a project which is actually doing something similar with uh

um you know this kind of easy start for the proposals but I think this idea goes much longer uh because we could add here specific uh voting uh specific maybe metrics uh what we right now trying to conceptualize is uh let's say doing the quarterly index of customer basically indexing how much gas was used by the users and letting them actually support and give us say a usage based on what standards they actually want to see or even issue an RFPs.

Um and if that portal is accepted by Ethereum then uh you know it could have with time add the discussions it's very it would it could be like very gradual process but it could significantly streamline and uh help understand how the EIP processes work and feel that um very formalized because right now if I created EIP and it's my recent experience uh I put that in a stage of review. Uh as an independent author my expectation is that for the review there is some timeline at which I will get feedback but then I just see that my EIP is being

moved to stagnant which is a surprise for me because I would expect there is some protocol for giving a feedback for the authors. Uh and this portal would could potentially have more like decentralized machine which actually pushes um the process forward and uh it can split. You know the ideas we have for a state machine is uh to basically uh do the quarterly or any kind of pace you want system where uh based on the when the quarter ends you know the drafts are moved the review processes are moved. So you could have

like this just in time streamlined process of actually just managing the whole Ethereum like PM part. I guess it could be helpful and I know that Puja we spoke with you on the DevCon briefly um that you would actually want to see this more streamlined and like understand when the when when the statuses changes uh um on the on standards. So we also think that you know being able to edit and actually um is so let's say if today I want to do some discussions or edit uh I have to basically do be do that on two different platforms I need to use GitHub I need to

know how to do the forks whether here you basically could uh create the edits and uh propose your div and then you could have different algorithms and also community engagement to actually discuss which ones do make sense and um yeah just connect it all to the larger like kind of like more decentralized concept you know try to hear the amount of usage from the customers and give them the weights to actually support issue RFPs streamline the state machine um and we are trying to talk not just Ethereum but other ecosystems to get them um use this and the concept would be that as I was

mentioning from the beginning we don't want to develop it as um um just you know a grants based project we rather want to do the business model same as this course does whether it's fully open source you can host it yourself u but then um we would be offering just these hostings and some AI enhancements where um um similar as this course uh basically business model. So just looking for a feedback here uh any thoughts uh we really want to contribute something useful to the Ethereum community and this one of the things which comes to our mind.

>> Thank you so much for this presentation here. Um I I have a few comments especially with respect to more discussion. I wanted to understand about the issue with the stagnant like is there a way where we can like get more attention to the proposal before moving it to stagnant because as per as per the present process a proposal is moved to stagnant if there is no activity for 6 months or more. Um so as an author of a proposal I I see clear distinguishment from draft

to you know being uh in review. So the draft thing uh early stage of proposal is something where we can discuss um and again like my main work and I can share it like uh actually is really strongly related to the voting algorithms right now and different round robin types of discussion using web 3 which I'm not touching here but basically the discussion stage and then I assume that there are high level hierarchy in this ecosystem even if I were I would want to have it like fully decentralized I respect that there is a hierarchy of experts in the

field who are established experts and I would want to have very like my expectation that there will be a feedback so if there is a six months of a it's not my six month in my understanding of responsibility to take an action on that standard because I already wrote it and I want to have strong community feedback telling No, we're rejecting that or uh you know what should I do? >> Yeah. Yeah, I can totally understand that from author's point of view. But just for uh people to know about it, um generally speaking, EIP standardization process, EIP or ERC standardization process is very much authored. We would want author to be around in order to

help make that as a standard. So um it's a general advice to anyone who is proposing proposal uh move ahead with draft and to review and continue moving forward with whatever is recommended to like add in the particular standard. If you will receive any objecting feedback you are advised to update your proposal. Otherwise if you are getting positive community support you can perhaps proceed towards final in the same flow. So yeah that's a general process.

>> Yeah. So yeah so for example the one which was uh pushed to stagnant is EIP7784 uh and that's related to the um making uh contract byte code hashes uh op code for getting contract uh bite code hashes uh and that would basically imply that the core developers of EI APS have to take a look on that. Um, let me check if the link is correct. If I told the correct number, yeah, it's the one, the get contract of code. And

that would basically require uh that standard to be put on the on some kind of review for core developers. And if I would be told that, you know, we'll we'll review that in one month or in two weeks, even though it's very challenging for me because sometimes those calls are like 2 am by night. And that's why I think it's very important to actually work on some kind of portal for that rather than relaying on the online calls because if you just try to do that with online calls, you're just cutting the half of the planet out of from actually being cap able to you know efficiently participate in that. Uh

because any high performer, high intellectual person in my opinion more or less will sleep at night. is just quite not sustainable. Uh and it requires in insane amount of dedication to just wake up 2 a.m. just to you know go for a call. Um which often like in my case it's not a direct profitability. It's um so it's not like part of my main work I be getting paid for basically. So um that said I I would say that at least like putting that on agenda is required and uh would be very appreciated and uh and then uh having

even a synchronous uh review feedback uh would be useful. So if there would be some pace of let's say that once the standard goes to the review stage there is like one quarter or is some stack uh of uh you know capacity of the reviewers so that like take first in you know first out system and they review as much as they can and uh and then the community prioritization this is what I see as very needed because I understand that core developers are overloaded their time is very uh precious and they need to understand how to prioritize and even though my standards might not seem

initially as a priority uh I I can see a lot of applications where it is a priority. So um and there is no like there is no mechanism today to actually like how do I prioritize that um outside of like just like technical calls or having personal relationship to all of the core developers. Yeah, I can understand this is sometimes be challenging when people are in not very good time zone for the ETH calls that happens. But uh generally speaking for all core proposals even if you are not able to make the call it is a good idea to share that core proposal uh to

the all core dev agenda and people can be discussed. I have noticed that there is a a new web page some something called as forecast.org or and I have also added it here. People are free to like rank their proposal, share their thoughts and things like that. So if you could um like work on the initial stuff just explain what the proposal is and bring it to any or all of agenda for other developers to to discuss this. I hope that would be helpful. >> But yeah, um I'm not sure if we can do much about the time zone. That is another problem. Yeah, I'm sorry. Uh if anyone else has any other comment to add about the project,

please feel free to add. Um I I suppose we can share these links in today's meeting notes. Uh so you so people can follow. If there is any other place where you could request for support, feel free to add the link and we'll be happy to share it with the community. >> Yeah. Um thank you for attention your time and just to repeat at the end uh so what we are trying to do here is to build something that is self- sustainable and if uh the AP editors would want to use our tool uh we would

basically look for um we would not look for much of financial support. We would rather want to make it self sustainable by productizing it and inviting more of the ecosystem and you know arbitral optimism zing you know all of them and just pulling that all together and actually fighting the fragmentation of blockchain standards which happens today. U thank you for your time >> and thank you for sharing this is definitely a good initiative as I can see it in the chat people have liked the tool. So yeah, we are hoping to get more feedbacks on that.

Very well with that we can perhaps move on to the next section which is uh other discussion and updates. For this one the first item um added here is request to add a label for typo. I mean this is my personal request. If we can get the label typo that would be very easy to filter out because you know we are receiving a lot of uh typo related PRs and the volume is all increasing. I wonder Sam if this is possible to add an additional level. >> Uh yeah it should be um it wouldn't be automatic though. um

somebody would have like the author would have to create it through uh a template that adds it. So I don't know how useful it would be. >> So we can perhaps create a template for all these kind of typo PRs even that would simplify the life as well. >> Yeah. Yeah. >> Okay. Let's see if if we can get that thing done because that is good. We can also ask people to make a PR to do that. I will also check with other teams if there are anyone any taker of it otherwise we we'll look for it. Thank you. Uh the next one is I I was hoping to have more editors on in here but um it seems like

some of the editors have uh dropped for another call and I don't know if you would be in a position to get a decision on the EIPS website uh uh which is already shared here. Sam I wonder if you got any async feedback on this and uh we do have something to share on like whether we are going with the new version yet. Uh I haven't had a chance to do any updates. Um it's really just a matter of uh getting the number of PRs down to something manageable. So >> okay then we can perhaps look into it in the following um call for API and see in between if we can help decrease maybe we

can come up with um another um call something like ERC blitz that we did a while ago to run it maybe. >> Yeah to catch up. Yeah that that would be helpful. I don't see anyone from the EIPS inside team but perhaps we can take a look at the link that is added here in the agenda and based on that uh I am uh looking at the uh website and it suggests that we have five new drafts in EIP, six new drafts in ERC.

We have moved four proposals to last call and uh two proposals to final in ERC section. We do not have much progress progress on RIP side. However, uh we have moved poor proposals to stagnant status on EIP side. So that's from the EIPS insight monthly data analytics. Other than that u we are also working towards as I mentioned decreasing the number of open pull requests. So we have increased our number of editing office hours. Now it's going to be weekly. So

the next week on Tuesday July 22nd at 1600 UTC it is with Gender Singh which would be for EIP only uh pull request. So authors if you have any PR which requires editor's attention or you don't know why it is stuck for a long time please feel free to join the call even if you are not able to make the call please drop the link in the agenda uh so we can discuss it with the editor. Apart from that I have also added list for the upcoming meetings. Meeting 67 will be EIP plus ERC with Victor and meeting 68 will be EIP only again with Matt Garnet. So we are trying to take

turns and address both set of GitHub repositories in order to decrease the number of available requests. So that's all about today's agenda. I wonder if anyone has anything else to bring up today or else we can wrap up a little bit earlier. Cool. Thank you. In that case, I think uh we are getting our uh 15 plus minutes back. Thank you everyone for joining us here. Thank you Sam. Thank you Victor.

Thank you PS Sky for sharing this project. Have a great rest of the day everyone. Yeah, [Music] moving on.

[Music] Heat. Heat. [Music] Heat. Hey, Heat. [Music] Oh. Oh. Oh.

[Music]