All Core Devs - Execution #223

Transcript

Justin Florentine: Good morning, y'all.

Carson: Morning! Or, well, afternoon to anybody in Europe.

Ansgar Dietrichs: Good morning, everyone. Can you all hear me alright?

Justin Florentine: You sound great, Ann, Scar.

Ansgar Dietrichs: Also do you, perfect. There were some last-minute, agenda, additions. I'm currently on Pacific time, so I just woke up, so I couldn't process them over the last 6 hours, so I just added them to the agenda. So for anyone who had a look… Earlier. Do you have another look. And because the agenda got a bit more full, I ended up switching the… and we'll have the… EIP process proposal, not at the very end, as originally planned, but a little bit early on. But yeah. Okay, I think we are, do we want to wait a bit longer? Do we want to get going? I think we can go live now.

Josh Davis: Alright, you're live, Oscar.

Ansgar Dietrichs: Awesome. Well… Welcome, everyone, for… for AllCoreDevs, 223. It's gonna be a while until we have a nice number again. Yeah, this one will, I think, be primarily all about, Glamsterdam… EIP planning, but before we get into that, we do have a few Fusaka-related points, again. So, to start us off there, we have Barnabas with a quick update on the Sepolia BP01 and 2 situation?

Barnabas Busa: Yep, hi everyone. So, Fusaka DevNet 3 is still ongoing. We have 99% participation. Every single client combination is working just fine now. We rolled out the latest Lighthouse image, and that solved all of our bugs as of now. Tepolia had their BPO activated. 2 days ago, we went up to max blobs of 15, and the next BPO will be in 4 days and 9 hours. The next fork will be, than the Hudi network, which will get its, Fusaka update in 5 days and 4 hours. And then the first BPO will be in approximately 2 weeks from now. And, in 19 days BPO, too, on Houdi. everything went smoothly on BP01, and we expect a smooth transition on Hoodie as well. If you're running a Hudi validator, please make sure that you update your node, as there's only 5 years left now till the fork.

That's about it for the testnets.

Ansgar Dietrichs: Thank you, and it's great to see that it's going so smoothly. Is that… were there any comments? Did anyone have anything specifically regarding the testnets, regarding Sepolia, or the upcoming HUDI? Folks that they wanted to discuss?

Barnabas Busa: Maybe just one more, point. Pulaski is officially going away next week. It's already seeing some drop in participation. We are close to on finalization at this point. We are at the low 70s. So, if you're running a host key validator, just keep it up, till you can, and then we're gonna be officially shutting it off next week, Friday. And if you're listening, and you still have infrastructure running in OSCI, please migrate to Polia or Houdi as soon as possible.

Ansgar Dietrichs: Yep, perfect. That… thank you for that, Yeah, and so if anyone still has anything on their bucket list that they really wanted to get done on Holsky, now is your time. Okay, then next up, with everything going so smoothly, Alex wanted to talk about, mainnet dates. Alex, do you want to start us off? We then have a few comments to go through.

Alex Stokes: Yeah, definitely. So, last week, let's see, let me just make sure I have the right dates here… So, essentially, the proposal would be to follow, this document from Barnabas, which I can drop here in the chat, one second. And what does that have? So it has, mainnet for Fusakra on December 3rd. You can look at the Bakken slot there in the dock. BP01 and 2 on December 9th, and then on January 7th, respectively. So… We brought this up on last week's ACDC as sort of a temperature check, and… Was I… are you talking about the doc part of this? I just saw the chat here.

Barnabas Busa: Yeah, so the original, BF01 proposal was the 17th of December, and we have… there was a bit of pushback from different client teams, saying that the 17th of December falls a bit too close, to Christmas and the holidays. So we decided to, propose the 9th as BPO1.

Alex Stokes: I see, okay, so the dock hasn't updated, but yeah, it was moved from last time. Okay, thanks for calling it out. But yeah, so then check the doc for the latest times, but, yeah, long story short… We did, like, a temperature check, last call. People were generally on board, so I wanted to do the same thing here. So, I think one caveat is if we follow our process doc, I think, you know, when reading, it says basically we would wait to officially set these dates. Until Hoodie has finalized, which will be next week. That being said, if we want to go with the schedule, the timing's pretty tight, and so… That would ultimately look like client releases on… I believe that's November 3rd, so one week before… or sorry, one month before the proposed mainnet date.

And just given the timing, it makes sense to go ahead and get this on people's radars now. yeah, I would like to go ahead and see what people think about this here. Generally, I'd say from the CL side, we're gonna go with these dates. If we're good to go from the EL side, which we can, you know, assess on this call right now. then I would say, you know, basically we'll do this, we can follow our process and go ahead and confirm, officially on next week's ACDC. But, wanted to go ahead and get this on people's radars, just so they're aware, because, yeah, you know, you'll have more time to get a release together if you're a client team.

And I guess, final note, this is all conditional on hoodie going well, so again, if something doesn't for some reason, then yeah, we'll have to adjust. But so far, it's been going well, and it seems like we can pull this off, so… That's my spiel, and I'd love to hear from any EL teams or anyone else on the call, what they think about this.

Ansgar Dietrichs: Yeah, perfect, thank you. We already have a few comments in the chat from Lukash and Marius. Plus running. Anyone else with comments on… This… So maybe if we briefly just… Check, go through the… the client teams, to see, is there… is there anyone from Reth on the call with an opinion on this? Do these dates look reasonable from your side?

Jen: Yeah, looks good.

Ansgar Dietrichs: Sounds good. And from the peso side?

Justin Florentine: No issues here.

Ansgar Dietrichs: Awesome, and Aragon?

Andrew Ashikhmin: Yeah, sounds good.

Ansgar Dietrichs: Okay, did I miss any client? I don't… I hope so. You know, please, no more clients, I need one hand to count, and so this is great. Okay, then when we… yeah. Alex, you already mentioned that, basically, because there was also some discussions in the issue, Andrew mentioned that, yeah, the process specifically would then officially only make these dates, let us set these dates next week, but basically the idea is we pre… Pre-committing to this timeline, assuming, hoodie goes smoothly. Perfect. We will, a bit later on, talk about the GlumSlam EAP process, because then the question is also, does this then today already trigger the deadline for ERP proposals? So that would mean, now would be the last week that would start today, basically, for your pre-proposals, but let's get into that once we get to Amsterdam.

which actually we will do immediately now. So, any last comments on the actual timeline?

Barnabas Busa: Just one mention that I've proposed to basically clarify the mainnet update requirement, instead of maintenance should not have an upgraded set until all testnets have been upgraded, to manage should not have an upgrade date set until at least one testnet has been upgraded. I'm just curious what everyone thinks of this. I posted the PR for that, in the chat. Continuity. So this would basically allow us to schedule, the mainnet right now.

Ansgar Dietrichs: Put us?

Potuz: I'm not against this, but one issue that this raises is that our users might update the client. With a testnet release that has the mainnet date. But it's not really considered to be a mainnet release. Like, we are still releasing things, even though we've already been through a couple of testnets upgrades, and we still find bugs. And clients that, if we go with this thing of, like, setting a date well in advance after just one testnet upgrade, we might see users that haven't really upgraded to the actual mainnet release with all the bug fixes.

Ben Adams: Yeah, we don't need to put the dates in a release until… Closer to the race. If that makes sense.

Barnabas Busa: Yeah, it's… it would still be up to the clients when they want to back in the data. It's just that we could officially schedule today.

Alex Stokes: I guess one note is, I believe there's an escape hatch in this document. Let me go see if I can find the text, but basically it just says, like, you know, this is all subject to change at the whims of… ACD. The thing with this is that… it doesn't say which testnets, and, like, I think not all of them are created equal, essentially. But yeah, I think we could go either way.

Ansgar Dietrichs: Is this something that we'd prefer to make a decision on today, on the call, or would we rather take that discussion offline?

Marius van der Wijden: I… I prefer to set the date more in advance and have, like, people know the date, rather than following some arbitrary document that someone drafted up a long time ago.

Ben Adams: Yeah, I think…

Marius van der Wijden: Basically, predictability for the ecosystem.

Ben Adams: I think POTUS's concern is addressed by not Putting the dates into an actual release. Until later. Would that be correct, buddy?

Potuz: Yeah, so the… I mean, there are other issues, too. Like, on P2P, you advertise, when you have the next fork epoch, you change your ENR and a bunch of things, So the fork schedule changes, and this changes the configuration of clients, so we might have clients that are already announcing what the next fork is, and some clients that don't. It's not really a serious problem, it's just something to think about.

Ansgar Dietrichs: So could it make sense to have, like, an explicit decoupling of these two, points in time in the document? That we basically, like, we go with this proposed change, in terms of the… deciding the dates, but then we specifically, explicitly, like, use the old mechanism for… To say, basically, only after the last testnet do we have client releases, or would that not make sense?

Alex Stokes: Yeah, I think that could make sense. I don't see what it's going to change today, so then perhaps we just take this discussion async to the PR, and we can cover it next week's call. After people have chimed in there.

Ansgar Dietrichs: Yeah, that sounds good to me. Any last comments on it right now, or… Ready to move on? Okay, then, I mean, the chat remains open. Awesome. Then, I think we are ready to move to, Glamstadam. Before we get into the entire EAP side of things, I just wanted to briefly check, is there any specific DevNet updates, anything that… Happened, recently that people wanted to briefly talk about? Yeah, sorry, when I said definite, more like work towards definites, that's, I should have been a bit more precise. Okay, no problem. Alright. Oh, yeah.

Barnabas Busa: We have, local access list, crypto assist that's running locally, and, We are still iterating towards the… a staple DevNet. Hopefully, maybe tomorrow or early next week, we can launch, local access list DevNet Zero.

Ansgar Dietrichs: Awesome. That's very exciting. Good. Then… see, that's good context for us to go into. Into the governance discussions, that there's already real nice progress. Alex, you had a comment on the issue. We discussed over the last week the process for From now onwards, now that we're getting close to the… To the proposal deadline, how we want to go about the non-headliner EAP discussions. Do you want to summarize that?

Alex Stokes: Sure, yeah. So, yeah, I mean, I think this is our first time through this headliner process, and I think this transition wasn't exactly as concrete as it could be, so… To that end, just giving, like, an actual sort of schedule here, Yeah, again, like Ansgar was saying, it seems like we can go ahead and start thinking about Amsterdam, not headliners. And the sort of next milestone we had set is, you know, once we had agreed to Mainnet, then we'd have one week after as a deadline for proposals. And… again, it sounds like we'll confirm, quote, officially, these dates next call, but I think we're at a place where we can go ahead and do that. And again, that being…

Saying any non-headliner EIPs need to have been proposed for Amsterdam, with deadline one week from today. So, consider this your one-week call to do that. There's already actually…

Ben Adams: I have a concern on that. deadline, just due to the… due to the process of EIPs, so they have to go through the… is it the EIP office editing hours, if it's a new EIP? And next week is… ERCs and the week after is EIPs. If anybody wants to propose a new EIP, they're unlikely to get it in. Now, they're unlikely to get it in by next week deadline.

Alex Stokes: Fusion.

Pooja Ranjan: I just want to add a small point here. Next week is not ERC only, it is EIP plus ERC. We generally try to keep ERC one alternate week, but EIPs are all the weeks, so if there is anything, we can definitely add it on the agenda, and we can get it merged.

Alex Stokes: Okay, this was news to me, so… Okay, you're saying you have to go to the EIP editing office hours call to get an EIP arched? A new one?

Ben Adams: No, no, it's just… it's just the schedule on getting new ones merged isn't… I think, like, a two-week deadline would be… would be better. From now, since that date is forward.

Alex Stokes: Okay, I don't really see the link there. People not propose, and then…

Ben Adams: Yeah, but… you can't… you need the EIP numb numbered and merged, and then put in the proposal EIP. There's, like, it's…

Alex Stokes: Right, but I guess you're saying that they only hand out numbers if you show up to this call? That's the part I wasn't aware of.

Ben Adams: No, no, I'm saying if you… if you're trying to, yeah, what I'm saying is it's not… it's not instant. If you… EIP in today. You know, you won't necessarily… Be able to have it merged and in… The matter… EIP. By… next week.

Alex Stokes: Okay. Yeah, I guess I'm kind of wondering about this, and would echo Barnabas here in the chat, like. I think we can assign numbers as soon as there's a PR, and then… even if that PR is not merged, you could make yet another PR that puts the number into the meta-EIP.

Pooja Ranjan: I… if I'm… I'm sorry, Anskar, your hand is there, so if you want to…

Ansgar Dietrichs: Yeah, I just wanted to briefly, say that I think we should also be… to me, the deadline is really more about basically signaling your, the proposal intent, so if someone basically gets, like, if they don't yet have a number signed, or they have a number signed, but they don't figure out how to do the PR against the meta EIP before the other one is merged, or whatever, and they end up just commenting on the… on next week's ACDC issue with the intent to propose the EIP, anything like this, I think as long as it's clear that an ERP is proposed, basically by a week from now, I personally would not Mind counting that against the deadline.

Given that it's a bit of a… Yeah, more symbolic. Point in time, anyway.

Ben Adams: Yeah, okay, that's… that's fine.

Pooja Ranjan: That's very helpful.

Alex Stokes: Yeah.

Pooja Ranjan: I would echo with Emska here, but generally, speaking, getting back to Ben Adams' point, I think it would be a good idea to give a two weeks timeline for any new author to propose anything, like, at least getting the PR merged, as in draft format, but, as it is also mentioned in the chat, generally speaking, we get the number almost the same day, and we can use that number, we can use that number against the meta-EIP as well. We can perhaps update it later on.

Alex Stokes: Okay, so then I'll amend this to say, yeah, like, even… just a PR to the IP repo would count, and we can sort out the governance stuff, you know, in parallel, if we need to. But I would prefer to keep things moving here, just… to keep, yeah, keep things moving. Otherwise, yeah, it'll just spill out further in time. And, you know, one reason why is the next point, which is that, yeah, because of this, then we can move to, you know, discussing the different EIPs. There are a large number of ELEAPs to go through, so we'll need to reason about that. There's fewer on the CL side, so it should be easier, but, towards that end, I think having…

Some sort of document of clients and opinions, like we've done in the past, would be really useful. And even if it's, like, higher level, like, you know, I don't know if people are gonna necessarily have a view on every last EIP, but even, like, directionally with themes would be good, and I think that will help, you know, us here, as we go over the next couple calls, sort through all the different EIPs. I would propose, then, that clients try to get such lists out by, like, November 6th, and then I think that's an ACDE date. Let me just double check. Yes, it is. So… having that ready, and then that basically gives us the rest of November to go ahead and sort through everything.

Then we can finalize the Glamster Dam scope, by November.

Ansgar Dietrichs: Right, and just to give a little bit of context for this, because if someone hasn't checked, if some of you haven't checked the PFI list for a while, we have currently… well, it's a bit in flux, and we'll hopefully be able to, later on this call, to remove up to 2 EIPs from it, but we are roughly 30… at 30 proposed EAPs. Out of those 30, it's exactly 2 C outside EIPs. Plus you can count fossil, but fossil is already CFI'd, so… so we have three CL-side ERPs. There might be one more coming, I heard. But basically, then we have 27, 28, outside EAPs, so the, it… there's, like, a very big asymmetry, also in terms of the… the amount of work to just…

go through for client teams, and even as Alex was saying, even if, say, a full-on EIP by EIP, yes-no opinion is, I think, not really necessary for the first round of… documents with opinions, but even just in terms of having ideas of, like, what themes, what rough scoping, these kind of things, it will be more effort for ELDF, so I think you should be aware of that when we discuss timelines. That said, yeah, what do people think about Alex's idea to basically have, a first round of People going over the EPs, forming opinions, communicating them over the next two weeks. Does that sound realistic?

Łukasz Rozmej: Well, it sounds a bit aggressive if there are 20 ATIPs, but we'll see what we can do.

Justin Florentine: Yeah, I'm kind of thinking the same thing. Feels a little tight, I think one more week would be totally doable, but I don't super strongly hold that opinion.

Ansgar Dietrichs: Yeah, Alex and I were going back and forth about this as well. Obviously, the problem is that, these documents really only make sense for an ACDE, so then the question would be 2 weeks, or then otherwise 4 weeks, really. And 4 weeks gets us basically exactly to the, to the ACDE that is right during DEF CON. I don't think we've decided yet whether we'll skip that ACD or not, but either way, it doesn't feel like an ideal. point either, and then otherwise, we only really, have time towards the end of the year, so it feels like it would be really, really nice if we could make two weeks from now happen, even if, again, like, I think given the number of EIPs, we… it would be understood that it's much more of a coarse view of

Like, just some basis for discussion, that people basically come into it with some clear idea, at least, of how they feel about the general list. Not so much, like, a super detailed opinion, ERP by ERP. But also, we do need to make realistic plans. So the question is, like, yeah, do people think that even if not ideal, that can work, or is it just unrealistic in two weeks?

Łukasz Rozmej: I think it can, we just need to schedule it, and yeah. So, hopefully, yes.

Ansgar Dietrichs: Okay, anyone that really hates this? Otherwise, I do think we should probably look in that approach. Okay, yeah, Alex, I think then we can say we continue with that, and we say that, for… can you maybe clarify also, Alex, for the two weeks from now? Is that just for the EL client devs? How does that… I mean, again, the CL side is much more comfortable, but how would that map to the CL side?

Alex Stokes: Yeah, I mean, if… if client… if, like, a CL client team finds it useful, then, you know, by all means, I think that would be good. But yeah, there's really only, yeah, like, 3 or so. CLEIPs, so I feel like we could probably just cover them in turn.

Ansgar Dietrichs: Okay, yeah, then… so then we just make… specifically make it a process point for the EL site. So, then… I'll also try to do some shepherding, reach out to you all. I also had a plan separately to, to, maybe with a few colleagues from the research side, have a few thoughts, published. I just didn't want to do it before this call, because obviously there's always this tension between me as a coordinator and me also sometimes having opinions, so if you see opinions of mine over the next week or so, make sure that that, yeah, that treat them as just, like, as a researcher opinion or not a coordinator opinion. But yeah, then let's… let's lock in the process, and so on ACDE, in two weeks, we will, hopefully have at least some general, like, documents from… from… from each

Yale client with, with, with, a take on how we should go about these, PFI ERPs? And then we can kind of dive into the details there. Lucas?

Łukasz Rozmej: Could we also give opinion on CFI TIPs?

Ansgar Dietrichs: So you're asking specifically about fossil there? I think that's the only CFI DRP that we have?

Łukasz Rozmej: Oh, okay. Yeah, sure, so… Yeah, because, like… You know, we can weigh which ones we want more or less, right? So fossils should also be on this list where…

Ansgar Dietrichs: Yeah, that's a good clarification. I do think, yeah, I would include fossil in the scope. That makes sense. It is, of course, primarily, I think, implementation overhead-wise, as seal-heavy, but I think governance side, it makes sense to have it covered on both. I'm trying to also follow along with chat. I think… I guess there is a suggestion of whether we can repurpose out of the order, basically, like, one… CL site call, ACDC for some EL… Work, basically.

Does anyone want to… Briefly talk about that idea?

Barnabas Busa: So instead of waiting just… for nothing, we should probably just go through all the EL EIPs, in an ACDC call, or just rename that one call to ACDE, so that we can have all the EL devs show up as well.

Ansgar Dietrichs: That seems reasonable, and would that be then… I assume that wouldn't really make sense for next week already, because, I mean, A, that would be a bit short notice, and B, that would be before even that initial deadline, so is that more maybe for the one in three weeks, then? M.

Alex Stokes: I also think we should get through all the CL stuff first, like… if we happen to, you know, get through all the seal stuff, and it's good, then yeah, if there's, like, if it makes sense, we could… Swap one of the calls.

Ansgar Dietrichs: Okay, so then you're saying this is better discussed on an ACDC call, if it…

Alex Stokes: Well, I think more just we might need a little more time, like… I think it's just a, yeah, one or two calls early to say we're gonna need that.

Ansgar Dietrichs: Okay, so, Ben, let's bench this for now, maybe? Oh, Ben, do you have a comment on this?

Ben Adams: Yeah, we often have extra time in ACDT also. I mean, we could maybe use that as well. Just gives us… That's a large volume.

Ansgar Dietrichs: Sounds good. So then, but do we all agree that that's all more for, like, basically after that initial two-week period, or would, basically, does someone want to basically try to, like, allocate some specific time, ACD-related time, over the next two weeks already for some specific discussion?

Łukasz Rozmej: I would say after.

Ansgar Dietrichs: Okay, then, it's a good idea, and we can already, like, explore basically what kind of the… We have there, but yeah, let's then discuss in two weeks. Any kind of extra, opportunities for discussion. Is there… I also saw in chat the question, basically, for any EIP champions that have ERPs proposed, is there anything they can do, basically, like, over the next two weeks to make the ERP maximally legible, to basically make it easier for people as they go through the list to understand kind of the positioning of the EIP. Anything like that?

Alex Stokes: this might be a little tangential, but I just, want to call out Marius's comment here in the chat. Essentially having, like, a DFI section on a client team list would be very helpful. Just, you know, if there's things we know we don't want, then we can just acknowledge that and hopefully cut down the list. Pretty quickly.

Justin Florentine: Real quick question. How complete is our list of champions for the EIPs? That would be a great way for folks to reach out and come to this meeting with specific questions that they have on each one. Is that… Gonna be good to go and useful for people? Almost fully complete. Yes, Josh, thank you.

Ansgar Dietrichs: And Josh, I think my understanding is that the one ERP that's missing a champion, we also have that on the agenda for today, right? I think that might actually get removed anyway, unless you're talking about a different one. Yeah, perfect. Justin, did you mean that we should have encouraged the ERP champions to specifically all show up in two weeks, or was that not what you were trying to say?

Justin Florentine: what I was trying to say was that, the AIP champions and being able to contact them is a key part of the pre-work, so that we can limit the discussion to specific questions that folks have for each EIP.

Ansgar Dietrichs: Okay, yeah, so basically, like, just, this is… this is a call to all the EAP champions. Please make sure you are very available over the next two weeks, if you want to give your EAP the maximal chances, people might specifically have questions. I might try to reach out to you, make that as easy for people as possible. Okay, Alex, other than the specific, kind of, two weeks from now, documents, process, was there any other specific. like, proposed action item from your process overview? Or would we just then take everything else as we go?

Alex Stokes: I think that's it, yeah. I mean, again, I just… the… core constraint, let's say, is I would like just to have this settled by the end of next month. And yeah, I think, having, you know, written views as soon as possible will help people make progress, throughout the next month, and definitely, yeah, you know. we are, quote, twiddling our thumbs on the CL side, we can offer some time to keep the discussion going. So yeah, we'll see how it goes. I mean, hopefully it's pretty streamlined, and yeah, we won't need to… Make that many adjustments, but yeah. Otherwise, let's take it as we go.

Ansgar Dietrichs: Sounds good. And then one more comment from my side there, it would also be nice, given that the ACDE in two weeks, again, is, like, right in the middle of the DEFCON week, if maybe people make sure that they internally discuss with their team, so that, like, on next ACDE, we can talk about what we do with that call, do we keep it, do we… remove it. Obviously, that would then, also inform the general discussion of whether we can find some alternative, kind of. call opportunities, for… for ERP discussion, yeah, I think that would be… Very useful. Yeah, with that, any… anyone else that… I mean, I see there's an active chat discussion, I'm sure there's going to be a lot of offline discussion as well. Is there anything, still on this… around this general process question that… that we should synchronously discuss now?

Okay, then I think we can go… to some… more general EIP, glam system EIP housekeeping. We might have the list grow or shrink a bit more over the next few minutes, so let's all hope for the best, hope for more EIPs being removed than added. But with that, Maria, you had two repricing-related topics you wanted to touch on?

Maria Silva: So the first one is a quick one. So, on, following this discussion, I, I posted here on… on the issue, a proposal for adding to breakout calls, to discuss repricing EIPs. So, of the 31 EIPs, a lot of them are repricings, and they have some, technical details that are not just, changing parameters, some are simply changing some… some numbers, but there are others that are more… have more, depth, let's say. And so I think it would be useful to have, two additional breakouts where we kind of deep dive on all the EIPs. We discuss potential issues, and then, we can have some sort of, early…

signaling on prioritization and understanding if things make sense. And the proposal would be to have it on Wednesday. At 3 UTC, so we do next Wednesday, and then the Wednesday after. And then after that, we can, come to ACDE, with an overview of key takeaways from that. So yeah, so I'm proposing it. I think it would be useful, but I want to know if folks that are interested in these find it useful, because if we're gonna have attendance in those breakout rooms, they are not as interesting. So yeah, just putting it out, to see if false, it's… it's… It's useful.

Ben Adams: Yeah, yeah, I think, I think it's quite important because there are so many different… repricing EIPs that we really need to… holistic view of them all together. I think it would be… Very valuable to have the breakouts. Beforehand.

Ansgar Dietrichs: Yeah, I mean, I'm obviously biased on this topic, I'm somewhat involved with a lot of this repricing work myself. Yeah, I do think that given that that's much more… Clustered, at least. There's a lot of interconnections. Yeah, I do think this would be very, very helpful. Do people, as Maria said, the idea would be to basically use both? next Wednesdays. Does that work for people? I think it's enough, like, there's… there's more than 10 ERPs that at least are related to repricing, so… so I think there's really a lot to go through. It would be a bit rushed to try to do this in a single call. Does that work for people, or is it… it's basically too… too much to ask?

Ben Adams: Works for me.

Ansgar Dietrichs: Okay, so… Yeah, Maria, sounds like…

Maria Silva: Yeah, yeah, seems like… Some people are interested, there are no clear, cons or timings that don't work, so… Perry, you are asking, do we expect community members in these repricing calls or not? I would say, I think these calls should be open to anyone, but I understand that People that will show will be mostly car dives, but yeah, The page captains as well.

Ansgar Dietrichs: But I would say, maybe a clarification question, Maria, right? My assumption would be that it would be… like, the focus would be more a technical… the technical side, and, like, going through that, and answering people's questions, but maybe less so the specific governance conversation, or, like, the… Yeah, or do you have a different…

Maria Silva: No, no, no, no, no, no, exactly. It's mostly about, like, understanding the EIPs and doing more technical deep dives on it. Of course, the governance discussion will be on ACD.

Ben Adams: And I assume a little bit will be… Trying to… Smooth over any rough edges so that the IPs are… Consistent with each other.

Maria Silva: Bye. Okay, so I think maybe we can move to the next topic. So, Asgar, I'm not sure what the process is, but we can figure it out. I think, we will schedule these breakout calls. Cool. So the next topic I wanted, so I'll just quickly share my screen. for this one. So I wanted to talk about, Browning errors, and why this is important for repricings. So… First, what is… what is the problem here? So the… the problem is, essentially, the compute upcodes are way too efficient when compared to the other operations and the current gas price. So this means that with integer gas, we cannot make them cheap enough.

To actually have the right balance of difference in pricing between the really efficient offloads and the remaining uploads. And so… This means that, at the moment, even if we do a repricing. without doing anything else, we will have rounding errors. And what do I mean by a rounding error? So imagine that an operation… so we do the benchmarking, we find a certain anchor, so it could be, for instance, ECUB Cover or something like this, and we say that an operation should cost 0.8. But because we cannot have, fractional gas, we have to round it up to 1. And so this means that for that operation, we incur a 20% error due to routing. So this means that we could fit 20 more of this operation, if we were not running it.

And, you can see here, so here I'm just, plotting the average rounding error for compute operations. Assuming different anchors, and so here, anchors, I'm using the milligars per second metric, so you kind of, use these, and then you assume a block execution time of 2 seconds, you derive the block limit, and you can do then the anchoring based on that. And you can see here that with, the performances that we have right now, so it's around the, the 30 to 50 milligars per second. We do have a lot of running errors on average, and then only after the 500 milligars per second anchor, which is an order of magnitudes larger than what we have right now, is when we actually start to have

Low grounding errors. And if we look at transaction levels, so here I just took a sample of a thousand blocks. And I saw how many of each opcodes were executed in those blocks, and I assumed the repricing based on the Aztec's empirical analysis, so the analysis for the EIP704, and then I did the reprice, assuming 50 milligars per second. Anchor, and essentially you can see the level of errors that we get on an average block, so this would be around 4%. And so, this is the problem. Now, I think we have two solutions, and I will just give, like, a quick overview of them. So, one option is we just do a rebase, so we can…

go to all GAS variables and parameters, and just scale them by a factor of a thousand. Block limits and targets move from billion of units to… to… from million to billion, and gas costs move from units to thousands. And so this allows us, then, on the compute side. To actually make them much more cheaper while still having integer Gus. Or we can do fractional gas. So, there was an old EIP called particle gas, so DIP would be similar, so we add a new counter, it could be milli gas. And then all… everything inside the EVM execution of the transaction is, accounted in Milligas, and then we do a rounding at the end of the transaction, so…

During transaction execution, you use this new counter. After transaction execution, you round up, and then transaction fee, transaction GAS limits, block limits, and everything is going back to the normal gas. So these are the two… solution, so both have pros and cons. So, on fractional gas, you are essentially adding some, complexity to the EVM, so we are adding a new variable, and we are adding this, mechanism of running a transaction level. But the gas rebate, will likely impact UX, so this is kind of, first a hammer on hard-coated valleys, so we may be breaking stuff. And also, it… So this, this point can be… debatable. It's like, how much of a… different experience this is, because users mostly have the gas estimation with their wallets, and devs, maybe they can adjust, but essentially, it's like the concept of gas and gas limit will change.

And this, this could have an impact. So I know this was very fast, so I just wanted to have… To, to put these in your attention, and also to ask if there's, like, Any solution that seems to be clearly better than the other, and the reason I'm asking is, I already have drafted initial EIPs for both solutions. And I can propose them both for Glamsterdam, and then have this discussion, during the governance process, or if there's already a clear solution, I can just, Proposed one of them, and then we can discuss if it makes sense to include it or not, instead of having to, So yeah, if there are any comments, I will open the floor now. Also, I will share the link after you have here the references for the analysis, for the… for the… the compute repricing, and also for the apps that I…

We're selling robots. Okay, I'm trying to follow now the shots. Yeah, but please just jump in if you have any comments.

Ansgar Dietrichs: Andrew?

Andrew Ashikhmin: Well, I think it's an unnecessary complication, because there is a lot of variability in the actual costs, like which architecture you run on. which is the underlying libraries, like numerical libraries, you use for computationally heavy stuff. How… like, whether you use, like, for things like storage versus CPU, it depends a lot on various data structures, hashes, and, like, whether… like, whether you use an NVMe or not, so it's like, there is so much… variability that, to my mind, it's the… it's kind of… the… the uncertainty In the actual cost is just too big to justify such fine-grain adjustments, and we are, to my… like, I see it as we are trying to, like, this is a micro-optimization… an unnecessary micro-optimization, so we have much, much bigger fish to fry. If we…

adjust the, like, do the, like, first, like, we should move step by step, first things first, like, let's do the first order. pricing readjustment, which aligns better with the actual cost, but my point is, like, maybe the second order is just infeasible, because, yeah, like, you… The real costs will vary a lot depending on the architecture, the hardware, and the software.

Ansgar Dietrichs: Mario, do you have.

Maria Silva: Right, so I, I think… so your comment, you are not necessarily referring one solution or the other, you are just saying none of the solutions.

Andrew Ashikhmin: Correct. I think it's, at this point at least, none of, like, none of the solutions are necessary.

Maria Silva: Right. So I, I think to… To me, that discussion is something we can… we can have, at some… at some point, and I think it makes sense to have, based on all the other EIPs that we have. But yeah, I think I would like to focus more on just the difference between the two possibilities, and whether there's a clear One that is better than the other. But yeah, thank you, thank you.

Ansgar Dietrichs: And then Carl, next up?

Carl Beekhuizen: Yeah, thanks. A few things, yeah. Addressing some of the points raised, previously, the… like, we always use the worst-case client. So, like, sure, there's variability between clients, and even the benchmarks only have a limited resolution, but we always use the worst-case client for a benchmark. And so, like, that is our constraint. I kind of disagree if we're, like, have a… like, average rounding errors or something of… or, like, if we have rounding, that's, like, 20% off, like, that's 20% scale we're just leaving in one dimension on the table. Obviously, that'll vary per opcode, but… I think this is, like, some kind of optimization we can achieve there. The second thing is that… In effect, we are rebasing anyway. Like, every single opcode, we're just proposing changing the pricing here.

So all rebasing is, like, the rebasing idea here is doing is just being like, okay, cool, but we're gonna change, like, agree to change everything by a slightly bigger… Factor than we intended to. And we can, like… debate how big that needs to be, right? The proposed rebase here was 1,000, but even if we do a rebase of, like, scale everything by 10x, then something that was, like, a 20% error is now a 2% error. That's a very big difference. So yeah, I think there's… there are many things we can do here to achieve some of these things here. I'm personally not a huge fan of… Doing particle gas, I think it's just, like, massive complexity here.

But, like, within the EVM, and, and risks of… Having, consensus errors, but, that's open for debate. The second thing that, LightClient was raising is, like, concerns about breaking existing contracts. So I've been running some experiments, and in all the transactions, we have ever. like, changing, rebasing 1000X. There are 1,000 transactions that would fail, that would have previously succeeded, and 1,300 transactions that have a different state route at the end. So, in effect. Like, basically none of the transactions change or run into new errors or that kind of thing. So it seems to be, like, very marginal effects to, like, actual… EVM users and transactions, so I don't think that should be a major thing that's holding us back right now.

I think the bigger things you're gonna see is, like, what happens on, like, when we, like, to existing, like, tooling and that kind of thing outside of the EVM, and wallets, as opposed to, like, how does it break contracts within the EVM? It seems like people have been pretty good about not hard-coding too much. Yeah, gas constants, etc.

Ansgar Dietrichs: Ben?

Ben Adams: I mean, with… with rebasing externally. You have a problem that… plants… Because we were all too slow to move our defaults, they've… Set what the block gas limit is, and… So we… we don't control what the validators do, so we'd have to coordinate everybody to also rebase up, unless we reinterpret the values. Then you've got, yeah, wallets and so forth. There's a lot of UX. On the upper end. Coupled with that, smart contracts that do, you know, gas left and all that sort of stuff. Or pass explicit gas in coal. Upgrades. Whereas we could do… in… we could do… I mean, at particle gas, we'd ascent… we wouldn't introduce floating-point numbers, we'd just… Internally rebased, so… in the EVM, we'd rebate everything up, and then when it was red, we'd just…

Rebase it back down one more. You know, when there's any introspection. Or at the end of the contract. So, we sort of did both, so… So the gas didn't change, but internally, when we're processing it, we assume everything's 10 times bigger, or 100 times bigger. And that could work.

Ansgar Dietrichs: And my understanding is that it's basically exactly… that would be… that variant you just described would be the Milligas proposal, or the… there was, I think, an old ERP in the past called Particle Gas, all kind of similar ideas. Maria, can you briefly clarify? Is that…

Maria Silva: Yeah, yeah.

Ansgar Dietrichs: Give me at least two.

Maria Silva: Yeah, that's… that's exactly how it works. So you have an internal counter that is still an integer, and then that would be the milligas counter, and all the op codes prices would be in milligas. The gas left accounting would be in milligas. But then at the end of the transaction, you round up to GAD, and so you report… the EVM reports back the gas, but not technically gas. So, everything at transaction limits, transaction fees, and so on, so forth, block limits are still In gas.

Ansgar Dietrichs: Okay, photos?

Potuz: Yeah, one thing that called my attention is that, A bunch of the data supporting this is based on anchoring on 2 seconds to execution. And this will change dramatically on Glamsterdam, and then even potentially might change even more on the age fork. So… so that's something to… to keep in mind, that if we are anchoring on 2 seconds execution, then Glamstering gives us 8. Perhaps the numbers we're getting are wrong, or not, just not the appropriate ones. And then again, if we shorten the slot times, then… Well, that one might not be so dramatic if we also divide the gas limit, but again, the point stands that, Seems a little bit premature if we do not know what the effects of longer execution is going to be.

Maria Silva: So I would add, the way that we are defining the anchors is on million gas per second, so you can then use that rationale to say what would be the block limit on a certain execution time, so if you want to do 2 seconds, you can… make the conversion by multiplying by 2. If you want to do 4 seconds, you multiply it by 4, but the anchor is on a per second, so it's kind of like… It's… it's independent, so the only thing that then… like, if you are anchoring on a 50 million gas per second, the only thing is that if you are then Allowing for… for second execution time, you… you… you can raise the block limit by…

for a set amount. But the rounding errors shouldn't change. Because it's on a per… so the plot I was showing is on a per transaction, was the second plot, and the first plot was on the per upload level. Does these make sense?

Ansgar Dietrichs: Yeah, maybe this specific topic we can type to the chat. I would also… maybe try to timebox this discussion a little bit. We can go a few more minutes, but given that we are not yet actually talking about the governance decision of including anything, we're just talking about which variant or both to even propose. So, yeah, let's go through, like, whatever comments people still have, but then I do think we should probably… leave some room for the other, agenda topics as well. Andrew?

Andrew Ashikhmin: Yeah, I think what would be helpful is to, maybe it's already reported somewhere, but I would like to see the variability of the actual costs, because, as I mentioned, it depends a lot on the hardware. And even on the same hardware, there are some natural variability, like, during two. whether something is close to the CPU in caches or not, things like that. So, if you run a bunch of experiments, I would like to see the standard deviation and things like that. I think that would help us to… Yeah, basically to make more… In informed decisions.

Maria Silva: Right, so I was using the data from the ASIC's empirical analysis, I'm happy to share the link, but in the slides, there's a link to the EIP, and then the EIP is the link to the analysis. But if you can't find it, I'm happy, like, just ping me on Discord, and I will share that with you. But we are also working on redoing some of those benchmarks, so we'll be able to make more numbers, then. Okay.

Andrew Ashikhmin: Yeah, and I would be interested in comparison of, like, like, we do have minimal hardware specs, so I would like to see results both for NVMe versus SSD, and for ARM versus AMD, at least.

Maria Silva: Yeah, if I recall correctly, ASX Analysis was doing just, one hardware spec, not multiple, but I can… I can send that to you.

Ansgar Dietrichs: And just to mention, I do think that sounded like a general kind of repricing question, not just related to this precision question, so I think that would also be a great topic for next week's call. The breakout call, specifically, around, repricings, like the question of what does the… what are the benchmarking bases for the different repricing. Proposals. Carl, you have your hand up?

Carl Beekhuizen: Yeah, just briefly, the repricing, like… the data that's being used here is kind of… should be treated as preliminary data, like, this is not the proposal for the final EIP. As clients are improving, and as we get, like, much better benchmarking data, like, expect these numbers to change, and the exact things here to be reworked. This is more just flagging what are the questions that we already know are going to come up based on what we can already see in this data. Yeah, all these concerns are very valid and should be brought up and, like, discussed in these other things, but, like, we're not making… the proposal here isn't to make a final decision on

Exactly how things are done right now.

Ansgar Dietrichs: Sounds good. Yeah, then maybe it did sound like some people were skeptical that we need either of the three APs, and then within that, some people preferred one approach than the other. I don't… there doesn't seem to be that much harm in having both proposed, given that at most, one of them will make it into the fork anyway, other than to make the lives of everyone on the call that has to go through it in the next two weeks, like, slightly worse, because they have to briefly understand that these two, are basically just doing the same thing in different ways. But I feel like that's manageable, given that we just talked about it. So, I don't know, like, does that mean maybe… yeah, maybe it seems like the default outcome would be to maybe propose both.

Maria Silva: Yeah, it seems like there's no consensus, so I would just simply propose both and give you work. Sorry about that.

Ansgar Dietrichs: Okay, yeah. Awesome, thank you, Marie, for that segment. Then, let's move on. The next one is, is nice, because it might just, actually reduce everyone's work a tiny amount. There are two EIPs that, I think, my understanding is, can be removed from PFI list, but I wanted to briefly go through them. There is EIP7667. Nixo, you first, observed that, it, or at least you left the comment on the agenda that, that it, lacks a champion, and then also, I think Sophia just now left a comment on the agenda, saying that the ZK team also thinks that Glamstadam is not yet the right fork for this EIP? Can… is there any, kind of, any… Anything to add on, like, the status of the CIP?

Or any considerations around potentially removing it from the PFI set?

Nixo: I can just say it was added to, this PFI set only because it sort of came, in a bundle with the last, set of PFIs that were supposed to be for the vertical fork. So it really wasn't even intended to be added to this fork in a way that, that the other PFIs were. So, it should be uncontroversial, but if anybody has any… Reason that it should be added.

Guillaume Ballet: Speak up now. What's the other EIP, actually, that you described?

Ansgar Dietrichs: No, I think that's true for both EAPs. Both ERPs, yeah.

Nixo: This, this EIP was originally proposed in April of 2024.

Ansgar Dietrichs: And just for context for people, like, this EAP, the reason why that one… this one is at least in principle still relevant for the future, and even before any state changes, is that the idea is to make precompiles more expensive to account for the cost that it causes for ZK EVM provers. But, I think my understanding is that, basically, like, in general, that discussion, both on the benchmark side, on the general, like, do we even want to do this, do we want to make prices based on ZK performance, is not yet advanced enough to be relevant yet for Glamsterdam, so unless there's any specific objections, we can… Remove it from PFI. And then, Guillaume already mentioned it, the other one, I think, that I came across, I think is even more clear-cut, that's 6873, which, is, I think, just a preparatory step for any kind of tree change. Like, I don't know, Guillaume, do you have any

concrete content you already said offline that you think it would make sense to remove it from PFI?

Guillaume Ballet: Yeah, it was inherited from, like, it was moved, I think, by Tim. to… to, to Fusaka or Glamsterdam. I guess it bounced to Glamsterdam after a while. We don't need it for the moment, so there's no reason to keep it on the roster.

Ansgar Dietrichs: Awesome. Then after this call, I'll remove both of these ERPs from PFI, and… We made you also stop just a tiny bit easier, so… small win. Awesome. And thank you, Nixu, for, for, bringing this up, because, yeah, that's really good. M… Yeah, then we have one more agenda point, which is Carlos wanted to talk about EIP 8058. Palace?

CPerezz: Yep, I'll share my screen. Hold on one sec… Okay, I need to restart soon, so just one second, apologies. Thank you, Marius.

Ansgar Dietrichs: Maris, can you maybe do this, like, you know, at the beginning of each stream, before we go live? That would be really nice.

CPerezz: Okay, so you should be seeing my screen now. So yeah, I want to quickly present this EIP. Nothing really complex, so I think we can go quite fast through it. So basically, the idea is that with EIPs that are being proposed for Glamsterdam, especially the ones that reprise, state access and state growth, aggressively, some of them, like, 8037 and 8038, one of the realizations that we came up with was that, Clients are basically incurring into any cost when the user deploys bytecode that is already deployed, so basically it already exists on their database, and therefore they don't know… they don't do anything. But they charge, as if they were actually duplicating the bytecode, which is not something that they do.

So, the idea was to basically address this, mainly because if we get something like EIP837, the gas cost for deploying a contract will jump up significantly, and the price that users will incur for deploying contracts will be quite outrageous. So, if If they aren't even incurring into any state growth, it's a bit weird to charge them that much. So, the idea of the deduplication is simple. It's based on using access lists. The why will come later, but the idea is, if you're a user and you know that this contract, is already deployed and another account, has its code hash stored. You just include this in the access list, and therefore the client, the only thing that needs to do is run the init code, hash the resulting bytecode, and see if those match.

If there's a match, there's no need to actually deploy any bytecode, and therefore, the client can skip charging the gas code deposit cost to the end user. So, just to address some minimal things, if we add it within the same block, the expected behavior is that transaction A will always pay the full gas cost if the address doesn't exist. If there's another transaction which happens to include the previous one, which is quite unrealistic, but could happen, we basically treat it on this way and receive the duplication cost, too. The core trade-off here, which is what I want to basically discuss, is the following. We went for the access list-based approach, because there's two main problems. The first one is.

We don't want to force clients to hold a reverse mapping between code and account, which is what we will need to do if clients will be able to just look up this. So that we basically, A, reduce storage, or at least we don't make it even bigger, and B, we reduce the complexity of the AIP to the minimal. There's a second thing, which is, if you snap sync or you fullsync, the bytecodes that you will have are different. Because some clients, when they full sync, they store bytecodes of reorgs, because they are basically not part of the state, technically. And so… when you snap sync, you will… you will not see an account that has the gold hash, and therefore you will never ask for this range of leads, and so you will… what we have is essentially clients having, like.

in Cancun was at 27,000 difference between bytecodes that they have, or bytecodes that they don't have between each other. So to avoid all of this mess, the simplest thing was to just do it via access list. The problem, of course, is that if we do it on this way, at the moment, there's no clients that actually expose any RPC endpoint to actually check for cold duplication. There's external services that allow you to do that, like third parties, Etherscan, and there's some others. It's free to do so. But of course, I mean, I understand that it incurs in some UX friction. At the end, I tried to bring this topic to the wallet meeting last week.

But no one showed up, so we couldn't discuss it. One of the main, things that… are against the UX burden, is that the amount of unique versus duplicated bytecodes, as you see by the study of Wei Han from the Stateless team, is that 97% of the bytecodes deployed are basically duplications. So the impact, I assume it will be minimal, because most of the things that get deployed nowadays are just mere copies of things that already exist, and most of them are pretty standardized and famous, so it's not really hard to basically find an account that holds the code hash for the contract that you want to deploy. So, basically, I think this is more or less it. There's…

just… I just added this, thing so that you can basically see the difference between what you will pay and what you will not pay if we have deduplication in EIP837 for a 24 kilobyte contract. Of course, if we have 256 kilobyte contracts, this goes, like, to the moon. And yeah, next steps are just discuss this, figure out, if clients want changes, or they have questions, or whatever, and if we can include it and finalize this thing, we will implement it, at least for Geth, and yeah, that should be mostly it. So, yeah, that should be it from my side. If there's any questions or whatever, happy to answer.

Łukasz Rozmej: I have a question, is this forward compatible with code checking and putting the code into the tree?

CPerezz: That's a good point. I think it should be, because the bytecode at the end is chunked always on the same way. But I would defer to Guillaume, who will probably have a much more informed answer.

Guillaume Ballet: The short answer is yes, there will be some tweaks to do, but, yes, it is.

Łukasz Rozmej: Okay, but we need to… Account for those tweaks, beforehand with implementing this, or will be to those… do these tweaks when we will go… get to code tranking?

Guillaume Ballet: I think it's more of a code chunking thing, but, yeah, we, I mean, okay, I can make a write-up to go over the exact issues and see if we find them. But the… from what I see, the code chunks… Would be stored exactly like code today, so there's no reason for it to… to be any different.

Łukasz Rozmej: So, because in vertical, we wanted to put code chunks directly into the tree, right?

Guillaume Ballet: Yeah, but code chunking in… okay, code chunking has, okay, there are two versions of code chunking. There's code chunking in 2926, which is an MPT-based thing, and this is what I was referring to when I said there's no problem. When you go into any unified tree, like the unified binary tree, or vertical trees, for that matter, we will need to change the EIP to, to actually put the code independently and not per account like it is currently specified. This is a conversation we want to have on the next, Stateless Implementers call. But I think there's a lot of support for this, so in this respect, there would not be any problem either, but we need to get to the details. But once again, this is only a problem for a unified tree, and not code chunking itself.

Ben Adams: For discovery, I see me just use, estimate guess, rather than… You know, is this bytecode already deployed? Because that would be quite hard. You're not going to change your… subtly change your bike code to match one that already exists. But obviously, It would bring down the cost of, like, Contracts that deploy contracts with become, you know, like Uniswap, E2, deploying liquidity pools, they would become very cheap, because that's obviously the same. Exactly the same contract, so it's deployed again and again.

CPerezz: But that's theoretically fair, no? Meaning, the user is paying exactly for the resources that the node is consuming, so…

Ben Adams: Yeah, yeah. I'm… I'm… I'm not against it. And it would also, it would also encourage more… More reuse.

CPerezz: Are there any strong opinions from clients on how we should, handle, the attention of this reverse index, meaning, is it okay if we… like, the worst case is the user pays the same that he's paying nowadays, so there's not, like… there's no, like, drawback, I would say. But it's true that the way to obtain this discount at this point is mainly you need to iterate through your tree, or, like, you need to know what you're doing with the node, or, you need to go to a centralized slash third-party service. So, are there any thoughts on that?

Ben Adams: Wouldn't estimate gas. You know, the normal… what you'd do with the wallet, tell you.

CPerezz: So Estimate Gas should be easy to do, right? Because for Estimate Gas, you already should have the access list field, so you can just check if the code exists or not.

Ben Adams: Yeah, so… I mean, I assume that's the approach somebody would try and discover. They're essentially saying, if I deploy this contract, how much is it going to cost me? That's why you want to know if the bike code already exists, isn't it?

CPerezz: He is.

Ben Adams: That would… that would… that would already come from Estimate Gas.

CPerezz: The problem is, for Estimate Gas to work, the access list has to have the account whose code hash is, basically your bytecode, hash, right? So… Estimate Gas will only work correctly if you are already providing the account, which holds the code that you want to deploy. So that's the… that's the main problem, basically.

Ben Adams: One… one issue I can see with it… Potentially is, block access lists. You know, how does… where you have a contract deploy… the same contract deployed in the same block, is there… there might be some weird edges around pricing and parallel execution. Because you're… I'm not sure how that would work with block access.

CPerezz: I mean, transaction ordering is still a thing, right? Even if you have block access lists, meaning the way in which you Execute the transactions is not related to how they are ordered in the block, so… Theoretically, the order of the block is what rules the entire thing, discount-wise at least.

Ben Adams: Yeah, but what I mean is you're… you're now… Changing the pricing of a transaction based on an earlier transaction. If you see what I mean. So you need to know whether the earlier transaction deployed the contract. That you're trying to deploy in a later transaction, so you're…

CPerezz: Sure. Independency. Sure, that's true. I mean, the odds of that happening are scarce, I would say, because basically, this means that in a block, two people, or the same one through two different accounts, deployed the same exact bike code, which wasn't existing up to this point. So, I mean, this, of course, can happen, but it would be very weird, I would say. Nevertheless, I think since this is contract deployment, and it will be heavily, heavily priced, block access lists. won't have, like, much to do there, meaning if you have two 24 kilobyte deployment, within a block, there's not… there's not much more room left for… for computing, much stuff. I mean, depending on the gas prices, of course, but…

Ansgar Dietrichs: Okay, any further… Comments, discussion points on this specific EIP? And, Carlos, can you remind me? This one is not yet in the PFI list, right? So this will also still be added, or…

CPerezz: I made the PR during the call, so, I mean, I'm unsure if the bot, versed it. No, it's still… I mean, it's in the CI phase, so… Okay. It's bending again.

Ansgar Dietrichs: Perfect, sounds good.

Toni Wahrstätter: Yeah, no.

Ansgar Dietrichs: Yeah.

Toni Wahrstätter: One last question, just, I was just typing it, but I felt like it makes more sense to just, say it. The last comment of Carlos, that with the block access list, I think it wouldn't be a problem, because the code deployment is also mapped to a transaction ID. So, I think Carlos is right there, that it shouldn't be a problem.

Ansgar Dietrichs: Okay, awesome. Then… thank you, Carlos. The unfortunate news is that then, out of the EIPs section, we actually removed two, but added three. So, not going our way, but… At least, that's all for today, so no more… no more added now. Let's see how many more come throughout the week. But yeah, I think that's all for today, then. There was an open discussion section, but I think it's really best if we leave the Glamstadum discussion to… two weeks from now. And so with that, thank you everyone for coming, and, talk to you all in two weeks. And… in between.

Potuz: Bye.

Justin Florentine: Thank you.

Guillaume Ballet: But…

Carl Beekhuizen: Thanks, Al.

CPerezz: Right.

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