EIP Editing Office Hour #116 (EIP + ERC)

Transcript

[music] >> EIP editing office hour.

This is meeting number 116 and added on Ethereum {slash} PM repo with issue number 2270. Today we are joined by editor Yoav Regev and on agenda we have quite a few item, a few related to ACD, quick actions and review queues. Uh welcome Yoav. We do not have added specific item on ACD, but if you want to maybe take a quick look at the link and see if uh anything of high priority that we would want to address just today.

>> Okay, so let's see because I see a lot of these in our ACD which are updates and PRs. So that's not something what I can uh do. Oh, wait, I can filter on wait waiting on adding this right. Okay. Interesting. Right. Let me just just open these ones because I'm not so sure why Why is this not Now, that's interesting.

Mhm. Yeah, okay. So, this itself is already like a very interesting issue because this HTML prover is signaling that this uh link So, this validation prefix and the execution body is not part of EIP-141. Uh okay, I will check if it is actually not, but it's already like a interesting question itself. Because if you link to an EIP and if this EIP changes and then one of these header changes then uh when EIP target is merged of another EIP which points to um well, also another EIP. Uh then on the merge part, it can link to a

uh header which exists, but when that that EIP where it links to actually updates uh then it might suddenly disappear. So, that's something interesting because that depends on the the version of the EIP which you which you're linking to. Um of course, for final EIPs, this is not a problem because if you link to final year EPs, they these cannot be changed. Um, but um, for these drafts or like these review EPs, this obviously can. Um, let's see why this is the case.

>> I'm I'm thinking it is giving a relative link, so would it not change would it not just get updated all by itself? >> No, because so this this this is EP 7907 7906. >> Ah, okay, okay. Yeah, got it. >> But it's weird because this should actually exist. So, I'm not sure why this is flagging. let's take a second. if I just put the hash this is an execution. I think what is not.

Okay, let me check in in code why this is not work. Uh, can you still see like my uh, the GitHub? >> No, um, I mean [clears throat] we can see the screen where you are checking HTML proofer. >> Yeah, okay, I see. Okay. Yeah, because I don't want to share all my screens. Um, yeah, okay, let me just do that. that's it. Okay, let me run that in the in the

background. Um, what was this thing? All right. Okay, so this needs an offer approval. So, this is not editor related. I think this is the one which I just had. Yes. Also. Okay. Okay, so this is a new one. Okay, let me go back to three points.

A an agent tool. Oh, it's right. So, like I'm also thinking about this. So, I'm mostly pointing agents to do like a base review. So, I will also do like I will also read it. Um but this is of course something which you can automate.

So, what we could do is we could like create an an an agent file or like I don't I think you have an agents.md or something like that. And uh people who write these EAPs uh can either look at agents.md themselves. So, this should also be written like in in human form of course. So, you can also just read like okay, what what why do we want this and then what should we enforce? But that's they can already like um run an agent themselves to review themselves. And then uh most draft EAPs should actually end up uh being um fine to be directly merged.

>> Yeah, I I think this idea was proposed a while ago and um some of the bots were designed in order to do this thing and that's why they highlight some of the issues which are already there in the proposal and author can fix it before it comes to editor. The one concern that was uh mentioned at the time was like because these are draft proposal, it's always a good idea to pass it through a human eye for the reason that they should avoid any kind of duplicate proposals.

Um of course this is something that can be integrated even if it is reviewed but not just get merged and make it ready for editors to go over it. >> Right. That's a that's a very good point. Yeah, I I'm also not not saying that we should not read these uh EIPs. But it's more that people create an EIP which like has some very clear like for instance this this part keeps um popping up like not linking to this EIP. >> Missing the link, yes. That's right. Mhm. >> Yeah, I mean I think this can be fixed with EIPW.

>> Uh yes, exactly. Then yeah, that's that's actually a good idea. I'm not sure now why it always is not a rule. >> Mhm. >> Yeah. So let me write it down. Okay, let's read this one. >> Mhm, interesting.

All right, so Okay, I don't know that. >> All right. Okay, I also see cyber center

here. So, let's take a look at PR 1952 and 1942. >> All right. So, 1952 is about the tooling the stagnant bot. >> Uh yes. Okay, this is I think what I wanted to merge like merge earlier. Like I've looked at this thing last week. Let me I think check again. I think it is ready to merge. Uh >> Uh no, it requires two approvals. So, we still have to add one and wait for the other one.

>> Okay, that's fine, but I can then at least add my approval. >> So, it was 1952. Uh let me check where was this. >> I'm going to check my default approach

to stream. Yeah, okay. Okay, so my this agent last night is total functional shift. Let me actually make it post up pending review. And let me see because it's complaining about the the active bots.

All right, so I guess the main question here is that this bot Cybersecurity, do you remember which bot this is? Because we have multiple, we have a review bot and also like an an EIP bot. Um which which bot is this? >> Yeah, so this was the uh stagnant bot. >> So, it's it's working in the EIP repo, but not in the um ERC repo. I think on the split, um it obviously didn't activate when that's around the same time of when the split happened.

>> The um just the back ground again, so let me get this right. Uh Sam ran it through with the LLM, but it errored. So, I obviously looked at them errors, created a new PR, and that's what we see there today, which is um 1952. >> Yes, I see. Okay, let me check the the ERC bot. All right.

All right, all right, all right. Okay, there's at least one if you might check check about this security thing. Uh let me let me check what what my what is the agent flags. Yeah, okay. Yeah, yeah, I like it. That's that's this thing, okay. Yeah, okay. Okay, what I'll do is I will

this is a review for self. Uh you can of course also take a look at it if there's anything you want to change. Um but I have to look into the permissions of this the specific bot. Uh and also it's flagging that maybe there are some conditions where any changes are rolled back. So, um >> I'm just wondering if I possibly close this one and then maybe we go back to PR 1916 the one that Sam created.

Potentially, if that's an option. >> Yes, let let me let me check. Let me check. Right. Oh, yeah, it's this one. So, uh so this one was merged, but this was problematic because of what again? Oh, right. Right, so this should work. Okay. Right, so okay.

>> Right. Okay, let me run this agent in now in the background. Because yeah, I mean like this second one what has to run. Already two weeks ago, but yeah, this is something what what what we should definitely address. and let's see also 1942. >> Yeah, so you kindly run this through. I think [snorts] it was back end of last week. You had three L and comments in there.

Which I've rectified. >> All right. Yeah, okay, let me let me just check that. >> It pulled up one recommendation on the second comment. But the ERC that it was recommending was stagnant. So I didn't run that one through. I went about different way. You'll see in the comments. Obviously that was the um L M's recommendation.

Okay, seems >> Yeah, that's right. Yeah, let's see because maybe of

interest. Uh, let me actually check if you maybe already have that in your receipt. Um. Because wait. No, no, I want to see this one. Yeah, so maybe of interest. So, uh, in Glemsterdem, I think yeah, Glemsterdem, right? So, we are actually on mainnet we are uh, um, uh, adding this to this this EIP to the to the chain.

So, this is actually this defines a deterministic factory contract. Yeah, to uh, I'm not really sure if all layer twos use this contract, but you could point to this as like a default contract. But, this is of course not a blocker. I just wanted you to know that uh, that this EIP is being um, merged to the to the chain. Um, and yeah, this all looks good. So, let's let's merge it. >> Yeah, I'll definitely thank you. You're welcome. I'll definitely check that one out as well. What was your your recommendation on that?

So, just to cast my eye over it or do you think there's some sort of >> [snorts] >> link in that one? >> Uh, so you mean linking to this EIP? >> Yeah, is is that what you was uh, proposing? >> Yes. So, of course you have to take a look um, and let me actually check because maybe it was already merged in a previous fork, but I don't think so. So, we are scheduling this for Glemsterdem. Yes, exactly. Um, so you should be able to add this to your requires of the EIP.

So, you can you can state it and then it is also clear because uh, so we are adding this on mainnet um to really define like this contract is already exist for like I don't know like multiple years on mainnet it's like the standard factory contract. Um to also signal like this is the create two factory contract you should use to deploy your deterministic contracts. So you could directly integrate that into your ERC like okay use the EIP 797 factory contract. >> Got it. Yeah, I'll definitely have a look at it. Um Yeah, I'll I'll definitely look at that today.

Thank you, Yocum. So like this ERC will get merged but you will have like Oh wait, it is No, this is fine. Um This should get merged, right? Okay, let me take a look at this. This will get merged and then you can um create a follow-up PR to to add this this EIP to your requires list. Yeah. >> Yeah, I got it. Thank you. >> Okay, let me check another EIP or ERC because I was working on that but there was something very weird going on.

That's this one, I think. Yes. Because for some reason this PR is adding an EIP or an ERC which I don't really get. Wait, oh now now it is finished, I think. And it's reverted. Oh, is it Was it this one? Right. Oh, okay, that's good. Then I can approve this one also. That's great. That's great. EIP 259 EIP 259 is pretty cool.

>> All right, let's take a look here. Because these are like EP editions. Which I think I've seen before. Cool, this one is this one is that's

nice. >> Okay, let's see what that these ones. >> Also, I have also added one in the chat which you reviewed last week and I guess the author has um fixed it. There was some um some error that you suggested to fix, I guess.

>> I see. All right, let's see. Okay, this was the All right, yeah, this was this this one. All right, let's see what's happening here. Oh, yeah. Oh, this one. I remember this one. All right, let's check this one.

>> I think we need to provide better guideline for ERCs because they come from all directions and a lot of ideas. >> Sorry, what's up for you? >> So, I was just thinking like if we can provide better guideline to ERC proposals. >> Like for EIPs we have like you know selection process like this is meaningful EIP this will go in and things like that which is going to help. I know that there is no required section of implementation. It's reference implementation only but it will be useful to see real implementation of these standards.

That's that's yeah. Like I I get the idea but if we start to host implementations of of these standards then we are basically also going to host code so especially specifically here then the solidity code solidity code of it. I'm not really sure if we want to do that because let's say for instance that we move an ERC to final and then at some point there is a security incident then we do not want to give the impression that the hosted version of like ERC implementation or like a solidity

implementation of a specification um is like bug free. Um so this like a more like it's more like a middle ground I would say, so um defining like the high-level idea uh and what things you'll do. I think that's that's like fine for the specification, but the actual implementation should then be I think somewhere else because that's I think not yeah, I would say like not our responsibility or at least I I do not want that the ERCs start to host like very um vulnerable code.

Yeah, if if if you get what what I mean. >> Yeah, I I get it. No, I'm not suggesting that we should have it in the EIP specification. What I'm um considering here is like we need to know before moving it to final that there is interest and that is a standard that is being proposed, not just one use case. >> So, if if this information can be captured maybe with the help of Fellowship of Ethereum Magician where other discussions are happening, they can obviously share reference implementation over there and things like that before moving it to finalize.

I mean, this particular one is going into draft, so not specific to this comment uh >> [clears throat] >> proposal, >> but in general um it would add a value to have standards if there are utility, more general, not specific only. >> Yeah, exactly. Yeah. Yeah, I I guess it's more like well, it's like an a procedure because like I think that's EIPs uh can >> uh move somewhat fast because in the sense of like if an EIP gets uh into the protocol, then it's very clear then it should already be final once it gets uh uh ac- active on on mainnet. Uh but for ERCs, I think that this timeline might be much longer uh in the sense

that that you have an idea of like a specific um uh purpose. >> Right. >> And this of this of course has to be battle tested into the public. And there might of course be also uh um changes or like um clarifications to the specification. So, yeah. Maybe maybe it should have like a much longer timeline. So, you have like a review version and then that like for instance like a last call deadline of an ERC of 2 weeks might actually be way too low for for an ERC. >> Right. Yeah. I mean, it does not need to be always necessary that first the proposal has to be there.

Maybe, you know, if someone implements some developer implement a a particular application protocol in their project, they test it and then come to Ethereum when they think that that is a very good proposal. The specs should be documented and it should be available for public usage. Now, I mean like battle test it your own end and then bring it in here. I don't know. I'm just thinking out loud how we can make sure that whatever proposal comes are used and are of high quality.

>> Yeah, but I guess like like the the usage case might also be linked to like the existence of like an ERC, right? So, Like okay, so I don't really know like how how this exactly works into into the ERC ecosystem. But I would assume that people have like an idea like okay, this is a problem and we want to solve this and then you draft an ERC. Uh then people start to implement it and then we realize that in practice there are actually problems. So, then you edit your draft and then at some point it is getting more um mature and then you move it to review.

And then at some point it is being battle tested for like so long in public that you can say, "Okay, now we are going to finalize the specs." So, you move it to last call. And then of course at some point if an ERC is finalized, but it seems that there there is like an a purpose missing or an there are some edge cases or it needs some clarifications, then of course you can create a new ERC which then requires the existing final ERC and then you can write an well, an version two of this ERC or like additions to to this ERC. So, I I think this is somewhat already works like this. So, for instance like the the tokens derived from ERC ERC-20.

>> Right. Yeah, I mean it's a long debate. Maybe we can we can think more about it. Yeah, it was just a thought. >> Yeah, yeah, I I I like the thoughts. Yeah, I think like these kind of of questions like I would need or we we would need persons who are more familiar with the ERC ecosystem. So, I'm more familiar with the EIP ecosystem. but uh because these these people will have more knowledge like in practice like what what was like really been benefited the ERC process. Like how can we specify how like how should this this ERC document

look like? What is like helpful? What is not helpful? And how should this process does look like because this that's something different than how the EIP process looks like. Yeah. >> Right. And maybe we can use this office hour to like send an invite to all ERC authors and implementers. If you have ideas, suggestions on how do you see the process can be improved and could be more useful to the ERC ecosystem or application ecosystem, please reach out to us. This office hour could be a good platform where we can discuss ideas and then eventually bring it to the process.

>> Exactly. Exactly. Yes. Yeah, and I think also like what could also be raised is that like the the both offices but the the ESC editing offices definitely understand so that's that's also something to to address. >> Yeah, we are looking for more ESC editors so if you have expertise in the domain if you would like to contribute please reach out. >> Let me see because this seems that it also did not yet have an review at all.

Okay, let me double check do that. And it >> So there is a comment on this agenda by an

author. I think this is a generic comment these days people think that all checks have passed it is all green then what is blocking the process. If we can maybe share a little bit. That can be a general message. >> Yeah, I guess the answer is that uh that the office is understaffed but what I think what I what I should at least do is I should just point my agent to all these these ESCs so that this at least gets some attention.

Uh because the most thing that the agent flags is actually correct. of course I do not I want to check what it says because sometimes it says like very very weird things which are not But I mean, I can understand the frustration also from people opening these uh these PRs because there's like nothing you can do because you get like no reaction and that it's also not clear what they should do because these people are waiting since What is this uh since July? Yeah, since July. So, that's uh not not good. Not good at all.

>> For this particular case, I guess the PR number is 1907. >> Yes. So, let's Yeah, let's check that if that's correct because it should be correct. Yeah. Okay. Look at this one. Yeah, it's like on on that So, on this specific thing like I I really think we got that we should start to explore like creating these uh last language model

rules into the ESLint and the EAP uh repository. So, that people can point their agents to this so that when we point our agent to it that this should not flag anything that is already in the in the agents list. To also help automation with also to speed up this process because I mean waiting since July for response is like not uh that does not give any trust into this process at all. So, yeah.

>> Yes. We have quite a few things to do to improve the process. >> Yes, definitely definitely. Uh but yeah, I think like in in general because like creating pending reviews sorry these initial reviews is already like a great start because then they at least give give these uh ESC some attention. The problem is just that like if I read an ESC like I do not have the knowledge and the context of these things so I cannot judge if something if an ESC is like helpful or not or if it doesn't make any sense or not and although that's not really an editorial part of the review I I think you should

also like have some kind of context for for these uh these reviews because otherwise it's basically like if you would have an a document which is not in a language that you speak but you just check the style of this document and like like specific things then this is not really a helpful review at all. so yeah I I guess that's that's another point like I I think we need more people on the on the ESC side uh for this yeah. >> Yes, totally agreed. >> Okay, this is the usual one that's good.

Yeah so this like these this like the reason why I don't directly want to my agents to post these kind of of of of things because I I really wanted to to check this uh and not just post like a review to what might even be garbage because that does not only waste my time it also wastes wastes the time of the people writing these documents. so let's see if it's still have four items. Yeah I I I I need I need to read these things first. Let me check the other ones so that's No, it's this one.

907. So, let me actually open this Okay, let's let's read it. >> I'm not sure we have enough time to finish the entire review.

Uh we are left with only 3 minutes, but I I don't know if there is a way to do it. Maybe we can need some technical help or support here in order to do the initial review by the >> Yeah, the the the the the the problem I have with like directly automating that is that I think that there really should be a human between the process of an agent creating like a pending review and then a human checking out like does this actually make sense or not? Because sometimes it also brings up like comments uh also on EIPs which just make no sense. Like the the bot might think think it makes sense, but in the ecosystem context, it simply does not not make uh any sense. So, the bot might

not have the correct context for these things. >> Um but yeah, as an automation part like what I think what we should do is uh give um offers also the well, the same agent documents uh well, not the same Yeah. Like I have a like a local document where I appoint my agent to like I want you to check these things. I think this should be part of the uh EIP and the ERC repository. So, um people can also review them locally themselves. So, they can always You out um things what we flag. for instance like these RFC URLs which uh keep um not being added for instance.

for JVR I will comment that Um okay, what what are we going to do cuz I also have to leave after this this office hour. Uh I will keep this tab open and then I will like leave and >> Yeah, yeah. Of course, this can be done async, that's no problem. This can be done async. Yes, I mean um let's take a look if only the RFC thing RFC linking can be added to EAPW board, that would be super helpful. Uh and for um other reviews I would agree having someone looking into it before making it a review comment Mhm. would be helpful.

>> Yeah, yeah, yeah. I think this is something that we should we should think about. Yeah. All right. Okay, I guess I will stop uh >> But that leaves some some stuff to to to think about. Um and for Cyber Century, the um the staked bot, like I know I promised 2 weeks ago that I would look into it. Um I really think that we should activate this thing because it should really start stagnating uh ERCs. Uh but I want to be confident myself that uh the way this is set up is also the secure way to set this up. So that's why I want to take another look into into it. Yeah.

>> Yeah, thank you, Yoav. >> All right. Uh so uh thank you, Yoav, for taking out time for today's office hour. Next week the office hour will be on Tuesday at 1600 and it will be run by Sam Wilson. So please check out agenda and uh yeah, we will be posting it on ethereum/pm repo. Thank you, everyone, for joining us here today. See you around. >> [music] >> Hey.