EIPIP Meeting #128

Transcript

[music] [music] Heat. Heat. Jesus. Thank you.

Heat. Heat. [music] Heat. Heat.

>> [music] >> Heat. Heat. [music]

>> Welcome to EIP IP meeting number 128. This is issue number 21106 on Ethereum/PM GitHub repository. On agenda we have uh some call for input, editors discussion, a few policy discussion item that we can collect editors thoughts uh followed by updates from earlier meetings EIP insight and I believe we also have got a demo today uh with the EIP lab team and I see the contributor has also joined but we will go ahead and get started with the first item which is call for input.

Um, welcome editors and over to you Sam. >> Sure. So, um, the first one 393 is just, um, [sighs] waiting for the second PR to get another editor approval. Um, I can't force merge things anymore. So, uh, working on that at the for the time being, but if somebody else wants to approve it, um, that'll get merged and we can close the call for input. Uh then we have 398 which is um light clients PR. Um what are we waiting for on this one?

Um this is just waiting for an implementation which I guess there is one here. So we need to go and approve that. Yeah. Okay. I think Matt just needs to mark this as ready for review and then we're good to go. Uh, and then it is I don't think we need anymore. Um, >> Sam, we are losing you.

and we cannot hear you anymore. >> I'll switch computers. >> Okay, >> that's the end of conference. I'll be right back. I think we could not collect what you mentioned for the last one. If you would like to maybe repeat. Oh, you have merged it. Okay. Cool, cool, cool.

So that's it for call for input and let's move on to the next one. So next are a few items which are there for editors discussion. Uh I think the first item is okay I have received this as an issue on EIP's GitHub repository. U just wanted to bring it here in this meeting. So editors may take a look. I already see Yam has [music] added some response. Wonder uh if people would like to discuss this. Yokam if you would like to maybe initiate with your thought here uh capture your thoughts and then it can [music] be discussed a little bit more.

>> Yes. Uh so are we talking [music] about EIP 11845 PR >> that is right yes sorry uh sorry it is the issue number 1658. Let me add it here in the chat. Uh so that's about the reduced duplication and drift between Ethereum [music] EIPs and ERC. >> H right. Oh sorry this this one. Yeah. yeah I like I think this is pretty straightforward because uh we like in the past we moved the ERC's uh to a new repository uh and there is a [music]

drift between the uh shared files and the idea from Ryan is to to well one of the ideas is to have an an shared [music] infrastructure repository where both of these repositories point to. I think this is the uh the logical choice here. So I think we should we should do that. So in order to keep all the fells in sync with each other that we do not have uh two versions [music] of the fells for each uh for either the EIPs or the ERC's. This is more or less correct. I'm I'm sure that we do have to duplicate the work on EIP1 [music] as well. U but I wonder if there is a way to have shared resources. Sam, do you have any thoughts

on that? >> Sorry, I just got back. Um, what what thoughts do I need to have? >> So, uh, we were talking about the, uh, duplication of work that has arisen because of the repo split. Um, we are talking about issue number 1658 on EIP repository. It talks about um how we can have shared resources. I know for now we have to like make two PRs for EIP1. One is on EIP repo and one is on ERC repo in order to keep both of them in sync. Y >> but there are other issues as well. I wonder if there is a way to maybe unify

the effort and we don't have to duplicate it. Um, in the long term, I think EPSWG is the way to do that, assuming that we actually go down that road. In the short term, I think, uh, the idea of maybe using subm modules is, um, something we could do. Uh, we'd still have to make a PR to both repositories in that case to update the subm module commit hash, but at least they'd be in sync. Um, what other option? I guess we could also um just put it into a third repository and then clone it as part of the build and then you wouldn't have to make any pull requests or or any um bump any commits for the subm module. Um

yeah uh any of those options would work. Um do we have a preference for something like that? >> I mean I'm open wherever user does not have to duplicate the word. So subm module is an optimum way to move forward. It's fine. Um Yokam if you have any preferences around you. >> Yeah I think my light preference is the the the subm module [music] but uh Sam is right like we do not want to to add any [music] work for for the Y users because then we well uh people will [music] run into problems. Um so yeah if we find if there's like a way to do this in a very uh easy way uh such that the user does not have to do any more

comments then that [music] would be nice but I don't think there is one where we force clone a repository I think we have to do the subm module [music] in it anyways uh so we think if it points to that command very [music] clearly in the readme then I think that that should sounds good to me.

So I wonder if uh if anyone would like to own this responsibility some uh is it something that can be like you know you can maybe take care of >> um I don't want to commit to adding more things onto my plate right now but uh >> or maybe if you could maybe if you could create an issue where you can like uh describe what is required then we can share it with the community to ask for some help around that look. Yeah, >> I can write that up.

>> Yeah, I guess that would be an easier step. So, it's not on someone. It is something that is open uh for the cup. Cool. Uh the next item here is with respect to Glamsterdam, but I would like to maybe uh go ahead with the third PR here. not the second one. So the PR number is183 which is a glamsterdam PR. It seems [music] that it has received the author's approval. Uh Sam, you had shared some uh some uh suggestions which I have already incorporated. If you can maybe able to approve it, it will be merged.

Uh have >> uh this needs to be rebased I think. Um assuming that 7 92 8 has been [music] merged >> but it is not showing any base [music] I mean merge issues is it? Oh yeah 7928. Okay fine I'll go ahead. >> Yeah. So it just needs to be rebased. >> Yeah. So if I rebase it will it be merged or do you uh I mean like uh >> I'll uh I'll approve it and then it'll merge once you rebase it. >> Okay. Perfect. That makes sense. Cool. And then after that we can go to uh another PR which is there for EIP 8037 and the number is183. [music] I guess this is very similar to

situation which Yokam has highlighted in the discord channel. So uh Yokam if you would like to maybe talk first about the issue where we are seeing PR EIP dependency [music] and then we can also take a look at Maria's suggestion here. Uh yes, sorry because which which PR is this? 1183. >> That's right. 883. [music] >> Oops. Sorry. I'm [clears throat] so sorry. I don't know why my copy did not work. So this PR number is 1879 of Maria's PR.

So basically >> basically this EIP 8037 [music] is dependent on 1 2 3 4 5 6 7 8 9 10 EIPs. [laughter] >> Yes. Yeah. I see. Yeah. I I mean like the only comments I have here is that uh we should follow the procedure and that's that that all the EPS mentioned uh should be in review. The only thing is that there could of course be cases where we want to make an an exception to this but I I don't don't want to make like a lot of exceptions. There could be links to EIP which are are like of a historical value or like as an educational value. So these are that

could be sentences like okay uh we have tried this in the past but it didn't work out. And if you link to this EIP which could be stagnant or draft that the office will not move to a higher stage then that could be it could be a reason to um to to to to still move these EIPS to a higher level of of phase. U but I would also think that that we might want to avoid that because this will then happen again in last call. It will also happen in in final.

Uh so I think the [music] suggestion is then okay maybe maybe remove remove it but yeah for this EIP all of them should first move to review and then we can then it will auto merge so not not auto merge but then we can can approve it because the bot is also failing [music] for this uh this one. >> Yeah I think I have created a PR for each of the EIPs which is added and requires here in order to move all of them in review. We can definitely wait for authors to approve that. Um, [music] and maybe editors can go ahead and add approval as well. Um, so when authors approve, it will automatically merge and we don't have to wait for authors. Uh,

we don't have to wait for editors approval again. >> That's that's a good point. Um yeah, one of the policies I want to do myself is I want to really uh because moving these things to a new phase is on itself fine. Uh but I really want to [music] uh especially with these clams EIPs, I want to check that these EIPs are actually correct because um they [music] depend on each other and they are sometimes have conflicting definitions and I do not want to move [music] an EIP in review which is clearly still not ready for for review if that makes sense.

>> No, I agree. I totally agree because moving to review status is moving it to a more responsible status where we feel that EIP is more prepared. Uh the other day Sam was reviewing a proposal of Amsterdam and it took about 40 minutes. The PR was just to move from draft to review because the proposal was already in CFI and it took longer. So we understand that but here's the thing like we are not getting enough attention from authors and if we don't then it would be very difficult to move it on to these statuses and uh at this moment currently we should be having all the EIPs and last call because we are very close to public test net public test net means last call I don't know if there is

any solution around that how do [music] we think we can maybe inspire authors to take a look at the PRs Yes. Or maybe we create one. >> Yes. Uh so so like I agree that based on the process these EIPs should already be in last call. Um but okay that this is specifically also because I [music] am working on these the testing part of this these EIPs. But the problem is that the uh and this is like a symptom of a problem of the the process [music] itself because these EIPs so we have 8037 EIP 8037 we have EIP 2780 and we have EIP 8038 these are all [music] repricing EIPs and the problem is that

if you re if you you if you would print out these EIPs then there are conflicting definitions uh on them and the problem is that we are also still doing spec changes for for these Um and okay so let let me just think out loud because the thing is that if I would move it to review then on this pass I could do like a check okay are these EIP consistent the problem is that still [music] spec changes are coming in so that would mean that if and if the EIP moves to review then a spec change comes in then it can become [music] inconsistent again um so yeah I don't know I okay I I think I start to to move a little bit to to approve moving this

to review [music] but with the explicit comment that we we should improve the consistency of these these EIPs. Um yeah [music] I will I will think about it a little bit but if if Sam thinks it is fine then then Sam can also approve. >> Yeah I think review is fine. Um I think that's um acceptable but uh yeah obviously they should be consistent before going into final or last call. Right. So my goal here is to let all the proposal be moved to review. So there should not be any blocker and we can even move the meta EIP to review status and then I will take it to ACD call and request all the authors to like sensibly

look into all the PRs because I know for each of the EIPs there are more than one open PR which should be addressed before the status change but the status change PR is just to bring them to a right status and I will request them to maybe take a look at it address all the PRs close it and then make a new PR to move it to the last call. I believe we still have got couple of weeks before we can transition all of those to the last call. So u editors please take a look at the open PRs for Glamsterdam especially and yeah if you can add approval it will just be waiting on author's approval

which I'll be following up in the background with that maybe we can move on to the next one. The next one is EIP1 update uh I believe it is added by Yohham. Um I guess it is done by Dan Yokam if you would want to provide updates on >> Yes. Uh let me find if you if you could link the uh EIPR in the chat [music] then I know that we are talking about the Yeah. Okay. 11845. Okay. So this uh is an update to EIP1.

Uh the context of this is that the we currently have the allowed [music] URLs which allows the execution spec tests URL. The thing is that this repository is being u well I don't know what the right term is like archived or deprecated or whatever but it should not be used anymore to uh uh to to link to because all these URLs are moves from [music] execution spec tests to the execution specs repository. This is the reason why uh this URL is [music] removed from um from the EIP. But we have a procedure [music] which I think Sam knows the exact number of this to uh to to to [music] propose changes to the URLs and we shall

discuss this. So we we yeah that's that's what uh 5757 is the process for adding them. Removing them I think we can just do I don't think there's [music] any process for it. like if if um >> which EIP [music] sorry 56 >> I think it's EIP 5757 ah yes yeah that's correct uh but it has a rule for any appro the original removal rule maybe I didn't read this correctly so it says original removal any approved written that ceases to satisfy the above requirements must be removed from EP1 if a removed or written later satisfies the

required again it may be reapproved by following the process discussed oh okay okay right okay so there's there is basically we we shouldn't even have to discuss this so I well not I but we as editors can approve this uh >> exactly yeah >> update >> okay great yeah okay thanks yeah >> but since this is an PR2 EIP1 it might require two editors approval so yeah kindly add [music] approval Cool. Uh with that we can move on to the next one. 1 2 3 4 5. The next five issues/prs which are listed on agenda I believe they can be closed. So we don't want to

go ahead and discuss each one of them but I would request editors to maybe take a look at it and if you can uh you have permission may be able to close them if you find appropriate or just leave a thought why it cannot be closed so we can address it later. Moving ahead, there are a few items for policy discussion. The first one is ETHbot [music] merging and EIPW related uh some concerns. Yam has added a detailed [music] comment about that. Um um Yam if you would like to maybe u summarize the comment and what are we looking to discuss as well get a decision on today.

>> Yes. Uh so for the EAP for the sorry for the merging related points there are two two points. Uh the first is that I think because it currently seems that if Ebot merges the uh APR it uh squashes all the commits which I [music] think is fine. Um but what it does not do is it will not put any offers [music] or co-authors of um of these comments as >> that's annoying as as yes as as quest and I think we should do that because [music] of the yeah accountability or the kid blame or the whatever. Yeah.

So the main question is here uh and I can also open an issue for ebot but uh that's this this [music] should be changed because >> that's perfect. >> Yeah I think that's un unobjectionable. >> Okay no okay that's great. Okay cool then uh yeah I will get an issue for this and then we can follow up for that. Uh yeah and then the other point is that um if you check the uh comments of in the EIP repository on GitHub then [music] for uh well in most cases if you do scratch merge then in the URL or well in in the the the commit text you can directly click on the PR number and then

you can go to the PR and I think this is like very handy because uh then you can also see like to uh you directly check like any reviews or any uh any whatever. Um so that's the second point. I can also open an issue for this one that we somehow figure out how we can make the Eve bot related merges also point to these PRs which get merged. >> That should be a well I mean it would just be adding it to the the commit message I think in Ebot. So that shouldn't be too hard. Um, yeah, it should be pretty easy to do.

Yeah, it should just be updating the the the commit message to include the the both the authors and the the PR number. So, could do that at the same time. Okay. Yeah, I can I I will just move on to the other points which I had. Uh so this is the other [music] that's the third point. This is about the EPW rules. This is just for uh making our [music] lives as editors somewhat easier because then we let the block uh sorry the bot flag specific problems with the EIP uh directly because I often find myself that for

instance the EIP [music] or ESC's on the first reference must have an URL link. So you link to uh dotapix.md >> that one should be there already. >> Okay. Then if if if it should be there then I think that in one of the repositories then this this rule is [music] either disabled or it does not work because I keep uh flagging this on [music] you. Uh okay maybe >> yeah if you have a link uh send it my way and I'll take a look at it.

>> Yeah. Okay. I I will do that. Yeah. And yeah. Okay. [music] So, and the second point is basically the same but then for RFC's. So, we have like this this sentence with RFC I think 211. Well, uh which describes these words like must and should and and and those Oh, wait. It's actually in the comments. So, RFC 2119 and RFC 8174. It's very handy to directly have this URL to the RFC's u um website so that you can directly look up like okay what's actually being meant. Some EIP office or ESC offers do not directly link link to this. I think we should also enforce

that if this is not already being done. >> I will add an issue for that. >> Okay. And then the final one is the copyright waiver enforcement. So we have that uh in EAP1 we say that this specific line should be included as copyright. [music] Uh most EAP offers do this but some of them do not. Uh they link [music] to the CC0 copyright of the um to a website and not to the [music] copy which we have in the repository which should be the actual line there. So we should also enforce that.

>> Yeah, somebody opened a pull request for that 11 hours ago. So I will take a look at that. Okay. Well, that's that's great timing. [music] Okay. Really cool. Okay, let me I I will just continue on these uh these points. Let [music] me figure figure out what I want with this solidity code. Um yes. Okay. So this is about uh yeah solidity and we have solidity template code in EIPs which um well [music] as as as you can see on the

on the pa screen what it does is it imports these interfaces from at [music] permit 2/inface and this is an external library and my question is do we want this and I think because we do not want uh or we we we [music] ban exter external URLs. I think we also should not want external libraries to be used [music] in this case, but I'm not not super sure because this is like super limiting especially for these interfaces. But yeah, rules is written we shouldn't be allowing them.

I we've been fairly flexible on it because it's very very annoying if we if we don't allow that. Uh because then you'd have to define every um like interface yourself. Uh but yeah, like we technically shouldn't be allowing them. So we should probably enforce that rule. Oh yeah, I mean in the reference implementation section, I think it's probably okay. I think people can generally find out where to find these things, but uh I'm not entirely sure like what do you think?

>> Yeah. So, so I'm I'm also not entirely sure because like one of the the the main reasons why we for instance do not want external URLs is because these can change. Uh that's the same problem with these kind of interfaces. Of course like this at permit 2 seems to be a uh interface which is version two and this should not have any structural changes uh to this interface. So this should be [music] fine. Uh but yeah then again if you start to enforce this this is indeed as you say incredibly annoying. U but the point that you made about this should be okay in the reference implementation I think that's that's a very good point. So what we do uh what

we should maybe uh write down as a rule or whatever that [music] uh inside the specification section we would maybe not want this. So for these interfaces what what you would do there is you would indeed copy the interfaces which you use into your uh specification directly well into the specification such that that there is no way to to uh to get confused or or whatever but that this is allowed in the reference so in the in any section which [music] is not specification. So we have like hard rules for specification but not for these other sectors that you can then use these external libraries.

>> Yep. That makes perfect sense. And for the reference implementation, I think it's generally okay because we don't expect people to literally run the reference implementation. So seeing the actual code that they're importing isn't necessarily that important cuz it's just illustrative like there's no normative um [music] stuff inside the reference implementation. So I think I think it's okay for them to be there. Um, yeah, I think that makes sense. >> Cool.

>> Yeah, I I that's also like a very good point that the reference [music] implementation is not uh intended to be used as copy and it could also really assume that people would not like just blind copy these. Yeah, I think >> I would certainly hope not. >> Yeah, exactly. Yeah, but sometimes you get surprised, right? Yeah. Um, okay. I think I will move to the fifth point. So um one of the things I I think Sam you this is already into the um into the contributing rules or like in the guidelines and I also see that you are enforcing this on reviews. So the point is that we only want to enforce RFC 2119 keywords in the specification section.

And the reason for this is that um I've seen your reviews also stating this or maybe it's also in the in the rule or both that um if these normative keywords are outside the specification section then uh in some cases it really feels like this is not uh uh [music] intended to be used as this RFC 2119 uh keyword but instead like as an emphasis [music] and uh the fact that we do not want these keywords outside [music] the specification section because that could uh uh um basically create new specification rules outside specification section which is not what we want because these rules

should all be in [music] the specification section and not outside it. So you you can as an implement be sure if I follow if I [music] yeah would only of course don't do that but if I would only read the specification section [music] then I can then I am sure that all the rules are in there and there are not not like some other edge cases or rules or whatever uh inside uh for inance like the security section [music] this is also very interesting one where we see like a lot of these RC keywords. So um yeah okay I I guess what the point what I wanted to raise here is that I think we should really start to enforce this. So we do not allow these keywords outside the specification

section. So the the way to fix this is very simple. You will just lowerase all these keywords. >> Yep. Yeah. Exactly. So, uh, we could make EW detect them and then if it finds them outside the specification section, it just says like use lowerase or put in the specification section. Yep. Cool. Cool. And then the last point is uh yeah, it's a very small one. We we are currently using the master bench on the EIP, [music] ESC's and RIP repositories. Uh I think we should change the default branch to main because this is the new uh canonical name for well the the the [music] main branch of repositories.

This comes up fairly often, maybe once a year we talk about it. And um my opinion on it is it's not broken. Don't change it. Um changing it will break all of the downstream EIP tooling. it'll make us have to change all of our scripts and stuff and um I don't I don't really see the point in changing it. >> Okay. Yeah, it is also not a very hard requirement for me but uh yeah, I just wanted to [music] raise it. Yeah, and you were right. This will break a lot of things. Yeah, good point.

>> Cool. Um so with that I I guess we have some action items per se each uh discussion point over there. Um you want to add anything more on that Yam or maybe we can move on to the next item? >> No I'm actually very surprised that we could go through this so fast. So that's that's very nice. Yeah I will create these issues and action items and uh yeah thanks. >> Awesome. Thank you. >> Very well. So let's move on to the next item for discussion which is discuss changes to uh changes for EIP 77 23 which is uh networking. Yeah. So this uh EIP uh let me open the EIP as well so we have a

good view of so this is network upgrade inclusion stage. It talks about uh which all stages an EIP goes through when it is being considered for an upgrade. So we understand that EIP status and EIP [music] stage are two different thing. The status is something then we see the maturity of technical documentation and stages are the consideration of that proposal and being tested from [music] DevNet uh through public test net to test net and finally on the mainet. Um the discussion point here is uh about [music] clarity on upgrade stages and statuses.

My understanding I just have shared. I want to check with editors. Do we feel uh there is some kind of inconsistency [music] or there should be more clarity about upgrade stage and EIP status in the first [music] place? >> Yeah. Um so I I think that we as [music] EIP editors should actually not interfere with the fork process. So this is about um uh well the the rules which the current canonical EIP7723 I think. Um so this network upgrade yeah this one. Um so this

has has creates the the rules for uh well what's network upgrade how do we do this what what is this proposal inclusion considered scheduled and declined etc etc um and you were right like the this claps then meta should indeed move to review the problem is that if you then have all of these EIPs in the client for inclusion is that um these EIPs themselves should also in review phase. Well, of course, we can imagine that the client EIPs [music] are not really expected to have a status of review yet. Of course, they can, but most of [music] them will not have the status because they will all be draft.

The thing is that this uh network process also [music] has some rules or some some notations about the status of this decline for inclusion. Um which [music] then which my main point on the PR which is currently [music] open. So move this EIP7773 to review which is the Clemson meta EIP is that uh in [music] order to um pass the Ebot we [music] would have we will need to have all the EIPS in the review phase which we won't have because [music] then uh all the declines for inclusion EIPS will not reach this status. The uh consequence of this is that we then remove all the declines for

inclusion EIPs from the EIP itself which I am not entirely sure if that's the correct move. But on the other hand in the we can of course see this in the g history of the fail if it was declined for inclusion in the past and uh what we also know is that by the uh fork process policy [music] is that the final version of the EIP won't have the declined EIPs in [music] it anyways. Um, so I think this is fine and if there is like any need for an EIP offer to prove that an EIP was declined in Amsterdam, then you can do that via the git history. Um, yeah.

So I want to make a few points [music] here. First of all, I have a strong belief that uh this EIP7723 might need some correction [music] at some places. So I started this conversation with the differentiating between status and stage and I believe EIP 7723 is specifically talking about network upgrade inclusion stages. So when we say that define the stage that EIP goes through the process of planning and we have defined all these stages. So I will be coming back on decline for inclusion a little later. First I want to talk about this proposal because I

feel like this proposal might require some changes in right here so we we do not get confused. I have uh opened an EI uh sorry, opened a PR a while ago. Let me let me try to open it right here. that suggests that uh in this EIP in this EIP uh there is confusion on usage of the word status and stages. It is saying that all EIP status.

Okay, this is a correct version. I'm sorry. I'm I'm just trying to put it together. Okay, so my idea is that first of all, we need the clarity between stage and status. They should not be mixed together, right? So when we say that all EIP statuses apply to single network upgrade, EIP must be proposed, considered, decline and scheduled. Which means here statuses are referring to P proposed considered decline in schedule which needs to be corrected. It should be [music] stages. That's my understanding. And similarly I have seen that this this is uh interwapped and used [music] at multiple places. For the

correction of this I have created this PR back in January and it is still waiting. I have not received any comment from authors why this is not being merged. But I feel like this needs to be merged if we want to hold EIP7723 correct and use it for different uh upgrade statuses upgrade stages. Having said that, let's get back to the uh DFI section. So DFI are supposed to be listed when when the proposal is in the draft status because in most of the cases as you can clearly mentioned that proposal may not be in review status. So we may not be

um having the status change for DFI proposal. But in that case if we include the DFI section in upgrade meta it will not move forward. And for that the solution mentioned here is that um that it should be removed uh when times comes like when going to last call it should be removed from um from the upgrade meta. But my recommendation here would be like we don't have to. It says that when an upgrade meta is moved to last call uh decline for inclusion and all PFI, DFI and CFI should be removed

and just uh leave schedule for inclusion. My recommendation here would be the decline for inclusion can be removed when the proposal is moving in the review altogether [music] because this is most likely there will be at least one EIP in DFI which will be in the draft status and that would be a big blocker. So this sentence can be corrected in EIP 7723 in order to make it fully worked. So that's the second change. There is no PR for it yet. But I think this [music] has a strong argument to do so. I wonder what people think here. If they agree, we can go ahead and create a PR and again take it to author.

Maybe discuss an ACD. But if editors strongly disagree because this is again a process EIP. If editors strongly disagree then there's no point moving forward with it. >> I mean this is somebody else's process. So I don't think we have any say in this really. Um, but uh I'm down to remove all of those sections. Um, and if you're having trouble getting the authors to to look at the PR, you might just want to open a new EIP under a new number. Um, and have yourself as an author on there. Um, that would also be a a valid solution to this.

Um well that may be a little complicated given the acceptability of uh EIP7723 in the ecosystem. My preference would be to maybe go ahead and talk to authors. I will definitely try. Yeah. Yeah. No, I totally understand. >> Uhhuh. Yeah. Of course. I totally get that >> and uh if that is the worst case solution we'll do that. But for now if people agree then maybe I can go ahead and make a PR to have this change. So these are the two changes per say EIP 7723 this proposal is still in the draft uh sorry uh last call started it is not finalized. So this is our chance to make this proposal like correct so we can

have it for future references. The third change that I want to point out about this proposal which should be incorporated in meta which is currently not being incorporated is the statement that says that this is only for core EIP. These days in practice all EIPs are being considered part of meta e which is uh being listed as DFI, PFI, CFI or whatever it is. But 7723 clearly specifies that this is activation stages for core EIP. So my proposal here is that we should go ahead and maybe because this is only done for two

upgrades, we can go ahead and do that and it's not a big change uh for any of the meta e if we decide to do it today. For example, um Fusaka, let's take it for Fusaka. So here if we'll take a look at it, it says other eaves but they are under the header of included. So if we just change the heading of this [music] without making too much changes to it, it can be considered as separate section and then we will be holding EIP 7723 ride that included is the stage for these EIPs not [music] these. So this is for the past

that we may want to correct if we agree to the idea that u network upgrade inclusion stages only work for core EIP. Now let's take a look at glamsterdam So if we are um looking at Glamsterdam EIP, there is a section of networking EIPs which are under CFI by 7723. This should not be under CFI. But this says that this is found under you know EIP [music] 7723. So we are contradicting there are small things that we can fix in order to do what we say we are doing.

uh but again that requires consensus from editors from authors and then we can bring it to ACD. I wonder what [music] editors think about it. >> Yeah. So the first point here is is [music] that and Sam also already mentioned this that this process is of course a very core process [music] of Athereum but it is not part of uh of this is not part of the EIP editor's process. So um what I think because I completely agree with you that uh that this uh that the uh the network upgrades EIP is being contradicted by the current uh well by by maybe also by the Fusaka

meta but also by the Clemson EIP like this is this is something what we should definitely not do in the process. Um, so what I think what we should do and then saying that not as an editor but like as uh as someone who wants to improve the fork process is that we should uh I think that we should bring this up at ACD that um [music] and because these ACDs are of course always packed but at least put it on the agenda that okay listen we are not following the uh network upgrade specification [music] uh here here is a PR changes it and then also lay out okay like these and these rules are not being followed correctly and how we can improve that. Um and then

as a second point you are also completely correct [music] because the word stages and status is very confusing because of course we also have the EIP [music] status um which could re refer to that or not uh which is very confusing but the main point is that well [music] we or you do not need to have editor approval of any changes [music] to these EIP because we only follow the EIP process and not the uh fork process. Yeah, >> that is correct. So, um with this I'm open to maybe put together some points related PRs and add it to the next ECD agenda to bring it to author's

attention. But at the same time, I feel like when it comes to process, if something is being uh considered for rough consensus, editors should be part of that rough consensus. However, I believe in empowering editor a little bit more because they are the first point of contact for anyone. Let it be author, let it be a community member or anyone who wants to understand and contribute. So what we are doing in practice [music] which brings me to my next point. What we are doing in practice, we should do it for a little bit more. For example, as of now, if we have an open PR which is pending author's approval, um let's say the

author is not [music] around anymore, uh and it is for a typo or something, editors do merge them at their discretion. This is not formally documented on EIP1, but that is being part of the process right now. We do it with approval of two editors just to make sure that nobody is making mistake right here and if there are small correction that editor think that it is right it's just that author is not addressing we can address it and close the PR I think that thing should be formalized even more and we should pay attention to these kind of PRs because this can significantly decrease the number of open PR. I think this PR

with respect to 7723 is a clear example of that. This PR was opened back in January and this is July past six seven months. This has not been addressed by the author. I think uh uh it has been discussed multiple times in ACD meeting but not been addressed but this is an important proposal that needs to be discussed that needs to be addressed and editor should be able to enforce something in place and yeah I mean I would be happy to like be added as co-author and make these changes because I strongly believe these are right.

Sorry Sam please go ahead. >> Oh no worries. Um, so for non-final EIPs, I don't think editors should merge anything without author approval. Um, like maybe maybe typo fixes, like stuff like that that are super obvious, but for anything else, I I don't think we should. Um, if we want to make those kind of changes, we should do it the same way any other author would and fork the EIP. Um, I think that just if we take the place of author's judgment in non-final EIPs, [music] that opens the door to us being pressured into making these kind of changes. So, for example, like somebody comes along and makes a pull request against uh, I don't know, some

popular mostly implemented standard um, that just hasn't gone to final yet and they start pressuring EIP editors into merging their changes without author approval. um we probably don't understand the full scope of where that EIP is being used um or ERC I guess um or the the technical ramifications of it. I don't think we're qualified to make those kind of choices. So I don't think we should be approving anything uh without author approval except for obvious fixes and like typos and stuff like that. Um and then we should encourage people to either get themselves added as authors or to fork the EIP. Um and that way we can remain you know neutral and not

involved in any of these kind of disputes. >> Yeah, I would agree. So having this policy in place that uh if a PR remains pending author approval for more than 2 weeks for a final EIP, we can uh get in merged at editor's discretion but for the open like non-final EIP we should not do that. Okay. Um, do you think we can document it formally maybe on contributing them contributing MD or EIP1?

>> Yeah, I think that that'd be fine. Um, >> okay. >> Yeah. >> Yeah. I I think we should make it formal. Uh, that way you know future editors would also know if they are not here around. >> Cool. Uh, we have like 7 minutes left and I know there are a lot of items for discussion here today. I quickly want to just mention one last thing from my end which is respect with respect to working group. Thank you Yohim for taking a look at it and uh I believe I have added response to all the queries that you had. Uh Sam if you ever get a chance please take a look at it and do let me [music] know uh or let the group know if

uh we believe that we should perhaps move in this direction. For initial process I have added only five dispute but I think we can shrink it to two or three um and uh start from there. Uh if there is a general agreement and we can start working around how we can handle these kind of disputes [music] how we can look into issues try to address them and create an environment where we can receive more participation from the ecosystem. Um with that maybe u um we can move on to the next one. I know there are a lot to discuss but let's move on keep moving on with the higher priority stuff right now. I understand there is a demo

requested which we don't think we will be able to do it in full but before we get to demo uh if we can get updates on EIP working group u I I believe that is going to be fairly [music] quick. >> Sure. >> Uh yeah go ahead. Sorry. >> All right. So, uh, Sam and I have made some foundational progress on the multireo local build system. Um, covered in the last few meetings we've had here. The first two PRs are merged. Um, including a new one for the repo manifest work that lets separate repos identify each other properly. The remaining work is still in review and iteration. Extra eyes would definitely

be welcome from anyone interested in the local build workflow repo tooling or the developer experience. The link is in the GitHub issue comments, so you're welcome to check that out. Thanks. >> That was quick. Thank you, RTO, for updates. >> You got it. >> Very well. Uh, next we can move on to the community demo. I believe it was requested by EIP lab. We have just four minutes left. So if you want we can maybe schedule this demo for the next meeting. But if you want to make a quick intro what this is what this demo is about and what you want to share today please. The stage is all yours.

>> Yes. Uh hello. Can you hear me? >> Yes we can. >> Okay. Excellent. Uh thank you uh for this space. Yes, we are uh we are going to to show very very fast what is the EAP lab and the propose basically is a is a tool for testing any EAP using a smart contracts on the execution layer and these EAPs could be um related to upgrades in the clients or the protocol itself. But with the EVVM stack, we can just h just make it like like a mock but useful mock that maybe is for production. Uh ready to use by anyone

just in a few minutes. So please uh if you want to show the the demo we have like two minutes and then we can show more. >> Hello everyone. Um can you see my screen? >> Yes. >> Okay. So we are in the EIP lab um app. So we click on [music] launch EIP lab and you should have open AI API keys and I will charge it with an EIP. This one is the 8034 and I just give me a second. I have to load models and uh I just click on launch deep research. What uh EIP lab agent will do

is to read all the EIP and understand which uh parts of the op codes uh understand which part of the configuration of the Ethereum protocol have to be um emulated and modified using the EVVM stack. So uh it will it won't take that long. So just for understanding I hope you know about EVVM and what we do is to run a Ethereum virtual machine in all their blockchains using smart contract. So this EIP lab will um ask for um some questions in order to uh shape the uh the the result which will provide um compilable

um smart contracts. So um I'm going to answer the questions using an agent that I have in order to speed up the demo and as soon as I receive the responses uh we will show how how it will work. So our AI agent what does is to it will show obviously the token cons consumption and we'll create a version of the EVDM stack which can be uh modifying the core contracts adding additional services or in a hybrid mode um confi reconfigurate the EVVM stack plus additional services in order to emulate up codes for example um ced knowledge proof um hashes

verification Obviously we are not going to provide the infrastructure for that process but we can provide the the um up code emulation in a service in order to provide a just no uh for for your testing. That mean that you can prove any EIP using this stack which [music] will save tons of money, tons of um time uh instead of um running um your own infrastructure, your own nodes reconfigurating the the the the Ethereum virtual machine but using the EVVM stack in local and obviously in test nets and maybe even production

environments. So uh at this point it is reading um all the information I gave and it will generate smart contracts that emulates in this case the 8034 EIP which is in revision and and it will provide the contracts the necessary contracts for testing this EIP. So I know I I'm not really a a smart contracts or Ethereum developer um protocol developer but I do understand that when you are trying to test any EIP you should have like a really wide understanding about the protocol itself and how to the up codes

will work in the Ethereum protocol. So uh this is what I made with with the team in order to to provide um researchers and developers >> uh sweet for testing any EIP only with three clicks and almost uh less than $5 of cost per each iteration. >> well thank you Okan in the next call we can show the full demo. Thank you, POA, for this opportunity. And yes, for everyone that doesn't know, EVVM lets you deploy virtual blockchains like the VMware or virtual box or maybe a CH root on Linux for blockchains. So, uh we we

run we call it vertical scalability. So, okay, thank you for this space and and maybe in the next call we can show a full demo how to modify it, how to improve it and how to deploy it to use it properly. and it is just finishing of um creating the smart contracts. It has all the EVM context. So yes, we will have the 8034 EIP ready to test using the EVVM stack. >> Excellent. for for just one mention the the EAP H250 or the key nonsense is very easy to deploy on the EVVM to have a synchronic is how we call it. So this is fully

implementable and full usable and it's very nice to use on production on an EVVM. Uh so well let's talk in the next call with with more time. Thank you for your attention and for your time. >> Thank you guys. >> Thank you both. Thank you EAP lab team. Um this seems like some [music] uh tool that maybe we can bring it to attention to uh testing team or uh the other people if they want to use it for their uh solidity contract or any kind of contract deployment. Um [music] definitely we would love to have a detailed overview of it in the next meeting. But thank you so much for sharing this tool with us.

Um we are at our I am happy to share that we do have uh editors available for next few [music] weeks. Uh but editors if you get a chance please take a look. I I do see August 4th is still empty. If there is anyone who is available please add yourself for office hour and we'll continue to [music] address the issues, question concerns of community of EIP authors on EIP editing [music] office hours. That's pretty much all for today's EIPAIB meeting. Last question for editors. When do we want to have the next meeting? Should it be the first week of August or do we have any other date in [music] mind?

>> Yeah, that's that sounds good. First week of >> Let me just check my calendar. >> Yeah, I can actually also do that before I commit to to to this. Um, so the first week of August I will probably be busy. >> Okay. Then likely we should schedule it one week ahead or one week earlier. >> 12th or 19th maybe. >> For me both work. 12th works for me and the 19th works for [music] me as well.

>> Okay, let's keep it for 12th. Uh and if there are any changes then we will move it to 19th or August. >> Cool. [music] Thank you everyone for joining us here today. See you around. Take care everyone. Bye-bye. >> See you. >> Thank you. Bye-bye. Heat. Heat. [music] >> Thank you.

>> Heat. >> Hey, heat. Hey.