All Core Devs - Consensus #171

Transcript

Alex Stokes: Hello! Stan care? Let's give it, like, another minute, and we'll get started.

Okay, Josh, if you're helping with the stream, I think we're good to go.

Josh Davis: Alright, Alex, you're good.

Alex Stokes: Thank you. Okay. Hey, everyone. Welcome to ACDC, this is call number 171. It is issue 1825 in the PM repo. There's the agenda in the chat. And, yeah, I think it'll be… Well, there's a lot on the agenda here, so yeah, let's go ahead and get into it. So… First up, Fusaka. So, as we all know, we had Mainnet just recently. And… went pretty well. There's at least one issue with PRISM. I think they're working on a post-mortem for that. Yeah, and then this week we had BP01, which, again, seemed to have gone pretty well. Would anyone like to add anything for either of those two events? I know for the post-mortem, I think prison might still be working on it.

Barnabas Busa: Yeah, so, BP01 looked very good. That was happening earlier this week. We did a quick, blob spamming test as well, just yesterday. We were able to do 15, blob transactions in 28 consecutive slots, and the network, didn't seem to mind it at all, so that's good.

Alex Stokes: Okay, great.

James He: For Prism, I guess we've recently released, two new releases. One release that's just a hotfix, so that you don't need the flag anymore, and then, we had another release with, Semi-super node, feature and a backfill feature. There's still a couple other things we're still investigating, but, Just wanted to call that out.

Alex Stokes: Yeah, great. And that was, like, 701 for the patch, and then… Was there a 710?

James He: Yeah.

Alex Stokes: Okay. Thanks. Potus?

Potuz: Yeah, we've noticed something that, perhaps is affecting other clients as well. We, we had some users reporting, like, a bad degradation on attestation performance, and it boiled down to disk. We… we aren't, calling… attesting on a block until we saved all of the column sidecars. And it turns out that some nodes that had moved, database to slower disks are now… were performing perfectly fine before Fulu are now performing badly because of this. So, it might be a general thing, we are looking into how to optimize this, but, but yeah, so we're urging our users to move to NV, to faster disks, just because of this.

Alex Stokes: And you think it's because of the blobs, or something else?

Potuz: Well, I think it's just this thing of, like, attesting while we are storing. Just replying to Raul, it's… it's a dangerous, it's a trade-off. If you… if you fail storing, then you need to go back and do something about it, because otherwise you'll be on an async situation where your database is telling you that that block was available, but then you don't really have the columns that you need to adjust for. So I think it's… yeah, it's these kind of situations where you don't want to be a sink.

Raúl Kripalani: Yeah, remind me, did we have in a… do we signal the head slot, the latest slot that we have custody for, in the metadata message, or the status message? Because if we do, then you could just not update that until it's written to disk. So you wouldn't be expressing that you have custody yet.

Potuz: Well, the problem is, what happens if you get the child? And then, you'd be syncing a block. For which you've said that the parent was available, and now you don't have the columns to even serve them.

Raúl Kripalani: Mmm. Okay, I suggest we take this offline. There's a thread, I think, already in Discord, so we can continue there, and we can dig deeper. I do think there's some trade-off that we can, like, optimal trade-off that we can hit here.

Potuz: Yeah, we are… we are going to optimize this anyways, but just to flag this, that this.

Raúl Kripalani: Hmm.

Potuz: This is affecting users that don't have fast disks, and it wasn't before.

Alex Stokes: Okay, yeah, thanks for raising that, Enrico.

Enrico Del Fante: Yeah, just, comment on that. So, I think, like, we… when we are… when you are test… you're testing that you have seen things, so the sampling was okay, so I think it's theoretically Okay to attest while you are storing, and then it's just a problem of guaranteeing… guarantee that you can serve that? So if you are… also serving via RPC, things that are in flight is okay, and then the problem is just having The database consistent when you start up the node, and making sure that you are filling, eventually, gaps that you are creating while stopping the node, and you haven't finished writing stuff on disk. that's a thing that we are dealing with.

Potuz: But even attesting is an issue, right? Because you have a separation of the validator client and the beacon node. So, by attesting, the validator client calls the beacon node, it says, what's your head? So to attest to that thing, the beacon node itself must have updated the block and said, this is my head. But then to do that, the beacon node itself must have declared the block available. And I think, being async here, saving your head, declaring locally on your Bitcoin node this block is available, but not having the column is… raises a dangerous… raises a danger.

Enrico Del Fante: I'm not fully agree, but I think we can… can discuss.

Alex Stokes: Yeah, I think his point is that you do have the columns, they just went up, they persisted, right?

Enrico Del Fante: I mean, it's attesting the availability, so if you've seen, it means that the data was available.

Potuz: Yeah, but the beacon node doesn't know it's seen something. It… so we… at least we consider things seen, like a block. Have I seen this block? Yes. If I have it in DB, I have seen it. I don't… I don't act on anything that I have not stored. Otherwise, I might end up in a situation in which my DB and my view of the chain is inconsistent, and this leads to bad bugs.

Enrico Del Fante: But again, custody, to me, is different by sampling. So… That's the… that's the main point why I'm saying that it's okay.

Raúl Kripalani: Yeah, I think… I think that perhaps the difficulty here is that the status message, does not separate between the custody head and the chain head. So, there's just a head slot. So then, when you are externalizing that you have a particular slot that you consider head, any client would be entitled to ask you for the custody columns for that head. Which, in this case, you might not be able to serve if you haven't stored them in disk, and the client is not able to pick that… serve them from the buffer. Which I think might be the solution here. Just, like, save them in the buffer. But anyway, we can take it offline, because I think we're getting into implementation details now, but…

Yeah, I just wanted to say.

Dustin Brody: I… I, I, I, I will say one, I agree, fine, take it off, find these are not implementation details. And I think that there's a lot of temptation to take these shortcuts that are not I mean, I… how do I say this? Without opening, you know, cans of worms here, but… which are dubiously valid, let's say. Debatably valid. It is not that easy.

Alex Stokes: Yeah, I mean, I think we might disagree on what's a shortcut and what's not. But yeah, Rol, you mentioned there was a thread somewhere in Discord, so… Yeah, let's just move this somewhere else. Okay. Anything else on Fusaka? Otherwise, there's one more thing on the agenda. But otherwise, yeah, then, you know, it may not be PO1. Looks like they went well. This issue that we had just now… Anything else?

Enrico Del Fante: Just…

Alex Stokes: Okay.

Enrico Del Fante: One thing, yeah, we have, we have… Several, things that we will improve. You know, coming release. Some bugs here and there, so some… some of the clients using Tegu is… is not… is… Giving us some feedback, and we are improving. several things, so hopefully we will have something. by… this week on, Nishan, starting next week.

Alex Stokes: Okay, great. And this is around, like, new things in Fishaka with.

Enrico Del Fante: Yeah, yeah, definitely. Stuff related to Fusaka, custody, and sinking, and so on.

Alex Stokes: Okay. Great. Thank you for the update. Okay, then, the last thing here on the agenda for Fusaka is a bit of a bridge item, which is a retrospective process. Let me grab the link really quickly. Should be this one. So… Yeah, we did this starting with Pectra, and, you know, the context there was Pectra was, like, a pretty rocky fork. So… You know, we had the idea to do, essentially, a retrospective on, yeah, kind of the fork and the upgrade process generally. Now that Fusaka is generally out the door, it makes sense to go ahead and do this again. So, Nixon made this Ethan Magicians post here. And the idea is for the next few weeks, just to have this open. Yeah, if anyone would like to provide feedback, this is a great place to do so. And yeah, this helps just refine how we do everything.

Yeah. So, take a look. And, essentially, the idea would be, this phase of the process would go until, we start ACD in the next… in the new year. Which is, yeah, something like 3 weeks from now, so… Take a look, you know, reflect, and… And add your feedback there, when you have a minute. Okay. Anything else on Fusaka? Otherwise, we'll move forward into the future. Okay. So let's go… And we had a few things here. So, one, there was this conversation about justice payments in EPVS, We should talk about that. Otherwise, the intent was to finish scoping for Amsterdam. We had a few open questions on some of the EIPs, that we'll get to. In this section, so… To kick us off with trustless payments.

Let me just kind of replay, you know, at least my understanding of the frame here, so… You know, we had this part of the EIP, And it was selected in full as a headliner, you know. A long time ago at this point. We've had this conversation a couple times in ACDC of justice payments, and, you know, how the feature works, and, you know, should it be taken out, should it be split, different options here, should we leave it as is? A few weeks ago, there was definitely some… you know, input from the community here, in particular some of the existing builders and relays, and different people in the MEV ecosystem, who, you know, this would definitely impact.

They had some concerns around the design here. So, they brought this to, I think it was 2 or 3 ACDCs ago, In the meantime, we had a breakout. Where, you know, I think we continued the conversation, and… yeah. The point of all this, or at least, yeah, again, given the narrative, how we got to today, we should make a call on what to do with this. So… yeah. I'm happy to open the floor for comments. I can sort of play back my summary of where I think things are at. Unless someone would like to add… their takes. Okay. So, from what I've seen… You know, what we had said, again, a few different calls ago, we basically would, you know, have trustless payments as is.

Unless there was some security issue. And… yeah, again, I think this is… Yeah, there are many different opinions here on what we should do. From what I've seen… There have not been any arguments to the point that trustless payments are, like, actually negative or bad for the protocol? There are some arguments that might suggest they're not being used, or, like, wouldn't be used, but then we have to take into account the fact of what we gain. And what we gain is essentially this fallback for… you know, what might be retail scenarios, but again, keeping in mind Ethereum's values and, like, what we're trying to do here in aggregate. We can definitely make the argument that this is important, and that we should do it now.

So… I think that's essentially where we're at. We keep it as is. in terms of what might start to be a compromise, you know, I think there's been some work around finding ways to… allow the status quo of the MEV ecosystem to exist in this world. So at least that's something I would want to ask today, and or something I would, you know, want to keep working with the authors of EIP on. is finding a way to make sure this is supported with, like, minimal disruption. Again, you know, I think in particular, having, relays be staked is… is an ask. I don't think it's a huge ask, and I think that's kind of the main difference. Otherwise.

You know, today's players can kind of live in the status quo. So… That's where I'm at. Again, I don't know if there are any other comments or perspectives we should raise.

alex (ultra sound): Maybe, like, just very shortly, wanted to speak some appreciation for everybody in… for engaging in the discussion. Maybe one very small meta point? just… that I've noticed, because I've spoken to a lot of people now about this, and I've noticed that on, regardless of what people's positions or opinions were, they… We're sometimes pretty worn out by the discussion. I think sometimes when you work on a really hard problem, that makes a lot of sense, right? Stuff is just hard, rest, support each other, and continue. But I feel like when it's… the resistance is more, like, people against each other, than maybe in general for the EIP process or future changes. I could imagine, this is very much my personal opinion, that slowing down might be very healthy to, right, work through some of these things, but again, I'll immediately say that I feel like a lot of people have really done their best to try and do precisely, that.

So, thank you.

Alex Stokes: Yeah, thank you. Yeah, you definitely have been helping coordinate, you know, this investigation that we've just had, which, again, I'm… I mean that in, like, a very positive light. We are going to get to the best divine by having the most people look at this and poke, you know, from every possible angle and corner, so… Yeah, thank you for that. And… okay, so… Again, I think then where we're at, we keep the EAP as is. there's, I think, some questions around, you know, from here, details around how these different components should fit together, and again, I think we should… Make sure that there's a way, again, that, you know, the current ecosystem will not be completely disrupted.

My understanding is that this is already the case. But yeah, let's just make sure that we can kind of… Keep that in mind as we move forward with the design. So… Any final comments on this? I would say for the record, like, yeah, this is, I think, at least the second time we've kind of formally considered this. And again, the takeaway is we're keeping them in. I do feel at this point, we've done the work to hear as many people out as we can. And… yeah, again, the only, you know, consideration, or the only point at which we'd want to revisit this is if there were, like, very, very clear security issues, which, again, no one seems to be able to find, so…

Any closing comments on that? Before we go to the next topic. Okay. I don't know, there's some comments in the chat, but I think people should speak up if they want. Yeah, Oscar.

Ansgar Dietrichs: Yeah, not at all to disagree with that decision. I think that's actually my decision, but, just maybe as a general comment, I do think for many reasons, some of them definitely, I think, also triggered by some kind of behavior from the EF research side, but I do think, looking back at the history of the EFP and the governance process around it and whatnot, I feel like it relatively early on turned unnecessarily adversarial, and I think it turned very much into a my proposal, your proposal kind of situation. I think there were several kind of, like, smaller adjustment ideas that then ended up never being really considered, given that it was like, oh, this is yet another attempt to basically subvert

like, one side winning or something, I don't know. Maybe this is purely my perspective, this could be, and then… my apologies for bringing this up. I just do feel like, once we have a retrospective, maybe for the EPBS inclusion process, I do think we could have done more as a group. Again, not even, I think, in chat, I actually worded it a bit as inclusive as the champions, that was probably immature, I think more as a group as a whole, including from our side. I think we could have done more to keep it focused on the technical questions, and I think there could have been more collaboration on, yes, let's move forward with EPBS, but also early on into the process, let's take some more time actually

working on potential iterations. So I do think there was something that didn't went well. I understand why the community now reacted the way They did, but by now, I think we have a good headliner, maybe not perfect, but yeah.

Alex Stokes: Thank you. There's a good question here. from Francesco, I think we should address. So, yeah, again, I think, in part, to try to find, like, a nice middle ground between, again, kind of the status quo and what this EIP would introduce. There are some proposals to modify parts of trustless payments, and I do think we should sort out, yeah, how we're going to resolve those. You know, I think my sort of straw man would be what Justin's saying here in the chat, like, something like mid of January, we should say, like, pencils up on spec changes. Potu's here. You said these are big changes. I don't know if you want to speak more to that.

Potuz: Oh, they aren't so big in principle, but they… so I guess the biggest concern here is that, for historical reasons, perhaps, this goes back to, like, 2 years ago, and discussions with Mike Neuter, actually, and the builders at that time. mentioned that, yes, they would… if they are going to be state, they would rather not be losing capital and then be earning rewards. But it turns out that now, when they are faced with the churn and deposit churn, they, they… said that they are… they seem to be aligned that they would rather forfeit the rewards, not be validators, keep the stake without getting rewards. And, and yes, and just take… take that as the… as the… Payment for bids.

The problem of doing this, like, removing the builders from the validator slides, is that it also removes the ability for validators to submit bids. I'm not sure if this is a trade-off that we're willing to make, because this was the feature that allowed us to remove the self-building property. We were hoping that this set of validators would still be decentralized enough, that we can just remove the self-building requirement. Anyways, there's a bunch of discussion to do about this. I believe that we can actually implement these changes. I think this is an honest request from builders to avoid the churn.

Alex Stokes: Right, and so to be clear, this is taking away the validator duties of the Xerox3 validators?

Potuz: Right, so it would be taking away the validator duties, and in this way, we can allow them to deposit faster. They still would need to go over a long term to withdraw, otherwise this is a DOS. But it will allow them to deposit and get included quickly, because it wouldn't even affect a week's substitutivity period or anything. So it's easier… it makes the protocol easier to reason about. There's many reasons why you would want to have something like this. You could also, in principle, include builders that are only staked for one ETH, or minimally. And then they would be able to bid for this match. But, yeah, so, I think for me, the biggest loss of such a system would be the fact that we lose this very nice feature, which is validators are able to submit bids.

Alex Stokes: Okay. So, I think in terms of moving forward, you know, I think getting clarity here. Base up, is what we should do. Yeah, I assume there are still EPBS breakouts. Like, I think this is something we should be covering on the breakouts until we get to some resolution. Yeah. Like, I think it's a little premature to be like, okay, you know, by January 15th, like, pencil's up. But if anything, that's, like, a target I think we should keep in mind, and sort this out as soon as possible. You know, one way to de-risk this moving forward is just… Yeah, I mean, again, we have history here, but if we can get to a place where we do the more permissive thing first.

To add, you know, essentially more restrictive things later, we should do that. Oh, let me rephrase that one. What I mean is, like, you know, if we can do something such that it's, like, more future… like, more forward compatible later, we should do that. In the event that, say, we want to ship and, like, do these iterations down the line. Okay. Yeah, Francesco's saying here in chat that he's worried we might not be able to sort this out. Yeah. I think it's worth at least, yeah, taking another breakout call to really investigate this in earnest. It sounds like we have an idea. Like, is it really just this one idea? Of having non-validating stick builders.

Okay, I mean, that sounds like it… what… it sounds like the situation to me, so… Let's keep moving forward on that. This should be the topic of the next breakout, and yeah, let's try to assess there how this looks like in terms of, yeah, any additional changes, and what that means for… what that might mean for… I'm meaning things. Okay. Any other comments on trustless payments for the moment? Okay. So… That's that. And… okay, next up, would be doing the non-headliner EIP scoping. So… okay. We have a number of VIPs to touch on to round out the Glamster Dam scope. One of them is the question of fossil that we had. There were questions then around 7688.

8061 and 8080. And I think those were the last ones on the CL side that we needed to get through. So… Let's go ahead and touch on Fossil. So… yeah, again, this is also, you know, I think there's been some history here with this EIP. What we had said, you know, the process for this. was that, you know, there were concerns around Scoping and Glamsterdam, And… And because of that, you know, we wanted to think about putting it into a feature fork, say HECA, As part of that, you know, it'd be nice to have some credible way to commit to HECA, or commit to Fossil and HECA. And I feel like we tried this on the last call.

I think there was already confusion. around, you know, should we do CFI, should we do SFI, and how that should work? So, that all being said, you know, as of the last ACDC, the points were made, you know, hey, we essentially shouldn't get just, like, you know, different client team members' opinions just in time. we should also reach out to the execution layer. So yeah, so we took this to ACDE last week. And I think, again, people are generally supportive of including this in some fashion. And I think that essentially brings us to today. So, you know, I think following that arc, you know, I'm willing to have a conversation if people want to try to think about scheduling

Fossil in some form or fashion, ECA. But… I will also say at the same time, having thought about this some more, I think… What will happen is it will be tricky to say, hey, you know, we should ignore the process. Process being just opening up the headliners, for HECA and moving forward that way. So, you know, if people want to… Essentially, yeah, raise points for one way or the other, you know, we should do that now. I do think right now my recommendation is just to say, hey, you know, we tried this, it's going to be hard to get consensus, I think especially given the fact that If we do want to deviate from the process, it should be, I think, fairly uniform that this is what we want to do.

I think already some people have called out that we should not ignore the process that we have laid out with headliner selection, etc. So that would mean going to the headliner process for HECA, with this question of fossil. one quick side note, and then I'll stop talking. Given that we just finished up Fusaka, this is… essentially, now is the time to think about headliners. for ECA, which I'm gonna touch on this after we finish this EIP scoping for Amsterdam. But, yeah. Point being, we would start the headliner selection process for HECA, essentially, you know, start of next year, so in just a few weeks. Okay. Yeah. So I spoke.

soispoke: Yeah, thanks, that was, yeah, I think that was a good recap. I mean, my opinion is that we should… It would be quite healthy to stop, like, moving the goalpost, and… And we keep asking clients what they think, and they keep basically saying that they are in favor of included, but then we keep moving anyways. And I also just want to add that We are, again, like, in a situation in which most of the pushback on Forsole is about process. It was already the case for Glamsterdam, and now we are basically repeating the exact same pattern for H-star. I actually think it maybe echoes… well, I don't want to take his word, but, like, what Anzaga was saying was, like, decisions being made on technical merits of an EAP of a feature, rather than just, like.

Focusing on, on the process, and… Yeah, I feel like, at some point, like, if, you know, if people have, like, strong technical reasons to be concerned, but also, or they actually don't support it, like, they should voice it, but it's not been the case for a while, and I do think there is, like, a sort of limit To allowing… allow… allowing, sort of, like, veto power if the pushback from, people that don't want to see fossil in is just about process. Yeah, the last point is, you know, I think I said that on ACD a bit, but… continuously having, client teams sort of, like, have to come up with opinions, about an IP. That means they need to have the actual discussions, they need to come together, come back with an opinion over and over again, and I think, like, it's quite wasteful in terms of time if we actually don't end up considering these opinions, so I just want…

Maybe people to be mindful of. Yeah, draining this process, longer, which is why I would favor, like, actually coming to a decision, around fossil inclusion, just because it's been very long, and yeah, I will stop talking now.

Alex Stokes: Yeah, thanks. Okay, yeah, Tano, and then maybe I can respond to Tama.

donnoh | L2BEAT: Yeah, so… I've been asked to express my opinion on the topic, so I spent a lot of time, like, talking with L2s, because, you know, that's what I do at AltoBeat. And Osil came out, a few times as a way to reduce the challenge period, which is something that, a lot of protocols want. But, you know, even apart from this. The two things I want to say is… One of the reasons I think the conversation around fossil has been frustrating a little bit, both people, you know, pro-folsale or against fossil is because I don't think we're, we're… Like, discussing it, the proper way. And I think the proper way to discuss fossil is to think about timely inclusion, right? So, first of all, we need to agree that timely inclusion is valuable.

And what I want to convince you is that it is. Like, there is a huge class of protocols that requires time and inclusion for safety. One obvious example is, you know, optimistic roll-ups with a challenge period. Another example is the intent protocols, that also have a challenge period for settlement. Another example is, stuff like polymarkets. They use a 2-hour strange period to settle disputes. Or in general, you know, upgrade delays, exit windows, you want to exit, withdraw from protocol, you need time inclusion for safety, right? But it's not just about row censorship resistance, it's also about safety of funds. And the proper way to model inclusion is through economic attacks. I've seen very, very few attempts to discuss fossil in the lens of

What is the advantage that it gives? to a user, if there are, an economic attack, right? So I pay a tip to close the transaction, someone else pays another tip to, right, to push out my transactions. There is only one paper, by Offshore Labs trying to discuss these benefits of fossil. The outcome of this paper and the result is, it seems like it gives you, one other magnitude improvement, in the sense of, if you have an attacker that has $100 billion and wants to censor you, in… without fossil, you need 10 times more money to try to include these transactions with fossil. I don't think the model is perfect, I think the model, needs to be improved.

It doesn't correctly matter faucet, in my opinion, but I think this should be how the conversation would need to go forward, and that's also why I think it's valuable to have a little bit more time to discuss. the benefits of postal.

Alex Stokes: Okay, thanks. Yeah, again, just sharing my perspective, given that I talked to many of the people on this call. I don't think anyone's really debating, at least to first order, like, the technical merits of fossil. I think it, you know. In terms of how… We got to today, it's really just a question of, like, when to scope it and, you know, what process gets us there. And yeah, so again, you know, it was considered for Amsterdam. I think there are legitimate concerns around scope and complexity to not do that. Then the question was, you know, can we put it into the next work, especially given… And I think what's pretty uniform support for it. And then, circling back to… so I spoke, yeah, like, I agree the process has not been ideal, you know, it's been pretty rocky, and, you know, I think my answer to that today is just to say, hey.

Let's take a step back, lean back on the process, because that's something we can all agree to. That's just, like, sort of a, you know. Established precedent that we have. And… then that would be my suggestion, is say okay. Given especially that we're starting HECA headlining just in a few weeks, this is the time to do that. Carl.

Carl Beekhuizen: Yeah, I think my thing here is that it's like… Fossil does bring many amazing benefits that I think most people here would like to see. The reason I think it's important that we still go through the process is just that we need to consider Shipping fossil means we don't ship other things, we need to consider what are those other things, and whether we want to make those trade-offs in H-star, and I don't think those discussions have been had. So, for that reason, I think it's very important we go through the headliner process. I think it's very likely that we end up back at Fossil, and… Great then, but I think it's important to do that.

Alex Stokes: Yeah, and, you know, maybe to add to that, not just for us, but also to give the community an opportunity to weigh in. And… Yeah. There's some side chat, I don't know if anyone would like to speak up. To add an input to the conversation.

Nixo: I think… I think CFI-ing is, pretty uncontroversial at this stage, as, like, a… as a positive signal, SFI is… is controversial, and I think that for that reason, we should go for CFI, because if we make it SFI, there's not really any meaning in the difference between CFI and SFI. I… SFI's something as a head… as the first thing that goes in Essentially denotes it as the headliner. And so I understand the desire to move it to SFI as soon as possible to make it the frontrunner, but it… it really should go through the process, and this, sFI-ing it to begin with makes this meaningless.

Alex Stokes: Oscar.

Ansgar Dietrichs: Yeah, while I tend to agree with Nixu, I personally also preferred to just have it, steep aside, just given that I think Tomar had a point that we keep always asking, like, on all codefs, there's always the conversation, okay, what does… what do the codevs think? And then the codevs seem to have preferred, in the past, SFI, so I just wanted to say, if we go ahead with SFI, I personally would prefer the The version of that where we just say, it is SFI already. But we just go through the normal headliner process as usual, and in that headliner process, we will just consider, okay, we already have SMI for us, so does that mean we want to have it as the headliner? We could still decide to not have it as the headliner. I mean, as of one call ago, we were still

considering including it into Amsterdam as a non-headliner, so there's definitely precedent for it to potentially be a non-headliner. So we could just decide that as part of the headliner process. I don't think it would be too much of a bending of the process, and I would… if there's strong demand to do SFI already today. I personally would prefer that over locking it in as a headliner, because that really, in a way, I think, is… is a bit of a violation of the headliner process.

Alex Stokes: Yeah, I mean, I think the catch there is, like, this should be considered a headliner. Like, you know, fossil is big, putting it into the program. protocol will produce headlines, which is, like, you know, the intuition behind the name Headliner. I think it was… so I spoke, and then Carl.

soispoke: Yeah, just wanted to say, I… I… I think the SFI is more important than the headliner for Fossil, because, again, I think… if we followed through the whole history, was about, like, trying to get a credible commitment for… for Fossil, whether it's a headliner or not. And… yeah, I mean, my worry right now is that you know, as a headliner, I already said that, but, like, forceful is very ill-suited, just because it is cross-layer, and it is quite a big EIP, but, like, it's not huge, and it's very ready, so it sits in between this sort of, like, EL and CL, and, like, huge Feature versus very small, which makes it, yeah, a bit… a bit weird, to fit in the headliner process, so I… I mean, I would be completely fine, SFI-ing it as a non-headliner, rather than CFI-ing it as a headliner, which I think is, yeah, more weird for the process.

Alex Stokes: Yeah. I don't know, to me, like, Headliner is different than CFI or SFI, like… headliner is an intrinsic thing around the importance and impact of an EIP. And then, yeah, like, the CFI-SFI thing is kind of separate to that, where it's like, okay, we would have a headliner, and posted to that is that it's something that would be scheduled. And then we move forward to the usual process where, okay, you know, we CFI something to say, again, it's being considered for inclusion. As soon as we are ready to put it onto DevNets and the R&D process, it becomes SFI. And, you know, I think sort of the only shortcut there with the headliners is that they sort of de facto and or immediately go from

Let's see if I'd ask if I stop. Carl.

Carl Beekhuizen: Maybe this is just a misconception on my part, but… My understanding of Headliner is also a lot to do with the size of this, and I do feel like the fossil's pretty big. I feel like it's wrong to be deciding. on whether you're SFI- this or not, based, like, without it… being… A headliner, because from my perspective, this is a rather large change. Maybe it's not as large as some of the other things we've had as headliners, but… So, pretty impactful. I think that's one thing. The second thing is, like, if… we are going… like, wanting to go down this route. In the past, we've first decided the headliners, and later on, decided what else goes in the fork, based on how much capacity we have left after deciding the headliners.

They're the most important things, so I think specifying this before we do that, and then… Finally, I think the… credible commitment thing here is, like, something that's been run with a little bit too hard, and I think… There's a little bit of… we tried to abuse the process to try and make… this feature not go… not happen in Glamsterdam due to complexity, when I think that was a backwards way of doing this. I think this was… would have been too complicated to put in Glamsterdam, especially if you want to keep shipping things on shorter timelines. And so we should have just put the bulletin and been like, this can't be in Amsterdam based on that, we don't…

need to. make these credible commitments, and I think, like. That was… I don't know if that was the initial intention, of these… things around credible commitments, but I feel like this spiraled very quickly out of control, and then people, like, feel let down because… They feel like we need to give them these things, around… Or on fossil. I just think there's, like, that the path of how we got here has been a little bit unfortunate, and has, like, resulted in a lot of this fatigue, and keep having to ask the dads what they want or whatever, and I think, as we mentioned, it's clear the devs do want something like Fossil, but It still needs to be considered within the greater picture, and…

Alex Stokes: Gonna talk?

Vitalik Buterin: Yeah, I mean, I, yeah, like, I remember being in the call a couple of weeks ago, right? And, It certainly felt to me like, we were… we justified Fossil not being in Glamsterdam under the, arguments that, like, basically everyone wants it, and, it's, like, of course it's going to happen in H-star, and, the people saying that it'll just keep on getting pushed back more and more are being, like, unrealistic. and, like, from… that perspective, like, we definitely do have a history of pushing things back more and more, and, I, I think in this situation, there's a lot of, a lot of value in, like, actually, yeah. showing that we are able to, like, hold ticket… to commitments if we decide… if we decide to do them. And, I think, I mean, more…

more generally, right? Like, the process needs, some kind of defense against, like, things, continually getting put… getting pushed back more and more until they, until they eventually don't happen, and just, like, basically the, yeah, like, actually, yeah, actually getting it out there and giving people confidence, that it will get out… that it will get out there seems like something that, a lot of people have been counting on. Like, I don't think we can… Isolated from all of the, all of the other discussions.

Alex Stokes: Right, yeah. I think my take here is that it's definitely a headliner. Like, I think, you know, possibly is big, and it does have a lot of impact. We should be… proud of that, and, like, give it the recognition it deserves, that it is a headliner. If it is a headliner, you know, we have this fairly new process around that, which would make it a bit tricky to… move ahead with some, you know, definitely SFI today. Again, because we are going to start the headliner process for HECA in, you know, just a few weeks' time. So, I think given that we don't want to… not respect this new process that we are trying to install to make ACD more smooth around scoping and EIP selection.

We should just respect that and move forward with this again in a few weeks' time. I think it was June, then Carl, then my client.

Jihoon Song: I wanted to talk about Also, but if the decisions already made.

Alex Stokes: Oh, sorry? No, yeah, you can, yeah, you can, you can share.

Jihoon Song: Yeah, so, I just wanted to say… share that, From my understanding, the main reason behind pulling fossil from Klamsterdam was fork scope, which affects some fork cadence. And I do agree that we will also want to respect the process, but in terms of better pipelining perspective. Sfi… I think SFI and Fossil will help us a lot to achieve faster fork cadence, as we can have developers' attention, either it be core devs or APM Fellows, so… Regarding fossil readiness, we had 4 CLs and 1 EL interrupt a while ago. Nethermind was close to make the intro, but has been busy with other stuff, and then EPA Fellows came up in a bottom-up fashion, and they've built RES and Aragon EL prototypes.

So, as soon as we can have core devs attention by SFI, for example, I expect we can have 8 clients interop very soon, which is more than enough for kicking off the first DevNet. And yes, this is based on Fusaka, but we already know how to rebaste fossil onto Goloas. And core devs have estimated development time for the rebase will be roughly a month, once we have working EPS implementation.

Alex Stokes: Yeah. if anything, I think my takeaway from that is that, yeah, there's a lot of work that's gone into this, and so it should be a very straightforward, or let me say, it's a very strong case to be made for it as a headliner. Okay. You know, if we wanted to find some solution that still signals, like, hey, this is, very important and top of queue for core development generally, I think Nick's suggestion of CFI. Today, makes a lot of sense. But yeah, Carl and Matt, and then, yeah, we should probably move on to other things.

Carl Beekhuizen: Yeah, I want to push back against Vitalik a little bit, saying that we're, like. We have a history of delaying things. And… in order to, like, making sure that that was also not being shipped. I don't think that's the case here. I don't think anyone talking about This process here is, like, trying to delay fossil for the sake of not getting included. I think it's, like… Like, at least that's my perception. I know there's some people who really don't like fossil that much, but I don't think there are that many. I think it's more just about questioning whether it's the right thing to do right now, and I think the same has been true for many of the other things we've delayed. It hasn't been about…

not wanting them at all. It's just been about, hey, we only have limited resources that we can spend on this, and is it the right thing to be doing right now? Is it the most impactful thing?

Vitalik Buterin: Right, well, hold on, there's two separate arguments, right? One, which is that following the process is good, and the other is the idea that this is a lower priority than 6-second slots, and I think the second one is, like, one that, a lot of people are really against. I mean… I… yeah. I don't know, like, I feel really against it, because, they basically, it's, it feels like the sort of thing where, like, we, really would be just continuing to push, back everything related to censorship resistance more and more. And, Like, that, like… and so I think, like, it is, it is important to separate those two arguments now, right? Because, like, I personally talk to a lot of people who are afraid that, Ethereum is, going into a, kind of… basically,

a mode that deprioritizes everything other than acceleration, and it's, like, really important to clearly show that, that's not what we're doing. And, that, like. Basically, the fossil is being eaten, delayed or done in a particular time for good technical reasons.

Carl Beekhuizen: I mean, I agree with what you said, I'm personally one of the people who thinks acceptance slots would be more impactful, but do you still really want to see Fossil on Chain at some point? I think from the people I've spoken to, I've seen a lot of the opposite opinion. I think a lot of people hear Fossil and think it's just a censorship resistance thing, and then don't understand that there's some nuances there, like… Fossil doesn't, include… censorship resistance for blobs, or fossil has this 8KB limit, so it's not really useful for people that use a lot of data, so it's not useful for the stock people. Things like that, I think, are… A little underappreciated and under-discussed.

But yeah, I mean, that's the one… I do hear your points. The second thing I wanted to touch on quickly is just about… What we're talking about here in terms of timelines is, like, we're… the proposal's just to be discussing this again in January, where we're gonna have the headliner process. I don't… there's not like there's this major delay in terms of when we are discussing it, and I don't really see opinions shifting that much between now and then, so I don't think there's, like, this huge risk being taken by Hustle to be following the process? Anyway, I think my opinions are not on this one.

Alex Stokes: Alright, like Client, and then we'll wrap up.

Lightclient (Matt Garnett): Yeah, I just wanted to say, I feel like we're trying to do some process engineering here. Like, it doesn't really feel like the right place to… talk about alternative proposals to fossil, or we're not really talking about technical aspects of fossil, we're just trying to close the fork scoping for Glamsterdam, and then we have this weird aspect of making a commitment for the future, and… It doesn't seem like an open process when we're, like, committing to the next thing, when we've already communicated what the process should be, and so people who might not agree with what the next thing is is supposed to be are not coming onto this call and, like, making alternative proposals. So I think, like Carl said, we're not saying we're never gonna do this, we're just saying, let's follow the process starting

when the process starts as soon as possible, which is gonna be January, that's a month away. If it is the most supported thing for the headliner process, then we're just gonna put it into H-star, regardless. So, I think that CFI is the right thing to do there.

Alex Stokes: Caspar? Most common.

Caspar Schwarz-Schilling: I just wanted to say that. The process, in my mind, as of last ACDC was to ask clients whether to SFI or not on this call. And I think clients can take into consideration whether they think it's too much of a deviation from the process. to SFI now, and decline it on the basis of that, but I think we've asked clients To form an opinion, and you can just ask them.

Lightclient (Matt Garnett): The point of the process, though, is to communicate publicly about how we make decisions and do operations, and if the clients can always just, you know, pick what they want to do immediately, and not You know, have an open communication and process about it, then… You know, what was the point of even saying, this is how we're gonna do things?

soispoke: No, but it's been open and communicated.

Lightclient (Matt Garnett): It's been open for Glamsterdam.

soispoke: Well, 5 months.

Lightclient (Matt Garnett): It's not been… it's been open for Glamsterdam. It's not been open for H-star.

soispoke: I mean, we've literally asked clients again, right? Like, what do you guys think? And they…

Lightclient (Matt Garnett): Again, it's not.

soispoke: Just for clients.

Lightclient (Matt Garnett): It's for the entire community. It's for… it's an open process for everyone involved. It's not just, like, clients who are deep in this thing, who are coming to all the calls to come and say, you know, I want to do this next.

soispoke: What I'm saying is, last time you said, maybe we are afraid it's too… it's just, like, individual decisions, and basically emoji-based inclusion of things, so… and I think the decision was to say, okay, let's actually ask client teams once again, because that's fair, like, we actually need To ask them their opinions maybe one more time, and now we are doing that, and we don't… care, apparently, because we are asking them, but we don't take into account that… those opinions. So why are we asking them if we just move on anyways?

Lightclient (Matt Garnett): I don't know, I wasn't the one who proposed we ask them. I think, and I've said from the beginning, that we should just do the headliner process ASAP and pick Fossil, or whatever, as the headliner. Not these, like, credible commitments that, like, circumvent the process.

soispoke: But then we are, like, in a very tough situation, right? Because, like, either we go back on what we say. And then, like, you can't really trust what we say, because the point of, like, saying things and trying to get to critical commitments and everything is, like, to stick to it. Or, we go against this process that now seems to be overruling every other aspect, including, like, what importance a feature brings to the table, which is just, like. both situations are, like, there. We need to just choose one, basically. And I think that is up to clients. Probably, and people in this call to decide, and I think there is no concern about, like, the community being completely taken aback by the fact that Fossili will be included in the next fall. Like, they've been asked for 5 months

what they thought, they've participated again and again, they keep being very supportive, so I don't think there would be, like…

Lightclient (Matt Garnett): Amsterdam. We didn't start the process for H-star yet.

Alex Stokes: Yeah, I mean, maybe just to jump in here, so, you know, I think the intent was we would try to find a way to commit in HECA. I think it should be clear that We are not able to find a way. it's… it is contentious. I think in light of that, we fall back on the process. So, in terms of moving forward, that is what I would propose. Yeah, essentially, we just do DFI for Glenshire Dam today. We picked this back up with the headliner process in January for HECA. And, again. I think, reading the room, it should be very clear that this is a leading candidate for HECA as a headliner.

soispoke: What do you think about NSCALS? position to SFI without the headliner decision.

Alex Stokes: Yeah, so again, I think we should be honest about it being a headliner, and because of that, it would be sidestepping the headliner process to do this. Which, you know, I think earlier I was more optimistic that this was… You know, something we could do. I think even as soon as we had the idea, it became contentious in and of itself. So, yeah, like, I think, you know, this is the first time we're doing this headliner process, but lesson learned. We shouldn't be trying to… yeah. Be optimistic in the… This way, in terms of, like, pipelining things or trying to move forward before the process has time to play out. And… then yeah, I think that brings us to where we are. I think, again, we just picked this back up in January.

And move forward with Glancer Dam today.

Trent Van Epps: That sounds good to me.

Alex Stokes: Okay. Then, let's do that. And again, you know, apologies for any additional thrash or anything.

Nixo: Wait, sorry, is this decision to not make a decision?

Alex Stokes: the decisions to DFI for Amsterdam, and then we would go back to the process for headliner selection in Perka.

Nixo: go back to the decision to make it a CFI or a SFI today?

Alex Stokes: we can have that discussion. I think we also need to move on. I think your proposal to CFI? is interesting. it does capture the community support, you know, and CoreDev's support today. The proposal was to not do that. Are you saying you would like to push for CFI?

Nixo: I would push for a decision. At this point, I don't even care if it's CFI or F… Specified, let's just make a decision today.

Alex Stokes: Yeah, and so what I'm saying is that we should just follow the process that we have. We reached DF5 for Amsterdam. And then we'll open the headliner process in January. Also, we'll be there.

soispoke: Wait, so it's not even CFI'd?

Alex Stokes: We can CFI.

Nixo: See if I… also, a bunch of people have their hands up.

Alex Stokes: Yeah, I think, like, Clan and Kesper were from previous clicks. Potus?

Potuz: Yeah, so I support what Nex is saying. I think, kind of, CFI in it is uncontroversial. I agree with you that it seems that we cannot make… we couldn't come to consensus into making a credible commitment for next work. But I think there was overwhelming consensus that CFI status was granted. And also, that would be… give the communities at least some signal that we… we agreed to have this discussion, we just couldn't come to consensus on how to signal for the next fork, but we have some form of consensus. It's not that we're completely broken and we cannot agree on anything. And I think CFI was overwhelmingly approved.

Alex Stokes: Yeah, okay. the CFI for HECA. I can make the change to the MIDIP. After this call. Then we'll pick this back up in January. So, to play this all back… DFI in Glamsterdam, CFI in HECA. We'll start the Hellowner selection process in January. Break up. Can we move forward with this? Okay, I'm seeing many thumbs up. Please? Well, I don't know. What I don't want to have happen is this happened a few calls ago, where we made a different decision on fossil, and there were a lot of thumbs up, and then we basically walked that back. So, let me just play it back one more time, so we're on the same page, and I know this is taking a lot of time on the call. It's important.

DFI for… okay, Fossil… DFI for Glamsterdam. Okay. CFI. For Hecca. We'll start the headline process in January. Where again, all of his support should show up, and I think it will be a very strong contender. Or the headliner for ECA. I think we should move on. We're getting agreement. Again, I know this is… been rocky and contentious, and I apologize for that. I think we're in a good path. From here. Okay. Thank you, everyone. Well, let's move on. Okay, we do only have… it looks like 25 minutes left. So, let's try to get through the other EIPs. I believe the only thing we had to touch on were these three, so 7688, which are the stable container EIPs.

And we essentially had a question of what to do with 8080 versus 8061. I suppose we'll just go in order here. So, with 7688, We had said we wanted to take some time to do a little more due diligence on the complexity here. This would reach into SSD libraries, would also check… some consensus types, in Glenser Dam, which, yeah, I think kind of has some pretty big implications. Yeah, I would be very curious to hear from client teams if they have updated thoughts on inclusion of 7688 for Glamsterdam. Okay, yeah, Etan, would you like to say something?

Etan Kissling: I mean, I…

Trent Van Epps: Can't really hear you.

Etan Kissling: Mmm.

Alex Stokes: Yeah, your audio's pretty batty, Tom.

Etan Kissling: Is this better?

Trent Van Epps: No, it's not better.

Alex Stokes: Yeah, maybe I can try to help here. So, there's this PDF… And if I open it up, Okay, so I think this looks like calling out which of the types would change?

Etan Kissling: Fairfield.

Alex Stokes: Yeah, it's still… I don't know, it's, like, very droppy. Yeah, I'm not exactly sure what to make of this either.

Etan Kissling: Goodbye.

Potuz: It's an explanation of why the CIP… I mean, that PDF at least looks like an explanation of why the EIP is useful, in that it prevents those changes in the generalized indices.

Alex Stokes: Alright, so I think we understand the benefits of the feature, though. It's more, like, I think the question is, like, okay. how much, like, what's the actual lift to get this implemented, and all the Z libraries, you know, I think they'll need to be tested, and then the question's also, from there, if they need to be audited. And yeah, let me, let me rephrase that. They will definitely have to be tested, and the question is, like, what does that imply? Do they need to be audited? Do, you know, there'll be fuzzing efforts, etc, etc. So, I think it's… yeah, it might end up being a bit more of an ask. Also, you know, I think getting to a place where we're touching consensus types on top of changing the same consensus types with EPBS and Clemsterdam is a little tricky.

So it's, yeah, a decision I think we should make lately. And… yeah, I mean, I have… my own… opinion, but yeah, I'd love to hear from client teams. Totas?

Potuz: I just want to mention one thing about the CIP, which is… and I feel that this is getting sidetracked every time, but the price that we pay by not including this every fork should count as complexity that we should have saved on the previous forks. By having the CIP before, we should have saved complexity on previous forks, and we are always gauging this EIP against the complexity that it takes to implement for the next fork, forgetting how much we could have saved by having it earlier.

Alex Stokes: Yeah, Barnabas is asking if PRISM's pro-inclusion.

Potuz: I don't think we have a common understanding on the CIP. I don't think we have a common agreement on the team on the CIP.

Alex Stokes: Okay. Yeah, I mean, I think, again, I think we understand the benefits. The concern is just, you know, scope and complexity that ends up Becoming more than we think it is. Yeah, I mean, on that point, I think it'd be good to hear from, say, Pandops, or maybe the testing teams, if they have a, you know. Sense of the lift here. Okay, just going over the chat here, so… There is generally support from the client teams, which is a good signal, Yeah, Solius has a suggestion that basically, you know, we attempt this.

Which, yeah, I… Don't know if this is the best way to do this, Just given other attempts at process things. But essentially, we would, CFI, and then when there's room, you know, once it's clear what's, what's possible, then we could think about, SFI decision.

Saulius Grigaitis: Yeah, just… just a small note. So, I think the current process is a bit, fast, how it works, every 6 months or so. It's… kind of, we shifted to, like, one big feature, plus, one headliner big feature, plus some small… some really small, things. And the problem I see is, in this process is that, it becomes really hard to fit mid-size features, which are not very small, and also not a headliner feature. So I think this 7688 kind of falls into this category. And my suggestion, of course, it's not the best in terms of the process, but as soon as we know the actual situation with the headliner feature, this time it's going to be EPBS, which, you know, it's still… for myself, it's still not clear how long it will take all the clients to implement and test and so on.

I mean, if we see that everything is going well, then why not to include this 7688 in Glamsterdam? But otherwise, if we see that we underestimated the complexity of EPBS, then, well, the only option is to keep the scope smaller. So that's my view.

Alex Stokes: I mean, so the question I'd have then is. how easy would it be to take out? Because I think what will happen is we'll get to a world where there's, like, you know. Partial implementation, like, people start moving down this branch. And, you know, so this definitely happened with the attestation, EIP impactra, where it ended up being more, yeah, more of a lift than we thought. But also, kind of got… The point where it was not worth it to take it out. I do think with the CIP, the changes are pretty self-contained, so… yeah, like, it seems like we could just do this work on a branch, and then… If it gets to that point, we could just… Discord the branch.

Does that align with client team's view of how they could go about doing this? Burnabus?

Barnabas Busa: So I was following in the chat, and in the chat, basically every single, CL team, said that they are in favor of, including this, so I do not see a reason True. further discuss it. Let's just CFI it now, and then let's move on to the next CIP, because we only have, like, 15 minutes left.

Alex Stokes: Yeah. Okay. That seems fair. So yeah, let's CFI7688 for Amsterdam. And… Yeah, I think, just, again, for the record, let's keep in mind these concerns are on complexity, and we should go about developing this in a way that it is possible to take out, if we get to a point where we feel like that's the best choice. But people do seem to say this is, yeah, a pretty self-contained change, and it's worth reaching for now. So, let's do that. Okay. So, we will see if I… 7688. Okay, then we have the next two EIPs here, 8061 and 8080. And… So I think at one point, there was just 8061 here. We pulled out a subset into 8080.

If Francesco's here, I would have a question, because I think, at this point, they're actually just two separate EIPs. And I'd like to confirm that. But then ultimately, yeah, the question is, we need to decide what we'd like to do. The last time we touched on this, 8080, essentially would handle this edge case that we had with withdrawals and consolidated validators. There was, you know, pretty broad support for it. The question then was, do we also want to do 8061? Which, adjust the term limits. And the main thing here is this just provides better staking UX, especially if you're trying to exit the set. And I will say on this point, a number of parties have reached out from the community, so there's a comment here on the agenda from Fidelity.

Essentially saying that, yeah, this is something they're in favor of. I also had… someone from Bitwise reached out, who was also in support of the… so I just wanted to, again, add these quotes to the record, In terms of their support, you know, as community approval for these… At least for AD61. So… From here, yeah, I think we should make the decisions here. I believe I would say… CFI 8080 is pretty… non-controversial. Then the question is, do we want to do 8061? So yeah, maybe to play that back, I would propose we see FY8080. Any disagreements?

Okay. I would also propose that we see FY8061. And the main thing here is that it will shorten the week's subjectivity period, which is the main question. So, I'm curious what client teams think about this. I don't think they are Barnabas. I mean, we talked about this in the last CL call, and… Everyone was in support.

Dustin Brody: I do have a question regarding ADE61, about, the… person from Fidelity, their… their write-up, and talked about a 7-day, target, for the… OE subjectivity period? Where does a 7-day target come from? Like, what… as, as a… Because… because they framed us as… I mean, on one level, I think the correct approach was to say, what is the target? And then… then as the word, target that, as opposed to just sort of saying, we want to speed things up, and the receptivity period ends up where it ends up. So I… that's, I think, the more principled approach, but where does the 7 days come from, is my question.

Alex Stokes: Yeah, I mean, I think it's just adjusting the turn parameters and seeing the result, and, you know, for the turn parameters in the IP, you end up with something like a week. But yeah, Francesco, you had your hand up. I don't know if you want to add anything.

Francesco D'Amato: Yeah, I mean, I had my hand up for something else, but yeah, let me just, I guess, reply to this. Like I said in the shot, the 7 days is just a number, it doesn't come from anything, but just, like, the previous number that was, like, 16 days or, you know, 15 days or something, like, doesn't really come from anywhere. Or, like, originally it didn't come from anywhere. But yeah, I guess what I wanted to say, originally was, like, again, this is just something that comes from the parameters that are currently in the IP. we can just pick whatever we want. Of course, if we just pick the current number, then, you know, the IP is kind of pointless, it doesn't do anything. But, you know, it could be 12 days, it could be 10 days, it's just, like, there's a trade-off. Of course, it's not worth doing the IP if we say, oh, let's just reduce the week-side period.

From 15 days to 14 days, that's not gonna do basically anything, but again, it doesn't need to be 7 days.

Alex Stokes: Yeah, and then, just to be clear here, the, you know, I mentioned Fidelity and Bitwise, like, they were not involved with the CIP. They just wanted to signal support for it. Just so that's clear. Mmm… Okay. Yeah, I'm not hearing anyone say no to this. Actually, okay, no. There was a comment from Lighthouse, Yeah, Kingy, I don't know if you'd like to say more.

kingy_sigp: Just that… just that the adjustments are, you know, it's always non-trivial when we… when we touch the consensus code, and we haven't seen We haven't seen the specific advantages that people would like to, achieve, so… I think that we could… We could go down the CFI path, if that's what everyone else wants to do, just that, it's… It may not be as easy as it looks, and it's something that we… We could easily get wrong.

Alex Stokes: In terms of implementation, because I feel like this is something we have pretty good test support for, in terms of the spec test and things.

kingy_sigp: Sure. I… yeah, sure. Look, if that's the direction everyone wants to go, that's… that's fine.

Alex Stokes: Okay. it seems like Rough Consensus is leaning towards CF58061, but yeah, anyone… I feel like that doesn't represent their views. The proposal here is basically to… yeah, we can, like… further tweak the parameters to get to, like, the period we want. But in terms of making a decision today, we would go ahead and… CFI, unless, yeah, the conversation goes elsewhere. Greg.

Greg K |Lido: Yeah, so I'm a bit, confused. Like, I have the feeling that for all these IPs discussed after Fossil, there was no progress at all since the last ACDC. So basically, we had CFI'd all those APs, and we were waiting for… kind of progress in the understanding of them from, like, all stakeholders, and I get the feeling that for most of them, like, the input we had now is very small, so I was curious, like, when do… should we expect a really final SFI or DFI decision? Because I was assuming that that was today.

Alex Stokes: Yeah, so the thing that we needed today is CFI things, or DFI. If we DFI them, then, you know, we don't think about them for Glensterdam, and we move forward. With the CFI decisions, it's, again. Kind of what it says. It's considered for inclusion. The framing should be, like, yes, the intent is to put this into the fork. From there, just in terms of process and actually, like, making this manageable to deploy, what we prefer to do is… target the SFI set on a given DevNet, let's say, and again, to make this manageable, you kind of go one by one, so what that would look like is, again, we're right now focused on EPBS. For DevNets, once that is good and stable, then we basically can move VIPs from CFI to SFI, so there's just a process there to get to it.

I would also push back some, I think. Yeah, we have made progress. again, yeah, I don't think Etan can really speak, but he did, make this, you know, diagram to call out the changes. I think people have had time to think a bit more about the implications there. So, yeah, we made progress there. And… Otherwise, yeah, now we're just kind of discussing these last two. And we had already, I think, had a pretty good agreement on CFI for one, and then the question was just 8061 now with weak subjectivity. And on that note, what I'm hearing is, yeah, other than perhaps Lighthouse with some concerns, but they're open if everyone else would like to move forward, we would go ahead and see if I…

8061 along with 8080, and then, of course, obviously, the exact parameters can be tuned as we go through the R&D process. So… That would be the proposal. To CFI7688. Cfi 8061 and CFI 8080. And… That's what we do today. Does this sound good from the client teams? Okay. No one seems to have an issue, so let's do that. And… okay, we just have a few minutes left, so… to round things out, let's move to Hecca and Bogota.

And… I think the main thing I wanted to call out today was, just a proposal here in terms of how to move forward. with Scopian there. So, again, this is following, the process that we've established for Glamsterdam post-Petra. And… Yeah, the… the immediate next step is this retrospective period, following the one… One for Picture, we now have one for Fusaka. Which, again, we covered that earlier in the call. Then from here, the proposal would be to essentially copy, the process from Glamsterdam, where, again, you know, we have some time for fork, fork focus and headliner proposals, then move into headliner discussion, finalization. Then we do non-headliners, and, you know, from there, move to mainnet. So…

This Ethanitions post here is proposing a way to move forward there. And, you know, in terms of the next, critical thing here for HECA, it would have this headliner proposal process starting January 8th. I believe this is the first ACD that we'd have in the new year. That would go for about a month. Then we would move to outliner selection over the next month, and move forward from there. So, that's… that proposal. I don't know if people have any… January 5th, okay. then yeah, I might need to adjust the date. But that's basically the intent, is that we start the headliner discussion, just with ACD in the new year. So… yeah. Again, I think this is what we should do. I do think people generally feel like that liner process, you know, is productive in terms of bringing the community more involved and giving them a way to engage more productively.

So, I would propose we follow a similar process, and yeah, in terms of timing, it's pretty straightforward, just about a month per segment. And then we move forward with Hecca and Bogota. Any comments or questions on that? Oh yeah?

Leo: Yes, I wanted to, mention that I want to change, I mentioned this in the Discord, I wanted to mention the that I, I want to change the name of the star. We have been looking at this, and HECA is the first time that this is not really a startup is located in India. International Astronomical Catalogue of Stars. We look for it, and… It's kind of mentioned somewhere in a little corner in a Wikipedia page, but, yeah, and we… if we don't have, proper methodology, we, you know, we are running the risk that Maybe in the future, we're gonna have four names that are fake, or the… means something weird. So I would like to have a second vote for the name of the star.

And following to that, the poor mantle as well.

Alex Stokes: Okay, so you'd want to… at least the question is if we can change the name, effective.

Leo: Yeah, that's correct.

Alex Stokes: Yeah. I don't know, I… kind of personally would say the ship has sailed. I don't know if other people feel like we should change the name.

Leo: And there are some votes on the… on the chat.

Alex Stokes: Okay. Hmm, okay, so… Let's see… I think in terms of moving forward… We should take this discussion back to the naming thread that I think you linked here. Yeah, I think what I would say is if we really want to do this. then we should have an actual suggestion for next ACD, and make the call there. So do you think we can do that? Like, essentially, yeah. Because it's not part of this official list, Sure, we can go ahead and change it if people would like to, but I think also we should go ahead and have a name. Soon. So there should be…

Leo: There should be a proposal for next ACD next week, and then we can change it there. Sounds good, right? But I start a second vote, and I try to mobilize all the core devs to get a vote, and maybe by next week, we already have a vote, and then at that moment, we can decide if we change to the new, you know, most voted.

Alex Stokes: Okay, so yeah, I mean, I guess if you can show support for a new name, and you want to bring it to ACD next week… then, yeah, I think we have a conversation there. Yeah, does that sound good to you?

Leo: Yep, sounds good. Thank you.

Alex Stokes: And then, I think the last thing, because we are pretty much at time, but I was going to touch on the portmanteau. I will say right now, Hikota, Hakota, however you'd like to pronounce it, is a leading candidate. I think we need to pourmanteau also ASAP. So… Yeah. I suppose then, let's see if we can get a proposal to change HECA next week, and if so, I'll also try to have a portmanteau to propose also as something we want to lock in. And we would go ahead and finalize that, at the latest by next week, and then we can move forward. Okay. then I think we're at time. Thank you, everyone. For joining. I know there was a lot to cover today, and yeah, just,

Yeah, thank you. Thank you for participating, and I'll see you on the next call.

Shariq Naiyer: Have a good one, guys.

Potuz: Alright, guys.

Cayman Nava: Bye.

Pooja Ranjan: Goodbye.

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