All Core Devs - Execution #226

Transcript

Jochem Brouwer: Hey, honey.

Ansgar Dietrichs: Oh, hello, everyone. Can y'all hear me right?

Jochem Brouwer: Yes, yes, how are you?

Ansgar Dietrichs: Good, good, good. Looking forward to yet another packed call.

Jochem Brouwer: Yes, yes, yes.

Ansgar Dietrichs: Is the microphone okay, by the way? I emptied a glass of juice over this, and this is the first time I'm using the microphone since having the laptop repaired.

Justin Florentine: great and full of vitamin C.

Ansgar Dietrichs: It's awesome.

Jochem Brouwer: Better than, than normal, so, yeah.

Ansgar Dietrichs: Okay, wow. They built in an aftermarket improved microphone, maybe.

Danno Ferrin: Did Mike Neff finally deliver?

Ansgar Dietrichs: Maybe, maybe I should be worried, maybe this implies that they, you know, used a non-standard microphone, you know, maybe, maybe this is a bedside. But anyway, yeah, let's maybe wait for a couple more seconds, and then we can go live. Okay, then, yeah, I think we're good to go live.

Josh Davis: Alright, you're live.

Ansgar Dietrichs: Perfect. Well, hello. Welcome, everyone, to All Core Devs Call 226. Which will be the last one for this year? Yeah, let's get right into it, it'll be another packed one. We have a few… Announcements first, so the first one is specifically concerning the… holiday, schedule? So, Banabas had a comment on the agenda with the proposed schedule that I also think makes most sense, so I just wanted to briefly get an act on this. So, we have ACDE today, on the 18th of December, then we will have a few calls in a row that will be canceled over the holidays, so… Next week, 22nd and 25th of December, both calls are canceled. And, then also, the week after, 29th of December and 1st of January, both calls would be canceled.

We would then have… restart the ACD schedule with the 5th of January, which normally would be an ACDT, because that's a Monday, and the proposal here is to change that into an ACDE. So basically, start the year January 5th, with an out-of-schedule ACDE, And that is just so that we, can finalize any outstanding Glamsterdam scope decisions that we might have by that point, and really just start the year with a fully finalized FOC scope. And then after that, we would continue as usual, so that week we would then, next to the ACDE, also have an ACDC on Thursday, and then the first ACDT of the year would be the Monday after. Does that schedule generally… Sound reasonable? If I don't have any objections, then we will just lock that in.

Perfect. And then also, just to mention, I talked with Tim, and while generally the idea was to basically have Tim take back over at the beginning of the year, we decided that it's, probably doesn't make sense to do that, right at the year cutoff, so I'll still, head the call on January 5th. Awesome. So then, that's the first agenda point, and then on the, announcement side, just a… Kev had a very quick, shoutout he wanted to give to a ZKVM roadmap document that he recently published. Kev, are you on the call?

kev: Yep. Yeah, I just wanted to quickly give some visibility, to our roadmap doc, which just entails some of the projects we want to be doing going into 2026. If you have any comments, then please just leave it in the the ETH R&D channel that we have, called L1ZKVM, and Antigar's posted a link in the comments.

Ansgar Dietrichs: Perfect. Thank you. Yep, and those were the announcements, so then we can go right to the, H-star section, so we have a quick H-star section before we get to gramsum scoping, just because there's a few decisions we wanted to get out of the way. Well, few decisions and one just quick summary. FOCIL… we've talked enough about FOCIL here over the last few weeks, so this time I want to just briefly inform you all, for those of you that were not on the call last week. There was a decision made to basically, CFI FOCIL for the upcoming H-star hard fork. So we will have FOCIL as a kind of a pre-CFI DAP, and then we'll start the,

we'll, we'll start the, the headliner process there soon. With that out of the way, then we… there's another HL-related decision that was made on ACDT, is my understanding, and this is a name change. Apparently, I think there was some issue with the… with HECA not being a proper star or something. I didn't actually pay super close attention, I'm not sure if there's anyone here that can maybe… briefly explain that, but anyway, there's a new name now for the… for the CL, for the… for the CL site, of the, of the, hard fork, and I unfortunately have no idea how this is pronounced. He's a, his, has, whatever, I don't know, does anyone have context and or know how to pronounce this name?

Hey, Zoo. Alex, I see in chat that you might actually disagree or something. I mean, this was presented to me as a decision that was made on ACDT, not something to decide today, but, if you have context on this, can you, I don't know. Do you want to briefly comment on this? No audio, okay. Okay, well, yeah, I don't know, this was not on my list of… to actually make a decision on, I just was going to repeat, but if there's… if there's an issue… Okay, well, that's… that's not bike shit. I think, yeah, then let's go with this renaming. So, we'll just, you know… and it's apparently pronounced Hezu. Jesus. Okay, that's, I guess, the… the name. Great. And then, we do have a decision, though, and that is on the actual full fork name, the motto of those… of that with Pogota.

There was an updated poll in the ETH Magicians using this new first part of the name. And the leading candidate there in the poll is Hegota. So, I just wanted to see if we have agreement to accept Heikota on today's call as an official decision. Anyone who has anything? Any veto reason? I agree with Justin that it's a, it's a fun, fun choice that, that it's unpronounceable, but yeah. Okay. Sure, then I think we log in both that individual nickname and the portmanteau of Hegota. Yeah, looking forward to that, Falk. Awesome. And then, One more… Actually, I see now that I forgot to put that on the agenda, that's my bad.

But, Nick so specifically wanted to get a sign-off on the proposed, timeline for the… for the HSTAR EAP selection process, both headline and non-headliner, and can post a… link to that in the chat. My bad for not having this on the agenda. Nick, so are you on the call and could briefly speak on… speak to this?

Nixo: Yeah, so that, that timeline is proposed. Opening the headliner proposals, and then choose… And it sort of, TBD on the rest of it, depending on how that goes. I would advocate for only 30 days for the non-headliner proposal, but in general, I'd like to get this solidified so that I can, make it a blog post and put it out to the world and sort of, blast that out.

Ansgar Dietrichs: And just to clarify, I see that in this, link that you shared in the agenda that, that is this post by Alex, that there are still a few TBDs, on the timeline, including what you said, right? Like, the, the exact, time span for proposing non-headliner ERPs and whatnot, so are you asking for clarification and fill-in for these TBDs, or would you just announce them with these TBDs still in there?

Nixo: No, I would just announce the dates that are written in there, and then say that they're a 30-day window to, headliner EIPs will follow that, depending on our actual decision-making ability. So, as soon as the headliners are chosen, then the non-headliner proposal window would open up.

Ansgar Dietrichs: Okay, sounds good. And just for people, you know, so just so we have the foundation, so basically the proposed is that January 8th to February 4th, we would have time for focus discussion and headliner proposals, February 5th to February 26th, we would actually have headliner discussion and finalization, and then, basically, yeah, as you said, proposal is to start the opening up the non-headliner section once the, This proposal, once a decision on the headliner is made. Do we generally have agreement on this? Does it sound reasonable for people? Can we announce this as the official timeline, or is there any wishes for corrections, or… Adjustments? Okay. Great. Well, these calls are great, I just keep making proposals, and everyone is just quiet, and we just make decisions. Very efficient. Okay, then we… we just, we log in that,

Timeline. And apologies again that this was not on the agenda. Okay, with all of that out of the way, we are ready for the main part of the call, the Glamsterdam, scoping continuation. So just for some context, we made 18 decisions on last call, we have 22 more decisions to go. I… my goal would be to basically get through the vast majority of these today, and make as many decisions as possible, and then whatever is left over, and there's, like, already one or two EIPs specifically that… where that's generally the recommended action, at least. we would then make those few remaining decisions on January 5th, and then hopefully have a fully locked-in Foxcope by January 5th.

To start off the section, though, there is a short update from the repricing side, and I think, Marius, you want to give a brief overview?

Marius van der Wijden: Yes, hello, everyone. Let me quickly share my screen. So, first of all, I'm synthesizing… synthesizai… I'm combining a lot of the, the work that, the repricing teams have been doing, so a big shout out to, Jocham, and Luis, and Carlos, and Maria, and Camille from the Nethermind team, and the rest of the Nethermind team who's been working on this. So, they've been putting in a lot of work in order to, To get us to the point here, and, Yeah, let me jump right in. Short recap, currently we are running at roughly, at max 20 megacity per second. What we are trying to achieve with this, Repricing effort is a harmonization between the compute opcodes itself, and then also a harmonization between the areas of compute, state access, data.

And we want to do a mitigation for state growth. Because if we don't mitigate state growth and we increase the gas limit. Then, yeah, the chain will grow much faster. faster than we would have liked. So what we are, currently… proposing is to target, 60 megacity per second. So all operations below 60 megabits per second would need to be repriced. up. That is around 18 operations in total. The list, here on the right shows these 18 operations, but this is, pending client improvements and further analysis. And one thing that we might want to propose In the future is, price reductions for… for very expensive operations. But this heavily depends on the timelines for,

for, for, for Glemson, and, Yeah, so… we don't want to propose that today, but what we want to propose today, is to CFI EIP7904, In order to, to move this along. For data, we have two EIPs that touch call data, 7976, which increases the call data floor gas, and 7981, which increases the cost for access lists. The numbers in the EIP might change, depending on the other repricings. But both of these EIPs are very necessary if you want… if we want to increase the gas limit, and they are ready to go. And, regarding state access, again, we are targeting 60 megabits per second. We have, EAP8038, which, increases the cost for state access. The numbers there are still missing, but, we,

We are very confident that, or… we are very clear that there needs to be increases in state access costs, and, in order to scale, and so, numbers there will follow, and we would like to also lock that in today. 2780 reduces the intrinsic transaction gas. This will need to be updated based on, 8038, and also some of the… maybe some of the repricings that we do. We're not trying to force a decision on 2780 today, but overall, it has become quite clear that repricing for state taxes is necessary. For state growth. There are 3 options, that we have, AT37, State creation gas cost increase, which, which is a fixed, increase of the costs for state creation. 8073, dynamic state pricing for steady growth. This is,

dynamic state cost creation based on current block limit. This is, proposed by the Netherland team. And 8075, adaptive state cost to cap growth and scale at 1. This, this, introduces, like, a similar mechanism to 1559 in order to, get us to a certain target of state growth per block. And what has become clear over the last couple of weeks, that some repricing has to be done with regard to state growth. And, if we move into the future also. Probably state needs to be… Measured on a different axis than compute. But we… we would like to postpone the decision on which of those, three EIPs to do, in… onto January 5th. And, if you want to learn more about state growth, you can check out Ender's overview of… of the different.

Different, proposals. So, concluding… We would like to target, 60 megabits per second with repricings, that would, that would significantly, like, allow for significant more headroom, for scaling. We would like to move 7904, the general repricings to CFI today, move 7976, increase call data flow gas to CFI, 7981, increase access list cost to CFI, and we would like to move AT38, the state access gas cost update. to CFI. We would like to discuss 2780, the reduced intrinsic transaction gas, either on the call today or, postpone it, and we would like to postpone the decision on state growth, to January 5th. Yeah, that is basically… what I wanted to share today.

I can leave the… I cannot see the… I cannot see… There's the chat, but, I will leave this up for a bit, so we can discuss it.

Ansgar Dietrichs: Sounds good. And now, already, just for context, because for the, actually, in a second, making the CFI and DFI decisions, I have updated the document that we used last week. I already put the link in chat, but, if there are questions for Marius first, then I think we should, yeah, keep the screen share here for a second. So, are there specific comments on the repricing? proposals here.

Ben Adams: And just a… Just a quick comment on 2780. Additionally, I think ETH transfer logs, that would add a A small amount additionally on top. Which is a different EIP.

Marius van der Wijden: Yes.

Ansgar Dietrichs: And also, from my side, maybe, just to clarify for… so people are aware, right, the idea would be that while the base cost of a transaction would go down. in combination with the… the state access, gas cost increase EIP, the cost of a… of a transaction that, would actually create a new account on the receiving side, would actually go up, right? So basically, we would then be in a world where we have two different base prices, and one of them is below the current $21,000, and the other one is above the current $21,000. Is that… is that correct?

Ben Adams: Yeah, so it aligns, the state growth, and… The cost of that account creation will be You know, it… depending on what we do with, state growth. will be that price. But at the moment, there's a loophole where if you create an account. That's part of a… broad transaction, that's cheaper than if you do it as part of a call, which is an inconsistency, so it aligns to the more expensive price. And takes it off a regular transaction.

Ansgar Dietrichs: Makes sense. Lucas?

Łukasz Rozmej: So, one theoretical kind of question, or, like, philosophical. So, I kind of agree that we probably need to reprise state growth, especially. But if state growth is one of the main chain… of chain main usage, if we reprice it similarly as we increase gas limits, the question is, are we really scaling, right? So… If we need to scale, we need to allow for more state growth than we have at the moment.

Marius van der Wijden: That's not 100% true, because if we… we would change the ratio between compute and say growth. And that would allow for… for…

Łukasz Rozmej: Marco.

Marius van der Wijden: More… more compute, yes.

Łukasz Rozmej: Yes, true, but how much… percent of gases currently compute?

Marius van der Wijden: Dink.

Maria Silva: That's why…

Marius van der Wijden: Do you?

Maria Silva: moment is, like, around 30% is…

Łukasz Rozmej: You're breaking out, I didn't get that, sorry.

Marius van der Wijden: It's… I think it's 30% of the block is state growth. Or state-related operations. If I remember correctly.

Ben Adams: Also, with the repricings, if we… if we do them… We're reducing the price of compute, so we are effectively increasing, in a relative term, the price of state. And, you know, it's also dependent on the… gas. Price. Which is my concern with the… The basic estate growth one. Where if we… if we just… Versus the two targeted, you know, this is… targeting a certain amount of state growth and adjust the price. If we just increase the price of state, then potentially The gas price drops, and therefore, we end up with just charging less and doing the same growth.

Ansgar Dietrichs: Right. In the interest of kind of getting through much of what we want to get to today, I would propose that we specifically do not discuss the state growth side of this until January 5th, unless people, of course, think that we can't make decisions on these other ones before we actually have discussed state growth more, then of course, we can revisit that, but… Yeah. One more clarification, maybe, Marius, because I think many people here are still under the impression that most of these EAPs are basically proposed as is, because there was this strong urge to make CFI decisions today, we actually are in this position where I think a lot of these… some of these EPs will be… are proposed to basically be included as is, so the data ones, for example, and the state access one are basically proposed to be included as is. The general repricing one, that one I think we need to clarify for people here. The proposal, at least from

From the repricing team side would be to radically reduce its scope. only to increasing the cost of compute-related operations that are not currently performing at this 60 megabits per second floor, and remove all other changes to pricing on the compute side, and so that includes removing all of the cost reductions. Again, this is just the proposed approach, because there were concerns about testing scope for a larger set of changes. this could be revisited, but I just wanted to say that, just so we are on the shared understanding of what the proposal here is, at least from the That's what the proposal is, radical reduction in scope.

Marius van der Wijden: Yes, like, we are at a point where it doesn't make sense to. to think about what could be done, maybe, in a certain future. I think it is more important what can be done now, and what will bring the biggest benefit. And the biggest benefit right now is to, is to reprice the… these worst cases that we have in the EVM, and, and then, be able to, to increase At least theoretically, the throughput from 20 MHz per second to 60 megabits per second. And that is before block access lists and before PBS.

Ansgar Dietrichs: And then maybe one more, there's a question in chat from Luis, from Besu, block of access lists will make compute much cheaper than state access, so basically why are we… Basically treating them the same here. Marius, do you want to comment on that?

Marius van der Wijden: Well… It's not clear to me why, state access should… wouldn't be cheaper, wouldn't be more exp… oh, would, like, wouldn't also get cheaper with, block access lists? Because we can… Load the state, before, and so all of the state would actually be kind of cached at the moment of, of accessing the state. And also, The numbers for the state access costs will definitely be revisited once we have a, version of block access list life that we can. That we can really… that resembles the final thing, and that we can use to, to measure. All of this.

Ansgar Dietrichs: Right. And basically. For context, this proposed 60 megah per second floor is in a way more heuristic, of saying, yes, we could continue to wait until we have perfect numbers post local boxes and EPBS, but by then, at that point, we'll be very late into the fork process, so instead we just do the Next best thing, the cheap thing to do here, that is just to pick a… pragmatic flaw, and then, yes, probably after the benefits we get from local access and EPBS, that probably means that compute and state are not quite performing at the exact same level, because they'll receive somewhat different speedups from these changes, but given that it's hard to predict how they will fall out today.

by just targeting the same floor, we'll get similar-ish benefits, at least. I think that that is the… The intention here behind such a simple shared floor. Okay, do we have more questions to this? Because otherwise I would just start to, like, have us move over to the other document, the main document with all the EIPs, and then we can talk about whether to follow these recommendations or not. Maybe one more before we go there. How do people feel about this downscoping of the general repricings one? Obviously, again, it's called general pricings today. It had this large ambition of repricing everything and making a lot of compute cheaper. It would now only make… basically the things below the flow more expensive instead? Are people generally okay with that recommendation? Would they want a more ambitious scope?

what is the feeling on that ERP in particular, Ben?

Ben Adams: I'd like to leave the door open to, also decreasing costs, but… not as… You know, a hard… a hard band. See how we go. At least, I mean, it's obviously better to… To remove the worst cases is the first step.

Ansgar Dietrichs: And Dragon.

Dragan Rakita: We will be fine with increased scope and repricing every output. At least CPU, related one, related data IP.

Marius van der Wijden: Right, and… The problem, like, the problem with increasing scope is that The work is not on the client teams, to do this, like, the work on the client teams is very easy, they just need to… change one variable. The bulk of the work is on the testing teams and the benchmarking teams. To, do all of these benchmarks. And, we have a lot of people working on it, but I don't… realistically see us. If the… if the rest team would step up and say, we put, like, 2 or 3 engineers on, into this effort, and, in order to get the full repricings, and have, like, the extensive effort, then I think then I think we would… we would be in a much better state. But, as I've seen in the discussions around repricings and state float.

Many teams are not… are not as focused on it, or do not put as much resources into it as I would have liked. So, yeah.

Ansgar Dietrichs: Dragon?

Dragan Rakita: And we have, like, that big, gas, I'm not sure of how it's called. Basically, 4th to 5th version, that basically specifies how, or recommends how the gas should be moved. And I wasn't DCIP, basically, based on that data. Shouldn't we just reuse those data? Basically, somebody already did that kind of work.

Marius van der Wijden: Yes, but, that data is… Not… Very good. I would… To put it lightly.

Dragan Rakita: Okay, then the confidence on the data is… not… Not great. Okay.

Ansgar Dietrichs: Yeah, and maybe one last comment there from my side. I personally think that repricings will be a big part of Ethereum going forwards in general, and I think the plan is to add this into a more standardized pipeline, and… say, by H-star, have… enough confidence in the data situation that we can also do more larger-scale repricings. If we are fast with this, then maybe some of these repricings might end up making their way back into this ERP, if there's room and there's time, but basically start with the minimum scope for now that we need, which would just be the The floor, and we can always add things back if… into the fork process, we realize we have room and time.

It's easy to do, but basically better to start small. Then to start too ambitious. Okay. Then, I think, kind of, we can move to the main, kind of, decision-making section here. I think, Josh, you wanted to… share your screen. The document is… Here, I put the link in chat. It's the same document as last time, just, I updated the annotations, And marked the… all the decisions, you'll see further down in the document, I marked out all the decisions that we… that we did last week. As of 30 minutes ago, they're also reflected in the meta-EIP, by the way. Okay, so then let's first talk about the repricing section. So, just to repeat, $27.80 is a bit…

a separate decision, because that one we can or cannot do, depending on how people feel like it. It had pretty strong support from all the clients. So I would… that… it is a CFI candidate for that reason. And then the other four, basically, Specifically the recommendations from the repricing side. If we would prefer to not do one of them, then we should revisit all four decisions, because those four are really… only, impactful if they're done together. But maybe let's first take the decision on 2780. How do people feel about this? This had pretty strong support across all clients. Anyone that opposes a CFI decision?

Ben Adams: I obviously support it, but I'd just like to highlight, as I say, It does also depend on… Some other repricings. For the exact numbers.

Ansgar Dietrichs: Yeah, I would say, in general, this is maybe something that's a bit unique to this section, the entire, kind of, repricing section here. All of these EIPs would be included as an intention to basically do these changes. Well, the general repricing ones, the EIP also needs to be updated to reflect specifically this floor. Production and scope, but all the other ones roughly have the right scope, but the values in all of them would be subject to change, and probably would continue to be subject to change for… For a while longer into the fog.

Dragan Rakita: In general, 2718 makes sense to add. I would just slightly modify it, or basically have discussion around it. to exclude… the problem with when the transaction creates new… new target, new account, I would make this dynamic check. Basically, make interesting gas only include the bytes that's going to be sent, and the count access of the caller that's going to be done. And when the transaction starts executing. We deduce… deduct additional gas if… depending if the value is more than zero, and if the target account is not existing. And of course, fail if there is not enough gas to do this suction.

Ben Adams: I mean, that's… that's essentially what it… what it, what it proposes. Blitz sit. It breaks down… The intrinsic gasped into parts, and then says, okay, so the intrinsic gas is very low, and now, depending what you're doing on top, you start adding parts. Rather than.

Dragan Rakita: Yep. Yeah, but it does it as the part of interest to gas. What I'm saying is, let's split that. To not have additional check in intersection pool, and just do that check at… as part of execution. In this sense, The gas that is part of interest, the gas, it doesn't… it can be split from the gas that's needed for creating new state.

Ben Adams: Okay, but that would just be the gas limit on the transaction, and then you'd… You'd fail by saying that.

Dragan Rakita: Doesn't even… okay, I think there were some more details, yeah.

Ansgar Dietrichs: Yeah, my question is, Dargan, would you feel comfortable, say, CFI-ing the CIP today, and then figuring out these details afterwards, asynchronous, or would you prefer To basically have all of these details worked out before you would want to make a final decision.

Dragan Rakita: CFI today. Anything that we chose, it's good enough and can be included. It's not a blocker.

Ansgar Dietrichs: Okay. Then, anyone else with something they see as a blocker here? then… I would say that this is a CFI decision. So, one CFI decision to go, down, I mean. And then, let's take the other ones one by one, but maybe start with the one that was the most… uncertain, which was the, the last one in this list, actually. 80… 38 state access gas cost increase, because if there's one that possibly has an issue. Then it's this one, I think, so let's maybe discuss this one first. Do we feel comfortable making a CFI decision on this one, with the understanding that basically we'll specifically establish this 60 megap per second floor. Is that basically anyone Feels uncomfortable with that.

is there, in general, like, is there support for CFI? Is just… do people not have an opinion? Like, what's the… What is the… the client situation here? We can also, of course, delay decisions. It felt like… Yeah, Ben, could you briefly comment on why you would prefer the delayed decision?

Ben Adams: Yeah, so there's… there's, like, 3 in this area, and… I think it needs a bit. Bit more consideration. I don't think it's straightforward.

Ansgar Dietrichs: Are you talking about the state growth one, or the state access one? Because, sorry, this is very confusing.

Ben Adams: This one specifically.

Ansgar Dietrichs: It's the state access one, so this would only make, S-stores and S-loads to existing locations, like, affect that pricing.

Ben Adams: I apologize. I misread.

Ansgar Dietrichs: No, I think, I mean, yeah, I should really make this clearer. So, so this one is specifically not about state growth. So this state growth one is the one that is… in the separate section below. That one, the recommendation will be to talk about it on January 5th for a decision. So this, this one that we're talking about right now, 8038, is just about… Interactions with existing state. I just… You took this one first, because out of all of the previous discussions of these, repricing changes, this was always the one that was… had the least clear support, so I wanted to check on this one first, given that they really need to be included as a bundle, basically.

Ben Adams: I mean, one of the issues is it's all TBD, so it doesn't say whether we're increasing or decreasing, and it will be very affected by bowels.

Ansgar Dietrichs: So, the idea would be to have this in… enforce a flow of 60 MHz per second, even without taking the impact of EPBS or balls into account, so that then, with the impact of EPBS and BALTS, we can run it at an even higher Gas per second, so this would… result in an… With a… in the price increase for most operations there.

Ben Adams: And it does have the issue that we may break a lot of… People who do gas introspection limits. So decreasing is easier, because it doesn't break anything.

Ansgar Dietrichs: But the problem is if… yeah, again, the reason why that was proposed is just that if everything else is priced so that it basically can run it. 60 megabits per second or something, and then state can only run at 20 or 30. then we are running the entire AVM at, like, half speed because of it. So that's why. And of course, the point would be, if we CFI it, that means that now it will be subject to thorough testing. Testing does include backwards compatibility checks, so that does not yet mean it's definitely in the fork, it just means we basically prioritize Figuring out all of these issues.

Ben Adams: Yep, I'm okay with that.

Ansgar Dietrichs: Okay, then, I mean, from the get side, obviously we have heard from Marius. Is there anyone else from the Get side on that has… A take on whether Geth would… be in favor of the CAP? Otherwise, I would just… Take Marie's. take on this for Geth, and then do we have, from, Wrath, Besu, or Erigon, do we have… opinions?

Ameziane Hamlat: on… on… on the basis side, I think we are fine with this EIP. I agree, like, to be… TBD is a bit confusing, but I guess, I know that there are some, some benchmarks that are, happening right now, so, yeah, if, if the repricing is based on, real data and the benchmarking, I think it makes sense to, to, to change, State access, pricing.

Ansgar Dietrichs: Sounds good. And yeah, I think basically this is the main decision we have to make for these four ERPs. Do we make the inclusion decision today? Knowing that we still… there's still quite a bit of benchmarking work to go, or do we basically just keep them in this PFI state for as long as we take for the benchmarking, which basically delays the decision for quite a while longer? I personally would be open to both, but I think overall there was strong desire to basically make decisions sooner rather than later. Guillaume?

Guillaume Ballet: Yeah, in this, respect, and to be, like, full disclosure, people from my team have actually worked on the… I think this is the IP someone from my team worked on, but I think we should include it, because if we don't, you know, consider it for, like, if we don't CFI it, everything will be pushed, pushed down the road, like, okay, this one hasn't been benchmarked. Let's not look at it until it's been benchmarked, and so on. So if we… if we don't CFI it today, I don't think the benchmark will happen as quickly as we need them, so I would be in favor of, of CFI-ing it just for this reason, and then if we turn out… if it turns out the benchmarks are not good enough, or whatever.

we, you know, considered doesn't mean included for sure, so I'd say it doesn't cost much to… Yeah, just, just go for it, and get those benchmarks.

Ansgar Dietrichs: Okay. Yeah, I think that actually seems to express sentiment here quite well for people. Then I would propose we actually make a CFI decision now, last chance for anyone to object. Okay, then we CFI8038. For the other three in this list, then let's go just, one by one from the top. So, the next one would be 7904, general repricing. Again, just to reiterate the current shape of the ERP, as you can see it if you click on it. It will be still the more ambitious scope that would be touching a lot of compute. The idea here would be that we are CFI-ing it with the decision of only downscoping it to the cost increases to establish this floor, and later on into the FOG process, see if we possibly have room to add back some of these cheaper prices.

Is there a position to CFI there? Yes?

Ameziane Hamlat: Yeah. Quick question. I understand that, like, the numbers are going to change depending on the benchmark's results as well, but my question is related to one of the slides that you shared, Marius. So, for this target of 60 MGS per second, there are some opcodes that, would need to, to… to have, like, a different replacing, basically, make them even… even more expensive, like, meal mode, from what I understand. Is that correct? Like, I mean, like, the repricing is not in one sense, we can have, like… both kind of replacing make. Sum-up codes cheaper, and other ones, more expensive.

Marius van der Wijden: Yeah, so…

Ameziane Hamlat: Is that correct? Yeah.

Marius van der Wijden: Yeah, so right now, we are only… only really proposing to make things more expensive. And in order to get to the target of 60 MHz per second, we would need this is… my… This is pending benchmarks, but the way benchmarks are looking right now, we would need to reprice 13 operations… And let me look at the slides, if that was correct.

Ameziane Hamlat: 18 or…

Marius van der Wijden: 18… so, sorry, 18 operations, yes. And, Some of them would only need to be repriced by… By 10%, but, some of them would need to be repriced by, like, 3X, roughly. So for example, The point evaluation precompile. roughly runs at, so, the analysis that we did right now, P99 of, of, like, 7 days of benchmarks, so, like, I don't know, like. 50 benchmarks, or, or so, of all clients, and, in P99, we arrive at, For the point evaluation, we arrive at, 31. Oh, sorry. Yeah, we arrive at, at 31… Mega gas per second, so…

We would need to reprice, by… 2.5. X.

Ameziane Hamlat: I see. So, so just to be sure, AIP7904, like, as it is today, it is more about, like, having more throughput on, on, on arithmetic operations, so basically. make them cheaper? Are we talking about, like, the opposite? Like, make, yes.

Marius van der Wijden: Exactly. So, yeah, we, we, we will be, considerably rewriting the… the list in… 7904. Ben?

Ben Adams: Yeah, so I assume the goal coming out of the minimal. Changes would be to… Be able to increase the gas limit, versus, Do more at the same decimate. Which would be the lowering price.

Marius van der Wijden: Yes.

Ansgar Dietrichs: Yeah, so this is kind of, in a way. a bit of a process compromise, because I think it could also have been a new EIP instead, to basically say, okay, this 790704, by its spirit, was more about making things cheaper. Instead, we want to have… make things more expensive. But of course, given that the proposal window is already closed, it seemed more appropriate to just reuse the existing kind of compute repricing EAP, even though the nature of the EAP indeed does change now, as people have picked up on. It seemed like there was then, with these clarifications about the intention here, that there was broad CFI support. Any remaining questions? Okay, then, where we can see if I had this one.

The other two are much smaller in scope each, they're just adjustments to the data side of things. It is definitely possible there that the numbers might also still be adjusted, of course, pending kind of looking more into this, although I think Tony already had quite a bit of confidence into these rough numbers, at least, but basically, with that caveat said, Any, any, opposition to CFI-ing, 7976. then I would say, CFI. And, any opposition to CFI-ing 7981? That is specific to the, access list. That bitch.

Ben Adams: I'd just like to express a strong spot on that, because Accessless, since we're also doing bowels, They become sort of irrelevant, other than the… Very original purpose that they were introduced for, which was fixing broken contracts. Otherwise, they're like a hindrant.

Ansgar Dietrichs: Yep. I agree. Okay, then, but yeah, let's for now just see if I did this, and we can, in later folks think about a more proper. deprecation. But yeah. Okay, then we, CFI all EIPs in this section. Nice. Just to move to the next one, again, the recommendation would be to not make a decision today on the… on basically the exact, way in which we want to… to… to tackle state creation, state… state growth, Pricing, do people agree with that? To delay that decision until January 5th? Okay, then we can move to the next section.

Łukasz Rozmej: I have a question. So, is there a plan what will happen between today and January 5th, though?

Ansgar Dietrichs: Yeah, so the people, at least some of the people at the EF that are working on this topic will be working in the meantime. And so, the idea would be that, by A January 5th, we just have more time to dive into this topic, because we won't be so cramped with other decisions, and then B, by then we should also have Some more data, too. Support that decision.

Marius van der Wijden: Yeah, I can… I can shine a light on what's happening with the state benchmarks. We, bloating again, to a 4x minutes state, and in the meantime, we are also, updating our infrastructure to run These, the state-related benchmarks on basically different state, whatever, like, snapshot we have of whatever network we want to run, and we want to run them on on a snapshot of mainnet, on a snapshot of 2x mainnet, and on a snapshot of 4x mainnet at least, to see, to see how these numbers compare, what, what we, will be running into in, in the future, and, in order to get more accurate numbers. Like, I can, for, so for the op codes.

They have been running… Also, for the compute, operations, we have, pretty good benchmarks now, and they have been running, Every couple of hours, but for the state benchmark, the, the, The infrastructure is just significantly more complex, and, So, we have had some benchmarks, but the numbers are not super reliable, because they are… they cannot be run, like, I don't know, 5 times a day, and so, yeah, we just need a bit more time.

Ansgar Dietrichs: Okay, then, I would move on… if… There's no more comments on this topic. Okay, then we have the, non-core repricing ones, so these are still repricing decisions, but, given that they are not specifically part of this core section, they can really just be treated as individual one-off decisions with no specific, kind of considerations here. So there are… there were two competing proposals for repricings on memory. Initially, there was actually quite a bit of interest in the, first one in that list. I think last call, we even initially talked about it as a potential Mmm… As a potential CFI candidate or something, but, in the end. I think there were some… I'm not blanking, actually, like, one of the two had account abstraction concerns, I think that was 7, 9, 7… wait…

Am I… Yeah, I think one of them had account obstruction concerns, and in general, it seemed unclear whether there was enough support for either of them, so I just… given that we need to actually make decisions here, anything that doesn't have a strong yes is basically going to be a default no, so, like, that's… this is why I put both of them as DFI candidates, so do we by now have strong support for either of those two approaches? Otherwise, I think a reform of the memory logic of the EVM would probably be delayed until H star. Oh, yes, we no longer have to say H star. Mmm… That's right. I already forgot what we call it. Hagota. Not Hogota, Hegota. Yeah, exactly. Anyway, so do we have… I, I basically, I, yeah, let's, let's go through them. 7686.

Suggestion is DFI? Does anyone want to argue against DFI? And maybe before we make that decision, then also for the other one, because they're really kind of related, 7923… Are there, if… would anyone oppose a DFI on this one? Okay. Then, I would suggest to just… yeah, then I would say we just DFI both of them. Again, not because of any specific reason, just because, yeah, we need to make decisions, and default is just DFI on each one, where we don't make CFI decisions.

Okay, then, We move on. The general repricing sections here, we have, a few more to talk about. T-store repricing 7971, I think, actually, this is the one that I had in mind initially, but that was… used to be a CFI candidate, but then actually had some account obstruction concerns. if those, of course, have been addressed, and if by now, people… would want to reconsider this, we could do this. Otherwise, again, just for the… if something is not in its out rule, I would… I marked it as a DFI candidate. Does anyone have strong opinions on this one specifically? Ben?

Ben Adams: I mean… It's a shame, not to… not to do it, but… Yeah, they… the account abstraction concerns are real. Good. Could I suggest we delay it instead, and see if we can resolve this?

Ansgar Dietrichs: And so, delay would mean until January 5th, do you think?

Ben Adams: yield.

Ansgar Dietrichs: that until January 5th, we could, have people look into this more?

Ben Adams: Yes, so if the issues aren't resolved by then, then we get fired.

Ansgar Dietrichs: And just to answer the question, Dragon, from chat, I think, in general, my understanding at least, is that any EIP that introduces specific hard caps on any individual type of usage into the, into, like, the actual inner execution of a transaction, so not, like, outer, like, say, call data size or something, but the inner part of an execution. It's just problematic, because any Transaction that bundles the operations of multiple users. that are shared, basically. Then one user can use up everything up to that cap. And then another user's operation would fail because of it. I think that's roughly the type of concern that always comes up on these types of changes, and this is why gas in general is so elegant, because you can check, right? Once one user's operation returns, did they consume… how much gas did they consume? Is there still enough gas left? All these things, so that's a failsafe, but if there's some sort of

Secret second counter. that could also run up, and at some point block the transaction execution further. That really basically breaks all of these use cases that bundles multiple user operations for multiple users. So I think that that is a general type of concern.

Dragan Rakita: Yeah, I think the AIP is unfortunately named because it doesn't just include hard limits. To be honest, hard limits I would remove for that IP, but it reduces some, gas for, Cars for accessing all the created transition, transient storage, so that part is quite nice. So yeah, maybe just removing hard limits and leave it for the gas to be a basic limiting factor for transient storage would maybe be a solution for this.

Ben Adams: Yeah, I think… I think the issue, why it has the hard limit is because if it just decreases the gas price of transit storage. The amount of memory you can allocate becomes huge.

Dragan Rakita: Yeah, but it has different pricing if you increase the trading storage, or when you just access trading storage to just, Chain.

Ben Adams: Huh.

Dragan Rakita: existing 3D storage.

Ben Adams: Different times. Maybe just drop the, drop the price for access, but… Keep the storage high.

Dragan Rakita: Yeah, exactly. I think the gas values maybe need to be… they will depend on general repricing that we do. But in general, yeah, seems like a nice AIP. We… from red side, we mark it as neutral, so it depends, do we have, like. Do you want to close it or not? It's different mechanism, so it's not just repricing group, sorry.

Ansgar Dietrichs: No, no, yeah, that's fine. But then I would maybe suggest, indeed, that we follow with Ben's proposal and just delay, one more time until January 5th, because it seems like people would still like to include this in general if we can find a way to make it safe. But also, that, of course, means the understanding should be that the default here will be DFI. So on January 5th, unless we have a way to resolve all open questions, it will be DFI, but people want to give it one more round of chance, basically. One more chance. Okay, so then delayed decision on 7971, and then we move on to, 7973, warm account right metering, This one is, a DFI candidate, just because it basically was kind of one of those middling EIPs, not much support, not much opposition,

Which makes it a default DFI, anyone that wants to oppose DFI here.

Dragan Rakita: Just to add comment, this kind of logic we already have for S-Store, basically for storage. And basically, it is some kind of optimization when we want to… Increased balance for account that's already scheduled to be… not scheduled, but… Increasing the balance two times, second balance is going to be cheaper. So, from our side, it's marked as neutral, because it depends if there is room to include it or not. I don't have any concerns on AIP in general, but more on the… if you have scope for it.

Ansgar Dietrichs: That doesn't sound like a passionate CFI argument, so then I would stick with DFI here. Okay, then, DFI on this one. Then we have one more in the section, EIP8032. This is the size-based storage gas pricing. This one does not have a recommendation, either CFI or DFI, because, it was quite controversial on the last call with some people concerned about the overhead. On the other hand, it had some… quite a bit of initial support, and so I know Guillaume is on the call to talk about it some more, and then we can see whether we want to make a decision on this today.

Guillaume Ballet: Yeah, So, okay, I didn't, like, you told me we're not going to talk about it today, so I don't have any presentation. I did publish the Twitter thread explaining the transition part of it yesterday, so glad I did this. Please have a look if you're wondering how the transition would work. Yeah, I did, I did watch the rerun, I was on holiday last time. I would like to address the two comments I heard that were, in my view, completely wrong. One of them is that… It's redundant with AT38, I think, or 8037, I forgot which one. That is completely not true, because AT38 or 8037, I guess it's 8037, has to do with the state growth in general.

Whereas, this one has to target, is only intended to target the one contract that is, causing a huge scalability issue, especially in REST. So that's not… that's not the same thing at all. Regarding the transition, like I said, I did a thread, the Twitter thread yesterday, so please have a look at it. But it's very simple. if, if you can do, something as… like, if you can handle an iterator, which everybody in this, in this chat should be able to, I think, it's… it's exactly what it is. It's just about iterating the stat, the state, and adding a new, a new counter to the… to the account. So, there's… I mean, there's always risk, of course, but if you compare it to something like the vertical transition, which, which is itself… which in itself was tested and validated and well-specified, we… it's… it's really… it's really much, much simpler.

I am, of course, happy to answer any questions about this. But I think, we should CFI this one, and the reason we should CFI this one is because this is having a negative impact on the network, and, sorry, the Xen construct in particular is having a negative impact on the scalability of the network, and if you want to disincentivize. Disincentivize, you know, touching this contract, which is, which is dragging everybody down. you don't have a better option, than this, because once again, AT37, solves a lot of problems, but doesn't address this one in particular. Yep, I think that's all I have to say. If there are questions, happy to answer them.

Ansgar Dietrichs: Ben?

Ben Adams: Not to, rousing speech, but I would suggest delaying this one so we can consider. The new input.

Guillaume Ballet: What new input are you looking for?

Ben Adams: Oh, you… you… that you've just prepared. Because I doubt anybody's read it. Fully.

Guillaume Ballet: Oh, you mean this right? Okay, sure, yeah.

Ansgar Dietrichs: Matt and chat, no delay would not mean CFI. Delay would mean making the CFI decision on January 5th.

Ben Adams: Yeah.

Lightclient (Matt Garnett): Doesn't CF… does not… does CFI not mean that we are considering… Including it. And we're looking for more information. It's not good.

Ben Adams: We're cons… we're considering, considering including.

Lightclient (Matt Garnett): I don't know, I feel like if we're trying to go through all of these EAPs… CFI… Matches what we're looking for here.

Łukasz Rozmej: I have a question, so the potential downside here would be that if we have, like, archive sync that is replaying everything from the beginning, it has to go explicitly through this migration every time, right? Yep. Previous and the next.

Guillaume Ballet: Absolutely. So, this is… I mean, this is in consensus, right? The iterator pointers are stored in a system contract. So you… you have… it's… yeah, it's part of the consensus, you do have to replay them, and but this is just… unlike the vertical transition, this is just iterating the… what we call the snapshot, or the flat DB, so, this is something that, over a full sync. Would take about 30 minutes extra, 30 extra minutes, which, if your full sync is, just as hours, is, just a drop, over the course of a full re-execution.

Łukasz Rozmej: Okay, I still… I'm afraid this might be too complex, for the scope. I think everything touching the tree is really, really complex, and very error-prone. Maybe not complex from the design perspective, or from the implementation and testing, too. It is doable, I agree that this is doable, I'm just unsure about if it's not… Too complex to… to… to do it, right? It would be different if we were to have this at the beginning, but during that migration, I'm not convinced yet.

Guillaume Ballet: I mean, yeah, there's only one, you know, if you… if it feels complex to you, I can only… you know, I can't really tell you anything, for just feelings, like, I'm happy to take some time, you know, aside and discuss it, and… and, you know, try to change your mind, but, if you're just telling me it feels complex, I… I can't, you know, I can't… say anything that's gonna change your mind. Yes, touching the state is complex, in a way, but this is something that has been tested, that has been done by Guess and Baesu. NetherMind was more or less on the… close enough to doing it. I think Somnat did something like that for Erigon. Actually, not sure, I should check with him. But, it's not like it's completely…

misunderstood by everybody. Every client… okay, most clients have done something similar for the vertical testnet, so it's not like, yeah, it's not like it's, it hasn't been done before, and and… Yeah, okay. All I can offer is, let's talk, let's talk, and let me, let me show you, how it would be done.

Ansgar Dietrichs: So then… just to… in the interest of, like, moving on for today, I'd rather keep these, like, last few remaining discussion points for January 5th, so we can have that call just for a few. more in-depth discussions, I would propose to then delay their decision on this one, given that there doesn't seem to be a clear… Clear agreement on either side yet? Okay, then let's move on. We have a few more topics to go through, and we still have 18 more minutes. We have, the contract section, first specifically allowing for larger contracts. So, the situation there is that we have two competing EAPs that both basically aim to allow for larger contracts. One is 2926 chunk-based code localization, and the other one is

7907. Basically, it would not make sense to include both. We could basically choose to include one of the two, or not do any of them, and basically, revisit this for the next fork. The reason I specifically marked, one of them as DFI candidate is not necessarily a personal preference, it's just specifically due to the fact that, In terms of, prior discussion, there was pretty strong opposition, by… by several clients, to 2926, but it was actually quite controversial, so we could… yeah. I just wanted to open this discussion back up. 2926 or 7907? Guillaume?

Guillaume Ballet: Yeah, I'm actually quite surprised that you say there was strong opposition, because I did present it twice, and I don't remember any opposition whatsoever. Could be, you know, could be that I don't remember, but, yeah, I'd like to know who has, who has, who is strongly in opposition to this. I would say, of, between AT32 and 2926, if I had to pick one, I would pick AT32. The reason why we want 2926 is because it does address the prover killers, and it solves the code size limit in one swoop. It's pretty simple. It's aligned with the state growth EIPs that we want to do. It provides a consistent access cost to code, just like it does… when I say access, I mean both read and write, something that is not as

awkward as the one proposed in 7907. In my understanding, the people that were working on 7907 gave up on, on this, on this CAP, I could be wrong, but that's, that was my understanding. Okay, you didn't, alright? Matt did, if he hasn't changed his mind, and I think, could be wrong, don't want to put words in his mouth. I think Dragon did too. Okay, what I wanted to add is, yeah, like, the 2926 is… future-proof? it's solving a lot of problems in one go. It's pretty simple. Wukash will probably disagree with that, but that's my take on it. And I think 7907 is instant tech debt, so even if you DFI chunk-based mercilization, I would say also DFI7907, because, it's, in my view, it's a big, it's a big mistake to do… I mean, okay, it's not a big mistake, but it's going to be instant take that.

Charles Cooper: I don't even think they're fundamentally incompatible.

Ansgar Dietrichs: Ben?

Ben Adams: Yeah, so 7907, we dropped that from Fusaka, but that was because… I mean, it was very late in the fork, and there were complications with it, which I don't… So the solution for that is adding the length to the account, which was, like, too big a change for Usaca, whereas I think for Gramsterdam, it's… it's fine.

Ansgar Dietrichs: Right. Greg?

Greg K | Lido: Yeah, so, from my side, yeah, just going to share that, like I also shared in the PR that, like, in light internally would segment with those two IPs, it seems to us that 7, 907 is simpler, and TIR supposed to text on the PR, My main point is, like, it's important to increase the code size limit, so the option to neither of them is too bad. Like, there is really need for this, like, also from the kind of lighter contacts, but I think in general for apps. And, you know, developers, it's required to have this increase, so one of them at least, should be CFI'd, in my opinion. Yeah, and the reason that, we think that 7907 is

appropriate, is that it simpler that it's much more clean, in the sense that it says… it sets a specific cap of 48 kilobytes, and, it's kind of more pragmatic short-term solution. So, if… this is wrong that, so let's say client teams believe that it's more complex than, the other solution, then that's fine. Because, 2926 seems more kind of future-proof, like, it's… it does a bigger change that is, more important for the stateless client's future and stuff like that. So, it's not that we are against DCAP, for some reason, it just seemed to us that 7907 does the job of, you know, doubling the maximum contract size without having so big complexity, and yeah, as Ben said, like, it was, I mean, ideally, it should have been already in Fusaka, it's kind of delayed, but now, like, it seemed to us that

it's, it's not so hard to be part of Amsterdam.

Ansgar Dietrichs: Thank you.

Guillaume Ballet: Yeah, just wanted to say, yes, it's definitely simple, 7907 is definitely simpler in the short term. It's going to be a lot more complicated in the long term, because, you do have a very, a very, You know, like, you have an asymmetric, management of the code, so that means that compilers will try to put, to optimize the code in such a way to… to put as much code as they can in the best, in the free part of the code, and then you're going to have a lot of special gas golfing. approaches. I think in the past, we… we always, found out that the more, you know, people try to work around the limits when it comes to gas, to gas accounting. So, so I don't think… I think we're opening, we're opening a Panera's box, and that's the… that's the point of 2926. We are, just making a consistent, like, the… the cost is the same from chunk zero to chunk, 1 billion. You do…

you do remove the code size limit right off the bat, so it's not, like, doubling. The other problem of 7907 is that it doesn't solve the problem that if you need even one byte of the code, you have to load the entire 64 kilobytes, if that's 64 kilobytes, and that's… that's, yeah, so it's not addressing a lot of the problems we know. When it comes to the code size, both AIPs just added to the account header, so that part doesn't change.

Ben Adams: Yeah, so, I mean, they both introduce a change to the account of adding the length And then in 7907, it does sort of address it, in that, yeah, you will need to load the full 64 kilobytes, but you… you pay additional. We're loading that. So, I mean, I see it as a pragmatic first step. Because, it's… what it does to the account tries is the same in both VIPs, so… I don't see it as, necessarily incompatible.

Guillaume Ballet: Well, in the case of 2926, you actually add a new tree inside the main tree, so it does more.

Ben Adams: Yeah, yeah, but I mean, they… they've… they both have the same first step, which is adding a code… code length to the account, so… That's the same change, and then… The additional is just gas pricing and… A higher limit.

Ansgar Dietrichs: Right. So, this seems like a tricky situation. We have, pretty passionate and strong support by two… well, by at least, the GATP and, and, and Guillum, within that for, for the, for 29… 26. And then we have, at least 3 clients currently that are more leaning towards DFI on this one. But then also we don't have strong, like, like, clear, unified support for 7907 as an alternative either, so how do we… Best actually make progress here towards a decision.

Dragan Rakita: Didn't we talk about 20… that we don't want 2926 in this fork? But we didn't talk, do we want 7907.

Guillaume Ballet: When did we talk about this? I completely… if that happened, I'd like to… I'd like to be informed.

Dragan Rakita: Asgard's mentioned in the chat, there are 3 clients that are They went to DFI2926, Bezu, Erigon, and Red.

Guillaume Ballet: Yeah, just to clarify.

Dragan Rakita: Thought.

Ansgar Dietrichs: So, let me briefly clarify. So, we had, several, two occasions so far where people have voiced opinions on these EIPs. One was the phase, the asynchronous phase, where all clients wrote preference documents. Out of those preference documents, we had, for 2926 in particular, we actually had both Geth and NetherMind signaling A on this, so this was indeed support on the CRP, and then we had Beisu listing it as DFI, which was a separate category that they invented beyond ABCD, S, A, B, C, and D, just for, the Purith and for the CAP. And then we had, Erigon also listed, with an X emoji. They only differentiated between X emoji and checkmark emoji, and this one… and question mark emoji, and this one was an X emoji for…

For Erigon. And since we had one synchronous discussion, this was two calls ago, actually, so last call we didn't get to this, so two calls ago, when we went through the very first round of discussing all EIPs. In that first round of discussion, it was controversial, where Erigon specifically… sorry, sorry, where Geth, expressed support. Erigon expressed, to not do this ahead of tree changes, and Nethermind had some concerns around it being expensive. And then Reth specifically expressed concerns about it being too complex, and also today, again, in chat, expressed, leaning towards DFI. So these are all the ways in which clients have so far expressed positions on the CFP. Does that clarify where we're at?

Guillaume Ballet: Yeah, I mean, regarding the Erigon one, which, indeed, did the same comment last time, my answer was, like, are you really going to do a… are you going to… are you ready to support a tree change in, H-star, or whatever it's called, Hogota? Are you ready to do this? Because otherwise, you're not gonna have, you're not gonna have a tree change anyway, so… that's the whole point of the CIP. Assume that tree change, is not going to happen for a few years, and we still need the code chunking, anyway. So… Yeah, just.

Ansgar Dietrichs: So…

Guillaume Ballet: I, I'.

Ansgar Dietrichs: So, I mean, I understand the situation here. The question is just, Guillaume, look, again, it's at least 3 clients, I don't know how to count Nethermind, but basically, like, at least 3 clients currently leaning towards DFI. I'm just… I personally, of course, wouldn't mind letting this decision until January 5th, it just, right now, doesn't look like that would actually change anything, and the default decision right now is DFI, obviously. We can't include something where 3 clients are on DFI. So unless you specifically think you have high chances of convincing people. between now and January 5th, I personally don't really see how we could not make the DFI decision today. If that makes sense.

Guillaume Ballet: No, it doesn't. I mean, you make a decision last time without, you know, me being present to defend it. It's, yeah, like… this, this is the first time I hear about, about the DFI, okay, so I met two times ago, I was there last time. Yeah, like. Once again, if I address… Every argument made. There should be some time for people to think about it and at least change their minds. You, like, so far, that's exactly what I said about 1832. It's all about feelings. Oh, I feel it's too complex, da-da-da. Yeah, okay. I want actual points. If you have actual points, then fine. We DFI it. I do not see any points being made.

Charles Cooper: I have a question, which is that there… is there consensus that, there are no, let's see, technical drawbacks, like, I'm wondering if there's any issues with code locality, and I've also discussed this with some other developers, because every chunk needs to be looked up.

Guillaume Ballet: Yeah, okay, sure. I mean, no, there isn't more, you have a different type of code locality in 7907, but… Yeah, you load a piece of code, you need to jump to a different location, you pay for a different thing, but it's 31 bytes, so… Your leeway to actually do code locality is going to be very limited.

Charles Cooper: That's what I'm saying, like, every time… every 32 bytes, the execution client needs to look up the next chunk.

Guillaume Ballet: Yeah, and, every… every 64, every, 24 bytes, kilobytes, you're gonna have to do the same thing. You're gonna be loading every… yeah, it's the same thing.

Ansgar Dietrichs: So… Yeah, just… because again, like, this is not… I don't personally have strong opinion. I actually really, in some way, really would want larger contracts in the EVM sooner rather than later. I think that's actually a quite desirable feature, but I don't really have super strong opinions myself on this. I'm really just trying to synthesize client positions here. I just think… in order to ever CFI anything, we would have, basically, like, all clients be willing to at least give up their veto, and probably most clients support it. We are pretty far for… from that status, that's not a good or bad thing, that is just the description of where we are today. So, unless, specifically, the three clients that are on the, kind of, opposition list, Erigon, Rath, Besu.

Would specifically all signal to… or, like, at least two of them would signal right now that they would at least be open to changing their mind. by January 5th. I think, just process-wise, there's not really much of a choice other than to make a DFI decision. And I really would not want to carry this on over into January 5th, unless, again, there's a specific reason for that, Lukash.

Łukasz Rozmej: I have two questions. One, was this, prototype anywhere, and does this prototype have, potential performance problems? Because now you're loading code, potentially. You're loading code as you do load state, which can create heavy latency issues. It can be probably mitigated with preloading it, or still keeping, this code also, by hash, and just loading it all, and just… Going through memory. But yeah, there are some questions around that. Hmm… website.

Guillaume Ballet: What's the second question?

Łukasz Rozmej: Was this prototype, and does this prototype handle any performance degradation potential here? Because this is kind of loading on the code on demand, and if we actually do this while executing. we will probably blow up execution times by loading code a lot from database, and so it needs to be handled better, in my opinion, to… in practice, right? In theory, we might Keep this… this, You know, the schema of trunking, but in practice, we probably want to preload a lot of code, or a whole code, when we execute it.

Guillaume Ballet: So, regarding the first question, and I know we're at time, so I'm gonna try to be quick. Has it been prototyped? Yes and no? It's been prototyped inside Verko. I didn't bother implementing it, because I figured, the bad decision was likely to be made, and my time is unfortunately limited. Regarding the loading. I would expect, I mean, yes, if you start, if you start loading it chunk by chunk, like, actual chunk by actual chunk, it will probably be, much slower. This being said, I expect you would be putting coach chunks in pages, so… so the limit, like, the performance hit. I'm expecting are much lower than that. But if, yeah, okay. I could implement it, I just need to have the assurance that at least there's a chance that it's, that it's worth it. So, yeah, I'm still waiting for… Yeah.

Ansgar Dietrichs: Yeah, then… and again, like, I'm sorry, I'm really not trying to be confrontational here, just trying to, like, move the process along. So, like, I would then briefly go through If we, you know, two more minutes here, and see if there's still people from these… from the clients here, and they can indicate whether they are open to you know, having their mind changed by January 5th, or whether that's hopeless, so… say, starting with, RETH, do we think… from the RETH side, do we think this is a soft no, or a hard no? Like, what's… what's the… what is the take on this EAP?

Dragan Rakita: internal, deifying it for Glamsterdam.

Ansgar Dietrichs: Okay, and for… from Bezo, do we have anyone still on the call?

Justin Florentine: Yeah, we're still in the DFI camp. We like this a lot better with other state tree changes. We're not opposed to it on its own, but we do think that it should wait for a time when other state changes are going in as well. Or, sorry, tree changes are going in as well.

Ansgar Dietrichs: And Erigon? Yeah, if we don't have anyone from Erigon anymore on the call, then, yeah, I would say, for process reasons, we… like, it doesn't seem like there is room for clients to be convinced here, and without client agreement, we just simply cannot include this in the fork. So, again, there's not… not as a personal decision, just as… just following the process here, I think it seems clear that this is a DFI decision today. M…

Guillaume Ballet: Okay, can we have the quick DFI decision about 7907, then?

Ansgar Dietrichs: I don't think we are over time already, because we took so long for this decision. I assume this is probably where that one is headed as well, but then we will have to wait for this until the continuation on January 5th. We did not discuss this today yet. Okay, then… So, just to… repeat DFI on 2926, and decision delayed until January 5th, 7907, not specifically because this one needs more time, just because this is the cutoff of process where we got to today. So this is the continuation. The plan for, January 5th will be to just continue with the remaining list first, and then get back to the few open questions that we had, and hopefully have time to go in depth there.

Thank you, everyone. And we're really getting very close to having the scope finalized. Thank you. Have, happy holidays, Merry Christmas, and talk to you all next year.

Marius van der Wijden: Bye-bye.

Łukasz Rozmej: Bye.

Greg K | Lido: Bye.

Fredrik Svantes: consultant.

Lightclient (Matt Garnett): Merry Christmas.

Jochem Brouwer: I agree.

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