All Core Devs - Execution #224

Transcript

Ansgar Dietrichs: Hello, hello, everyone.

Justin Florentine: Good mornin'!

Ansgar Dietrichs: Wow, this is the energy we need today. I'll check back in with you at the end of the call, see if that's still the energy level you're at. We'll wait for another minute or two, but then we'll probably get going relatively soon, just because… There's so much to talk about today.

Okay, I think we can go live.

Josh Davis: Alright, you're alive, landscape.

Ansgar Dietrichs: Perfect. Well, hello, good morning, afternoon, everyone. Welcome to… Another AllCoreDevs, the plan for today is… pretty… packed, because we want to actually start the Glamsterdam scoping discussions. So, for that reason, I'll today be a bit more opinionated and 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. 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 Busa: 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. During the BPO fork transition, there seemed to have no bug, but 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. Regarding how serious the bug is, or, what they can say. 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 Busa: 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, May not release, and they are currently soaking the release, and should be ready by Monday, based on our latest information. 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. or diversions.

Ansgar Dietrichs: That's what you…

Emmanuel Nalepa: Sorry.

Ansgar Dietrichs: Oh, maybe, Yamenu, go ahead.

Emmanuel Nalepa: 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. We understood this bug, we fixed it, we ran the fix for a little bit less than… 24 hours now. 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. 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 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 Busa: I think last week we brought up, this discussion, or maybe it was this Monday, whether we would like to push for the client traces still for this week, and, Technically, the conclusion was that most client teams were fine to make a release this week, other than Prism, and 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 releases and mainnets, so… 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. 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 to allow the hoodie fork to soak, to allow the BPOs, like, in this case, the BPOs didn't actually happen until, technically, the… 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 two releases that basically will come after the initial announcement, or is this a reason to delay? 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… 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. 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. 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.

So, yeah, just a reminder. Okay, anything else at all regarding Fusaka? Anything we should touch on? on this call. Okay, so there will be a, announcement for the mainnet releases coming, and then we'll backfill the missing clients there. And go ahead. Awesome. Looking forward to Fusaka. 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…

Just… maybe someone wants to say 30 seconds? Where people should go. Or you can just find it on the agenda. So if you have any… if you have, opinions about the… 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… 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… Nix or Josh, if you could share the screen for that? Awesome. And if we go to the first slide there…

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 blow up the, 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

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. 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.

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. That would be… 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 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?

If so, I would just go ahead. And again, it's not ideal, but I think, just given that we have an unprecedented number of ERPs, this is the best 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. 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. 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, 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. It is published, and, like, please also read into some details, because, 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 And then we also have something… something published from the GATT side. Is there someone on the call that could briefly describe that?

Felix Lange: 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. we do think that there's, like, room to ship a significant number of EIPs, especially because of the repricing. Basically, how this is gonna work is… 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… 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.

Changes that are… 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, 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, 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…

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… 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 Prioritize headliners, and avoid the same mistake that we made in 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.

a lot of work, so I would rather… Do a small number of low-hanging fruits. and not jeopardize block access lists, rather than be too greedy and try to squeeze too much. As to repricing. I think that… I quite like the approach that we took in Fusaka, during the peripher… 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. Like, this general repricing that effectively means lowering 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.

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. 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 EGLP, like, in the list, like, we looked at two angles. What is the performance impact? And here, we were mostly looking into, like, the repricing piece that we would like to prioritize. And I think, like, we think this one facilitate lots of performance optimizations. And then secondly, how will the CIP, Improve developer experience, And, yeah, those are the two, kind of, decision parameters that we're going for.

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: We do.

Ansgar Dietrichs: What you would prefer to prioritize in the park?

Justin Florentine: We do, Anskar. So, we have not gotten to the point where we're ready to publish, however, we have 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. 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… 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 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 Brody: Yeah, sure. So… 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. 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 up to about a half dozen EIPs, which would fit in Amsterdam, yeah. Now, the Nimbus also has, views on, so there's a… MaxBobs is… is something that we support, although…

I think with a caveat that it's granted not really a consensus EIP, it doesn't actually matter that much. Clients can implement it either way or not. And 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… 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. And everything else is, you know, some clients bounce around in performance, and that's fine. But that… I think that… if none of the other repricings go in, we want that one to go in.

And then otherwise see the documents.

Ansgar Dietrichs: Sounds good.

Dustin Brody: 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 Brody: 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 Brody: 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… So, we do have an EL… 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. But we have people.

Ansgar Dietrichs: Yeah, yeah.

Dustin Brody: 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 Brody: Fair enough. Yeah.

Ansgar Dietrichs: Makes sense. Awesome. Thank you, Dustin. 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. 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 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

Or make decisions about fossil here on the ACDE calls. 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. 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 optimizations beyond the base spec compliance that, all require significant work and clients to support. And we might end up deciding to ship them, as basically as expected feature sets, so basically that is…

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. 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. 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

feature set around block-level access lists to support. So, just wanted to highlight that, and because it's relevant here. With that out of the way, I think we can jump back into the presentation, because I had one slide with Quick, update from the repricing, breakouts, and then wanted to go to the main ERP discussions. 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, 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.

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. 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.

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. 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. In particular, there's still some worry around 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

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, Approval across the board. 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

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, 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 directory pricings related to bandwidth, state, data, or memory, or state growth. Do we have

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, computational opcodes, 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… bump, the price of the most underpriced things, like we did with, with Modex.

Ansgar Dietrichs: Sounds good. And I'll also try to, keep everyone's comments to… like, try to be as concise as possible, basically. Justin?

Justin Florentine: 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. 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. 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…

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. In my mind, the reason for bundling is that 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 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 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

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… These bundle, these… the… 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 in, Glamsterdam. And then there's some discussions on scope, maybe there's some, operations that are not as mispriced as 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?

Dragan Rakita: To be honest, I would like to have them as separate therapies. But look at them as the group, I see there are two groups here. One is increasing, any storage or creation of the contract. 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… At potential edge cases where the guys is not priced correctly. I would say that… First part, first group, where we need to increase the gas for creation or access to the state, is more important. But either way, yeah, that's my comment on this.

Ansgar Dietrichs: Sounds good. And, Justin?

Justin Florentine: And then, probably, last comment for this section. 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? 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… 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 of the state creation. So it's operating on a different dimension. So, if that caused the gas price to fall, because now things are expensive, then People can create the same amount of state, just everything is now at a cheaper gas price. So it… My concern is it doesn't necessarily 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. It may not have the intended effect. So, for instance, if the gas price fell because of them. Then people could afford to put more in a block. 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 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 proposed since. 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.

M… 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? Andrew?

Andrew Ashikhmin: Yeah, I would deify the milligas approach. I think we have much bigger fish to fry, and the, like, the… Improvement, the potential improvement in precision is not worth the complexity.

Ansgar Dietrichs: Sounds good. Lucas?

Łukasz Rozmej: I'm especially for the first to hear, the, like… 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 Lange: Yeah, I just wanted to say that, like, regarding the DFI, we were also discussing this EIPAT58, So, yeah, so in general, we were… in Geth, we think that this, like, 8053, 8059, 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 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.

Just so we have less things to consider.

Ansgar Dietrichs: Sounds good. Any other opinions? Marius?

Marius van der Wijden: Yes, for the hard limits for transient storage. As I understand it, this will interfere with, AA? I would like to… hear more from… the author and maybe the AA teams, how they think about this. Not on this call, but maybe on the next call. Yeah, so if the… I think it's… It's Charles, if… I don't know if you see it, but… yeah. Yeah, exactly. I think that.

Charles Cooper: Yeah, well, too.

Marius van der Wijden: There needs to be more work in going into this before I can… 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… From the, core bundle, the state's, growth EIP, some people raised the concerns of the The values being a bit too high. And I think adding this IP would actually help there, because what we are doing here is we are making, accessing and writing to large contracts more expensive, so that the Base costs for the rest of the contracts don't need to be as expensive. 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? I'd wonder… Otherwise, open, yeah.

Ben Adams: For 8032. 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. 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… were not on this list yet, so… so I put them into the data blocks. So, these ones… 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. Warm account rate metering, multidimensional gas metering, and interblock temporal locality gas discounts.

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… 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. Which is a little simpler, but has different sets of trade-offs, so… should be considered… As an alternative and trade-off, if people are interested or not in The memory costing stuff. 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. Ben?

Ben Adams: Assuming we do quite a large number of the other repricing EIPs, then… 8… 011, multi-dimensional. It might be, too much in Amsterdam, and might be better to see how everything plays out, and then 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. Awesome. Any further comments on this list? Otherwise, Marius?

Marius van der Wijden: Yeah, so regarding AT57, we are also strongly against this, this idea has come out multiple times in the past already, and Martin has had written a… A, A pretty good explainer for why this is not, good, and the drawbacks it has, and why we shouldn't do it. 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 Cooper: 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. 2000.

Ansgar Dietrichs: Yeah, I think simplifications was one of the things people were asking for there. Okay, then I think we can move on to the next section. And… 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. 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… CFI or DFI, opinions from any clients regarding any of these? 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. And, also about the 7979, I think it's, we shouldn't do… go there. We should do EOF, or, like, reconsider EOF. 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 Lange: 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… basically, included. 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. Everyone… Seems to be in favor of it so far. Regarding some of the other ones… We did, look a bit into 7791, gas to ETH, there is… It's hard to say, but we feel like this should not happen, so we are against this one.

It's, 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… Is against it, we might as well exclude it right away. 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 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 Space for individual, final decisions people want to propose making, and then the discussion attached to that. Any other comments, opinions, plus or minus, towards any of these EIPs on the list, Dragon?

Dragan Rakita: 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. we had some chats in Discord about this, but I'm not sure if anything is clued. Is it… 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. 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. And… Yeah, the question… Was whether we want to make the decision to reinforce that this is the rule, or we want to make a decision to change that rule. And, Yeah. This doesn't need… to… Yeah. We should, we should, we should just, not take… up time to discuss the CIP. At this time.

Ansgar Dietrichs: That's good. Raidan, do you want to respond?

Dragan Rakita: 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 Lange: 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. relatively, straightforward to test, so I think we would support that from the, yeah, from the testing team, yeah.

Ansgar Dietrichs: Sounds good. Any further comments on this block? I think this is the largest set of individual earpiece on these slides. Okay, then we can go to the next slide. These are just a few ones, We already heard a little bit about… about the period, topic, so we have, SSE transactions, SSE receipts. 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? Justin?

Justin Florentine: Yes, we're generally against SSZ, both 6404 and 6466. 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 Brody: Yeah, so one… one point I'd like to make regarding the separate, 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… Purith as one big unified headliner probably is not ready. However, there are parts which do look… 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… All kind of, complement each other. And… 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.

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… 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. and… 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… That's kind of the idea of this process, right? So, this would…

For now, basically be a clear indication that this is where this is headed. 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… Move on, okay, then we can go to the next slide. Yes. So, contract, contract deployment related. We have the, removing the init code size limit, we have the… 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. 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 larger contracts, so there is some interdependency here. Do we have… Clients with, opinions on either of those three.

Andrew?

Andrew Ashikhmin: Yeah, I think, we should, do 7907. It's just, it'll help, smart contract devs.

Ansgar Dietrichs: Sounds good. Any other comments? Felix?

Felix Lange: 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. We're just basically, like, we're just no longer… we're no longer really, like, pursuing this EAP anyways.

Ansgar Dietrichs: Sounds good. There was also comments, I think, if I'm not mistaken, I just want… I'm gonna briefly double-check that there was… 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 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. 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… 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 Ballet: 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. We can take it offline.

Guillaume Ballet: 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… Place a dragon.

Dragan Rakita: I just want that it is complex, because it touches a lot of things. 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, we would basically have the three approaches of doing nothing in Ramsadam, doing the one that's listed here, 7907, or… which is, I think, what we also discussed for Fusaka and then ended up not doing, or doing this chunking-based approach. 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?

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. Like, 64 kilobytes, or around that number.

Ansgar Dietrichs: Sounds good. Anyone else with, opinions here? Guill.

Guillaume Ballet: Yeah, I mean.

Ansgar Dietrichs: size.

Guillaume Ballet: 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. for a long time, of course, we will take that offline. But, yeah, like, this is guaranteed to be… what I mean is 79… 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, What 7907 buys us? 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. In terms of… yeah, there will be some coding, but I think it's quite alright. My worry with 2926 is that, If we do it ahead of the binary tree, then we may end up with a different design, and then it somehow 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.

Yeah, I think it's just premature to do it.

Ansgar Dietrichs: Yeah, one last comment from Guillaume here.

Guillaume Ballet: 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… not having it anytime soon. That means you still have very large witnesses, which 2926 solves. You still have Prover Killers, which 2926 solves, and… 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. And, yeah, like… 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.

So, yeah, as far as I'm concerned, it's an empty promises that, that we'll have binary trees in the future. 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 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. 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. Do we have client opinions on any of these? Felix.

Felix Lange: Yeah, so, we wanted to mention that, like, 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… 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… Seems kind of a distraction now, and also there isn't really, like, a, you know… 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.

It is. easy to… 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, 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 Harvey-Hill: Oh, good.

Carl Beekhuizen: Huh.

Ansgar Dietrichs: Huh? Oh.

Marc Harvey-Hill: Yeah, for, Nethermine teams, so those two metal ones, I think… Generally, we agreed that we weren't sure if it was the right direction, or if we were gonna do… Like, sort of the account abstraction path to post-quantum, whether those two would make sense. 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 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. 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. 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. 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? Okay, then we can go to the next slide. We are getting close to… to the end. This is a… well, no, that's a bit premature, but we are… Comfortably more than halfway through, let's put it that way. 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. 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. do we have client comments on any of them, Justin?

Justin Florentine: Just a couple brief comments. I did want to point out that Genesis file format does not require a hard fork. 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… Removing the bloom filters is also important. 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 Client release coordination point in time, so basically hard forks are just a convenient kind of coordination point for them. Result?

Zsolt Felföldi: Yes, yeah, I just, wanted to, quickly address, like, eTransfer Semitolog and trustless log index, so, 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, Yeah, we should take, over time, the protocol in a direction where, we can really, like, trustlessly prove everything, so, 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 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… 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 Lange: 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. Like, the part that is actually in the consensus. And, 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. 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,

we think that the things like the Genesis file format and, For example, this is something that we can easily just agree on, but it makes sense to put it in the hard for… By which we will, 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. So it's a… I think we're kind of walking a strange line here with these… 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… 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, 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, 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. 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.

people can see why it's useful, and I think… 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. Do we have any further comments? Otherwise, we can move to the next vlog, or maybe just a few seconds. Okay, then let's move to the next book. Salt your sister if you end up, by the way. Yep, next, this appears to be in the last slide. 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, with that, we still have 10 minutes. Again, just to reiterate, the idea is that I will…

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, structure of future calls. 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 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: General comments on process. So, I do want to kind of… 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, 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, 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 Clients invited, and if you want to participate in that conversation, then It would not be… basically, it's only… 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: No, I understand that, and I appreciate that, but I also feel bad, you know… 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. is there. How do other people here feel about this? Photos?

Potuz: I think the difference that Puzzle has with respect to other EIPs on the EL side is that, we… 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. But… Fossil does affect how you scope the EL fork itself. 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…

trying to include any of these other CIPs. 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. 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. on the CL side, basically the decision was made to have EPBS selected as the headliner, but then fossil… was decided to not be removed from the fork consideration, but instead just be bumped down to normal EIP, 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. 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.

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. 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 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. 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.

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. One more process point then, and I don't think we will have time for anything other than process. into weeks. on ACDE that is during the week of DevConnect. I know that many people are not attending DevConnect this year anyway, my… 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.

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? Well, maybe let's put it this way. 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. 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.

M… We have 2 more minutes. I think… Are there any specific process-related things we need to discuss? 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.

Guruprasad Kamath: 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. 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. 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,

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… 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 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. 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. 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, Yes, see you all in two weeks.

Lightclient (Matt Garnett): Thank you.

Carl Beekhuizen: Thanks a lot.

Marius van der Wijden: Thank you, I'm.

Guruprasad Kamath: Thank you.

Pooja Ranjan: Thank you.

Andrew Ashikhmin: Come by.

Potuz: Rock bye.

Fredrik Svantes: to…

Łukasz Rozmej: Bill?

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