EIPIP Meeting 22

Transcript

welcome to eipip meeting 22. the first item on agenda is stronger rules for discussion url when you click the link that is coming from the uh issue that was created sometimes back by exec we wanted to pick up some of the other issues that are there in the eips ripple so the first one is a stronger rules for discussion so far we have been recommending um ethereum magician forum for discussion for any of the proposals but it's just a recommendation

do we have thoughts on should it be recommendation or should it be you know a little more stronger than recommendation i'm all in favor of it i'm happy to have it stronger than a recommendation i'm happy for your requirement i think there would be two questions related to it number one what is the ideal place for discussion tool and number two would be uh a strongest recommendation for that so are we on the same page about the uh discussion to

place that it has to be fellowship of ethereum magician that looks good to me but yeah yeah i mean that's my preference i think that having it available for people to use the issues is also okay that way if for some reason they don't want to create an account on another website they can use github which they already need to be having an account on i think that we could disallow ease research i think that that's not really the appropriate place for eip discussions anyways so i think that just a preference of the magicians but a requirement that it's either east magicians or the eip repository issue that's what i would say with the eip

repository issue the one downside that i see is like when the eip is merged it is generally recommended to close that issue but with it magician there is nothing as like you know closing the issue and that is open forever so how do we want to uh like you know uh what is suggested here is like you know we should be adding it to eip1 and you know adding a recommendation or maybe the stronger version of recommendation is it something that we would like to

create a pull request saying that the discussion took place is a fellowship of a theory magician or i would like that okay okay then we can add that as you know i mean i'm not sure if we should add that as you know one of the outcomes of this meeting today because we have less participants will mention it as what what the present group think and if there is no strong opposition then we'll try to create a pull request to

update that sounds reasonable yep sounds good okay the next item is handling retroactive changes um uh it is coming from the at one dot oh specs i think uh like client you have created an issue about that eip261 is the example cited here yeah i'm not sure if this is the right group to discuss this with but i'm but i say i'm curious to your thoughts even if it's not uh there is the cip

um the ip2681 i guess whatever yeah yeap2681 this is basically changing the transaction uh the validity requirements of a transaction retroactively up until we this was agreed on in the last all-court devs it was theoretically possible to have an account whose nonce is incredibly high something that could be represented in you know an arbitrary length integer and what was decided on the call is that we would have a stricter requirement and set a max max cap of for an account nods to be

two to two or sorry two to the 64 minus one so it's the highest that nodes can be and this is something that as of when this was decided upon last week and i assume it's still true today there are no accounts who are even close to that and so the decision was to make this happen retroactively meaning that we would just say this is actually how it always was from genesis that way we don't have to really include this in a fork it's it we're just saying that it's going to have always been thought of as true because there was nothing that invalidated it up until now i don't know what the correct way to handle this is in terms of documenting the change

because the ethereum you know improvement proposals this is that's kind of the document that describes ethereum but it's not the not exactly the the full specification but neither is this e1 specs repo it kind of seems like the yellow paper is is the main specification and so i i don't know if anyone has any thoughts or comments of what the appropriate method for documenting a change like this is yeah i think um i think uh this item we can bring it back when we have you know more people

i mean right set of people to answer this uh thing i mean it's coming from network upgrade uh repository so my thought was james presence would have helped you yeah that's what i figured too that sounds good yep uh moving on the next item is implementation section this is again coming up from the eip repo issue um it talks about like uh should be ha should we have implementation section in the eips i don't know if people have thoughts on it um i think micah is probably

the biggest proponent for making this not making eips not have the implementation section so it's kind of unfortunate to not discuss that with him um i like i probably are bore on the side of possibly having it i think there are some cases where it makes sense to have an implementation section in the cases where it's you know some sort of erc i think that those are the best cases for having an implementation section and the core changes were

the implementation section links to a change in a client i think those are the less good cases for it right i wish uh malka has joined the call but due to some outage power outage in his location he wouldn't be able to make the call today so let's move it to the next meeting i just heard from hudson also uh unfortunately he is also not able to make the meeting today i'm wondering should we continue with the rest of the items what do we have here is there anything we feel like we can

make decisive action on without hudson mica or james yeah just the next item eip repo cleanup that's the one i'm working on right right i was about to say that yeah the only update i have is uh let's see pull up my notes here um i've i'm trying to get a hold of um william entrekin because he's done some work and made some progress on this but i can't get him to respond so i'm also gonna try and contact um sam richards or josh stark i haven't done that yet but plan on reaching out to any of those and if anyone else has any information of who at the ethereum foundation or the ownership that

owns that website that might be able to help me or or give me access so we can try and make some improvements there if anyone has any more information anyway that's work in progress i'm continuing to work on that that's all i had so i believe uh you're talking about a single source of truth right right yeah there's right now there's uh eips.ethereum.org and there's also ethereum.org slash eips and they're sort of like copies of each other but we should have one or the other and william and tradekin has done some research and found one is by far used the most and so we're talking moving towards that one but anyway there's some other cleanup

that needs to be done but so yeah so i believe exec also had some uh thoughts on that about single source of truth for eip's repo and that we did earlier okay that's good i'll try and reach out to him too cool thanks okay so uh one another item is eip repo cleanup uh uh the uh intention behind adding this was like we were we were looking into proposals to you know kind of filter out which are in

draft which are in steel i know most of the eips have been if they are still they have been removed or marked still with the help of both but there are still some eips which are there for you know more than longer duration that it needs to be in the state of last call so would it be the right time to look into the proposals again and reach out to the authors what a general thought here i thought we were going to wait until i i guess do we have the the a well-defined uh set of states that uh the eip can be

be and i thought we were just waiting until we had that well-defined state then once we have that state then we're going to start start contacting all the authors to um see if we can push things along yeah that was the last decision made but now that we are we are having some clarity on statuses and that is already added in eip one sometimes backwards right right okay cool yeah so so in other words can we start contacting um eip authors again and start pushing things along that's my thought is but if people have different opinions yeah that'd be fun to start pushing forward with that matt if you may have any uh suggestions

or comment here i know i mean like the bot is working but if there is anything that can be done and would be helpful for the cleanup i think the best thing that can be done is to avoid commenting on repositories where the bot has marked them as stale in those cases if we mark if we comment then the timer resets and if the bot is going to clean that up we have to wait again three months or whatever the threshold is sort of ought to intervene so i would say if there are issues that you we want to comment on that haven't had the bot comment or someone else commented after the boss did and we wanted to comment and that's okay but if the bot has commented no one has

responded it's probably best to just leave those until applause does it automatically so in other words once the bots commented on them that's the final state and we want to leave them there or is there some state after that that we want to get him to yeah there's one more state after that well the bot i think makes two comments it marks something as stale meaning that it has not been interacted with for a period of time i forget what the exact time is and then uh maybe a week after that it will close it or two weeks or something like that it'll actually close the issue so if someone comments in that intermediate time it will reset the counter all the way back to zero okay so in other words but then once it's closed then it's closed and um that's the end and that's

the goal is it's cleaned up okay cool good to know thanks for that so one question i have i mean it's a kind of confusion even if it is closed on the github repo but the status won't change if it was already there in draft in eips.ethereum.org will it all right that's a good point that that is true that's something that i guess we will need to have manual intervention for now so i guess that yeah i think i was thinking maybe the bot does that but it does not yet do that it only closes the issue

so the things that are actually closed would need to be manually moved to the um whatever the preferred inactive stages abandoned or yeah yeah so how we started sometimes back was looking into that eips.ethereum.org and from there we picked up eips which are either in draft or last call or any other status but final we made a list of that and were trying to reach out to author asking if they would want to pursue this or not so even if most of the issues or pull requests have been closed by bot

marking them still if we find that something is still there in last call i think that can be a starting point for us to reach out to author yeah i agree so help it sounded like you were talking about just eips.ethereum.org as if that was different than ethereum.org eips what is i thought those were both built from the eip repository and deposited in those two locations via some build process but but are those different then is that is my understanding and correct as per my information the difference there

is uh uh ethereum.org slash eips does not list the eips which i mean what kind of what category of eip it is or what state it is only eips.ethereum.org list that oh okay i got i'll need to do some more research on that then thanks so i think that is one action item we can mark it on cat herders and we will restart working on it we have the sheet maybe we would want to clean up more the sheet and fresh it up and start working on it again

moving on the next item is eip status block slash document i guess edson is working on that document and he recently submitted a draft edson would you like to [Music] share and talk more about the talk you're on mute nits and if you're talking uh i'm not sure him we are not able to

hear him but i may have the draft let me share the link if people would like to give it a look or maybe leave some comment and feedback for that sure i shared the link in the chat so if people have thoughts and comment on the article we are planning to publish it on ethereum cathode is blocked this uh generally states about what are the current statuses that the group agreed upon it is already documented in eip1

just this explanation of uh how how we are moving along the process of standardization is this going to get published to the ethereum.org blog or is this only going to go on medium uh the plan is to put it on ethereum cat herders blog okay yeah i mean um because we have access to that only so if it is something that should be on a broader scale we can probably share it or i don't know if there is another suggestion for that or any other better place for it to be

published yeah i'm not sure what the right place is it just seems that you know chain large changes to the theory improvement process is you know a pretty big change in my opinion sounds good to me so i'm sorry i did not get it properly so where uh i mean would be the right place maybe on the github repo of ethereum dot spec uh i don't know about the ethereum specs repo i would say you know these changes are

already going into the eeps repository you know via eip1 where the change was made and so people who follow along there would see that this is happening so then it's a question of how do we announce it what are the right channels to announce it and i mean did you mention any ethereum.org blog i don't know sorry i just cut out perspective i was getting a phone call um i didn't hear what he said friends yeah you mentioned something about an ethereum.org blog yeah there i mean there's the ethereum.org blog where they post a lot

of you know things that the ethereum foundation is doing and that varies from you know updates of guests to informational posts about their research to their grants to protocol related stuff like you know the genesis of e2 these are things that they post and so i feel like this is in that kind of category of informational things about ethereum that they could post on and i don't know you know i don't know who the right person as they ask about that is probably james hancock would know if that would fit in yeah that's yeah if james hancock's the best one we should definitely look into that i think see if we can get

it posted there right so we will uh like hold the publishing it on the characteristic medium right now if people have feedback on it feel free to suggest and then i will check with james on this okay thank you thank you for that suggestion so who that that sounds like an action item to me should i do that or do you want to do that pooja or we should wait till we have james in the next meeting or i i think edson would be the right person to do that uh it's his blog so uh i'm not sure if he's uh unable to uh mention atm and talk here but i'll communicate it to him

okay cool thanks we'll mark it on as an action item to get in touch with james too okay okay so the last item from here is a review action item from previous meetings and uh yeah there are a few things so some decision makes an action item needed decision mates were funding for eip editors uh on that we had a small discussion in cat herders meeting um i would be reaching out to ethereum magician people to first

you know check with them if they are comfortable for editors funding because uh the idea was if this eip is very much close to the fellowship of ethereum magician people so let them have this funding uh thing for eip editors if at all we would like to pursue this idea and uh if not working then cat hurdlers can help out with the requesting of fund and distribution as required as needed but i think the the first step here would be to decide if we would like to go with this idea of funding how many editors are there and if they are actually interested in being funded maybe in one of the future meetings we

would like to bring up this as a discussion item like if we want to pursue that the next decision made in the last meeting was like client is now an editor congratulations and uh thank you very much nightlife for of offering your services are gonna data we were looking for more people to help out with yeah uh okay 21.3 states uh discuss issues from the network upgrade repository here we did try but in absence of sufficient people or the right set of people here we could not make any uh decision we would like to bring it up

again in the next meeting um the action needed was 21.1 contact nick johnson about the eip merch bot that was done oh it's done okay we can mark it as closed okay so that's all about it um so is nick johnson then volunteered to uh be someone that can make changes to the merge bot that we request and stuff like that i don't know i i need to re-look at the discussion that happened i think that the main outcome was just that we were sure we were you know

we figured out that for sure he is the one who was running it we figured out where it's located and he said that he could add someone to it so that they could restart it in the case that there were issues which was the main thing we were looking for but nobody really was it you know committing to making actual changes to it okay sounds good thanks did we lose someone hello anyone i'm here so did we lose pooja i'm sorry i'm talking

while i'm muted okay so i'm so sorry so i was uh i was saying that i want people to look at the project board that is there in this repository i'm sharing the link in the chat so when we started this group of eipip the intention was to improve the process as well as support the eip repository that is already there to clean it up to make the process streamlined and all these things we have made good progress here we have finished so many tasks that we started in the beginning of this year

um the group started in january 2020 and by the by the end of the year we made good progress so if people have suggestions what other tasks or action items we can consider for this group feel free to add here we are already working on eip repo cleanup there were two things i think is missing uh we sometimes back we talked about having a document i'm not sure if we have that document for eip editors right with rules and responsibilities did we miss it out somewhere okay i'll look into that i think it was

on somebody's action and we may have missed while carrying the meeting notes so that was there one important thing that i find here is define a process for reaching consensus on core eips is it worth putting in a future uh meeting agenda what would that involve in other words if there's a controversy or something like that or what would that involve my thought is general idea of like we do have a general process but the unclear part is like uh how do we reach on consensus like it happens in the all core dev meeting but um

uh i mean i come i came across uh this uh thing like for core proposals consensus are made in all code of meetings uh just one person or two person say i mean one client or two clients say it is there but there is no defined line so we want yeah that seems totally ambiguous and confusing and expecting people to browse through those notes and everything to try and find out what status everyone's on anyway my thinking is we need to have some definitive source where people can say if you're in if you are for this you sign this petition if you are against it you create an account anyway just in my opinion i think everyone knows my opinion on that but i think that would be a great

help if if we could say uh singles and and also you have to be able to jump camps if if you're not on board you need to be able to jump off and if you aren't on board jump on and track all that rigorously just my thoughts i i think as of now uh with the one dot or spec repo we are trying to get some clarity on that like if we look into the yellow v2 or v3 uh um document md file there we are trying to mention like which client is okay with what proposal or they are planning to implement it this may be good as per the core eips are mentioned there but

for some other eips like network eips networking eips we do not have that process so it never gets clear like if those eips are ever implemented in clients on if at all implemented what all clients have implemented or willing to implement i'm not sure if you would like to get clarity on these sections as well yeah that that's both of those things are critic it'd be great to just have a single source of proof uh have a process where everyone could know go to a single source and find out what is the current state-of-the-art state of that i'm afraid that this may not be the best group to tackle that

i think that this is something that it's unfortunate how the process currently is but you know it's really run by client teams and client teams sort of dictates what goes into the protocol what doesn't and i'm not sure that we can come up with a process for them the only way we could hope for a process is if we did it together with them and you know my experience of working with them is that they are really busy and they don't have time to mess with this sort of stuff right now right yeah but basically i'm just talking about a communication process where all of the um teams can like

communicate to everyone else what they are and are not implementing and who's on board and who's not on board and that kind of stuff yeah i mean i find this as you know an area of opportunity that can be the gap can be reached i understand that client teams may not have the kind of bandwidth to document these processes or how to do they think about it but if we get some senses of the decision making process possibly documenting them and sharing them with people in the form of blog as we are doing it for statuses of eips and others would be helpful but just a thought i guess i think that there are things

that we can tackle within the vip repository that is that we would be better suited for um and i mean those are things like trying to have more separation of concerns in terms of the types of eips that we have i know that mica wants to just totally remove erc type eips from the repository and see i think these are things issues that we could really make progress on i'm afraid that we would spin our wheels a lot and i would have to discuss exactly what we want to do in terms of understanding how you know the network upgrade process works and to actually write those documents but you know my experience in being a

part of some of those conversations is that it's incredibly opaque and trying to write a blog post it's going to be hard because there's not much there's not really a great there's not really a process that's followed it's more just constant discussions and a lot of those discussions happen privately within the guest team things that we aren't privileged to anyways and then the results of those conversations are the sorts of things that we see bubble up on all core devs so i don't know i don't know i don't know if that's the best place to spend time working i think there are other things that we could do yeah i think i'm getting there we don't have to mess with the current process i get that part i mean we could use the time to get some uh some areas where we can be actually

uh helpful so i mean i would love for uh you know i would love it if we could help make the network upgrade process less opaque and i feel like you know six months ago that was something that i also felt strongly about this berlin hard fork a lot you know a lot more with the eip i've been helping champion with micah i just realized that this is a really complicated process and there isn't a process that's really followed and we just see that weekend or you know every all core devs whenever we try and decide on something we'll circle around for an hour and come kind of back to the same point

there's no rhyme or reason it's just everybody's trying to do the best that they can to think about what's the best to the network so so it sounds like to me you're talking about exactly there should be a petition of what someone wants to do and everyone that agrees with that could sign that petition and that could be a dynamic petition and if anyone disagrees they could create a competing camp and say i don't like that for x y z and people just and you measure and so you can really track who's on board with what and who's not on board and why and what requires to get everyone on board and track that in real time in a dynamic petition system i mean that's essentially what's

happening right now in all core devs and on discord it's just we don't have the formalization of these petitions and i don't think that that's something that the core does are going to be amenable to in the near future i think they feel you know incredibly overwhelmed with the amount of things that need to happen to the theorem protocol and they don't want to go through add additional um bureaucracy to decisions that are already very hard for them no no no no the problem is is now they spend hours and hours going hashing over and over and over and no one knows any of the decisions made i'm saying reduce all that work and just make a concise statement on a petition say i'm for doing this who is and isn't

on that and it seems like to me that would reduce everyone's work and communication would all be natural anyway just a thought yeah i mean you know on paper that sounds amazing and it sounds like it will reduce things but the problem is that i think some of the things that are being discussed it's not easy to synthesize into a petition you know the great example is just the work that we've been doing on type transactions the questions that have been coming up are things that we didn't think about at the previous meeting they were things that just you know continue to come up during the implementation phase and that's why i'm talking about a dynamic petition that constantly changes and improves because

you have a petition so you can submit a change in a wiki kind of a way and then everyone that is supporting gets notified of those changes and if no one objects within 24 hours it goes live and you can assume unanimous consensus and that way you can track who is and isn't on board in real time and it becomes easy and the and and and and so you constantly change that petition trying in other words you do negotiation for the people that aren't on board and say well if we made this change to the petition would that get you on board and and then you submit that to the petition and if no one objects then you can assume that everyone that has signed it still agrees with that change so so it's not just a static petition it's

a dynamic petition yeah i mean i i hear you're saying i think that sort of happens informally by a discussion on discord and the number of people that are involved in those discussions are small enough that people generally just have an idea of who's on board and who's not on board yeah it needs to be able to scale so thousands of people can be involved in the process the thing is i don't think that thousands of people will i don't know if they'll ever be in in this process i think that this is a process that will always be limited to sub 100 people and i'm not saying it is a scalable i'm not saying this is scalable as it is there are things

that should be done to improve the system um it's you know i just don't know if yeah i don't know what the right way to go about that is and i don't think that we can really go about it without enfranchising more of the core developers in the work there's no way that we can just impose something upon them and say here's this great process we've come up with on our own it has to be something they really want to take the lead on and i don't think at this point that they do once want that that makes sense yeah to me it it takes someone who wants to do something like violate the state of the chain that critically needs to be done that's a hard decision and if someone wants to do it they can start a petition say i want to do this

and then people can start getting on board say yes i want to do that and start building consensus and and so it's a tool for someone that wants to do something to make it change that's primarily what it is so if someone right now i'm it seems frustrating to me because especially violating changing the the state of the blockchain everyone's just afraid to touch that because they're going to cause a fork and no one wants to go there but if we can't do that ethereum's going to be stuck in the mud and if someone wants to champion a petition we need to find out a way to formalize that and make that so that we can make those kind of decisions on large scales so i just wanted to uh you know get

people's attention to the project board to mention that we made good progress uh now if we want to take some more tasks that can be added here so that's i think that's that covers all four items that were discussed if anyone has anything um we could not address some of the items today we would like to bring it back to the next meeting i have two questions the first one is you know regarding sort of the i guess the project board

but also just higher level what the this group's goals are and i guess i was wondering is this a group that expects to carry on in perpetuity are there always things that you think that there that will need to be done or the script needs to handle or is there kind of an end goal that this group wants to get to that says okay we've achieved what we've wanted to achieve and now we're complete i mean yeah i think there's there's two steps number one we want to redefine the process so we have a clear defined process then what then that's the primary goal but then once that done my goal is is to participate in an ongoing basis maybe not as it is as busy as we have

been but to constantly be working on cleaning up eips and reporting back and say what have we and have we not accomplished and what eips can be cleaned up and coordinating who's going to try and clean up what i eip to me that's i thought was a long term effort yeah i mean my thought process is also very close to what brent just explained like the idea of having this group was to get the process uh you know improved and uh if we started with eips because that was the area which needed most attention and that's how we renamed this group as eip eip but if in the process we find that there are certain other areas where help can

be provided it's it's good it's okay we would be happy to do that yeah i think that one thing that is sort of eap tangential that this group could really help a lot on that i think would be very helpful is to create a specification for eth1 in the same vein as the e2 specification because right now in my mind that's one of the biggest missing pieces of you know understanding standards in ethereum and understanding the protocol is that there isn't no good single source for information and if this group could help facilitate

someone to to build that i think that would be incredibly useful in both the aspect of improving how standards are written and understood and improving how things are discussed in terms of network upgrades and the protocol itself yeah that sounds good i think we can start thinking over it as well i mean like i like the idea and um now that we are moving ahead we should consider all these sessions where it can be provided and makes things better for community to reach out to

sounds good see the one other thing was is that and i know edson's not here now but i think he was the one who was leading the effort on building some resources to onboard eip editors and so i'm still willing to go through that to give feedback on it yeah i think i mentioned that we missed it somehow in the process i mean like in in from the meeting notes it's where it was missing but i'll talk to edson about it and we'll try to bring it in the next api meeting okay okay so i think that's it for today if anybody has any other question

or anything so the next meeting is in two weeks december 16. um thank you everyone for joining i hope that we have uh more people to make a decision on the items that we missed today see you all in next two weeks thank you thank you oh