Ansgar Dietrichs:Well, hello. Welcome, everyone, to All Core Devs Call 226.
Transcript
Ansgar Dietrichs:Which will be the last one for this year?
Ansgar Dietrichs:Yeah, let's get right into it, it'll be another packed one. We have a few…
Ansgar Dietrichs:Announcements first, so the first one is specifically concerning the… holiday, schedule?
Ansgar Dietrichs:So,
Ansgar Dietrichs: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…
Ansgar Dietrichs:Next week, 22nd and 25th of December, both calls are canceled.
Ansgar Dietrichs:And, then also, the week after, 29th of December and 1st of January, both calls would be canceled.
Ansgar Dietrichs: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,
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:Does that schedule generally… Sound reasonable? If I don't have any objections, then we will just lock that in.
Ansgar Dietrichs:Perfect.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
kev:the ETH R&D channel that we have,
kev:called L1ZKVM, and Antigar's posted a link in the comments.
Ansgar Dietrichs:Perfect.
Ansgar Dietrichs:Thank you.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:There was a decision made to basically, CFI FOCIL for the upcoming H-star hard fork.
Ansgar Dietrichs:So we will have FOCIL as a kind of a pre-CFI DAP, and then we'll start the,
Ansgar Dietrichs:we'll, we'll start the, the headliner process there soon.
Ansgar Dietrichs: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…
Ansgar Dietrichs: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?
Ansgar Dietrichs: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.
Ansgar Dietrichs:Do you want to briefly comment on this?
Ansgar Dietrichs:No audio, okay.
Ansgar Dietrichs: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…
Ansgar Dietrichs:Okay, well, that's… that's not bike shit. I think, yeah, then let's go with this renaming. So,
Ansgar Dietrichs:we'll just, you know… and it's apparently pronounced Hezu.
Ansgar Dietrichs: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.
Ansgar Dietrichs:There was an updated poll in the ETH Magicians using this new first part of the name.
Ansgar Dietrichs:And the leading candidate there in the poll is Hegota.
Ansgar Dietrichs:So, I just wanted to see if we have agreement to accept Heikota on today's call as an official decision.
Ansgar Dietrichs:Anyone who has anything? Any veto reason?
Ansgar Dietrichs: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.
Ansgar Dietrichs:Yeah, looking forward to that, Falk.
Ansgar Dietrichs:Awesome.
Ansgar Dietrichs:And then,
Ansgar Dietrichs:One more… Actually, I see now that I forgot to put that on the agenda, that's my bad.
Ansgar Dietrichs:But, Nick so specifically wanted to get a sign-off on the proposed,
Ansgar Dietrichs:timeline for the… for the HSTAR EAP selection process, both headline and non-headliner, and can post a…
Ansgar Dietrichs:link to that in the chat. My bad for not having this on the agenda.
Ansgar Dietrichs:Nick, so are you on the call and could briefly speak on… speak to this?
nixo:Yeah, so that, that timeline is proposed.
nixo:Opening the headliner proposals, and then choose… And it sort of,
nixo: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,
Ansgar Dietrichs: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,
nixo: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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,
Ansgar Dietrichs:This proposal, once a decision on the headliner is made.
Ansgar Dietrichs: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…
Ansgar Dietrichs:Adjustments?
Ansgar Dietrichs:Okay.
Ansgar Dietrichs: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,
Ansgar Dietrichs:Timeline.
Ansgar Dietrichs:And apologies again that this was not on the agenda.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:we would then make those few remaining decisions on January 5th, and then hopefully have a fully locked-in
Ansgar Dietrichs:Foxcope by January 5th.
Ansgar Dietrichs: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.
Marius van der Wijden:So, first of all, I'm synthesizing… synthesizai…
Marius van der Wijden: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.
Marius van der Wijden:So, they've been putting in a lot of work in order to,
Marius van der Wijden:To get us to the point here, and,
Marius van der Wijden: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,
Marius van der Wijden:Repricing effort is a harmonization between the compute opcodes itself, and then also a harmonization between the areas of compute, state access, data.
Marius van der Wijden:And we want to do a mitigation for state growth. Because if we don't mitigate state growth and we increase the gas limit.
Marius van der Wijden:Then, yeah, the chain will grow much faster.
Marius van der Wijden:faster than we would have liked. So what we are, currently…
Marius van der Wijden:proposing is to target, 60 megacity per second.
Marius van der Wijden:So all operations below 60 megabits per second would need to be repriced.
Marius van der Wijden: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.
Marius van der Wijden:And one thing that we might want to propose
Marius van der Wijden:In the future is, price reductions for… for very expensive operations.
Marius van der Wijden:But this heavily depends on the timelines for,
Marius van der Wijden:for, for, for Glemson, and, Yeah, so…
Marius van der Wijden:we don't want to propose that today, but what we want to propose today, is to CFI EIP7904,
Marius van der Wijden:In order to, to move this along.
Marius van der Wijden: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.
Marius van der Wijden: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.
Marius van der Wijden:And, regarding state access, again, we are targeting 60 megabits per second.
Marius van der Wijden:We have, EAP8038, which, increases the cost for state access. The numbers there are still missing, but, we,
Marius van der Wijden:We are very confident that, or…
Marius van der Wijden: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.
Marius van der Wijden: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.
Marius van der Wijden: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.
Marius van der Wijden:There are 3 options, that we have, AT37,
Marius van der Wijden: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,
Marius van der Wijden: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.
Marius van der Wijden:This,
Marius van der Wijden:this, introduces, like, a similar mechanism to 1559 in order to, get us to a certain target of state growth per block.
Marius van der Wijden:And what has become clear over the last couple of weeks, that some repricing has to be done with regard to state growth.
Marius van der Wijden:And, if we move into the future also.
Marius van der Wijden:Probably state needs to be…
Marius van der Wijden:Measured on a different axis than compute.
Marius van der Wijden: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.
Marius van der Wijden:Different, proposals.
Marius van der Wijden:So, concluding…
Marius van der Wijden:We would like to target, 60 megabits per second with repricings, that would, that would significantly, like, allow for significant more headroom, for scaling.
Marius van der Wijden: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.
Marius van der Wijden:to CFI. We would like to discuss
Marius van der Wijden: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.
Marius van der Wijden:Yeah, that is basically… what I wanted to share today.
Marius van der Wijden:I can leave the… I cannot see the… I cannot see… There's the chat, but,
Marius van der Wijden: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,
Ansgar Dietrichs: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?
Ansgar Dietrichs:proposals here.
Ben Adams:And just a…
Ben Adams:Just a quick comment on 2780. Additionally, I think ETH transfer logs, that would add a
Ben Adams:A small amount additionally on top.
Ben Adams: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.
Ansgar Dietrichs:in combination with the… the state access, gas cost increase EIP, the cost of a… of a transaction that,
Ansgar Dietrichs: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…
Ben Adams:The cost of that account creation will be
Ben Adams:You know, it… depending on what we do with, state growth.
Ben Adams:will be that price. But at the moment, there's a loophole where if you create an account.
Ben Adams:That's part of a…
Ben Adams: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.
Ben Adams: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.
Łukasz Rozmej: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…
Łukasz Rozmej: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.
Marius van der Wijden: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.
Marius van der Wijden:Or state-related operations.
Marius van der Wijden:If I remember correctly.
Ben Adams:Also, with the repricings, if we… if we do them…
Ben Adams:We're reducing the price of compute, so we are effectively increasing, in a relative term, the price of state.
Ben Adams:And, you know, it's also dependent on the… gas. Price.
Ben Adams:Which is my concern with the… The basic estate growth one.
Ben Adams:Where if we… if we just…
Ben Adams:Versus the two targeted, you know, this is…
Ben Adams:targeting a certain amount of state growth and adjust the price. If we just increase the price of state, then potentially
Ben Adams: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
Ansgar Dietrichs: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…
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs:From the repricing team side would be to radically reduce its scope.
Ansgar Dietrichs: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.
Ansgar Dietrichs:Again, this is just the proposed approach, because there were concerns about testing scope for a larger set of changes.
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Marius van der Wijden:to think about what could be done, maybe, in a certain future. I think it is more important
Marius van der Wijden: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
Marius van der Wijden:At least theoretically, the throughput from 20 MHz per second to 60 megabits per second.
Marius van der Wijden: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…
Ansgar Dietrichs:Basically treating them the same here. Marius, do you want to comment on that?
Marius van der Wijden:Well…
Marius van der Wijden: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?
Marius van der Wijden:Because we can…
Marius van der Wijden:Load the state, before, and so all of the state would actually be kind of cached at the moment of, of accessing the state.
Marius van der Wijden:And also, The numbers for the state access costs will definitely be revisited once we have
Marius van der Wijden:a, version of block access list life that we can.
Marius van der Wijden:That we can really… that resembles the final thing, and that we can use to, to measure.
Marius van der Wijden:All of this.
Ansgar Dietrichs:Right. And basically.
Ansgar Dietrichs: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
Ansgar Dietrichs:Next best thing, the cheap thing to do here, that is just to pick a…
Ansgar Dietrichs: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.
Ansgar Dietrichs:by just targeting the same floor, we'll get similar-ish benefits, at least. I think that that is the…
Ansgar Dietrichs:The intention here behind such a simple shared floor.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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…
Ansgar Dietrichs:basically the things below the flow more expensive instead? Are people generally okay with that recommendation? Would they want a more ambitious scope?
Ansgar Dietrichs: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…
Ben Adams:You know, a hard… a hard band. See how we go.
Ben Adams:At least, I mean, it's obviously better to…
Ben Adams:To remove the worst cases is the first step.
Ansgar Dietrichs:And Dragon.
draganrakita:We will be fine with increased scope and repricing every output.
draganrakita:At least CPU, related one, related data IP.
Marius van der Wijden:Right, and… The problem, like, the problem with increasing scope is that
Marius van der Wijden:The work is not on the client teams,
Marius van der Wijden:to do this, like, the work on the client teams is very easy, they just need to…
Marius van der Wijden:change one variable. The bulk of the work is on the testing teams and the benchmarking teams.
Marius van der Wijden:To, do all of these benchmarks. And,
Marius van der Wijden:we have a lot of people working on it, but I don't…
Marius van der Wijden: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
Marius van der Wijden: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.
Marius van der Wijden:Many teams are not…
Marius van der Wijden:are not as focused on it, or do not put as much resources into it as I would have liked.
Marius van der Wijden:So, yeah.
Ansgar Dietrichs:Dragon?
draganrakita:And we have, like, that big, gas,
draganrakita:I'm not sure of how it's called.
draganrakita:Basically, 4th to 5th version, that basically specifies how, or recommends how the gas should be moved.
draganrakita:And I wasn't DCIP, basically, based on that data.
draganrakita: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.
draganrakita: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…
Ansgar Dietrichs:say, by H-star, have…
Ansgar Dietrichs: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
Ansgar Dietrichs:The floor, and we can always add things back if… into the fork process, we realize we have room and time.
Ansgar Dietrichs:It's easy to do, but basically better to start small.
Ansgar Dietrichs:Then to start too ambitious.
Ansgar Dietrichs:Okay. Then, I think, kind of, we can move to the main, kind of, decision-making section here. I think, Josh, you wanted to…
Ansgar Dietrichs:share your screen. The document is…
Ansgar Dietrichs:Here, I put the link in chat. It's the same document as last time, just,
Ansgar Dietrichs:I updated the annotations,
Ansgar Dietrichs: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.
Ansgar Dietrichs:As of 30 minutes ago, they're also reflected in the meta-EIP, by the way.
Ansgar Dietrichs:Okay, so then let's first talk about the repricing section. So, just to repeat, $27.80 is a bit…
Ansgar Dietrichs: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.
Ansgar Dietrichs:So I would… that… it is a CFI candidate for that reason. And then the other four, basically,
Ansgar Dietrichs:Specifically the recommendations from the repricing side.
Ansgar Dietrichs:If we would prefer to not do one of them, then we should revisit all four decisions, because those four are really…
Ansgar Dietrichs:only, impactful if they're done together. But maybe let's first take the decision on 2780.
Ansgar Dietrichs:How do people feel about this? This had pretty strong support across all clients.
Ansgar Dietrichs:Anyone that opposes a CFI decision?
Ben Adams:I obviously support it, but I'd just like to highlight, as I say,
Ben Adams:It does also depend on… Some other repricings.
Ben Adams: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.
Ansgar Dietrichs: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…
Ansgar Dietrichs:For a while longer into the fog.
draganrakita:In general, 2718 makes sense to add. I would just slightly modify it, or basically have discussion around it.
draganrakita: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.
draganrakita:And when the transaction starts executing.
draganrakita:We deduce… deduct additional gas if… depending if the value is more than zero, and if the target account is not existing.
draganrakita: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.
Ben Adams:Blitz sit.
Ben Adams:It breaks down…
Ben Adams: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.
Ben Adams:Rather than.
draganrakita:Yep.
draganrakita:Yeah, but it does it as the part of interest to gas. What I'm saying is, let's split that.
draganrakita:To not have additional check in intersection pool, and just do that check at… as part of execution.
draganrakita:In this sense,
draganrakita: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…
Ben Adams:You'd fail by saying that.
draganrakita: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
Ansgar Dietrichs:To basically have all of these details worked out before you would want to make a final decision.
draganrakita:CFI today. Anything that we chose, it's good enough and can be included.
draganrakita:It's not a blocker.
Ansgar Dietrichs:Okay. Then, anyone else with something they see as a blocker here?
Ansgar Dietrichs:then…
Ansgar Dietrichs: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…
Ansgar Dietrichs: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.
Ansgar Dietrichs:Then it's this one, I think, so let's maybe discuss this one first. Do we feel comfortable
Ansgar Dietrichs:making a CFI decision on this one, with the understanding that basically we'll specifically establish this 60 megap per second floor.
Ansgar Dietrichs:Is that basically anyone Feels uncomfortable with that.
Ansgar Dietrichs:is there, in general, like, is there support for CFI? Is just… do people not have an opinion? Like, what's the…
Ansgar Dietrichs:What is the… the client situation here?
Ansgar Dietrichs:We can also, of course, delay decisions. It felt like…
Ansgar Dietrichs: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…
Ben Adams:I think it needs a bit.
Ben Adams:Bit more consideration.
Ben Adams: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,
Ansgar Dietrichs: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…
Ansgar Dietrichs:Interactions with existing state.
Ansgar Dietrichs:I just…
Ansgar Dietrichs:You took this one first, because out of all of the previous discussions of these, repricing changes, this was always the one that was…
Ansgar Dietrichs: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…
Ansgar Dietrichs: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
Ansgar Dietrichs:Gas per second, so this would… result in an…
Ansgar Dietrichs: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…
Ben Adams:People who do gas introspection limits.
Ben Adams: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.
Ansgar Dietrichs:60 megabits per second or something, and then state can only run at 20 or 30.
Ansgar Dietrichs:then we are running the entire AVM at, like, half speed because of it.
Ansgar Dietrichs: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
Ansgar Dietrichs: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…
Ansgar Dietrichs:A take on whether Geth would…
Ansgar Dietrichs:be in favor of the CAP?
Ansgar Dietrichs:Otherwise, I would just… Take Marie's.
Ansgar Dietrichs:take on this for Geth, and then do we have, from, Wrath, Besu, or Erigon, do we have…
Ansgar Dietrichs:opinions?
Ameziane Hamlat:on… on… on the basis side, I think we are fine with this EIP.
Ameziane Hamlat:I agree, like, to be…
Ameziane Hamlat:TBD is a bit confusing, but I guess, I know that there are some, some benchmarks
Ameziane Hamlat: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,
Ameziane Hamlat: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?
Ansgar Dietrichs: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?
Ansgar Dietrichs:I personally would be open to both, but I think overall there was
Ansgar Dietrichs:strong desire to basically make decisions sooner rather than later. Guillaume?
Guillaume: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.
Guillaume:Let's not look at it until it's been benchmarked, and so on.
Guillaume: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.
Guillaume:we, you know, considered doesn't mean included for sure, so I'd say it doesn't cost much to…
Guillaume: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.
Ansgar Dietrichs:Then I would propose we actually make a CFI decision now, last chance for anyone to object.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:Is there a position to CFI there?
Ansgar Dietrichs:Yes?
Ameziane Hamlat:Yeah.
Ameziane Hamlat: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.
Ameziane Hamlat: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…
Ameziane Hamlat: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…
Ameziane Hamlat:both kind of replacing make.
Ameziane Hamlat: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.
Marius van der Wijden:And in order to get to the target of 60 MHz per second, we would need this is… my…
Marius van der Wijden:This is pending benchmarks, but the way benchmarks are looking right now, we would need to reprice
Marius van der Wijden: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,
Marius van der Wijden:Some of them would only need to be repriced by…
Marius van der Wijden:By 10%, but, some of them would need to be repriced by, like, 3X, roughly.
Marius van der Wijden:So for example, The point evaluation precompile.
Marius van der Wijden: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.
Marius van der Wijden:50 benchmarks, or, or so, of all clients, and, in P99, we arrive at,
Marius van der Wijden:For the point evaluation, we arrive at, 31.
Marius van der Wijden:Oh, sorry. Yeah, we arrive at, at 31… Mega gas per second, so…
Marius van der Wijden:We would need to reprice, by… 2.5.
Marius van der Wijden: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.
Ameziane Hamlat:make them cheaper? Are we talking about, like, the opposite? Like, make, yes.
Marius van der Wijden:Exactly.
Marius van der Wijden:So, yeah, we, we, we will be, considerably rewriting the… the list in… 7904.
Marius van der Wijden:Ben?
Ben Adams:Yeah, so I assume the goal coming out of the minimal.
Ben Adams:Changes would be to… Be able to increase the gas limit, versus,
Ben Adams:Do more at the same decimate.
Ben Adams:Which would be the lowering price.
Marius van der Wijden:Yes.
Ansgar Dietrichs:Yeah, so this is kind of, in a way.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:It seemed like there was then, with these clarifications about the intention here, that there was broad CFI support. Any remaining questions?
Ansgar Dietrichs:Okay, then, where we can see if I had this one.
Ansgar Dietrichs: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
Ansgar Dietrichs:quite a bit of confidence into these rough numbers, at least, but basically, with that caveat said,
Ansgar Dietrichs:Any, any, opposition to CFI-ing, 7976.
Ansgar Dietrichs:then I would say, CFI. And, any opposition to CFI-ing 7981?
Ansgar Dietrichs:That is specific to the, access list.
Ansgar Dietrichs:That bitch.
Ben Adams:I'd just like to express a strong spot on that, because Accessless, since we're also doing bowels,
Ben Adams:They become sort of irrelevant, other than the…
Ben Adams:Very original purpose that they were introduced for, which was fixing broken contracts.
Ben Adams:Otherwise, they're like a hindrant.
Ansgar Dietrichs:Yep.
Ansgar Dietrichs:I agree.
Ansgar Dietrichs: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.
Ansgar Dietrichs:deprecation. But yeah. Okay, then we, CFI all EIPs in this section.
Ansgar Dietrichs:Nice.
Ansgar Dietrichs: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,
Ansgar Dietrichs:Pricing, do people agree with that? To delay that decision until January 5th?
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs:Some more data, too.
Ansgar Dietrichs:Support that decision.
Marius van der Wijden:Yeah, I can… I can shine a light on what's happening with the state benchmarks.
Marius van der Wijden:We,
Marius van der Wijden:bloating again, to a 4x minutes state, and in the meantime, we are also, updating our infrastructure to run
Marius van der Wijden:These, the state-related benchmarks on
Marius van der Wijden:basically different state, whatever, like, snapshot we have of whatever network we want to run, and we want to run them on
Marius van der Wijden: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,
Marius van der Wijden: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.
Marius van der Wijden:They have been running…
Marius van der Wijden:Also, for the compute, operations, we have, pretty good benchmarks now, and they have been running,
Marius van der Wijden:Every couple of hours, but for the state benchmark, the, the,
Marius van der Wijden:The infrastructure is just significantly more complex, and,
Marius van der Wijden: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…
Ansgar Dietrichs:There's no more comments on this topic.
Ansgar Dietrichs:Okay, then we have the,
Ansgar Dietrichs: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,
Ansgar Dietrichs: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
Ansgar Dietrichs:Mmm… As a potential CFI candidate or something, but, in the end.
Ansgar Dietrichs: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…
Ansgar Dietrichs:Am I…
Ansgar Dietrichs: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…
Ansgar Dietrichs: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.
Ansgar Dietrichs:Oh, yes, we no longer have to say H star.
Ansgar Dietrichs:Mmm… That's right.
Ansgar Dietrichs: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.
Ansgar Dietrichs:Suggestion is DFI?
Ansgar Dietrichs:Does anyone want to argue against DFI?
Ansgar Dietrichs:And maybe before we make that decision, then also for the other one, because they're really kind of related,
Ansgar Dietrichs:7923… Are there, if… would anyone oppose a DFI on this one?
Ansgar Dietrichs:Okay.
Ansgar Dietrichs:Then, I would suggest to just… yeah, then I would say we just DFI both of them.
Ansgar Dietrichs: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.
Ansgar Dietrichs:Okay, then,
Ansgar Dietrichs:We move on. The general repricing sections here, we have, a few more to talk about.
Ansgar Dietrichs: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.
Ansgar Dietrichs:if those, of course, have been addressed, and if by now, people…
Ansgar Dietrichs: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.
Ansgar Dietrichs: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…
Ben Adams:the account abstraction concerns are real. Good.
Ben Adams: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
Ansgar Dietrichs: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
Ansgar Dietrichs:Transaction that bundles the operations of multiple users.
Ansgar Dietrichs:that are shared, basically. Then one user can use up everything up to that cap.
Ansgar Dietrichs: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
Ansgar Dietrichs:Secret second counter.
Ansgar Dietrichs: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.
draganrakita: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,
draganrakita:Cars for accessing all the created transition, transient storage, so that part is quite nice.
draganrakita: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.
Ben Adams:The amount of memory you can allocate becomes huge.
draganrakita:Yeah, but it has different pricing if you increase the trading storage, or when you just access trading storage to just,
draganrakita:Chain.
Ben Adams:Huh.
draganrakita:existing 3D storage.
Ben Adams:Different times.
Ben Adams:Maybe just drop the, drop the price for access, but… Keep the storage high.
draganrakita:Yeah, exactly. I think the gas values maybe need to be… they will depend on general repricing that we do.
draganrakita:But in general, yeah, seems like a nice AIP.
draganrakita:We… from red side, we mark it as neutral, so it depends, do we have, like.
draganrakita:Do you want to close it or not?
draganrakita: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:One more chance. Okay, so then delayed decision on 7971, and then we move on to, 7973, warm account right metering,
Ansgar Dietrichs:This one is, a DFI candidate, just because it basically was kind of one of those middling EIPs, not much support, not much opposition,
Ansgar Dietrichs:Which makes it a default DFI, anyone that wants to oppose DFI here.
draganrakita:Just to add comment, this kind of logic we already have for S-Store, basically for storage.
draganrakita:And basically, it is some kind of optimization when we want to…
draganrakita:Increased balance for account that's already scheduled to be… not scheduled, but…
draganrakita:Increasing the balance two times, second balance is going to be cheaper.
draganrakita:So, from our side, it's marked as neutral, because it depends if there is room to include it or not.
draganrakita: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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:Yeah,
Guillaume: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.
Guillaume: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…
Guillaume: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.
Guillaume: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…
Guillaume: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.
Guillaume: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…
Guillaume:to the account. So, there's…
Guillaume: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.
Guillaume:I am, of course, happy to answer any questions about this.
Guillaume:But I think, we should CFI this one, and the reason we should CFI this one is because this is having a negative impact
Guillaume: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.
Guillaume:Disincentivize, you know, touching this contract, which is, which is dragging everybody down.
Guillaume:you don't have a better option, than this, because once again, AT37,
Guillaume: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.
Ben Adams:The new input.
Guillaume:What new input are you looking for?
Ben Adams:Oh, you… you… that you've just prepared.
Ben Adams:Because I doubt anybody's read it.
Ben Adams:Fully.
Guillaume: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:Doesn't CF… does not… does CFI not mean that we are considering…
lightclient:Including it. And we're looking for more information.
lightclient:It's not good.
Ben Adams:We're cons… we're considering, considering including.
lightclient:I don't know, I feel like if we're trying to go through all of these EAPs… CFI…
lightclient: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,
Łukasz Rozmej:archive sync that is replaying everything from the beginning, it has to go explicitly through this migration every time, right?
Łukasz Rozmej:Yep.
Łukasz Rozmej:Previous and the next.
Guillaume:Absolutely. So, this is… I mean, this is in consensus, right? The iterator pointers are stored in a system contract.
Guillaume:So you…
Guillaume: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.
Guillaume: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.
Łukasz Rozmej:It is doable, I agree that this is doable, I'm just unsure about if it's not…
Łukasz Rozmej:Too complex to… to…
Łukasz Rozmej: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: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…
Guillaume:and, you know, try to change your mind, but, if you're just telling me it feels complex, I… I can't,
Guillaume:you know, I can't…
Guillaume: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…
Guillaume: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…
Guillaume: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…
Ansgar Dietrichs: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.
Ansgar Dietrichs: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…
Ansgar Dietrichs:Clear agreement on either side yet?
Ansgar Dietrichs:Okay, then let's move on. We have a few more topics to go through, and we still have 18 more minutes.
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Ansgar Dietrichs: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,
Ansgar Dietrichs:In terms of, prior discussion, there was pretty strong opposition, by… by several clients,
Ansgar Dietrichs:to 2926, but it was actually quite controversial, so we could… yeah. I just wanted to open this discussion back up. 2926 or 7907?
Ansgar Dietrichs:Guillaume?
Guillaume: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,
Guillaume: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.
Guillaume:The reason why we want 2926 is because it does address the prover killers, and it solves the code size limit in one swoop.
Guillaume: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
Guillaume:awkward as the one proposed in 7907. In my understanding, the people that were working on 7907
Guillaume:gave up on, on this, on this CAP, I could be wrong, but that's, that was my understanding.
Guillaume: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.
Guillaume:Okay, what I wanted to add is, yeah, like, the 2926 is… future-proof?
Guillaume: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
Guillaume: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: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…
Ben Adams:I mean, it was very late in the fork, and there were complications with it, which I don't…
Ben Adams: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.
Ansgar Dietrichs: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,
Greg K | Lido:it seems to us that 7, 907 is simpler, and TIR supposed to text on the PR,
Greg K | Lido: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.
Greg K | Lido: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
Greg K | Lido: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…
Greg K | Lido:this is wrong that, so let's say client teams believe that it's more complex than, the other solution, then that's fine.
Greg K | Lido: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,
Greg K | Lido: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
Greg K | Lido:it's, it's not so hard to be part of Amsterdam.
Ansgar Dietrichs:Thank you.
Guillaume: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,
Guillaume: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.
Guillaume:approaches. I think in the past, we… we always,
Guillaume: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…
Guillaume: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…
Guillaume: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
Ben Adams: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.
Ben Adams:We're loading that.
Ben Adams:So, I mean, I see it as a pragmatic first step.
Ben Adams:Because, it's… what it does to the account tries is the same in both VIPs, so…
Ben Adams:I don't see it as, necessarily incompatible.
Guillaume: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…
Ben Adams:That's the same change, and then…
Ben Adams: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,
Ansgar Dietrichs:the GATP and, and, and Guillum, within that for, for the, for 29… 26.
Ansgar Dietrichs:And then we have, at least 3 clients currently that are more leaning towards DFI on this one.
Ansgar Dietrichs:But then also we don't have strong, like, like, clear, unified support for 7907 as an alternative either, so how do we…
Ansgar Dietrichs:Best actually make progress here towards a decision.
draganrakita:Didn't we talk about 20… that we don't want 2926 in this fork?
draganrakita:But we didn't talk, do we want 7907.
Guillaume:When did we talk about this? I completely… if that happened, I'd like to… I'd like to be informed.
draganrakita:Asgard's mentioned in the chat, there are 3 clients that are
draganrakita:They went to DFI2926, Bezu, Erigon, and Red.
Guillaume:Yeah, just to clarify.
draganrakita: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,
Ansgar Dietrichs: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,
Ansgar Dietrichs: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…
Ansgar Dietrichs:For Erigon.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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: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?
Guillaume:Because otherwise, you're not gonna have, you're not gonna have a tree change anyway, so…
Guillaume: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
Guillaume:the code chunking, anyway. So… Yeah, just.
Ansgar Dietrichs:So…
Guillaume: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…
Ansgar Dietrichs: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
Ansgar Dietrichs:are on DFI. So unless you specifically think you have high chances of convincing people.
Ansgar Dietrichs:between now and January 5th, I personally don't really see how we could not make the DFI decision today.
Ansgar Dietrichs:If that makes sense.
Guillaume: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…
Guillaume: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.
Guillaume:Once again, if I address… Every argument made.
Guillaume:There should be some time for people to think about it and at least change their minds.
Guillaume:You, like, so far, that's exactly what I said about 1832.
Guillaume:It's all about feelings. Oh, I feel it's too complex, da-da-da. Yeah, okay.
Guillaume:I want actual points. If you have actual points, then fine. We DFI it. I do not see any points being made.
Charles:I have a question, which is that there… is there consensus that, there are no,
Charles: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:Yeah, okay, sure. I mean, no, there isn't more, you have a different type of code locality in 7907, but…
Guillaume: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…
Guillaume:Your leeway to actually do code locality is going to be very limited.
Charles:That's what I'm saying, like, every time… every 32 bytes, the execution client needs to look up the next chunk.
Guillaume: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…
Ansgar Dietrichs: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…
Ansgar Dietrichs: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…
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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.
Łukasz Rozmej:You're loading code as you do load state, which can create heavy latency issues.
Łukasz Rozmej:It can be probably mitigated with preloading it, or still keeping, this code also, by hash, and just loading it all, and just…
Łukasz Rozmej:Going through memory. But yeah, there are some questions around that.
Łukasz Rozmej:Hmm… website.
Guillaume: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.
Łukasz Rozmej: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
Łukasz Rozmej:Keep this… this,
Łukasz Rozmej: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: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.
Guillaume: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.
Guillaume: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.
Guillaume:This being said, I expect you would be putting coach chunks in pages, so… so the limit, like, the performance hit.
Guillaume: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
Ansgar Dietrichs: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
Ansgar Dietrichs:you know, having their mind changed by January 5th, or whether that's hopeless, so…
Ansgar Dietrichs: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?
draganrakita:internal, deifying it for Glamsterdam.
Ansgar Dietrichs:Okay, and for… from Bezo, do we have anyone still on the call?
Justin Florentine (Besu):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?
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:M…
Guillaume: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.
Ansgar Dietrichs:We did not discuss this today yet.
Ansgar Dietrichs:Okay, then… So, just to…
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs:Thank you, everyone.
Ansgar Dietrichs: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:consultant.
lightclient:Merry Christmas.
jochem-brouwer:I agree.
Chat Logs
00:03:25
Shariq Naiyer:@jochem-brouwer
00:03:32
jochem-brouwer:Thanks :)
00:03:42
Pari:Proposed ACD holiday schedule: 18dec - ACDE
22dec - ACDT Cancelled
25dec - ACDC Cancelled
29dec - ACDT Cancelled
1jan - ACDE Cancelled
5jan - ACDT -> ACDE
8jan - ACDC
12jan - ACDT
00:03:55
Fredrik:Replying to "Noob Q: how do I cha..."
I believe you need to have a zoom account, then open settings, my account, change pic
00:05:36
Ansgar Dietrichs:zkEVM roadmap doc: https://github.com/eth-act/planning/pull/1
00:07:21
stokes:imo the heka name has shipped
00:07:27
frangio:HEH-zuh
IPA: /ˈhɛzə/
Stress on the first syllable, with a soft final “uh” sound.
00:07:33
Justin Traglia:Pronounced hegota 🙂
00:07:38
stokes:i think fine to leave it alone
00:07:43
Justin Florentine (Besu):no one can pronounce? fantastic choice.
00:07:45
Pari:hegota 😄
00:07:52
stokes:i won’t push back
00:07:54
Pari:Replying to "no one can pronounce..."
Its part of the unspoken rules...
00:07:55
stokes:no audio
00:08:01
Pari:Try saying any of the testnet names properly, I dare you
00:08:06
Marius van der Wijden:Lets not bikeshed the name
00:08:13
stokes:then accept
00:08:18
Justin Florentine (Besu):Replying to "no one can pronounce..."
can't spell ethereum, can't pronounce the forks. love it.
00:08:30
Francesco:I think we need an extraordinary council meeting for this
00:08:47
Justin Florentine (Besu):hokota
00:09:00
nixo:sgtm
00:09:00
stokes:ship it
00:09:00
Karim T. (matkt):Replying to "no one can pronounce..."
Besu ?
00:09:03
Guillaume:yes, it's ugly
00:09:03
jochem-brouwer:ship et
00:09:27
Will Corcoran:Replying to "hokota"
north hokota
00:09:50
Ansgar Dietrichs:https://ethereum-magicians.org/t/eip-8081-heka-bogota-network-upgrade-meta-thread/26876
00:10:48
jochem-brouwer:This is 8jan-4feb then?
00:11:06
Justin Florentine (Besu):kinda love this aggressive scheduling of forks tbh
00:12:12
stokes:ship it
00:13:52
Trent:lmao
00:14:01
Josh Davis:Well done
00:14:10
Ansgar Dietrichs:repriced that wording mid-sentence
00:15:17
Ben Adams:Movie poster for EIP-7904: General Repricing https://x.com/ben_a_adams/status/2001148892214137249
00:15:55
Ansgar Dietrichs:to clarify, it’s a proposed 60 Mgas/s floor, so only reprice the operations that are currently performing worse than that floor, not the ones above
00:16:16
Dustin:is there a standard benchmark platform for this?
00:16:26
Dustin:hardwarewise
00:16:53
jochem-brouwer:Antwoord verzenden naar "is there a standar..."
Yes, @kamil could chime in on this
00:17:14
Pari:Replying to "is there a standard ..."
Yes, we use reference hardware machines that were the same as the benchmarker machines used for gas limit increases throughout the year
00:18:48
Maria Silva:For clarity, EIP-8073 is not yet merged. But it is a simple change to EIP-8037, which we can easily add
00:19:17
Ansgar Dietrichs:Anders’ overview: https://notes.ethereum.org/@anderselowsson/3-paradigms-for-state-creation-repricing
00:20:03
Francesco:Another option could be to modify 8075 to just do separate metering of state growth (as in the more general multidimensional metering), without the adaptive state_gas_per_byte component
00:20:30
Maria Silva:Replying to "Another option could..."
Correct
00:20:34
Maria Silva:Replying to "Another option could..."
Good point
00:20:36
Francesco:Replying to "Another option could..."
https://notes.ethereum.org/@anderselowsson/3-paradigms-for-state-creation-repricing#Metering
This I guess
00:20:55
Carl Beekhuizen:Please can we rename 7904 to Compute Repricings
00:20:56
Francesco:Replying to "Another option could..."
Or rather, this https://notes.ethereum.org/@anderselowsson/State_metering
00:20:58
Toni Wahrstätter:Replying to "Another option could..."
What's the difference to the full multidim proposal? Is what your saying a subset of it?
00:21:06
Ansgar Dietrichs:PFI EIP list: https://notes.ethereum.org/@ansgar/glamsterdam-el-pfi-eips
00:21:14
Louis:Replying to "Please can we rename..."
Good idea
00:21:17
Toni Wahrstätter:Replying to "Another option could..."
Ah, nvm, thx for sharing
00:21:46
Francesco:Replying to "Another option could..."
Full multidim meaning metering or pricing? If the former, the difference is that it’s only adding the state growth dimension to the metering, rather than a few resources
00:21:50
Ameziane Hamlat:Are the numbers going to change for EIP-7904 following the results of the benchmarks ?
00:22:22
Louis:Replying to "Are the numbers goin..."
I think it would be changed according to new benchmark results
00:22:36
Maria Silva:Replying to "Another option could..."
A key difference is that 8075 excludes state creation cost from the bock limit, instead of using the max function as multidimensional metering
00:22:55
Maria Silva:Replying to "Are the numbers goin..."
Yes, it will use the recent benchmarks
00:23:39
Dustin:"about 30%"?
00:23:40
Maria Silva:Sorry, 30%
00:23:40
Toni Wahrstätter:30%
00:23:48
jochem-brouwer:~~70% compute :)~~ forgot data part
^ should be strikethrough
00:23:55
Maria Silva:Let me get the plot
00:24:14
Toni Wahrstätter:Replying to "70% compute :)"
Don't forget data
00:26:04
Guillaume:Replying to "Here is the breakdow..."
what is "access" here ?
00:26:10
Maria Silva:Replying to "Here is the breakdow..."
State IO
00:26:23
Łukasz Rozmej:Replying to "Here is the breakdow..."
State -> state write
Access -> state read?
00:26:42
Luis Pinto | Besu:BALs will make compute much cheaper than state access, why don’t we go through a general repricing after that is integrated? It feels we will go through another round of repricing after all clients implement that
00:26:47
Ahmad Bitar | Nethermind:Replying to "Here is the breakdow..."
State is storage cost i think. access is read/write
00:26:50
Guillaume:Replying to "Here is the breakdow..."
+1, I'd like to know
00:26:55
Łukasz Rozmej:Replying to "Here is the breakdow..."
What is Bandwith?
00:27:23
Maria Silva:Replying to "Here is the breakdow..."
State Access is IO, State is state growth
00:27:40
Maria Silva:Replying to "Here is the breakdow..."
Bandwidth is call data (excludes blob)
00:28:05
Guillaume:Replying to "Here is the breakdow..."
so access also includes writes, but writes that are not growing the state ?
00:28:08
Łukasz Rozmej:Replying to "Here is the breakdow..."
got it, so post glamsterdam this will be highly domiated by State?
00:28:12
Ansgar Dietrichs:my understanding is actually that BALs benefit state access to a similar degree to compute.
compute: parallelization
state reads: batch reads
state writes: parallelized state root calculation
00:28:33
Toni Wahrstätter:Replying to "BALs will make compu..."
Numbers in some eips will need to be updated based on epbs+bal devnets
00:28:46
Stefan Starflinger:fyi :) - Glamsterdam devnet-1 has been launched https://dora.bal-devnet-1.ethpandaops.io/ https://ethpandaops.io/networks/bal-devnet-1/ gloas fork is in less than 3 hours.
00:28:51
Csaba:BALs transform state access cost into a networking cost, which contends with other network related cost components
00:29:13
Maria Silva:Replying to "Here is the breakdow..."
I split each opcode cost into the different components. For instance, SSTORE has a component for compute, state access and state growth
00:29:17
Luis Pinto | Besu:Replying to "BALs will make compu..."
True state access will be much trivial
00:29:22
Maria Silva:Replying to "Here is the breakdow..."
Here is the analysis: https://ethresear.ch/t/going-multidimensional-an-empirical-analysis-on-gas-metering-in-the-evm/22621
00:29:28
Guillaume:Replying to "Here is the breakdow..."
so acess is just reads, not IO
00:29:49
Maria Silva:Replying to "Here is the breakdow..."
SSTORE also contributes to state IO
00:29:58
Marius van der Wijden:Targeting 60MGas/s with repricings
Move EIP-7904: General Repricings to CFI
Move EIP-7976: Increase Calldata Floor Gas to CFI
Move EIP-7981: Increase access list cost to CFI
Move EIP-8038: State-access gas cost update to CFI
Discuss EIP-2780: Reduce intrinsic transaction gas on the call or postpone
Postpone the decision on State Growth to Jan. 5
00:30:04
Luis Pinto | Besu:Replying to "BALs will make compu..."
Thanks Toni, if we are taking info from devnets to reprice I’m happy with that
00:31:34
Ansgar Dietrichs:compromise idea:
downscope EIP to only performance floor for now
revisit later into fork process, if there is room we can add back a few high impact cost reductions
00:32:05
jochem-brouwer:Can give a workshop on writing these benchmarks also :)
00:33:00
Louis:Replying to "Can give a workshop ..."
I like the idea, I could help with this
00:33:10
Louis:Replying to "Can give a workshop ..."
I need to work on more documentation
00:33:11
Ahmad Bitar | Nethermind:why the 60M not 100M floor?
00:33:21
Guillaume:Replying to "Here is the breakdow..."
I'm trying to understand what you call IO and what you call state
00:33:35
Guillaume:Replying to "Here is the breakdow..."
because it's the same thing in my view, so I'm looking for the cut-off
00:33:49
Marius van der Wijden:Replying to "why the 60M not 10..."
100M would necessitate ~40 opcodes being repriced
00:33:58
Maria Silva:Replying to "Here is the breakdow..."
Maybe we can take this after? It is hard to explain in chat
00:34:02
Ansgar Dietrichs:https://notes.ethereum.org/@ansgar/glamsterdam-el-pfi-eips
00:34:06
Maria Silva:Replying to "Here is the breakdow..."
Let schedule some time to go over it
00:34:07
jochem-brouwer:Antwoord verzenden naar "Can give a worksho..."
We could setup a guide/workshop as an entry point to write benchmarks. I'll contact you :)
00:34:14
Maria Silva:Replying to "Here is the breakdow..."
Also, please read here: https://ethresear.ch/t/going-multidimensional-an-empirical-analysis-on-gas-metering-in-the-evm/22621
00:34:14
Ahmad Bitar | Nethermind:Replying to "why the 60M not 100M..."
yeah, but 100M was one of the goals for 2026, no?
00:34:25
Louis:Replying to "Can give a workshop ..."
Sure, I am interested in this
00:35:13
Pari:Replying to "why the 60M not 100M..."
60M/s no?
00:35:14
Marius van der Wijden:Replying to "why the 60M not 10..."
100MGas/s and 100M block are 2 different things. With 60MGas/s we can get to 180MGas blocks
00:35:24
Maria Silva:Replying to "why the 60M not 100M..."
Note that we are targeting 60M gas per second - so is ePBS gives us 6 seconds of execution, we get 60*6 =360 M gas limit blocks
00:36:02
Maria Silva:Replying to "why the 60M not 100M..."
Plus, the gains from BALs
00:36:23
Marius van der Wijden:I'm fine with CFI for 2780
00:37:16
Ameziane Hamlat:Besu is for CFI’ing 2780
00:37:43
jochem-brouwer:I think we should discuss these details async?
00:40:11
Ben Adams:Can we delay 8038 decision?
00:40:11
Pari:Round robin asking clients directly?
00:40:20
Marius van der Wijden:Well I already gave my take on it :D
00:40:48
Mario Vega:This one has a very high testing complexity: https://github.com/ethsteel/pm/blob/main/complexity_assessments/EIPs/EIP-8038.md
00:41:31
Marius van der Wijden:It needs to be done in my opinion if we want to get anywhere with scaling
00:41:34
jochem-brouwer:I think we should CFI it so this opens the road to change the state access costs
00:44:10
Luis Pinto | Besu:Lets go and we figure out right numbers after
00:45:13
Justin Florentine (Besu):sounds like the definition of CFI to me
00:46:28
jochem-brouwer:This is also a good note process-wise, to signal we consider this :) Thanks for that note
00:47:11
Ahmad Bitar | Nethermind:CFI
00:47:21
Ben Adams:CFI
00:47:29
draganrakita:CFI
00:48:55
Ansgar Dietrichs:so for now we would change the EIP to exclusively make (a handful of) operations more expensive, remove all cost reductions
and keep the option to add back some cost reductions later into the fork process if we have time
00:50:28
jochem-brouwer:I want to CC @Carl again, I think we should indeed change title to General compute repricing or something like this for 7904
00:50:33
Ansgar Dietrichs:the initial idea of 7904 was to get more compute for same gas limit
instead we now want same compute (except for a few bad cases) and more gas limit
00:51:14
Ameziane Hamlat:CFI
00:51:25
draganrakita:Imo having equalizing EIP for gas is important, be that by increasion some opcodes or reducing all by a fraction. CFI
00:52:22
Luis Pinto | Besu:CFI ‘ both
00:52:40
draganrakita:CFI
00:52:51
jochem-brouwer:Yer, lets deprecate it
00:52:57
jochem-brouwer:(access list)
00:53:23
draganrakita:Replying to "Yer, lets deprecate ..."
We are kinda discouraging its usage with this EIP
00:53:32
Marius van der Wijden:Replying to "This is also a goo..."
We should make sure that the set of CFI'd eips is not too large in order to be able to still prioritize resources
00:53:38
jochem-brouwer:Antwoord verzenden naar "Yer, lets deprecat..."
Yup :) So its a side effect of it, which is nice :)
00:53:56
jochem-brouwer:Benchmarks
00:55:05
Louis:Replying to "This is also a good ..."
I would like to know what benchmark scenario should testing team prioritize for benchmark.
00:56:01
Ansgar Dietrichs:I feel a bit like acd dictator with all these suggested decisions - so please do jump in if I ever steer things to a decision that doesn’t genuinely seem to be consensus
00:56:07
Guillaume:could they not be run on five different networks?
00:57:02
Marius van der Wijden:Replying to "could they not be ..."
Wdym? We are trying to run them on different networks, the problem is that the infra for running it is a bit jank at the moment
00:57:40
Marius van der Wijden:Replying to "could they not be ..."
Or do you think the three networks we're planning for are too much?
00:57:46
jochem-brouwer:H-star = Hogota :)
00:57:54
jochem-brouwer:Hegota*
00:58:10
Guillaume:Replying to "could they not be ru..."
I mean, if the problem is that it's slow so it can't be run 5x a day, maybe we can 5x the networks in parallel
00:58:19
frangio:"AA concerns" are more specifically ERC-4337 concerns, btw
00:58:22
Guillaume:Replying to "could they not be ru..."
just a random thought, not easy to do I know
00:58:30
Marius van der Wijden:Replying to "could they not be ..."
Ah yes, hopefully we will
00:58:49
Marius van der Wijden:DFI
01:00:25
draganrakita:What concerns AA has with transient storage?
01:01:40
frangio:for gas it's actually not even reliable. all of this needs to be reworked
01:02:34
Ansgar Dietrichs:then sounds like we should look into whether we can safely remove the cap in some way by Jan 5
01:02:40
Ansgar Dietrichs:Replying to "then sounds like we ..."
and delay decision today
01:02:47
jochem-brouwer:Antwoord verzenden naar "then sounds like w..."
yes agreed
01:02:56
jochem-brouwer:Antwoord verzenden naar "then sounds like w..."
So 7971 w/h limit
01:03:07
frangio:so this should be with the Repricing group?
01:05:13
draganrakita:True 🙂
01:05:17
Marius van der Wijden:dfi
01:06:15
Ben Adams:delay decision; so can consider new input
01:06:32
Marius van der Wijden:Thread: https://x.com/gballet/status/2001320602813022308
01:07:05
Maria Silva:100% Agreed with Guillaume
01:08:09
Ansgar Dietrichs:I personally would propose waiting with 8032 decision until Jan 5, to have better state benchmarks.
those better benchmark numbers will tell us how harsh the state access cost increases will be without this EIP, which will inform the urgency here.
01:08:14
Maria Silva:8038 has a section on how it can be complemented with 8032: https://eips.ethereum.org/EIPS/eip-8038#interaction-with-eip-8032
01:09:04
lightclient:does delay mean CFI?
01:09:43
Ansgar Dietrichs:we have not made any SFI decisions beyond headliners
01:09:49
Ansgar Dietrichs:Replying to "we have not made any..."
CFI is already strong signal
01:10:08
Marius van der Wijden:Replying to "does delay mean CF..."
Also delaying to Jan 5. gives us a better overview of the scope of the CFI'd eips and if we still have space in the fork
01:10:40
draganrakita:Would DFI it bcs of migration concerns
01:10:41
Charles:sorry guys just joining -- i thought we just started (time zone confusion)
01:10:59
Wei Han Ng:Replying to "Would DFI it bcs of ..."
what's the exact concern that you have?
01:11:05
jochem-brouwer:Antwoord verzenden naar "does delay mean CF..."
Good point, also regarding interactions with these EIPs which might not directly be clear
01:11:30
draganrakita:Replying to "Would DFI it bcs of ..."
Migration is something that was never done
01:11:35
Marius van der Wijden:Replying to "sorry guys just jo..."
fyi we have DFI'd the evm memory limit eips
01:11:53
Charles:ack
01:12:20
Marius van der Wijden:Replying to "sorry guys just jo..."
There's only so much space we have in a fork :(
01:12:26
Luis Pinto | Besu:Would also postpone to January, but it looks important to bring root hash computation complexity into the protocol
01:12:29
Wei Han Ng:Replying to "Would DFI it bcs of ..."
this particular migration is much simpler than the verkle one, and verkle migration has worked and tested before
01:12:57
jochem-brouwer:I think this iterator is less complex than we might imagine. But thats coming from prototyping 😅 I think we can setup tests just like everything else, and make something which looks complex actually less complex.
Some EIPs look simple, but are more complex than we think. Some EIPs look complex, but are actually "simpler" than we might imagine beforehand
01:13:00
Ansgar Dietrichs:could we ask the testing team to make a testing impact assessment by Jan 5? obv might not be possible for them with holidays in between
01:13:02
Marius van der Wijden:Replying to "sorry guys just jo..."
The decision for Limit for transient storage is delayed until Jan 5. in order to see if we can get rid of the hard cap
01:13:33
Karim T. (matkt):Do we have a thread to talk about that on discord ?
01:13:34
Łukasz Rozmej:I know it can be done. Question is it worth the complexity to stay forver in protocol and bandwith for Glamsterdam.
01:14:10
Guillaume:Replying to "I know it can be don..."
in protocol, I'd say yes because it's going to be reused later :D
01:14:17
Charles:i have argued against eip-8024 and for eip-7923 here btw: https://ethereum-magicians.org/t/eip-8024-backward-compatible-swapn-dupn-exchange/25486/3
01:14:36
Łukasz Rozmej:Replying to "I know it can be don..."
How many Trie migrations do we need? :)
01:14:42
Mario Vega:Replying to "could we ask the tes..."
Transition is hard, regardless of whether has it been done already, our testing framework has to be updated to account for forks that have a transition period, we had a prototype for verkle yes, but having a prototype is one thing and having all tests updated and compatible is a different one
01:14:44
Łukasz Rozmej:Replying to "I know it can be don..."
Can it wait for binary tries?
01:14:55
jochem-brouwer:Why 2926 already DFId in this doc?
01:15:11
Josh Davis:Replying to "Why 2926 already DFI..."
“Candidate”
01:15:33
jochem-brouwer:Antwoord verzenden naar "Why 2926 already D..."
Yeah sorry, I meant `DFId?` in this doc 😅
01:15:49
Justin Florentine (Besu):Replying to "Why 2926 already DFI..."
first mover advantage, mostly
01:16:04
Marius van der Wijden:I like 2926 as well
01:16:08
draganrakita:You are wrong
01:16:19
Greg K | Lido:Lido supports 7907: https://github.com/ethereum/pm/issues/1837#issuecomment-3669452216
01:16:26
kev:It addresses some prover killers to be clear
01:16:27
lightclient:2926 gud
01:16:33
Luis Pinto | Besu:2926 fixes a root problem with code access in protocol
01:16:34
Danno Ferrin (Tectonic):Lido also opposed 2926
01:16:44
Ansgar Dietrichs:in terms of opposition: Besu and Erigon had 2926 listed as DFI preference
01:16:50
Łukasz Rozmej:After Verkle everything will seem simple ;)
01:16:50
lightclient:7907 is much harder than we make it out to be
01:17:04
Marius van der Wijden:Replying to "Why 2926 already D..."
Ansgar compiled the list from comments on the last ACDs as well as the preference documents of the clients
01:17:19
Charles:Replying to "sorry guys just jo..."
eip-7923 is not a large change, it's designed as just a pricing change
01:17:37
draganrakita:Reth marked it DFI too
01:18:41
Ansgar Dietrichs:we have 3 of 5 clients signalling for DFI on 2926. I have a hard time seeing a path for inclusion unless they change their mind
01:18:43
Mario Vega:Replying to "sorry guys just join..."
It’s a large testing change, a lot of tests expand the memory and we have to go back and see that we don’t break them
01:20:11
jochem-brouwer:Antwoord verzenden naar "Why 2926 already D..."
Alright, yes sorry about this comment, my personal perception was that this was "less DFI candidate" than I get from the actual analysis, so I understand now why it is listed here as-is :)
01:21:56
draganrakita:EIP-7907 gives u 80/20 benefit on contract size, so this is why we support its inclusion.
01:22:12
Somnath Banerjee:Here's an unpopular opinion: Use ssz inside state MPT
01:22:37
Ansgar Dietrichs:this is pushing my limited acd host skills - seems like an impass, 2 clients for one EIP, 3 for another. how to resolve?
01:23:27
Marius van der Wijden:No progress, DFI both?
01:23:43
Ahmad Bitar | Nethermind:Replying to "No progress, DFI bot..."
We really need to solve the contract size limit
01:23:55
lightclient:Replying to "No progress, DFI bot..."
2926 actually solves it though 🙁
01:23:57
Charles:doesn't 2926 have some other problems like messing with code locality
01:24:09
Karim T. (matkt):DFI 2926 it’s only because of bandwidth ? Imo if it’s because of bandwidth we should DFI the two no ? And see for the next fork
01:24:17
Pari:Replying to "this is pushing my l..."
Ask what pieces of data would help clients decide for one or the other, i.e what info would move the needle?
01:24:27
Guillaume:Replying to "doesn't 2926 have so..."
nope, on the contrary
01:24:30
Ahmad Bitar | Nethermind:Replying to "No progress, DFI bot..."
im just arguing against DFIing both. i dont have a preference as i haven't personally checked them
01:25:00
Charles:Replying to "sorry guys just jo..."
are there any objections besides testing change size?
01:25:43
Charles:Replying to "doesn't 2926 have ..."
can you explain? doesn't a lookup happen every 32 bytes?
01:27:20
Ansgar Dietrichs:last time we did not discuss this EIP at all
01:27:23
Justin Florentine (Besu):he's not making it, he's citing client team prefs
01:27:50
Ansgar Dietrichs:Replying to "he's not making it, ..."
right, that’s what I was trying to say at least
01:29:01
draganrakita:We are all making our best guesses with knowledge that we have
01:29:27
Guillaume:Replying to "We are all making ou..."
I suggest you try to get more knowledge on that eip then
01:30:42
Somnath Banerjee:"You can please some of the people, some of the time", Steve Jobs
01:31:23
draganrakita:Replying to "We are all making ou..."
I did read it, I didn’t say it is wrong or bad, but it is too complex for Glamsterdam or for benefits it offers
01:31:41
Josh Davis:CFI
2780
8038
7904
7976
7981
DFI
7686
7923
7973
2926
Delay
8037
7971
01:33:03
Charles:i'd like to request reconsideration of 7923, it's a stronger EIP than EIP-8024 (imo) and it's very useful for users that i think is not well understood by client teams
01:33:28
jochem-brouwer:I want to add here, the code size increase for both 2926 and 7907 also has interactions with the gas repricing for the state. So from that perspective, it would make sense to reconsider this in Hegota
01:34:15
jochem-brouwer:However, also want to add that we need code size increase as the community strongly signals that this is necessary
01:34:32
lightclient:one more one more!
01:34:43
lightclient:christmas miracle!
01:35:02
Justin Florentine (Besu):Replying to "one more one more!"
portlandia reference detected?
01:35:28
Justin Traglia:Bye everyone
Summary
10 highlights
· 3 decisions · 4 action itemsExperimental
Summary
10 highlights · 3 decisions · 4 action itemsExperimentalfork status and schedule
repricing updates
testing progress
Decisions
Action Items
- All teams: Review zkEVM roadmap and provide feedback in ETH R&D L1ZKVM channel00:05:39
- nixo: Publish Hegotá timeline as blog post00:10:32
- Benchmarking team: Complete state benchmark infrastructure for mainnet/2x/4x snapshots00:54:15
- Client teams: Review Guillaume's Twitter thread on EIP-8032 transition mechanism01:06:15