EIP Editing Office Hour #105 (EIP + ERC)

Transcript

[music] Heat. Heat. [music] >> [music] >> Thank you.

>> Oh, heat, [music] heat. Heat. Heat [music]

up here. >> Welcome to EIP editing office hour meeting number 105. Uh this is issue number 2150 on Ethereum PM GitHub repository. On agenda we have uh some PRs from ACD [music] uh agenda like we

want to pull up the PRs which are required for codevs conversation. Then we have review miscellaneous and a bunch of draft. Um so Sam I mean my first question right here is with respect to the ECD agenda. As we understand we are moving towards the test net phase public test net phase of [music] Glamsterdam upgrade. I was hoping to have all the EIP review in the review status because um that's the appropriate status being the proposal in CFI and SFI.

>> I I have went ahead and u created all the PRs. Now every PR require author's approval which we are getting but most of them are interdependent. So I I guess I have opened 10 plus PRs [music] today and uh we received a confirmation from one clean PR is just one that is uh178. No sorry >> no no my bad. The number is 11876 which is Glamsterdam EIP's promoted to review. So that's a very clear case and we we have included it in [music] here for merging because now it requires only editor's approval to get merge.

Well, my question to you is is it appropriate to include all the PRs and get the editor's approval and the PR will be merged when the author approves it. >> Does this make sense? >> That that's fine. Yeah, the editors can approve before authors. >> Okay. Yeah. I wanted to understand if there is like a sequential dependency like only author has to approve it first and then editor can. >> Nope. No, it can go in any order. >> Okay. Perfect. Then in that case, I'm going to go ahead and add all the other PRs [music] which are there. But perhaps we can start from this one.

>> Sounds good. I'll get started. Yeah, I mean that's the smallest EIP I think I've ever reviewed. >> Yeah, I mean the only change is a status change. We are trying to make sure that they are with respect to their stage, network upgrade stage. Uh so these PRs are by me but I am hoping that we would be getting some uh some um follow-up PRs in which whatever minor changes and

specs they would want to have will be included. >> Yep, that makes sense. Does this one need an editor review? Probably not. No. Okay, cool. >> Okay. I I think the best way if you would want to take a look at it or else I can go ahead and add it >> u in the EIP repository. I think the first 10 are a bunch of PR by me [laughter] can do.

So 8173 needs to go first. So that is another case like there are some proposals in [music] which they have referred to some of the EIP which do not belong to Glamster. I think >> in that case they have to take it out. Yes, that would be correct >> of the proposal.

So, this is uh Greg's proposal, right? For Greg's proposal, there are EIP 3540, which is a stagnant, EIP 4750, which is a stagnant, [music] so he has to take them off. >> Yep. >> Yeah, I was about to write this note. And EIP 8173 isformational EIP which is in draft status. So Greg will have to create another [music] PR for it to move it to the review status. >> I guess I'll probably tag the authors in this one because Okay,

expand to the rest of the way. So, call return op codes three new instructions to support calls and returns with the option of validated control flow. This minimum change the EVM to support calls and returns. No controller blah blah Yeah, I have added most of them in the

agenda Awesome. Okay. Rash now Come here.

Okay. So, sub routines return sub returns to the original caller. Um okay

without pushing to the return stacks the serines return sub. Okay, [sighs] where was I? I was looking

in rationale for emerge from it. Okay, I guess that's a question for the

discussions too. Go over here. in my

Okay, back over to here. Um Trepine. in pop the destination

from the top of the data stack. Push the position PC plus1 to the return stack. Set the PC to the destination. If the destination is not an enter sub instruction or the return cycle already holds the execution is in an exceptional halting state. Yep. Gas is mid marks a destination for call sub like jump. It's otherwise a no opt. Yeah. Destination. Yep. jump desk returns control to the caller of the sub routine. Set the PC to the position P from the return stack. The [music] return stack is empty. Execute.

Yep. After the code beginning with magic bytes must be a valid program. Execution begins immediately after the magic bytes values popped off. The return side do not need to be validated. They are alterable only by call sub and return sub. No.

Are we in rationale here? No. Okay. Should I be execution is defined in the paper as a

sequence of changes DVM state exceptional haunting conditions or properties of the machine check before instruction execute if execut without commission. Put it one.

Yeah. paper. So from over here, go here. That delete that change that to master. Oh, all right. [sighs and gasps] There's no longer a PDF in here. I noticed there is a PR which was merged just yesterday or maybe 10 hours ago uh that talks about removal of some yellow paper reference from 7979.

>> Okay. I mean that that would be acceptable. Um I guess we can go here. Um, Hello,

Kelly. Oh, I see. Okay. Okay, every jump jump must be immediately preceded by a push whose immediate value is in the is the destination. The destination must be a jump test or an inter sub. Immediate

data is not an instruction. A jump to an enter sub enters the sub routine. Um, So Immediate

value is the destination. The destination must be an intercept instruction. Okay. Okay. On every path, each instruction must find at least as many items on the data stack as it removes. Must not leave more than each call. Okay. Every path reaching instruction must arrive with the same stack offset. What do you define stack offset,

the depth of the data stack minus the current baseline. Okay. Every frame begun at a given entry must close with the same net stack effect. Every path routine instruction must drive the same stack offset. uh countries in an earlier fork should

remain deployed reaching deprecate up code and one is an exceptional halting state. The layout of magic header is explicitly deferred to a follow on specification. No, 7702 wouldn't do that. So, yeah,

with no static issues. Here we are. If you need documents for jump performance and increase complexity of instruction encoding It's something.

I'm surprised to see those many changes in in this proposal. I was under impression that this is almost ready. >> Yeah, I'm being picky. No, I I think the documentation of a proposal and specification clarification are two different things. So perhaps they [music] are uh providing the specification that testing team may require but for documentation purposes it might require a little bit more. Okay, cool.

So, there is a review that took 40 minutes. Nice. >> Yeah, it was basically looking like a draft proposal. So, yeah. Anyway, it is moving from draft to review. But in the meantime, we received approval from three authors. [music] So there are three PRs which are ready to be merged and those are the next three on the Glamster EIP promoted or you can also find [music] it on chat. >> Perfect. Let's take a look at these. A minimal create to factory shared by EVM chains. The availability of well-known creative made a formal requirement to enable deterministic deployments of identical address across chains. [music] Yeah. Okay.

I'm aware that there are some of the EIB which may have [music] other open PRs with respect to these proposals but uh uh these PRs [music] which I have added here in the agenda are just moving it to review status. It did not >> Yep, that makes sense. [music] want to include other changes. Okay, that's that's easy enough for me.

Go. Moving on to the next one. 7928. Did I see that one over here? 7928. Yeah. Okay. So, we can start with this This EIP introduces block level access.

Oh yeah. Okay. This transaction [sighs] 791.

This is weird. For all these proposals which are getting into one upgrade, we are making each other a required section. Stuff good.

Nice. Let's go over here. Let's go. Edit here. >> So, do do we want to wait for author's u response [music] to them or >> uh No, this is just a mechanical transformation. I don't I don't really mind doing this myself. Mhm. And then let's just search for this um A2 Z plus

S back space. [snorts] Yeah, because now we can prove this and then we're good to go.

So that was 81 878. So then we're moving on to this one, I think. Is that the one? 7928. Yeah. Okay. So let's wait for this to merge. Oh, what's wrong here? 7981. Okay, this one. 7976. These are very very interdependent EIPs.

>> Yes. And in one of the uh PR I think there are five or six dependent EIPs. Okay. I think I reviewed this one pretty recently and I don't think there was anything wrong with it. So, um, that's fine. So, Okay, let's wait for this one to merge.

Then we can rebase the other one and then we can merge the last one. I'm happy that they all are added together. We can also look for [music] 1883 in the meanwhile. 1883.

It's double83. Yeah. So, what are you waiting on before you merge? I just know I'm gonna forget if I start going to a different proposal. So, >> Oh, no. That's perfect. That's perfectly all right. No problem at all. >> Okay, cool. And then it was this one.

That was 7976. Yeah. Okay. So, we go [music] over here and go down here. I can't rebase you on the web because why that that's dumb. Okay. See code ERPs. Good. Check out. Do I have you on here? I probably do. >> It's the branch R seven, right? Maybe I can rebase on my end.

>> I can do it. Don't worry. Okay, perfect. Yeah, let's try no playing our seven.

All right. [music] So that should be rebase now. This should just merge all on its own.

Now it'll need an approval from me, I suppose. I'm just going to add that. I don't think I read this one. Okay. Okay, that's fine.

Okay. So, you wanted me to take a look at this one in the meantime. >> Yeah, this has also received the approval. >> All right. analysis of the runtime computer operations. This is what anformational EIP should

be. This is [laughter] This is perfect. Um All right,

switch back over to this one. Are you done yet? No, you're still building. All right. yeah. I mean, I guess that's probably it for today. I don't really think I'm going to start a next another one. So, um, yeah, hopefully >> we'll see you all on the next office hours. >> Thank you, Sam. It was great. I mean, at least we could, uh, move some of the PRs [music] and move some of the EIPs. I hope to receive more approval before the next ACD call and we'll bring them all as early as possible.

>> Sounds good. >> Thank you all for joining us. Yep. Yeah. Bye-bye. >> Yes.

Okay. [music] Heat. Heat. Heat up here.

Oh, [music] heat. [music]