All Core Devs - Consensus #170

Transcript

Alex Stokes: Hello. Okay, let's give everyone another minute or two, and we'll get started. It is a holiday in the US, so… We might have fewer people today. Than usual, but let's see what happens. I was laughing with Terrence said. And in the meantime… Let me check one thing…

Okay… It's just earlier here. Let's see. Let's give it one more minute, and then we'll get started. Okay, Josh, are you helping with the stream? And if so, then we are ready.

Josh Davis: Alright, you're live.

Alex Stokes: Okay, thank you. So, welcome, everyone. This is ACDC number 170. It is issue 1812 on the PM repo. And, yeah, today, we should touch on Fusaka, the fork is coming up in just a few days, so we'll just touch on a few things there. To get ready? Then, we'll continue with Glamsterdam, and the big thing there would just be to continue Forkscopin. So, let's go ahead and get into things. With Fusaka. So, yeah, first I'm just curious if there are any updates. I know we've been doing some mainnet shutoff forks, anything like that. And… oh yeah, please.

Barnabas Busa: Yeah, so we started, Ministry of Work 1, yesterday, and we went through full BP01 and BPO2, with basically the same behavioral values that we are planning to do launch on midnight. So we did 15 mix blobs on BPO1, and 21 max blobs on BPO2. have been, spamming the network, here and there. Sometimes we shut off the spammers, sometimes we relaunch it in order to get, some transactions from Minnet. And we have seen very close to 100% participation throughout the past, 24 hours. The oil is looking good.

Alex Stokes: Okay. Great to hear. Yeah, Barth has a question if we're using MedBoost, on mainnet Shadow Fork 1.

Barnabas Busa: We are not.

Bharath Vedartham: Okay.

Alex Stokes: Okay. Cool. So, then in that case… Unless there are any other updates there. I did want to touch on this mainnet LAN. Okay, I'm not sure which Chris this is, but they had a question about, Nimbus SuperNodes. That seems relevant.

Barnabas Busa: Yeah, so we have been using their 25.11.0 on the Mini Shadow Fork, and that release has been pretty solid. They have made a new release, with the 25.12, that one at the bug. And Nimbus was, gonna come out with a new, release yesterday or today. Yesterday they didn't, so hopefully today we have an update from them.

Alex Stokes: Okay, thanks. Yeah, Dustin, you have more to add?

Dustin Brody: So, I don't know, so I can respond to this, or if this is just… but yeah, I mean, we are working on this… On a do- on a… On release, it fixes a very specific issue that actually, Barnabas and some of the other testing there had found before, and… That's going, going through final phases of… of that. We're… we are truly aiming to get something out as soon as possible on this. We're aware of the timeline.

Alex Stokes: Okay, great, yeah, cool, yeah, just keep us updated. I imagine we'll need to update the EF blog post as well, so… yeah, I'll keep an eye out.

Dustin Brody: Yeah, yeah, that's… that's true. So, so this will probably be… first, I don't… this 25.12, by the way, maybe I'm misparsing what was said. We don't have that release, that sort of obviously would be… it doesn't… December doesn't exist yet, but… but this would likely… we would be aiming for a 25.11.1 would be the likely version number on this, but anyway.

Alex Stokes: Yeah, thanks. Yeah, again, we'll keep an eye out. Good luck.

Dustin Brody: Yep, yep.

Alex Stokes: Great. Then, the next thing was the Husaka mainnet plan, and I dropped a link here in the chat. It's, again, here on the PM repo. And the main thing here is just coordinated incident response, so this is, something we added, with Pectra, again, just in case something does go wrong. It's very clear who's responsible for what, and how we can kind of proceed. So… Some of the client teams have filled this out. Actually, I haven't checked this morning. So, okay, there's a few more PRs here. And in any case, yeah, please… Make a PR, so we just know who is responsible for what. And… yeah, I don't think there's much more to discuss here. I've sent messages to each individual client team, so…

Yeah, just a reminder to… Get this ready, and… yeah, then in other… In other news, Fusaka… We'll go live, in just a few days, so… Very exciting. And… Beyond that, I don't think I had anything. Is there anything else, people feel like we should discuss for Fusaka? Okay, cool. I'm not sure, if there'll be any sort of, like, launch parties or anything, usually. someone does a livestream situation. So yeah, I guess we'll keep our eyes out for that. But otherwise, I'm sure everyone will be watching the chain, when the fork happens, and yeah, let's hope for a good fork, and we'll go from there.

Alright, yeah, there's this one here, Nixo posted, and then, yeah, sounds like also another mine's planning to have one, so… cool. Should be fun. And again, fingers crossed for a smooth fork. Okay. Then, if we're going to Fusaka, let's turn to Glamsterdam. And I want to just start just by asking if there's been any updates on DevNets. So, I know, last time we asked this question, yeah, kind of things are still in progress, and that might still be the case, but I figured I'd ask. And in particular, I mean, DevNuts for EPBS.

Stefan Starflinger: We've made a lot of progress with the tests, regarding, block-level access lists. And I think 3 clients are passing pretty much all the tests now. And I think we can start with DevNet soon. I'll be testing it in Kryptosis this week.

Alex Stokes: Cool. Any updates on the EPBS side? I think we had been thinking we would kind of have separate dev nets for the headliners, and then only once those are stable would we merge them into a Glenster Damnet.

Parithosh Jayanthi: Yeah, could we maybe get some updates from the EPBS research crew or plan teams on how the implementations are going?

Terence Tsao: We can give out the other precision sites, so we have a bunch of PRs that's open for the Beacon spec, and that's, like, in the process of getting reviewed and merged, but so far, most of them are passing the SPAC test. We just need to merge them to develop. And then that's probably the biggest blocker, for Defnet Zero. And this moment, I think after Fusaka's shift, we'll see more, like, progress on that front. Yeah.

Alex Stokes: Er. So, Prism and, any other clients? Has anyone else made implementation progress? Okay, then yeah, so… That's.

Enrico Del Fante: I can talk for tech or test stuff, any thoughts here. So, yeah, we've been… working on APBS in Teco for a while now, and we are merging things in master, which is good. couple of weeks, we slowed down a little bit, but we are in a good shape. I think there are some… Database-related and fortunate things to do, but most of the flows are actually kind of there. So… yeah, we feel good.

Alex Stokes: Okay. And then, yeah, Phil's just saying here, Lodestar, looking more like January, so… Okay, yeah, I mean, I think that's understandable, you know, everyone's focused on Fusaka, and otherwise, yeah, different, Amounts of progress with different clients. King Yi saying here, steady progress in Lighthouse, so… Okay. Thank you, everyone. And on the topic of ePPS, so, there were actually quite a number of discussions last week at DevConnect around this feature of trustless payments. We've discussed this quite a bit on ACD, but I think now, as implementations have progressed, and especially other people in the community have had some time to look more at the feature. There are definitely some questions around the implications of this part of 7732.

And… Yeah, I think from here, I'll just hand it over to Alex, who wanted to say some things about this.

alex: Yeah, sure. I think you pretty much nailed it. Last week during DevConnect, I talked to more people about it. I noticed that there was, like, various levels of understanding, and as, like, I tried my best to find the latest version of 7732 and what is and isn't possible, and… make sure that, my view of it was accurate, and started talking to people about it. I noticed that there was definitely some let's say just contention still within Fuse, actually lots of contention on all kinds of various parts. It mainly centers, I'd say, around process payments, but that definitely isn't the full picture yet. I did my very best to talk to lots of client teams about this to see if they even wanted to have the discussion, or saw a reason in some of these, at least for me, new perspectives on why you may or may not want to ship this current version of 7732.

what's been happening so far is more discussion. I wanted to flag that the next EPBS breakout call, I'm trying to push for and organizing, as a focal point to have some of these discussions and bring in some of the perspectives that, at least from my experience, talking to people, have not been fully hashed out yet. And that's, I think, most of it. Just that maybe if you want to be involved in that discussion, and you do still see use in the different variants, like 7732 is there, some form of it will definitely go in, it looks like. But yeah, some people want to talk about which form still, and see if there is space. So yeah, you can reach me, I'll put my Telegram in the chat.

next week, December 5th, EPBS breakout call to talk about it, and I'll for sure be trying to make discussion happen already. Like, there's a Telegram channel I can add you to, and maybe Discord. The R&D Discord is also a natural place for some of the discussion to happen, so yeah. You know where to find me.

Alex Stokes: Great, thanks. So, yeah, if you want to look into this, again, next Friday during the PBS Breakout. And otherwise, yeah, there's, Alex's Telegram handle, so laser job. Thank you. Okay. And… From there, and yeah, I mean, maybe just to be clear, I think the intent right now is just to discuss this design a bit more. I think we'd want to have that discussion before bringing it back to ACD and making any sort of, you know, decisions around scope or anything of the EIP, so… Yeah. Should be good there. Okay. Then… next up… I'd like to continue fork scraping. And… Yeah, so maybe I'll just play back, kind of where we're at.

So, we have the headliners, we started scoping for the non-headliners. And… last call, which would have been 2 weeks ago. We kind of went through a number of them. Client teams left some opinions on different EIPs. We were able to DFI one of them, lost call, I believe it was 8068. Let me just make sure I have the right number… yeah, 8068. So that was deified, but then we still have quite a number on the CL side. And we need to go ahead and pick the set that we would like. to CFI for Amsterdam. So… I'd like to make progress here today. There have even been some changes, because there's kind of a bundle of EAPs that touch on consolidations, and the queues, and how those all fit together.

Since the last call, Francesco has split something out into, sort of a more streamlined EIP with 8080, And in any case, yeah, we'll get to that. Before we move through all of them, we should touch on Fossil, because this is where we left it during the last call, is that… you know, due to scoping, and, you know, essentially the extra complexity it would bring to bundle with EPBS due to the testing overhead, the security overhead, all of the above. We said that if we could find a way to commit to it for Hecca, Bogota, so the fork after Amsterdam. That feels like a much better decision to make. And that's kind of where we left it.

Yeah. I guess before we move forward, I don't know if there's anything anyone would like to add around the fossil question. I'm not sure if there is. So, okay, then let's just move ahead, so… For this, yeah. So, I talked to some people last week, and… again, I think people are generally on board with this. The question is just, like, how do we actually make this credible commitment? So… you know, I think two straightforward options. We could either CFI fossil for Heika Bogota, made a meta AIP that, is not merged yet, but it exists, so, you know, we could just essentially make a PR to that PR. You know, some people might not want CFI, and so in that case, we could also do SFI.

Yeah, okay, people here in the chat saying, SFI. And… yeah. I mean, the thing… the difference here is, like, SFI is, like, a, you know, fairly stronger signal, which I do think mirrors the… Demand for this feature, again, everyone… I mean, I don't think anyone has spoken against Fossil as an EIP. The question's more just when. And, sure, you know, marrying that then, I think SFI for Heck of Bogota. Makes a lot of sense. Yeah, so… I'd propose we do that. Does anyone have any comments to what I just said? Turds.

Terence Tsao: If you want an SFI fossil, don't you also want, like, other contending, like, EIPs, for example, like, 6-second, or other EIPs that wanna, like, SFI to HACA also have, like, a fair chance as well, meaning, like, opening the floor to, like, restart the process for HACA, something like that?

Alex Stokes: Yeah, I mean, this is a very good question. So, yeah, like, you mentioned 6-second slots, you know, there will be other EIPs we want to think about as headliners. And this is kind of the thing we need to sort out, so… We don't want to, like, get ahead of ourselves, necessarily. And, yeah, I guess given, you know, the demand for Fossil, I think we could kind of carve out a special case here, where we say, yeah, we move ahead with SFI, That doesn't mean we, you know, skipped the headliner process for HECA. We would still have that, you know, I think pretty soon. And then from there, you know, essentially the framing, at least to me, would be, hey, you know, this is, like.

The strongest signal that we're sending is that fossils should be, you know, in the fork. Then from there, we can think about other things that go in the fork. You know, we touched upon this last call, but say, for example, there is a lot of demand for 6-second slots in Hecca. I think, you know, I do trust that if we start now, then it's much more likely to think about doing both, rather than, you know, say, the situation today with Amsterdam, where, as we saw, we're still very early in the DevNet process for EPBS. So, again, it feels… Much less wise to go ahead and sort of put two more headliners into the fork. Whereas, you know, I think, at least it feels to me, like there's more room to do this for HECA, especially if we sort of start today.

So, yeah, maybe…

Dima Gusakov: The thing is, if we not commit for fossil, but we do EPBS, and then we risk not including fossil, at least in the next hard fork. It creates a bit of a problem, again, at least for those running, nodes from home, running validators from home, with this, increased, Up low at bandwidth for local block production. And for me, it's very concerning if we agree on… like, we already agreed on doing EPBS, that's amazing. And if Fossil is not in Glamsterdam, I think it's… it will be a good decision to commit to have it in the next hard work, at least. Otherwise, we create a gap And should fossil not make it into the next hard fork, this gap will be widened.

So, for me, it's kind of concerning to have EPBS without fossil. It's fine to have it, like, in two separate forks, but in two adjacent forks, not… But the bigger gap.

Alex Stokes: Yeah. No, that's fair, and I think that's why we're trying to find a way to… signal today that it would go into Hecca? And that all being said, yeah, there's a number of comments in the chat here around… Yeah, different, different aspects to this. Yeah, maybe to drive the conversation forward, so let's say we SFI'd it today, but, you know, the understanding is that we still have the headliner process to consider with other EIPs. Does this seem okay to people? Yo, Barnabas.

Barnabas Busa: Yeah, so I think we might need to rethink our… total process, how we decide which EIP should make into which fork. What we need to actually do is, if you're going to be doing two forks a year going forward, then we need to have much better pipelining, so that means that we need to dedicate specific EIPs for N plus 1 fork a lot sooner. And, yeah, we… I think we just, like. just need to change the way we think about the IP scoping, and maybe we can shorten the time for making decisions.

Alex Stokes: Yeah. I mean, okay, so that… kind of suggest another way forward, if people want to think about this in the context of, like, other EIPs, is we would essentially, you know, do the HECA BOGA telescoping, like, much sooner than otherwise. Then the question is, how do we square this with Glencer Dam? And… Yeah, I think it's… yeah. It might be a little… little tricky. So… Yeah, thinking about what to move… how to… how to move forward here. So, okay, I mean, one thing we could do is just take this as a given. I don't know if we're gonna reach consensus on this call today, on Fossil. Which means we probably won't finalize the Amsterdam scope.

But that would be one path forward, is, you know, we could talk about the rest of the EIPs today for your Amsterdam. And then from there, we could start thinking about ecoscoping, because, yeah, I agree with you, Barnabas, that… we don't necessarily have the tools, at least, okay, we do have the tools, because we could CFI, we could even SFI. But… Sounds like that makes some people uncomfortable. So… We could start that process. Then the question is just, you know, if we don't get to a reasonable heca scope that people are happy with, then it would essentially roll back to the clamp stream scoping. So… There's some risk there. And yeah, just going from the chat, there's…

Certainly just, yeah, I think we're pretty split on this as a group. Like, plant…

Lightclient (Matt Garnett): Yeah, I just propose that we… start moving forward. I think that it's too contentious to go into Glamster Dam. That's… You know, objective at this point. And the best we can do is… CFI. For HECA. There's really no other commitment that we can actually make. We can SFI it, but that honestly just dilutes the meaning of SFI, because we really can't Decide what is going to go into the fork this far out. And without doing the actual headlining identification process.

Alex Stokes: Yeah. That does seem like a reasonable path forward to me, just given, yeah, the process we have and how things work. But that all being said, I know, you know, given the demand for this, I'm open to finding other creative solutions. I think it was Kaspar, so I spoke, and then Anskar.

Caspar Schwarz-Schilling: Yeah, I just want to point out that on last ACDC, the discussion was whether fossil should go into Glamsterdam, because there's already pretty broad support from a lot of clients. Obviously, also some voices, a lot of voices against, but point being, the discussion was anchored on whether Fossil goes into Glamsterdam. And as a compromise, We wanted to explore a credible commitment for Fossil in Hakka. And if we cannot find that, then I think the discussion needs to go back whether to whether fossil should go into Glamsterdam or not.

Lightclient (Matt Garnett): I mean, we can have the conversation of fossil going into Glamsterdam, but… it's not gonna go into Amsterdam. It's already clear there's too much contention for it to go in. So, there's not really anything else to do, as far as I can tell.

Alex Stokes: Yeah, so I spoke.

soispoke: Yeah, I mean, I agree. I, I think… Cfi, basically. You know, the process changed quite a bit. So it's, it's also, like, hard to follow. you know, when the process changes, and for what reason, but I think it's pretty clear that CFI-ing has become a bit meaningless. Like, it's… for fossil, for example, like, program for them, it's been Basically, more of a, like, on hold… status than any sort of, like, credible commitment for inclusion, and we can see that very clearly. So I think… I don't think there is, like, no alternative path, like, I think an alternative path is to SFI for school for HSTAR. If not for Glamstadam. yeah, for me, it's just, like, CFI for, for, for Hecker.

It's not equal to a credible commitment. Like, we are… we are saying we want to get better at pipelining. We are saying the main reason, like, for Soul is not going to be included in Glamstad is, like, for scope and complexity. I think if that's the only reason. And we ship folks on a, like, faster cadence anyways, why wouldn't we able to credibly commit And improve pipelining to… to… SFI-ing for sulfur for Hecar. I think, like, otherwise, like, you can't just, like, change the process whenever it fits with what you sort of, like, want to include. It just gets very confusing.

Alex Stokes: Bansgar. And then Excel.

Ansgar Dietrichs: Yeah, I personally think that the debate is a little bit mis-focused, when, to me, the credit commitment is already a bit of a strange term. I mean, obviously, we like that in crypto, but I… don't think what we want, really, here is to somehow make the process force us to include this in H-star, because If there ever, like… I think it's… it's a super fringe outcome where we all, in the end, in 6 months, are here, and we no longer wanted an age star. If that were to happen, then something clearly must have happened in between that really changed our mind. Maybe someone found a really big flaw in Fossil, or, like, we have a new proposal, and it's not quite ready, or what… who knows, right? Like, it would have to be a very different world.

For us to… to be in that position, and so it makes no sense to me to really try to find a process tool to basically commit us to including. I think the main level of comfort or confidence that people here were looking for is just, do we, as core devs, all agree? And I think the answer is clearly yes, right? Everyone here wants it in H-star, and I think that is what matters. I feel like we're kind of, like… it's a complete sidetrack to find a process. It's also a hack of the… like, we should never pre-commit like, this early on. And if we CFI it now, I think CFI makes a lot of sense. Of course, it doesn't mean it's guaranteed, but it is basically guaranteed, because we all very strongly want it in the fog, and so any work that's starting now for… in preparation of H-star will already make the clear assumption that it will be based on fossil, and I think that's very productive.

Alex Stokes: Yeah, and maybe, you know, just to go down the CFI path a bit more, like. we could add a note, I don't know, there could be some, like, special designation that, even in the MedAP says, hey, like, you know, everyone expects this to definitely be included, so… There are ways to, yeah, strengthen, strengthen the language, and hopefully then the commitment. Nixa.

Nixo: Here's my proposal, is that we… between this call and the next ACDC, we outline the next headliner process, because we've only gone through this… this headliner process once. We don't really have, like, a clear consensus of what it has to look like. So instead of this headliner process presenting 8 to 10 headliners that we choose from, we have two decisions to make. The first is, is Fossil the headliner? That's a yes or no. It's in… it only is a no if people feel strong opposition that in this… in the time between now and H-star, things have significantly changed. Second decision is what is the headliner that may accompany Fossil. And this way, it's a… it's a more credible commitment without having bypassed the meanings that we… that we

outlined for SFI and CFI, while also giving time for people outside of the 68 people in this call to decide what the headliner for H-star is going to be.

Alex Stokes: Yeah, I mean, I think that's probably the most, sort of, by-the-book thing. I would… Be a little concerned that it would be rushed to do the headliners, like, now. And then it could be the case that, yeah, we get to a headliner set for Pekka, and fossil's not there, and then it, like, ripples back through everything. But, that being said, perhaps we should just try. And… yeah, I mean, again, I think it's… I think we have a good sense of what our headliners are that we'd at least want to think about. Tony?

Toni Wahrstätter: Yeah, I would agree with what Amska just said. It feels like CFI-ing would be the right decision, because we don't know, where we are in 6 months, or next year sometime. So, yeah, it feels like the commitment the clients gave, which is, supporting it in Amsterdam on a conditional basis, is already a commitment, enough.

Alex Stokes: Okay. So, in terms of moving forward, what I would say is that I think we should go ahead and assume, as of this call, that Fossil will not go into Glamsterdam. From here, I do think there's a question of, do we want to CFI, do we want to SFI? Or do we even want to go ahead and just, you know, move through the headliner process for HECA? I would propose we take that async, and then try to get to some resolution, again, asynchronously before the next call. In terms of how to move forward. And… for example, I could go ahead and make a PR to the Medi IP in the next week, That would, yeah, do SFI or CFI, and that can be a place we can take some discussion there.

Separately, yeah, I can reach out to everyone and try to get a sense of what's the best path forward. So… Does that seem okay? And yeah, I mean, Delight clients… point here in the chat about making a decision, I think, you know, this is essentially DFI, but conditional on finding the right configuration. So I spoke.

soispoke: Yeah, I mean, I do feel like, at this point, I don't want to, like. Be difficult or something, but it feels like it's been… maybe 6 months, or, like, over… over 6 months, then, like, people… people have supported fossil generally, and… every time… Like, it is a bit contentious, and every time we sort of, like, keep delaying making decisions about it, And I don't know if, like, sentiment is gonna change from now Compared to, like, two weeks later, basically, so I'm… I'm, like, feels like, you know, like, it's very clear what the trade-offs are, everyone is, like, pretty clear on, like, what people want, and… and… and, like, from now on, like, it feels like every time we have a conversation about Fossil, it's more like, okay, yeah, maybe let's see if I put it on hold. It was, like, that for the headliners, and it's exactly that for, like, the non-headliner EIPs.

And then it's gonna be exactly the same for HECA. I just feel like at some point, like, it doesn't really mean anything anymore to delay processes and decisions, so…

Alex Stokes: Okay. Yeah, I mean, if I had to make a decision right now, I would say DFI for Glenster Dam, and SFI for HECA, and then we just move forward with that. And we'll just have to accommodate that for the headliner process, you know, say in a couple months when we get to it. Okay. There's a clap emoji. Is everyone okay with that? I think that seems to be the thing that swears most of the sides. Okay. I'm getting a lot of positive reactions. So… okay. Then let's do that, and just to repeat it to be clear, DFI Fossil for Glenster Dam. I will make an SFI PR for Hecca Bogota for Fossil. And then, yeah, you know…

The point being is this is, you know, I think the strongest signal we can make today, for the headliner process for Hecca Bogota, again, in a couple months. Yeah, and then we'll move forward. Again, I… think the sentiment around inclusion is clear, and again, maybe just to make it abundantly clear, like. This is the thing people want to ship in Amsterdam. They might want to also ship other things, and then it's… they're sorry, in HECA. Let me start over. To make it abundantly clear, the sentiment is to ship this in ECA, this being fossil. There might be other things we want to ship, and we're gonna have to figure out, you know, how to square those two down the line, but again, I think, given that we're starting today, there's a really straightforward path to do that.

Okay. Great. From here, Let's move to the rest of the EIPs. And, let me just find the agenda. It floated off somewhere. So, okay. From here, yeah, there's 1, 2, 3, 4, 5, 6 other CLEIPs for Amsterdam. And… Yeah, I think in terms of moving forward, so there is a bundle of things here around the term limits and consolidations and how they work with exits and all the above. There has been an update here, because we said we would split out, I think it was a leaner version of 8061 into 8080. Is Francesco on the call? Because he could give us some more context on what he did there. Or if someone else is aware of… oh, actually, Francesca might not be here today.

Okay then we'll move…

Mikhail Kalinin: I can probably speak a little bit on that.

Alex Stokes: Oh, sure. Yeah, that'd be helpful, thanks.

Mikhail Kalinin: So… Yes, the 8080 is basically, allows to use the consolidation queue, for exits, when the exit queue is longer than the consolidation queue. That's basically what it does. And, it's, also fixed to the problem that the 8071, fixes. And, in my opinion, 88 is strictly better than 8071, so I would prefer it to replace the previous EIP. So…

Alex Stokes: Okay.

Mikhail Kalinin: And, could someone remind me how Yeah, sorry.

Alex Stokes: No, go ahead.

Mikhail Kalinin: Yeah, it just basically does the only this thing.

Alex Stokes: Okay. Great. And how does 8061 relate to 8080? That part, I haven't had time to dig into.

Mikhail Kalinin: It's, AT61 was proposing to basically do the same, to reuse, to use consolidation queue for exits, but it also does other things, like, increasing the, exit queue. The most recent version of 8061, basically. Keeps the activation queue the same as it is today, but increases the exit queue and also allows to use consolidation queue as the exits. So that's… that's a bit different, the IP. It changes the queue, and it changes the acceptability period.

Alex Stokes: Okay. So, then in that case, I think it'd be fair to say that we have 8080 to replace 8071, and yeah, that tracks with what I remember from the last call. I think then we would also want to think about 8061 and 8080 together, so it's not that one replaces the other.

Mikhail Kalinin: Right, so 8080 is an alternative to 8071, but not an alternative to 8061.

Alex Stokes: Okay. Thank you. Potus?

Potuz: Yeah, I just want to remind that there was some pushback against, 8061, and that's why 8080 was, was proposed, and we… we were one of the ones pushing against 8061. 80… 8080 seems to us as a better fix for the problem that 8071 would fix, so… My personal preference, I'm not sure if President is behind this, but I suspect they are, would be to go with 8080 and GFI 8061 and 8071.

Alex Stokes: Okay, and just to be clear, we would lose, this change to the trim limits themselves. Right.

Potuz: Right, so the problem with that… well, there was… yeah, there were a few things. I mean, whether or not we had enough of a discussion about the sensitivity period, and also that it touches… I mean, it's a deeper change than the simpler change, just the helper. on updating the churn, and compute the exit, and update the churn that 8080 does. 8080 is a very simple change.

Alex Stokes: Okay.

Anders Elowsson: Maybe… Yeah, so essentially, it's sort of an efficient way to ensure that we use the SHARN. But I haven't really… did you… because as we were discussing, things during the last, call, I felt like the discussion was that, that you guys would, sort of, maybe… maybe consider what… what kind of weeks of activity you find acceptable, and maybe have some input on that for this talk, or something like this. Did anyone make any further considerations on that? Because, I mean. Just increasingly showing in general would be positive right now, because we want to ensure that we don't have so long queues. Maybe someone has input on that.

Alex Stokes: Yeah, does anyone? I'm not sure what DevConnect people have had time. But I do agree it would be nice to consider. Greg?

Greg K | Lido: Yeah, so I think because the discussion goes to, kind of, the technical details of these alternatives, so I guess what is… agreement is that, we all agree that we should fix this consolidation queue issue. Like, also, in light of we had identified this and report to Francesco, that, like, this feature is unintended and it exists. But, like, for both those alternatives, I think there is some kind of extra discussion, so I'm okay, let's say, for 8080, but we also have some extra comments on it, like, not as it is now, but with… after some edits. But yeah, through DevConnect, we didn't have time to properly, you know. review. So, I'm not sure if we can now, like, in this call today, make a final decision

on with CAP, we could keep the agreement that one of those will be here… will be there, definitely, to fix this issue, and perhaps have a specialized breakout call to discuss these technical details, because I don't think that now is the time to discuss the details of them. I don't know what others think about it. So they just, like, agree that one of them will be definitely there, we cannot deify all of them, that this will not happen, but, have some Additional discussion on it, but not now.

Alex Stokes: Yeah, I mean, we might want both, just to throw it out there. Anders.

Anders Elowsson: No, I just want to say, yeah, so… so 8080, it gives us both things from… that we wanted from 71 and 61, so it gives us both. So from that perspective, we might be satisfied with just 880, but we can also consider 61.

Alex Stokes: Yeah, and maybe just to play back my understanding, we'd want 8061 if we also want to change the… increase the churn itself. It seems like there's pretty broad agreement on 8080 as a way to fix, this issue that 8071 set out to fix. Potus.

Potuz: I'm sorry, I was gonna say your last sentence, that we can probably DFI 8071 right now, and then… I mean, if people still want to delay this discussion, we can discuss later whether we go with 8061 or 8080, assuming that we're gonna take one of the two. So these… these two commitments, I think we can… we're ready to make today.

Alex Stokes: Yeah, I agree with the DFI and 8070, so yeah, let's go ahead and do that. Is there appetite for both 8080 and 8061? And really, the thing I want us to consider is just increasing the churn limits, which I don't think 8080 does by itself right now.

Potuz: But isn't… so I thought… I haven't checked if 8061 has changed, but I assumed that 8080 was just a subset of 8061, that it's just removed.

Alex Stokes: So that's my understanding, yeah. But I don't think it touches the Chinese one, right?

Potuz: I thought 8080 is the substance.

Alex Stokes: Okay, that was the… yeah, yeah, I see what you're saying. So the contention was actually with the churn limits, and so we took both the nice things out into ADA. Okay.

Potuz: Right, so 8080, I think, is consensus that is the right fix for 8071, and 8061 might have extra stuff that we may or may not like.

Alex Stokes: Yeah. So… I would actually go ahead and say CFI for 8080, because I think we feel good on that, and I think we'll need another call to think about changing the churn limits. So then I would kind of propose we do that. I guess the one thing is if… the only extra bit of 8061 is the turn limits, and we decide we want that, then we do 8061 instead of 8080, but… That seems… yeah, like something we need to figure that out. Yeah. Okay. So, maybe in terms of process then, we'll just leave both of them alone, and yeah, the ask would be, we will decide on the next call, so we need to figure out

How to adjust the turn limits, if we want to do that. So… okay. DFO 8071. 8080 or 8061. We will CFI one of those, or yeah, some combination of things here. It just sounds like, even from the chat and what people have said today, we need a little more time to dig into that. So we'll do that. So… There's a question from Greg, just keep the… Point, that's spec updates. Yeah, I mean, so, it just… the thing is, I think the Slack updates we want to make to 8080 would just get us back to 8061, so, like, we can just figure it out. But I think what we can say today is, like, we'll CFI something between these two.

And we will define that something on the next call. Two weeks from today. So… okay. I think we're pretty good there. The next one in this direction of touching, different staking mechanics would be 8062. This is adding… I think it was, like, a 5 BIPS withdrawal fee, on the sweep for 00… One validators during their withdrawal process. This one is interesting. I think, from what I recall from client opinions on the last call, there was kind of, yeah, a mixed, mixed view here. I will say we had, at least, you know, I saw some of our conversations last week at DevConnect. And sentiments seem to be against us, if only because it feels a bit early.

The main thing this EIP would set out to do, as far as I see, is drive more consolidations more quickly. And yeah, again, just talking to different validators and, you know, just generally people in the community last week, it sounds like the issue is not so much that, it's not so much, like, an economic thing that's ruining consolidations, it's more the tooling, and so that seems to suggest people just need more time. So, again, I could see something like 8062 at some point. Personally, it feels a bit early to do now. What do others think? Yeah, Anders?

Anders Elowsson: Yeah, concerning timelines, yeah, so it would be… if we… if we do Glamsterdam in, say, I don't know when it happens, 8… 8 months from now, or something like that. I think we need to be a bit forward-looking and consider the fact that it's not something that's gonna take place now, it's gonna take place in quite some time, and that once we get to H-star, it's going to have to… have taken quite a long time until we have some incentives in place, and I… Of course, I agree with the notion that there are plenty of staking service providers that will We'll switch over. to compounding validators. I have no doubt about that. And that they are working on it right now, but I am also fairly certain that there are

many, many setups and some saying service providers to have a certain proportion of their stake that they do not intend to move over and compound and consolidate. At least, that's the impression I've gotten from the conversations right now. And so my point would be, That we… we should really signal that we want them to move over, and the way to signal that is to impose a very small the first kind of fear, because as I've said before, it's more profitable for you to stay on on the sweep validators, if you have, for example, 128 ETH that you're sticking on 4 sweep validators, and you could consolidate into one 128 ETH validator, you would have better capital efficiency, as it is right now, on the sweep validators.

Although it's not, of course, 100% certain that you know what you want to do with that. additional capital, but we can presume that you, perhaps, will have some profitable avenue for spending that capital, so… so that's just my point that I want to say there, but I'm open to the conversation there.

Alex Stokes: Okay, thanks. Dima?

Dima Gusakov: Yeah, so, the problem with OX01 validators and with these, like, it's not just the fact that, some saving providers, or most of the staging providers, are not consolidating validators because it's more profitable for that. it is way more to it. So, first of all, like, from the solo staker's perspective, and from the conversations that I also got last week, like, a lot of solo stakers indicated that for them, for example, it is crucial to have predictable income. That is… that gets materialized on their execution layer wallet, because at the end of the day, they need to pay bills. And with, since most of them are not super nodes capable of having, like, 2K ETH, which we discussed multiple times here, this is a very huge pile of money.

The only option for them, should they consolidate to all XO2, is to use partial withdrawals, and with the current withdrawal queue, partial withdrawals share this… the same queue, or at least they… I mean, it's not that predictable, so this is the take from solo stakers. They do need sweep, because they do need predictable rewards on their execution layer wallet, which is understandable. And that might be solved with, say, custom ceilings for OX02, so that once you consolidate, you can also set the suite threshold, which would for sure be higher than 32 ETH, but at the same time, it will fit your needs. So imagine you are a solo staker with 4 validators, you will be able to set it at

I don't know, 128 ETH or so, and still do, like, do both, so benefit for the network, because at the end of the day, you cannot consolidate more than you have. and you get predictable withdrawals. The same problem, or kind of the same problem, is also true for professional operators. So the second comment here will be from professional operators who work with their clients. And even though at the dashboards it might seem that, I don't know, Figment, P2P, or whoever else, they own a huge pile of capital, and they have a lot at stake. internally, this stake is not owned by them, so their clients, they prefer to have control over withdrawal credentials in most cases, which means that if their client does not have 2K ETH,

It means that for them, again, consolidating validator means changing the conditions or the terms that they have in between them and the client, where, for example, the client was previously getting these rewards on a regular basis. And now, with, with their validators being consolidated, but not up to 2K, they will not get this rewards, which would involve, like, changes to, again. Oh my god, the contracts, and so on and so forth. And the last thing, and this is probably the thing that I'm the closest to, is for the staking protocols like LiDAR, there are modules, like community staking module, where with the current OX02 design, it's practically unfeasible to transition to OX02, Because of the way how bonded validators are, how fractional staking works, because you will need to…

Have sort of a regular update process or whatever else that would increase bond requirement as the validator balance increases. And, for example, without custom ceilings, without any, like, feasible option here to have a predictable amount of ETH on the consolidated validator, which is guaranteed by the network, Lido will simply not be able to transition any of CSM validators to OX02, Just because of this limitation. So, I would say that even though the… I fully share the intent, and I fully believe that most of the network should be consolidated. But there are some parts that cannot be consolidated with the current design of OX02, and we should take it into account. And instead of creating a disincentive for OX01 validators, so that people will be in a situation where their condition got worse, and they are forced, somehow forced to migrate to OX02,

I would propose to think about how can we improve OX02 design so that it will fit the needs of the majority of the ecosystem players, and we will eventually end up with, I don't know, with evolutionary transition to OX02, rather than forceful transition, where we simply impose restrictions or penalties on the OX0101 validators.

Anders Elowsson: Yeah.

Alex Stokes: Yeah, Anders.

Anders Elowsson: Yeah, so I think we are in broad agreement that we should have this, sort of, User, tunable, ceiling. So… so I wouldn't, I wouldn't say that, there's any disagreement there, and we can, sort of, for this discussion. assume that perhaps we will try to achieve that for H star, but my point is that Well, it's just my… I don't think that we will reach the sort of consolidation that we need, even with such ceilings. And that's why I… When we have two options, then, for, for, for, for facilitating consolidation. The one option is to sort of reward, stakers for having larger… larger validators, and the other one, which is proposed done in 1862, is to sort of,

incentivize them to move over and, in that way, consolidate without specifically rewarding bigger validators or smaller validators. So that's essentially the rationale for doing AT62, but Yeah, so that's what I wanted to say about that, but I can see, of course, the point can be, like, oh, before… since we do not have, that, that tunable threshold that you can set yourself, then, okay, then we should not do the incentives before that, but the way I see it is also that Hi. this, yeah. I fear that we will delay finality… fast finality by not trying to, sort of, be a bit more… Yeah. forceful on this issue, which will be a big degradation for Ethereum.

Alex Stokes: Bunner to go.

Enrico Del Fante: I just want to say that I was resonating to Dima's last comment, saying that we should make new things, improve, instead of adding… forcing people to move via penalties. It's just features. That needs to be improved to make everything better on the other side. A part of that, maybe I'm not… fully, grasping the reason why 02 has an impact on fast finality. I don't know, if we kinda introduce the least limit on the 02, then we fall into the same category of problem where There are a lot of sweeps and withdrawals, and we may have the same problem on 02 as well.

Anders Elowsson: Okay, maybe I can explain about Fast Finality very briefly. Oh, I'm sorry, did I… did I interrupt you?

Enrico Del Fante: No, no, it's fair, if you can elaborate on that, it will be definitely helpful. Well, I don't wanna… I would just wanna double-check if the DEMA idea actually fits the needs of having an improved 02 while being compatible with Fast Finality.

Anders Elowsson: Yeah, yeah, no, no, I mean, I totally sympathize with the idea of improving… improving the compounding validator. I just don't think that it will be enough. So that's… that's why… why I… I proposed A to C2, because I… I do not think it would be enough, because I know that certain staking service providers, they are locked in… in the… in the sweep… sweep validator, and… and they… they don't want to… And they would… this is just going to be a lot of work to change, and they would prefer to do it. And so then we have options for… okay, and so the reason we want to have a consolidated valid data set is because in this fast finality design, that the consensus team is working on.

all validators are going to cast their votes on finality within a set time frame, such that we can achieve a faster finality. Right now, we need to go to 32 slots plus 32 slots to reach finality. So that's the reason why we want to consolidate, because then we can use fewer votes. that's sort of the main… main reason, but… but this design is sort of in flux right now. It's not certain exactly what it will look like, but… but the general… general… generally, just fewer validators will help us achieve.

Enrico Del Fante: It means that it requires a lower cup.

Anders Elowsson: On the, on the… on the…

Alex Stokes: Just a lower number, like, there doesn't have to be a cap, but the smaller the set, the better for finality designs.

Enrico Del Fante: Yeah, but if 02 now has a kind of a limit in which it starts withdrawal, withdrawing, Let's say, -oh, more than… 266. It means that Yeah, we are still in this range where we might not have enough Enough consolidation, because 266 actually represents just 4 validators. Not more, so…

Anders Elowsson: Yeah, yeah, that's true. That's true, but we will have to sort of… the idea is that we observe that there are only, like, 5,500 nodes on the network, and we want to, therefore, the ideal would be to have, like, 5,500 validators, that's it. And we want to go as close as possible, and then those that only stake 128 ETH, yeah, of course, they will have to then stake 128 ETH and nothing more anyway, so that's perfectly fine.

Alex Stokes: Okay, let's jump back to the scoping discussion, but yeah, hopefully that was helpful. So, while this was going on, I was also looking at the client opinions from last week, or the last call, and it seemed like most client teams were neutral to against, and yeah, I think also given the arguments today, it's kind of in the same… or in the same spot. So, I would propose we… DFI 8062. But all that being said, as you've seen from the discussion, yeah, there's definitely more to do here, around making 0.2 better, and we can always keep 8062 or something like it for a future fork, and yeah, move forward there if we need. Pressure to go to 02.

So, anyone disagree with, DFI? Of 8062. For your Amsterdam.

Anders Elowsson: Well, I disagree with it, but I don't, if everyone else agrees, then I don't wanna…

Alex Stokes: Yeah, this seems to be…

Anders Elowsson: They're of concern.

Alex Stokes: So, I think we move ahead with DFI.

Dima Gusakov: The final point to add here, is that, Anders, I agree with you that we do need to have, again, as many consolidations as possible. The problem with, with the current EIP is that in the same way as we are currently discussing in the chat, that custom ceilings, and as you said, might not result in a sufficient consolidation, what you're proposing would also likely not result on its own in a sufficient consolidation. So I believe we just need to add, like. a few more blocks there to increase our chances to maximum. I'm just not super comfortable with saying that we will start with penalties before improving UX. So I would rather go with a path where we improve UX, and then, should we see not enough consolidations, we can confidently say, okay, we did our best to improve user experience here.

And, then, guys, okay, now it's time to impose a penalty.

Anders Elowsson: Can I just say that, okay, I mean, yeah, I just want to say that I'm fairly certain that even if we set this variable threshold, it's not going to be enough, and that we need some sort of way to move people over and to consolidate, so… I don't agree with the framing that, oh, let's try this and then see what happens, because I'm just… this is just my personal conviction that I don't think it's gonna be enough. But yeah, if everyone disagrees, then of course, I'm not gonna… Object.

Alex Stokes: Okay, so yeah, let's move ahead then with the DFI of AD62 for Glemsterdam. And, yeah, from here, again, there's… Different designs to pursue. you know, I'll just throw out here, we have a breakout room as an instrument, so, you know, maybe that's one path forward, is a breakout room for this, and then from there, you know, we have some time to work on a different design for a future fork. Okay. So, let me see the list here. We touched on all of these… Okay, so then we just have 2 more to get through today, it looks like. So, yeah, let's do 8045, because I think it'll be pretty straightforward. 8045 is this EIP that excludes slash validators from proposing. Pretty straightforward, it's in the name.

Right now, they're not excluded, and especially in situations where there are mass slashings, this leads to, essentially, yeah, let's say degraded performance. Because there are just many fewer blocks. And that's not great. So, again, going over the client opinions, it looks like there's generally sentiment to move forward with this. It is a pretty small change, and yeah, my only hesitation would just be adding many small changes. But, yeah, would anyone like to speak for or against the CIP? Notice.

Potuz: Yes, as I mentioned last time, my grudge with this CIP is the fact that today, I mean, to know who's proposing or not, we can use many states within the epoch, not necessarily a checkpoint state. And these are the kind of things that we cache. Now, the reason is because we only care about being active or about the effective balance. Being slashed is something that happens within an epoch, and this forces us to use a state that has to be the right state to check for proposals. This is a change that I'm not completely comfortable with because of this reason, that this forces us to use a state that might not be the state that changed pre… within an epoch. On the other hand, after Fulu, with a look ahead, it sounds that it's safe.

But it's… I haven't really vetted it yet.

Alex Stokes: It does seem like Proposal Look Ahead, yeah, would get around this, because you can just always check that in the state.

Potuz: Yes, that's if you actually have the state for the right branch. So you need to have at least a state that has the right look ahead. But yeah, so I suspect that it does fix it, but I don't think it's trivial as to say, yeah, this is a very simple change, and that's it.

Alex Stokes: Yeah.

Potuz: It might bite us as the attestation index did.

Alex Stokes: Sure. Barnabas?

Barnabas Busa: Yeah, so I think this would be very good, to be able to recover from an unhealthy network, and this is actually… this was pretty critical in Holsky, So, I would like to see this change in, And with the proposal look ahead. I just don't see the probability of having a validator that gets lashed on the same epoch where, it's gonna be proposing, like, that's not such a big deal. What the big deal is, is if we have a huge amount of validators that get slashed, that we're gonna be just missing blocks all the time. So, like, even if… even if you have a validator that is going to be included in the next epoch that gets slashed in the current epoch.

Then, like, yeah, we're gonna be missing one block, but the chance of having that is very, very small.

Potuz: But it's not about that, Barnabas. The issue is not that I am afraid of, like, hitting a proposer that actually just got slashed. The problem is that if anyone gets slashed, and I'm using a state that counted that validator as active or not, I might get a different shuffling, and I might get a different set of proposals, regardless of whether or not this guy was included or not. That's the whole point. I need to be careful as to what is the state that I cache to check what the proposals are. If there's only one line, one branch, and we're not for it, the proposal look-ahead immediately gives me this. If I am Fort, I'm not really sure. I…

Would need to vet that.

Alex Stokes: Okay. So, pending this concern, which I agree we should look into. would people, like, do people generally lean towards including this in Amsterdam? Because one thing we could do is CFI it today, and basically just, yeah, have this, like, pending… to do. To verify this thing. And if it turns out that there's an issue, like POTUS is saying, then we would just take it out. Or we could change the IP, so there are options.

Potuz: I think we can… we can, like, SFI it if we agree that some people are going to get together and vet that the proposal look-ahead works. Even if you're, like, syncing from a branch that you haven't, that you don't have. Like, if you manage to sync enough states from that branch until you hit the proposal look ahead, you can use any state that contains that slot. So I think this is true, it just needs to be vetted.

Alex Stokes: Yeah. So, yeah, I mean, that's what I'd say, is we go ahead and put this into the CFI set, and again, this, you know, correlates with how we usually take it, you know, process these things. If there's a security issue, which this would be a security issue, then, you know, obviously we would adjust or just even take it out, so… I think in terms of moving forward, we go ahead and CFI, and yeah, do exactly what Putin said. Some people… well… look into this more deeply, and yeah, I will… at least do what coordination I can to make sure that someone's actually on it, and that we don't drop this. So… okay. Are we good there?

Okay. I'm curious what other client teams think. Because everyone else has been pretty quiet on the issue. all I'd really see then is just, the opinions from last call, but again, they were pretty positive, so… okay, we got a lot of plus ones. Okay, so yeah, then CFI… Let me get the number right… 8045. Okay. Then, we just have one more here, and yeah, then we will have made actually a lot of progress today, which is great. So, the last EIP to discuss for today would be 7688, and this, is forward-compatible continuous data structures. This adds stable container into the SSC spec. I actually do have a question. with the CIP. if it were in, does it also imply that we go ahead and change, say, the beacon state or different data structures in Glenster Dam? Like, would we actually go ahead and also…

Not only introduce this new concept of stable container, but also go ahead and change data structures.

Dustin Brody: Yeah, so the most basic version of this is that it changes some bounded lists into unbounded lists. So it doesn't necessarily change the overall shape of these data structures, but it removes some in many cases, actually kind of meaningless bounds. If you look at the validator limit, that's just some big number. And it removes those things. But it doesn't restructure them in any other way.

Alex Stokes: Okay, but yeah, I guess to be clear, like, this isn't just adding this concept to the spec, this would actually, you know, if we include 7688, it would actually be, you know, touching… Like, would it just replace every instance of container in the spec with stable container?

Dustin Brody: It… not every. It's… it's… there's some case-by-case aspect, I believe, but… but it's many. I mean, it goes through… the EIP goes through and sort of covers the case-by-case aspect again, and this is not… people can read that, but…

Alex Stokes: And… okay, cool. Just to play it back then, in terms of sentiment… Yeah, I think client teams, some of them were for, some against. There's also… A lot of community support, that's worth calling out. Even on the agenda today, Ocean from OBOL said, you know, they support this. There were a number of, comments from the last call from different staking pools and things that also were interested in this. Some other people are here on the call, and yeah, they're also interested in this. So, you know, I think the thing that has always been the question here is, you know, when is the right time to do this? It's certainly nice to have, but Ethereum, you know, will survive without it. So we just have to answer the question, like, yeah, is now the right time?

I'd love to hear from some client teams. And also echo here Barnes' comments, you know, how complex is it? even putting aside the code complexity, which would touch SSD libraries, you know, I am very curious if clients think they'd want to get audits of the new code, because again, if there's, like, a bug in this, like, the chain forks, and it's quite bad. So, yeah, even if, again, the, like, spect is small, I think there are considerations around security here we should take into account. So yeah, any client teams want to chime in? Kingitas stay here for Lighthouse. They were originally against it, but now they're more open, given the Miva Fossil to Heka.

Saulius Grigaitis: Yeah, so for… from Remdina's side, we… we think that this feature is really great and nice to have, and sooner or later, we… we definitely should have it. But at the same time. As seems the consensus is still that we need to ship the hard forks as soon as possible, or essentially fast. We think that it's, it's a bit too big feature to, to put that into, into Glamsterdam, so… I mean, unless there is shift of thinking that, you know, the longer hard forks are actually not that bad, then we would accept, and we would promote this feature. But unless this happens, I think, it's, It's not, glamstaden is not the place to put this.

Future.

Alex Stokes: Okay. Other pontofts. Enrico here. Tegu in the chat says we're okay with 7688. I don't know, yeah. People are generally saying it's slow effort, but again, I think the question, that I would have is hear what Perry said, how large is this feature going to be? And, you know, just put it in the context of everything else. Yeah, I… I'm not sure myself. Like, what I don't want is to get to a world where… you know, this is something like that decision change in Petra, like POTUS mentioned earlier, where… again, it might look simple, but as we get into it, it's way more effort than we think. And again, it's like, I do think… yeah, there's performance implications, as Terrence mentioned in the chat, and then definitely security here.

Yeah, Barnabas proposes VCFI, and then, yeah, basically we can take it out if it looks like it's too big. I would want to do that sooner rather than later, if we do do it. But yeah, it does seem like generally there is support for this. And one thing that would be nice is I think Etan is the champion, and he's not here, which is unfortunate, so… If we CFI, that gives, yeah, I guess, more time. For him to come make a stronger case. Okay, I guess the other thing is we'll still need one more call to finalize the churn EIPs, so we could just pause on this for now, and… I will reach out to Etan and try to make sure he's at the next call.

Then we can decide there. But I can say, yeah, people lean towards including the cell, but this might also give people some more time to look into the full complexity. So how about we do that? So… Again, I think we made a lot of progress on most of the EIPs. we would still have, I believe it's just some question of 8061 versus 8080 on the next call, and then also, 7688. And we'll… we'd be… we would be making final decisions on those EIPs on the next call, so… Okay, no one seems to have any issue with that. Okay, so let's do that, and then just to summarize, yeah, I think people lean towards including 7688.

And from there, we can move ahead with the fork. Okay. Barnabas had a question here… oh yeah, SSC and the engine API, yeah. Do you want to say something, Barnabas? We have a few minutes.

Barnabas Busa: Sure, so the idea would be that, we should probably drop JSON, just because the number of blobs we're planning to put out in the next, year, and ideally, we should probably have the engine API to support FLZ, and make, all the calls, In… in binary, basically.

Alex Stokes: Yeah. I agree that's something we should do at some point. Okay, there's a few other things, I think, to call out from the agenda, but then let me play back the Glamster name decisions, just so they're all clear. So, with Fossil, We will SFI for Hecca Bogota, and DFI for Glamsterdam. 47688, gonna make a call on the next ACDC. And the ask there would be to get a better sense of the total complexity and what's really involved. 8045, we said we would go ahead and CFI today. Although there is this caveat that if it turns out that there's some issue with how this feature works across forks and complicating client implementations, we would pull it out.

8061 and 8080. Again, we're going to look a bit more into the observativity and figure out exactly what's the best thing to do there. We'd answer this question on the next call, and essentially do one or the other. Or find some resolution between those two. 8062, we decided to do DFI for Amsterdam. And 8071, we decided to DFI. So, I believe what I said was correct. I ally client.

Lightclient (Matt Garnett): We didn't really get the decision to SFI fossil for HECA. Like, we were kind of discussing different things, and it didn't seem there was a decision to do the SFI, it seems like. That wasn't what was agreed upon?

Alex Stokes: Mmm, I think it was. We said DFI for…

Lightclient (Matt Garnett): Pull all the client teams.

Alex Stokes: Yeah, well, just on this call. So, you know, this is what I believe I said earlier in the call, and there were a bunch of thumbs up at the time.

Lightclient (Matt Garnett): But, I mean, we can't just, like, decide things based on some chat emojis. Like, we didn't ask individual client teams if they want to SFI it. And I feel like, at minimum, we should ask the client teams verbally if they want to SFI for HECA.

Alex Stokes: Okay. Prism.

Potuz: We haven't had this discussion, Bottus wants to SFI it for Tekken.

Enrico Del Fante: we were for it in Glamsterdam, so we are. break.

Alex Stokes: Sorry, what was that? I just missed it.

Enrico Del Fante: We were in favor for considering them in fossil in Amsterdam, so we definitely are. In February. Let's see if I aim for HECA.

Alex Stokes: Okay, I guess the question is also, though, if you're okay with SFI.

Enrico Del Fante: Yeah, yeah, for, for HECA, yes.

Alex Stokes: Okay. Lodestar? Or yeah, Sean unmuted, so, Lighthouse.

Sean Anderson: So just for me, like, me personally, we haven't talked about this particularly in the lighthouse, but the… I feel like it should be CFI, not SFI. I agree with, like, Klein's point that it kind of dilutes SFI, because, like. Is it, like, are we actually committing that hard to it?

Alex Stokes: It seems like we went to today, but… Okay. Sure.

Sean Anderson: Yeah, just personally, yeah.

Alex Stokes: Yeah, And… okay, nimbus, I think Dustin had a comment in the chat that he's fine with SFI. Lodestar says they're okay with SFI…

Lightclient (Matt Garnett): Nimbus said they're fine CFI-ing.

Dustin Brody: Either is fine. No, no, no, either is fine. I responded, yeah.

Lightclient (Matt Garnett): Yep.

Dustin Brody: Yep.

Alex Stokes: Okay. Grandine, I think that was the last one. Solius, are you okay with SFI of fossil and HECA?

Saulius Grigaitis: I just wrote on chat.

Alex Stokes: Oh, I missed it. Well, CFI or SFI? Like, this is the distinction that we need to… Subtle. Yeah, Potos.

Potuz: Trent just said the right thing. It seems that we're taking input from individuals instead of, like, teams, and to be frank, when Matt raised this point, I… my understanding from the call also was that this was kind of contentious. That there wasn't a decision. And even it's kind of strange to make such a decision within this group, that the whole Yale teams are not, and particularly the teams that are, like, that were pushing for other headliners are not here. Even though it's definitely my personal preference to make sure that Fossil is, it's… Sounds weird, it wasn't my reading of the call?

Alex Stokes: Okay. Yeah, I thought we all had agreement on this earlier, but… Especially if you want EL input, this is something we could take to next week's call. I think this does kind of… yeah, we walk back a little bit in terms of scoping progress. But… Yeah. I mean, yeah, not… like Plan suggests here, if everyone's okay with CFI, just make it CFI, but then there's some pushback against that, so… Although I think, to be clear, the clients seem to all be okay with CFI. modular the points raised around, yeah, individuals versus clients, and then also the EL side of things. Did you have a hand on, sorry?

Okay, I guess not.

Ansgar Dietrichs: I mean, yeah, I just wanted to propose, but it doesn't matter so much, but, like, we could next week on ACDE get a signal, and then maybe make the SFI decision in two weeks, because I feel like, in a way, it's more appropriate to make the final decision on the ACDC side. But that way, basically, everyone, also maybe anyone from the ACD, from the CL side that's not on the call today, has two more weeks. We can think it over the implications of, kind of, an early SFI decision. Get the Yale takes, and then make a decision in two weeks, I personally think that would be most appropriate, but yeah.

Alex Stokes: Okay, that works for me then. So… Okay, then Fossil, I think we're on the same page now, that, yeah, we need a little further consideration. We'll take this to next week's ACD and see what the sentiment is there. And then we'll revisit this two weeks from today, and make a final call there, along with the other EIPs that I called out. Okay. Let's see, we have, like, one minute. There are a few more things… to call out, I think, there was an ask for, everyone to start thinking about a name for I-Star. And… otherwise, I think we've covered everything. Okay, yeah, then I think we're good, and… great, okay. Thanks, everyone. Again, I did… I do think we made a lot of good progress here.

And I'll leave a summary of these decisions on Discord, and we will continue the conversation on next week's call. So, thank you everyone, and I'll see you next time.

Potuz: Goodbye.

Mikhail Kalinin: Bye. Thank you.

Ansgar Dietrichs: I'm wrong.

Fredrik Svantes: Thanks.

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