EIPIP Meeting 74

Transcript

welcome to apip meeting 74 I have just shared agenda and chat we have a few open issues and pull requests as usual to be discussed on this call as well as we have another important topic which is EIP and ERC repo separation there is a proposal that we will look into and we'll cover some of the discussion continued from earlier meetings so let's get going the first item listed here is a CI upgrade EAP bar to EAP review bot I think it was suggested by Sam Sam if you would like to like provide info and we can discuss this one first this is uh

pandas actually yeah it's my it's my PR someone's the one that suggest suggested it for the meeting um So currently Erp bot has quite a few bugs and the code is not easy to maintain um in fact I'm still not entirely sure where some of the stuff that needs to be fixed even is I have tried multiple times to fix particularly the bug that means that PR's that delete files can't be merged um multiple times unsuccessfully so I really don't even know how to fix that one I'll and I also so what I did was I made a complete rewrite of the EIP bot I

think the only reason that it's not merged is concerns over uh if there's some oversight we made that allows PRS to be merged when they shouldn't be so basically concerns about me like I have fully tested it tested every part of it manually and have automated tests too but there is still a chance that something slipped through and I think that's what's blocking it at some point it would probably be useful to merge it maybe try it for a take a snapshot of the repository and roll and and force push it backwards if need be but I really don't think that there is any bug

I have thoroughly tested it and there are automated tests and as somebody who's reviewed it it does seem fairly understandable um yeah imagine Victor if you guys have any thoughts on merging this one well I think we probably definitely want to at least probably have a local clone of it so that we can force push if the worst comes to worse and someone does find a way to absolutely break it but um I think it's almost certainly fine I mean it sounds like it's

pretty ready to merge if there's tests you mainly tested it and Sam has taken a look and it looks looks good all right so consensus is to make the switch [Music] everything confess it and then what is happening in your audio mind me damn yeah sorry it's a 3D printer cool all right so let's go ahead and merge that if any of the editors May merge it during the call it would be nice or we can do it after the call as well moving on to the next one which is an issue I think it's a new contract interface and

EIP should require to include a privacy consideration section anyone else thoughts on this uh I don't think we need another section for it I'm feel pretty strongly that if there are privacy considerations for an EIP they should go in the security consideration section uh I I propose an alternative thing which is that we rename the security consideration section to just considerations and allow subsections such as a mandatory security subsection and a I I guess we could also make it a mandatory privacy subsection I just don't think that there are that

many eips that require privacy like it's at a blockchain a public I don't think there are that many erps that require security considerations either nonetheless it's still a reformed section definitely have it yeah I think I think we uh the privacy considerations at the very least should be mandatory for choreographies even if there are oh sorry I meant security considerations not privacy I think core EIP should have Security even if people just say security considerations are mandatory now right now for all VIPs regardless of type or category

this part like why do we need privacy I mean I can understand if that is something related to specifically related to ERC but again because we are talking about standards so do we need to have the Privacy part like we are trying to make it open source adaptable by everything so as much as transparency recommended yeah I think it's primarily for like as you said transparency purpose it's like if something's gonna like somehow leap some information um just by the nature of whatever algorithm it uses that should probably be taught the end user it also makes but uh as someone who has done application

development um being able to know what what affects the tools you depend on create allows for things like gdpr compliance to be a little bit easier so that would be my rationale for why it would be a good idea two at the very least uh rename the security considerations uh to considerations so my problem with having it just considerations is is my already any better your audio is great okay so with just considerations is that people are going to try stuffing whatever the hell they want in there that isn't even

related to security or privacy they'll they'll have like one monetary considerations and and all sorts I think that's absolutely fine if there are any considerations they should be listed in fact there might even like for example the my EIP that's the ethereum notary interface uh interface uh that I'd like to put a legal consideration in there if possible but like that's just like not and there's no good place to put that sorry trains how about we add a new other

considerations and um as optional so that if someone want to bring in privacy they can bring in there and if they go or any other things comes up they can put it there and uh we can still keep a security considering separate and mandatory I was thinking just subsections of the uh consideration section so you have to top the second level considerations third level privacy third level security third level on other well uh I don't think we're gonna get very far talking about this on the call maybe we can make a thread on or actually discuss this in the issue um various discussion on that in the

issue that's in fact the proposal I put there so to summarize the proposal here is to have a renaming of this section security consideration has just consideration and there could be the different types of consideration depending upon the proposal I I am fairly against giving people more flexibility I'd like to not have and other considerations or just a vague consideration section I'm also generally against I do like the idea of people being more cognizant about how their ERC and I'm saying ERC because I think that there's not many

cases or eips coming to play with respect to privacy but I do think there are a lot of ERC protocols that should consider follow their application deals with user information the thing that prompted this was actually an interface VIP so yes there are in fact eips that would definitely deal with I just don't understand why privacy isn't security like aren't they the same like isn't privacy a subset of security yeah that that was actually me I but like I I definitely still believe in that but the public perception of them is

different right especially since there's a trade-off like privacy and security there is often times a trade-off there and so I think it might be meaningful to distinguish that Okay it definitely looks like we have divided opinion here on the um call that the present participants so maybe we can uh have more discussion going on in the issue section and if we get more feedbacks there probably will bring it up to the next meeting does that sound

reasonable that's good awesome so we know that we have another we have another topic for discussion today and that is a proposal a proposal to separate eips and ERC repo uh the proposal is proposed by Tim Baker we have him on the console team if you would like to maybe provide a brief overview so we can start discussing on the topic yeah sure I thank you for having me um also thank you forever like all of you I think almost everyone on this call sort of replied on this thread so um appreciate the engagement there um I guess it's probably worth starting

from like you know where this came from and then we can get to the specifics um but high level the thing I I like the number one thing I've been like focused on and uh sort of care about is um figuring out how do we get to a point where there's a single sort of pretty straightforward process to propose uh consensus changes to ethereum um and by consensus I mean like not just consensus layer but just like the changes to the consensus rules of the protocol um and today I mean I think pretty much everyone here knows which is for clarity like on the execution layer side we use this weird thing where we have a yellow paper that's now out of date we have eips that act as like layers we apply on

top of the yellow paper and this is you know more or less what we which we call our spec um and or at least historically that was the case and then on the CL side uh they have a python spec where they just make prs2 and that is basically the um the actual spec of the network um on the on the technical side yeah we uh I mean Sam and his team you spent a bunch of time over the past year getting an El spec up to mainnet which is which is great um so I think this gives us like a much better sort of technical uh base on which to like specify changes to ethereum especially in the post-martial context um and so we've I think we've done like really good work rectifying that's part

of the process um but the bit that's still quite uh separate is that um we basically use eips to specify changes on um on the execution layer they don't do that on the consensus layer and it would be nice that uh this would be the same thing and a few reasons why this would be nice is like um one you can think of like the changes on the consensus layer now matter like much more given that like we've merged you know the beacon chain is live and it's all one system um and you know you can take one very like straw man example you could say look uh the consensus layer can literally just double issuance on the network do this through like some random PR to the specs and there's not really a

great place where like it gets um it it gets like documented in a way that's as easy for people to understand as like eip1234 is the place where the changes proposed the other the other bit that's quite hard is um when you have changes that affect both layers so we have two examples of this right now like withdrawals and and 4844 um and both are like pretty awkward so like withdrawals has like a hack MD that acts as a sort of meta spec and then that basically points to the um CL repo and the El repo for the cleip and the the CL specs sorry in the ELA P to like describe the changes 4844 is this weird sort of EIP where the El changes are

described in the Eep and then the sort of references without linking the CL specs for the rest um so I I think you know the the ideal Insight would be something like you know these Corey IPS or these core changes get specified in in like a common way and then can link out to their respective specs um and talking to client teams I think people are you know generally on board with this Vision but one I think the biggest the biggest challenge is how do we get people on the consensus layer side to want to interact with the EIP process to like specify their changes um and and kind of add this extra degree of like uh formality to their process

which they don't currently have um I think they're you know I spent a bunch of time talking to them they fear that like the EIP process is pretty rigid and bureaucratic and and that the the sort of friction created from it won't be worth it uh you know and and just sort of slows them down and they would also like the feel like they can like they don't they aren't only the ones that have to comply to the EIP process but maybe you know the EIP process and can can kind of adapt to how they do things because you know they might do things better than than we do as well um and and so you know this is kind of a long intro but the idea is like I think that the

main problem I've been thinking about is how do we like create a process for specifying changes to the core consensus rules that is like very I don't know like enticing for people on the consensus layer to start contributing to and ideally that has like lower friction than the full EIP processes that exist today um and then you know the sort of second order effect from there is I think based on that you can imagine core EIP starting to like evolve in a way that's different than the rest of the EIP process um and I think this is kind of where the idea of like splitting erc's and eips came out of where um you know this would be a a way to

kind of signal like look um this process was well diverged this is like the first step in that Divergence um and and you know we can kind of then both take them take them forward in different directions um I appreciate all the arguments that you know like there's a some high technical overhead to do that so I I I don't want to like you know incur all this work just for the sake of it like I think it it's it's sort of considering the the like those drawbacks as well um but I think you know the sort of meta proposal I have here is like how do we include CL people and give them away that's like much more flexible where like they can start to iterate on the process

um even if it doesn't meet you know whatever bar the current EIP process has um I think it's it's like we're in a much better spot if we have like quote-unquote bad CL eips that like don't fit our templates don't you know work quite well then if we have the current status quo which is nothing and like them being sort of scared to the the to engage um so yeah I'll pause here but that's high level sort of why I wanted to bring this up and and kind of the rationale behind it yeah um here's my thoughts first of all we need more me we need more editors period if that so or some other system so that more PR's can get reviewed once that once that's done the IP process will be

a lot less bureaucratic secondly I think that there's no reason why we uh can't have a for example my proposal to just automatically merge all the drafts that would make it very easy to get started I don't I don't and we could even possibly disable uh make the validator do warnings for draft uh eips instead of full blocks so that's my thought and that I think would definitely help people get on board and not require splitting the repo which it's easier for everything's in one

place select Echo puja's argument against um Auto Merchant draft PRS is that a lot of eips get abandoned in draft so the only time editors interact with them is in the first PR into the port into the repository so I think that's probably the strongest argument against just automatically merging drafts I don't get it why is that a downside because they'll be terrible yeah I think if they're terrible nobody uses them if we serve terrible eips from our domain then it looks bad on us and I

think there is I mean I hate to say but I think there is some amount of like reputation that we want to maintain and we want to have a minimum bar for quality for what we publish okay then we just lower the stagnant threshold for draft gips and allow deleting them if they stagnate I mean that is increasing our work the first thing that we can do at the entry level is like make sure that we are adding only good proposals even in the draft status there is nothing wrong in staying as long as they are not ready to be merged as draft considering that we have now so many channels open we do arrange this by weekly meeting for EIP editing officer authors are welcome to

come and talk to us to move the proposal to make them better and then add it as a draft if we start Auto merging them we are practically losing this space of giving this opportunity to learn I I if I may chime mean I think uh a team comes in and raise the problem that's uh because of EIP editing has of too many frictions um they want to kind of propose a fork and I can resonate a lot with that I'm actually a big fan of reducing the frictions and uh respect adopters including allowing um much more linking to useful sources uh what I feel

um that we were going into debate is about like whether like um a micro area whether we want to accept drug merging or not that's a more practical but in a high level do we want to have a fourth version I want to bring to the attention to this group also that there's nothing stopping El and El and cl applying developers to continue just ignoring EIP fully which is what they do and out of respect for this proper program team come to us and I believe that if we could think of how we can reduce the friction for them that's the only way we can keep the the core or

other EIP type inside of VIP I personally feel that um I'm totally in support of having a core EIP and maybe Network EIP and even interface EIP have different rules and different layouts and different merging frictions by different people what I feel reserved is to have different repository and different domain names to serve them which has both technical problem as well as it creates confusion for people to understand where to go to to look at ethereum proposals um so what I propose to uh game and a group is that can we allowed a group of

core contributors to quickly become EIP editors and uh for them to make decisions about their emerging rule their editing rules in that way we can keep distance in one single repository um yeah that would be my proposal in this I agree with that we could we could just Fast Track quite a few core core developers into being core EI eipe editors and actually with the new uh with the new IP review box it wouldn't be that hard to uh to uh make it like a core only

like no website changes like a slimmed down editor thing that only works for for eops and doesn't give General editor stuff yeah before diving into Solutions too much here I want to understand a little bit more about what the problem is so what is friction like what about our process is difficult for first young people to want to work with I can answer that it's that we spend the it to a lot of people it appears that we spend a lot of time on knitting picking stuff and I can actually

I actually somewhat uh agree with that Center but it's just that the reason why we spend so much time on nitpiggy stuff is that we want our eips to look good right that goes back to the kind of the like the like reputation like things but I think that we are actually a little bit too nippy with too nitpicky and some in some cases particularly with drafty IPS that aren't even going to see the light of day um a lot of the time but yeah I think it's nice and maybe I'm children yeah that needs to be reduced

so I think um like I followed the process more closely than like the average consensus layer Dev and I do think it has improved like quite a lot over like the past I don't know six ish maybe 12 months um I do think like that those like incremental improvements sort of are perceived against like four years of basically stagnation from the CL teams and and and I think this is a lot like you know there's a bunch of like small tweaks that that cause friction like I mean and whether this is like the syntax rules whether this is um

yeah this I don't know the the templates or stuff like that um I mean you know I think it uh like the for example the the SSD EIP right now um you could imagine a world where like you just merged the first draft of that and then still kind of have the discussion about like you know the improvements after it um but I I do think like talking with cl folks is like they just viewed this as like something that if they sign up for will like slow them down immensely and they might not be able to control um and they sort of add this dependency in their process that like uh they I don't know they're sort of fearful of to some extent and and something that like signals to them that like you know

they'll be able to like use this process in a way that's like useful for them even if it's not like completely following sort of current rules um I I think that's the thing they would like to see um and whether this is you know spilling it out in a separate process in repo um I think that that sense that signal I think the other option of like yeah adding some like you know potentially even just CL EIP editors or something that um that can merge stuff you know like even if it's not if it's not perfect um that might be good enough to get them to use it and and I think if we went down that route you know for example like it would be worth looking then at like okay uh I don't know over the past

two months like we we sort of force merged these four eips you know what like what's like the check that they weren't passing like what is the thing we overrode in the bot and that might be like the most useful way to understand like What's um what's like what where the friction comes from um but I I do think like you know there there's definitely like a quote-unquote irrational fear from the CL side to participate in this um that's based on just like the accumulated perception over a long time rather than like having spent a ton of a ton of time to sort of uh yeah actually engaging in the process and I guess most people it's just you know most people don't have a

ton of time to engage in the EIP process um yeah well once you actually know what the process is and what the formatting and stuff is then it's actually quite simple I think there is a but there's definitely on I think Beyond just this like question about being fearful of the process there's also this problem that the process for getting you know core eips over the line and the process for doing ercs are different and we're spending a lot of time trying to come up with the rules that work for both of these systems and we are you know just coming up with something that's sort of modeled in the middle and I think that to me is the biggest argument why it needs to be just

separate because what would you say go in for two totally different is an example of something that's very different between EIP like core eips and erc's I think Corey IPS there's this very specific small group of people that like are actively working all the time to try and make these things happen and we have very like specific ideas about you know trying to come up with certain test cases you know writing security considerations about all these things and for erc's it's like a completely wide open world like anything is possible we have people who are writing completely new protocols we have people who are writing additions to protocols like we should they should be thinking a lot more about how can they make the

process more amenable to the types of things that they're doing you know we don't really have as much of this extension of EIP is usually in core EIP so that's like a super common thing for ERC all the time they want to add new things to the nft standard as it's something that they just keep adding more and more erc's rather than coming with a more principal top-down approach about how can we just like continue moving the NFP standard forward and this to me is just a problem because nobody is really engaged on that side because we don't want I mean it's hard it's hard to have them engaged in this process because this is a very important process the course in as well and so we don't want this influence application developers come in and start defining tons of different like procedural things

and so I think if we make it separate give them a room to experiment and try different things then they'll end up with a much better process that speaks of their names will end up with a much better process of some sardines because we'll be able to bring people in who are involved with the core process who don't have to ever look at anything because they aren't we are successions about you know we want to make this change oh this change doesn't work as well for ERC etc etc great and I think that the question is like I think there's two there's two levels to that one is like the technical coupling of the repos and two is like the quote-unquote management of it so you can imagine in a world where like

you know we keep it all in one repo to like lower technical overhead but then we the the process sort of evolved independently or whatnot and and I think there it's like yeah maybe you need like you just need time and over time you see um yeah over time you see them the Virgin maybe that leads to a split I do think like even if you read the ip1 today there are like all these awkward things around like you know Corey IPS and I think there's also this weird question with Corey IPS that's different is like how do they fit with the network upgrade process and that's always been like a very sort of awkward thing and and potentially having a separate process

there um I potentially having a separate process there helps like converge to something that's like not only a Specs process but it's like a Specs plus like statuses map to hard Fork status or whatever um process yeah okay there's two totally different systems resonates I resonate and recognize what team says that or EIP already have a different treatment at least when it needs to move to final can we just allow more diverging of the rules but not forking the repository allowing more editors

from the core peen to uh to to to merge okay what is the argument Repository and having everything everything in one place having allowing uh reference one another um there's a lot of arguments for having when before IPS made their reference an ERC or vice versa sorry when do core eips need to reference ercs well say that something relies on an art code being available such as say good like proxies rely on delegate call um also 10 ID proposed by uh 55 was being referenced in I believe erc's 112

a712 which is both I personally perceive as both interface and ercs these are extremely simple things to resolve once they're split up you can say requires that VIP requires this Fork of ethereum I think uh I think William entrigan provide a good argument about a nor forking mainly because of the technical um the the uh the wholeness of the technical side a stack people can go to and then see everything together it is definitely nothing uh preventing them you can even break down core uip into two different repository for execution

and and and consensus right um but like that's what we have right now and we're trying to unify these things so why do you the reason uh the rational arguing for unifying them is can be also leveraged to you to to argue for unifying many of the other stacks like okay the people who are working and the people who are working on these core things this is one specific group that they're working on the El they care about what the CL is doing if you want a CEO care what the El is doing this is like a a known group of people or is the application inside like this is also a number of people but if they're completely disjoint there's no there's

almost no overlap people who are building application stuff there are very very I mean people can follow yeah I I do think there is like a separation of concerns like between what's built on ethereum versus like the specification of the protocol right it's I think some yeah doesn't the protocol just build on itself absolutely not well I mean protocol is the is it constantly being moved forward with upgrades and adding features but these are like application developers to use this is

but this is totally different right really applications on top of the platform and adding features on top of the platform to the platform I don't see much difference at all well there is because like for example like the most obvious feature is that a consensus change requires the entire network to adopt it or the network is gonna afford right and it's like and and you know and it it has to be bug free otherwise the networks you know well I can try to bug like I think the sort of bar in terms of like consensus building that we require for Corey IPS is you know much much higher than an ERC which is like an opt-in feature and then and then I agree I think Sam you were the first to make this point on magicians then this is

like sort of a spectrum right imagine core eips are on one side of it ercs are on the other side something like an interface EIP is kind of weird because you know maybe like sure not all the clients need to add 868 but then if they don't gossip these transactions the right way it kind of messes up with the you know with the network verify different that one would be in the networking the WT repo that one shouldn't be a pip really anymore right but but yeah but I do I yeah so I I think it's like there's two clear spots right there's like a standard for like a new NFC royalty uh thing which you know is opt-in has like you know there's no sort of if

if I never know that it exists I can use ethereum and like my experience has not changed but then there's something like oh we're gonna double the issuance and then it's like wow everybody who like has a say in like ethereum should probably be aware of this thing and this is where like I think Corey IPS are different we're like um even when we add an opcode it's like we're asking all the nodes to like update at the same time and um and it's really valuable that like this information is like clear and this is I guess not to Matt's point it's like the fact that we don't have this for the CL today I I see this as like a really terrible sort of failure of the process because um you know you go to the CL specs you see like a diff on the specs with like a

couple comments but it's really hard to make out like what what are like each feature so like you know this this Fork introduced one two or three things um you don't have something like a security consideration sections you don't have something like a rational um and and and I think it's just like the process is much less like legible um than the EIP process and like yeah rectifying that is like basically the number one thing I care about like if we can get to a spot where when we have changes happen on the consensus layer there's like a handful of VIPs we can point to that say Hey you know we've changed validated rewards we've like updated the fourth choice rule you know whatever else like added withdrawals

like that's extremely valuable because then the community can review those changes understand them um which is is much harder to do today um yeah I think we are talking about maybe two different processes here so when we are talking about separating repo am I understanding is that we are trying to follow the same process that was followed that was being followed so far and it's just that we are having two different folks for erc's and eids they both followed separately but when we are trying to follow the process which is already being followed by the fields perhaps that is going to be a different process than than the one currently being followed at EAP so uh if we happen to follow what CL is doing then it would

be better to which are the The Proposal was to have a fork and then the the core eips doesn't follow any obviously rule if I understand it correctly to reduce it yeah that's exactly what I want to clarify like are we proposing that VIP repo will not be following anything that is being followed so far we are trying to move towards the different process of you know the code proposal which was earlier in the execution specs uh poor EIP process and then separately develop a process for both of them independently that suits both of the needs in the best way

and part of that is like figuring out how to engage Clauses in the EIT process yeah yeah but I think I'm yeah I'm weakly opinionated on the order of those two things like if you know if if y'all think that like having the ability to like have CL folks sort of update the process of the core stuff as part of the EIP process as it exists is the right first step until you know potentially like there's there's enough friction that like the separating the repos make sense and maybe that never happens like I I I'm fine with that but I I think like the yeah the most

important thing is like how do we get CL people to feel like they can come and contribute and that there's very low friction for them to do that and regardless of the way you do it it's gonna assume that like a sort of higher error bar or like a lower Quality Bar for cl stuff and I think we should be very okay with that because our current status quo is that we don't have an error bar for or an error rate their quality rate for like ecl stuff because like they just don't have VIPs right so it's almost like we don't see them but yeah um yeah and I I think that's that's bad yeah how about this compromise we introduced a new type of VIP basically a

track EIP and it's basically a redundant it's a different EIP one it describes an entirely different process but everything's still on the same repo so it can all enter so so track you so eips of different tracks can still interact with one another while still having several processes huh I don't even think we need a new VIP one this is sort of what I liked with forking the repos is like you know most of the stuff actually stays the same right like um so I don't think you need a separate EIP one um I think I don't know where the EIP rules are written are they eip1s or on like the whole page of the website uh okay but yeah so I think

um yeah I guess and maybe I don't know the other way I would frame this is like I would rather lower the friction and then rebuild the process than to try and like proactively come up with the right process because I think that's sort of the thing that it's like if we add a bunch of new process rules to make this work then we don't know that they're right and this is sort of the the other problem it's like if we can just you know try out a bunch of Cl eips see how they differ and then sort of go from there I think that gives us a better like starting ground than saying like oh we're going to try and think of the right way to

accommodate them in a new process and then add a bunch more constraints around that um so I think yeah so I yeah I'd be yeah no I'm like thinking that an EIP one could be changed to attract the IP and then what you what we do is basically you create a new IP Erp depends on the ip1 and just says these conditions don't apply to BC IPS which would allow for a fast trap s sorry I didn't catch that dude I think you're just adding more levels it's like okay I want to make a change I

usually make a core AP oh wait VIP wants us to go look at this time you guys see that information okay we just document it very clearly is it does this is like your full-time job hours and hours reading about how to like make a change and everything making changes for years and I think this is yeah this is kind of back to what I was saying earlier is like to me if we had you know someone who can like force merge client uh cleips you know these people are not stupid either right like they do care about their work they do generally like

do high quality stuff so it's like you you start by force merging their stuff in even though it breaks the rules then you sort of retroactively look at like okay what's like what rules did it break how did this thing differ you know and you can even imagine a world where like aside from asking for a title with like a number that's you know they don't need anything else right like maybe they don't even use the same sections maybe they don't use that and then it's like maybe you like over time sure you build this separate eip1 that documents this but I think your odds of like success are much better if you start from allowing them to use it as they would want to use it and from there you know

potentially enshrining some things or maybe you know after six months you tell them look you know you guys never put in a security consideration sections that's really bad we're gonna force you to start doing it but at that point they're already sort of uh um like engaged enough that they can maybe understand like the the value of of this yeah well then maybe the path forward is we you know find somebody from the consensus teams this is probably the hardest part that wants to be an EIP editor we tell them you know you can force merge and override whatever you want for cl eips that way they get exposure to the process um oh no it's got to be it's got to be one

of them directly it's got to be a CL developer um because they need to learn the process and uh that's it we don't change the process at all because I I don't think like it's just a perception of frustration right like the reason why it takes so long is because like for erc's at least we have myself and Panda that do it right like that's and it is 90 Panda so like for core eips we have like Matt and Greg and everybody and they go through a lot faster there's a hell of a lot less friction than there is for erc's so if they had a development like if they had a core EIP editor um they can go as fast as they want they won't be blocked on anything because

they can just approve their own eips and they can force merge if they want people to improve their own Yankees sure but I'm talking about like as a group like okay anybody inside as long as that that death doesn't write to the IP yeah yeah okay sure so uh how we could add two like it doesn't matter right like yeah and uh they'll only get notifications about Corey APS maybe a few random ones but it's really not that bad as long as you're not on the ERC track um and that way they control exactly how much friction there is they're like what the heck is they get to just merge their eaps without doing this and I have to smoke validator all the time we would be willing to accept

that yeah I don't want to have to deal with like the angry after like I want to put them in their own box and let them flourish in their own realm just pin the blame on me keep W is not that bad yeah I agree contained also an example of a consensus layer a proposal which which was considered to be standing in the process for way too long that it was for proposal for it 44 to be moved to the review um status so uh Sam had this discussion in the call we had yesterday the EAP

editing office however there was dependency on one proposal to another so they wanted to have like each 68 to be a part of a required section if they allow people to just keep on Force merging and do not follow any process then it may end up creating chaos so the simple thing was there to have each 68 and review and to get each 68 interview we needed to have e67 in review so I talked to Marius yeah I think created a pull request and it was solved so I think it is a simple process I think this is exactly the type of thing that you want to like Shield CL people from as they start like right so so what she is yeah yeah roses and we have people like uh

many years did not have to come and make the pull requests I did it for him so when we know what is the problem we are here to help them out Sam explicitly mentioned in the comment that what we need is to move this into review and Proto made a PR to make it into a review process so it's not that it is dependent on anybody it's just that awareness that is lacking in the CL team and it's the comfort that we have to provide them that if you are following the right thing and if you even if you don't know what is the right thing we are here to help you out so let us know what challenges you are facing and we are here to help you out move it smoothly congratulations yeah I don't think it's the right thing they'll be like it's just stupid why

should I like why is this rule there like I just want my spec and I sympathize with like you know the reason why the process is there but I think if you start by like forcing them to follow and like sort of Wade through this like Labyrinth of like exceptions um and networking VIPs I think are like every time like I don't know for some reason they sort of end up being the worst ones but like um I mean I think part of it is that the guest team absolutely hates the EIP process and refuses to engage with it and so as the people who are making the network eips they make the draft just to get the number and tell the people to implement it and that they don't ever do anything else with it yeah as you've seen I've actually gone ahead

and tried tried to get the ball rolling on a few of those interfacing ideas Sami was saying something I think we missed you um yeah sorry it's completely slipped out of my body no but maybe okay so Sam I think to your like your previous proposal was like okay we add a couple um we add a couple CL folks as EIP editors for core they can force merge stuff it's important that they're actually CL people and not just like random people because this acts as a way to pull them into the process

um does that generally make sense because there's a CL call tomorrow I think it would be reason you know if people here agree with that then we can just go on the CL call tomorrow and ask if one or two people want to be sort of tributes for this and and kind of go from there um I think the thing is like yeah they need to have Force merge access for Corey IPS and and feel that like you know they can sort of own that part of the process and then through social means we can hopefully align them with the rest of the process but um technically they should have sort of free reign on that sort of small section um

okay so I I'm happy to go on the CL call tomorrow and share that and I can come back I mean you're obviously all welcome on the CL call as well but um yeah I I can go and kind of let them know and we can go from there yeah and just you are like getting access is not a big challenge here we just want to make sure that people having answers are really responsible I mean I don't mean to say that year pay data are not responsible we just want to maintain a few uh bullet points to be covered over there and getting that fish should not be a problem and we are happy to provide all the support to just go through the basics of it and yeah it would be great to have more people in yeah and I think one thing also that

like we can in terms of being responsible maybe one um soft requirement we can do is we can tell them look you can force merge stuff but like try and keep that for cl things right um so like you know because I don't think we should add a separation in core eips but like I think it's fine to say that like you know evm changes like shouldn't be forced merged in by some CL Dev who just is pissed off at the EIP process like technically they would be able to do that but to tell them like you know please refrain from that and use this as a way to help CL folks on board I think that's a reasonable ask speaking of editors can we make uh

zinyan one okay wait before we jump topics here I have something else to throw in um just a heads up that the merge to eip1 that makes ercs use ERC Dash as the prefix and everything else use EIP Dash as a prefix was merged so I'm in the process of updating uh epw um be ready for a lot of very angry people being very confused I was the one who was talking about putting out crcs yeah I was the one I think was the one biggest fan of referring them as EIP considering there was no ERC written in

the repository but now that it is actually reflecting erc20 I think I will pull myself from that uh being a roadblocker there sorry it's great that we decided that we can get some CL dollars on his editors and they can enforce versus CL stuff but I still want to get erc's out of this repository I don't think it's the right place for them and I really haven't heard any

compelling arguments that they should be in here well I I think the the purpose of dips repository is literally any standard relating to ethereum I think that is the scope of it quite frankly I don't think that the special rules for query IPS make sense like having it make it having it turn the final only when it's merged into the quote-unquote canonical ethereum that doesn't make sense to me right because the standard is final long before that I think didn't IP you know we're focused on a beer we

don't care about other change I don't really care if I'll go away she makes an EIP to update their easy amounts we're moving ethereum oh one forward and so we're very much tied to the hardcore schedule of ethereum yeah but nonetheless I don't think that the eip's repository should be the place to make government uh governance decisions I think that the proposal should all be final even competing ones and then the best one is selected to be part of the mcnet I mean I think this is this is

and I I think that this is just like not understanding the process very well because there's no way that we can make something final before it reaches a test net if we make it final before a reason to test that and we realize that there's like a small City that needs to be changed at the last moment we have to go create a whole new AIT and let's create a huge you know cause and confusion about what is the actual thing that's going in and so like we have to leave it as last call and so we actually start 4K test match and probably before it gets worked out to mainnet yeah and that would be the risk of moving it to final before a Tesla is made but nonetheless I don't think it needs to be the EIP editors is responsibility or anything related to the EI uh to the Erp

processes responsibility to care about what has or has not been implemented where I'm not really saying that that's that's not really what I'm asking for I'm I'm trying to say that I think that the process for ercs and eaps are different and that they should be completely separate yes the original scope of the EIP repository was to Define all of the standards related to ethereum but that one in 2016 and over the years we have realized that that things that are happening on the application layer are very different to think they're happy as a core layer and so I'm saying that the scope should be changed at this point in time what changes would you propose would be made

uh what what divergences would you like to see in the processes I mean it's not really up for me to say like I think the process that we have right now has been mostly dictated by the needs of the core protocol with some occasional input from what application developers want in that process and so it's not really my place to say how the application developer should modify their process to support their workflows I think the process that we have right now is reasonable for doing core protocol changes but it's not very good for the application developers and how do I know it's not very good if the application developers because they don't even follow the process unisoft launched this big permit 2 contract a few months ago and they just didn't go

through the entry process no they were like why would we do that like let's just ship it and this is like the risk that we're having because people don't want to do this process it doesn't work very well then we just fix it and like if if if everyone is complaining about the same thing both both uh elcl and application devs then that suggests that there's something wrong that should be fixed everywhere and not by forking but there's there's just all people from different perspectives like we need to let the people with those perspectives come in and play a role and pioneering the changes we can't just

like sit here at the top of this pyramid and ask for feedback and then make all the changes pop down I'm not involved enough like high level application development right they might not they might not be the same disagreements yeah yeah well well then why don't they just make a PR modify an eip1 I mean that's the entire point of like that that we get to almost like crowdsource the process I mean look I hear you they should be more involved with the process I I don't disagree like I'm frustrated a lot more involved with the process but I think the right way to get to the ball with the process is to sandbox this process away from the core process and let them be the captain of that thing

let them have ownership and responsibility over the this full like end-to-end process if we add them and involve them out what I agree with letting the core people do the core stuff and not having to care about the ERC staff nonetheless I think that they should still remain one Repository is just pointless like it's just a pointless semantic and I'm saying that I've like quite a bit of feedback about it's too much noise for people to just follow this repository because it's such a grab bag of different things that are happening before I think what what team has proposed in

two steps the first step is inviting the CL team uh Court to become editors and see if they can still fit in this is separation this is separate than the CL editors yeah we're separating the ercs and the EAP repository we already said that we'll add the CL people with editors and they'll have Force merge abilities I'm saying that we need to get the arcade out of this process as well and let the app developers take the range and really you know manifest the process that they they want to have I I still I I still think that this should be done without separating them I think they can be have different why like what what is the argument for it's not

suffering again so that they can interact with one another so that they're not committed there's no need for them to interact with that one another you could always find that you need to interact as if you're saying this relies on this core change and I don't think the core ever needs to interact back to ERC like there would be no point I would not accept the EIP a core EIP that refers to an ERC I think Greg has some uh um strong opinion on this shall we wait for him to come on and and and have a have a say on this we already make some good progress in compromising and we can also see how it plays out he should be here and I'm sure we'll talk about this many more times but let's keep going on for a couple more minutes

right and we are almost out of time for like to have this discussion continued maybe we can bring it back in the next meeting for two days from what we got as a conclusion that maybe on the tomorrow's the CL side CL meeting will try to look talk to CL and Dev and see if they are interested to be a part of the process and maybe if Matt if you would like we can bring it back again to hear your arguments of having it separated though I feel like when uh seconds this has been going on for three years and I just want to make it happen and I don't think that there are any compelling reasons to keep these things together other than this idea of unity

and I'm saying that there is no need for this thing of unity because they are actually not a singular like a design space anymore we are very well aware that these are two totally different areas of development and we should respect that by giving them their own places to Define their processes right I as much as I agreed but I think that you know this thing coming from more from the ERC uh authors that I don't want to be a part of eib repository we want to be having a separate repository than code or EIP repository would make more sense to me but so far I think we have not received

any negative feedback in terms of uh complaints like ERC authors why would they have negative feedback you don't have to go through this chart process but they they they do have issues they don't use the process so they just don't use it and then they go on with their lives and they launch their projects and their their you know standards and they just say you should use it because we're a unit so operator you should use it because we're open to these right I would I would maybe slightly differ here because I have seen in according to eaps inside I have seen them more of ERC proposal merged as final so they are definitely moving ahead they are definitely following the process and limitations how many of

these ercs are coming from like top tier teams things like Open Season unit swap the people who should be the most involved with where the space is going in terms of creating standards unfortunately unless it's required for interop you're not going to see people writing standards like I I don't understand why uniswap would ever want to write a standard for anything they make well I mean if you look into permit too I have permit two is totally something that should be a standard like permit to is this idea that you have this Singleton permit contract or you give an allowance like a Max allowance to and then unit swap is able to across all of their different token pairs rather than

given the allowance of that token per contract across all the token pair contracts it can basically do some sort of like authorization via This Global permit contract why do they need a standard or does it only work for you to swap well I mean it worked for anybody but the point of having the standards is that this is like an interface that anybody can interoperate with and yeah the contract is there the the interface is published so it's it's done there is no standard required you just use the contract like a regular contract right exactly I think it would absolutely be worth it worth it to be for it to be a standard take eip1820 which is basically got the exact

same thing except with except basically uh VIP it's basically erp165 on steroids and with the registry contract instead of each contract implementing uh function it's less about having the artifact of the standard interface being defined and more about the process of getting to that artifact that I think was missed on pernet2 other projects what I'm saying is they aren't building something that warrants a standard there aren't going to be I think they're absolutely why is that not like because they built it everybody should use this permit but everybody should use this permit contract and so in the interest of doing

things in like an open way that is amenable to everybody's needs it would have been a lot better unisoft was like Hey open C what do you think about this permit 2 contract is this something that you're going to be able to use too because if everybody implements their own permit to contract then the gain is not that large oh for sure but for private for-profit companies um except Google like take Google for example Google has tons of Standards with uh with the ietf like they do have a vested interest in interoperability there is no difference here there's nothing that you can do to the horse the private companies to have these types of Standards other than the

the social pressure and I I think it's like really important that we try and have this social pressure that people are building standards for things that can be utilized by many different people that they have to build it in the open I agree with you here and I do agree that we should make the process easier but I don't think we should do it by splitting the record I'm sorry to like interrupt here we must have to wrap up now we are like uh beyond the time uh we can definitely bring it back in the next meeting I just want to make one small point before we point up like what we are doing here is helping people to build a standard we cannot force people to come and build a

standard with us so it is totally up to people who want to contribute who want to help other people out what we can ensure by making the process easier and that's yeah but what we can do is just by making the process easier so we can rather focus on what are the challenges what are the friction that people are feeling here and try to resolve that um I I think this would be a good point to maybe wrap up and have if people would like we can have it discussed in the next meeting anyway we have to see the result that is coming up from the CL team or more eipa editors if they are willing to join um any final comment thoughts anybody would like to add before we just close for today yeah I just want to quickly uh

check if uh with the to the temperature checker for uh adding me as an editor I think flight client was the only objection I mean I haven't really seen a whole lot of editing in the last month and a half frankly I can I can try to help I think I think he is more I I think he is more than capable as an editor and I think that's primarily because right now his suggested edits have basically no weight because he's not an editor yet ultimately I think that we need to be

bringing people into the process who are involved with client teams and that's like my in focus I think if you wanted to come on an ERC editor then that would be great but I am like worried about adding more people who have the power of controlling what the like standardization processes for core eips who aren't involved with the court process at all [Music] ERC editor uh we're going to start uh like uh yeah please go ahead now we have this really difficult problem though where

it's like and this is why I want to separate these repositors because how do we like have this conversation about changing the process and I am saying like I don't feel super comfortable but I need more people who have the ability to change the EIP core process um who aren't involved with these client teams and so what like you're supposed to not participate when we start talking about changing the core process like this is a very confusing way and we haven't had an editor added in this manner before yeah I'm in favor of letting CL and El and core devs to make the whole decision about the the core EIP uh editing rules uh I can uh reframe from uh

participating at all yeah well that's totally okay and then I actually don't have a strong opinion there you guys see why this is this makes much more sense if these are two separate things where we don't have to have this it's like oh we're about to talk about course standard change Victor is not going to participate in this specific discussion blah blah blah we already have different editors right in the in our bot metadata no I'm talking I'm talking about any types of meetings we have great tooling for dealing with this on the pr level I'm talking about at this meeting level when we start talking about you know we want to have this change like what if we want to change

the statuses or something for core EIP you got a new status like about to go in hard work right like having these discussions I'm saying that I don't want to be adding more editors into these conversations who don't have context about what it's actually like dealing the process as a yeah I can totally um refrain from um commenting on the core EIP process as an as an ERC editor for sure yeah I totally understand that you need more context on that side to comment on that would that resolve your concern yeah I mean this is this resolved my concern on

that front I still think that this is like a a muddied situation of having the ERC and eits together to me doesn't make a very clear reason to have them separate but we're not going to resolve that for a while so I'm having to forward with this agreement sounds good thank you all right I'm not sure like Sam has already dropped off so um do we have a consensus here like what are we trying to conclude out of this if I were to summarize yeah I would just post it on the pr and make sure that Sam packs the agreement okay that makes sense

thanks Matt absolutely all right uh thank you guys thank you for joining us today uh hope to see you in two weeks have a good one everyone