Ansgar Dietrichs:Awesome. Well… Welcome, everyone, for…
Transcript
Ansgar Dietrichs:for AllCoreDevs, 223. It's gonna be a while until we have a nice number again.
Ansgar Dietrichs:Yeah, this one will, I think, be primarily all about, Glamsterdam…
Ansgar Dietrichs:EIP planning, but before we get into that, we do have a few Fusaka-related points, again. So, to start us off there, we have Barnabas with a quick
Ansgar Dietrichs:update on the Sepolia BP01 and 2 situation?
Barnabas:Yep, hi everyone. So, Fusaka DevNet 3 is still ongoing. We have 99% participation. Every single client combination is working just fine now.
Barnabas:We rolled out the latest Lighthouse image, and that solved all of our bugs as of now.
Barnabas:Tepolia had their BPO activated.
Barnabas:2 days ago, we went up to max blobs of 15, and the next BPO will be in 4 days and 9 hours.
Barnabas:The next fork will be,
Barnabas:than the Hudi network, which will get its, Fusaka update in 5 days and 4 hours.
Barnabas:And then the first BPO will be in approximately 2 weeks from now. And, in 19 days BPO, too, on Houdi.
Barnabas:everything went smoothly on BP01, and we expect a smooth transition on Hoodie as well. If you're running a Hudi validator, please make sure that you update your node, as there's only 5 years left now till the fork.
Barnabas:That's about it for the testnets.
Ansgar Dietrichs:Thank you, and it's great to see that it's going so smoothly.
Ansgar Dietrichs:Is that… were there any comments? Did anyone have anything specifically regarding the testnets, regarding Sepolia, or the upcoming HUDI?
Ansgar Dietrichs:Folks that they wanted to discuss?
Barnabas:Maybe just one more, point. Pulaski is officially going away next week.
Barnabas:It's already seeing some drop in participation. We are close to on finalization at this point. We are at the low 70s.
Barnabas:So, if you're running a host key validator, just keep it up, till you can, and then we're gonna be officially shutting it off next week, Friday.
Barnabas:And if you're listening, and you still have infrastructure running in OSCI, please migrate to Polia or Houdi as soon as possible.
Ansgar Dietrichs:Yep, perfect. That… thank you for that,
Ansgar Dietrichs:Yeah, and so if anyone still has anything on their bucket list that they really wanted to get done on Holsky, now is your time.
Ansgar Dietrichs:Okay, then next up, with everything going so smoothly, Alex wanted to talk about, mainnet dates.
Ansgar Dietrichs:Alex, do you want to start us off? We then have a few comments to go through.
stokes:Yeah, definitely. So, last week, let's see, let me just make sure I have the right dates here…
stokes:So, essentially, the proposal would be to follow, this document from Barnabas, which I can drop here in the chat, one second.
stokes:And what does that have? So it has, mainnet for Fusakra on December 3rd. You can look at the Bakken slot there in the dock.
stokes:BP01 and 2 on December 9th, and then on January 7th, respectively. So…
stokes:We brought this up on last week's ACDC as sort of a temperature check, and…
stokes:Was I… are you talking about the doc part of this? I just saw the chat here.
Barnabas:Yeah, so the original, BF01 proposal was the 17th of December, and we have… there was a bit of pushback from different client teams, saying that the 17th of December falls a bit too close,
Barnabas:to Christmas and the holidays.
Barnabas:So we decided to, propose the 9th as BPO1.
stokes:I see, okay, so the dock hasn't updated, but yeah, it was moved from last time. Okay, thanks for calling it out.
stokes:But yeah, so then check the doc for the latest times, but, yeah, long story short…
stokes:We did, like, a temperature check, last call. People were generally on board, so I wanted to do the same thing here.
stokes:So, I think one caveat is if we follow our process doc, I think, you know, when reading, it says basically we would wait to officially set these dates.
stokes:Until Hoodie has finalized, which will be next week.
stokes:That being said, if we want to go with the schedule, the timing's pretty tight, and so…
stokes:That would ultimately look like client releases on… I believe that's November 3rd, so one week before… or sorry, one month before the proposed mainnet date.
stokes:And just given the timing, it makes sense to go ahead and get this on people's radars now.
stokes:yeah, I would like to go ahead and see what people think about this here. Generally, I'd say from the CL side, we're gonna go with these dates.
stokes:If we're good to go from the EL side, which we can, you know, assess on this call right now.
stokes:then I would say, you know, basically we'll do this, we can follow our process and go ahead and confirm, officially on next week's ACDC.
stokes:But, wanted to go ahead and get this on people's radars, just so they're aware, because, yeah, you know, you'll have more time to get a release together if you're a client team.
stokes:And I guess, final note, this is all conditional on hoodie going well, so again, if something doesn't for some reason, then yeah, we'll have to adjust. But so far, it's been going well, and it seems like we can pull this off, so…
stokes:That's my spiel, and I'd love to hear from any EL teams or anyone else on the call, what they think about this.
Ansgar Dietrichs:Yeah, perfect, thank you. We already have a few comments in the chat from Lukash and Marius.
Ansgar Dietrichs:Plus running.
Ansgar Dietrichs:Anyone else with comments on…
Ansgar Dietrichs:This…
Ansgar Dietrichs:So maybe if we briefly just…
Ansgar Dietrichs:Check, go through the… the client teams,
Ansgar Dietrichs:to see, is there… is there anyone from Reth on the call with an opinion on this? Do these dates look reasonable from your side?
Jen:Yeah, looks good.
Ansgar Dietrichs:Sounds good. And from the peso side?
Justin Florentine (Besu):No issues here.
Ansgar Dietrichs:Awesome, and Aragon?
Andrew Ashikhmin:Yeah, sounds good.
Ansgar Dietrichs:Okay, did I miss any client?
Ansgar Dietrichs:I don't… I hope so.
Ansgar Dietrichs:You know, please, no more clients, I need one hand to count, and so this is great.
Ansgar Dietrichs:Okay, then when we… yeah.
Ansgar Dietrichs:Alex, you already mentioned that, basically, because there was also some discussions in the issue, Andrew mentioned that, yeah, the process specifically would then officially only make these dates, let us set these dates next week, but basically the idea is we pre…
Ansgar Dietrichs:Pre-committing to this timeline, assuming, hoodie goes smoothly.
Ansgar Dietrichs:Perfect. We will, a bit later on, talk about the GlumSlam EAP process, because then the question is also, does this then today already trigger the deadline for ERP proposals? So that would mean,
Ansgar Dietrichs:now would be the last week that would start today, basically, for your pre-proposals, but let's get into that once we get to Amsterdam.
Ansgar Dietrichs:which actually we will do immediately now. So, any last comments on the actual timeline?
Barnabas:Just one mention that I've proposed to basically clarify the mainnet update requirement, instead of maintenance should not have an upgraded set until all testnets have been upgraded, to manage should not have an upgrade date set until at least one testnet has been upgraded.
Barnabas:I'm just curious what everyone thinks of this.
Barnabas:I posted the PR for that, in the chat.
Barnabas:Continuity.
Barnabas:So this would basically allow us to schedule, the mainnet right now.
Ansgar Dietrichs:Put us?
potuz:I'm not against this, but one issue that this raises is that our users might update the client.
potuz:With a testnet release that has the mainnet date.
potuz:But it's not really considered to be a mainnet release. Like, we are still releasing things, even though we've already been through a couple of testnets upgrades, and we still find bugs.
potuz:And clients that, if we go with this thing of, like, setting a date well in advance after just one testnet upgrade, we might see users that haven't really upgraded to the actual mainnet release with all the bug fixes.
Ben Adams:Yeah, we don't need to put the dates in a release until… Closer to the race.
Ben Adams:If that makes sense.
Barnabas:Yeah, it's… it would still be up to the clients when they want to back in the data.
Barnabas:It's just that we could officially schedule today.
stokes:I guess one note is, I believe there's an escape hatch in this document. Let me go see if I can find the text, but basically it just says, like, you know, this is all subject to change at the whims of…
stokes:ACD. The thing with this is that…
stokes:it doesn't say which testnets, and, like, I think not all of them are created equal, essentially.
stokes:But yeah, I think we could go either way.
Ansgar Dietrichs:Is this something that we'd prefer to make a decision on today, on the call, or would we rather take that discussion offline?
Marius van der Wijden:I…
Marius van der Wijden:I prefer to set the date more in advance and have, like, people know the date, rather than following some arbitrary document that someone drafted up a long time ago.
Ben Adams:Yeah, I think…
Marius van der Wijden:Basically, predictability for the ecosystem.
Ben Adams:I think POTUS's concern is addressed by not
Ben Adams:Putting the dates into an actual release.
Ben Adams:Until later.
Ben Adams:Would that be correct, buddy?
potuz:Yeah, so the… I mean, there are other issues, too. Like, on P2P, you advertise, when you have the next fork epoch, you change your ENR and a bunch of things,
potuz:So the fork schedule changes, and this changes the configuration of clients, so we might have clients that are already announcing what the next fork is, and some clients that don't. It's not really a serious problem, it's just something to think about.
Ansgar Dietrichs:So could it make sense to have, like, an explicit decoupling of these two, points in time in the document? That we basically, like, we go with this proposed change, in terms of the…
Ansgar Dietrichs:deciding the dates, but then we specifically, explicitly, like, use the old mechanism for…
Ansgar Dietrichs:To say, basically, only after the last testnet do we have client releases, or would that not make sense?
stokes:Yeah, I think that could make sense. I don't see what it's going to change today, so then perhaps we just take this discussion async to the PR, and we can cover it next week's call.
stokes:After people have chimed in there.
Ansgar Dietrichs:Yeah, that sounds good to me.
Ansgar Dietrichs:Any last comments on it right now, or…
Ansgar Dietrichs:Ready to move on?
Ansgar Dietrichs:Okay, then, I mean, the chat remains open.
Ansgar Dietrichs:Awesome. Then, I think we are ready to move to, Glamstadam. Before we get into the entire EAP side of things, I just wanted to briefly check, is there any specific DevNet updates, anything that…
Ansgar Dietrichs:Happened, recently that people wanted to briefly talk about?
Ansgar Dietrichs:Yeah, sorry, when I said definite, more like work towards definites, that's, I should have been a bit more precise.
Ansgar Dietrichs:Okay, no problem. Alright.
Ansgar Dietrichs:Oh, yeah.
Barnabas:We have, local access list, crypto assist that's running locally, and,
Barnabas:We are still iterating towards the…
Barnabas:a staple DevNet. Hopefully, maybe tomorrow or early next week, we can launch, local access list DevNet Zero.
Ansgar Dietrichs:Awesome. That's very exciting. Good.
Ansgar Dietrichs:Then… see, that's good context for us to go into.
Ansgar Dietrichs:Into the governance discussions, that there's already real nice progress.
Ansgar Dietrichs:Alex, you had a comment on the issue. We discussed over the last week the process for
Ansgar Dietrichs:From now onwards, now that we're getting close to the…
Ansgar Dietrichs:To the proposal deadline, how we want to go about
Ansgar Dietrichs:the non-headliner EAP discussions. Do you want to summarize that?
stokes:Sure, yeah. So, yeah, I mean, I think this is our first time through this headliner process, and I think this transition wasn't exactly as concrete as it could be, so…
stokes:To that end, just giving, like, an actual sort of schedule here,
stokes:Yeah, again, like Ansgar was saying, it seems like we can go ahead and start thinking about Amsterdam, not headliners.
stokes:And the sort of next milestone we had set is, you know, once we had agreed to Mainnet, then we'd have one week after as a deadline for proposals.
stokes:And…
stokes:again, it sounds like we'll confirm, quote, officially, these dates next call, but I think we're at a place where we can go ahead and do that. And again, that being…
stokes:Saying any non-headliner EIPs need to have been proposed for Amsterdam, with deadline one week from today. So, consider this your one-week call to do that.
stokes:There's already actually…
Ben Adams:I have a concern on that.
Ben Adams:deadline, just due to the… due to the process of EIPs, so they have to go through the… is it the EIP office editing hours, if it's a new EIP?
Ben Adams:And next week is…
Ben Adams:ERCs and the week after is EIPs. If anybody wants to propose a new EIP, they're unlikely to get it in. Now, they're unlikely to get it in by next week deadline.
stokes:Fusion.
Pooja Ranjan:I just want to add a small point here. Next week is not ERC only, it is EIP plus ERC. We generally try to keep ERC one alternate week, but EIPs are all the weeks, so if there is anything, we can definitely add it on the agenda, and we can get it merged.
stokes:Okay, this was news to me, so…
stokes:Okay, you're saying you have to go to the EIP editing office hours call to get an EIP arched? A new one?
Ben Adams:No, no, it's just… it's just the schedule on getting new ones merged isn't…
Ben Adams:I think, like, a two-week deadline would be… would be better.
Ben Adams:From now, since that date is forward.
stokes:Okay, I don't really see the link there.
stokes:People not propose, and then…
Ben Adams:Yeah, but… you can't… you need the EIP numb numbered and merged, and then put in the proposal EIP.
Ben Adams:There's, like, it's…
stokes:Right, but I guess you're saying that they only hand out numbers if you show up to this call? That's the part I wasn't aware of.
Ben Adams:No, no, I'm saying if you… if you're trying to, yeah, what I'm saying is it's not… it's not instant. If you…
Ben Adams:EIP in today.
Ben Adams:You know, you won't necessarily… Be able to have it merged and in… The matter… EIP.
Ben Adams:By… next week.
stokes:Okay.
stokes:Yeah, I guess I'm kind of wondering about this, and would echo Barnabas here in the chat, like.
stokes:I think we can assign numbers as soon as there's a PR, and then…
stokes:even if that PR is not merged, you could make yet another PR that puts the number into the meta-EIP.
Pooja Ranjan:I… if I'm… I'm sorry, Anskar, your hand is there, so if you want to…
Ansgar Dietrichs:Yeah, I just wanted to briefly, say that I think we should also be…
Ansgar Dietrichs:to me, the deadline is really more about basically signaling your, the proposal intent, so if someone basically gets, like, if they don't yet have a number signed, or they have a number signed, but they don't figure out how to do the PR against the meta EIP before the other one is merged, or whatever, and they end up just commenting on the… on next week's ACDC issue with the intent to propose the EIP,
Ansgar Dietrichs:anything like this, I think as long as it's clear that an ERP is proposed, basically by a week from now, I personally would not
Ansgar Dietrichs:Mind counting that against the deadline.
Ansgar Dietrichs:Given that it's a bit of a… Yeah, more symbolic.
Ansgar Dietrichs:Point in time, anyway.
Ben Adams:Yeah, okay, that's… that's fine.
Pooja Ranjan:That's very helpful.
stokes:Yeah.
Pooja Ranjan:I would echo with Emska here, but generally, speaking, getting back to Ben Adams' point, I think it would be a good idea to give a two weeks timeline for any new author to propose anything, like, at least getting the PR merged, as in draft format, but, as it is also mentioned in the chat, generally speaking, we get the number almost the same day, and we can use that number, we can use that number against the meta-EIP as well.
Pooja Ranjan:We can perhaps update it later on.
stokes:Okay, so then I'll amend this to say, yeah, like, even…
stokes:just a PR to the IP repo would count, and we can sort out the governance stuff, you know, in parallel, if we need to.
stokes:But I would prefer to keep things moving here, just…
stokes:to keep, yeah, keep things moving. Otherwise, yeah, it'll just spill out further in time.
stokes:And, you know, one reason why is the next point, which is that,
stokes:yeah, because of this, then we can move to, you know, discussing the different EIPs.
stokes:There are a large number of ELEAPs to go through, so we'll need to reason about that.
stokes:There's fewer on the CL side, so it should be easier, but, towards that end, I think having…
stokes:Some sort of document of clients and opinions, like we've done in the past, would be really useful.
stokes:And even if it's, like, higher level, like, you know, I don't know if people are gonna necessarily have a view on every last EIP, but even, like, directionally with themes would be good, and I think that will help, you know, us here, as we go over the next couple calls, sort through all the different EIPs.
stokes:I would propose, then, that clients try to get such lists out by, like, November 6th, and then I think that's an ACDE date. Let me just double check.
stokes:Yes, it is. So…
stokes:having that ready, and then that basically gives us the rest of November to go ahead and sort through everything.
stokes:Then we can finalize the Glamster Dam scope, by November.
Ansgar Dietrichs:Right, and just to give a little bit of context for this, because if someone hasn't checked, if some of you haven't checked the PFI list for a while, we have currently… well, it's a bit in flux, and we'll hopefully be able to, later on this call, to remove
Ansgar Dietrichs:up to 2 EIPs from it, but we are roughly 30… at 30 proposed EAPs.
Ansgar Dietrichs:Out of those 30, it's exactly 2 C outside EIPs.
Ansgar Dietrichs:Plus you can count fossil, but fossil is already CFI'd, so… so we have three CL-side ERPs. There might be one more coming, I heard. But basically, then we have
Ansgar Dietrichs:27, 28, outside EAPs, so the, it… there's, like, a very big asymmetry, also in terms of the… the amount of work to just…
Ansgar Dietrichs:go through for client teams, and even as Alex was saying, even if, say, a full-on EIP by EIP, yes-no opinion is, I think, not really necessary for the first round of…
Ansgar Dietrichs:documents with opinions, but even just in terms of having ideas of, like, what themes, what rough scoping, these kind of things, it will be more effort for ELDF, so I think you should be aware of that when we discuss timelines.
Ansgar Dietrichs:That said, yeah, what do people think about Alex's idea to basically have, a first round of
Ansgar Dietrichs:People going over the EPs, forming opinions, communicating them over the next two weeks.
Ansgar Dietrichs:Does that sound realistic?
Łukasz Rozmej:Well, it sounds a bit aggressive if there are 20 ATIPs, but we'll see what we can do.
Justin Florentine (Besu):Yeah, I'm kind of thinking the same thing. Feels a little tight, I think one more week would be totally doable, but I don't super strongly hold that opinion.
Ansgar Dietrichs:Yeah, Alex and I were going back and forth about this as well. Obviously, the problem is that, these documents really only make sense for an ACDE, so then the question would be 2 weeks, or then otherwise 4 weeks, really.
Ansgar Dietrichs:And 4 weeks gets us basically exactly to the, to the ACDE that is right during DEF CON.
Ansgar Dietrichs:I don't think we've decided yet whether we'll skip that ACD or not, but either way, it doesn't feel like an ideal.
Ansgar Dietrichs:point either, and then otherwise, we only really, have time towards the end of the year, so it feels like it would be really, really nice if we could make two weeks from now happen, even if, again, like, I think given the number of EIPs, we… it would be understood that it's much more of a coarse view of
Ansgar Dietrichs:Like, just some basis for discussion, that people basically come into it with some clear idea, at least, of
Ansgar Dietrichs:how they feel about the general list. Not so much, like, a super detailed opinion, ERP by ERP.
Ansgar Dietrichs:But also, we do need to make realistic plans. So the question is, like, yeah, do people think that even if not ideal, that can work, or is it just unrealistic in two weeks?
Łukasz Rozmej:I think it can, we just need to schedule it, and yeah.
Łukasz Rozmej:So, hopefully, yes.
Ansgar Dietrichs:Okay, anyone that really hates this? Otherwise, I do think we should probably look in that approach.
Ansgar Dietrichs:Okay, yeah, Alex, I think then we can say we continue with that, and we say that,
Ansgar Dietrichs:for… can you maybe clarify also, Alex, for the two weeks from now? Is that just for the EL client devs? How does that… I mean, again, the CL side is much more comfortable, but how would that map to the CL side?
stokes:Yeah, I mean, if… if client… if, like, a CL client team finds it useful, then, you know, by all means, I think that would be good.
stokes:But yeah, there's really only, yeah, like, 3 or so.
stokes:CLEIPs, so I feel like we could probably just cover them in turn.
Ansgar Dietrichs:Okay, yeah, then… so then we just make… specifically make it a process point for the EL site. So, then…
Ansgar Dietrichs:I'll also try to do some shepherding, reach out to you all.
Ansgar Dietrichs:I also had a plan separately to, to, maybe with a few colleagues from the research side, have a few thoughts, published.
Ansgar Dietrichs:I just didn't want to do it before this call, because obviously there's always this tension between me as a coordinator and me also sometimes having opinions, so if you see opinions of mine over the next week or so, make sure that that, yeah, that treat them as just, like, as a researcher opinion or not a coordinator opinion.
Ansgar Dietrichs:But yeah, then let's… let's lock in the process, and so on ACDE, in two weeks, we will, hopefully have at least some general, like, documents from… from… from each
Ansgar Dietrichs:Yale client with, with, with, a take on how we should go about these, PFI ERPs?
Ansgar Dietrichs:And then we can kind of dive into the details there.
Ansgar Dietrichs:Lucas?
Łukasz Rozmej:Could we also give opinion on CFI TIPs?
Ansgar Dietrichs:So you're asking specifically about fossil there? I think that's the only CFI DRP that we have?
Łukasz Rozmej:Oh, okay. Yeah, sure, so… Yeah, because, like…
Łukasz Rozmej:You know, we can weigh which ones we want more or less, right? So fossils should also be on this list where…
Ansgar Dietrichs:Yeah, that's a good clarification. I do think, yeah, I would include fossil in the scope.
Ansgar Dietrichs:That makes sense.
Ansgar Dietrichs:It is, of course, primarily, I think, implementation overhead-wise, as seal-heavy, but I think governance side, it makes sense to have it covered on both.
Ansgar Dietrichs:I'm trying to also follow along with chat.
Ansgar Dietrichs:I think… I guess there is a suggestion of whether we can repurpose out of the order, basically, like, one…
Ansgar Dietrichs:CL site call, ACDC for some EL… Work, basically.
Ansgar Dietrichs:Does anyone want to…
Ansgar Dietrichs:Briefly talk about that idea?
Barnabas:So instead of waiting just…
Barnabas:for nothing, we should probably just go through all the EL EIPs, in an ACDC call, or just rename that one call to ACDE, so that we can have all the EL devs show up as well.
Ansgar Dietrichs:That seems reasonable, and would that be then… I assume that wouldn't really make sense for next week already, because, I mean, A, that would be a bit short notice, and B, that would be before even that initial deadline, so is that more maybe for the one in three weeks, then?
Ansgar Dietrichs:M.
stokes:I also think we should get through all the CL stuff first, like…
stokes:if we happen to, you know, get through all the seal stuff, and it's good, then yeah, if there's, like, if it makes sense, we could…
stokes:Swap one of the calls.
Ansgar Dietrichs:Okay, so then you're saying this is better discussed on an ACDC call, if it…
stokes:Well, I think more just we might need a little more time, like…
stokes:I think it's just a, yeah, one or two calls early to say we're gonna need that.
Ansgar Dietrichs:Okay, so, Ben, let's bench this for now, maybe? Oh, Ben, do you have a comment on this?
Ben Adams:Yeah, we often have extra time in ACDT also. I mean, we could maybe use that as well.
Ben Adams:Just gives us… That's a large volume.
Ansgar Dietrichs:Sounds good. So then, but do we all agree that that's all more for, like, basically after that initial two-week period, or would, basically, does someone want to basically try to, like, allocate some specific time, ACD-related time, over the next two weeks already for some specific discussion?
Łukasz Rozmej:I would say after.
Ansgar Dietrichs:Okay, then, it's a good idea, and we can already, like, explore basically what kind of the…
Ansgar Dietrichs:We have there, but yeah, let's then discuss in two weeks.
Ansgar Dietrichs:Any kind of extra, opportunities for discussion.
Ansgar Dietrichs:Is there… I also saw in chat the question, basically, for any EIP champions that have ERPs proposed, is there anything they can do, basically, like, over the next two weeks to make the ERP maximally legible, to basically make it easier for people as they go through the list to understand
Ansgar Dietrichs:kind of the positioning of the EIP.
Ansgar Dietrichs:Anything like that?
stokes:this might be a little tangential, but I just, want to call out Marius's comment here in the chat. Essentially having, like, a DFI section on a client team list would be very helpful.
stokes:Just, you know, if there's things we know we don't want, then we can just acknowledge that and hopefully cut down the list.
stokes:Pretty quickly.
Justin Florentine (Besu):Real quick question. How complete is our list of champions for the EIPs? That would be a great way for folks to reach out and come to this meeting with specific questions that they have on each one. Is that…
Justin Florentine (Besu):Gonna be good to go and useful for people?
Justin Florentine (Besu):Almost fully complete. Yes, Josh, thank you.
Ansgar Dietrichs:And Josh, I think my understanding is that the one ERP that's missing a champion, we also have that on the agenda for today, right? I think that might actually get removed anyway, unless you're talking about a different one.
Ansgar Dietrichs:Yeah, perfect.
Ansgar Dietrichs:Justin, did you mean that we should have encouraged the ERP champions to specifically all show up in two weeks, or was that not what you were trying to say?
Justin Florentine (Besu):what I was trying to say was that,
Justin Florentine (Besu):the AIP champions and being able to contact them is a key part of the pre-work, so that we can limit the discussion to specific questions that folks have for each EIP.
Ansgar Dietrichs:Okay, yeah, so basically, like, just, this is… this is a call to all the EAP champions. Please make sure you are very available over the next two weeks, if you want to give your EAP the maximal chances, people might specifically have questions.
Ansgar Dietrichs:I might try to reach out to you, make that as easy for people as possible.
Ansgar Dietrichs:Okay, Alex, other than the specific, kind of, two weeks from now, documents, process, was there any other specific.
Ansgar Dietrichs:like, proposed action item from your process overview? Or would we just then take everything else as we go?
stokes:I think that's it, yeah. I mean, again, I just… the…
stokes:core constraint, let's say, is I would like just to have this settled by the end of next month.
stokes:And yeah, I think, having, you know, written views as soon as possible will help people make progress, throughout the next month, and definitely, yeah, you know.
stokes:we are, quote, twiddling our thumbs on the CL side, we can offer some time to keep the discussion going.
stokes:So yeah, we'll see how it goes. I mean, hopefully it's pretty streamlined, and yeah, we won't need to…
stokes:Make that many adjustments, but yeah.
stokes:Otherwise, let's take it as we go.
Ansgar Dietrichs:Sounds good. And then one more comment from my side there, it would also be nice, given that the ACDE in two weeks, again, is, like, right in the middle of the DEFCON week, if maybe people make sure that they internally discuss with their team, so that, like, on next ACDE, we can talk about what we do with that call, do we keep it, do we…
Ansgar Dietrichs:remove it. Obviously, that would then, also inform the general discussion of whether we can find some alternative, kind of.
Ansgar Dietrichs:call opportunities, for… for ERP discussion, yeah, I think that would be… Very useful.
Ansgar Dietrichs:Yeah, with that, any… anyone else that… I mean, I see there's an active chat discussion, I'm sure there's going to be a lot of offline discussion as well. Is there anything, still on this… around this general process question that… that we should synchronously discuss now?
Ansgar Dietrichs:Okay, then I think we can go… to some…
Ansgar Dietrichs:more general EIP, glam system EIP housekeeping. We might have the list grow or shrink a bit more over the next few minutes, so let's all hope for the best, hope for more EIPs being removed than added.
Ansgar Dietrichs:But with that, Maria, you had two repricing-related topics you wanted to touch on?
Maria Silva:So the first one is a quick one. So, on, following this discussion, I, I posted here on…
Maria Silva:on the issue, a proposal for adding to breakout calls, to discuss repricing EIPs. So, of the 31 EIPs, a lot of them are repricings, and they have some, technical details that are not just,
Maria Silva:changing parameters, some are simply
Maria Silva:changing some… some numbers, but there are others that are more… have more, depth, let's say. And so I think it would be useful to have, two additional breakouts where we kind of deep dive on all the EIPs. We discuss
Maria Silva:potential issues, and then, we can have some sort of, early…
Maria Silva:signaling on prioritization and understanding if things make sense. And the proposal would be to have it on Wednesday.
Maria Silva:At 3 UTC, so we do next Wednesday, and then the Wednesday after.
Maria Silva:And then after that, we can, come to ACDE, with an overview of key takeaways from that. So yeah, so I'm proposing it. I think it would be useful, but I want to know if
Maria Silva:folks that are interested in these find it useful, because if we're gonna have attendance in those breakout rooms, they are not as interesting. So yeah, just putting it out, to see if
Maria Silva:false, it's… it's… It's useful.
Ben Adams:Yeah, yeah, I think, I think it's quite important because there are so many different…
Ben Adams:repricing EIPs that we really need to…
Ben Adams:holistic view of them all together. I think it would be…
Ben Adams:Very valuable to have the breakouts.
Ben Adams:Beforehand.
Ansgar Dietrichs:Yeah, I mean, I'm obviously biased on this topic, I'm somewhat involved with a lot of this repricing work myself. Yeah, I do think that given that that's much more…
Ansgar Dietrichs:Clustered, at least. There's a lot of interconnections. Yeah, I do think this would be very, very helpful. Do people, as Maria said, the idea would be to basically use both?
Ansgar Dietrichs:next Wednesdays. Does that work for people? I think it's enough, like, there's… there's more than 10 ERPs that at least are related to repricing, so… so I think there's really a lot to go through. It would be a bit rushed to try to do this in a single call.
Ansgar Dietrichs:Does that work for people, or is it… it's basically too… too much to ask?
Ben Adams:Works for me.
Ansgar Dietrichs:Okay, so… Yeah, Maria, sounds like…
Maria Silva:Yeah, yeah, seems like…
Maria Silva:Some people are interested, there are no clear, cons or timings that don't work, so…
Maria Silva:Perry, you are asking, do we expect community members in these repricing calls or not? I would say, I think these calls should be open to anyone, but I understand that
Maria Silva:People that will show will be mostly car dives, but yeah, The page captains as well.
Ansgar Dietrichs:But I would say, maybe a clarification question, Maria, right? My assumption would be that it would be… like, the focus would be more a technical… the technical side, and, like, going through that, and answering people's questions, but maybe less so the specific governance conversation, or, like, the…
Ansgar Dietrichs:Yeah, or do you have a different…
Maria Silva:No, no, no, no, no, no, exactly. It's mostly about, like, understanding the EIPs and doing more technical deep dives on it.
Maria Silva:Of course, the governance discussion will be on ACD.
Ben Adams:And I assume a little bit will be… Trying to…
Ben Adams:Smooth over any rough edges so that the IPs are… Consistent with each other.
Maria Silva:Bye.
Maria Silva:Okay, so I think maybe we can move to the next topic. So, Asgar, I'm not sure what the process is, but we can figure it out. I think, we will schedule these breakout calls.
Maria Silva:Cool. So the next topic I wanted, so I'll just quickly share my screen.
Maria Silva:for this one.
Maria Silva:So I wanted to talk about,
Maria Silva:Browning errors, and why this is important for repricings.
Maria Silva:So… First, what is…
Maria Silva:what is the problem here? So the… the problem is, essentially, the compute upcodes are way too efficient when compared to the other operations and the current gas price.
Maria Silva:So this means that with integer gas, we cannot make them cheap enough.
Maria Silva:To actually have the right balance of difference in pricing between the really efficient offloads and the remaining uploads.
Maria Silva:And so… This means that, at the moment, even if we do a repricing.
Maria Silva:without doing anything else, we will have rounding errors. And what do I mean by a rounding error? So imagine that an operation… so we do the benchmarking, we find a certain anchor, so it could be, for instance, ECUB Cover or something like this, and we say that an operation should cost 0.8.
Maria Silva:But because we cannot have, fractional gas, we have to round it up to 1.
Maria Silva:And so this means that
Maria Silva:for that operation, we incur a 20% error due to routing. So this means that we could fit 20 more of this operation, if we were not running it.
Maria Silva:And, you can see here, so here I'm just, plotting the average rounding error for compute operations.
Maria Silva:Assuming different anchors, and so here, anchors, I'm using the milligars per second metric, so you kind of, use these, and then you assume a block execution time of 2 seconds, you derive the block limit, and you can do then the anchoring based on that.
Maria Silva:And you can see here that with, the performances that we have right now, so it's around the,
Maria Silva:the 30 to 50 milligars per second. We do have a lot of running errors on average, and then only after the 500 milligars per second anchor, which is an order of magnitudes larger than what we have right now, is when we actually start to have
Maria Silva:Low grounding errors.
Maria Silva:And if we look at transaction levels, so here I just took a sample of a thousand blocks.
Maria Silva:And I saw how many of each opcodes were executed in those blocks, and I assumed the repricing based on the Aztec's empirical analysis, so the analysis for the EIP704, and then I did the reprice, assuming 50 milligars per second.
Maria Silva:Anchor, and essentially you can see the level of errors that we get on an average block, so this would be around 4%.
Maria Silva:And so, this is the problem. Now, I think we have two solutions, and I will just give, like, a quick overview of them.
Maria Silva:So, one option is we just do a rebase, so we can…
Maria Silva:go to all GAS variables and parameters, and just scale them by a factor of a thousand.
Maria Silva:Block limits and targets move from billion of units to… to… from million to billion, and gas costs move from units to thousands. And so this allows us, then, on the compute side.
Maria Silva:To actually make them much more cheaper while still having integer Gus.
Maria Silva:Or we can do fractional gas. So, there was an old EIP called particle gas, so DIP would be similar, so we add a new counter, it could be milli gas.
Maria Silva:And then all… everything inside the EVM execution of the transaction is, accounted in Milligas, and then we do a rounding at the end of the transaction, so…
Maria Silva:During transaction execution, you use this new counter. After transaction execution, you round up, and then transaction fee, transaction GAS limits, block limits, and everything is going back to the normal gas.
Maria Silva:So these are the two…
Maria Silva:solution, so both have pros and cons. So, on fractional gas, you are essentially adding some, complexity to the EVM, so we are adding a new variable, and we are adding this, mechanism of running a transaction level.
Maria Silva:But the gas rebate, will likely impact UX, so this is kind of, first a hammer on hard-coated valleys, so we may be breaking stuff.
Maria Silva:And also, it… So this, this point can be…
Maria Silva:debatable. It's like, how much of a…
Maria Silva:different experience this is, because users mostly have the gas estimation with their wallets, and devs, maybe they can adjust, but essentially, it's like the concept of gas and gas limit will change.
Maria Silva:And this, this could have an impact.
Maria Silva:So I know this was very fast, so I just wanted to have…
Maria Silva:To, to put these in your attention, and also to ask if there's, like, Any solution that
Maria Silva:seems to be clearly better than the other, and the reason I'm asking is, I already have drafted initial EIPs for both solutions.
Maria Silva:And I can propose them both for Glamsterdam, and then have this discussion, during the governance process, or if there's already a clear solution, I can just,
Maria Silva:Proposed one of them, and then we can discuss if it makes sense to include it or not, instead of having to,
Maria Silva:So yeah, if there are any comments, I will open the floor now. Also, I will share the link after you have here the references for the analysis, for the… for the… the compute repricing, and also for the apps that I…
Maria Silva:We're selling robots.
Maria Silva:Okay, I'm trying to follow now the shots.
Maria Silva:Yeah, but please just jump in if you have any comments.
Ansgar Dietrichs:Andrew?
Andrew Ashikhmin:Well, I think it's an unnecessary complication, because there is a lot of variability in the actual costs, like which architecture you run on.
Andrew Ashikhmin:which is the underlying libraries, like numerical libraries, you use for computationally heavy stuff. How…
Andrew Ashikhmin:like, whether you use, like, for things like storage versus CPU, it depends a lot on various data structures, hashes, and, like, whether… like, whether you use an NVMe or not, so it's like, there is so much…
Andrew Ashikhmin:variability that, to my mind, it's the… it's kind of… the… the uncertainty
Andrew Ashikhmin:In the actual cost is just too big to justify such fine-grain
Andrew Ashikhmin:adjustments, and we are, to my… like, I see it as we are trying to, like, this is a micro-optimization… an unnecessary micro-optimization, so we have much, much bigger fish to fry. If we…
Andrew Ashikhmin:adjust the, like, do the, like, first, like, we should move step by step, first things first, like, let's do the first order.
Andrew Ashikhmin:pricing readjustment, which aligns better with the actual cost, but my point is, like, maybe the second order is just infeasible, because, yeah, like, you…
Andrew Ashikhmin:The real costs will vary a lot depending on the architecture, the hardware, and the software.
Ansgar Dietrichs:Mario, do you have.
Maria Silva:Right, so I, I think… so your comment, you are not necessarily referring one solution or the other, you are just saying none of the solutions.
Andrew Ashikhmin:Correct. I think it's, at this point at least, none of, like, none of the solutions are necessary.
Maria Silva:Right. So I, I think to…
Maria Silva:To me, that discussion is something we can… we can have,
Maria Silva:at some… at some point, and I think it makes sense to have, based on all the other EIPs that we have.
Maria Silva:But yeah, I think I would like to focus more on just the difference between the two possibilities, and whether there's a clear
Maria Silva:One that is better than the other.
Maria Silva:But yeah, thank you, thank you.
Ansgar Dietrichs:And then Carl, next up?
Carl Beekhuizen:Yeah, thanks. A few things, yeah. Addressing some of the points raised, previously, the…
Carl Beekhuizen:like, we always use the worst-case client. So, like, sure, there's variability between clients, and even the benchmarks only have a limited resolution, but we always use the worst-case client for a benchmark.
Carl Beekhuizen:And so, like, that is our constraint.
Carl Beekhuizen:I kind of disagree if we're, like, have a…
Carl Beekhuizen:like, average rounding errors or something of… or, like, if we have rounding, that's, like, 20% off, like, that's 20% scale we're just leaving in one dimension on the table.
Carl Beekhuizen:Obviously, that'll vary per opcode, but…
Carl Beekhuizen:I think this is, like, some kind of optimization we can achieve there. The second thing is that…
Carl Beekhuizen:In effect, we are rebasing anyway. Like, every single opcode, we're just proposing changing the pricing here.
Carl Beekhuizen:So all rebasing is, like, the rebasing idea here is doing is just being like, okay, cool, but we're gonna change, like, agree to change everything by a slightly bigger…
Carl Beekhuizen:Factor than we intended to. And we can, like…
Carl Beekhuizen:debate how big that needs to be, right? The proposed rebase here was 1,000, but even if we do a rebase of, like, scale everything by 10x, then something that was, like, a 20% error is now a 2% error. That's a very big difference.
Carl Beekhuizen:So yeah, I think there's… there are many things we can do here to achieve
Carl Beekhuizen:some of these things here. I'm personally not a huge fan of…
Carl Beekhuizen:Doing particle gas, I think it's just, like, massive complexity here.
Carl Beekhuizen:But, like, within the EVM, and, and risks of…
Carl Beekhuizen:Having, consensus errors, but, that's open for debate. The second thing that, LightClient was raising is, like, concerns about breaking existing contracts. So I've been running some experiments, and in all the transactions, we have
Carl Beekhuizen:ever.
Carl Beekhuizen:like, changing, rebasing 1000X. There are 1,000 transactions that would fail, that would have previously succeeded, and 1,300 transactions that have a different state route at the end.
Carl Beekhuizen:So, in effect.
Carl Beekhuizen:Like, basically none of the transactions change or run into new errors or that kind of thing.
Carl Beekhuizen:So it seems to be, like, very marginal effects to, like, actual…
Carl Beekhuizen:EVM users and transactions, so I don't think that should be a major thing that's holding us back right now.
Carl Beekhuizen:I think the bigger things you're gonna see is, like, what happens on, like, when we, like, to existing, like, tooling and that kind of thing outside of the EVM, and wallets, as opposed to, like, how does it break contracts within the EVM? It seems like people have been pretty good about not hard-coding too much.
Carl Beekhuizen:Yeah, gas constants, etc.
Ansgar Dietrichs:Ben?
Ben Adams:I mean, with… with rebasing externally.
Ben Adams:You have a problem that… plants…
Ben Adams:Because we were all too slow to move our defaults, they've…
Ben Adams:Set what the block gas limit is, and…
Ben Adams:So we… we don't control what the validators do, so we'd have to coordinate everybody to also rebase up, unless we reinterpret the values.
Ben Adams:Then you've got, yeah, wallets and so forth. There's a lot of UX.
Ben Adams:On the upper end.
Ben Adams:Coupled with that, smart contracts that do, you know, gas left and all that sort of stuff.
Ben Adams:Or pass explicit gas in coal.
Ben Adams:Upgrades.
Ben Adams:Whereas we could do… in… we could do… I mean, at particle gas, we'd ascent… we wouldn't introduce floating-point numbers, we'd just…
Ben Adams:Internally rebased, so… in the EVM, we'd rebate everything up, and then when it was red, we'd just…
Ben Adams:Rebase it back down one more.
Ben Adams:You know, when there's any introspection.
Ben Adams:Or at the end of the contract.
Ben Adams:So, we sort of did both, so…
Ben Adams:So the gas didn't change, but internally, when we're processing it, we assume everything's 10 times bigger, or 100 times bigger.
Ben Adams:And that could work.
Ansgar Dietrichs:And my understanding is that it's basically exactly… that would be… that variant you just described would be the Milligas proposal, or the… there was, I think, an old ERP in the past called Particle Gas, all kind of similar ideas. Maria, can you briefly clarify? Is that…
Maria Silva:Yeah, yeah.
Ansgar Dietrichs:Give me at least two.
Maria Silva:Yeah, that's… that's exactly how it works. So you have an internal counter that is still an integer, and then that would be the milligas counter, and all the op codes prices would be in milligas. The gas left accounting would be in milligas.
Maria Silva:But then at the end of the transaction, you round up to GAD, and so you report… the EVM reports back
Maria Silva:the gas, but not technically gas. So, everything at transaction limits, transaction fees, and so on, so forth, block limits are still
Maria Silva:In gas.
Ansgar Dietrichs:Okay, photos?
potuz:Yeah, one thing that called my attention is that,
potuz:A bunch of the data supporting this is based on anchoring on 2 seconds to execution.
potuz:And this will change dramatically on Glamsterdam, and then even potentially might change even more on the age fork.
potuz:So… so that's something to… to keep in mind, that if we are anchoring on 2 seconds execution, then Glamstering gives us 8. Perhaps the numbers we're getting are wrong, or not, just not the appropriate ones. And then again, if we shorten the slot times, then…
potuz:Well, that one might not be so dramatic if we also divide the gas limit, but again, the point stands that,
potuz:Seems a little bit premature if we do not know what the effects of longer execution is going to be.
Maria Silva:So I would add, the way that we are defining the anchors is on million gas per second, so you can then use that rationale to say what would be the block limit on a certain
Maria Silva:execution time, so if you want to do 2 seconds, you can…
Maria Silva:make the conversion by multiplying by 2. If you want to do 4 seconds, you multiply it by 4, but the anchor is on a per second, so it's kind of like…
Maria Silva:It's… it's independent, so the only thing that then… like, if you are anchoring on a 50 million gas per second, the only thing is that if you are then
Maria Silva:Allowing for… for second execution time, you… you… you can raise the block limit by…
Maria Silva:for a set amount. But the rounding errors shouldn't change.
Maria Silva:Because it's on a per… so the plot I was showing is on a per transaction, was the second plot, and the first plot was on the per upload level.
Maria Silva:Does these make sense?
Ansgar Dietrichs:Yeah, maybe this specific topic we can type to the chat. I would also…
Ansgar Dietrichs:maybe try to timebox this discussion a little bit. We can go a few more minutes, but given that we are not yet actually talking about the governance decision of including anything, we're just talking about which variant or both to even propose. So, yeah, let's go through, like, whatever comments people still have, but then I do think we should probably…
Ansgar Dietrichs:leave some room for the other, agenda topics as well. Andrew?
Andrew Ashikhmin:Yeah, I think what would be helpful is to, maybe it's already reported somewhere, but I would like to see the variability of the actual costs, because, as I mentioned, it depends a lot on the hardware.
Andrew Ashikhmin:And even on the same hardware, there are some natural variability, like, during two.
Andrew Ashikhmin:whether something is close to the CPU in caches or not, things like that. So, if you run a bunch of experiments, I would like to see the standard deviation and things like that. I think that would help us to…
Andrew Ashikhmin:Yeah, basically to make more… In informed decisions.
Maria Silva:Right, so I was using the data from the ASIC's empirical analysis, I'm happy to share the link, but in the slides, there's a link to the EIP, and then the EIP is the link to the analysis. But if you can't find it, I'm happy, like, just ping me on Discord, and I will share that with you.
Maria Silva:But we are also working on redoing some of those benchmarks, so we'll be able to make
Maria Silva:more numbers, then.
Maria Silva:Okay.
Andrew Ashikhmin:Yeah, and I would be interested in comparison of, like, like, we do have minimal hardware specs, so I would like to see results both for NVMe versus SSD, and for ARM versus AMD, at least.
Maria Silva:Yeah, if I recall correctly, ASX Analysis was doing just, one hardware spec, not multiple, but I can… I can send that to you.
Ansgar Dietrichs:And just to mention, I do think that sounded like a general kind of repricing question, not just related to this precision question, so I think that would also be a great topic for next week's call.
Ansgar Dietrichs:The breakout call, specifically, around, repricings, like the question of what does the… what are the benchmarking bases for the different repricing.
Ansgar Dietrichs:Proposals.
Ansgar Dietrichs:Carl, you have your hand up?
Carl Beekhuizen:Yeah, just briefly, the repricing, like…
Carl Beekhuizen:the data that's being used here is kind of… should be treated as preliminary data, like, this is not the proposal for the final EIP.
Carl Beekhuizen:As clients are improving, and as we get, like, much better benchmarking data, like, expect these numbers to change, and the exact things here to be reworked.
Carl Beekhuizen:This is more just flagging what are the questions that we already know are going to come up based on what we can already see in this data.
Carl Beekhuizen:Yeah, all these concerns are very valid and should be brought up and, like, discussed in these other things, but, like, we're not making… the proposal here isn't to make a final decision on
Carl Beekhuizen:Exactly how things are done right now.
Ansgar Dietrichs:Sounds good. Yeah, then maybe it did sound like some people were skeptical that we need either of the three APs, and then within that, some people preferred one approach than the other.
Ansgar Dietrichs:I don't… there doesn't seem to be that much harm in having both proposed, given that at most, one of them will make it into the fork anyway, other than to make the lives of everyone on the call that has to go through it in the next two weeks, like, slightly worse, because they have to briefly understand that these two, are basically just doing the same thing in different ways.
Ansgar Dietrichs:But I feel like that's manageable, given that we just talked about it.
Ansgar Dietrichs:So, I don't know, like, does that mean maybe… yeah, maybe it seems like the default outcome would be to maybe propose both.
Maria Silva:Yeah, it seems like there's no consensus, so I would just simply propose both and give you work. Sorry about that.
Ansgar Dietrichs:Okay, yeah.
Ansgar Dietrichs:Awesome, thank you, Marie, for that segment.
Ansgar Dietrichs:Then, let's move on. The next one is, is nice, because it might just, actually reduce everyone's work a tiny amount. There are two EIPs that, I think, my understanding is, can be removed from
Ansgar Dietrichs:PFI list, but I wanted to briefly go through them. There is EIP7667. Nixo, you first, observed that, it, or at least you left the comment on the agenda that, that it,
Ansgar Dietrichs:lacks a champion, and then also, I think Sophia just now left a comment on the agenda, saying that the ZK team also thinks that
Ansgar Dietrichs:Glamstadam is not yet the right fork for this EIP? Can… is there any, kind of, any…
Ansgar Dietrichs:Anything to add on, like, the status of the CIP?
Ansgar Dietrichs:Or any considerations around potentially removing it from the PFI set?
nixo:I can just say it was added to, this PFI set only because it sort of came,
nixo:in a bundle with the last, set of PFIs that were supposed to be for the vertical fork. So it really wasn't even intended to be added to this fork in a way that,
nixo:that the other PFIs were. So, it should be uncontroversial, but if anybody has any…
nixo:Reason that it should be added.
Guillaume:Speak up now. What's the other EIP, actually, that you described?
Ansgar Dietrichs:No, I think that's true for both EAPs. Both ERPs, yeah.
nixo:This, this EIP was originally proposed in April of 2024.
Ansgar Dietrichs:And just for context for people, like, this EAP, the reason why that one… this one is at least in principle still relevant for the future, and even before any state changes, is that the idea is to make precompiles more expensive to account for the cost that it causes for ZK EVM provers.
Ansgar Dietrichs:But, I think my understanding is that, basically, like, in general, that discussion, both on the benchmark side, on the general, like, do we even want to do this, do we want to make prices based on ZK performance, is not yet advanced enough to be relevant yet for Glamsterdam, so unless there's any specific objections, we can…
Ansgar Dietrichs:Remove it from PFI.
Ansgar Dietrichs:And then, Guillaume already mentioned it, the other one, I think, that I came across, I think is even more clear-cut, that's 6873, which, is, I think, just a preparatory step for any kind of tree change. Like, I don't know, Guillaume, do you have any
Ansgar Dietrichs:concrete content you already said offline that you think it would make sense to remove it from PFI?
Guillaume:Yeah, it was inherited from, like, it was moved, I think, by Tim.
Guillaume:to… to, to Fusaka or Glamsterdam. I guess it bounced to Glamsterdam after a while. We don't need it for the moment, so there's no reason to keep it on the roster.
Ansgar Dietrichs:Awesome. Then after this call, I'll remove both of these ERPs from PFI, and…
Ansgar Dietrichs:We made you also stop just a tiny bit easier, so… small win.
Ansgar Dietrichs:Awesome. And thank you, Nixu, for, for, bringing this up, because, yeah, that's really good.
Ansgar Dietrichs:M… Yeah, then we have one more agenda point, which is Carlos wanted to talk about EIP 8058.
Ansgar Dietrichs:Palace?
CPerezz:Yep, I'll share my screen.
CPerezz:Hold on one sec…
CPerezz:Okay, I need to restart soon, so just one second, apologies.
CPerezz:Thank you, Marius.
Ansgar Dietrichs:Maris, can you maybe do this, like, you know, at the beginning of each stream, before we go live? That would be really nice.
CPerezz:Okay, so you should be seeing my screen now.
CPerezz:So yeah, I want to quickly present this EIP. Nothing really complex, so I think we can go quite fast through it.
CPerezz:So basically, the idea is that with EIPs that are being proposed for Glamsterdam, especially the ones that reprise, state access and state growth, aggressively, some of them, like, 8037 and 8038, one of the realizations that we came up with was that,
CPerezz:Clients are basically incurring into any cost when the user deploys bytecode that is already deployed, so basically it already exists on their database, and therefore they don't know… they don't do anything. But they charge, as if they were actually duplicating the bytecode, which is not something that they do.
CPerezz:So, the idea was to basically address this, mainly because if we get something like EIP837, the gas cost for deploying a contract will jump up significantly, and the price that users will incur for deploying contracts will be quite outrageous. So, if
CPerezz:If they aren't even incurring into any state growth, it's a bit weird to charge them that much.
CPerezz:So, the idea of the deduplication is simple. It's based on using access lists. The why will come later, but the idea is, if you're a user and you know that this contract, is already deployed and another account, has its code hash stored.
CPerezz:You just include this in the access list, and therefore the client, the only thing that needs to do is run the init code, hash the resulting bytecode, and see if those match.
CPerezz:If there's a match, there's no need to actually deploy any bytecode, and therefore, the client can skip charging the gas code deposit cost to the end user.
CPerezz:So, just to address some minimal things, if we add it within the same block,
CPerezz:the expected behavior is that transaction A will always pay the full gas cost if the address doesn't exist.
CPerezz:If there's another transaction which happens to include the previous one, which is quite unrealistic, but could happen, we basically treat it on this way and receive the duplication cost, too.
CPerezz:The core trade-off here, which is what I want to basically discuss, is the following. We went for the access list-based approach, because there's two main problems. The first one is.
CPerezz:We don't want to force clients to hold a reverse mapping between code and account, which is what we will need to do if clients will be able to just look up this.
CPerezz:So that we basically, A, reduce storage, or at least we don't make it even bigger, and B, we reduce the complexity of the AIP to the minimal. There's a second thing, which is, if you snap sync or you fullsync, the bytecodes that you will have are different.
CPerezz:Because some clients, when they full sync, they store bytecodes of reorgs, because they are basically not part of the state, technically. And so…
CPerezz:when you snap sync, you will… you will not see an account that has the gold hash, and therefore you will never ask for this range of leads, and so you will… what we have is essentially clients having, like.
CPerezz:in Cancun was at 27,000 difference between bytecodes that they have, or bytecodes that they don't have between each other.
CPerezz:So to avoid all of this mess, the simplest thing was to just do it via access list.
CPerezz:The problem, of course, is that if we do it on this way, at the moment, there's no clients that actually expose any RPC endpoint to actually check for cold duplication.
CPerezz:There's external services that allow you to do that, like third parties, Etherscan, and there's some others. It's free to do so.
CPerezz:But of course, I mean, I understand that it incurs in some UX friction. At the end, I tried to bring this topic to the wallet meeting last week.
CPerezz:But no one showed up, so we couldn't discuss it. One of the main, things that…
CPerezz:are against the UX burden, is that the amount of unique versus duplicated bytecodes, as you see by the study of Wei Han from the Stateless team, is that 97% of the bytecodes deployed are basically duplications.
CPerezz:So the impact, I assume it will be minimal, because most of the things that get deployed nowadays are just mere copies of things that already exist, and most of them are pretty standardized and famous, so it's not really hard to basically find an account that holds the code hash for the contract that you want to deploy.
CPerezz:So, basically, I think this is more or less it. There's…
CPerezz:just… I just added this, thing so that you can basically see the difference between what you will pay and what you will not pay if we have deduplication in EIP837 for a 24 kilobyte contract. Of course, if we have 256 kilobyte contracts, this goes, like, to the moon.
CPerezz:And yeah, next steps are just discuss this, figure out, if clients want changes, or they have questions, or whatever, and if we can include it and finalize this thing, we will implement it, at least for Geth, and yeah, that should be mostly it.
CPerezz:So, yeah, that should be it from my side. If there's any questions or whatever, happy to answer.
Łukasz Rozmej:I have a question, is this forward compatible with code checking and putting the code into the tree?
CPerezz:That's a good point.
CPerezz:I think it should be, because the bytecode at the end is chunked always on the same way.
CPerezz:But I would defer to Guillaume, who will probably have a much more informed answer.
Guillaume:The short answer is yes, there will be some tweaks to do, but, yes, it is.
Łukasz Rozmej:Okay, but we need to…
Łukasz Rozmej:Account for those tweaks, beforehand with implementing this, or will be to those… do these tweaks when we will go… get to code tranking?
Guillaume:I think it's more of a code chunking thing, but, yeah, we, I mean, okay, I can make a write-up to go over the exact issues and see if we find them. But the… from what I see, the code chunks…
Guillaume:Would be stored exactly like code today, so there's no reason for it to… to be any different.
Łukasz Rozmej:So, because in vertical, we wanted to put code chunks directly into the tree, right?
Guillaume:Yeah, but code chunking in… okay, code chunking has, okay, there are two versions of code chunking. There's code chunking in 2926, which is an MPT-based thing, and this is what I was referring to when I said there's no problem.
Guillaume:When you go into any unified tree, like the unified binary tree, or vertical trees, for that matter, we will need to change the EIP
Guillaume:to, to actually put the code independently and not per account like it is currently specified. This is a conversation we want to have on the next, Stateless Implementers call.
Guillaume:But I think there's a lot of support for this, so in this respect, there would not be any problem either, but we need to get to the details. But once again, this is only a problem for a unified tree, and not code chunking itself.
Ben Adams:For discovery, I see me just use, estimate guess, rather than…
Ben Adams:You know, is this bytecode already deployed? Because that would be quite hard. You're not going to change your… subtly change your bike code to match one that already exists.
Ben Adams:But obviously, It would bring down the cost of, like, Contracts that deploy contracts with
Ben Adams:become, you know, like Uniswap, E2, deploying liquidity pools, they would become very cheap, because that's obviously the same.
Ben Adams:Exactly the same contract, so it's deployed again and again.
CPerezz:But that's theoretically fair, no? Meaning, the user is paying exactly for the resources that the node is consuming, so…
Ben Adams:Yeah, yeah.
Ben Adams:I'm… I'm… I'm not against it. And it would also, it would also encourage more… More reuse.
CPerezz:Are there any strong opinions from clients on how we should, handle,
CPerezz:the attention of this reverse index, meaning, is it okay if we… like, the worst case is the user pays the same that he's paying nowadays, so there's not, like…
CPerezz:there's no, like, drawback, I would say. But it's true that the way to obtain this discount at this point is mainly you need to iterate through your
CPerezz:tree, or, like, you need to know what you're doing with the node, or, you need to go to a centralized slash third-party service. So, are there any thoughts on that?
Ben Adams:Wouldn't estimate gas. You know, the normal… what you'd do with the wallet, tell you.
CPerezz:So Estimate Gas should be easy to do, right? Because for Estimate Gas, you already should have the access list field, so you can just check if the code exists or not.
Ben Adams:Yeah, so… I mean, I assume that's the approach somebody would try and discover.
Ben Adams:They're essentially saying, if I deploy this contract, how much is it going to cost me?
Ben Adams:That's why you want to know if the bike code already exists, isn't it?
CPerezz:He is.
Ben Adams:That would… that would… that would already come from Estimate Gas.
CPerezz:The problem is, for Estimate Gas to work, the access list has to have the account whose code hash is, basically your bytecode, hash, right? So…
CPerezz:Estimate Gas will only work correctly if you are already providing the account, which holds the code that you want to deploy. So that's the… that's the main problem, basically.
Ben Adams:One… one issue I can see with it… Potentially is, block access lists.
Ben Adams:You know, how does…
Ben Adams:where you have a contract deploy… the same contract deployed in the same block, is there… there might be some weird edges around pricing and parallel execution.
Ben Adams:Because you're… I'm not sure how that would work with block access.
CPerezz:I mean, transaction ordering is still a thing, right? Even if you have block access lists, meaning the way in which you
CPerezz:Execute the transactions is not related to how they are ordered in the block, so…
CPerezz:Theoretically, the order of the block is what rules the entire thing, discount-wise at least.
Ben Adams:Yeah, but what I mean is you're… you're now…
Ben Adams:Changing the pricing of a transaction based on an earlier transaction.
Ben Adams:If you see what I mean. So you need to know whether the earlier transaction deployed the contract.
Ben Adams:That you're trying to deploy in a later transaction, so you're…
CPerezz:Sure. Independency.
CPerezz:Sure, that's true. I mean, the odds of that happening are scarce, I would say, because basically, this means that in a block, two people, or the same one through two different accounts, deployed
CPerezz:the same exact bike code, which wasn't existing up to this point. So, I mean, this, of course, can happen, but it would be very weird, I would say. Nevertheless, I think since this is contract deployment, and it will be heavily, heavily priced, block access lists.
CPerezz:won't have, like, much to do there, meaning if you have two 24 kilobyte deployment, within a block, there's not… there's not much more room left for… for computing, much stuff. I mean, depending on the gas prices, of course, but…
Ansgar Dietrichs:Okay, any further… Comments, discussion points on this specific EIP?
Ansgar Dietrichs:And, Carlos, can you remind me? This one is not yet in the PFI list, right? So this will also still be added, or…
CPerezz:I made the PR during the call, so, I mean, I'm unsure if the bot, versed it. No, it's still… I mean, it's in the CI phase, so… Okay.
CPerezz:It's bending again.
Ansgar Dietrichs:Perfect, sounds good.
Toni Wahrstätter:Yeah, no.
Ansgar Dietrichs:Yeah.
Toni Wahrstätter:One last question, just, I was just typing it, but I felt like it makes more sense to just, say it. The last comment of Carlos, that with the block access list, I think it wouldn't be a problem, because the code deployment is also mapped to a transaction ID.
Toni Wahrstätter:So, I think Carlos is right there, that it shouldn't be a problem.
Ansgar Dietrichs:Okay, awesome. Then… thank you, Carlos. The unfortunate news is that then, out of the EIPs section, we actually removed two, but added three. So, not going our way, but…
Ansgar Dietrichs:At least, that's all for today, so no more… no more added now. Let's see how many more come throughout the week.
Ansgar Dietrichs:But yeah, I think that's all for today, then. There was an open discussion section, but I think it's really best if we leave the Glamstadum discussion to…
Ansgar Dietrichs:two weeks from now. And so with that, thank you everyone for coming, and, talk to you all in two weeks.
Ansgar Dietrichs:And… in between.
potuz:Bye.
Justin Florentine (Besu):Thank you.
Guillaume:But…
Carl Beekhuizen:Thanks, Al.
CPerezz:Right.
Chat Logs
00:02:57
Marius van der Wijden:Replying to "Good morning y'all"
Mine too for today :D
00:03:20
Marius van der Wijden:Replying to "Good morning y'all"
Only two more calls and a presentation left
00:06:42
stokes:https://notes.ethereum.org/@bbusa/fusaka-bpo-timeline
00:07:04
Barnabas:Please note that BPO1 has an adjusted time compared to before!
00:07:15
Barnabas:https://github.com/ethereum/pm/issues/1764#issuecomment-3435616551
00:08:11
Barnabas:original BPO1 proposal was the 17th of Dec, this has been shifted to 9th of Dec.
00:08:51
Barnabas:I’m also proposing to change the rule of when we can schedule mainnet: https://github.com/ethereum/pm/pull/1780
00:09:05
Łukasz Rozmej:GTG
00:09:22
Marius van der Wijden::+1:
00:10:23
Phil Ngo:🚢
00:11:25
stokes:3 Nov for client releases!
00:11:27
Barnabas:preconfirmations
00:12:32
Justin Traglia:I like the current language around it. Wait for all testnets.
00:13:43
Łukasz Rozmej:I'm fine with "all but 1 testnet"
00:14:29
Barnabas:I just want less bikeshedding :D
00:14:30
potuz:config changes on the ENR and P2P advertises the next fork epoch... it's not entirely trivial, but again I think it's reasonable not to require all testnets
00:14:37
stokes:Replying to "I just want less bik..."
But we love bikes
00:15:00
stokes:ACD can, if needed, override parts of this document.
00:15:17
Justin Traglia:But then it leads to more confusion if/when the dates change.
00:16:07
potuz:I like that idea
00:16:14
Marius van der Wijden:We never forced clients to release all at the same time before
00:16:27
Justin Traglia:Sounds fine to me
00:16:33
Barnabas:Setting the date early is better for predictability, and thats all I want to push.
00:16:40
J Sunnyside Labs:Btw do we also have testnet guideline for BPO forks?
00:16:42
Barnabas:This would all matter in glammy not for fusaka.
00:17:19
Barnabas:We don’t have any glammy devnets up yet
00:17:57
Stefan Starflinger:we should have one up soon for BAL
00:18:31
stokes:https://github.com/ethereum/pm/issues/1764#issuecomment-3433396802
00:20:00
Justin Florentine (Besu):i'm not aware of that requirement?
00:20:06
stokes:Replying to "i'm not aware of tha..."
same
00:20:09
Barnabas:They had months to propose already?
00:20:34
Raúl Kripalani:We are planning to submit an EIP for the sparse blobpool
00:21:38
Barnabas:number will be assigned same day, it won’t be merged, but that should be fine
00:21:46
Barnabas:as long as you have a number its ok no?
00:21:54
Marc Harvey-Hill:could make the deadline the cutoff for making a PR to glamsterdam meta-eip, so don't need to wait for merge
00:22:17
Marc Harvey-Hill:or making a draft Pr if you don't have a number yet
00:24:41
Ansgar Dietrichs:I think we can say:
until 1 week from now to make PFI intent clear
until 2 weeks from now to have everything properly merged (EIP itself and PFI in Meta EIP)
00:25:47
Josh Davis:There are 31 PFI’d EIPs
00:25:50
Pooja Ranjan:We’re looking to add more editors to help merge PRs faster and keep the review queue moving.
If anyone has thoughts or feedback on this proposal, please share them in the comments.
https://github.com/ethcatherders/EIPIP/issues/394
00:25:59
Ben Adams:small fork ;)
00:26:33
wolovim:https://forkcast.org/upgrade/glamsterdam#proposed-for-inclusion
00:27:05
kev:Does the November deadline take into consideration devconnect?
00:27:12
Barnabas:Replying to "Does the November de..."
yes
00:27:28
Barnabas:EL devs are not too busy anyways :D
00:27:59
Justin Florentine (Besu):FOCIL
end of list.
00:28:21
Justin Florentine (Besu):(this is a joke, not besu position)
00:28:37
Barnabas:Replying to "(this is a joke, not..."
sad you have to highlight this fact 😄
00:28:43
Marcos A. Maceo:Replying to "(this is a joke, not..."
++
00:30:12
potuz:@Raúl Kripalani have there been EIPs for the mempool before? I think EL devs explicitly don't want to specify it isn't it?
00:30:39
Caspar Schwarz-Schilling:Worth pointing out that there’s a lot of related EIPs, eg repricing, that maybe make it a bit easier to work through ~30 EIPs by themes / bundles
00:30:44
Marius van der Wijden:My position for the previous discussion: we should always error on the side of practicality. The process should work for us, not us for the process
00:31:00
stokes:I do think it would be very helpful for CL teams to have written opinions out
00:31:14
stokes:(So parse as a strong nudge ;) )
00:31:17
potuz:Can we use ACDC time to analyze some of the EL EIPs? no reason to delay 2 weeks just because of existing schedules and artificial divisions of ACD
00:31:36
stokes:Replying to "Can we use ACDC time..."
Im fine w/ that if enough EL devs show up
00:31:39
wolovim:Do client teams have any requests of eip authors to make it easier to review their proposals?
00:31:56
stokes:Replying to "Can we use ACDC time..."
Would want to get through all of the CL stuff first
00:32:04
Barnabas:Replying to "Can we use ACDC time..."
Maybe lets have 3 ACDE in a row and skip an ACDC?
00:32:14
stokes:Replying to "Can we use ACDC time..."
Its an idea lol
00:32:25
stokes:Replying to "Can we use ACDC time..."
It is a lot to moderate calls back-to-back like that
00:32:37
Ben Adams:and example effects/test cases
00:32:38
Barnabas:Replying to "Can we use ACDC time..."
Ansgar is up for it I heard.
00:32:55
potuz:Replying to "Can we use ACDC time..."
lol
00:33:24
potuz:Replying to "Can we use ACDC time..."
Agreed on going through the CL EIPs firsts
00:33:31
potuz:Replying to "Can we use ACDC time..."
can't +1 for some reason in this client
00:34:11
Ben Adams:Use extra time in ADCT also?
00:34:11
Barnabas:Lets get through all the CL stuff next week?
00:34:31
Justin Florentine (Besu):we should schedule async pre-work harder
00:34:32
potuz:I don't think we need to swap the entire call, just use the free time to discuss EL stuff
00:34:45
stokes:Replying to "Lets get through all..."
Possibly, not sure what Cl PFIs will come thru
00:34:49
stokes:Replying to "Lets get through all..."
In the next week
00:35:31
Marius van der Wijden:I think it would be good for client teams to highlight proposals that they ABSOLUTELY don't want, so we don't spend too much time on those
00:35:42
potuz:+1 ^
00:36:37
Josh Davis:Almost fully complete.
00:36:41
Josh Davis:Missing 1 champion
00:36:46
wolovim:All champions listed on forkcast: https://forkcast.org/upgrade/glamsterdam#proposed-for-inclusion
00:37:00
Josh Davis:I think thats the one
00:37:04
potuz:Like asking Vitalik to show up on the hashing pricing?
00:37:47
kev:Forgot to put on agenda:
For max-blobs, it doesn’t require a hardfork so it’s not explicitly proposed
00:38:20
Barnabas:Replying to "Forgot to put on age..."
max blobs?
00:39:02
kev:Replying to "Forgot to put on age…"
https://eips.ethereum.org/EIPS/eip-7872
00:39:03
Marius van der Wijden:Replying to "Like asking Vitali..."
If he's the champion, he should be available for questions/discussions
00:39:32
stokes:You want to PFI it?
00:39:38
stokes:Replying to "Forgot to put on age..."
Should get it on the meta eip
00:39:47
Raúl Kripalani:The CL could use this as a perf engineering cycle if there’s lesser EIP work
00:39:47
kev:Replying to "Forgot to put on age…"
It doesn’t require a hardfork so wasn’t sure
00:39:50
nixo:Replying to "Like asking Vitalik ..."
it sounds like zkEVM is for removing this EIP
00:39:57
stokes:Replying to "Forgot to put on age..."
Its not a core consensus thing but we also have been trending towards making this type of thing part of formal forks
00:40:14
Barnabas:Replying to "All champions listed..."
doesn’t seem to match the latest master commit from https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7773.md
00:40:29
potuz:Replying to "Like asking Vitalik ..."
guess who's the only EIP without a champion :)
00:40:31
Barnabas:Replying to "All champions listed..."
e.g declined for inclusion list only has 1 on forkcast, while has 6 on the meta eip
00:40:43
stokes:Replying to "The CL could use thi..."
Perhaps; if there’s ‘spare time’ (which im also not convinced of), then it can go into refining glam EIPs/specs as we get deeper into impl
00:40:49
Maria Silva:https://github.com/ethereum/pm/issues/1764#issuecomment-3436247707
00:41:18
Pooja Ranjan:Replying to "Forgot to put on age..."
Keeping on Meta EIP anyway will be nice for signaling.
00:41:31
Barnabas:Replying to "Forgot to put on age..."
yeah, every change whether it requires a hard fork or not should be proposed, so that it wont get forgotten
00:41:44
Josh Davis:Replying to "All champions listed..."
Those are all headliners that we did not select. We are trying to decide how to represent these best while maintaining historical context
00:41:48
wolovim:Replying to "All champions listed..."
We can add those recently DFI’d. They are not mixed up within the PFI list, for example, just not represented anywhere. I think those are the unchosen headliners
00:41:50
Raúl Kripalani:Replying to "The CL could use thi…"
Yeah, EIP volume != implementation effort, big ‘if’
00:42:29
Marius van der Wijden:I will be there :)
00:42:32
Barnabas:Replying to "All champions listed..."
unchosen headliners are DFIed
00:42:35
CPerezz:@Maria Silva Are these calls the same as the ones we have on Fridays for repricing?
00:42:45
Maria Silva:No, carlos
00:42:51
Marius van der Wijden:Replying to "@Maria Silva Are t..."
Hopefully with more attendees
00:42:51
Barnabas:Replying to "All champions listed..."
just put them in the DFI section?
00:43:22
Josh Davis:Replying to "All champions listed..."
We want to make sure that they are designated as headliner proposals in the DFI. They will make it there eventually
00:43:37
Caspar Schwarz-Schilling:Replying to "The CL could use thi…"
Also epbs (CL) being glam timeline bottleneck
00:43:58
Ameziane Hamlat:I will be there as well
00:44:10
Parithosh Jayanthi:Do we expect community members at these repricing calls or not?
00:46:26
Ansgar Dietrichs:it’s a good problem to have :-)
00:46:52
Ansgar Dietrichs:Replying to "it’s a good problem ..."
I miss being able to just leave useless comments like that in chat more often during the call
00:47:07
Ansgar Dietrichs:Replying to "it’s a good problem ..."
can’t wait for Tim to take back over so I can return to my professional chatter role
00:48:33
potuz:what is that chart? it's showing negative rounding errors after 400Mg/s ?
00:48:46
Ben Adams:Made opcodes too efficient
00:49:38
Carl Beekhuizen:Easy giga-gas
00:49:46
Ben Adams:Didn't think we'd we get to GigaGas this way ;)
00:50:06
Ansgar Dietrichs:Replying to "Easy giga-gas"
core devs don’t want you to know about this one weird trick to scale your L1
00:50:07
Ahmad Bitar | Nethermind:fractional gas seems to be a lot more work IMO
00:50:28
Carl Beekhuizen:Replying to "Easy giga-gas"
cryptotwitter in shambles
00:50:46
potuz:these sound like juicy consensus failures happening soon in the next fork :)
00:51:14
lightclient:Have you looked into how this affects existing contracts?
00:51:23
Ben Adams:Replying to "fractional gas seems..."
More upstream work and side effects from rebasing
00:51:43
Carl Beekhuizen:Replying to "Have you looked into..."
I have been, basically no effect with “rebase”
00:52:06
Ben Adams:Replying to "Have you looked into..."
With contracts that do gas introspection?
00:52:12
Carl Beekhuizen:Replying to "Have you looked into..."
yes
00:52:15
Marios:Why not combine x1000 with a redefinition so that nothing actually changes on the UX
00:52:30
Toni Wahrstätter:I more leaning towards scaling gas up instead of doing fractional gas. Users don't care too much about abs. gas used and introducing fractions feels prune to bugs
00:53:01
Marius van der Wijden:I would prefer to anchor to the 21k gas for a basic transfer
00:53:35
Marius van der Wijden:Replying to "I would prefer to ..."
So neither fractional gas nor repricing *1000
00:53:37
Łukasz Rozmej:take 1 gas as basic compute cost, adjust the rest
00:53:37
potuz:Replying to "Have you looked into..."
yeah I assume the EVM will show the old gas price rounded
00:53:52
Ben Adams:Replying to "I would prefer to an..."
Basic transfer is mispriced; so would through everything out
00:54:00
Łukasz Rozmej:Replying to "I would prefer to an..."
@Ben Adams wants to lower that number :D
00:54:06
potuz:Replying to "Have you looked into..."
only in total gas used and burn is that this would make a difference, so only in consensus, not EVM
00:54:09
CPerezz:Replying to "take 1 gas as basic ..."
This will break a lot of contracts that have hardcoded gas costs in CALL/DELEGATECALL
00:54:28
donnoh | L2BEAT:fwiw arbitrum solves this problem by introducing “ink” where 1 gas = 10k ink https://docs.arbitrum.io/stylus/concepts/gas-metering#ink-and-gas
00:54:48
Marius van der Wijden:Replying to "I would prefer to ..."
Yes, but instead of lowering that, we can increase everything else
00:55:06
Łukasz Rozmej:Replying to "take 1 gas as basic ..."
how low should be the lowest operation now in gas?
00:55:08
Łukasz Rozmej:Replying to "take 1 gas as basic ..."
0.8 gas?
00:55:11
Łukasz Rozmej:Replying to "take 1 gas as basic ..."
0.0000001 gas?
00:55:26
Marius van der Wijden:Replying to "I would prefer to ..."
Thats what I mean, anchor to the 21k, repricing everything including the simple transfer, so that the anchor works
00:57:56
Ameziane Hamlat:@Maria Silva could you share the links to the benchmarks results and links from the presentation ?
00:58:16
Maria Silva:Replying to "@Maria Silva could y..."
https://notes.ethereum.org/@misilva/Hy6o1OLRgx#/
00:58:27
Maria Silva:Replying to "@Maria Silva could y..."
All links are at the end
00:58:33
Ansgar Dietrichs:my personal opinion is the other side from Carl - I feel a bit uncomfortable with a large rebasing like 1000x
I think particle gas / milligas is not actually that much overhead (your actual gas counter in the implementation is now 1000x more resolution, but any time the EVM asks, you round to the old resolution) and would just get rid of the backwards compatibility headache
00:59:38
Ansgar Dietrichs:Replying to "my personal opinion ..."
but maybe that is me being too conservative, and we need to get comfortable with bigger gas changes anyway 🤷♂️
01:03:11
potuz:Yeah Maria it does make sense, but the worry I have is that the broadcast/execution part of gas usage changes a lot in Glamsterdam
01:03:24
potuz:and presumaby that will need a bigger change in gas pricing
01:04:12
Ansgar Dietrichs:Replying to "and presumaby that w..."
I think the repricing effort overall does already work on including the ePBS and BALs effects in the pricing targets
01:04:33
Ansgar Dietrichs:Replying to "and presumaby that w..."
but yes, you are right, these two headliner EIPs do significantly change how much room we have in a slot for different operations
01:05:05
Maria Silva:Replying to "and presumaby that w..."
We definitely want to take that into account in for repricings
01:05:48
Ben Adams:Also rebasing externally would add more bytes to each tx (gaslimt) so use more bandwidth
01:06:01
Maria Silva:Great point, Carl
01:09:17
kev:I think it’s too early
01:09:20
potuz:Maria, Carl, was the biggest point against a rebase the external tooling that will need changes? I didn't get why for example wallets would need to change at all.
01:09:40
potuz:to me it was a nobrainer that rebase should have minimal impact
01:10:19
Carl Beekhuizen:another thing to flag, I personally think we should not target an arbitrary MGas/s and rather anchor on an existing OPCODE/ reference point.
eg. I think it’d be better to aim to keep the 21kGas tx minimum than 200MGas/ second. the former is a more meaningful anchor for everyone imo
01:11:22
Ahmad Bitar | Nethermind:im thinking neither rebasing nor fractional should be the solution. we should just do repricing of everything and keep the smallest unit as 1. of course, along side that we would raise the gas limit to align with the new prices. this is way less big of a hassle than the suggested approaches. the suggested approaches feel like over engineering
01:11:41
potuz:Replying to "another thing to fla..."
I think this is trickier with regards to what I am pointing that the broadcast/execution part of the slot changes in Glamsterdam and therefore the relative OPCODE gas pricing should change IMO
01:11:42
Raúl Kripalani:That should be the sound of Fusaka
01:11:45
Hsiao-Wei Wang:Du du du du
01:11:45
Marius van der Wijden:I will sample it from the recording
01:12:13
Maria Silva:Replying to "Maria, Carl, was the..."
This and hardcoded values
01:12:16
Carl Beekhuizen:Replying to "Maria, Carl, was the..."
Yes, pretty much. e.g. a basic ETH transfer would require 210k gas with a 10x rebase
01:12:35
Carl Beekhuizen:Replying to "Maria, Carl, was the..."
Well hardcoded values aren’t really a thing in practice
01:12:51
potuz:Replying to "Maria, Carl, was the..."
but not on the wallet, the wallet doesn't need to change, the tx gas limit needs to be multiplied in the client in consensus
01:13:04
potuz:Replying to "Maria, Carl, was the..."
also think that @Ben Adams comment on bytes on the fly is wrong
01:13:05
potuz:Replying to "Maria, Carl, was the..."
because of this
01:13:11
Ansgar Dietrichs:I am still nostalgic for the time where I could remember which EIP number was which proposal. now it is just this never ending avalanche of digits everywhere
01:13:16
potuz:Replying to "Maria, Carl, was the..."
the wallet doesn't need the division
01:13:38
Carl Beekhuizen:Replying to "Maria, Carl, was the..."
Aah, you mean under particle gas, not rebase?
01:13:54
Carl Beekhuizen:Replying to "Maria, Carl, was the..."
Rebase means every gas code now costs e.g. 10x more
01:13:59
Maria Silva:Replying to "im thinking neither ..."
With this, we are incurring those rounding errors I was showing at the beginning.
01:14:02
jochem-brouwer:Antwoord verzenden naar "I am still nostalg..."
We should know all proposals by heart, right? :)
01:14:04
Carl Beekhuizen:Replying to "Maria, Carl, was the..."
Both internally and externally
01:14:12
Toni Wahrstätter:Why using the AL instead of a new field?
01:14:17
Maria Silva:We can discuss if that is a problem we want to tackle or not
01:14:20
nixo:Replying to "I am still nostalgic..."
just get them all tattooed on yourself so you can easily access them. ezpz
01:14:29
potuz:Replying to "Maria, Carl, was the..."
I mean just rebase all opcodes to 1000 the current price, but only do it internally and dont change anything outside, not even in the EVM for gas introspection
01:14:32
potuz:Replying to "Maria, Carl, was the..."
just total accounting
01:14:37
Ben Adams:Replying to "Maria, Carl, was the..."
external rebasing would need the tx gaslimit also to increase; otherwise everything gets weird
01:14:55
Ben Adams:Replying to "Maria, Carl, was the..."
internal rebase is the fractional gas
01:14:59
Ansgar Dietrichs:Replying to "I am still nostalgic..."
we should have an acd pub quiz once a year at devcon or interop or something, with prizes for whoever can remember EIPs by number the best
01:15:03
Carl Beekhuizen:Replying to "Maria, Carl, was the..."
Exactly @Ben Adams
01:15:09
Louis:Replying to "I am still nostalgic..."
Can eip named after comet?
01:15:18
Łukasz Rozmej:is this forward compatible when bytecode will leave in a tree?
01:15:24
potuz:Replying to "Maria, Carl, was the..."
Oh ok I am getting the nomenclature wrong
01:15:24
Maria Silva:Potus, what you are suggesting is my milli-gas proposal
01:15:25
Marius van der Wijden:Replying to "I am still nostalg..."
There are these trash-tv participants in germany that did that, tatooed all their trash tv seasons on them
01:15:31
Ahmad Bitar | Nethermind:Replying to "im thinking neither ..."
if we reprice all opcodes and precompiles, Wouldnt those rounding errors completely disappear. for example, just use 30 instead of 3 and use 15 for something you want to price as 1.5. this way it is not a real rebase, but opcode and precompile repricing.
01:15:49
Ansgar Dietrichs:Replying to "I am still nostalgic..."
we can name EIPs by cities of smaller Ethereum conferences. if there is one thing more endless than EIPs it’s conferences
01:15:59
Leo:Replying to "I am still nostalg..."
There was a quiz at the Grantee night with questions about EIPs
01:16:05
potuz:Replying to "Maria, Carl, was the..."
yeah probably I messed up what "rebase" means, but yeah I meant only internally work with every gas unit multiplied by 1000
01:16:11
Ahmad Bitar | Nethermind:Replying to "im thinking neither ..."
you can think of it as rebase, but without the big tooling and wallet associated changes around it. as they can just consider it as repricing
01:16:13
Carl Beekhuizen:Replying to "Maria, Carl, was the..."
btw even with external rebasing, only 2339 transactions in Ethereum’s history ever that would either fail or have a different state-root
01:16:15
Wei Han Ng:Replying to "is this forward comp..."
It's only possible if there are no accounts referencing it
01:16:23
Ahmad Bitar | Nethermind:Replying to "im thinking neither ..."
and then the gas limit goes up matching the new prices
01:16:51
potuz:Replying to "Maria, Carl, was the..."
external rebasing is literally asking the wallet to send 21M for a transfer? that I think will be a nightmare fork
01:18:04
Carl Beekhuizen:Replying to "another thing to fla..."
yes, pretty much every opcode’s pricing will change under (separate) EIP-7904
01:18:21
Maria Silva:Replying to "im thinking neither ..."
The errors I was showing is already with a reprice based on Jacek’s empirical numbers. What you are suggesting is a softer rebase (like 10x), while still incurring some rounding errors. So I think it get some UX complexities while keeping rounding errors
01:18:35
Ansgar Dietrichs:Replying to "is this forward comp..."
should be compatible, because the code hash and the code tree root are both just pointers to the code, just in different formats
01:19:10
Carl Beekhuizen:Replying to "Maria, Carl, was the..."
How different can it be? If it doubled to 42k would that still be ok?
01:19:37
CPerezz:https://github.com/ethereum/pm/issues/1773
01:19:42
Carl Beekhuizen:Replying to "Maria, Carl, was the..."
Becuase unless that is the anchor, it will change to somewhat
01:19:56
Carl Beekhuizen:Replying to "Maria, Carl, was the..."
But I agree a 1000x external rebase is a non-starter
01:20:08
Carl Beekhuizen:Replying to "Maria, Carl, was the..."
I’d argue no more than 10x
01:20:53
Ahmad Bitar | Nethermind:Replying to "im thinking neither ..."
are the rounding errors still significant with a soft rebase?
01:21:03
Ahmad Bitar | Nethermind:Replying to "im thinking neither ..."
as described above?
01:21:18
Ansgar Dietrichs:it’s a bit unfortunate that we don’t have EOF (…), because contracts could be more thoroughly deduplicated just on the code section. without it, any contracts that have constants hard coded into code that change between deployments can’t be deduplicated
01:22:04
potuz:Replying to "Maria, Carl, was the..."
I think any required changes on wallets makes a nightmare fork. We should learn this from rollups that are blocked from making any internal changes that will need wallet support, coordinating this is a nightmare
01:22:11
Guillaume:Replying to "it’s a bit unfortuna..."
Ansgar said the E word
01:22:13
jochem-brouwer:Antwoord verzenden naar "it’s a bit unfort..."
Yes I wanted to bring this up, esp. with Solidity constants where I'm rather sure constants (like ERC20 token name) are indeed written to code instead of storage. So you cannot duplicate ERC20 contracts if you want a different token name
01:22:29
potuz:Replying to "Maria, Carl, was the..."
so it's not abou tthe value, but rather the players that need to help in the fork
01:22:38
Ansgar Dietrichs:Replying to "im thinking neither ..."
is a soft rebase just 10x everything instead of 1000x everything?
because you can’t only 10x the compute operations, otherwise they are too expensive relative to state access and calldata and so on
01:22:38
Carl Beekhuizen:Replying to "im thinking neither ..."
And even outside of rounding errors. Say we set ADD to 1 gas, transaction minimum (21k) will still jump up a bunch
01:22:44
potuz:Replying to "Maria, Carl, was the..."
if we can keep it to client teams that's much simpler
01:23:25
Ansgar Dietrichs:Replying to "it’s a bit unfortuna..."
@Guillaume well you said the V word earlier on the call :-)
01:23:36
Guillaume:Replying to "it’s a bit unfortuna..."
I wasn't the first though
01:23:37
Maria Silva:Replying to "im thinking neither ..."
Yeah, if we 10x everything, I still think it is a rebase with impact to UX
01:23:38
Carl Beekhuizen:Replying to "Maria, Carl, was the..."
So the anchor in your mind should be the 21k? (That is my personal preference)
01:23:43
Ahmad Bitar | Nethermind:Replying to "Maria, Carl, was the..."
yeah, that is my thought as well. we should keep the work on the client. adjust prices and gas limit without any complications in the implementation of calculations or changes in the tooling and wallets
01:23:44
Ansgar Dietrichs:Replying to "it’s a bit unfortuna..."
@jochem-brouwer yes it really is an unfortunate limitation. even with it though, the gains still seem significant
01:23:50
Guillaume:Replying to "it’s a bit unfortuna..."
but I forgot to say "it will delay verkle"
01:23:51
Marius van der Wijden:Can we timebox this discussion maybe?
01:24:13
Ansgar Dietrichs:Replying to "it’s a bit unfortuna..."
I miss the old Guillaume, the don’t delay Verkle Guillaume
01:24:29
Ansgar Dietrichs:Replying to "it’s a bit unfortuna..."
you never know how good you have it until you lose it 😢
01:24:34
Carl Beekhuizen:Replying to "Maria, Carl, was the..."
But I haven’t run the numbers on the errors (which may be substantial, e.g. 2x scaling left on the table)
01:24:45
ignacio:Reg the current Binary Tree proposal, this means we need to change this https://eips.ethereum.org/EIPS/eip-7864#code. Apart from the point of not depending on `address`, might have some other implications reg the first 128 chunks that we store in the account stem. Prob we still would need to do that, and for other code chunk indexes switch to a tree address that only depends on code_hash and not account address.
So this means that there will still be some duplication introduced despite we might not be chargining it in this EIP.
cc @Guillaume
01:24:45
Guillaume:Replying to "it’s a bit unfortuna..."
I'm still alive you know...
01:25:51
Justin Florentine (Besu):Replying to "it’s a bit unfortuna..."
so you're saying i've got a week to PFI EOF for G*?
01:26:19
Ahmad Bitar | Nethermind:Replying to "it’s a bit unfortuna..."
Eth to 10K once included
01:26:25
Guillaume:Replying to "Reg the current Bina..."
the conversation we will have in the next SIC is precisely that we won't do this 128 thing. Eip 7864 will be updated when the decision is made
01:26:26
Toni Wahrstätter:Placeholder eips incoming
Summary
12 highlights
· 4 decisions · 6 action itemsExperimental
Summary
12 highlights · 4 decisions · 6 action itemsExperimentalfork status and schedule
critical infrastructure
- Holesky shutting down Oct 31st - already at 70% participation, urgent migration to Sepolia/Hoodi needed00:05:15
testing progress
- BAL DevNet Zero launching tomorrow/early next week00:17:42
glamsterdam governance
repricing discussion
- Compute opcodes 20% underpriced due to integer rounding at current 30-50 Mgas/sec anchor00:46:06
- Two solutions proposed: 1000x gas rebase vs milli-gas with internal counters and transaction-level rounding00:49:14
- Glamsterdam's 8-second execution window will significantly impact gas pricing calculations01:00:49
eip updates
organizational
- Two repricing breakout calls scheduled: Wednesdays at 3 UTC (Oct 30 & Nov 6)00:40:41
Decisions
- Pre-committed to Fusaka timeline (Dec 3/9/Jan 7) conditional on Holesky success00:08:31
- Non-headliner EIP proposals due Oct 30th (PR to EIP repo sufficient)00:18:44
- Client opinion documents due Nov 6th, finalize Glamsterdam scope by end of November00:24:54
- EIP-7667, EIP-6873 moved to DFI for Glamsterdam01:10:02
Action Items
- All client teams (due Nov 6th): Prepare opinion documents on proposed EIPs00:24:54
- All EIP champions: Be available to answer questions about proposed EIPs over next two weeks00:37:11
- Ansgar Dietrichs: Remove EIP-7667 and EIP-6873 from PFI list01:10:02
- Guillaume: Create write-up on code chunking compatibility with EIP-805801:18:27
- Maria Silva: Propose both gas precision solutions (rebase and milli-gas) as separate EIPs01:06:58
- All client teams: Decide internally whether to keep ACDE call during DevCon week00:39:46
Targets
- Holesky Fusaka fork: October 28, 202500:04:08
- Holesky testnet shutdown: October 31, 202500:05:15
- Fusaka client releases: November 3, 202500:08:31
- Fusaka mainnet: December 3, 2025 | BPO1: December 9 | BPO2: January 7, 202600:07:29
- Non-headliner EIP deadline: October 30, 202500:18:44
- Client opinions due: November 6, 202500:24:54
- Repricing breakout calls: October 30 & November 6, 2025 at 3 UTC00:40:41