All Core Devs - Testing #80

Transcript

Danceratopz: Good morning, everyone.

Ben Adams: Ayy.

Danceratopz: I feel really late, there are so many people already in the call.

Spencer Taylor-Brown: This is the one call everyone's excited about, so we all come earlier.

Danceratopz: Of course.

Leo Lara: Sol…

Danceratopz: That's who's recording the call today. Are they here?

dionysuz-bot: I'm… I'm recording it. This is David. What's up, Dad?

Danceratopz: Hey, David. Oh, nice to hear from you. Good to see you.

dionysuz-bot: Yes, good to see you.

Danceratopz: Perfect. Thanks. Okay, so… We already have quite a good turnout. Let me just give it another… Half a minute to see if more phases appear before we start.

David, would you like to start recording?

dionysuz-bot: Yes, you're alive.

Danceratopz: Alright, thank you very much. Good morning, everyone. Welcome to ACDT number 80. It's May the 18th. And we've got quite a busy agenda, mainly talking about Glamsterdam DevNet scoping. Before we go to DevNets, I wanted to bring up a few topics regarding scoping in general. This would be mainly just to… Yeah, like, fast track a discussion for ACDE on Thursday. The first topic to bring up is from Julio, Julio, sorry, that he posted last week, but we didn't have time for, and this is regarding bumping the max contract code size from 24KB to 64 kilobytes. Yeah. Jula, are you on the call?

Giulio Rebuffo: Yeah, yeah, I'm here. So, right, anyways, so there is already an EIP for… I mean, there is already an EIP to raise it to 32, so essentially what this does is just, you know, modify the EIP, you raise it to 64, and it's something that I've I mean, I've been discussing async with people, like, for the past 3 weeks, I would say. I have… So, I posted a message on Discord. I think all clients except eFrax and GAF, put, an ACC on it, and maybe I would like to get a formal AC on the call now, so that we can put it in the next DevNet. I think that even if, you know, we can even test in the DevNet, and if we see it doesn't work, we can just revert to 32, but I think it's… it's worth to…

raise it to 64. Also, because there has been some analysis done by both me and Carlos, and we proved that it should be safe even without a gas model to raise it to 64, so… yeah, so I'm just looking for an app from all clients, essentially. For that, so, I don't know, Nethermind, are you okay with this?

Ben Adams: Yes.

Giulio Rebuffo: Okay, Besu?

Daniel Lehrner: Yes.

Giulio Rebuffo: rough?

Dragan Rakita: Yeah, we're okay.

Giulio Rebuffo: Okay, so we're okay with it? Is there a gaffe, maybe, on the call? Okay. So… We can just… so, okay. Okay, so if there is no objection, then I guess we can go with it? Is that fine?

Łukasz Rozmej: Oh, I…

Danceratopz: Yes, Lucas?

Łukasz Rozmej: I think there… it would be good to get some feedback from benchmarking and repricing. team, on that, too, to be honest, because they might have some additional insight.

Danceratopz: That's a very good question.

Maria Silva: Right? Hi, should I… should I do it?

Danceratopz: Yeah, that would be great, Mimi, thanks very much.

Maria Silva: So I think there's, two things regarding benchmarking. So, I think first is, like, testing the 64 versus 32 is essentially the same amount of work, and we are planning to do either… either way. So what this means is that once we have a devnet where things are stable on implementation and we have all the repricings there, we do want to do a more… extended benchmarking, where we actually see, like, are there any operations that are bottlenecking us at the target gas limit that we set for for… for a Glamsterdam, and I think that the tests to do either the 32 or 64 are essentially the same. We do have already, some work done on these, so it should be feasible to

To do it, it's just a matter of Having the… the implementations on clients, and then as… as doing… running the… the benchmarks. I think in terms of then repricings themselves, so should we have this, change impact the cost of specific operations? I think I'm of the opinion and happy to kind of discuss this a bit more broadly, but I'm of the opinion that right now it shouldn't be an impact on repricings, and the main reason for that is that we won't see a relevant number of these contracts on Mainnet, right away. And for an attacker to actually deploy those contracts, it would be expensive, especially because we are raising the cost of contract deployments. So I would think that we still want to do the benchmarking, but I would expect maybe this to be something that we revisit in the next fork. So once we have maybe more contracts deployed, and this starts to become a possibility of…

Of attack, but until then, I would say we just, price with the… with the max size contract we had before the fork, and we benchmark and see the impact as well, but that won't have an impact on the state access EIP.

Giulio Rebuffo: Right, so… so, sorry, I want just to say that, I mean, I'm just gonna repeat that, I… I mean, Carlos already did some sort of benchmark, but yeah, okay. I mean, I guess then, we… we… I guess, again, we can kind of update it and reverse it, so it's… it's… fine, I guess? So can… Would we be fine, then? Okay, yeah. Who was next if you wanted to talk?

Danceratopz: Whips…

Ben Adams: Which DevNet would be the one we're targeting?

Giulio Rebuffo: I don't know, the next… I mean, there is now BAL devnet 7, right, coming up? Or… I lost targets, I lost count.

Ben Adams: So…

Stefan Starflinger: beaten.

Ben Adams: at least.

Stefan Starflinger: Glamsterdam, then Glamsterdam DevNets. I think it's a small config change anyway.

Giulio Rebuffo: Yeah, exactly. But anyways, yeah, I think we can… I mean, yeah, so glamsterdam-devnet-5, yeah, whatever, glamsterdam-devnet-5, it's fine. Or the… yeah, the bal-devnet-7 is supposed to come out today, right?

Stefan Starflinger: Yeah, exactly.

Giulio Rebuffo: So I think maybe we can do… maybe… The next afterwards, because maybe it's too late now, or… Yeah, exactly, like, so yeah, so yeah, it's late, so maybe we can do just Glam 5? So, yeah, I think we can do that one. Right.

Danceratopz: Okay, nice. Thanks, Maria. Marius?

Marius van der Wijden: Yeah, so I don't think we should price with the… Max 32, in mind. We should create the test for 64, because… If we have, like, it is very hard to decrease the… code size again. Like, if we go to 64, and then we realize, hey, there's a problem, let's go back to 232, That's not super easy, and the, and we might, like, we might have until the next hardcore where we can decrease it, we might have enough, 64 kilobyte contracts where an attack might be possible. The other… the other thing is, if I remember correctly, with… already with 32, and the current, Pricing? Like, before the repricings?

you could load something like 6GB of contract code, in a block, if I remember correctly. So… I don't think it's… it's super easy to reason about what Will happen if we… if we, like, double from… from 32 again to 64. I… also don't like the way this… this EIP ended up, in the process, where it circumvented, ACDE, Basically, totally, and was, like, soft included. In the, in, in… At Interop, which was exactly the same, how, the… how the process was circumvented the last hard fork for Pectra, and was the problem why Pectra didn't really work out, because we had, like, so many EIPs that are, like, last-minute changed.

And then we realized that the change is much more complex than we thought. I don't think there's much benefit to To going from, 32 to 64 in itself right now, so… I don't know, I'm… I'm… I would be very cautious about this EIP.

Giulio Rebuffo: Yeah, I mean, I agree that going from 3264 should be done with caution. I… what I was saying before is that you can change it… when I say you can change it later, I mean… you can try to include it in GRAM 5, you need it to do the test anyways, and then you… and then you can revert to the next DevNet afterwards. That's kind of the point. I mean, of course, you shouldn't ship it with the wrong value in the actual hard fork. that's kind of what… I mean, that's not… it wasn't my… My… my intention, but yeah, so this is kind of… the idea, so I'm not sure, do we just, do we just try this?

Because, I mean, there is a lot of… I mean. From what I can see, the majority of people here are kind of okay with it. So yeah, we can benchmark all 3 of them, too. I mean, with 64, you can benchmark all 3 of them, because you can just deploy all of them. Okay. Okay, so do I just merge it? Yes, no? Any last, you know, complaints?

Danceratopz: Okay, So, let's see if we can try and reach some sort of conclusion today. So, there's some noise in the chat. I'm sorry if the agenda was a bit misleading, by the way, this EIP is already CFI'd, right? And we have bumped, but this is about bumping it even more.

Giulio Rebuffo: Yeah, I mean, just to answer Tony, like, yes, you can… yes, whether you need a gas model or not, you… you need… test it. I mean, Carlos, again, Carlos already did this with Gaff. It shouldn't require a gas model, it's 64, but you need the… I mean, you need… but you need this to, to test it, so… I don't know. Here you go.

Danceratopz: Okay, Barnabas is suggesting waiting for benchmarks before we merge this.

Giulio Rebuffo: You actually need to merge it before the… I mean, you need to merge it before doing the benchmarks, right?

Maria Silva: I would say we need at least client… like, we need all clients to implement it so that we can then benchmark it. Because otherwise, you won't be able to craft a valid block that's…

Giulio Rebuffo: Wouldn't it be easier to raise it to, I mean, 364, so that everyone has it, and then do the bench one for 48, 32, and 64? I mean, it's just kind of an impl… it's just kind of a… I mean, it just sounds easier this way, right? I mean, I'm not saying that we should keep it for the final artifact.

Danceratopz: Expensive.

Spencer Taylor-Brown: Yeah, I just wanted to say, like, if this is going in Glamsterdam DevNet 5, which I assume will be in, like, a few weeks, like, there's still a lot of time to… like… I don't know. To figure out, like, with the benchmarks.

Giulio Rebuffo: So, I know, do we…

Danceratopz: Yeah, that's fine.

Giulio Rebuffo: Huh?

Danceratopz: Please go ahead, Julian.

Giulio Rebuffo: I was just saying, I, I was… I was just… because, I mean, I just… one, because, I mean. do we just tentatively put it in and then revert it, or what do we… what do we do? Because we need this implemented in clients, at least to test it anyways.

Danceratopz: I think we can either agree to update the EIP and revert it, if need be, or that we just benchmark it with the different values, and then update the EIP afterwards.

Giulio Rebuffo: Hmm… well, it's fine. I… I think I will… I don't know, I don't know, I think I will update AB. If that's fine.

Danceratopz: Marius, are you okay with that, or do you have any strong objection?

Giulio Rebuffo: I mean, it's…

Danceratopz: Okay. Yeah, Banums is asking us to move on, which is a very good point, or we're gonna get stuck here. I think we all agree that we'd like to have this in, and we need to benchmark it. So, moving on to the next point, Dragon brought up in E5 and D whether we can remove, self-destruct. And, for context, I linked, and he wanted to hear from people, whether, like, people that think it's too late to merge it or not. So, does anyone want to express an opinion here? Ben?

Ben Adams: Okay, going back to the previous one is… the code size is like a parameter change. This is an actual Complete new EIP. Although I hate self-destruct, so… I'm sympathical.

Danceratopz: Yeah, yeah, of course. This was… this is a new IP, no one's written it. I just wanted to get a temperature check. For me, I think it's… it's pushing it out a bit to include this now. It's relevant for this fork, though, because of the ETH transfer logs in 7708. And Pavel drafted, oh, he didn't draft. He has a CFI DIP now, 8246. Which removes the self-destruct gas burn. It would be cleaner to do it all in one go. But I just wanted to bring it up for discussion, as Dragon mentioned in Ethan R&D.

Dragan Rakita: Yeah, I think the change, code-wise, is small. But the impact is, yeah, bigger, because we are basically deprecating, removing the functionality from the AVM. So… yeah, I'm not sure. To be honest, I would like it to be included, because there is a lot of edge cases with the different AIPs affecting self-destruct. So, we are detaching self-destruct some other way, removing, basically including… removing… removing self-destruct as the new AIP, but we are detaching it from the other AIP, we are basically changing the same part of the code. So, yeah, I'm not sure. I would like it removed, I'm… I feel that it is time to remove it, but I would understand if the people want to push it for… for next work.

Danceratopz: Thanks, Jargan, for the overview. Lucas?

Łukasz Rozmej: Well, so last time when we were removing self-destruct, the multi-transaction, there was some small but vocal minority of people that were relying on this mechanism, so leaving it as is was the compromise, so I would… I wouldn't… Rug-pull them, so quickly, and give them… Check with them if they potentially migrated from it, or… Like, you know, have some broader impact analysis on that, again. So… maybe consider it for the next work.

Danceratopz: Okay. I think… yeah, Barnabas just asked if we can propose a new fork, sorry, a new EIP for the next fork, Bogota. I think, unless anyone has very strong opinions, they can raise it in ACD. I think we can agree that that probably makes the most sense. Alright, so, moving on, I think we can jump directly to, DevNet status for the… for speed, to try and compress a bit of timing. Let's have a look at BAL devnet 7 and how ready we are to launch. So basically, the spec changes are that, Cost per state buy, it's been bumped to $1,530, and… the protocol EIPs, E70 and 71, are now required. Does… I think everyone is basically aware of all this.

Spencer's basically about to push a new release very soon. Do you want to chime in with the differences on that release?

Spencer Taylor-Brown: Yeah, it can be quick, so… I believe last week we had 3 releases, so there was 7… 7.1.0, 7.1.1. And now we're… we've just tagged, a 7.2.0 release. It is essentially the same as the previous release, the only difference is a minor spec change with some new tests. So… it will literally be new tests that clients need to pass, and the release will also have A bunch of new block accessless tests. Yeah, well, it'll be out, very soon after the call. But, as far as I… personally, I feel like if clients are passing the previous release. And they should be okay for launching the DevNet.

Danceratopz: Nice. Yep. Thanks. Just before we jump to the, E71 PR, Tony, I just wanted to ask, client teams and perhaps Stefan, how they see the readiness for BAL devnet 7.

Stefan Starflinger: So, I've been doing some kurtosis testing with the clients that are passing all the, tests right now. So, that's, right now, ethrex, NetherMind, and Nimbus, and it seems to be going pretty well. I'm on, Epoch 50, spamming quite a lot, and everything is still in order, so that's very nice. So, my plan with launching the DevNet today, I think, We will keep it that way. And launch, I think, the DevNet later on today. And then I will deposit, the other clients. I think Besu is still missing some, tests. And Geth doesn't have a branch yet. And I'll look into, all of the clients a bit more, and then launch end of the day today, probably, or very early tomorrow morning.

Danceratopz: Awesome, thanks a lot for the update, Stefan. does GEF have an ETA on when the branch will land for DevNet 7?

Marius van der Wijden: No, we are still working on Trying to get some of the changes into our master branch, and then, at some point, we will have, hopefully by mid to end of this week, we will have a branch, for defensive, but… Definitely not today.

Danceratopz: Alright, thanks a lot, Marx. Dragon?

Dragan Rakita: Yeah, just to mention, those clients have a bug that we found. And they need to fix it before launching BAL devnet 7.

Ben Adams: It's just gonna be in the 7.2 test.

Dragan Rakita: Yeah, sure. But yet…

Spencer Taylor-Brown: be honest, that…

Dragan Rakita: Don't…

Spencer Taylor-Brown: Sorry, I'm gonna love that.

Dragan Rakita: I mean, so… Sorry, go on.

Spencer Taylor-Brown: Sorry, yeah. Yeah, it would make sense. So, if I get this release out, it's literally, like, maybe 9 extra AT37 tests. If clients could pass them before the DevNet, that would probably be better, yeah.

Danceratopz: Alright, nice. Okay, so… I think to gate, client participation in DevNet 7, it will be, using tests-bal at v7.2.0. And that should be released. Before the hour is up, before the call's over. Is that alright, Stefan? Can you hold back that long, or test with that one?

Stefan Starflinger: That sounds fine to me. I mean, I can launch it and just set the fork for later also. I'll see ya. But yeah, I'll try to launch it, tomorrow, then. After the release.

Danceratopz: Perfect. Thanks, Stefan. Alright, so on BAL DevNet 7, we mentioned that E71 was required. And Tony posted that there's an open PR that she emerged. Would you like to chime in on that? Tony?

Toni Wahrstätter: Yeah, last ACD, we agreed that EV71 will be mandatory for the next FLED. As far as I remember, all of the clients have implemented EF71, so this is ready to go, and it would be great if we can get this OpenPR merged.

Danceratopz: Is there anyone in particular, Tony, that you need to have a… need to take a look? Anyone would you like to… Request.

Toni Wahrstätter: I think… yeah, I think Felix, has already said he will take a look at it. Yeah, but basically everyone who has an opinion in it, making sure everything is right there. But I think things are good to go, and… yeah. I can… I can ping Felix again async, too.

Danceratopz: Thanks, Tony. Just… A quick… like, just a quick clarification. As the PR will go in, that's what should be on DevNet 7.

Toni Wahrstätter: Yeah, exactly.

Danceratopz: Okay.

Toni Wahrstätter: I think clients have already implemented it, although it was not merged. But yeah, this should… this should… this is one of those that should go in, because at some point we need it.

Danceratopz: Okay, perfect. Thanks. So, if there's any client devs who have implemented that and can take a look at that PR, it's, tony dropped it in the chat. Please take a look, it's in the agenda notes. Alright, so, I think the last thing… that I would bring up, which is DevNet 7 related, is the fact that benchmarking is moving to BAL devnet 7. Is there anything blocking on that side, or anything that you'd like to bring up in the call, from the benchmarkers?

Stefan Starflinger: I'm currently preparing the PR to merge from the benchmarking side and update the images.

Danceratopz: Nice. Thanks, Stefan. If there's nothing from, Maria or Jocham or Lewis, we'll just move on.

Maria Silva: I would, sorry, sorry, I would like to add, so, just to let people know that that now would be also a good time for everyone to start merging their optimizations into this branch, or at least to have your optimizations complying with the specs of BAL devnet 7, so that we can start running them on benchmark core. And seeing… the… the results. I would also like to point out that, I know there's a lot of work on these, fork, and there's a lot of new EIPs coming in, but at the same time. right now, optimizations are becoming a bottleneck, because we need to have optimizations done so that we can set the final repricing numbers, and then that will have implications on, for instance, CPPS deadlines and these sort of things. So, I would say if you can

put a focus in the next couple of weeks on improving your optimization, especially for the state access, and so this means batch I.O. and state route calculation. I think it would very, would be very helpful so that we can move the repricings forward.

Danceratopz: Awesome, thanks a lot, Maria. That's a very good point. So, there will be repricings made on this DevNet. Is there any timeline for when that will be made? Or is it more just about having implementations ready?

Maria Silva: So, so what I mean is, like, so for instance, for, 8038, right, to get the final numbers, on 8038, we need clients to implement a minimum set of batch I.O. and state root calculations, in their code. And only after we have that, we can run the final benchmarks and see what the final prices should be. What we are looking now at the moment is, like, the results we are seeing from optimizations are not as what we would expect to be a performance after block-level access lists. And so I think there's still some work to… To do their, and the… the cost is, like, the more we delay. having these prices, the less time we give the community to adapt, and so I think that's… that's why I think it's important to get… to have this as soon as possible, and why it's important to have clients work on their optimizations.

And I mean, I know that, everyone is working very hard on the fork, as a whole, I just… my… my ask is that we put some… some focus on these, rather than, adding more… more EIPs, and if it's still feasible to finish optimizations and work on the EIPs, then that's fine as well. It's just, I want to highlight how important this is, and how of a blocker this is for the fork.

Danceratopz: Awesome. Thanks, Maria. Thanks for stating that so clearly.

Toni Wahrstätter: That's okay, Dan?

Danceratopz: Yes, Tony?

Toni Wahrstätter: Maybe just to quickly add to that, I just posted a message, based on Maria's, what Maria just said in the BAL Discord. It would be great if clients could have a look, because I know most client teams have been, Yeah. very busy with the batch I.O. optimizations, but it would be great to get a feeling of which clients have already optimized for the post-state route calculation, because this is now getting increasingly important, as Maria just said, because of, Yeah, state. modification, repricing stuff, so there the post-shat route calculation optimization plays into the picture. So I posted a message in the chat, and it would be great if clients could just Chime in and let us know, like, how far they are with that optimization, such that we have a clear picture of what's going on there.

Danceratopz: Perfect, thanks a lot, Tony. Yes, Lucas?

Łukasz Rozmej: So to just give you Tony, a bit of, like. higher-level views. For example, in Nethermind, we already have some Optimizations regarding parallelizing a lot of stuff, but we are still working on stuff related to, like, better memory handling, lighter in-memory data structures, and, locking mechanism, things like that, which still net us a bit of, Well, quite substantial improvement. And we need DevNet 7 and benchmarks for… on DevNet 7 version for that, because kind of all the other, like, previous stuff is already kind of way obsolete, so we cannot really benchmark on that, because we need the tight feedback loop of benchmarking, profiling, to… to actually get there, so that's the state.

Danceratopz: Thanks. I think, I think we've raised the point, and I think we've now realized, the priority on this one. Thanks for setting up the thread, in the Discord, Tony. I think clients can chime in there, and we can handle the… The updates async as they come in from client teams. Okay, so, moving on to Glamsterdam DevNet 4, as I understand, this is, mainly, emerging point for the EL and the CL. It's basically targeting the BAL devnet 7 spec and the, V1.7.0 minus Alpha 8 consensus spec release. that, justin dropped in the chat higher up. Does anyone want to… talk about this DevNet. Did you want to maybe mention what's new in the release, Justin, or is everyone already clear on the…

On the scope there.

Justin Traglia: I do not want to mention everything that's new in the release, so I'll just check the release notes for that. Yeah, what POTA said, make the steel in charge of the gas limit.

Danceratopz: Nice.

Barnabas Busa: I would like to raise one specific point in the PR796. So, this basically puts the target gas limit into the, engineer PI, and basically the CL is going to be, saying what kind of gas they're expecting to get, and it'd be very nice if all the EL devs could, deprecate their gas limit flags on their next, GOS releases, basically. So that we don't… we're not gonna have, like, a mismatch of what gas limits, we would be expecting.

Dragan Rakita: Why deprecate O'Neill's side? If somebody's already using that field, it would be, like, breaking change, and it was… If I basically run Yale and CL, and… And some version, it's, like, not working anymore, and I'm not sure where to set it. So it would be a lot of confusion. I'll just leave it, and if CL, like, propagate that flag field, then just that field is going to override my EL settings.

Barnabas Busa: It's a lot more confusing. But, yeah, I mean, it's up to the devs in the end of the day.

Dragan Rakita: And it's, like, there is different, like, version of EL, CL, depending on what version you are, maybe you'd… maybe you're going to have, like, EL that removes that field, but CL doesn't have that field.

Barnabas Busa: No, but the seals will all have it by Gloas, that's the point, and at the fork, after the fork boundary, the EL flag will basically have no effect on anything. So I'm not saying to deprecate it now, I'm saying deprecate it after growth.

Ben Adams: Can we just confirm what DevNet this change is in?

Barnabas Busa: This will be part of, 4. Once again, DevNet4?

Ben Adams: Okay, but no bell doesn't sound.

Barnabas Busa: No.

Danceratopz: Okay. So we can update, potentially, the, the HackMD to make that clear, that this change comes in as well. So it's not just about Devin S7. Maybe I missed it myself, I can double-check afterwards.

Ben Adams: No, no, it's not… not in Valdevon at 7, as I understand it.

Danceratopz: I was mainly referring to the, Glam DevNet4 notes. Maybe I missed it there.

Barnabas Busa: Oh, it's… it's there. It's definitely there.

Danceratopz: Okay. Okay, well, it's good that everyone's aware of this. I'll update the agenda afterwards. Thanks for sharing this, the notes, even.

Barnabas Busa: Yeah, so basically, for the next DevNet iteration, we're gonna need to have a Glamsterdam-specific branch and a bal-devnet-specific branch for bal-devnet-7 and Glamsterdam DevNet 4. Oh. So, we cannot just reuse the, wall.net branch anymore. Due to this new change interest in the engine?

Danceratopz: So your shout… is this a shout-out to client teams to create Glamsterdam DevNet 4, instead of just using their bal-devnet-7 branch? Exactly, yep.

Barnabas Busa: Nethermind, and Erigon already done that.

Danceratopz: Nice. Okay. Alright, so I think that's clear for everyone now. Tony, sorry, you had your hands up earlier, and I tried to introduce you, but I was muted. Did you still want.

Toni Wahrstätter: No, I think it was clarified anyway. I, for a short moment of time, I thought someone was talking about deprecating a field in the EL header, basically deprecating the gas limit there, but this is not what is going to happen, it's just a flag.

Danceratopz: Yeah, okay, good, thanks. Okay, so, Glamsterdam DevNet 4 will be targeted after bal-devnet-7, Did anyone have any optimistic kind of timeline for that? Or should we just move on?

Barnabas Busa: I've been testing locally with Prysm, and Erigon and Nethermind, and things are looking good, but I think we're gonna need a few more CLs for this as well.

Danceratopz: Okay. Maybe it's, more, for EL client teams, too. Get ready and create a branch for that. Okay. I guess we'll handle that async as well. But obviously, we need to probably bal-devnet-7 to launch first, just for focus, and then move on to Glamsterdam DevNet 5. I'm sorry, I've got no fall. Okay, so, we still have a bit of time, did we want to go into trying to scope, Glamsterdam DevNet 5 today? I think it's definitely worth, a discussion. A lot of topics were discussed in the repricing call last Wednesday. Things that would be relevant for… for getting the repricing locked in. Some important decisions to make. And, pavel also brought up, removing the self-destruct button EIP, which is already CFI'd.

Maria, would you like to talk about the EIPs and the topics required for repricing?

Maria Silva: Right, yeah, happy, happy to do it. So, first on 7904, so this is the compute operation repricings. So after the block-level access list optimizations, we realized that most clients are performing, better than the target of 100 million GAS per second, so this would mean that we would actually not require any repricing at all. The only exception was, Erigon, that they were performing across the board, significantly worse. They started to investigate the… the issue, and they found, so they… they… from their initial analysis, they feel like it's something they could fix on their side, so it's not, any specific blocker from their implementation. It's such… it's just something that they can fix, and so they would be also fine with pricing by the second worst instead of the worst case.

And so, up until this point, from the benchmarking results we are seeing, it seems like we could even drop 7904, so we wouldn't need to change any compute-related pricing. So… there, what I would suggest is, like, not included in any DevNets. So far, we can still keep it open and see, like, just double-check once we start to see more results from bal-devnet-7, that the… the performance keeps, as we… as we've seen him… as we… we've seen the performance so far, but I would say it doesn't make sense for us to… to consider including it, so far. And, yeah, so, Maurice, that's for a target of 100 million gas per second, so… so… so yes, that would be to…

300 million. Yeah, that is correct. And so, that's 7904. Then we have 8038 and 2780, so 8038 is the state access EIP, so we are changing the prices of state access, and 2780 is the, intrinsic costs reduction. And there, so my argument there is, like, we still don't have the final numbers for those EIPs, that is correct. And we would need the client optimizations to finalize those numbers, but at the same time, these EIPs are changing slightly how we price things, so it's not just an update on the parameters, and they also have some, info… so they kind of… also have some interactions with, the state's, growth EIP, so, AT37. And so I feel like even without having final numbers, it could be, beneficial to include both,

in the next, DevNet, so that we… we kind of, implement the new… Gas, model. And then figure out all the, interactions with AT37, and then once we have the final numbers, we go and we update just those, just those numbers. And, And so yeah, so that was essentially, part of the discussion on the repricing. So, the first takeaway is that I think they are so interconnected that it would make sense to do them together instead of having one and then the other. There's also a lot of interactions with AT37, so it would be better to de-risk it sooner rather than Then later, and a possibility of doing that would be to use the numbers as they are right now, so the current costs of the EVM, and then we update the

the constants with the… with the right numbers once we have the benchmarks. So yeah, that's… I think that's the update.

Danceratopz: Awesome, thanks, Maria. I just… Just to clarify for my own understanding, basically you would like to get them in DevNet 5, and you will do a benchmarking with 8038 and 278 in, and that might require, like, another loop on those two IAPs to adjust the values afterwards. Is that what would be expected?

Maria Silva: So I, I, I, I would expect the, changes that we introduced by adding 80, 38, and 2780 wouldn't change the underlying performance of clients, so I think we could still do benchmarking on bal-devnet-7 and continue to do benchmarking, in, further forks. Including them on bal-dev… on Glamsterdam DevNet 5 is more to de-risk the implementation Rather than having the final numbers and benchmarking them. So it's really just implement, make sure, like, the tests are correct, and then the implementation on clients and the interactions with other AIPs are correct, while we continue to work on optimization, so we can Get the final numbers.

Danceratopz: Okay, got it. Thank you. So… from what you said, just surmising, it sounds like we would get 8038 and 2780 in the Glamsterdam DevNet 5 spec. We would omit 7904, tentatively, and… sorry, about RPC versus Tracer, could you just… Summarise what your thoughts are there, or provide a bit more context.

Maria Silva: Right, so my understanding there was this was most… mostly helpful for AT37 debugging and testing, so it was this idea of it would be nice when clients are debugging their own implementations of 8037, and even during testnets, understand why clients are diverging, to have more information on the state gas versus regular gas that was used, and so there was a discussion on how do we do this? Should it be through the RPC or a tracer? And my understanding was, like, the tracer would be the solution that people seem to be preferring. But maybe, Stefan, I don't know if you want to give an update there, because I think you were the one more into this discussion.

Get back to the team.

Stefan Starflinger: Into what discussion? Sorry?

Maria Silva: This idea of adding more information about the state gas and regular gas usage during testing and the.

Stefan Starflinger: Oh, yeah. Yeah, I mean, I haven't changed anything in the tracer, or added a PR for that. I closed the other PR for the debug. What was it, receipts? Because that wasn't, didn't really have that much approval. So that's the work in progress, from my side. If anyone wants to chime in there. Async.

Danceratopz: Thanks a lot, Maria, for the update and for Stefan. I think if… does anyone else want to chime in on… on that topic? If not… I think we can discuss that async. So, I guess, we won't even talk about timing for glamsterdam-devnet-5. I think, we'll need to get a little bit closer to the date, but one thing that is definitely, worth bringing up ahead of time is whether that DevNet would include, Pavel's, proposal 8246 to remove the self-destruct burn. I think it's a no-brainer that if we're going to include that in Glamsterdam, we need to include it sooner rather than later. Are there any… does anyone have any concerns or thoughts around this? Does it need to be included earlier, maybe, in DevNet… Glamsterdam, DevNet 4?

Or is DevNet 5 the right way to go? Ben?

Ben Adams: Did we move that from DevNet 7, or was that something else?

Danceratopz: I've got… I think that must be something else. So this is about removing the, the fact that no ETH gets burnt during a self-destruct. Event, it just stays in the account. And the motivation for this, Would be that we avoid, any logs due to ETH burns, so it simplifies, simplifies 7708. If that helps with context.

Dragan Rakita: And we deprecate self-destruct.

Danceratopz: Was that a call to champion self-destruct dragon? Removing self-destruct.

Dragan Rakita: Oh, just dreaming.

Danceratopz: I guess if we want to remove self-destruct, we better hurry up. The glimpstone. So, regarding this, I think, for today, it seems… feels like everything's a little bit too far out. But… I would say the latest, 8246 goes into Glamsterdam devnet 5. I don't know if, Pavel's in the call and wants to say something.

Paweł Bylica: Yeah, I am. But I… I don't have much to add. You kind of have to schedule it somehow.

Danceratopz: Thanks, Pavel. Yeah. I don't think there's any strong feelings. I think, My feeling is that everyone is in alignment, that this will go in glamstone. Perhaps I'll just ask the obvious question, whether anyone's against having that in Glamsterdam. Speak up now. Otherwise, I think we'll take it to a later call.

Paweł Bylica: I actually have one more comment. I've seen 7708 has been updated, to be dependency of the EIP. So I guess we should consider, like, the pair of these to be included in some DevNet, I think.

Danceratopz: Yeah, that's, that's fair comment, and yeah, I think it's just… it's important just to make sure that, everyone's aware that it's CFI'd, and basically 7708 already has 8246 as a dependency. So, yeah, we should get it in a devnet sooner than later. glamsterdam-devnet-5 seems fine. In terms of specs and tests as well, from our side. Lewis already has a PR open. It's linked in the, It's linked in the agenda, in case you missed it, Pavel, you can take a look. All right. Then, I think that brings us to the end of our… excellent adventure through DevNet scoping. And just to… Tidy up the hour… the agenda with the last topics that are still remaining. Barnabus, do you have any context on your, beacon APIs?

PR that you wanted to talk about? produce block people with payload.

Barnabas Busa: You know, so this Bacon API, came up, last night, whether we want to merge that in. Right now, I think, different clients might treat, the purchase block V4 payload a bit different, and Yeah, I would just like to clarify that, we're gonna be using this format or something else. And if you're gonna use this, then, we should probably start merging this in, too.

Danceratopz: Is there anyone in particular that you'd like to call out, to for a review, or… People in college.

Barnabas Busa: Maybe Bharat, or… I don't know if Jimmy is here. Or anyone, basically, that's active in the Beacon API spec.

Bharath Vedartham: I haven't, like, caught up with the entire discussion, but the one thing that I can, like, mention is that So, in the Beacon API, just in that PR, there were conversations on the builder-boost factor. Right? So, like, the amount of… the bid boost for, like, a blinded versus an unblinded payload, which… which I don't think exists right today, because we don't have that notion anymore with an execution payload bid. So, So, yeah, so the thing is, like, the builder boost factor, the… the, definition of that, I think, definitely changes with EPBS, like. Like, are we boosting a P2P bid or a builder API bid? That's a separate discussion, but one of the things, I think the community people wanted was also, like, standardization along these flags, like the builder boost factor, etc. So I have a spec in the builder specs, separate from the builder API spec.

On just, like, standardizing these flags, right? For example, one… is, like, min bid, which I think is what, like, every… well, based on my conversations with, like, someone like Lidos, like, they're very, like, you know, they're very particular about MinBid, and something like max trusted bid. So these are basically configurations that clients will have to support. So, I have a PR in the builder spec to, like. specify these things, right? Like, so that, you know, they're kind of, like, we have a common place for all of them, and they're standardized across clients. So, I guess we don't have to define… my understanding, at least, is we don't have to define the… builder boost factor, probably, in the Beacon API, and that can probably move to

That conversation can be moved to Builder Specs. Is what I'm… is what I think. That seems to be the right thing, according to me.

Danceratopz: Chiming in that. Barnabas, to say… Give you a bit more context to work with.

Barnabas Busa: I just wanted to raise to, CLT teams to take a look at it and approve it, or, Or, yeah, just because it's really, like.

Danceratopz: Awesome, okay. Thanks a lot, Banavas. I guess we'll take the whip async. I mean, I think, shout out if I'm wrong. But I think the only agenda point we haven't taught, Got round to so far is… which proposal To use for the REST SSZ Engine API. spec. There's two proposals, open ones and draft. I'm just gonna dump, mario brought this up in the… comments… I'm just gonna dump from… That in the chat, so you can have a look at the links. Mario, did you have any context you wanted to share, or is there anyone you wanted to ask? Or reach out to about these topics.

Mario Vega: I think the only thing that I would like to raise is that we need, like, some sort of decision at some point, because we want to implement this also in the yields specs, so we can start using it in consume. And we can test clients with this. But it seems like there was no consensus on which one of these two is gonna be implemented in clients. So, just raising it to see if there's already a consensus, to see if already the clients have decided on which one of these is going to be implemented. To be honest, I don't have, like, the full, extent on the status of this, so perhaps we can ask around and see

Which ones, the clients prefer.

Danceratopz: Thanks a lot, Mario, for the context. Yeah, that's great. Annabis has chimed in that Nethermind and Erigon has already merged 764. Into their… into their master, or into their trunk branches. Does that… do any of the client teams want to, express a preference? Mario?

Mario Vega: Also, I could… I could add… I mean, based on NetherMind and Erigon already implementing this, I would ask them if they think this is the correct way to go, based on their experience, or whether they would change something. Also, I… I don't want us to rush getting this merged, and… But I would like for this to be specced correctly, rather. So yeah, I would ask, never mind, is this the correct way to go? Did you have any complaints or any, like, concerns about 764? Yep.

Danceratopz: Nice, good question. Does anyone from Nethermind want to… is your list implemented?

Łukasz Rozmej: Sorry, I… is out of it. Is this about SSZ? .

Danceratopz: Yes, exactly, that's right.

Łukasz Rozmej: So, what's the question? It was very, really straightforward to, to do the Barnabas, part… version, because we, actually managed to reuse our internal engine API implementation completely, so we basically just built on top, and now, both… JSON RPC version and SSZ version kind of point to the same implementation internally, just a different entry point with different, standardization scheme. So it was very simple from that point of view. Whoa.

Danceratopz: We did run.

Łukasz Rozmej: We did have to… sorry, if I can add one more thing, we did have to, you know, do a lot of things to make it really performant, because we kind of make it directly from the wire serization to serialization without any copies, but that was a different problem, that was optimization problem.

Danceratopz: All right, thanks a lot, that's a good data point. I see the other proposal, 793, is from Marius. Is he still in the call? Are you still around, Marius, and want to chime in? Do you have an opinion on… Do you have a proposal?

Marius van der Wijden: Yes. I think my proposal is better. Sorry. No, the… the… the difference between my proposal and… and, Bannabe's proposal is, well, both of them… were written by AI. But, I think the way I structured them is a bit, more cleanly, there was a comment from Julio that, I didn't understand, because… doesn't really, like, seems like he didn't really, read it. And the… the comment from… from Lukash, that he wants to… That he would rather, just change the transport. and then refactor it, I also… Don't really think it's valid.

Because, I think… The… my version doesn't really refactor the API, But it brings it in a much, nicer format than just porting it over, which I think is… It's not… Yeah, it's, it's not, it's not clear, it's not clean, it's, Not a solution that we should go for. We should take the time to implement it properly. It is not a big difference between Between the two approaches, but I think mine is much… Claude and mine is much cleaner than Claude and Barnabas.

Danceratopz: Okay, we are at the hour. I would… I would just… I don't think we're going to get any quick resolution on this one, and we do have ACD on Thursday to… to argue there about whose claud's better, but Luca, sorry, I will let you…

Łukasz Rozmej: Okay, so I basically had… because, to be honest, I didn't read all the details of Marius PR either, because it's 1,100 lines of code, and I'm a bit lazy to read AI-generated spec. But my question is, Marius, does your… do… have your changes anything beyond routing? Because my goal is to have the same code underneath for JSON RPC and SSZ, and if I can have that, if I just need to root it to different URLs, I'm fine with it, whatever. But if I have to do some special changes into the data structures and handling, I don't want to do that.

Marius van der Wijden: No, it's, it's routing and error, codes. Those are the two things that are different between… between the two.

Łukasz Rozmej: Okay, routing is trivial, because this is basically REST routing. Error codes, it would be good to have a summary of what's different in error codes.

Marius van der Wijden: Yep.

Łukasz Rozmej: To understand if this is a problem or not.

Danceratopz: All right, good questions, and I'm sure Maris will be very happy to discuss it further. I'd say we can take it async in the meantime. Balibus, go on, go for it. One last.

Barnabas Busa: Yeah, just one last point that, my, change suggestion was basically just to get it through the line as, fast as possible, and with as little changes as possible. So, So that's why I think Nethermind and Erigon could already merge it into their master branches, because there's really not that many changes that are required, To get this, 3D line, and just get a huge performance, benefit, basically without any re-architecting of the, Engine API. So that was my original proposal as well. I didn't want to introduce a huge change, because every time when we try to introduce a big change. coupled together with the SSZ stuff, then it seems to be just, getting dropped instead of getting implemented.

Danceratopz: Thanks a lot, Barnabis, for chiming in with that. I think that's really relevant. Perhaps we can separate the two consents?

Marius van der Wijden: I think the… Yeah, I think the counter-take is, should we really merge something that is, Like, that is not meaningfully better than… What we currently have.

Potuz: Why is it not better?

Marius van der Wijden: Well, because it's… it's… the way it is implemented is just super weird. Like, it breaks every REST API convention, it… Horrible, horrible, to, to maintain, and to extend, and, Like, we have one opportunity to significantly, like, to change the thing, the, the way we do things. And I think we should do that, instead of just… putting… shit on top of. What we have right now.

Dustin Brody: I actually say, we'll… I think… I want to respond to Kev, and I want to agree with Marius, and respond to… I see where, well, whatever else it is. I… I think there are a finite number of opportunities. It's very clear that people will just settle on something and use it and use it until it, like, can't be used in this sense. We've had essentially the same engine API for years, conceptually. And… I have a strong suspicion that the first SSE-ish thing that lands will be the one we use for a long time, and it's worth being careful about that, and that the argument for doing it has been, like, as some kind of emergency measure has been, I'm sorry, super unconvincing.

Danceratopz: Just… A reminder that we don't need to decide today, and we are over time, but… It's my bad, I should definitely schedule the arguments earlier in the call. Sorry about that. But… unless anyone has something else to add, I'd say we take it async, please discuss in the Discord, and, we can bring this up in ACD on… on… Thursday. Hope that sounds good to everyone. Anything else that someone wants to add? Thanks a lot, everyone, for coming. Have a good week. Happy DevNeting.

Marius van der Wijden: Bye-bye. Thank you, Dan.

Danceratopz: Goodbye, everyone.

Parithosh Jayanthi: Thank you, bye-bye.

Louis Tsai: 8.

Eitan Seri-Levi: I…

Potuz: Bye-bye.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.