Pooja all right I think I just have shared agenda in chat welcome to eipip meeting 59 this looks like a small agenda for today's meeting the first item that is added here is clarify how to use erc versus eip to refer to different eips this has been collected by tim baker's comment on the last meeting agenda so yeah we have been discussing about this thing like we see that people are sometimes referring it as erc and sometimes referring it as eip is there any standard guideline that editors here would like to share it with the rest of the community to maybe follow
Micah: so for the community I don't particularly care for the eaps repo we always use eip never erc
Pooja: so for eip repo I have this question that I i'm not sure I think I would like to clarify it for myself as well like many times when we are referring to any erc category proposal in another eip we have tried to fix this in eip1 that it has to be referred as eip even if it is an erc for example eip20 instead of erc20 but what are the guidelines for an author if they are trying to refer to an erc category eip in their proposal
Micah: so they should put the only place that the erc would go is in the header field when it's asking for the category of a standard track eip and so you just put erc there everywhere else though in the ipsl if you're referring to other eips if you're linking they should all be eip
Lightclient: erc has sort of been used a lot by the community and it's kind of difficult now to say if you want to refer to erc20 it's now eip20 I think that just a lot more talking about in the documents or just like in conversation I mean we can't really control people doing conversation but I think that it just adds confusion if like in an already confusing process if now these things that they talk about and that is published in every place that it's erc 721 years t20 yeah erc1155 and now all of a sudden they're only eips and so it's just like people start questioning like why is this the case and I just don't it's just it seems a little unnecessary
Micah: are you lobbying to change changes so when people refer to an ea erc within the eaps repo they now do erc dash number number number and then the link is
Lightclient: I mean now like that's the how it was for a long time even though it wasn't encoded in eip1 I think we only started enforcing it pretty recently like most historical eeps refer to other ercs as that prefix erc
Micah: so I don't feel strongly about this if people have a strong opinion on wanting to have the erc instead of eip i'm fine with it but we should definitely update the rules if that's the case do we want to name the eip's erc dash number number number or keep them eip
Lightclient: oh I mean yeah that would make sense but lord I don't know what things that'll break that's kind of hard to do at this point too because people have links to the github so now we break that
Micah: does anyone feel strongly about keeping the eip naming convention or does everybody don't care or
Pooja actually I am in favor of keeping it eip because you know this is an opportunity that we can probably take it to educate people that eips and ercs are not different erc is a category but it's not a type individually that is as good as any other eip like networking interface and code definitely the process can be a little different the application can be different but that is part of ethereum repository and that has been forever eip 20 people started calling it for their convenience but still the repository calls at eip20 and at the time when it was listed it was listed as eip20 it was verbose that they started calling it erc so if we cannot control what people would like to say let it be erc but for documentation purposes if we start mentioning it as eip maybe in long run people will learn about the process and come around because at this point what I feel that changing eip eip22 erc20 on github repository would be a big deal we have to write a bot altogether to change this process to get it renamed based on the category until we find that this is my feeling i'm like more inclined towards it but again i'm not an eiv editor so i'll leave it on the grid do we see do we see a hope of getting eip written as erc on the naming as in header i'm talking about in future listen what
Micah: so the making things show up differently on ethereum.org isn't too hard this requires a little bit of engineering elbow grease to tell jekyll to do the right transformation when it's compiling however github dot com slash ethereum eips that one is significantly harder because people do link to that and that one we do not have control over redirects
Tim: so what do people link to when you so when you change a file like file name in github I guess it'll break the path right
Micah: yeah so relative we tell everybody to use relative length and eips meaning dot slash vip that way it doesn't matter what rendering system we use like it renders in github markdown and it renders any ips.here.org and it renders on random third-party sites that mirror yeah yeah yeah okay so I think renaming files is problematic at best yeah good sorry go ahead so renaming files is problematic and I would advise against that just because it's gonna be a huge amount of work and pain to do so but I don't really have a problem with changing our rules on how people title their links so right now we tell them your link must be named eip-120 i'm fine telling them you can name it erc-20 but it's still going to link to eip-20.md
Tim: yeah I think I think that makes sense I think like changing all the links and whatnot this is like a huge waste of time and like no one's died that erc20 is eip 20. I feel like if it's easy to change also the title like not if that doesn't break the bot right like it's kind of neat if like it could link to if the title could be like erc20 but not a strong opinion there I would I would definitely not take on like technical debt of any kind to make this work though or I guess so like the the h1 header like the the first thing in the markdown file can that be called like erc20 without breaking I wouldn't by the way I would I think it would be weird to change it for each dollar final so like I think it would be like a going forward thing like or anything that's in draft or review I guess it would be weird to now change the ip20 but like if if I have a new eip can I just title it ercx
Micah: so I mean maybe i'm generally apprehensive about leaving the repository in a half and half state if we can avoid it I would want I would ideally like to hear a pretty compelling argument for why this will have a very significant positive impact in order to support having like half of the eips be yet erc dash and half of them be eip dash that feels like it would add a lot of confusion
Pooja: yeah because if we look at the broader structure the structure is there are three different types one is a meta one is a standard and the third one is informational and under standard we have four different categories code networking interface and erc so let's be I mean if we are planning to change it will altogether affect the entire hierarchy how it has been defined in the first place and if I understand correct changing eip dash 20 token standard that is something that is coming automatically with the with the bot for all eips irrespective of category and type and that is going to be a tedious job to change it especially for erc category at this point of time and i'm not sure how much benefit do we get after changing this so the question I think I was trying to ask here that micah has very well put it into the chat that what do we want people to be referring it to erc20 which will end up as eip20.md or do we want it to be written as eip20 that will again end up as eip 20 dot md so in in in communication if people are using erc that that is not that we can control but as a group who are trying to improve the process what we can control is the documentation part so from this group it will be interesting to understand what do people think about the recommended documentation terms here like should it be erc20 or should I should it be ap20 I mean we can definitely allow both but having a standard would be nice to have
Micah: it sounds like people want the link titles to be erc20 i'm like and I as I mentioned i'm okay with them that's what people want just need that ddap one
Pooja: cool so sam votes for eip right okay maybe this is something that yeah please go ahead
Micah when someone who wants to make this change to ef one make the change we can discuss further on the pr so submit a pr that's to change the docs to say if you're linking to an erc use the erc title thinking ap use ap title and then we can continue formulating arguments in that thread
Pooja: that makes sense that's exactly what I was trying to propose here what I can do I will create an issue and I will try to put it over there so we can collect feedback from all other eip editors who are not present on this call and maybe if community want to participate we can also get their feedback so the question that i'm gonna put it over there like how do we want to refer to an eip in the documentation part especially we are not controlling how people want to communicate any final comment before we move on to the next topic cool so the next item listed here is a meta eip for executable spec process for core eips if I remember correctly in the last meeting we discussed about that we would be moving ahead with whatever was proposed as executable specs for corey ib's process i'm not sure if either tim sam you got got time to maybe come up with a meta eip wondering if there are any updates on that side there is
Tim: but I don't think it's quite final so I sent something to sam last week I haven't even thought about it since before I saw this called my agenda so I basically sam had a proposal a proposal scouter proposal I sent like a counter counter proposal and basically it's quite close to like what sam had the there's two changes I guess one is it it proposes two paths either we keep eip as the place to write the english stuff or we or or sam's approach which was we don't do that so it kind of shows what the process would would look like on both sides with like some pros and cons that that's the bit hopefully sam can also like unbias a bit more and I think that's like the biggest question that's probably like probably something we just want to get client devs input on and then like whatever they choose it probably makes sense there and then the other the other smaller change is that sam's proposal would have new eips the branch the branch name would be like eips slash the actual eip number slash a fork that it was targeting I propose that we don't have like a target fork on an eip when it gets proposed because if you imagine something like take 3074 for example you first propose it I don't know for like berlin then london then shanghai and it's weird you would just want to have like a single branch that tracks this proposal rather than having like eep slash of 3074 slash berlin and then e 3074 slash london and and so on it seems a bit weird so it seems like it's just a bit cleaner to like have eep slash the number and then like it's up to the eip champion to rebase their branch off like if master or whatever the fork is if they want to then keep putting it forward and I think that kind of matches like the current eip process like if you have a change and it doesn't go in a hard fork and then some changes happen in this hard fork that affect your eip then we expect people to update their eip they don't necessarily like create the new eip and they would create a new eip in the case where like the changes are so significant that like it's it doesn't make sense anymore and I feel like this this could work here too so yeah basically just changes that and proposes a world where like we do keep we we do keep the each repo for naming and non-uh specification descriptions and I think yeah sorry oh and after this I think if we have like rough agreement here like I would be up I don't know if there's going to be time on the next soccer devs we've been we've been running out of time quite frequently but I think in the next chord f call or two it just might be good to take five minutes to like ask for feedback about that and I guess not only from el devs like also from cl devs because yeah this would obviously affect if they you know if they need to actually write eips or whatnot
Pooja: I feel that would be a good idea maybe first we can have the draft of the meta meta with the changes that you just mentioned I can see that in the hack md file it is there I believe right you have mentioned that yeah I think
Tim: yeah we do need to resolve like do we keep the eip repo or not because it's like it would be a very weird draft now because it's basically it's almost like it'd have to be two different proposals and i'd rather we just get clear feedback from client devs and we we can narrow it down to one and and like yeah refine that spec
LIghtclient: does it really affect client devs where the eips live like is that something they even have an opinion on
Tim: I don't know if it will affect I mean first they do write a lot of vips so like to that level of effect I think they might have opinions about like I don't know like even if they're not directly affected like what's better I don't write the I don't write the ips I have a strong opinion about what's better so but I yeah I don't know maybe not having an opinion is unrelated to whether it affects you or not right but I guess kai devs are like the main stakeholders of like the core eip process I guess
Pooja: if the question is like whether we need an eip repo or not I feel like either I mean like irrespective of the answer yes or no they would need a place where they can start making pull requests and eipd will be there will be there for other proposals so maybe core eip people will not be using that but again I feel like I mean it's my personal feeling that having it somewhere place if not the eip if creating a separate repo for that that would be important to note
tim: oh yes yes I think sam and I agree that there needs to be like a description basically all the stuff that's in the core eip still needs to happen and the question is do we still call those core eips and have them in the eip repos or do we just put them coupled in the execution executable specs repo and that's that's basically the question and just for the record for those who are new i'm strongly in favor of keeping everything in the executable specs repo not splitting one oh sorry good
sam: so you said not splitting as in putting core like erc's in the execution specs repository or yeah do you not give me not putting the implementation from the documentation yeah no let's put the documentation for the invitation I think I should live in the same place which I think should be this specs repo
tim: I think that yeah my opinion for the eips is just like it's such a strong like there's such a strong like community awareness around it like I mean other blockchains literally call their stuff like erc20 and eip1559 and like yeah it's is young enough and if we are successful it will last long enough that we should be making long-term decisions not beholden to history and like our reasoning should be what do we want things to look like in 20 years not what I still want us to have the eip thing like I like that they're called like ethereum improvement proposals I think like clip or like elip that's just like really I don't know
Pooja: I can maybe I can maybe propose a metal path here I think it is inspired by tim's earlier thought even I am in like I find it good when people find these proposals because it's become way easier to communicate it with community and get feedback on just one individual topic that we want to share about just like one five five nine maybe what we can do is like earlier we used to have meta eip for upgrades right and it was like all together their meta eip but we started bringing them together in upgrade dot md and we keep that in executive execution specs repository if people like the group decides to not use current eip repository for future core proposals when it is finalized we can maybe create a dot md file of that and bring it to the repository for people to refer to what do people think about it I mean like not until it is finalized but once it is finalized then we bring it here
Tim: yeah the problem is you talk about it most when it's not final right like and and the other thing the other big challenge with this stuff is eips that span both the el and cl it's really nice to have a single name to talk about it like for example take like eip4844 we're gonna have like talked about it for a year before it goes live at least and it's almost like after that it doesn't really matter because like it's live it's part of ethereum and and yeah and it's like 90 of the discussion happens like before the thing goes live but anyways I don't want to take up this entire call to like go on the pros and cons I do think it would be good I don't know if you if anyone can edit this note i've given sam edit access but I think like if we could have like if people want to help with the pros and cons list at the end that's probably a good thing that we can just then share with like client devs and get some more feedback there [Music] yeah and I don't know how we make the decision when if there's two if there's like strong disagreement within the client devs as well I don't know how we make the decision but at least we'll know that there's strong disagreement there
Pooja okay if we have to summarize it for note taking people at this point like just from the present participants we are agreeing like to move the specs directly to the executable spec and not be a part of present eip depository is that a correct summary tim
Tim: yeah I think I think we all agreed previously that that was the best direction and then the question is how do we actually do that and I don't know I guess does anyone disagree that asking client devs once we've like spent a bit more time on this talk is the right next step I think it is a reasonable next step at least worse yeah so I think the thing that i'm just concerned about is that it's one of these things that asking more people I don't think is going to bring us clarity and so i'm not against I swear people and I want more people to be involved and i'm a fan of all that but I don't think that's actually going to help us come to a conclusion I am pretty confident that you're going to end up with some core devs being passionately on one side some passionate other side and some kind of don't really care and somewhere in the middle and so it would be nice if we could come up with like a plan for how we make a decision under the assumption that the core devs aren't going to magically solve this for us if you can solve that you've solved a lot of ethereum governance issues yeah [Laughter] you let me know yeah I i agree yeah but I think it's probably worthwhile to actually go through that step and then have at least a little more information when you you need to sort through it and if the general feeling from the courthouse is like we don't care then I guess we make a decision here and one concern I have with going to the core devs is that I don't think that there's consensus on even you you know similar opinions to greg's are gonna be like some of the courthouses are gonna express that and I i I don't think adding more people to the mix is going to help at all so okay so yeah and so are you saying like we should i'm not i'm not saying anything really i'm just saying I think I i I don't think we're gonna get more consensus out of this
Lightclient: I think yeah I i i'm on the fence yeah I think when I don't know that I don't think we'll get more consensus we'll get maybe more information yeah but I i agree it might not be consensus
Tim: I i agree that moving to towards the acd meeting would be the right next step but as sam's concerned I have the similar concern and I would prefer reaching out to them when we have a draft of like meta e proposing like this is our proposal the question should be like okay this is what we are proposing and the question should not go back to whether we should do this or not in the first place so until we have that like draft form of meta e we can probably hold reaching them this is a good point that if we show up with a complete plan I think we're more likely to get buy-in and consensus rapidly than if you show up asking questions what do you guys think we should do you show up we want to do this is anyone opposed I think you're more likely to get positive feedback than we'd like to change some things what do you guys think we should change et cetera you see I don't know i'm not convinced but I i can be but yeah I guess because this is like a big change it's like if I i think it's like worse to come in there and be like okay we're just gonna like stop using corey ips rather than saying like we want to do an executable spec and there's like pretty general I think consensus across that like sure some people disagree but it feels to me like it's more of like an a while back but then it's like saying okay we want to do that do like I don't know I feel like it's a reasonable question to ask like are you guys okay removing like stop not using corey ips anymore or are you not
Pooja: wondering if that can be solved with weight attempts your tweet gets more responses no I would not I would not go to twitter to solve this it's too specific I think
tim: yeah no and yeah and I think some of the like I think you know the the best feedback I remember from the last discussion was when martin said that like a bunch of core eips are underspecified and this spec actually forces people to literally specify code what they want and like I think it's like yeah the quality of the feedback you get like to me that that was like if I was on defense that was the thing that I was like okay if we solve this problem for martin like the executable spec will have been worth it and there's not really a strong counter argument so maybe my hope is like by having this conversation on aqua devs there's something of that vein with regards to like eips versus not that that comes out and then it's just like a no-brainer but maybe that's too optimistic I know it seems like i'm the only person who wants to discuss this on the call so I don't want to like force a discussion either okay so maybe we can give another eipip meeting to discuss this further before we reach out to acd yeah I think that's all right especially if I don't know if people think that in the next couple weeks they might look at this proposal and like leave some comments or changes I think it's yeah it's totally fine to wait two more weeks okay yeah that makes sense maybe we'll try to like share more of this hackmd file to people and try to collect more feedback on that
Pooja: cool i'll i'll try to bring this in the next meeting moving on to item number three that is eap bots related discussion I don't see jose on the call but it looks like jose got stuck somewhere in testing part and he is having hard time creating the testing environment for some of the issues that he is proposing solution to and also I haven't heard from the from the guy on the eipv side I wonder like is there anyone else or is there anything that foundation can maybe help out with *
Tim:* i'm sorry yeah you're asking if there's work to be done yes i'm asking if we can get more resources for this because I haven't seen any progress on eipv issue from this resource the foundation site okay let me try to rephrase my question so I wanted to check if we can get some help or some support from nhdev who is maybe available to help out with bot eip part presenter but to solve issues there are a lot of open issues and pull requests as well but the resource from categories who was working on the improving the bot he is stuck with the testing environment and he is looking for some help so this is on the typescript bot right that's right okay so I can't help with that I have no idea how to set up typescript environments if somebody's working on eipv I could probably help with that I don't know if anybody else does typescript but yeah for eipv if I remember correctly we had someone join in a few weeks ago and we were hoping to get some updates i'm i'm not sure I did not received any feedback and I haven't seen any improvement there so maybe we will try to reach out to them again and if not then if someone from the community is willing to look into the eapv path issues please reach us so some for the typescript bot is it okay that i
Pooja: I recommend that resource to reach out to you for help whatever is needed no absolutely not I can't I can't I can't help but type script I don't know about it okay sorry then I got it wrong my bad we'll see if we get any further update in the next meeting let's move on
Pooja: the next one is eips insight I see a lot of improvement this month there are a lot of activities in june we received three networking eips as final eip and one erc category proposal has been moved to final in addition to that there are nine eips in draft that have been added new and one eip in informational category has been added as a living status so this would be the second living eip after eip1 because eip1 was the only living eip so far there are some small changes to not some there is just one minor change to eip 681 which was a final eip we received a new eip editor so we are now five eap editors so things are moving smoothly and we are having less issues and pull requests for review there are a few graphs and charts and more information available on eips inside so please check out the link added or details on it I earlier mentioned in one of the meetings that i'm also planning to have a separate website where we can have these charts and graphs directly getting it from the github repository I remember mika mentioning that instead of going ahead with api we should may be able to create bot I just wanted to provide some update on that side mica it seems like we are having some trouble creating bot right away so at the moment what we are trying to do is parse data directly from the eips dot md file from there and collect values to share different charts that would be more than what is currently being shown in this hack empty file so yeah with a check md file eips.md on github repository eibs github repository so that's that's the approach that we are currently taking like collecting data directly from there and creating a temporary database to store data on everyday basis we are still working on how to automate the entire process we are working towards it and i'll be reaching out to the group and yeah it is if there are any help needed on that side just wanted to provide this update
Pooja: moving on to eip's editor apprenticeship meeting we had meeting number 20 yesterday the recording is now available now we are trying to look into the proposals all especially erc category proposal because we have been receiving a lot of requests from erc authors that they need help so if any author is new and they want to discuss anything in a specific you are welcome to join the eip editors apprenticeship meeting and share the questions with the eip editors the next meeting will be two weeks on tuesday
Pooja: item number six is review action item from the previous meeting contributors permission to eip github for sam stop trying to give me that okay fine then I can then I can probably remove this because even I am not able to get to my resource I haven't heard back from him in past one month because it's been over two to eipip meetings and I did not receive any response from there so I wonder like anyone from the foundation I don't know they would be able to help out with any of the future needs for that so maybe tim and now like client if if you guys have any reach on devops site for future help maybe we can use that but sam if you are fine with that I can remove this thing anyway I haven't received oh please yeah I absolutely don't want contributor status okay next is which I will collect feedback regarding one-time nft sale of unused eip numbers unfortunately I could not collect feedback although I have seen that the issue that is created on eips github repository has received a lot of comment maybe I will try to maybe tweet about it and collect more feedbacks but I will get back on this item next meeting third is samus and timbeko will create a meta e for executable specs we just discussed about the process so I will get back to this item next week I mean next meeting remaining eap editors to give their view on using executable specs in eap process obviously we are in process of collecting feedback from community from api editors and all core dev developers so we'll try to get back on this one in the next video that's all those are listed here on agenda anything else that anyone would like to bring up thanks sam I see your comment I have eips dot fyi that's nice name okay thank you definitely will look into it any final question comment for today if we have extra time we can continue discussing executable spec I do feel like we need to come to a conclusion on that
Micah: I have a pros and cons list in my doc if you want to go over that but sure I will tell you why all your cons are frozen all your pros are cons sure you want me to share my screen or do you want to just pull it up I have it pulled up okay cool walk me through it where should they skip to in this dock literally the bottom the last section is their pros and cons assuming this is like the main point of contention it's like do we keep the ip repo but okay so you want to keep the eaps repo and just to make sure I
Pooja: understand your position your reasoning is is you like the the meme value of it and i'm not using that pejoratively yeah yeah meme yes yeah mean value and then yeah the two strongest ones are like mean value and you can use the same number to describe a change across el and cl so you don't have like el1234 and cl4567 mapping to the same feature in a way like say beacon chain withdrawals or like eip484 so I feel like the latter problem we could solve without using the efp's recall like we can have a number selection mechanism and when that number pool is both cl and el and for any given number you may only have an el part or only a sale part or you may have both parts but that's all yes yeah so then you need and that's like that's half the problem but that's also half the burden of keeping the eip repo is aligning numbers across different repos so if so the we need a a number selection system and that could just be you know create an issue in github and let them use their auto incrementing number for it or we can have a website that you click a button and it will just give you a number like there are a bunch of ways we can get numbers and so I feel like let's ignore that half the problem for now because I feel like that's solvable in many many ways let's focus on the first part which is I think the where the real content point extension lies so I guess in in my mind I don't and maybe you can convince me otherwise with this I don't see huge value in ethereum changes being memeable like like rfcs are useful not because they mean well but they're useful because they specify useful things that are useful to people and I don't see yeah you help me understand why do you think yeah yeah yeah why are they injured why do we want yes so so for example like look at the altair hard fork right they don't have like any numbers or whatever and it's really hard to describe to people what happened in the altair hard fork so I think like having individually assigned numbers to changes make it easy to say like you know change one two three four is a gas cost change or this is like the change to the validated reward curve so that's like and that's like the first degree of meme ability if you want right where it's like because then otherwise it's just like people who are very deep in the weeds who discuss like these pr's on github and like there's no yeah there's no thing to hatch onto and I think I think I think that's bad yeah I think that will be solved regardless yeah I agree with you on on this point having a a short name whether that's a number or a randomly generated word I think anything is fine as long as you have something that's short and concise and you can refer to it by that thing you know like I mean github has like auto repo names for example or just generate a single or a double word we could do that we could do numbers i'm okay with any of those and I agree with you on this point but I think that's cool and then the question is like why is eip the right name right like and I think there first you know ethereum improvement proposal kind of works with what we're trying to do here and I think there's yeah I think like if from the outside you would want the process to like be as close as possible on the execution and consensus layer because that's like that's ethereum right like
Micah: i'm a bit i'm a bit like uneasy with splitting things too much there and so it feels like calling it an eip just aligns those two process better and it also you know the community knows what it is and like you know the community like it's been like a year year and a half now and like the elcl names are still quite hard have to place I i have half the the people still use e2 and obviously over time that'll change but I i think like I think it's better to call them all ethereum improvement proposals than to call them oh this is like el abcd and cl like xyz like it's just like a it it compartmentalizes them to an extent that I don't think is is good and and hopefully in the future it's like we want like the modularity at the software level but I guess it's just I just think it's wrong to like expose this at like the the user slash community level from their perspective it should be like eip4844 and like it reduces you know the the fees for l2s but then like implementers can deal with eip 484 on either side I don't I don't actually care where the where the text is stored so I would be fine I would be fine in a world where we actually just store the text in the eips repo one thing that's a bit weird technically there with sam's proposal though is the text only gets stored in branches and I think that's probably wrong like you don't want the actual text to just be stored in branches rather than master but that's not right I think that's a good one I think in right but most eips most cips are drafts right sure but I think that it's appropriate to store it in a branch if it remains a draft never makes it forward but you want a way to render that and again these are not like impossible problems but like I think it's I think there's value in having like eeps.ethereum.org and and if we change it from core to el and cl or whatever even that doesn't work though actually because this is the other thing that doesn't work it's like if you make a list you want 4844 to be like a thing and then point to the implementation details on both sides and like client devs have asked for that in the past like when we were when we're like discussing withdrawals for example they don't just want to see like withdrawals on the cl withdrawals on the el they want to see okay what happens at like this higher level of like you know this this is what like the cl is doing and then the el gets this and then this is where it's actually specified in detail so this is like the bit I struggle with it's like if you have something like withdrawals like 4844 it's just like much more logical to like specify at a higher level what the change is and then link to like the implementation details on both sides and obviously you can leave some comments and whatnot like in the implementation details that are a bit more in the weeds
Pooja: yeah that's I don't know that's just like my it just seems more logical for me to like have the spec be at this higher level of abstraction and the english like I guess have the identifier in english description via a slightly higher level of abstraction and then link down the specs on both sides which which implement the actual changes so I think you made a few points in there so I think the having both sets of things and in the future hopefully if we continue to go down the path of modularity you know more than just like this networking layer there's a sense layer there's the engine layer there's the evm layer etc having all those be share a numbering system i'm fine with having them share a naming convention i'm fine with as well so they're all eips or whatever i'm also generally fine with taking the eip name and leaving the eips repo that has all the leftover stuff which with something else so there's not confusion so like turn it into the erc's repo or whatever I think i'm also fine with that I think where i'm in disagreement with you is i'm still I feel like if we are successfully modularizing ethereum which I really do think we should be doing from an engineering architecture standpoint I really think that the only way we're going to scale our development speed is by modularizing things if we continue down that path I think we don't want changes to frequently touch multiple pieces like if we do pull out the evm and we have the cl pulled down we have the el pulled out and we have like the transaction pooling pulled out or something and all in different modules in order to maintain the velocity and the benefits of this modularity we really want them to be as isolated as possible and so I think that I think the thing that that bugs me about your desire to to have them kind of like make it easy to have these change sets that cover both cl and el is I feel like it's encouraging this architecture and development practices that we really don't want to be encouraging like they're encouraging bad practices from my point of view and we should really be discouraging that and one way to discourage that is to make it hard so like if it is difficult to have el ncl and evm and transaction pool changes that touch everything then people are less likely to try to touch all of them or more likely to do separate isolated pr's that touch individual pieces and then the emergent behavior when all those work together is something that is desirable but it was done through a series of isolated changes I think we really wanted I think what you're describing is like a theorem 3.0 in a way I think for the next like five years there are so many things that are going to touch the entire part of the stack that we need to do so I feel like I feel like we can most of them we can do modularly if we force ourselves to and that's what i'm pushing for is that we force ourselves to do that like we like they take withdrawals for example withdraws our parts el parcel that is a thing but we can divide it up so that the changes are isolated from each other and they don't depend on each other and I think the the el side would need to go first I think someone else who's more familiar with it we want to speak on this but like I don't think we should be doing this as one big change we should be doing this as two independent changes that then have an emergent behavior or maybe one is dependent on the other but like you don't start doing the the second one until the first one's finished and you might from a design standpoint you might design like and architect things more broadly when it comes to specifications and defining things I really do think feel like we should be doing this separately and so even in that short term and over the next one to two years we've got withdrawals and we've got sharding and all this stuff i'm i'm just really loathe to throw away this modularity that we've just finally gained we finally gained some modularity in the system and we're on a path towards enhancing ethereum's development velocity and I feel like if we just merge them like from a specifications level then we've thrown away throwing that modularity away and we're back to bottlenecked on whoever's the slowest developer and that's really what we need to get away from is being bottlenecked on you know whichever team is most bogged down and we wanted to make it so the evm for example can't iterate without having to wait for the we got you know a dozen evm proposals that alex wants to move forward with but he can't because he's blocked on the core devs and similarly you know there's consensus changes that I really don't want to be blocked on the execution devs and so yeah I think that's I think that's when I think about it I think that's I suspect that's where our biggest disagreement is is that I really want to discourage I think this behavior of one monolithic spec and it sounds like you feel like it's inevitable and necessary no I think I think I agree with you just that matters I think where I i think the bit that like I i want to avoid the most is exposing all that to the users it's like in a way yeah I agree with you that we shouldn't be exposed to users and I actually do think that we need so we have the execution layer a team and we have the consensual team I really do think we need a packaging team at this point like we need a team whose job it is to make it so we can shift I think peter actually started putting something together like this as a side project where it was like a thing you could download that would just pick a client cl client for you and yell client for you and set them all up in one little package like I think that should be something that we develop as like an actual thing and you know sponsor if necessary but you know that needs to exist and I i totally agree with you that we should not be exposing this stuff to the user at all but I think the right way to do that is not to turn it into model ftp software but rather have a set of people whose job it is is to bring all the pieces together at the end yeah and yeah anyways we're at time but I think there is there is part of that where it's like within the process of working on it like like 484 I think is like a really good example here like we need to tell users about it and l2 teams about it and like get people who are not like full-time core devs to engage with this stuff and so having a single place it's almost like I i would be like if there was a way to to get meta eips for these types of change or some things like I hate having to send people like a random hack md document that like links to the cl and oil specs what is that that feels like the right solution because it's just like a really shitty experience like it's not it feels like it's a half-assed like thing that like you know no one can find there's no discoverability like it's it would I think there's like a lot of value in just having like a document that's like hey here's like the overall change here's the rationale and like here's how you get one level deeper into detail and I feel like that should be like an official thing that's part of the specs not just like a a side thing that like any ip author puts together yeah so I feel my my gut is is that hack md is like a perfect solution for that but it sounds like what you want is something that's more formalized like a formalized process that has people that review it and maintain it kind of like we have with the ips yeah and like a loose I think I think that process it's fine for it to be looser than a core eip in a way right like because because I yeah and it's more like a melee eip or something like that I think what you're looking for is like a design document where it's not a specification it doesn't get into the nitty-gritty details of you know this byte goes here but it's a yes a design document that maybe has some flow charts that maybe has some sequence diagrams and has you know lots of text that describes how things are talking to each other I agree that is it would be a very useful document i'm not against I don't think i'm against formalizing that process I don't feel like the eips repo is the right place for it because the ip's repo at least currently is you know pretty strict pretty standardized like you know we have bots that expect a bunch of things to be in place and so i'd rather not have design documents in there because I feel like there's going to be constrained and I want them to be or less constrained like really encourage you know external links like I want that to be a thing in a design document I want you know lots of images and lots of flow charts and I don't want to be constrained to you know you have to have these sections and you have to have these header fields or the bots going to complain at you and so so I i think I agree with you the design docs would be valuable i'm ambivalent whether they're formalized or not I don't see a huge value in that but i'm not against it either I don't think eip's repository is the right place for those though okay that's fair I think I would be fine if yeah if we had like yeah anyways I i need to hop but I think I think there's probably something there that that could work yeah okay we'll talk about this again in two weeks i'm sure yeah yeah but yeah thanks yeah this is this is really helpful well thank you thank you both yeah thank you all see you in two weeks
- Pooja
- Micah
- Llightclient
- Sam wilson
- Ryan
July 13 2022
00:08:28 Pooja Ranjan: https://github.com/ethereum-cat-herders/EIPIP/issues/152
00:09:56 Micah Zoltu: Another Canadian. We are being overrun.
00:10:27 Sam Wilson: >:)
00:13:03 Tim Beiko: +1 to this
00:14:35 lightclient: which thing r u +1ing tim?
00:14:44 Sam Wilson: +0.5 EIP
00:17:27 Tim Beiko: Sorry, I think we should not go against the current w.r.t. how the community uses ERC
00:18:12 Pooja Ranjan: https://eips.ethereum.org/EIPS/eip-20
00:18:17 lightclient: they link to whatever they feel like
00:19:50 Micah Zoltu: ERC-20 ✅EIP-20 ✅ERC-20 🚫
00:23:22 Sam Wilson: To be clear, I do not. I prefer EIP-
00:23:36 lightclient: jail
00:25:42 Tim Beiko: https://notes.ethereum.org/@timbeiko/executable-eips
00:29:52 Pooja Ranjan: :)
00:30:31 Sam Wilson: My life in a nutshell.
00:32:14 lightclient: brb 1 sec
00:34:45 Pooja Ranjan: Agreed!
00:43:53 Sam Wilson: I have a sneaky related project
00:44:06 lightclient: snecki
00:47:49 Sam Wilson: I have eips.fyi if you need a fancy domain name
00:53:06 lightclient: i need to drop sry
00:53:08 lightclient: bye
00:53:12 Sam Wilson: Me too
00:56:25 Pooja Ranjan: +1 to Tim's point