EIPIP Meeting 83

Transcript

welcome to eipip meeting 83 I have shared agenda and shared this is issue number 241 at eip-e-ip GitHub repository uh we have a bunch of pull requests and issues added from the eaps repository to be discussed today and probably to make some decisions towards the merging um the first set of pull requests are the list of peers proposed by Sam Wilson to update eip1 anyone having strong feeling to merge these and not probably we can discuss one by one so the first PR here is

6907 it is to update eip1 to allow link to bips any thought objection support so I think the only person with an objection was uh Gavin and I don't think they're here um yeah all right um we still have I think three four more EAP editors so anyone from the editors Community other than Gavin having strong opposition to that all right so I think we can probably go

ahead with this and then we can resolve Gavin's um then turn on the pull request yeah exactly well we can resolve it after uh as long as everybody else is on board with this sounds good so we can move on to the next number and that is seven triple one it's add w3c as permissible origin all of them are proposed by Sam so I'll be curious to hear thoughts from other editors um yeah if you have any objection or anything you would like to add in

support or not in support I think I can see no reason at all not to allow it perfect and we're okay with the the wording as written or any changes we would like to see in the

pr inverting so we are good probably we can start with the same wordings if we do not have any anyone opposing to that very well we are just joined by light client math we were discussing issue number sorry the pull request number seven triple one so it is about at w3c as a permissible origin seems like most of the editors are on board just checking in case you have any thoughts concern with this one especially with respect to the wordings as is actually still have some discussion on

the w3c one um so we'll have to I'll go over it again to make sure everything is good but as long as nobody objects I can I can merge it yeah I haven't looked at it closely but it seems fine yeah we could probably just deal with these all as one big group so like um bips anybody object to linking to bitcoin and proven proposals Speak now or hold your silence all right w3c all right ietf uh rfcs are we allowed to link to those anybody object cool and then uh the what working group

any objections cool uh the yellow paper I know you object Matt so um I will let you make your case again the yellow paper is not up to date and it's deprecated in terms of the using the execution specs so I don't think we should allow authors to continue linking to it would it make sense to link to I don't know like the execution apis repo

instead or something like what's the equivalently authoritative stable link that replaces the yellow paper execution specs oh okay yeah so we'll we'll just leave the yellow paper off as that as that's contentious but yeah um all the other ones if I didn't hear any objections so I will merge all of those the execution specs are not useful for that purpose their their code you can't they're not useful for the purpose that the yellow paper is you can't you can't express Concepts you can't say this is a concept that I'm using that you you can't just include

blocks of python code to explain I'm sorry we've been here before so we can probably go ahead and merge the first four and we'll leave that open for any further decoration I greatly object to disallowing the yellow paper it has limitations but it's the original fundamental specification of the protocol the if you're I agree with the

Greg yeah I mean I I'm I don't mind linking to the yellow paper like to a specific commit of the yellow paper because even though it's not up to date like if you're linking to it should be fine in the last meeting we discussed about giving permission to a specific commit um so I'm I'm assuming that it is being proposed with the allowing link to yellow paper with respect to having specific comment um and um it seems like we just need to

get Matt on board and everybody else seems to be on on board Matt would you be fine with comets I mean we had to do it by commit already so it's on any different and I still don't think we should be linking to the yellow paper okay so if you want in a proposal to State the exceptional halting conditions on the execution how do you state them like you're asking for how you would

State them with the execution spec you would say any location where a subclass of exceptional halt is thrown um and how it how would you make a reference to that like a link to a list of them or like is that what you're asking you're asking how you would link to a list of the exceptional halting conditions um yeah I'm thinking of proposals I've written and how the hell would I write them uh by referring to by making I guess I would have to

understand that piece of code and the reader would have to understand the piece of code well enough to even understand what you just said I mean the same is true for the yellow paper but I think this is why we shouldn't allow it like we don't want to have new specs coming through trying to describe things the way the yellow paper described it because it's not maintained okay that's a different fight I'm trying to make but if the community decides that they do not want to have a specification then I can't stop that I think if someone is maintaining it and it's like staying up to date I don't really have that much of an objection to including it I still I think I prefer I

think that's the problem though right like we aren't linking to the live version of the yellow paper so I don't see harm and linking to an older version of it you link to it for Concepts it lays out the concepts an execution spec is not conceptual and many executions back does lead the concepts out it influence the whole protocol that's the yeah but it's it's code okay it's the same way that we do the consensus layer it works fine for them I think that it's better to try and unify the approach that we take to specifying the consensus protocol both consensus and execution and because the yellow paper isn't maintained I don't think

that we should be making room for it we should focus on unification of all these things okay there are thousands of references to the yellow paper and just go to Google Scholar and search for it thousands of references and the uh the execution spec it is great to have it but it doesn't serve the purpose programmers can read it mathematicians can't necessarily read it logicians can't necessarily read it we don't have a lot of mathematicians writing eaps but a lot of people read reacts

so even though they might not go into I did they might read it and then use it and the fact that's one question I have is that one reason we we put so much restriction which I object on linking is because some link can change uh I'm a little bit curious why at this moment we are rejecting linking to yellow paper because it didn't change and get updated this seems like conflicting with the principle why we restrict linking to it in the first place and uh because expect execution respect again in the future

stop working as well can probably like if it happens to yellow paper that it stops being mentioned yeah but we have three years we're full-time people working on the execution specs and it's being funded by the foundation so I have like high confidence that it's going to continue to be maintained of course that can change but that's just what we are today yeah I I I believe this you can have high confidence just like yellow people can stop being maintained um and I I don't see the reason why that's uh um a a paper um

foreign and how it works the transition of states that has not changed it does need to be updated and I feel that we should put resources to updating it it doesn't reject us from seeing yellow paper and it's called an Academia and many other a group of people think it's super

helpful in their View and the fact that we stopped linking to it actually reduces the uh the chance that it gets no to noticed and support and we just includes excluding mathematicians and other people from even joining this conversation anyway there's just a long history of of computer languages other systems that started out with reference implementations and then wrote actual

specifications owasm went from a reference implementation to a real specification somebody found the money and paid some experts to do that and they did it um and reference of implementations are not specifications they're not they're not readable by anybody but programmers in the language in which they're written and to ask people to Learn Python uh simply in order to to participate in understanding and working with ethereum is is a big mistake and I don't think we should contribute to it and I just don't see

the problem of course in the link um as as part of the editing it is a question of does this link to the yellow paper is it something that's likely to change to be a big problem yeah maybe we allow references to yellow paper in some particular section when where we where a person is giving some background or rational I don't know why we talk about this every call like we need to bring the yellow paper up to spec and then to discuss it like we just talk about the same things we talked

about last call every single time nothing's changed in the last two weeks well sorry I just have to this agenda because I added all the other ones that wanted to add principal sources um I kind of figured we'd just be like we're at a stalemate we can't decide we'll just move on to something else and I'm sorry for putting on the agenda again um we do this a lot I just okay um maybe come back come back to it at the end of the meeting so we can get through the other stuff um is that all right with everybody just because I think this is going to be the longest discussion and we can get through the other stuff quickly so

um just for note takers uh so far we have reached consensus for the first four pull requests that could be merged and for the fifth one if we get the time today we will come back to the discussion and I'm sorry Mack if we do not get time we probably would like to discuss it further or whatever is decided depending upon if there is any request to get a discussed in the future meeting um we may be adding all right uh moving on to the next one the next one is um is not for any proposal but it's a for about a CI pump seems like it has received a thumbs up from Victor and waiting for review by Sam and Mac anyone has uh thoughts or

would like to maybe take a look at PR number 6813 CI bump yeah I'll take a look through it it's um if it's just dependencies it'll be fine to do offline sounds good the next one is here about an EIP draft which is uh now closed and it is requested by author in the comment to the agenda that he thinks that this proposal could be reconsidered and uh this PR can be allowed to merge I wonder what editors think about it if anybody merges a PR to set a definition for ebm equivalence I will submit a different definition of evm

equivalence just just to make that clear well um I think I'm on that one originally I think it was uh trivial that it doesn't seem like a EIP would be VIPs it seems like I'm slightly convinced and made neutral now with the author proposing the context where some of the um ZK DVM Solutions trying to Market them as evm compatible but in in in some of the behaviors they actually did not and so that's the background of the Erp

um and with that I I'm leaning towards neutral because I it it seems to be to me some value to clarify that if you really are avian there is certain rule that you have you can't Market anything that is not uh I see value in that and I just want to hear other EIP it was about there is absolutely value in doing it it's just we are not an authority right like no one here has the power to stop the ethereum community from advertising full evm compatibility or compliance

like adding this EIP will change nothing in the marketing world it is also okay uh or I I it's also okay that people will argue that here is one of the way that they made this argument I I don't see the reason if there's value there I don't see a strong reason not to included or at least as an informational to show some opinions but I I'm open to the to here understand so like I said when we first brought this topic up if anybody merges an EIP defining EV like evm compliance I will

make a different EIP with different evm compliance and there will be no clarity so they're like like as a thought experiment that shows that there's no reason to merge this EIP because it doesn't change anything what's the category here is it informational or any other because if it's information probably um it would not make much of a difference if someone wants to go ahead with this because it's not changing the protocol or it's not even suggesting to

follow it yeah I I think it's it's a suggestion it's more or less than a subjective and then um I I don't know if uh if there's a reason in our label to officially reject yourself I would love to hear it um like what what's our official reasons down where it says hey just because uh we don't think it matches this criteria we're rejecting it and in the future if this criteria is not met we'll go by that as well uh yeah but I also don't wanna um I will spend too much time on this uh

um maybe anyone would like to comment to or maybe respond to this proposal um in the agenda itself that would be great to have so at least author who cannot join this meeting May get a clear response or if we are open to have a discussed some other time we can do that either I I just had a question if um if it isn't I I can see the argument that the EIP group or the EIP Corpus isn't where this gets decided I feel like it's kind of a meta question is is that an execution api's question or a future iteration of the yellow paper

question like is there some Authority some community that would be qualified to say um you know uh four interrupt purposes this is the you know like for the sake of bridge safety and Bridge interoperability this is what we're defining evm as complete I don't know our PC equivalents or something like who is there another group that would be in a position to to Define that I don't think there's really a group right now but I think there probably should be some sort of coordination amongst l2s to describe what their standards are and

the interoperability amongst them like we have defined the ethereum protocol and the word equivalent has a definition and people are free to call things equivalent if they want to but if it doesn't follow the execution specs it's not ethereum and that's fine but once you start opening the door for having some flexibility on that definition I think it's like really difficult to actually describe like what are they implementing what are the deviations they're making so I think that the layer two should be doing this I think the only way to enforce this is with a trademark you could have a seal of approval from someone who owns a

trademark and then sue people who Market it incorrectly and that is the only thing that would actually make a difference in this or or maybe a a test Suite if that's imaginable it's a huge paid in the ass to write but would it be I mean and they can run it and if they pass all the tests they can say that their ethereum equivalent right so maybe that test Suite just needs to be more have uh harder tests or something right like if they're pretty hard there's a lot of

tests in there I promise you no roller passes them ah okay so then if there's already a test Suite they're failing at the very least until they're someone who feels litigious uh an informational EIP could explain that I don't know I'm just advocating for them they know they're not even equivalent they're trying to add flexibility to the word like being equal to ethereum there is yeah flexibility on this and that's fine like I get it they can do what they want to do I don't think that we should be you know trying to approve of any specific definition because our there

are several different definitions about what it means to be equivalent one one thing I'll add as well for Roll-Ups is um do not all EDM based Roll-Ups so it'd be kind of weird to have like evm equivalents be like enshrined in a way as something better like it feels like that's not quite the right level of abstraction where if L1 wants to like make a claim about what it is or isn't the roll-up um it should be something that like also includes ZK roll up it might be something more like a bridge standards or some amount of I don't know right and effectively like L2 beats is probably the best we have for doing this but

yeah there's a risk in like if you focus on the equivalent too much then it's like steadily like works for ZK Roll-Ups um yeah right like they're trying to come up with four three seven that's equivalent to cross both optimistic roles and ZK ropes that's pretty hard problem so I think trying to expand that across all of the evm is even harder and they just need to figure it out themselves I don't think that we can like enforce anything upon them there's challenges that they're going to uncover as they implement the stuff and they're going to need to make their own decisions I just don't think that the market right now values the interoperability that people are

requesting with this like evm equivalence standard yet otherwise they would be working together well it seems it's clear enough that most of the EAP editors are not in favor of having it reopen or maybe even considered for uh being a standard at ethereum repository so maybe we can give it a rest I assume from Victor's earlier conversation that he is like from favor is moving towards neutral so unless we get a strong support of editors we probably will not be able to reopen this proposal and move it forward

any final comment on this uh topic before we move on to the next one all right uh so moving on to the next item uh which is a discussion continued or updates from the past meeting the first one here listed is new contract interface and eip's uh should be required to include a privacy consideration it's issue number 5682 so initially we discussed this item in October last year and this issue has been back and forth on the EAP AP meeting this time it was added by Sam Wilson to today's agenda and I suppose it is about getting affirmation to the decision made

in the earlier meeting and proposing the changes um with a PR so Sam if you would like to maybe briefly go over the issue and reiterate the decision yeah that would be great yeah so um people really want privacy explicitly mentioned for some reason I don't really understand why um and I think I'm the only one blocking that so I think a reasonable compromise would be to rename the security consideration section to just security and privacy and that was proposed by Greg on Discord are you planning to open a full request with this uh change

I was going to but it looks like Matt doesn't want to allow us security and privacy section just to be clear this would just be renaming the security considerations to security and privacy um and you don't have to talk about privacy if you don't want to it would just be a name change so I'm assuming Matt is still not in

favor of this renaming um yeah it would be gather you know consensus from other editors I know yeah is in favor for a very long time so I'm coming to a neutral point with a little bit of change to the security consideration math not in favor Greg if you would like to add anything and get gender Singh if you have any thoughts you would like to add to this one um I'm not sure what the objections are unless we just don't want to talk about privacy um is there a single example of a core EIP

where this would have been relevant I can see for erc's it makes sense I I guess I'm just curious in interface uh in in interface and network uh it could also right um yeah so maybe only four doesn't need it and then we can exclude cord well for sure um but I do see value in having all other layers yeah I mean I I understand that just creates a bunch of like random work I'm not an editor but like I'm fine with just a name change I just wanted to make sure there's no ethereum provider in router so they're

trying to allow multiple equipment providers and then by allowing ethereum providers the involvement would be do you notify user if they should be connected and if so does it reveal your happiness and then that is by itself not an eerc problem and also you could get your transaction bounded in uh in some bundlers implication of your intention and does that involve impossible and we um so these are uh things that can get weird and core of course everything needs to be uh changed but even so I I think there might be other

configurations in the future so I'm okay the core doesn't included I do see I get convinced I start off without you know it's going to be a possible thing that I I think I get convinced that in other layers there's uh very very uh often uh ignorance of of privacy um and we some authors do want to let reader know that hey you should actually for a few minutes my concern was just that yes often

privacy considerations are important but they are often so intertwined with security issues that trying to do them is a separate section can be difficult and so it just makes more sense to to handle them together if if they're fairly separate in a proposal well you you do them in separate paragraphs but forcing them into two sections when they're relevant can just just make it too difficult and Us in the discussion somewhat linked to the uh to the ietf advice on that and specific examples there where really

they were the Privacy was a concern and it was a security concern for the user if privacy was not maintained so they just seemed closely related enough to put them in the same section and um I just I don't see a big objection there so I see a comment by Sam in a chat like if God and ERC have different rules for adding I think we should hold off until we split the repos we do have this discussion as our next agenda item so um if it is fine we can probably give it a rest and give some time to have the

discussion about splitting ercs and core eips and probably like it yeah yeah and I quickly comment on that I think there's a there's a part I didn't get talked about which is the core versus other all other VIPs not just ERC and the example of game is about interface and I do think that there's a privacy issue with network as well so if we are talking about carving alcore EIP versus all other VIPs I think that is a good discussion that we can hold on to but if we're only talking about ERC versus core and Network and and interface then I I don't think there's a good boundary

to draw uh in deciding whether they should improve privacy in section or not right yeah I think that's a good point but uh in case we get the core eip's out of this like rest of the EIP so not only just with ERC also from interface and networking I'm not sure what is the proposal here but if we do then probably getting to a consensus about this particular mode one will be way easier than it is right now all right uh so let's try to give it a rest right over here we have about 20

minutes left on the call so let's get into the um the next item which is kind of one of the biggest can of worms coming our way so the next item that we are going to discuss is about splitting ercs and core eibs most of the people on this call are very much familiar with the discussion point we have been discussing in this meeting as well I'm curious to hear what uh what has changed since last and uh what do we want to discuss for today's meeting so proposers please take it away uh sure maybe I I can start um yeah so I I guess which changed since the last time so we now have people who are like reviewing erc's and like you

know like thinking about them as like a first class thing uh sort of EIP editors and I think that was always like for me the biggest blocker where if like I didn't want to like end up in a world where we just like break out the our season like it's just like no one reviewing them um and uh Matt and Sam have like agreed that they could stay on as editors on both sides if we were to split things so um yeah I think having that um like means we have probably like the the the capacity to handle both repos um in terms of why we should split them like I think high level is just there's

different they're like very different users for each type of like eips whether that's like uh erc's or like protocol changes um and talking with fine teams you know it's like increasingly like every every time we talk with them basically they say they'd rather have it split and they'd like to see the eip's process sort of evolve in a Direction that's like more closely coupled to like protocol development and similarly you know there's a bunch of things that can imagine from the ERC sites where it would make sense for that to evolve to a world like towards something that's more coupled with like application error development um yeah so I don't think there's like any like huge new reason for like why we want to do this I think it's something

that like at least on the core side like pretty much all the users or like folk type direct with who like write the IDS would rather have this changed um and if we have the resources to do it I think it makes sense to you um yeah I'll pause here but it's the background foreign [Music] I think networking probably makes so I

think core Network and networking makes sense together for sure interface is a bit of a weird one um I like I don't have a strong opinion um I could see it go either way and maybe it gets duplicated like across both categories um and uh yeah honestly like maybe interface meta and informational sort of get duplicated or sensed to one side or the other I don't have a strong view on that I think um core networking makes sense together meta probably makes sense more on the core side uh just because of how it's been used historically um

seem like maybe they could just be duplicated um and then yeah so the question okay of numbering my my very simple proposal for numbering is like you use odd numbers on one side even numbers on the other side so we we're moving to the bot and you just have the bot you know module one module zero zero depending on which repo you're in so like you you you sort of start from the same number and that means you're gonna have to hard code it you know uh on on one side but like say you you started from number eight thousand or whatever then you just like increment using uh yeah uh even or odd um

twins sorry they're gonna be like Siamese twins yes basically uh joined at the hip for life well hopefully over time they can like each walk their own way and like when they start they start their numbering system separately and people go oh these two numbering systems are independent otherwise it's just sort of I don't know this this whole discussion has struck me as so stupid from the very start well sure but like literally every client's Dev I speak with

would rather see this so and like I get that you object to it um it seems like yeah it just seems like yeah what do you really want splitting there I think it's just it's just an administrative system that we use to file things and give them numbers and run some Bots um the conceptual distinction is what matters um and that so we don't want to set the same process down for both like it would be nice if we could have some of the process be different for erc's and right now it's not easy to do that what these are really different right it is a little different that to finalize

your routine absolutely be going through the hardwood that's not that's not the requirement [Music] I think yeah it is you know it's in the ip1 it's I don't think it's in the ip1 so the present present difference between core and you know any other proposal is like core um generally is when it is with a network upgrade we keep on waiting the last period I mean like when it reaches to last call that also happens when it goes on test net not before that so there are certain criterias which kind of keep it separate from rest of the

proposal so it is different I think it would be interesting to understand what is this what is that is blocking you know um because it is sure yeah yeah so this is block it just adds a bunch of random friction and you can imagine you know it's like we're we're always like contrasting what's like the state today but you can imagine a world that's like we actually have like a really well-coupled process where say they go to the last call there's something like this is actually implemented or has like a series of tests you know in like execution tests and we can just get like more specific around like what are the technical requirements for like core eips

um I think over time as well as we incorporate more of like the CL stuff into it it just like reduces having to coordinate between CL and El is already kind of hard having to coordinate between like erc's and eip's is already kind of hard so like you know just reducing that the like CL and El gives you um yeah just like less people to coordinate with um and and it doesn't mean again like you know some of the actual people might stay on both sides and like I think but and I think yeah it just opens the door as well to like folks in the application they are like that feel like this is their space and like that process can evolve more towards like an application standardization process which is

different eips are like very they're like something stronger in a way than a standard where like you're not forced to use the erc20 standard right like you can deploy a contract and create a token that doesn't use it but like you do have to implement the IP 1559 if you want to run ethereum and there is like a subtle but like important difference there and yeah I I think just like they're literally different things that we're trying to do and they sort of started out bundled together but yeah it just makes sense to like have them logically separated a bit more yeah

ETF manages a huge range of documents some of which are informational some of which directly affect the Internet Protocol others of which Define applications that people may or may not run and they run a single editorial staff they have a single numbering system um and you know I've said we've got issues we need to solve that we keep going oh we'll split the repo but that doesn't actually solve the issues it creates issues of its own um and it comes down to things like well eip1 will get a bit more complicated

well we can hit so the ip1 has two chapters or we decide that we're going to have a different EIP for these things it's just it introduces complications and I don't see that it that it wins us a whole lot um the numbering thing I keep coming back to that because it simply means we haven't actually separated the processes we have to like coordinate the numbering forever um and repost yeah I don't think there's anything we can do about that like we started with them together and yes like we don't like the repos that's then we

don't have this problem so I mean we just made a mistake in the beginning putting them together they're like totally separate types of things that we're trying to coordinate around one is core eips that everyone has to implement they have to agree on otherwise they're Left Behind then you have the erc's which is like way more similar to internet standards where it's like this is the state of the art this is how it's specified you should probably use it but you don't have to you can do whatever you want and I just think like it doesn't make sense to tie these two things together so the ietf should actually have two separate editorial things there's nothing in the it ietf that everybody has to implement people can do whatever they want there is no

concept of consensus RFC 1034 is a DNS standard so if you don't use them you don't get DNS um yeah I mean sure same thing with HTTP if you don't Implement HTTP you don't get HTTP but it's like you don't have to use HTTP you don't have to use DNS you can Implement you can come up with your own protocol for finding the IP addresses of names ens like we have other ways of doing these things or with that logic if you don't want to use a theory we don't have to use ethereum but then again exactly and you can go as VIPs to Bitcoins repository and that's that's where I'm going with this it's like um the ietf is so General that it

standardizes it considered as multiple competing protocols like uh POP3 and IMAP let's say whereas we are specifically in ethereum document repository and there are certain documents that if you don't Implement you can't be on ethereum so there's a slight difference between us and the ietf but for erc's I think it's a way more similar analogy like you don't have to implement erc20s in your protocol you can use a different token standard right there can be competing parallel implementations of erc's there cannot be for eips like at least like that or final right like there can be two there's there's been like three withdrawal eips but at the end of the day it's like 4895 is the spec right and

all the other ones are just like that then drafts and that's like a fundamental difference but that's the idea with the standardization here like what I have observed so far uh when ERC are being edited ERC are being reviewed we generally try to make sure that there is no existing standard which already has the same kind of specification unless there is some improvement or unless that specifies that it is based on top of an earlier existing ERC standard then only it is allowed so I and I use sorry you can still use the RC 20s even though ERC 1155s exist you can argue that like 1155s are better but like it

doesn't block people from using years and 20s whereas today like on a theory like on Main net when we change the gas costs you can argue that the old gas costs were better but you you can't use the old gas cost like and that's the the difference right you like force everyone on that change foreign in some cases so I like to use poor VIP versus all other VIP and I see strong value in keeping them in the same repository and then keeping people so that people can have an eye on both

sides um I I don't think it's a it's a bug to begin with it's actually a good thing um one example is that metallic himself tried three times to go for account abstraction and two of them were using we're trying to evolve it in the course aspect and then we didn't win very small and then so account abstraction uh the 4337 is attempting on a different layer so that kind of knowledge does not get propagate very far if you have people working in Silo and and that's why I think having four uh having four EIP versus other VIP would be that would be a good idea in in the same in the same

place but we can definitely if the problem is about people don't like putting in the IP uh and they go to a random repo I'm fully with you I think we put so much burden in other in too much restriction in author and I'm always a big fan of relaxing it and like we don't allow other considerations we thought a lot of people put for uh private we just make up this reason that I don't feel very strong and then um over any author who want to do this um we seems to be in in a way of work and then it would not be changed even if the core EIP is I I I bet that is going to be the case as well I don't see very convincing uh argument right now how harp it out you can actually let people

come over with the current set of rules yeah so unless that is dissolved I don't think this is a um I want to see people coming and and use this as their way there is a place to help drop their VIP by making I mean the idea is that we're going to be able to then evolve these processes and slightly separately like you have all these things that you feel are important to do for the process and I have to argue against it because I don't feel it's very important in the core process or it doesn't align with the core process and we're spending tons of time debating all these things and I think they would be useful if they were just for ercs and I want to unlock this

so that you and other people involved with erc's can experiment with it I mean non-core right are you are referring non-core or do you refer to interface and in other words I mean there's so few networking I mean I think we should deprecate networking there's not very many interface I'm specifically talking with erc's this is the biggest ear this is the biggest EAP category by far what do you think about the interface I mean I think generally we should also deprecate interface because we have execution apis which covers the majority of the interface the types of things that interface standardize the one place

where it's a little bit confusing is around like JavaScript libraries and they're wanting to have standards and I think that you know maybe it's painful but they should probably migrate to interface on ercs and just like call them ercs I don't really care that much though like there's so few of them they could stay eaps too like it doesn't really matter to me up until now I feel that ERC is not about anything to be to be standardizing on small contrast so I feel it's very confusing to put um when you say that's uh they should migrate the the JavaScript library on cbrcs and uh no I'm saying that they should refer to their standards as ERC interface standard

ERC website provider standard right now to interface EIP right now right yeah I'm saying that we should get rid of interface eips also and call them like erc's and move them to the ERC repository like things that are related to the application layer I think this should live and be erc's and things more related to the core layer I think should be like eips if we divide it by audience right so the people who are implementing it and like and generally speaking like networking and core will be implemented together um so they should be in repository together and like interface and erst will likely be implemented together so they should live together

I guess yeah just because uh to be mindful of time like I my suggestion would be like I can bring this up on the next all core devs and see what clients thinks but I think if the client teams strongly desire this like given the core EIP process is effectively there as a way to like standardize what is mostly their work I would like like to move forward with this um but I'm happy to yeah check in on all core devs and like be if there's like broad support for this uh my client teams can we uh have a list of items that they

think it's really bad and hard for you to do in in EIP uh in the current EIP we probably and then I I felt like a lot of things exist in our policy restriction like I I I was involved in in the complaints that uh people cannot even link to execution is back and that's that's one of the reasons they just stop proposing that I saw one of the MP just started in the draft status because of one of the one one case in that so I love to see what's the real reason that they don't like to come to European and we should fix that I really feel we should fix our EIP and just relax our

research restrictions we can't relate to what yellow paper we can't list a lot of things I don't want to ask them to come up with a laundry list things they don't like about the IP process like we've asked them this in the past they absolutely hate the EIP process more or less like this is not going over well wait but a lot of times it's I I have to be to respectfully spend uh disagree with you got a lot of policy is where's that direction and I just trying to avoid those things every single day and they do not like the EIP process we've turned into a joy to them

uh oh yeah all like slightly uh nuanced this like I do think people have appreciated like the small like there's been like a bunch of small chains at the margin in in like the past year or two like I think and like having new editors actually work on stuff has been helpful so I don't want to like uh like completely dismiss the changes but I think it's I I would agree though it's like almost asking them about like what they don't like it like people feel very checked out from the EIP process in a way where like they just feel like it's like this thing that they don't really have control over or like every time they engage with it it's like not the best

experience and like splitting the process basically gives them like ownership over the thing where it's like um yeah this can now be the process that's focused with like core development and like we can just not have any other considerations beyond that as we're doing changes to it um I do need to hop as well though unfortunately um but is it helpful to put this on the awkward as agenda for next week or do people feel like there's not any value there I would also love to hear more thoughts about like what specific changes like client teams are looking to have in the new process that is going to make it different from the present process and

that's why it would be useful for them to have a new process all together okay I'll add that at the end of awkwardness tomorrow uh actually next week if we have time we'll get into it like if it's possible we run over and and don't have time to get into that but I think yeah um I think we should know like if the core teams say that they want to get rid of the erc's from the core repository are we going to do it or are we just going to come back to this call and block it like I said in chat we don't need consensus on this we do kind of need consensus though like we do not I mean of course we can just Fork the repository and do whatever we want but

that's just like we we want to have a subdomain on ethereum.org that says ercs and eips and somebody has to decide who you know picks the repository that it points to and those people are kind of us right now yeah I mean laughs I'm happy to sit in the corner in a core group and ask what kind of history and then we can make that uh list and see if it's it's doable and maybe they'll come up with it with the ideal states that it's achievable and then either it's by forking that's fine either it's not the core devs are not going to babysit the EIP process they don't want to sit and engage they

have so many breakout rooms and other things to do they're not going to try and talk about the process that's they that's their least favorite thing to do they don't even want to go to the calls where they talk about the technical things they're not going to engage with us and and then they will have repository they lose control of and then they will feel bad and then they'll go to random places they don't have control of this repository I'm trying to provide some sort of viewpoint to you guys about how they feel about the Repository and they don't want to deal with erc's I have never blocked a uh a a updates in it they don't have to they don't even have to look at what writing but uh I I don't see a lot of us have not bought any blocked any of the their their their

their their edits this is this is why whenever we added to originally as an ERC editor that I didn't want to like add you as a full editor because then we would have to debate like the merits of doing things at core and comparing them with erc's and again here like we're just debating about you're saying that it's okay for core developers and I'm saying as a core developer and as someone who's working with them on a day-to-day basis that it's not okay and now we're in the stalemate and you're going to block the ability to like remove erc's I'll block it too it doesn't solve the problem it's just it's a bookkeeping system it's a filing cabinet and we're arguing about well if

we put things in different filing cabinets it'll solve a problem it won't solve the problem when is the last time that you utilize the GitHub notifications to interact with the eaves Repository I can use I use a different way and then on the other hand um I'm here to provide aspect of the Arty authors I feel it's not very well represented um even though the majority of the uh a portion of it is from Erp and then I didn't know that when you uh use that comment I think it was a bit personal um I don't want to go that go down that route but I do believe that there's a lot of value in having people look at the both side of the category as well

and then my my argument is that splitting it doesn't solve the problem uh just like you um and you are still going to block and make it very hard in the in the future for all the new core EIP reports three of food for them to add it and then they will be unhappy um so that's that's will be my argument whether that you believe it or not I'm not sure um but uh yeah that's that's my opinion um yeah I think we are over time we will be probably listening to more from directly from the Codex in the next all code I'm meeting it would be really interesting to hear their thoughts like

what they are trying to introduce as a core EIP process uh that is going to help them if that is something really good I would hope that ERC or any other category process should also Implement those changes it would be nice to have changes which are going to make life simple of new Authors if that's okay we can probably wrap it at this point and we'll look forward to the decision or suggestions coming up from the all code I'm meeting so I know we had a couple of more items those are really quick one is eips Insight I have already added the list of proposals here we received one EIP in

final status and that is uh of course ERC category we did receive eight drafts out of those eight one is um core and rest 7 are ERC drafts we have only one proposal in last call with deadline 15th August the proposal is 6093 for rest of the details people may refer to the hack MD or the eipsinsite.com we did have a EIP editing office hour yesterday recording from the past meeting is added and also the agenda where authors can add their pull requests to be discussed in their next meeting if it is not merged before the next one I have also added the summary from the

last meeting also shared by Sam Wilson on the eat r d Discord please check it out and yeah thank you everyone for joining us today hope to see some good reference point from the next alcorder meeting to have it discussed in this meeting have a good one everyone thank you for joining foreign