Ansgar Dietrichs:Perfect. Well, hello, good morning, afternoon, everyone.
Transcript
Ansgar Dietrichs:Welcome to… Another AllCoreDevs, the plan for today is… pretty…
Ansgar Dietrichs:packed, because we want to actually start the Glamsterdam scoping discussions. So, for that reason, I'll today be a bit more opinionated and
Ansgar Dietrichs:a bit more strict with timeboxing for individual points. If you feel like I'm getting anything wrong, just feel free to jump in and we can assess. But I'll… I'll just err on the side of being more opinionated today.
Ansgar Dietrichs:To start with, though, we have a few quick Fusaka points to get through. I think we wanted to start with some testnet updates. Barnabas, do you want to give a quick update?
Barnabas:Sure, so yesterday we have BPO1 activated on Hudi, and next week we're going to have BPO2, which is the final BPO before, we hit mainnet.
Barnabas:During the BPO fork transition, there seemed to have no bug, but
Barnabas:later on, and early today, we discovered that there might be a Nethermine bug. I think the Nethermine team is currently still investigating, I'm not sure if they have anything to share yet.
Barnabas:Regarding how serious the bug is, or, what they can say.
Barnabas:But it seems to be related to Fusaka.
Łukasz Rozmej:Hi guys, yeah, it seems to be related to Fusaka and to Reorg, so we are still investigating.
Barnabas:Yep, and other than that, I think every other, EL team has made a mainnet release, with the mainnet times, and on the CL side, everyone but Prism has made,
Barnabas:May not release, and they are currently soaking the release, and should be ready by Monday, based on our latest information.
Barnabas:But this is another blog post going out, maybe today, and, we're going to put, to be determined for Netherland and Prism, for now.
Barnabas:or diversions.
Ansgar Dietrichs:That's what you…
Manu:Sorry.
Ansgar Dietrichs:Oh, maybe, Yamenu, go ahead.
Manu:Yeah, I can speak quickly about Prism. So yes, we discovered a bug in Prism, which was in the codebase for a long time, but only showed up at Fusaka on Houdi.
Manu:We understood this bug, we fixed it, we ran the fix for a little bit less than…
Manu:24 hours now.
Manu:Without any issue, and so, yes, the plan is to, to release on, next Monday.
Ansgar Dietrichs:Sounds good, Matthew.
Matthew Keil:Yeah, I wanted to just bring up something that… because we also found a bug that didn't rear its head until we got to Hootie, and it was directly related to the size of the network and the timing between columns, just because you got to a real… like, Hootie's the first real network.
Matthew Keil:with real… with, real mainnet conditions. So something that a few of us had talked about is that maybe proposing the fork transition, process has some built-in time to allow, like, like we had an issue
Matthew Keil:Prism had an issue, NetherMind had an issue, that really only showed up on Hootie. So some period of time between, when we go live with the latest fork on Hootie, and when the releases get cut, so that we have time to react to bugs that pop up, when we get there.
Barnabas:I think last week we brought up,
Barnabas:this discussion, or maybe it was this Monday, whether we would like to push for the client traces still for this week, and,
Barnabas:Technically, the conclusion was that
Barnabas:most client teams were fine to make a release this week, other than Prism, and
Barnabas:well, Luestar also had the chance to basically ask for a few extra days, but the idea was that we want to have one month between the
Barnabas:releases and mainnets, so…
Barnabas:Yeah, the only thing we could do is, possibly schedule the fork to a later date, if we need additional time between forks and, schedule.
Matthew Keil:And I understand that for this fork, I know that there is a big push, and I know that the mainnet date was kind of a really… a big goal, which I do support still. We're released and we're ready. But I'm just talking about as a process thing.
Matthew Keil:instead of having, Hootie release, or Hootie fork transition, and then release date 2 or 3 days after that, and then scheduling 30 days for, mainnet, do Hootie fork, and then give a week or two
Matthew Keil:to allow the hoodie fork to soak, to allow the BPOs, like, in this case, the BPOs didn't actually happen until, technically, the…
Matthew Keil:the fork, or the release was… needed to be ready for mainnet. So basically just saying that, like, from Hootie, you have, like, a one or two-week soak, to see how the clients do on, on the Hootie network, and then cut releases, and then 30 days to mainnet, for the next fork, or just as part of our forking process. Just a thought.
Ansgar Dietrichs:Yeah, and I think this is, in general, a reasonable conversation also for future Hard Fox. I am wondering specifically for consequences for Fusaka, are we still feeling okay, then, with going ahead with the timeline as is, though? Accepting that there will be
Ansgar Dietrichs:two releases that basically will come after the initial announcement, or is this a reason to delay?
Ansgar Dietrichs:the Fusaka timeline, specifically?
Matthew Keil:I mean, for us specifically, no, we're… our release from Initis Cut, we were able to get through that, but I know that there are other teams, obviously, you know, that have concerns, but I don't want to speak for them.
Ansgar Dietrichs:Yeah, I mean, I definitely want to give room for…
Ansgar Dietrichs:concerns, I would just kind of… my default would just be to say we go… basically go ahead with the plan as is. So, basically, now would be the time, if anyone would specifically not want us to go ahead with the Fusaka rollout plan as is, please speak up now.
Ansgar Dietrichs:Okay, then, sounds like for Fusaka specifically, we'll go ahead, as Barnabas just described, and then, yes, we should definitely pick up this, the kind of the general process conversation also afterwards, then, for future hard folks, so I agree.
Ansgar Dietrichs:Awesome. And then one last thing I saw on the agenda, that was not actually me putting it on there, so that was already on the agenda. There was a reminder, please add the relevant coordinators from your client team to this doc. There's a doc linked for the Fusaka upgrade, so I assume that's relevant.
Ansgar Dietrichs:So, yeah, just a reminder.
Ansgar Dietrichs:Okay, anything else at all regarding Fusaka? Anything we should touch on?
Ansgar Dietrichs:on this call.
Ansgar Dietrichs:Okay, so there will be a, announcement for the mainnet releases coming, and then we'll backfill the missing clients there.
Ansgar Dietrichs:And go ahead.
Ansgar Dietrichs:Awesome. Looking forward to Fusaka.
Ansgar Dietrichs:With that, then we have the rest of the call to focus on mostly Glamsterdam. For Glamsterdam, just to briefly get a small agenda point out of the way. Oh, wait, actually, wow, okay, this makes no sense, I'm not sure why I put the H-star naming under Glamstadam. Anyway, it's on the agenda, so might as well briefly get to it. There is a call for H-star naming, that's obviously not Glamsterdam-related, but…
Ansgar Dietrichs:Just… maybe someone wants to say 30 seconds?
Ansgar Dietrichs:Where people should go.
Ansgar Dietrichs:Or you can just find it on the agenda. So if you have any… if you have, opinions about the…
Ansgar Dietrichs:the way the EL and CL names for H-star should be combined, then go to the agenda and you'll find a link. Awesome. Then on to…
Ansgar Dietrichs:the, main part of the call today, which is, the first pass at Glamsterdam, fork scoping. I just put just a few notes together into just visual, like, like, like a presentation, if, maybe…
Ansgar Dietrichs:Nix or Josh, if you could share the screen for that?
Ansgar Dietrichs:Awesome. And if we go to the first slide there…
Ansgar Dietrichs:basically, the idea, so I discussed with Alex, and, and a few people, this would be my proposal for the process for today, and of course, feel free to object here, but basically, the point is we have, like, 40 ERPs, roughly. If we specifically start having individual CFI, DFI discussions today, I think that will really
Ansgar Dietrichs:blow up the,
Ansgar Dietrichs:yeah, the call, so what I would propose is that we just decide no specific decisions today. Instead, it's more about temperature checks, but I think it would be really important that we have a specific output coming out of the call, otherwise we just don't make progress. So my goal would be to navigate us through the list of ERPs. We have a really nice, convenient grouping by themes that I have on the other slides that
Ansgar Dietrichs:That gives us some sort of, like, handle to go through the DRPs, and that we come out of it. I will basically then just, in a maybe somewhat opinionated way, synthesize all the comments from the call today, and create a CFI candidate list and a DFI candidate list. This is not an official governance artifact in any form, so this has no direct meaning for the governance process, other than to guide for the call in two weeks.
Ansgar Dietrichs:to guide the discussion, so we can basically then start with the DFI ERPs. Anyone who's on the DFI list can also basically knows that the champions can try over the next two weeks, asynchronously, to convince people why their ERP maybe is important.
Ansgar Dietrichs:And that, that basically people just know the CFI candidates are the ones to also prioritize for, for potential testing scope, these kind of, these kind of things.
Ansgar Dietrichs:That would be…
Ansgar Dietrichs:my, proposal, and then process-wise, we would start with briefly just… I'd briefly just go through all the clients, ask for just, like, a one-minute summary of
Ansgar Dietrichs:have you published your opinions on general, kind of, fork scoping yet? And if so, is it, like, an EIP by EIP, or is it… just basically give us, like, a one-minute summary of basically what the client has published, if anything, in terms of preferences yet? And then I'll also give a one-minute update from the repricing side, and then we just go through the EIPs. Just wanted to briefly see, does this general process make sense for people?
Ansgar Dietrichs:If so, I would just go ahead.
Ansgar Dietrichs:And again, it's not ideal, but I think, just given that we have an unprecedented number of ERPs, this is the best
Ansgar Dietrichs:that I, and also, like, with Ala in the conversation with Alex, that, that we could see. Awesome. Then, I actually… yeah, I don't really have slides for the first part, the clients, so maybe we can stop the screenshot for now, and then I'll just briefly call on each client. Again, the idea is not that you actually, like, walk through the entire, kind of.
Ansgar Dietrichs:document that you have, the entire reasoning, just give us, like, a one-minute high level. Have you, like, what have you published, basically? I'll go through the list of the ones that I saw on the agenda. So, the first one was NetherMind, so someone from NetherMind who could very briefly.
Łukasz Rozmej:Yes, yes, we published a list, we tried to, like, tier the… the EIPs.
Łukasz Rozmej:We… it's not like if your EAP or EAP is in lower tier, we are not open to discussion, if it's… if there is a good, reason, and one of the EAPs like that is the state, for example, state,
Łukasz Rozmej:gas cost increases. We are open to discussion, we just didn't really like that much that the EAP proposed. So, yeah, so that's our thing.
Łukasz Rozmej:It is published, and, like, please also read into some details, because,
Łukasz Rozmej:Like I said, we can also… are happy to discuss the lower AIPs if there is a good reason for that.
Ansgar Dietrichs:Sounds good
Ansgar Dietrichs:And then we also have something… something published from the GATT side. Is there someone on the call that could briefly describe that?
Felix (Geth):Yeah, so, we did publish a document. The point of the document is twofold. One is just ranking all the EAPs, and we have a… explain the tier system, how we interpreted it.
Felix (Geth):we do think that there's, like, room to ship a significant number of EIPs, especially because of the repricing.
Felix (Geth):Basically, how this is gonna work is…
Felix (Geth):The way we see it is the repricing effort is not really done, and there's a lot of eaps in there, and they will all have to be…
Felix (Geth):evaluate it somehow, and then whatever comes out of this process, we can basically make it a priority to ship this, but there is no… we don't want to comment on, like, all of these individual repricing EIPs, because it's not really super clear yet which ones will really make it, or what kind of tweaking will be required. We do also think that, like, most of the other, like.
Felix (Geth):Changes that are…
Felix (Geth):can be kind of simple, like, there aren't really that many complex changes, and from our side, I guess, in our document, the main things that are actually very complicated is the,
Felix (Geth):some of the stuff we put in S tier, because we highlighted it mostly just, for… for the purpose of showing that we think it's important. So, for example, the, Trustless Log Index that, one of our guys is also proposing, Jolt7745,
Felix (Geth):that one is pretty complex to implement, but we do think it will be worth it also to, like, go for it. But most of the other EIPs are actually very simple changes, just, like, a bit of extra logic in the gas, or just changing some numbers and so on. So we think we can actually ship quite a few EAPs in this fork, and this is the sentiment that I wanna…
Felix (Geth):mostly convey.
Ansgar Dietrichs:Awesome. Thank you. Next up, we had a document by Aragon.
Andrew Ashikhmin:Yes, so we've published our stand on most AIPs. We have some question marks, and it means we either didn't have a chance to look into it, or maybe, like, people don't have an opinion or don't care, but yeah, for most, we have either yes or no. I… like, I think…
Andrew Ashikhmin:I would actually, like, I met a comment. I would err on the side of rejecting EIPs, not because I don't like EIPs, but because I think we should
Andrew Ashikhmin:Prioritize headliners, and avoid the same mistake that we made in
Andrew Ashikhmin:in Pectra, when we, actually tried to squeeze too much into it, and then we had to split the hard fork. So, like, on, at least on, on our side, the EL headline, block access list will require a lot of work.
Andrew Ashikhmin:a lot of work, so I would rather…
Andrew Ashikhmin:Do a small number of low-hanging fruits.
Andrew Ashikhmin:and not jeopardize block access lists, rather than be too greedy and try to squeeze too much. As to repricing.
Andrew Ashikhmin:I think that… I quite like the approach that we took in Fusaka, during the peripher…
Andrew Ashikhmin:I would actually keep doing the same, namely, just start, repricing the, bumping the price of the most, underpriced things. I think that will be more helpful with scaling than.
Andrew Ashikhmin:Like, this general repricing that effectively means lowering
Andrew Ashikhmin:the cost of computational op codes, and to me, it's a low, like, priority, because, well, yeah, I mean, computational op codes are a small part of the total gas schedule, while the effort to do it, like, comprehensively is quite big.
Andrew Ashikhmin:Yeah, so I would, in terms of repricing, I would concentrate on low-hanging fruits.
Ansgar Dietrichs:Sounds good. Then next up, we had comments from Red.
Jen:I also posted, our stance, earlier today. So, there's lots of EIPs, limited time. The way we approached it is.
Jen:We just gave our high priority EIPs, and then also kind of, like, Tier 2 EIPs, happy to refund the format and do another iteration. So the way we looked at
Jen:EGLP, like, in the list, like, we looked at two angles.
Jen:What is the performance impact? And here, we were mostly looking into, like, the repricing piece that we would like to prioritize.
Jen:And I think, like, we think this one facilitate lots of performance optimizations. And then secondly, how will the CIP,
Jen:Improve developer experience, And, yeah, those are the two, kind of, decision parameters that we're going for.
Jen:Happy to discuss any of those and edit more details on the impact and the why in the post.
Ansgar Dietrichs:Sounds good. And then we had a… well, before we get to numbers, maybe briefly, so I don't think there was a document published from the BESU side, right? I just wanted to ask, basically, like, where are you at in terms of your internal evaluation? Do you have some general, kind of, high-level views already on…
Justin Florentine (Besu):We do.
Ansgar Dietrichs:What you would prefer to prioritize in the park?
Justin Florentine (Besu):We do, Anskar. So, we have not gotten to the point where we're ready to publish, however, we have
Justin Florentine (Besu):consensus circling around fossil in our S tier, and 5, 6, maybe 7 of the gas repricing EIPs. So, we have specific opinions on the ones that we think are ready to go and aren't.
Justin Florentine (Besu):We are not ready to publish at the moment. We will be next week, just need a little bit more time, but the general shape of things for our S tier is fossil, and then…
Justin Florentine (Besu):gas repricings, and then, you know, an assortment of other things. I think we kind of concur with what Geth is saying, that most of these things
Justin Florentine (Besu):Do seem fairly low effort, and should be, famous last words, but they should all fit in a hard fork.
Ansgar Dietrichs:Sounds good. And then we had, comments by, Nimbus, so specifically, like, scoped around the Purith kind of effort, obviously kind of more cross-layer, so do we have someone to comment on this?
Dustin:Yeah, sure. So…
Dustin:In general, obviously, I… those are… so the SSC-based ones, so 7688, obviously, I don't want to get… well, but broadly speaking, it's, let's say, what we're oriented towards is a subset that we think is a safe subset of the period.
Dustin:And I want to explicitly kind of orient this, that there's parts of Pirate that we think are not yet ready, actually, and see the document, the Pirate.guide document linked in there for details, but that should specifically not be in Amsterdam. But we think there are
Dustin:up to about a half dozen EIPs, which would fit in Amsterdam, yeah. Now, the Nimbus also has, views on, so there's a…
Dustin:MaxBobs is… is something that we support, although…
Dustin:I think with a caveat that it's granted not really a consensus EIP, it doesn't actually matter that much.
Dustin:Clients can implement it either way or not. And
Dustin:I… specifically, regarding the repricings, I do want to sort of say, I'm coming… the… the call data… any… the call data one, I think, is… is to…
Dustin:from our perspective, the highest priority one, because that is the hard blocker. Anything which affects block size becomes an absolutely hard blocker on scaling, without significantly more networking changes.
Dustin:And everything else is, you know, some clients bounce around in performance, and that's fine.
Dustin:But that… I think that… if none of the other repricings go in, we want that one to go in.
Dustin:And then otherwise see the documents.
Ansgar Dietrichs:Sounds good.
Dustin:Okay, yeah, so that's true. Sorry, sorry, I want to agree with, Lucas there. I didn't include it, but I agree. Act.
Ansgar Dietrichs:Okay, so basically you're just saying you have a special focus around the size-related repricings. Okay.
Dustin:Yes, yes, as opposed to the ones which are sort of benchmarking, which we're all obviously in favor of, get that as accurate as possible, but, but those are a little bit lower priority.
Ansgar Dietrichs:Sounds good, thank you. And of course, just to clarify, right, for people, these are more CL-side requests about EL priorities, so obviously, somewhat of a different relationship here than from the other client's point of view, but, yeah.
Dustin:Well, yes and no. We have an EL. I mean, granted, it's not used by, you know, we… but it is released. It's alpha, sure, but…
Dustin:So, we do have an EL…
Dustin:centric, to some extent, perspective on this, but… but I will agree that it is not primarily what people… it is not the Nimbus people are using right now.
Dustin:But we have people.
Ansgar Dietrichs:Yeah, yeah.
Dustin:would work.
Ansgar Dietrichs:It makes sense. I really just only meant it as, like, just for people following, kind of, as a general kind of categorization, governance-wise, but yeah, no.
Dustin:Fair enough. Yeah.
Ansgar Dietrichs:Makes sense. Awesome. Thank you, Dustin.
Ansgar Dietrichs:Then, again, moving on for now, actually, I had two small things, before we get to the repressing summary, just to mention, specifically as part of the process decisions.
Ansgar Dietrichs:Alex and I also discussed that it would make the most sense for Fossil, given that it's a cross-layer change that is more CL-heavy to begin with, and the CL has much more
Ansgar Dietrichs:discussion… decision bandwidth this time around for the hard fork, that we will just make a decision to have the exclusive discussions and decisions around fossil on the CL side, meaning ACDC. So, for anyone from the EL side that obviously wants to participate in that, wants to have opinions, please come join the ACDC calls. We will not have time to discuss
Ansgar Dietrichs:Or make decisions about fossil here on the ACDE calls.
Ansgar Dietrichs:So, that just… and of course, with the asterisk that whether or not we actually include fossil will inform and change maybe how much room we have on the EL side as well, but the discussions and decisions will happen on ACDC.
Ansgar Dietrichs:And then the other point I wanted to briefly mention, just because people have mentioned it, block-level access lists, I also want to take… to just give into consideration that on block-level access lists, there is specifically several
Ansgar Dietrichs:optimizations beyond the base spec compliance that, all require significant work and clients to support.
Ansgar Dietrichs:And we might end up deciding to ship them, as basically as expected feature sets, so basically that is…
Ansgar Dietrichs:Transaction parallelization, that is, parallel state with computation, that is using, for, for clients that, that, for the firm that makes sense, using the state diff for, for syncing, and that is also, parallel loading of, of, of state.
Ansgar Dietrichs:Any of these, we might end up deciding this is an optional performance improvement, or this is a… basically, this is something that we expect all clients to support by the time of the fork.
Ansgar Dietrichs:where we land on each of these points in terms of decisions also influences the focus scope, right? Because if there's more expected as minimum support, as guaranteed support for bulk club access lists, that of course limits somewhat the remaining throughput that clients have to develop other features. We will not discuss this today, but maybe in two weeks, we can also make decisions around what is the expected
Ansgar Dietrichs:feature set around block-level access lists to support. So, just wanted to highlight that, and because it's relevant here.
Ansgar Dietrichs:With that out of the way, I think we can jump back into the presentation, because I had one slide with
Ansgar Dietrichs:Quick, update from the repricing,
Ansgar Dietrichs:breakouts, and then wanted to go to the main ERP discussions.
Ansgar Dietrichs:Exactly. So, and again, of course, please take… keep in mind that, as I go through this, that I'm obviously biased here myself, as one of the people involved with the repricing, so take that with a grain of salt, but I'm trying to be as neutral as possible,
Ansgar Dietrichs:So we had two breakouts, these last two weeks, and just very quick high level, there's basically two types of ERPs. You'll also see this in a second when we walk through the ERPs.
Ansgar Dietrichs:One of them is core. Core does not need to be a priority statement. It just means core repricing is anything that really just changes the price, nothing else. It does not change, kind of flip the logic. The idea there is really just to take all the operations and kind of basically try to make them all cost the same gas per second of effort, either on the transmission side, or then on the execution, loading, whatever side, basically.
Ansgar Dietrichs:the same worst-case time per operation, basically. That is the core intent around core repricings, and there's, I think, 6 or 7 EIPs specifically in that bucket. And then there are several more. It's a larger number, like around 10 individual EIPs that want to make changes to specific parts of the pricing logic.
Ansgar Dietrichs:to make this more efficient. So you can think of it as this kind of core that at least is proposed to be treated as a bundle, and then all the other ones are individual yes-no decisions, basically.
Ansgar Dietrichs:the recommendation from the repricing champions was to, basically, to CFI this kind of the score bundle. Again, we will not make CFI decisions today anyway, but this would be the recommendation. But I wanted to highlight that that is not necessarily yet universally supported across participants of the breakouts.
Ansgar Dietrichs:In particular, there's still some worry around
Ansgar Dietrichs:the significant remaining work on the benchmarking. We also heard this from the Aragon statement, for example, today. And there is, indeed, the option to say, like, we might, for example, we could on all could have decided to generally CFI the overall kind of, like, core repricing effort, but with the asterisk that we will rework the exact scope, and it could be limited to, for example, only treat a subset of the operations that have especially bad performance or things like that
Ansgar Dietrichs:So basically, the exact shape of this core bundle is still somewhat in flux. And then the only other thing I wanted to briefly highlight is that there was one EAP in particular out of these optional editions that seemed to have universal support, so this is, like, at least on my kind of top of my potential CFI candidate list, which is the 778-7778 refund logic change. That one seemed to have universal,
Ansgar Dietrichs:Approval across the board.
Ansgar Dietrichs:Yeah, that's all from the summary, and then I would just jump to the next slide and just start the main EIP discussion section. Again, if we get through all of this, if we get through all 40 EIPs and we still have some time, we can actually see if we might make
Ansgar Dietrichs:final decisions on anything already today, but for this first walkthrough, we would just not actually make any CFI or DFI decisions, so I'll just… for each of these bundles, I'll just basically, like, briefly,
Ansgar Dietrichs:highlight, what the bundle… what this kind of this cluster of EFPs is about, and then just ask if any clients have general opinions on whether they would want to CFI or DFI any of them. The first one is a bit special, because again, it could be treated as a bundle. So this is the core… these core repricing ERPs, so these are all of the ERPs that touch
Ansgar Dietrichs:directory pricings related to bandwidth, state, data, or memory, or state growth. Do we have
Ansgar Dietrichs:general client opinions on, is this a CFI candidate as a bundle for people, is it a DFI candidate, or would you reject the bundle approach and just CFI or DFI individual EIPs?
Andrew Ashikhmin:Well, so, I would actually reject the bundle approach and CFI or DFI individual IPs. I think, like, because general repricing, like, the meat of it is, lowering the cost of,
Andrew Ashikhmin:computational opcodes,
Andrew Ashikhmin:maybe you can transform it into something else, but that's what its de facto stands for, and I think… I would be happy with them cover EIP to…
Andrew Ashikhmin:bump, the price of the most underpriced things, like we did with, with Modex.
Ansgar Dietrichs:Sounds good. And I'll also try to,
Ansgar Dietrichs:keep everyone's comments to… like, try to be as concise as possible, basically. Justin?
Justin Florentine (Besu):We really appreciate the bundling and the effort that went into bundling them, and we found it very helpful in our reasoning. However, we do not think that they should be included as bundles, or should be considered as bundles for inclusion, and rather they should be examined on a one-on-one basis.
Ansgar Dietrichs:Sounds good, Carl.
Carl Beekhuizen:Yeah, I want to flag a few things. One, it's already been said a few times that people are more for making some things more expensive as opposed to others cheaper. Repricing is a relative thing.
Carl Beekhuizen:So if we make one thing more expensive or another thing cheaper, that's effectively the same. The second thing is, what's called generary pricing here is basically just the compute side of certain opcodes.
Carl Beekhuizen:I think the name is a little bad, and then the third thing is that if we really want to start pushing the scale of Ethereum and the EVM, we're going to very quickly start running into state bottlenecks. That's for both, like, history, like, state growth sites, and for just…
Carl Beekhuizen:like, the amount of time it takes to do reads and writes, which I think are also mispriced. So, I don't think it's as simple as, oh, we can just bump a few things up. I think, like, we should… if we really want to start pushing to, hundreds of millions and eventually gigas, then we're going to need to do things about state as well, and this would be a good time to do that.
Ansgar Dietrichs:Sounds good, Maria.
Maria Silva:Yeah, so I, I would just, add a point for arguing in favor of the bundle. So.
Maria Silva:In my mind, the reason for bundling is that
Maria Silva:if we reprice certain things. So, for instance, if we were to solve a few bottlenecks on the compute size, on the compute side with the 7904, we would not be solving
Maria Silva:all the bottlenecks we had. So, we would be solving some of the bottlenecks, but this means that then states and data, for instance, would become bottlenecks, and we would not be able to raise the gas limit. So, in my mind, this is really
Maria Silva:the minimum bundle that touches enough resources so that we can remove all the bottlenecks and continue to scale. And again, another point for doing this as a bundle is that these prices must be
Maria Silva:must make sense together. So, if we reprice things without changing some other things, we might be missing relevant bottlenecks there. So, I think it's…
Maria Silva:These bundle, these… the…
Maria Silva:idea that we need to benchmark all these things, all these key resources, and we need to make them work together for a certain target gas limit that we want to reach in
Maria Silva:in, Glamsterdam. And then there's some discussions on scope, maybe there's some, operations that are not as mispriced as
Maria Silva:as that, and so we can just leave them be, but we need to consider them holistically, and I think that's why, like, we need resources to do this, and so I think it's important to treat them, together.
Ansgar Dietrichs:Okay, thank you. Dragon?
draganrakita:To be honest, I would like to have them as separate therapies.
draganrakita:But look at them as the group, I see there are two groups here. One is increasing, any storage or creation of the contract.
draganrakita:this needed if we want to have… if we want to slow down the expansion of the state. A second group is maybe nibilation of gas and, like, removing…
draganrakita:At potential edge cases where the guys is not priced correctly.
draganrakita:I would say that…
draganrakita:First part, first group, where we need to increase the gas for creation or access to the state, is more important.
draganrakita:But either way, yeah, that's my comment on this.
Ansgar Dietrichs:Sounds good. And, Justin?
Justin Florentine (Besu):And then, probably, last comment for this section.
Justin Florentine (Besu):I just want to ask the group, how confident are we that these interactions are even discoverable at design time as opposed to test time?
Justin Florentine (Besu):I think that's, you know, we're gonna do our best to really make sure that we have that nailed down at design time, but it's inevitable that we're gonna find interactions much later in the testing process, so…
Justin Florentine (Besu):I appreciate the points that Marie and Carl are making with regard to the bundling and how they work. I'm just a little apprehensive that that's doable.
Ansgar Dietrichs:Sounds good. Ben, do you think you can take this to chat, or do you want to very briefly say…
Ben Adams:Yeah, just… just my crea… my concern on the increase
Ben Adams:of the state creation. So it's operating on a different dimension.
Ben Adams:So, if that caused the gas price to fall, because now things are expensive, then
Ben Adams:People can create the same amount of state, just everything is now at a cheaper gas price. So it…
Ben Adams:My concern is it doesn't necessarily
Ben Adams:The other ones are, like, how much can you fit in a block? But since they're operating on a… the increases to state are operating on a completely different dimension.
Ben Adams:It may not have the intended effect. So, for instance, if the gas price fell because of them.
Ben Adams:Then people could afford to put more in a block.
Ben Adams:If you see what I mean. It's not… it's not a hard control.
Ansgar Dietrichs:Makes sense. Then, just to briefly synthesize, right, like, I think there have been kind of some concerns around the general bundling approach, but also some pushback, so that is a topic we'll have to resolve. And then, I think state growth is just a kind of, like, a bit separate from everything else, so we probably, like, should have a separate conversation
Ansgar Dietrichs:offline, and then also in two weeks, about, like, the specifics of the state growth approach here. And I think there are also alternative approaches that have been
Ansgar Dietrichs:proposed since.
Ansgar Dietrichs:Okay, then, for now, moving on from this section, and again, this section was a bit special, because it was more about this bundling nature. Everything else from now on should be more homogenous in terms of conversation, because it's all more individual yes-no questions, so if we go to the next slide, we will have two more slides about repricing APs. There were a lot of repricing APs, but these are more individual features.
Ansgar Dietrichs:M…
Ansgar Dietrichs:From this list, again, recommended here was just specifically purely based on Maria's, and I had some input in this as well, subjective view, so this is not… there's nothing objective about these recommendations, other than that we think these are the more interesting ones of the repricings. From this list, are there ones that the clients really like, that you really like, or that you really would prefer to see in DFI for this hard fork?
Ansgar Dietrichs:Andrew?
Andrew Ashikhmin:Yeah, I would deify the milligas approach. I think we have much bigger fish to fry, and the, like, the…
Andrew Ashikhmin:Improvement, the potential improvement in precision is not worth the complexity.
Ansgar Dietrichs:Sounds good.
Ansgar Dietrichs:Lucas?
Łukasz Rozmej:I'm especially for the first to hear, the, like…
Łukasz Rozmej:to… for the refunds to not affect gas limit computations, this seems like a protocol bug to some extent, like an omission, and the limit on the transit storage needs to be set, because I think the worst-case scenario on transit storage allocate quite a lot right now.
Ansgar Dietrichs:Makes sense. And by the way, this reminds me, just… I wanted to mention, you offered reached out to me, that there are some concerns about the compatibility with account abstraction approaches, specifically around 7971, so that's something we should figure out offline. Felix?
Felix (Geth):Yeah, I just wanted to say that, like, regarding the DFI, we were also discussing this EIPAT58,
Felix (Geth):So, yeah, so in general, we were… in Geth, we think that this, like, 8053, 8059,
Felix (Geth):it's not really the good time right now to do this, and I mean, there's some… there's… these concerns are valid, that the gas is not precise enough, but we still feel like
Felix (Geth):is not important now, so basically same as Aragon. And then for the last one, it also seems kind of optional. So, yeah, there is some… it's also one of these things. It just makes it more correct somehow, but we don't think it's the biggest blocker, so we would, opt to, like, DFI the bottom three, at least right now.
Felix (Geth):Just so we have less things to consider.
Ansgar Dietrichs:Sounds good. Any other opinions?
Ansgar Dietrichs:Marius?
Marius van der Wijden:Yes, for the hard limits for transient storage.
Marius van der Wijden:As I understand it, this will interfere with, AA?
Marius van der Wijden:I would like to… hear more from…
Marius van der Wijden:the author and maybe the AA teams, how they think about this. Not on this call, but maybe on the next call.
Marius van der Wijden:Yeah, so if the… I think it's…
Marius van der Wijden:It's Charles, if… I don't know if you see it, but… yeah.
Marius van der Wijden:Yeah, exactly. I think that.
Charles:Yeah, well, too.
Marius van der Wijden:There needs to be more work in going into this before I can…
Marius van der Wijden:Yeah, before I feel it's… it's… it's right for me now.
Ansgar Dietrichs:Sounds good, Maria?
Maria Silva:Yes, I, I would, I would, argue, in favor of 8032, so size-based storage cost pricing. So, I think…
Maria Silva:From the, core bundle, the state's, growth EIP, some people raised the concerns of the
Maria Silva:The values being a bit too high.
Maria Silva:And I think adding this IP would actually help there, because what we are doing here is we are
Maria Silva:making, accessing and writing to large contracts more expensive, so that the
Maria Silva:Base costs for the rest of the contracts don't need to be as expensive.
Maria Silva:So I think this helps both with state growth, but also with the parts of state access that are hurting us the most at the moment. And so I would argue in favor and for not, EFI-ing this one for now.
Ansgar Dietrichs:Sounds good. Any other comments regarding any of these?
Ansgar Dietrichs:I'd wonder… Otherwise, open, yeah.
Ben Adams:For 8032.
Ben Adams:I like it. I'm wondering if we'd want to bring the limit down a bit more.
Ansgar Dietrichs:Yeah, I think adjustments, but I would say we should probably discuss adjustments offline, right?
Ben Adams:Yeah, but it's… it's a good one.
Ansgar Dietrichs:Sounds good. Awesome. Then I think we can move on to the next slide.
Ansgar Dietrichs:So we have one more batch of repricing-related ERPs. This was also all the ones that were initially repricing-related in the later blocks, I think there's one or two that also could plausibly be in the repricing camp, they just…
Ansgar Dietrichs:were not on this list yet, so… so I put them into the data blocks. So, these ones…
Ansgar Dietrichs:Oh, sorry, the first bullet point, obviously, ignore. This is just a formatting issue. So it's 5 more EIPs, chunk-based code localization, linear page-based memory costing. This one specifically also has some account obstruction issues.
Ansgar Dietrichs:Warm account rate metering, multidimensional gas metering, and interblock temporal locality gas discounts.
Ansgar Dietrichs:Do we have… Clients with opinions on… on any of these, either in the positive or negative direction.
Łukasz Rozmej:Interlocked temporary local gas discounts, I'm very against that, and I think we came to that consensus in the team. It's…
Łukasz Rozmej:it makes very hard, for example, if you don't have balls, and in Archive Node you don't have balls, to trace some old blocks, etc, do some things like that. Like, it might be very, very complex to get there.
Ansgar Dietrichs:Kuh?
Carl Beekhuizen:Yeah, just to flag that there's, an alternative EIP47923, which does linear memory costing, just without the paging.
Carl Beekhuizen:Which is a little simpler, but has different sets of trade-offs, so… should be considered…
Carl Beekhuizen:As an alternative and trade-off, if people are interested or not in The memory costing stuff.
Carl Beekhuizen:Link in the chat.
Ansgar Dietrichs:Yeah, and I think that one is on one of the later slides. I agree, it should be conceptually here, just didn't make the cut in time when we created these.
Ansgar Dietrichs:Ben?
Ben Adams:Assuming we do quite a large number of the other repricing EIPs, then… 8…
Ben Adams:011, multi-dimensional. It might be, too much in Amsterdam, and might be better to see how everything plays out, and then
Ben Adams:Reassess what we want to do there.
Ansgar Dietrichs:Sounds good. And of course, also just for context, right, like, these were also the EPs that, from the, repricing champion sides, it was more like uncertainty about whether they should make the cut for Glam Center.
Ansgar Dietrichs:Awesome. Any further comments on this list? Otherwise, Marius?
Marius van der Wijden:Yeah, so regarding AT57, we are also strongly against this,
Marius van der Wijden:this idea has come out multiple times in the past already, and Martin has had written a…
Marius van der Wijden:A,
Marius van der Wijden:A pretty good explainer for why this is not, good, and the drawbacks it has, and why we shouldn't do it.
Marius van der Wijden:Back in the day, so, yeah.
Ansgar Dietrichs:Sounds good. And Charles, as non-Quitive, I would ask you to basically try to keep the comment concise.
Charles:Yes, I'm one of the authors of 79.3, and I just wanted to comment that we did some more benchmarking today, and I think we'll make some simplifications.
Charles:2000.
Ansgar Dietrichs:Yeah, I think simplifications was one of the things people were asking for there.
Ansgar Dietrichs:Okay, then I think we can move on to the next section.
Ansgar Dietrichs:And…
Ansgar Dietrichs:So these are individual EVM improvements. We have the payoff code, we have revert, revert creation in case of non-empty storage, linear EVM memory limits.
Ansgar Dietrichs:Slot num op code, guess to ETH opcode, setDelegate instruction, call and return opcodes for the EVM, static relative jumps and calls for the EVM, and backwards compatible swap end, dupe N, and exchange. Do we have…
Ansgar Dietrichs:CFI or DFI, opinions from any clients regarding any of these?
Ansgar Dietrichs:Ben.
Ben Adams:Strong… strongly in favor of 8024.
Ansgar Dietrichs:Sounds good. Andrew?
Andrew Ashikhmin:So, I think 7610 is already implemented by everyone, so it's in the tests, it's in the clients, it's enabled retroactively, so I don't see how it should be part of the Glamstadum discussion.
Andrew Ashikhmin:And,
Andrew Ashikhmin:also about the 7979, I think it's, we shouldn't do… go there. We should do EOF, or, like, reconsider EOF.
Andrew Ashikhmin:We… because it's a superior alternative. Like, if we want to do something like that, we should do EOF.
Ansgar Dietrichs:Sounds good. Felix?
Felix (Geth):Yeah, so I just want to give some quick comments. So we think that EIP7843 slot numb opcode is a pretty easy addition, and we feel it's… we should just…
Felix (Geth):basically, included.
Felix (Geth):we feel similar to about the 8024, so I think all clients agree that this change is very low complexity in implementation, but it has a high impact for the application developer, so I feel like we can even make the call about it today.
Felix (Geth):Everyone… Seems to be in favor of it so far.
Felix (Geth):Regarding some of the other ones…
Felix (Geth):We did, look a bit into 7791, gas to ETH, there is…
Felix (Geth):It's hard to say, but we feel like this should not happen, so we are against this one.
Felix (Geth):It's,
Felix (Geth):not exactly so easy to explain, but the mechanism itself, like, there is some merit to it, but at the same time, it really, it can have some unforeseen consequences, and, like, if we really want to do this, this requires a lot more justification. So we feel like if everyone…
Felix (Geth):Is against it, we might as well exclude it right away.
Felix (Geth):And then, yeah, I mean, I think other team members may have more opinions, so I will just also leave it to them. In general, we didn't really have too many of these EAPs in the high tiers, so most of these we either ranked as, like, being
Felix (Geth):kind of strictly optional, if there's some capacity to implement, or we just reject them. So, yeah.
Ansgar Dietrichs:Sounds good. And again, as I said, just in… for the sake of getting through the entire list once, I would not, during this initial rundown, make any final decisions, but if we have time at the end of the call, I'm happy to just give room for open
Ansgar Dietrichs:Space for individual, final decisions people want to propose making, and then the discussion attached to that.
Ansgar Dietrichs:Any other comments, opinions, plus or minus, towards any of these EIPs on the list, Dragon?
draganrakita:7610. This is the case where that's kinda not possible to happen on Manet, but it gives us a lot of headache in testing.
draganrakita:we had some chats in Discord about this, but I'm not sure if anything is clued. Is it…
draganrakita:is concluded. We would like to remove that therapy.
Marius van der Wijden:Yeah, so I think we at some point, had already shipped the DIP7610.
Marius van der Wijden:Or, like, all the clients have agreed to that at some point, and we retroactively, did it. The only reason why it is on this list again is because we have been talking about it.
Marius van der Wijden:And… Yeah, the question… Was whether we want to
Marius van der Wijden:make the decision to reinforce that this is the rule, or we want to make a decision to change that rule. And,
Marius van der Wijden:Yeah.
Marius van der Wijden:This doesn't need… to… Yeah.
Marius van der Wijden:We should, we should, we should just, not take…
Marius van der Wijden:up time to discuss the CIP.
Marius van der Wijden:At this time.
Ansgar Dietrichs:That's good.
Ansgar Dietrichs:Raidan, do you want to respond?
draganrakita:I agree, that's it. Yeah, other than that, 802524, sounds great.
Ansgar Dietrichs:Sounds good. Felix, do you still have your hand up? Do you want to say something more? Is that just an artifact from your last comment?
Felix (Geth):Sorry, I just didn't lower it.
Ansgar Dietrichs:Sounds good. Mariam?
Mario Vega:Hey, yes, I think, we have analyzed many of these, EIPs, and I think the one that stands out as, like, something many client teams want to do is 8024, and we also analyzed this, from a testing perspective, and it's… I mean, it's not free, but it's, like.
Mario Vega:relatively, straightforward to test, so I think we would support that from the, yeah, from the testing team, yeah.
Ansgar Dietrichs:Sounds good.
Ansgar Dietrichs:Any further comments on this block? I think this is the largest set of individual earpiece on these slides.
Ansgar Dietrichs:Okay, then we can go to the next slide.
Ansgar Dietrichs:These are just a few ones,
Ansgar Dietrichs:We already heard a little bit about… about the period,
Ansgar Dietrichs:topic, so we have, SSE transactions, SSE receipts.
Ansgar Dietrichs:And I think the last one is actually just a CL site feature, if I'm not mistaken. But anyway, do any of the clients have opinions on either these specific earpiece, or maybe the kind of the question of the pure ETH effort regarding Glamsterdam in general?
Ansgar Dietrichs:Justin?
Justin Florentine (Besu):Yes, we're generally against SSZ, both 6404 and 6466.
Justin Florentine (Besu):Yep.
Ansgar Dietrichs:Sounds good, Andrew.
Andrew Ashikhmin:So, I think it should be part of, like, Purith should be a separate headliner, so it should not definitely be in Glamstadum, it should be discussed as its own headliner.
Ansgar Dietrichs:Sounds good. Any further comments on this?
Dustin:Yeah, so one… one point I'd like to make regarding the separate,
Dustin:separate headliner. Obviously, it was submitted as a headliner. Beyond that, though, the headliner, there are many parts of this which are clearly not ready for Gramsterdam, and… and so…
Dustin:Purith as one big unified headliner probably is not ready. However, there are parts which do look…
Dustin:potentially quite useful. And so… and one way of looking at this is a subset scope of PRETH. So, which is to say, more than one EIP, sure, because they…
Dustin:All kind of, complement each other. And…
Dustin:but that are not necessarily waiting for… for example, we've talked about the log indexing, here. Well, I mean, that's… there's a lot of skepticism of that one for various reasons. Out of scope of my comment here, but… but that… a full pure ETH implementation would have to address this. But… but rather than wait for the… necessarily.
Dustin:log indexing, to, to be resolved. Do things that are… that do achieve something useful.
Ansgar Dietrichs:Sounds good. Lukash?
Łukasz Rozmej:So, as much as I would like to have those, I don't think we have…
Łukasz Rozmej:scope to prioritize this, so I would just decline it at the moment. It's not… we have more important things, in my opinion, in the pipe.
Ansgar Dietrichs:Sounds good. And then as a general process comment, right, so this is kind of the intention for today, so I will… unless there's more comments here on this point, I would probably come out of this having, kind of these SSE EIPs on the DFI candidate list, which means that then also, like, for the next two weeks, you know, for a champion like Bestin, that would… that would basically be specifically.
Ansgar Dietrichs:and…
Ansgar Dietrichs:a hint that, like, okay, if I want to convince people to revisit that decision, the next two weeks would be really crucial, because, like, in two weeks, we might then make a final DFI decision here, so…
Ansgar Dietrichs:That's kind of the idea of this process, right? So, this would…
Ansgar Dietrichs:For now, basically be a clear indication that this is where this is headed.
Ansgar Dietrichs:Do questions to have you on top, or…
Łukasz Rozmej:Sorry, I'll just hang up.
Ansgar Dietrichs:Yeah, no worries. Awesome. Any further comments on, on this section? Otherwise, we can…
Ansgar Dietrichs:Move on, okay, then we can go to the next slide.
Ansgar Dietrichs:Yes. So, contract, contract deployment related. We have the, removing the init code size limit, we have the…
Ansgar Dietrichs:contract code size related, and we have the deterministic, factory pre-deploy. I think the first two are conceptually a bit closer, regarding the, kind of, the limits around the deployment itself.
Ansgar Dietrichs:The third one is more utility EIP. Note that there is also a related EIP in the general repricing section that would otherwise allow for
Ansgar Dietrichs:larger contracts, so there is some interdependency here. Do we have…
Ansgar Dietrichs:Clients with, opinions on either of those three.
Ansgar Dietrichs:Andrew?
Andrew Ashikhmin:Yeah, I think, we should, do 7907. It's just, it'll help, smart contract devs.
Ansgar Dietrichs:Sounds good.
Ansgar Dietrichs:Any other comments?
Ansgar Dietrichs:Felix?
Felix (Geth):So, yeah, in our ranking, we did rank 7, 9, or 7 very low, and the reason for that is that we think it would be much better to go with the chunk-based code localization scheme.
Felix (Geth):We're just basically, like, we're just no longer… we're no longer really, like, pursuing this EAP anyways.
Ansgar Dietrichs:Sounds good.
Ansgar Dietrichs:There was also comments, I think, if I'm not mistaken, I just want… I'm gonna briefly double-check that there was…
Ansgar Dietrichs:that the chunk-based one was mentioned in the possible editions section, so the last page of the repricing earpiece. We did not have comments
Ansgar Dietrichs:They are, so if, I mean, if someone basically has an opinion on that, that comes up, came up to them right now, also, we could still hear that. That's 2926 junk-based code localization. That is conceptually related here.
Ansgar Dietrichs:Andrew?
Andrew Ashikhmin:Well, I think it should be done when we actually decide to do a vertical, or the binary tree, or something like that, because…
Andrew Ashikhmin:I wouldn't do it ahead of it.
Ansgar Dietrichs:Makes sense. Ben?
Ben Adams:Isn't a chunk base quite expensive? So when you deploy a contract, you'd have to chop it into tiny chunks, and then recognize it. So it's suddenly much more expensive to deploy a contract than it.
Ansgar Dietrichs:Gil, maybe if you want to directly respond to that?
Guillaume:Yeah, I'm not sure why you say it's more expen… much more, I mean, yes, of course it's gonna be more expensive, because you need to do some chunking, but it's just about adding bytes every 31 bytes, so… not sure why you say it's much more expensive.
Ben Adams:Oh, I see any need to make a tree, and… yeah, anyway.
Ben Adams:We can take it offline.
Guillaume:Yeah, okay, let's do this.
Ansgar Dietrichs:Yeah, I think I have heard some efficiency questions around this AP specifically, so I think offline is a good…
Ansgar Dietrichs:Place a dragon.
draganrakita:I just want that it is complex, because it touches a lot of things.
draganrakita:Merkel base, con- Merkelizing the contract.
Ansgar Dietrichs:Makes sense. Then maybe one question that I would have here would be, so obviously here on this list, like, as we said, 7997 is a bit separate, it's more a convenience feature. I think 7903, we can also basically, like, mix and match with anything else, but in terms of a strategy for increasing the maximum contract size allowed,
Ansgar Dietrichs:we would basically have the three approaches of doing nothing in Ramsadam, doing the one that's listed here, 7907,
Ansgar Dietrichs:or… which is, I think, what we also discussed for Fusaka and then ended up not doing, or doing this chunking-based approach.
Ansgar Dietrichs:in general, do not… instead of just, like, opinions on the individual year piece, do clients have, like, a preferred out of those three options, basically? Like, a specific preferred strategy of what we should do with contract size in Glamsterdam?
Ansgar Dietrichs:Lucas?
Łukasz Rozmej:So, Nevermind is required for 7907, we just voiced the same, things we were voicing when it was proposed for Pectra, or, sorry, for Fusaka, that, the size increase might be too steep for us. We would prefer something less steep.
Łukasz Rozmej:Like, 64 kilobytes, or around that number.
Ansgar Dietrichs:Sounds good.
Ansgar Dietrichs:Anyone else with, opinions here?
Ansgar Dietrichs:Guill.
Guillaume:Yeah, I mean.
Ansgar Dietrichs:size.
Guillaume:Yeah, it's just, like, 7907 is completely redundant with, with 2926. Okay, there's been some claims of 2926 being more complex. I obviously disagree, having, considered those things.
Guillaume:for a long time, of course, we will take that offline. But, yeah, like, this is guaranteed to be… what I mean is 79…
Guillaume:07 is guaranteed to be completely redundant as soon as 2926 or any tree change happens, and therefore, what's the point of doing it, basically?
Ansgar Dietrichs:Right, and I… at least it is important to highlight that, indeed, it would not make sense to ship both of them, so they're, in a sense, alternative approaches here. Andrew?
Andrew Ashikhmin:Well, I think, like, 2926 should be actually done, when we decide on, on the binary, like, on doing the binary tree or whatever, because,
Andrew Ashikhmin:What 7907 buys us?
Andrew Ashikhmin:In the meantime, it just makes the lives of smart contract devs easier, so we can, if we decide to go with 2926 in the future, we just replace 7907 with it, so it's not a big deal.
Andrew Ashikhmin:In terms of…
Andrew Ashikhmin:yeah, there will be some coding, but I think it's quite alright. My worry with 2926 is that,
Andrew Ashikhmin:If we do it ahead of the binary tree, then we may end up with a different design, and then it somehow
Andrew Ashikhmin:The current iteration of 2926 is somehow suboptimal, with the updated… for the updated design, or we don't do the binary tree at all, and then it becomes a bit strange.
Andrew Ashikhmin:Yeah, I think it's just premature to do it.
Ansgar Dietrichs:Yeah, one last comment from Guillaume here.
Guillaume:Yeah, I'm not sure what you mean by strange, but, indeed, like, the binary tree EIP needs to happen. If it never does, and it makes no sense to do it without having ZKVM, so we're definitely…
Guillaume:not having it anytime soon. That means you still have very large witnesses, which 2926 solves.
Guillaume:You still have Prover Killers, which 2926 solves, and…
Guillaume:it allows you to remove the code size limit completely, instead of having this half-bake, oh, you're gonna pay for it, but only half the time. And, yeah, it's just a bit tacky. 2926 is a much cleaner solution.
Guillaume:And, yeah, like…
Guillaume:Yes, if it's redundant, if 29… sorry, if binary trees happen, but they are yet to be… to be approved. So, if you're willing to open the discussion of having the binary tree transition in Glamsterdam, I think it's a good argument, but I don't think anyone is ready to advocate for this.
Guillaume:So, yeah, as far as I'm concerned, it's an empty promises that, that we'll have binary trees in the future.
Guillaume:And as a result, we should, we should not plan that they are happening.
Ansgar Dietrichs:Makes sense. Yes, I do think this is a general topic, the strategy around
Ansgar Dietrichs:what we do about contract size in Glamsterdam, we should take that offline. That seems like there's still some unresolved questions there. Okay, then, next slide.
Ansgar Dietrichs:So, cryptography-related ERPs, we have four, there's the Falcon, pre-compile, there's, secondary signature algorithms, P256, and the pre-compile, for MLDSA.
Ansgar Dietrichs:Do we have client opinions on any of these?
Ansgar Dietrichs:Felix.
Felix (Geth):Yeah, so, we wanted to mention that, like,
Felix (Geth):we do think that the, so I have two comments about it. The EIPs 7932 and AT30, so these are… revolve around, signing transactions, and with a different…
Felix (Geth):curve, or in the case of 7932, more generally, just with, like, any kind of signature, somehow. We think it's not necessarily the time right now to make these changes. They are, like, not in themselves bad, but it's just…
Felix (Geth):Seems kind of a distraction now, and also there isn't really, like, a, you know…
Felix (Geth):We don't really want to work on this right now. And then for the… my other comment is that for EIP7619 and AT51, so these, add precompiles for cryptographic operations, we have a very well-established process for adding these kinds of precompiles.
Felix (Geth):It is.
Felix (Geth):easy to…
Felix (Geth):do it in some ways, but also it's a lot of work. So that's the thing. I mean, we know how to do it, but the work is big, especially because we really have to make sure that they are all implemented the same way, and with the newer algorithms, you know, they can be quite complex, or,
Felix (Geth):There might not necessarily be an implementation in all of the programming environments that are, like, needed, so… this can add up to a significant chunk of work, so we feel like we wouldn't necessarily want to do them, but there's nothing per se bad about it.
Ansgar Dietrichs:Sounds good. Any further comments?
Marc:Oh, good.
Carl Beekhuizen:Huh.
Ansgar Dietrichs:Huh?
Ansgar Dietrichs:Oh.
Marc:Yeah, for, Nethermine teams, so those two metal ones, I think…
Marc:Generally, we agreed that we weren't sure if it was the right direction, or if we were gonna do…
Marc:Like, sort of the account abstraction path to post-quantum, whether those two would make sense.
Marc:As to the other two, I guess we didn't have too strong feelings on them. Like, obviously, it's important to think forward towards post-quantum, but we're not really sure yet if those are the right, algorithm signatures we need to support, or whether this is the time to add it.
Ansgar Dietrichs:Sounds good, Kyle.
Carl Beekhuizen:Yeah, my comment was largely the same, but specifically on Falcon 512, that we're not sure that this will necessarily be the industry standard for how to
Carl Beekhuizen:Handle post-quantum signatures, so this seems very premature to ship this.
Ansgar Dietrichs:Deno?
Danno Ferrin:So, yeah, Falcon 5's probably gonna be FNDSA. MLDSA is, final is FITS204.
Danno Ferrin:And when it comes to implementing these on the EVM, MLDSA is one that's even more expensive, it'll take up the whole block. So pre-compiled to support these industry standard, features will be very valuable. But the reason for these two is because of post-quantum.
Danno Ferrin:we're looking at, either, you know, hardware or regulation timeframe that we need to start looking at getting off of EC curves. And we need to start looking at sooner rather than later, because not only implementation time, we need to concern ourselves with how long it's going to take our end users to migrate off of that.
Danno Ferrin:So, the more we wait, the harder we make that on ourselves. So, just keep that in mind.
Ansgar Dietrichs:Makes sense. Any further… Covenants?
Ansgar Dietrichs:Okay, then we can go to the next slide.
Ansgar Dietrichs:We are getting close to… to the end. This is a… well, no, that's a bit premature, but we are…
Ansgar Dietrichs:Comfortably more than halfway through, let's put it that way.
Ansgar Dietrichs:We have transaction and block features. That's Bloom filters, the ETH transfers emitting a lock, trustless log index, conditional transactions, the max blob flag for local builders.
Ansgar Dietrichs:I'm not sure, actually, this might not be a consensus-changing ERP. We have the provable RPC responses, the Genesis file format, and the sparse blob pool.
Ansgar Dietrichs:do we have client comments on any of them, Justin?
Justin Florentine (Besu):Just a couple brief comments. I did want to point out that Genesis file format does not require a hard fork.
Justin Florentine (Besu):I believe the same is the same… the same, is true for 78, 72. I do think max blob flag for local builders is important, I think Genesis file format is important, and I think…
Justin Florentine (Besu):Removing the bloom filters is also important.
Justin Florentine (Besu):ETH transfers emitting a log is something that we would like to include as well, but we feel a little bit less strongly about it.
Ansgar Dietrichs:Makes sense. And yes, as you're saying, I think some of these EAPs do not require a hard hook directly. I think they are more on the list because they would require a
Ansgar Dietrichs:Client release coordination point in time, so basically hard forks are just a convenient kind of coordination point for them.
Ansgar Dietrichs:Result?
Zsolt Felföldi:Yes, yeah, I just, wanted to, quickly address, like, eTransfer Semitolog and trustless log index, so,
Zsolt Felföldi:Yeah, because Trust Logan Index is mostly, like, my proposal, and, yeah, I do understand it's kind of a complex thing, I'm strongly convinced that,
Zsolt Felföldi:Yeah, we should take, over time, the protocol in a direction where, we can really, like, trustlessly prove everything, so,
Zsolt Felföldi:So currently, I'm working on as clean as possible implementation of this EIP, and I don't want to force anything on the protocol that, like, most people are not comfortable with, so in the coming weeks, I'm trying to… I will try to present as good material as possible to try to
Zsolt Felföldi:like, make this approachable, and I hope… I still think it might be, like, a good candidate for Glamstadom, but yeah, this requires work, so yeah, just that. Thank you.
Ansgar Dietrichs:Sounds good. Justin, you still have your hand up? Did you have another comment, or…
Ansgar Dietrichs:Okay, Tukash?
Łukasz Rozmej:Yeah, so I think Trust's log index is, pretty big, and potentially could be even considered part of a purif, headliner, but even by itself, it's definitely too big and too complex to fit into Glamsterdam.
Ansgar Dietrichs:That's good, Felix?
Felix (Geth):Yeah, so, my comment… I have two comments. One of them is also regarding the trustless login deck, so, Jolt was… I don't know if he really said it like that, but… so we are currently working on just creating a change for the execution, specs, just to show exactly what is the minimum complexity required for this change.
Felix (Geth):Like, the part that is actually in the consensus. And,
Felix (Geth):these… this is the part that the EIP is about. There are more parts to it that can be implemented, but at the core of it, it just does require certain changes within the block processing, too, you know.
Felix (Geth):these ones is what the EIP is about, but it can be confusing because the indexing itself and the searching and so on, they are just a bit bigger than this. Anyway, then we have some other things. So,
Felix (Geth):we think that the things like the Genesis file format and,
Felix (Geth):For example, this is something that we can easily just agree on, but it makes sense to put it in the hard for…
Felix (Geth):By which we will,
Felix (Geth):fully agree, need to, you know, have it implemented. In some way, we kind of reject the 7872, because we feel that it's kind of a pointless thing to specify the command line flags in an EIP. So, maybe that's going a bit too far.
Felix (Geth):So it's a… I think we're kind of walking a strange line here with these…
Felix (Geth):Not about the consensus at all, they are just kind of optional recommendations, and we have to figure out a way to process these. But yeah.
Marius van der Wijden:Those should be just feature requests on the different clients' repositories.
Ansgar Dietrichs:Makes sense. Yeah, it was… it was really, tricky to structure for just today with so many APs, but I agree. I think, kind of reworking this categorization, having a separate…
Ansgar Dietrichs:out-of-band conversation about these, like, non-consensus requiring… non-consensus changes. That makes sense. Old?
Zsolt Felföldi:Yeah, just, just one remark about the Trustless Logan Index, and yeah, I'm done with that for today. So, yeah, just, just so that, people can, like, like,
Zsolt Felföldi:how you should think about the complexity is that, yeah, so there's a minimum… as Felix mentioned, yeah, I forgot to, like, say this, but… so there's this minimum implementation that generates the consensus hashes, so that's what I want to, like, like,
Zsolt Felföldi:present some, some, some really, like, it's, it's 500 lines of code, and, like, like, CPU requirement, memory requirement, everything is bounded. So, yeah, this is… I'm not trying to convince you about this now, I'm just saying that this is what I'm trying to sell.
Zsolt Felföldi:is that it can be super useful, maybe the, like, the full stack that generates these trustless proofs and everything, yeah, so that's a more complex thing, but the minimum, changes required for consensus, that's not so big. And, like, the full feature set, that's something I want to present and get, like, yeah.
Zsolt Felföldi:people can see why it's useful, and I think…
Zsolt Felföldi:for someone who just wants to follow consensus, it's not going to be extremely complex, and yeah, this is what I want to prove, and yeah, that's it.
Ansgar Dietrichs:Awesome, thank you.
Ansgar Dietrichs:Do we have any further comments? Otherwise, we can move to the next vlog, or maybe just a few seconds.
Ansgar Dietrichs:Okay, then let's move to the next book.
Ansgar Dietrichs:Salt your sister if you end up, by the way.
Ansgar Dietrichs:Yep, next, this appears to be in the last slide.
Ansgar Dietrichs:Oh, wait, do we… was I… was I wrong? Oh, I think I was actually… oh, never mind. This was the last story, I was… I thought we were 3 slides from the end. Okay, never mind. Then I… I… my comment was actually right, that we were basically at the end. This is great. Thank you all very much, so,
Ansgar Dietrichs:with that, we still have 10 minutes. Again, just to reiterate, the idea is that I will…
Ansgar Dietrichs:maybe with the help of some people, go through the call, all the comments, both on the call and in the comments, and just synthesize it all into a hopefully as minimally opinionated as possible, kind of, like, list of DFI candidates, CFI candidates, maybe EIPs where there was either no opinion yet, or maybe just in general, no consensus. And none of that, again, is binding governance-wise in any way, it's really just,
Ansgar Dietrichs:structure of future calls.
Ansgar Dietrichs:I think a lot of this hopefully also will spawn some offline continued exploration of these, of these ERPs. Yeah, do we, in general, I would otherwise ask that I see in the last 10 minutes, if there's any specific
Ansgar Dietrichs:strong requests for already making any individual CFI or DFI decisions today, those 10 minutes could be for that, or if there are general comments on the process. Justin?
Justin Florentine (Besu):General comments on process. So, I do want to kind of…
Justin Florentine (Besu):expressed some concern about limiting the discussion of fossil to the CL call. I don't know that that's necessarily warranted. I think that's a thing that we should maybe… maybe we could take it offline, which is fine, but I do feel like this is a pretty broadly,
Justin Florentine (Besu):relevant EIP, both to the EL and the CL and Ethereum in general, and limiting the conversation to CL seems a little unnecessary, and the CLs already have a tremendous amount of work as it is. So, I do want to raise, you know, a light objection to that notion, but I'm happy to discuss it,
Justin Florentine (Besu):More broadly.
Ansgar Dietrichs:Yeah, and on this point, just to clarify, and then you can still object if you want to, by the way, but I think the idea was more to say the location of the discussion will be the ACDC calls, but we would specifically… that's also why I was communicating it today here, that the idea would specifically to, like, directly have all the EL
Ansgar Dietrichs:Clients invited, and if you want to participate in that conversation, then
Ansgar Dietrichs:It would not be… basically, it's only…
Ansgar Dietrichs:hosted by ACDC, but it would… there would not be, like, usual for normal ACL changes. Obviously, the CL clients are the ones with the voices that make the decisions, but on Fossil specifically, it would be an equal conversation across the ELs, and CLs are just hosted by the ACDC calls, because we have more throughput there, because there's fewer EAPs to discuss. Is that… does that work for you, or do you… would you still have an objection there?
Justin Florentine (Besu):No, I understand that, and I appreciate that, but I also feel bad, you know…
Justin Florentine (Besu):not having the conversation in the EL space, and only having it in the CL space, you know, I think there's a lot of actors that would be interested in it from the EL side that don't generally make that call, nor feel comfortable speaking up into it. Obviously, I don't have a problem speaking up anywhere. I think folks know that, but I do want to advocate for other people that do, that care deeply about Fossil.
Ansgar Dietrichs:Okay, yeah, I appreciate that. I think that's a trait, by the way, that the two of us share. But, yeah, is this some… is this a concern that other people share? I mean, obviously, this is… this was just a suggestion. If people strongly prefer to also have fossil in scope on the EL side, on the ACDE side, conversation-wise, we could revisit this.
Ansgar Dietrichs:is there.
Ansgar Dietrichs:How do other people here feel about this?
Ansgar Dietrichs:Photos?
potuz:I think the difference that Puzzle has with respect to other EIPs on the EL side is that, we…
potuz:we won't be affected at all if you decide to have pricing or not. On the CL side, we don't need to change our schedule, we don't need to change how we're scoping our fork, and we don't need to really be thinking about how to time it.
potuz:But… Fossil does affect how you scope the EL fork itself.
potuz:So I am… I'm surprised that Fossil is being discussed, it's moved the discussion to… even after you haven't been discussing all of these other EIPs, I would have included Fossil before in this discussion, before all of the other ones, because if you do include Fossil, then I suspect that you… you won't be…
potuz:trying to include any of these other CIPs.
potuz:So I think, we should focus more on the EL side of things. The CL side of things already has a big chunk to change, and if fossil is kind of… it needs to be agreed or not among the whole group.
potuz:I don't think it has to be… yeah, I don't know. I just wanted to… to agree with Justin on that one.
Ansgar Dietrichs:Andrew?
Andrew Ashikhmin:Well, a stupid question. I thought that we were doing EPBS as the CL headliner. I don't… like, it sounds strange to me that we are considering two CL headliners in a fork.
Ansgar Dietrichs:Yeah, so, for clarification, because I'm not sure we ever discussed this on the ACDE, but for… within the headliner process.
Ansgar Dietrichs:on the CL side, basically the decision was made to have EPBS selected as the headliner, but then fossil…
Ansgar Dietrichs:was decided to not be removed from the fork consideration, but instead just be bumped down to normal EIP,
Ansgar Dietrichs:And actually, even given that people did think it would… it had a specific significance for this fork, it was already bumped to CFI, so it's the one CFI EIP that we actually have for the fork right now.
Ansgar Dietrichs:Does not mean we have to include it, but basically, yes, so it is no longer in consideration as a headliner, but just as a normal EIP, but with a special consideration of already being CFI'd. That's the current status.
Ansgar Dietrichs:and just for comments and sharing.
Andrew Ashikhmin:Well, sorry, but, like, they're both big, like, again, like, it sounds like just a name game, because it is a headliner. Like, it just sounds weird to me that you kind of play with terms.
Andrew Ashikhmin:But anyway…
Ansgar Dietrichs:Yeah, I was not… that was not my specific decision, but I think everyone agrees this is why Fossil. I think Fossil is, on the one hand, the most… the highest priority one, because it is, I think, very core to Ethereum's values. On the other hand, it is also, in a way, the most costly addition at this stage of the process, because
Ansgar Dietrichs:because of the complexity. So I think people in general agree with you here, it's just that because it is so important, there's still the consideration of possibly just accepting the extra complexity cost. So that is basically exactly the conversation that we will be having.
Ansgar Dietrichs:well, either on the ACDC, or on ACDC and ACDE, depending on how people feel about this. I don't think we have time today. We have 4 more minutes, so I don't think we have time today to go into Fossil on the merits discussion, so the next discussion on it will definitely be on ACDC, so go over there and join if you want to participate.
Ansgar Dietrichs:And then maybe, unless there's more opinions now, we can offline discuss whether we also wanted Fossil to be discussed on next ACDE call in two weeks.
Ansgar Dietrichs:One more process point then, and I don't think we will have time for anything other than process.
Ansgar Dietrichs:into weeks.
Ansgar Dietrichs:on ACDE that is during the week of DevConnect. I know that many people are not attending DevConnect this year anyway, my…
Ansgar Dietrichs:suggestion would be to go ahead and continue the conversation in two weeks. As we said, that would then be the time where we, for the first time, would start to make individual decisions, so go through the DFI candidate list, and possibly DFI EFPs, go through the CFI candidate list, possibly CFI EFPs.
Ansgar Dietrichs:Of course, that only makes sense if people feel comfortable that we will have at least anything approximating an ACD quorum in two weeks, so I wanted to just get a temperature check on this. Are people okay? Comfortable with basically moving ahead with this plan and continuing the conversation in two weeks, or is this an issue for people?
Ansgar Dietrichs:Well, maybe let's put it this way.
Ansgar Dietrichs:the default would be, in two weeks, we continue with this plan as is. If people have strong objections to this, then in the meantime, offline, on Discord, go and please voice that, because, yes, otherwise, you will basically come back in three weeks, and there will have been decisions.
Ansgar Dietrichs:And because none of us had the comment chat, I think not this coming ACDC, but we have discussed whether potentially we might be able to repurpose any of the other ACD-related calls, to basically extend the ACDE discussion space, but this would not be relevant in this coming two-week cycle yet.
Ansgar Dietrichs:M… We have 2 more minutes. I think…
Ansgar Dietrichs:Are there any specific process-related things we need to discuss?
Ansgar Dietrichs:Okay, otherwise, we did have one last agenda point, which was the welding the steel. Just a quick question for anyone from the steel team. Obviously, we're at the very end of the call. Is there something you want to give us, like, a one-two-minute summary of this topic, or would you rather wait for an ACDE at a future point where there is more room? Although, fair warning, this might take a while.
Guru:Hi, I can give just a quick update. We also kind of have a blog post out for this, so we can kind of link that for anyone who's interested in more details.
Guru:So, yeah, so a couple of weeks ago, we had announced that we are doing the weld, which is putting our two, repositories together. So this is basically just an update on that, and I'm happy to announce that we have completed it. So, the execution spec tests.
Guru:code has been moved into execution specs. So, I mean, there are a lot of benefits for doing this. Everything has been, like, kind of updated in the blog post, you can kind of take a look. It kind of,
Guru:For the eels developers and the client developers, this doesn't change anything, but for testing developers, there are a few things that… a few minor things that change, and most of it is, like, a more positive developer experience. Again, I have kind of…
Guru:highlighted everything in the… in the blog post. I would have loved to, if we had more time, go over some of the changes, but
Guru:They're minor enough that you can just take a look at it, and if you have any questions, just reach out to us.
Ansgar Dietrichs:Sounds good. And then, steel-related, one last comment. There was also, I linked it on the agenda, there is a issue where the steel team is assessing complexity of PFI DAPs.
Ansgar Dietrichs:And I hope that the CFI candidate list from today's call will be helpful in helping them guide the prioritization of which one… which APs to look at first, but if you want to give impact to this directly, I also linked it in chat.
Ansgar Dietrichs:So have a look there. And with that, I think that's the end of today's call. Thank you all very much, with sticking with this. This was a lot, and I hope we made some progress, and,
Ansgar Dietrichs:Yes, see you all in two weeks.
lightclient:Thank you.
Carl Beekhuizen:Thanks a lot.
Marius van der Wijden:Thank you, I'm.
Guru:Thank you.
Pooja Ranjan:Thank you.
Andrew Ashikhmin:Come by.
potuz:Rock bye.
Fredrik:to…
Łukasz Rozmej:Bill?
Chat Logs
00:06:21
parithosh:Holesky as well actually
00:07:46
nixo:technically the 1 month that was requested was between announcement and mainnet, not necessarily releases and mainnet
00:09:14
Marius van der Wijden:No delay
00:09:21
stokes:Yeah I don’t see a reason
00:09:47
Matthew Keil:agreed
00:09:49
Enrico Del Fante (tbenr):Teku is fine
00:09:53
Matthew Keil:Full speed ahead
00:10:00
Dustin:With Fusaka at this point, it's fine
00:10:06
Matthew Keil:🚄
00:10:15
Dustin:There is a question of process in Glamsterdam
00:10:16
Justin Florentine (Besu):i can't think of anything to do with any additional time
00:10:42
Barnabas:https://github.com/ethereum/pm/blob/master/Fusaka/fusaka-mainnet-plan.md this doc
00:11:02
James He:We are working on release not out yet
00:11:42
stokes:Hogota
00:11:49
Josh Davis:Hekota
00:11:53
Chris:Out of interest - what would we do if we found a major issue with clients after BPO-2 on Hoodi? I think it's the first time we've had the delayed activation of features for a fork
00:12:04
stokes:Replying to "Out of interest - wh..."
We would assess
00:12:14
stokes:Replying to "Out of interest - wh..."
We will never ship to mainnet if we expect an issue
00:12:42
Barnabas:Replying to "Out of interest - wh..."
I guess it could also depend, whether the bug would be BPO related or fusaka related
00:12:49
Marius van der Wijden:Replying to "Out of interest - wh..."
We have delayed forks in the past, pretty last minute
00:12:53
Barnabas:Replying to "Out of interest - wh..."
We could unschedule BPO 2 but still leave BPO 1 scheduled
00:13:03
Dustin:18 of them are repricings though
00:13:20
lightclient:It’s that time again
00:13:40
Chris:Replying to "Out of interest - ..."
I guess the question is more - would we have to request the community rollout new versions ASAP changing the fork date or BPO schedule?
00:13:54
Matthew Keil:BTW, just for clarity I was talking about a process update for future forks. Not changing timeline
00:14:14
Barnabas:Replying to "BTW, just for clarit..."
can you make a pr with your suggestion?
00:14:19
Matthew Keil:Replying to "BTW, just for clarit..."
sure
00:15:33
stokes:Replying to "Out of interest - wh..."
Likely yes
00:15:40
Barnabas:why can’t we start DFI-ing today?
00:15:49
stokes:Replying to "Out of interest - wh..."
We’d have to get any problematic releases off mainnet
00:16:11
Ansgar Dietrichs:Replying to "why can’t we start D..."
just out of worry that will blow up the call
00:16:18
draganrakita:Replying to "why can’t we start D..."
Zoom needs the whip sound
00:16:29
Ansgar Dietrichs:Replying to "why can’t we start D..."
maybe let me say it this way: if we get through all EIPs and still have time, we can talk about making first full decisions
00:16:33
Barnabas:Replying to "why can’t we start D..."
I’d like to start DFI-ing
00:16:57
lightclient:Geth doc https://notes.ethereum.org/@fjl/geth-glamsterdam-eip-ranking
00:18:40
Łukasz Rozmej:trustless log index could be scheduled for H or even I fork, it's huge and very fragile (easy to have bugs)
00:18:49
Ansgar Dietrichs:Nethermind: https://x.com/URozmej/status/1986040895578296825
00:18:53
Marius van der Wijden:For gas repricing, the majority of work is on the benchmarking and verification, ,not on implementation
00:18:56
Ansgar Dietrichs:Erigon: https://github.com/erigontech/erigon/wiki/Glamsterdam-PFI-stand
00:19:33
Chris:Replying to "Out of interest - ..."
Have we been in the position before where we've announced mainnet versions and then had to rollback?
I guess we have about 3 weeks between hoodi BPO2 and mainnet fork so that should be enough time to reach out. Hopefully none of this is an issue of course
00:19:38
spencer-tb:Plus on prioritising headliners. BAL plus repricing is already a lot imo.
00:20:08
marek:Replying to "For gas repricing, t..."
yes, 100% agree with what Felix said, we need to evaluate EIPs and then decide
00:20:39
Dustin:the CALLDATA repricing is distinct IMO -- it affects block size
00:20:57
Phil Ngo:Replying to "Out of interest - wh..."
I think it’s more likely that clients will have patch releases to further upgrade if we find anything post-BPO2, but delaying as a last resort. Would have to assess what the issue is
00:21:01
Ansgar Dietrichs:Reth: https://hackmd.io/@jenpaff/S1bj9gqkbe
00:21:44
tamaghna choudhuri:trustless log index could be scheduled for H or even I fork, it's huge and very fragile (easy to have bugs)
The Eips idea is good but there are many open questions left and many problems
The main problems with the eip rn are
Database how to persist
reorg handling for filter maps
Proof format still in progress
non-standard SSZ usage
6466 Log container usage and 7916 ProgressiveList
network sync protocol missing
00:22:40
Jen:Replying to "https://github.com/e..."
@Barnabas adding GitHub handles is okay or you want full names in the list?
00:23:06
stokes:Replying to "https://github.com/e..."
GitHub handles is fine
00:23:14
stokes:Replying to "https://github.com/e..."
Discord may be better
00:23:36
Barnabas:Replying to "https://github.com/e..."
Yeah names generally ok, I think the client teams aren’t so big that we wouldn’t be able to know who you referencing 😄
00:23:37
stokes:Replying to "https://github.com/e..."
The idea is that these are point people in case there’s an issue and we need to hop in a war room etc
00:23:37
Ansgar Dietrichs:Nimbus / Pureth: https://pureth.guide/glamsterdam/
00:25:10
Łukasz Rozmej:Access list repricing also is on block size
00:25:49
Lean F | Lambda:We didn’t have the time to gather the info but FOCIL as S-tier is something we agreed on from ethrex
00:26:02
kasey:I think no post mentioned EIP-7928: Block-Level Access Lists - not ready for inclusion?
00:26:19
Łukasz Rozmej:I would consider waiting for zkVms to do benchmarking of opcodes
00:26:26
Toni Wahrstätter:Replying to "I think no post ment..."
It's already SFI'd
00:26:32
kasey:Replying to "I think no post ment..."
Oooh thanks!
00:26:34
Łukasz Rozmej:For repricing them
00:27:10
Raúl Kripalani:One way or another, EIP-7870 defines combined bandwidth limits for both EL and CL. So anything that changes network dynamics is inherently cross-layer
00:27:15
Dustin:Yeah agree, I'm a bit wary of the general repricing for that reason
00:27:47
Łukasz Rozmej:FOCIL FTW!
00:28:06
Justin Florentine (Besu):i will definitely be on ACDC advocating for FOCIL
00:29:03
Dustin:Replying to "For repricing them"
zkVMs seem to change performance characteristics fairly meaningfully regularly
00:29:18
Dustin:Replying to "For repricing them"
But sure
00:30:03
Barnabas:Replying to "i will definitely be..."
CL devs gotta stay focused on epbs 😂
00:31:00
Justin Florentine (Besu):Replying to "i will definitely be..."
and i will be the coke dealer keeping FOCIL from disappearing from the Glamsterdam conversation.
you're welcome.
00:32:18
Dustin:Yeah, that part of the core repricing seems worthwhile, e.g., anything which has come up in perfnet as a bottleneck
00:32:20
Marius van der Wijden:One thing I wanted to mention is that the numbers in all eips, esp. 7904 are nor final and will change significantly between now and the fork. Cfi'Aing the repricing changes to get more resources available from the testing and security team. We will definitely prioritize the worst cases and making things more expensive before making things cheaper/harmonizing
00:32:36
Sophia Gold:Replying to "For repricing them"
I don't expect proving will affect 7904 repricing
00:32:37
Trent:There are dozens of EIPs that will soon disappear from the glamsterdam scope, not for lack of utility or importance, but for reasons of pragmatic scoping
00:33:00
Justin Florentine (Besu):Replying to "i will definitely be..."
and FOCIL shouldn't be one of them.
00:33:09
Sophia Gold:Replying to "For repricing them"
Also we now like removing precompiles in H* instead of repricing for zk :)
00:33:38
Marius van der Wijden:I like em all, but I'm biased
00:33:50
Ahmad Bitar | Nethermind:Replying to "i will definitely be..."
Agreed. Even if glamsterdam is to be delayed by a month or 2. I would say it is worth it
00:34:16
Mario Vega:The bundling has made it difficult for the testing team to assess its testing complexity
00:34:48
lightclient:I wish this was just 1 EIP
00:34:54
lightclient:EVM prices 2.0
00:35:20
draganrakita:Replying to "EVM prices 2.0"
EVM v2 didn’t go that well
00:35:30
Mario Vega:Replying to "The bundling has mad..."
Talking about 7904
00:35:42
lightclient:Replying to "EVM prices 2.0"
But Eth 2.0 went extremely well
00:35:49
Barnabas:Replying to "EVM prices 2.0"
EOF was too small it should have included all the repricing EIPs too
00:35:52
draganrakita:Hm, that is true
00:36:20
Carl Beekhuizen:I put together a spreadsheet to help myself understand how all these core repricing EIPs interact. In case it is useful to someone else: https://docs.google.com/spreadsheets/d/1DZVM3UDK-KkfpWAWGbeIEgHuejpoyy0vkbqpT3WSU7I/edit?gid=0#gid=0
00:38:59
Marius van der Wijden:Design & test time are very similar imo for repricings
00:39:23
parithosh:^ yeah design is already using the same infra we would for testing mostly 😄
00:39:26
Justin Florentine (Besu):Replying to "Design & test time a..."
it's not so much the time, its the need to iterate
00:39:54
Carl Beekhuizen:Replying to "Design & test time a..."
Yeah, for now every gas number in a repricing EIP, it should be expected to change
00:40:17
Louis:Not sure if testing here includes refactoring existing tests
00:40:29
Danno Ferrin:Replying to "Design & test time a..."
It’s the 4-6 distinct implementations that make the measurment part dfficult, we can’t be sure until all implms are measured.
00:40:30
Anders Elowsson:Related to what Justin F is saying, there is indeed the economic aspect of it, where we need to hypothesise around the price-elasticity of demand for the different opcodes, to know the equilibrium outcome.
In essence: If you increase the price of state gas, how much state will users actually create…
00:41:18
Ben Adams:Replying to "Related to what Just..."
And if it causes gas price to fall; then the high state growth ends up costing same
00:41:34
Ahmad Bitar | Nethermind:No milli gas nor rebase please 🙏
00:41:48
Anders Elowsson:Replying to "Related to what Just..."
Yes there are plenty of aspects here
00:42:00
Marius van der Wijden:Replying to "Design & test time a..."
We have pretty good infrastructure for measuring now. Once we propose a new schedule and clients implement it, we can immediately test it and see results in hours
00:42:15
Maria Silva:Replying to "Design & test time a..."
Also, we are benchmarking all clients independently and then taking the worse measurements
00:42:19
Ahmad Bitar | Nethermind:Replying to "No milli gas nor reb..."
Just general repricing and gas limit bump
00:44:04
Charles:what is the interference with AA?
00:44:13
Ansgar Dietrichs:and again, after the call I will go and synthesize all of this feedback into CFI and DFI candidate lists
00:44:45
Łukasz Rozmej:Maybe it needs bigger limit?
00:44:46
Barnabas:Fusaka blog post out: https://blog.ethereum.org/2025/11/06/fusaka-mainnet-announcement
LFG! 🦓
00:45:36
CPerezz:It helps scaling too. As XEN is no longer the bottleneck for state root computation
00:45:48
Łukasz Rozmej:The transition there is complex
00:46:07
Maria Silva:Adjustments are possible
00:46:20
Maria Silva:And we still need to benchmark as well
00:46:38
CPerezz:Replying to "The transition there..."
Far less than Verkle. And we had 7 devnets working and transitions done.
00:46:40
Guillaume:Replying to "The transition there..."
much simpler than binary trees
00:47:34
draganrakita:I think we are not using the lists the clients make and compounding it into one doc with priorities
00:47:34
Marius van der Wijden:Martin had a writeuo why we shouldn't do this
00:47:50
Carl Beekhuizen:https://eips.ethereum.org/EIPS/eip-7686
00:47:53
Danno Ferrin:The paging is the key value to any memory costing changes.
00:48:10
Mario Vega:Replying to "The transition there..."
The fact that we have never done this on a testnet or mainnet is enough to not downplay it imo
00:48:14
Marius van der Wijden:Replying to "Martin had a writeuo..."
8057
00:48:48
Guillaume:Replying to "The transition there..."
we did it on a testnet, holesky
00:49:09
Mario Vega:Replying to "The transition there..."
what was the update? how did it go?
00:49:10
Guillaume:Replying to "The transition there..."
back in 2023
00:49:49
Guillaume:Replying to "The transition there..."
what update?
00:50:04
Mario Vega:Replying to "The transition there..."
Holesky had a state account update?
00:50:29
Guillaume:Replying to "The transition there..."
in a shadowfork, yes
00:50:40
draganrakita:Same here for EIP-8024
00:50:45
nixo:note that 7686 should be in “Repricing - possible additions” - it was initially miscategorized
00:51:46
Marius van der Wijden:I kinda disagree with slotnum
00:52:04
Marius van der Wijden:Replying to "I kinda disagree wit..."
Not super easy, not super necessary
00:52:05
Ansgar Dietrichs:I hope this format makes sense for people, I am sorry there is not enough time to have a proper discussion on each EIP. if we get through all EIPs, we can have a quick discussion about next steps at the end
00:52:19
Mario Vega:Replying to "I kinda disagree wit..."
Don’t we need an engine api update for that or does the EL already have this info?
00:52:29
Justin Florentine (Besu):Replying to "I kinda disagree wit..."
not super easy? isn't it just a new field on a message frame?
00:53:06
Justin Florentine (Besu):Replying to "I kinda disagree wit..."
it's not super necessary, but it opens up some interesting app layer designs, @Marc can elaborate
00:53:08
Marius van der Wijden:Replying to "I kinda disagree wit..."
It should be, but its not local to the evm
00:53:13
lightclient:8024 gud
00:53:50
Ansgar Dietrichs:Replying to "note that 7686 shoul..."
right, the first 3 blocks were based on Maria’s recommendations, which did not yet include the EIP
00:53:54
Ansgar Dietrichs:Replying to "note that 7686 shoul..."
but agree conceptually
00:54:01
Marc:Replying to "I kinda disagree wit…"
would need engine api change but I don’t think super complex
00:54:16
Ansgar Dietrichs:@Felix (Geth) do you still have your hand up?
00:54:36
Jen:Replying to "I hope this format m..."
Yeah this is really helpful
00:55:11
Mario Vega:Replying to "I kinda disagree wit..."
Yes, it’s something we’ve done many times, should not be complex to test
00:55:45
Marc:Replying to "I kinda disagree wit…"
would be helpful for any apps depending on slot number to work reliably with future slot length changes
00:56:33
nixo:a bit of context: 6404 is a dependency of 6466
00:56:48
Marius van der Wijden:Replying to "I kinda disagree wit..."
I am not hard against it, if you could motivate it with a list of potential use cases marc. I think it would convince me
00:56:51
potuz:Replying to "I kinda disagree wit..."
Shouldn't that one be bundled with changes to the slot duration?
00:57:16
draganrakita:RLP works, imo it is not worth the change
00:57:25
potuz:Replying to "I kinda disagree wit..."
although if contracts want to start deploying with that logic right now, they would be future proof
00:57:31
Marius van der Wijden:Now not the time for ssz
00:58:05
potuz:Replying to "RLP works, imo it is..."
It doesn't work for many many applications, from staking pools to rollup protocols
00:58:41
Marius van der Wijden:Replying to "RLP works, imo it is..."
I agree that at some point switching fully to ssz would be nice, just not a prio rn
00:58:53
potuz:Replying to "RLP works, imo it is..."
this will continue to be the case forever
00:59:00
potuz:Replying to "RLP works, imo it is..."
has been for over a few years now
00:59:09
Marc:Replying to "I kinda disagree wit…"
say if an app wants to do something like allow something to happen every x epochs, they could do this much more cleanly
00:59:26
Marc:Replying to "I kinda disagree wit…"
I think should be shipped before slot length change to give time to migrate
00:59:30
Greg K |Lido:7688 should be discussed in ACDC, right?
00:59:38
Justin Florentine (Besu):Replying to "RLP works, imo it is..."
agree, it's never been more important than competing features.
00:59:38
Dustin:7688 is CL yes
01:00:10
Łukasz Rozmej:Replying to "The transition there..."
Yeah but Verkle was potential headliner
01:00:19
lightclient:Did we talk about code merklization yet?
01:00:29
Łukasz Rozmej:Replying to "The transition there..."
I would be ok with doing this with migration of the tree
01:00:33
CPerezz:Replying to "Did we talk about co..."
No one commented anything
01:00:38
CPerezz:Replying to "Did we talk about co..."
But we passed it already
01:00:42
draganrakita:EIP-7907 is good ux improvement
01:00:43
Maria Silva:Replying to "Did we talk about co..."
It was in the repricing part
01:01:06
Danno Ferrin:7903 is needede for 7907
01:01:11
potuz:Replying to "RLP works, imo it is..."
Hard to gauge on aggregation, like on every single release, we have huge changes that could have been avoided on our side if we had forward compatible or stable containers, at each given fork they probably don't offset other EIPs, but we've now paid the price for at least 4 forks
01:01:12
Marc:Replying to "I kinda disagree wit…"
the motivation isn’t really allowing apps to support some new functionality- they can already do the same stuff today just not in a future-proof way. it’s just trying to give one less thing to worry about when changing slot length
01:01:42
Ahmad Bitar | Nethermind:We are for 7907 but with a lower size, like 64
01:02:14
Marius van der Wijden:I am for chunk based one over 7907
01:03:09
spencer-tb:Is 7907 redundant if chunk based will happen in the future?
01:03:59
Charles:the main issue that came up for eip 7907 before was the addition of the codesize index; have discussed offline and a good improvement would be to add the codesize directly to the account tuple (credit danno)
01:04:03
lightclient:We were pretty supportive of 7997 fwiw
01:04:17
Charles:Replying to "the main issue tha..."
i can update the eip if there is appetite for this eip
01:04:19
Guillaume:Replying to "Is 7907 redundant if..."
yes
01:04:55
Ben Adams:Replying to "We were pretty suppo..."
Is very low effort 🙂
And nice to have a standard
01:04:55
spencer-tb:Replying to "Is 7907 redundant if..."
Then I don’t think we should add 7907. Feels like wasted time.
01:05:12
Luis Pinto | Besu:Replying to "The transition there..."
IMO we definitely need to bring in how clients load bytecode from DB into the protocol spec at some stage. Currently there’s no concept of it, as far protocol goes only contract hash exists and it complicates increasing contract limits. The question is whether to do it now or later.
01:05:54
spencer-tb:Replying to "We were pretty suppo..."
Testing was medium complexity iirc
01:06:32
Marius van der Wijden:Replying to "We were pretty suppo..."
We already have resources lines up for a proper audit of it
01:06:49
Marius van der Wijden:Replying to "We were pretty suppo..."
(If chosen)
01:08:42
pk910:Replying to "We were pretty suppo..."
we already have deterministic factory contracts via unprotected / nickmined TXs? A standard would be great, but is it worth spendeing dev effort on it - we won't really have a benefit out of it as we preactically already have a non standard way to do the same?
01:08:55
Jen:Replying to "Is 7907 redundant if..."
I disagree- if we can ship 7907 and achieve better devex in Glamsterdam, then we should do it
01:09:05
Sophia Gold:strongly against adding new precompiles
01:09:18
Danno Ferrin:https://quantumdoomclock.com/
01:09:28
Luis Pinto | Besu:Replying to "strongly against add..."
Need to address PQ at some point
01:09:36
Sophia Gold:Replying to "strongly against a..."
this is not the way imo
01:09:40
Luis Pinto | Besu:Replying to "strongly against add..."
If not now, next fork after Glamsterdam
01:09:53
Danno Ferrin:Replying to "strongly against add..."
EVM PQ is on the order od 2-15M
01:09:58
spencer-tb:Replying to "strongly against add..."
What’s PQ?
01:10:04
Luis Pinto | Besu:Replying to "strongly against add..."
Post quantum
01:10:14
Danno Ferrin:Replying to "strongly against add..."
Post-quantum - EC crypto should be on a deprecation path
01:10:18
Luis Pinto | Besu:Replying to "strongly against add..."
That question is fair and telling that no one is looking at this
01:10:18
lightclient:Replying to "https://quantumdoomc..."
Clearly this isn’t consensus otherwise it would be a much bigger issue
01:10:38
Sophia Gold:Replying to "strongly against a..."
Danno what does 2-15M mean?
01:10:54
Danno Ferrin:Replying to "https://quantumdoomc..."
https://www.youtube.com/watch?v=OkVYJx1iLNs
01:11:16
frangio:Replying to "strongly against a..."
probably gas cost to verify pq sigs on evm
01:11:20
Danno Ferrin:Replying to "https://quantumdoomc..."
Also, government mandates are setting a 2030/2035 deprecation/removal timeline
01:11:48
Marius van der Wijden:Replying to "strongly against add..."
Might go down with repricings ;)
01:12:12
draganrakita:Falcon512 is becoming NIST standard, but to early to add it rn, probably in future
01:12:16
Dustin:Replying to "https://quantumdoo..."
that's quite a different claim than "Quantum computers will be able to steal all your keys by:
March 08, 2028 at 11:23 AM"
01:12:54
Carl Beekhuizen:Replying to "Falcon512 is becomin..."
if it becomes the industry standard, then strong agree
01:13:08
Danno Ferrin:Replying to "https://quantumdoomc..."
That’s the most aggressive credible claim. This one is better
https://www.youtube.com/watch?v=OkVYJx1iLNs
01:13:21
Marius van der Wijden:In 80% of the time 😆
01:13:22
Dustin:"is becoming a" is not "is a"
01:13:33
potuz:@Danno Ferrin advances in Lean + PQ are really picking up quickly now, it feels like just a few months to coordinate with them what will be the native Ethereum PQ approach would be worth it in this case.
01:13:59
lightclient:The EIP doesn’t require a hard fork, but the core devs do ;)
01:14:00
Ansgar Dietrichs:as Justin is saying, I believe some of these do not require a hard fork change
01:14:11
draganrakita:EIP-7708 is nice ux
01:14:43
Danno Ferrin:Replying to "Falcon512 is becomin..."
Falcon will be FN-DSA, FIPS-206 as the standard. But ML-DSA / FIPS-204 is out and finalized and is the current PQ DSA for FIPS compliant apps.
01:14:43
Mario Vega:Replying to "EIP-7708 is nice ux"
testing effort was low, only concern was we need to test system contracts that rely on eth transfers
01:14:48
Justin Florentine (Besu):what coordination is needed for 7949 or 7872?
01:15:17
Justin Florentine (Besu):Replying to "The EIP doesn’t requ..."
is this re: motivation?
01:15:42
Ahmad Bitar | Nethermind:Replying to "what coordination is..."
7872 doesnt need any coordination
01:16:00
Danno Ferrin:Replying to "@Danno Ferrin advanc..."
The pq-interop has been 100% focused on the consesus algorithm. It’s the wrong set of people to set EL standards. Perhaps we should start up another working group for EOA, blob, and P2P concerns.
01:16:06
Ahmad Bitar | Nethermind:Replying to "what coordination is..."
But it is important to protect local building and the resiliance and liveness of the network
01:16:09
donnoh | L2BEAT:Replying to "EIP-7708 is nice ux"
can confirm from l2beat side that 7708 is nice to have!
01:16:28
Ahmad Bitar | Nethermind:Replying to "what coordination is..."
Especially given the aggressive BPOs we have in the schedule
01:16:28
pk910:Replying to "what coordination is..."
7949 is probably mostly coordination between pandaops & client teams as we use the geneis files for all our devnets
01:16:43
Sophia Gold:Replying to "strongly against a..."
What about in riscv? :)
01:16:47
Danno Ferrin:Replying to "@Danno Ferrin advanc..."
For a new consensus protocol, the existing PQ-interop is all the right people needed, it’s a question of focus.
01:17:02
Dustin:Replying to "what coordination ..."
Yeah, without 7872, local nodes have to have approximately some of the resources of a supernode
01:17:04
Sophia Gold:Replying to "strongly against a..."
There are risc-v simd extensions
01:17:07
Ahmad Bitar | Nethermind:Replying to "what coordination is..."
I dont think it has anything to do with genesis
01:17:10
Łukasz Rozmej:Can't comment on something that is not ready
01:17:11
Ahmad Bitar | Nethermind:Replying to "what coordination is..."
Its more like a config
01:17:20
Marius van der Wijden:I would put 7668 and 7745 in the same fork
01:17:28
Ahmad Bitar | Nethermind:Replying to "what coordination is..."
Could be wrong
01:18:03
spencer-tb:Replying to "what coordination is..."
STEEL could help with 7949 here too I think. But defo low prio.
01:18:05
Justin Florentine (Besu):Replying to "what coordination is..."
correct, max blobs configured outside of genesis
01:18:11
Danno Ferrin:Replying to "strongly against add..."
A risc-v “canonical” version of a precompile is a good path.
01:18:35
Łukasz Rozmej:+1 for not including non consensus changes. We are fine to implement them.
01:19:07
Marius van der Wijden:I am also strongly against 7793 for glamsterdam
01:19:44
Marc:Replying to "I am also strongly a…"
why is that?
01:19:52
Danno Ferrin:Replying to "strongly against add..."
The price won’t go down 1000x with re-pricings. What is needed is either cheap small math ops (16 bit) or vector operations.
Also, I haven’t seen zkEVMs running the RV vector ops yet. Is ther eone I should be looking at?
01:20:05
potuz:Is Etan here?
01:20:20
Dustin:Replying to "Is Etan here?"
He's not no
01:20:27
tamaghna choudhuri:Replying to "Is Etan here?"
Sadly no : (
01:20:34
potuz:Replying to "Is Etan here?"
oh wasted a couple of minutes on that image :(
01:20:39
Sophia Gold:Replying to "strongly against a..."
None do. And we like to keep the ISAs minimal. I'll see if we can evaluate relative costs for this
01:21:08
Francesco:Replying to "+1 for not including..."
We still need a way to coordinate on everyone implementing them though. E.g. for sparse blobpool, we do kind of need all clients to do it in a timely way, if we think it’s important, otherwise we can’t get any benefits from it (unless we’re ok with just saying that if you run a client that hasn’t implemented it you’ll need more bandwidth)
01:21:36
Francesco:Replying to "+1 for not including..."
Doesn’t have to be included in the fork, but we probably do need ACD to decide on it?
01:21:57
draganrakita:Replying to "strongly against add..."
zkEVM will need to support some kind of quantum sigs, so having precompile for it makes sense
01:22:06
potuz:Agree with Justin
01:22:16
Marius van der Wijden:Replying to "I am also strongly a..."
Puts a big strain on block building, really big change (new tx type, new opcode) for little gain
01:23:18
pk910:Replying to "I am also strongly a..."
seems like we missed GAS2ETH in the eip discussuions?
I'm curious what other devs think. I'm against it. I don't think we should abuse gas for tips
01:23:31
Marc:Replying to "I am also strongly a…"
I don’t see it being a big issue, the tx index is specified up front so you can put these txs at top of block before building the rest
01:24:04
Marius van der Wijden:Replying to "+1 for not including..."
Also there's an argument to be made that teams will need to reserve work slots for these eips
01:24:05
Marc:Replying to "I am also strongly a…"
in terms of little gain, I think it’s a big improvement if you care about encrypted mempools
01:24:33
Kevaundray Wedderburn:Replying to "strongly against add..."
@danno I don’t think there is a benefit to supporting the vector extension, since the virtual CPU that the zkVMs prove is not that sophisticated
01:24:45
Francesco:Replying to "+1 for not including..."
Yeah if we don’t take it into account in these discussions, it’s clear that it’s going to be less likely to be implemented because everything else will take precedence
01:24:52
Łukasz Rozmej:Ship FOCIL.
01:25:07
lightclient:Idk FOCIL failed to get accepted as a headliner, idk why it is even CFI
01:25:10
Francesco:Replying to "+1 for not including..."
(More true for sparse blobpool, the max blob flag is a very small feature of course)
01:25:17
Łukasz Rozmej:Potuz is underestimating EL devs
01:25:28
potuz:why is that?
01:25:34
Carl Beekhuizen:Wait, isn’t it the opposite? If we ship FOCIL, we’ll have a lot more time for things on the EL side
01:25:35
potuz:that you guys can do all of them :)
01:25:52
soispoke:Replying to "Idk FOCIL failed to ..."
Because the process was actually flawed to begin with, and the difference between a headliner and not a headliner has never been very clear
01:26:02
potuz:Replying to "Wait, isn’t it the o..."
True, good point, it will affect timings on the CL more
01:26:03
lightclient:Replying to "Idk FOCIL failed to ..."
What was not clear?
01:26:11
Marius van der Wijden:Replying to "+1 for not including..."
(But I really think, we should not start creating eips for cli flags, esp not with 7 co authors)
01:26:17
potuz:Replying to "Wait, isn’t it the o..."
But I do feel the whole group should be involved
01:26:20
soispoke:Replying to "Idk FOCIL failed to ..."
What makes an EIP a headliner?
01:26:29
Dustin:people like FOCIL enough
01:26:46
lightclient:Can we move 8024 to CFI since every client wants it?
01:26:47
Danno Ferrin:Replying to "strongly against add..."
No vector is fine, it’s doing 14 bit math on 256 bit registers that is the real issue for an efficient EVM solution.
01:27:02
soispoke:Replying to "Idk FOCIL failed to ..."
Just the fact that it was posted on ethmagicians at a different time? Or the complexity? Or the strict CL/EL separation?
01:27:05
lightclient:Replying to "Can we move 8024 to ..."
Instead of debating process
01:27:08
Trent:Are we repeating the mistake of pectra overcommitment
01:27:18
lightclient:Replying to "Are we repeating the..."
No we are stronger
01:27:41
Marius van der Wijden:Replying to "Idk FOCIL failed to ..."
If it is delayed, do we delay the fork or remove the feature
01:27:52
Trent:I think this is a false choice - at that point, the damage to timeline is done
01:27:56
Ahmad Bitar | Nethermind:Just as a reminder, focil doesn't only add censorship resistance. It also allows optimistic rollups to reduce their challenge window thus finalizing faster
01:28:02
Marius van der Wijden:Replying to "Idk FOCIL failed to ..."
Was the original intention of headliner iirc
01:28:09
Barnabas:should next week’s acd be another acde?
01:28:26
lightclient:I think we usually cancel acd during devcon
01:28:43
Francesco:Replying to "Just as a reminder, ..."
Has any L2 confirmed that that’s enough for them to do it?
01:28:43
Danno Ferrin:Replying to "should next week’s a..."
Every acdc should be an acde if it keeps ending early. consensus issues first priority.
01:28:54
soispoke:Replying to "Just as a reminder, ..."
https://notes.ethereum.org/@rudolf/interop-16
01:29:00
spencer-tb:Can we start DFI’ing next week?
01:29:14
soispoke:Replying to "Just as a reminder, ..."
There was a dedicated interop call on this
01:29:15
Csaba:I also think CLI flags should not be made a requirement through EIP process. What if a client doesn’t even have a command line interface to start with? Not that we have such a client, but it really feels strange to standardise at this level.
01:29:23
lightclient:8024 CFI
01:29:26
lightclient:2day
01:29:28
lightclient:Do it
01:29:58
Marius van der Wijden:Lightclient trying to dos the process afain
01:29:59
Guru:https://steel.ethereum.foundation/blog/blog_posts/2025-11-04_weld_final/
01:29:59
Ansgar Dietrichs:can you put the blog link in chat?
01:30:06
Ansgar Dietrichs:Replying to "can you put the blog..."
ah, perfect
01:30:50
Barnabé Monnot:Replying to "Just as a reminder, ..."
It’s very likely an improvement for withdrawals (and I’m a big fan of it for interop reasons) but not worth blowing up the fork scope imo
01:30:51
lightclient:Replying to "Lightclient trying t..."
I am just using my favorite process
01:30:56
Csaba:Replying to "+1 for not including..."
As for networking EIPs, we explicitly said that these don’t have to be (but can be) on this list, but it is also important to have a space to discuss them, otherwise we risk not being able to scale.
01:30:57
Marius van der Wijden:Oh where will the tests be published?
01:31:03
spencer-tb:Replying to "Oh where will the te..."
EEST
01:31:14
Marius van der Wijden:Replying to "Oh where will the te..."
Nice
01:31:15
soispoke:Replying to "Idk FOCIL failed to ..."
It’s still not clear to me why an EIP that is not SFI’d as a headliner wouldn’t be able to be presented as a non headliner
01:31:17
Łukasz Rozmej:Replying to "The EIP doesn’t requ..."
We already said we will implement it you don't have to remind us every 6 months 😉
01:31:27
Ansgar Dietrichs:STEEL PFI complexity assessment doc: https://github.com/ethsteel/pm/issues/7
01:31:30
Francesco:Replying to "Just as a reminder, ..."
I am quite skeptical about this, for one thing (like potuz mentions) it is not resilient to 51% attacks, which is not the security model of L2s. Also reducing challenge windows isn’t just about censorship (it’s not even clear that it’s the most important thing)
01:31:34
Guru:Replying to "Oh where will the te..."
Test release remains the same as before
01:31:49
Justin Traglia:Bye all!
01:31:49
donnoh | L2BEAT:Replying to "Just as a reminder, ..."
go look at notes / recording of the call!
Summary
17 highlights
· 3 decisions · 4 action itemsExperimental
Summary
17 highlights · 3 decisions · 4 action itemsExperimentalfork status and schedule
client updates
organizational
eip discussions
- Core repricing bundle (6-7 EIPs) presented with mixed support on bundling approach00:29:30
- Strong support for EIP-7778 refund logic change00:34:44
- Strong support for EIP-8024 as low complexity, high impact00:50:30
- Multiple clients prefer to DFI milligas approach (EIP-8053/8059)00:41:25
- Strong opposition to EIP-8057 temporal locality discounts due to archive node complexity00:46:57
- Besu and Erigon oppose SSZ EIPs (6404, 6466); Dustin proposes subset PureETH scope00:56:40
- Debate on contract size: EIP-7907 immediate increase vs EIP-2926 chunk-based approach01:04:58
- Mixed views on post-quantum precompiles: urgency concerns vs uncertainty about standards01:10:08
- Trustless log index viewed as too complex for Glamsterdam by Nethermind01:15:40
Decisions
Action Items
- Besu team: Publish detailed EIP rankings by next week00:22:21
- Ansgar Dietrichs: Synthesize client feedback into CFI/DFI candidate lists before next call00:14:02
- Charles and AA teams: Provide info on EIP-7971 transient storage limits and AA compatibility00:43:32
- Guillaume and interested parties: Take contract size strategy discussion offline01:03:20