AllCoreDevs - Consensus #170

|2025-11-27| Agenda: #1812| canonical JSON

Transcript

stokes:Okay, thank you. So, welcome, everyone.

stokes:This is ACDC number 170. It is issue 1812 on the PM repo.

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

stokes:To get ready?

stokes:Then, we'll continue with Glamsterdam, and the big thing there would just be to continue Forkscopin.

stokes:So, let's go ahead and get into things.

stokes:With Fusaka.

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

stokes:And… oh yeah, please.

Barnabas:Yeah, so we started, Ministry of Work 1, yesterday, and we went through full BP01 and BPO2,

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

Barnabas:have been, spamming the network, here and there. Sometimes we shut off the spammers, sometimes we relaunch it in order to get,

Barnabas:some transactions from Minnet.

Barnabas:And we have seen very close to 100% participation throughout the past, 24 hours.

Barnabas:The oil is looking good.

stokes:Okay.

stokes:Great to hear.

stokes:Yeah, Barth has a question if we're using MedBoost, on mainnet Shadow Fork 1.

Barnabas:We are not.

Bharath:Okay.

stokes:Okay.

stokes:Cool.

stokes:So, then in that case…

stokes:Unless there are any other updates there. I did want to touch on this mainnet LAN.

stokes:Okay, I'm not sure which Chris this is, but they had a question about, Nimbus SuperNodes.

stokes:That seems relevant.

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

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

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

Dustin: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…

Dustin:On a do- on a… On release, it fixes a very specific issue that actually,

Dustin:Barnabas and some of the other testing there had found before, and…

Dustin:That's going, going through final phases of…

Dustin:of that. We're… we are truly aiming to get something out as soon as possible on this. We're aware of the timeline.

stokes:Okay, great, yeah, cool, yeah, just keep us updated.

stokes:I imagine we'll need to update the EF blog post as well, so… yeah, I'll keep an eye out.

Dustin: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…

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

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

Dustin:Yep, yep.

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.

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

stokes:So… Some of the client teams have filled this out. Actually, I haven't checked this morning.

stokes:So, okay, there's a few more PRs here.

stokes:And in any case, yeah, please…

stokes:Make a PR, so we just know who is responsible for what.

stokes:And… yeah, I don't think there's much more to discuss here. I've sent messages to each individual client team, so…

stokes:Yeah, just a reminder to…

stokes:Get this ready, and… yeah, then in other… In other news, Fusaka…

stokes:We'll go live, in just a few days, so… Very exciting.

stokes:And…

stokes:Beyond that, I don't think I had anything. Is there anything else, people feel like we should discuss for Fusaka?

stokes:Okay, cool.

stokes:I'm not sure, if there'll be any sort of, like, launch parties or anything, usually.

stokes:someone does a livestream situation. So yeah, I guess we'll keep our eyes out for that.

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

stokes:Alright, yeah, there's this one here, Nixo posted, and then, yeah, sounds like also another mine's planning to have one, so… cool.

stokes:Should be fun. And again, fingers crossed for a smooth fork.

stokes:Okay.

stokes:Then, if we're going to Fusaka, let's turn to Glamsterdam.

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

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

Stefan Starflinger:And I think 3 clients are passing pretty much all the tests now.

Stefan Starflinger:And I think we can start with DevNet soon. I'll be testing it in Kryptosis this week.

stokes:Cool.

stokes:Any updates on the EPBS side?

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

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

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

terence:And then that's probably the biggest blocker, for Defnet Zero.

terence:And this moment, I think after Fusaka's shift, we'll see more, like, progress on that front.

terence:Yeah.

stokes:Er.

stokes:So, Prism and, any other clients?

stokes:Has anyone else made implementation progress?

stokes:Okay, then yeah, so… That's.

Enrico Del Fante (tbenr):I can talk for tech or test stuff, any thoughts here. So, yeah, we've been…

Enrico Del Fante (tbenr):working on APBS in Teco for a while now, and we are merging things in master, which is good.

Enrico Del Fante (tbenr):couple of weeks, we slowed down a little bit, but we are in a good shape. I think there are some…

Enrico Del Fante (tbenr):Database-related and fortunate things to do, but most of the flows are actually kind of there.

Enrico Del Fante (tbenr):So… yeah, we feel good.

stokes:Okay.

stokes:And then, yeah, Phil's just saying here, Lodestar, looking more like January, so…

stokes:Okay, yeah, I mean, I think that's understandable, you know, everyone's focused on Fusaka, and otherwise, yeah, different,

stokes:Amounts of progress with different clients.

stokes:King Yi saying here, steady progress in Lighthouse, so… Okay.

stokes:Thank you, everyone.

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

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

stokes:There are definitely some questions around the implications of this part of 7732.

stokes:And…

stokes: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…

alex:make sure that, my view of it was accurate, and started talking to people about it. I noticed that there was definitely some

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

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

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

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

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

alex:You know where to find me.

stokes:Great, thanks.

stokes:So, yeah, if you want to look into this, again, next Friday during the PBS Breakout.

stokes:And otherwise, yeah, there's, Alex's Telegram handle, so laser job.

stokes:Thank you.

stokes:Okay.

stokes:And…

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

stokes: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…

stokes:Yeah.

stokes:Should be good there.

stokes:Okay.

stokes:Then… next up… I'd like to continue fork scraping.

stokes:And… Yeah, so maybe I'll just play back, kind of where we're at.

stokes:So, we have the headliners, we started scoping for the non-headliners.

stokes:And… last call, which would have been 2 weeks ago.

stokes:We kind of went through a number of them. Client teams left some opinions on different EIPs.

stokes:We were able to DFI one of them, lost call, I believe it was 8068.

stokes:Let me just make sure I have the right number… yeah, 8068.

stokes:So that was deified, but then we still have quite a number on the CL side.

stokes:And we need to go ahead and pick the set that we would like.

stokes:to CFI for Amsterdam. So… I'd like to make progress here today.

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

stokes:Since the last call, Francesco has split something out into, sort of a more streamlined EIP with 8080,

stokes:And in any case, yeah, we'll get to that.

stokes: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…

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

stokes:We said that if we could find a way to commit to it for Hecca, Bogota, so the fork after Amsterdam.

stokes:That feels like a much better decision to make.

stokes:And that's kind of where we left it.

stokes:Yeah.

stokes:I guess before we move forward, I don't know if there's anything anyone would like to add around the fossil question.

stokes:I'm not sure if there is. So, okay, then let's just move ahead, so…

stokes:For this, yeah. So, I talked to some people last week, and…

stokes:again, I think people are generally on board with this. The question is just, like, how do we actually make this credible commitment? So…

stokes:you know, I think two straightforward options.

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

stokes:You know, some people might not want CFI, and so in that case, we could also do SFI.

stokes:Yeah, okay, people here in the chat saying, SFI.

stokes: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…

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

stokes:And, sure, you know, marrying that then, I think SFI for Heck of Bogota.

stokes:Makes a lot of sense. Yeah, so… I'd propose we do that.

stokes:Does anyone have any comments to what I just said?

stokes:Turds.

terence: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?

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.

stokes:And this is kind of the thing we need to sort out, so…

stokes:We don't want to, like, get ahead of ourselves, necessarily.

stokes: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,

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

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

stokes:You know, we touched upon this last call, but say, for example, there is a lot of demand for 6-second slots in Hecca.

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

stokes:So, again, it feels…

stokes:Much less wise to go ahead and sort of put two more headliners into the fork.

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

stokes:So, yeah, maybe…

Dima Gusakov | Lido: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.

Dima Gusakov | Lido:It creates a bit of a problem, again, at least for those running, nodes from home, running validators from home, with this, increased,

Dima Gusakov | Lido:Up low at bandwidth for local block production.

Dima Gusakov | Lido: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

Dima Gusakov | Lido:And should fossil not make it into the next hard fork, this gap will be widened.

Dima Gusakov | Lido: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…

Dima Gusakov | Lido:But the bigger gap.

stokes:Yeah.

stokes:No, that's fair, and I think that's why we're trying to find a way to…

stokes:signal today that it would go into Hecca?

stokes:And that all being said, yeah, there's a number of comments in the chat here around…

stokes:Yeah, different, different aspects to this.

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

stokes:Does this seem okay to people?

stokes:Yo, Barnabas.

Barnabas:Yeah, so I think we might need to rethink our…

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

Barnabas:And, yeah, we… I think we just, like.

Barnabas:just need to change the way we think about the IP scoping, and maybe we can shorten the time for making decisions.

stokes:Yeah.

stokes:I mean, okay, so that…

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

stokes:Then the question is, how do we square this with Glencer Dam? And… Yeah, I think it's… yeah.

stokes:It might be a little… little tricky. So…

stokes:Yeah, thinking about what to move… how to… how to move forward here.

stokes:So, okay, I mean, one thing we could do is just take this as a given.

stokes:I don't know if we're gonna reach consensus on this call today, on Fossil.

stokes:Which means we probably won't finalize the Amsterdam scope.

stokes:But that would be one path forward, is, you know, we could talk about the rest of the EIPs today for your Amsterdam.

stokes:And then from there, we could start thinking about ecoscoping, because, yeah, I agree with you, Barnabas, that…

stokes:we don't necessarily have the tools, at least, okay, we do have the tools, because we could CFI, we could even SFI.

stokes:But… Sounds like that makes some people uncomfortable.

stokes:So… We could start that process.

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

stokes:So… There's some risk there.

stokes:And yeah, just going from the chat, there's…

stokes:Certainly just, yeah, I think we're pretty split on this as a group.

stokes:Like, plant…

lightclient:Yeah, I just propose that we…

lightclient:start moving forward. I think that it's too contentious to go into Glamster Dam. That's…

lightclient:You know, objective at this point.

lightclient:And the best we can do is… CFI.

lightclient: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

lightclient:Decide what is going to go into the fork this far out.

lightclient:And without doing the actual headlining identification process.

stokes:Yeah.

stokes:That does seem like a reasonable path forward to me, just given, yeah, the process we have and how things work.

stokes:But that all being said, I know, you know, given the demand for this, I'm open to finding other creative solutions.

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

Caspar Schwarz-Schilling:And as a compromise, We wanted to explore a credible commitment for Fossil in Hakka.

Caspar Schwarz-Schilling:And if we cannot find that, then I think the discussion needs to go back whether

Caspar Schwarz-Schilling:to whether fossil should go into Glamsterdam or not.

lightclient:I mean, we can have the conversation of fossil going into Glamsterdam, but…

lightclient:it's not gonna go into Amsterdam.

lightclient:It's already clear there's too much contention for it to go in.

lightclient:So, there's not really anything else to do, as far as I can tell.

stokes:Yeah, so I spoke.

soispoke:Yeah, I mean, I agree. I, I think… Cfi, basically.

soispoke:You know, the process changed quite a bit.

soispoke:So it's, it's also, like, hard to follow.

soispoke: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

soispoke:Basically, more of a, like, on hold…

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

soispoke:If not for Glamstadam.

soispoke:yeah, for me, it's just, like, CFI for, for, for Hecker.

soispoke:It's not equal to a credible commitment.

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

soispoke:I think if that's the only reason.

soispoke:And we ship folks on a, like, faster cadence anyways, why wouldn't we able to credibly commit

soispoke:And improve pipelining to… to…

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

stokes:Bansgar.

stokes: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…

Ansgar Dietrichs:don't think what we want, really, here is to somehow make the process force us to include this in H-star, because

Ansgar Dietrichs:If there ever, like…

Ansgar Dietrichs: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.

Ansgar Dietrichs:For us to…

Ansgar Dietrichs: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

Ansgar Dietrichs:comfort or confidence that people here were looking for is just, do we, as core devs, all agree?

Ansgar Dietrichs: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

Ansgar Dietrichs: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.

stokes:Yeah, and maybe, you know, just to go down the CFI path a bit more, like.

stokes: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…

stokes:There are ways to, yeah, strengthen, strengthen the language, and hopefully then the commitment.

stokes: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

nixo: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?

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

nixo: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

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

stokes:Yeah, I mean, I think that's probably the most, sort of, by-the-book thing.

stokes:I would… Be a little concerned that it would be rushed to do the headliners, like, now.

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

stokes:But, that being said, perhaps we should just try.

stokes:And… yeah, I mean, again, I think it's…

stokes:I think we have a good sense of what our headliners are that we'd at least want to think about.

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

Toni Wahrstätter: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.

stokes:Okay.

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

stokes:From here, I do think there's a question of, do we want to CFI, do we want to SFI?

stokes:Or do we even want to go ahead and just, you know, move through the headliner process for HECA?

stokes:I would propose we take that async, and then try to get to some resolution, again, asynchronously before the next call.

stokes:In terms of how to move forward. And…

stokes:for example, I could go ahead and make a PR to the Medi IP in the next week,

stokes:That would, yeah, do SFI or CFI, and that can be a place we can take some discussion there.

stokes:Separately, yeah, I can reach out to everyone and try to get a sense of what's the best path forward.

stokes:So… Does that seem okay?

stokes:And yeah, I mean, Delight clients…

stokes:point here in the chat about making a decision, I think, you know, this is essentially DFI, but conditional on finding the right configuration.

stokes:So I spoke.

soispoke:Yeah, I mean, I do feel like, at this point, I don't want to, like.

soispoke:Be difficult or something, but it feels like it's been…

soispoke:maybe 6 months, or, like, over… over 6 months, then, like, people… people have supported fossil generally, and…

soispoke:every time…

soispoke:Like, it is a bit contentious, and every time we sort of, like, keep delaying making decisions about it,

soispoke:And I don't know if, like, sentiment is gonna change from now

soispoke: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,

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

soispoke:And then it's gonna be exactly the same for HECA.

soispoke:I just feel like at some point, like, it doesn't really mean anything anymore to delay processes and decisions, so…

stokes:Okay.

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

stokes:And we'll just have to accommodate that for the headliner process, you know, say in a couple months when we get to it.

stokes:Okay.

stokes:There's a clap emoji. Is everyone okay with that?

stokes:I think that seems to be the thing that swears most of the sides.

stokes:Okay. I'm getting a lot of positive reactions.

stokes:So… okay. Then let's do that, and just to repeat it to be clear, DFI Fossil for Glenster Dam.

stokes:I will make an SFI PR for Hecca Bogota for Fossil.

stokes:And then, yeah, you know…

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

stokes:Yeah, and then we'll move forward.

stokes:Again, I… think the sentiment around inclusion is clear, and again, maybe just to make it abundantly clear, like.

stokes:This is the thing people want to ship in Amsterdam.

stokes:They might want to also ship other things, and then it's… they're sorry, in HECA.

stokes:Let me start over. To make it abundantly clear, the sentiment is to ship this in ECA, this being fossil.

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

stokes:Okay.

stokes:Great.

stokes:From here, Let's move to the rest of the EIPs.

stokes:And, let me just find the agenda. It floated off somewhere.

stokes:So, okay.

stokes:From here, yeah, there's 1, 2, 3, 4, 5, 6 other CLEIPs for Amsterdam.

stokes:And…

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

stokes:There has been an update here, because we said we would split out, I think it was a leaner version of 8061 into 8080.

stokes:Is Francesco on the call? Because he could give us some more context on what he did there.

stokes:Or if someone else is aware of… oh, actually, Francesca might not be here today.

stokes:Okay then we'll move…

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

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

Mikhail Kalinin:So…

Mikhail Kalinin:Yes, the 8080 is basically, allows to use the consolidation queue, for exits, when the exit queue

Mikhail Kalinin:is longer than the consolidation queue. That's basically what it does.

Mikhail Kalinin:And, it's, also fixed to the problem that the 8071, fixes.

Mikhail Kalinin:And, in my opinion, 88 is strictly better than 8071, so I would prefer it to replace the previous EIP.

Mikhail Kalinin:So…

stokes:Okay.

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

stokes:No, go ahead.

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

stokes:Okay.

stokes: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,

Mikhail Kalinin:exit queue. The most recent version of 8061, basically.

Mikhail Kalinin: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.

Mikhail Kalinin:So that's… that's a bit different, the IP. It changes the queue, and it changes the acceptability period.

stokes:Okay.

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

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

stokes:Okay.

stokes:Thank you.

stokes:Potus?

Potuz:Yeah, I just want to remind that there was some pushback against, 8061, and that's why 8080 was,

Potuz: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…

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

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

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

Potuz:on updating the churn, and compute the exit, and update the churn that 8080 does. 8080 is a very simple change.

stokes:Okay.

Anders Elowsson:Maybe… Yeah, so essentially, it's sort of an efficient way to ensure that we use the SHARN.

Anders Elowsson: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,

Anders Elowsson: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.

Anders Elowsson: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.

stokes:Yeah, does anyone?

stokes:I'm not sure what DevConnect people have had time.

stokes: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…

Greg K | Lido: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.

Greg K | Lido: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.

Greg K | Lido:review. So, I'm not sure if we can now, like, in this call today, make a final decision

Greg K | Lido: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

Greg K | Lido:the details of them. I don't know what others think about it.

Greg K | Lido: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

Greg K | Lido:Additional discussion on it, but not now.

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.

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.

stokes:It seems like there's pretty broad agreement on 8080 as a way to fix, this issue that 8071 set out to fix.

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

Potuz:So these… these two commitments, I think we can… we're ready to make today.

stokes:Yeah, I agree with the DFI and 8070, so yeah, let's go ahead and do that.

stokes:Is there appetite for both 8080 and 8061?

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

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.

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.

stokes:Yeah.

stokes:So…

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

stokes:So then I would kind of propose we do that.

stokes:I guess the one thing is if…

stokes:the only extra bit of 8061 is the turn limits, and we decide we want that, then we do 8061 instead of 8080, but…

stokes:That seems… yeah, like something we need to figure that out.

stokes:Yeah. Okay.

stokes: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

stokes:How to adjust the turn limits, if we want to do that.

stokes:So… okay.

stokes:DFO 8071.

stokes:8080 or 8061. We will CFI one of those, or yeah, some combination of things here.

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

stokes:So… There's a question from Greg, just keep the… Point, that's spec updates.

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

stokes:But I think what we can say today is, like, we'll CFI something between these two.

stokes:And we will define that something on the next call.

stokes:Two weeks from today.

stokes:So… okay. I think we're pretty good there.

stokes:The next one in this direction of touching, different staking mechanics would be 8062.

stokes:This is adding… I think it was, like, a 5 BIPS withdrawal fee, on the sweep for 00…

stokes:One validators during their withdrawal process.

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

stokes:I will say we had, at least, you know, I saw some of our conversations last week at DevConnect.

stokes:And sentiments seem to be against us, if only because it feels a bit early.

stokes:The main thing this EIP would set out to do, as far as I see, is drive more consolidations more quickly.

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

stokes:So, again, I could see something like 8062 at some point.

stokes:Personally, it feels a bit early to do now.

stokes:What do others think?

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

Anders Elowsson: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

Anders Elowsson: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…

Anders Elowsson:Of course, I agree with the notion that there are plenty of staking service providers that will

Anders Elowsson:We'll switch over.

Anders Elowsson:to compounding validators. I have no doubt about that.

Anders Elowsson:And that they are working on it right now, but I am also fairly certain that there are

Anders Elowsson: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,

Anders Elowsson: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

Anders Elowsson:the first kind of fear, because as I've said before, it's more profitable for you to stay on

Anders Elowsson: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.

Anders Elowsson:Although it's not, of course, 100% certain that you know what you want to do with that.

Anders Elowsson: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.

stokes:Okay, thanks. Dima?

Dima Gusakov | Lido: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.

Dima Gusakov | Lido: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.

Dima Gusakov | Lido:That is… that gets materialized on their execution layer wallet, because at the end of the day, they need to pay bills.

Dima Gusakov | Lido: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.

Dima Gusakov | Lido: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

Dima Gusakov | Lido: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

Dima Gusakov | Lido: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.

Dima Gusakov | Lido: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.

Dima Gusakov | Lido: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,

Dima Gusakov | Lido: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.

Dima Gusakov | Lido: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.

Dima Gusakov | Lido: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,

Dima Gusakov | Lido:Because of the way how bonded validators are, how fractional staking works, because you will need to…

Dima Gusakov | Lido:Have sort of a regular update process or whatever else that would increase bond requirement as the validator balance increases.

Dima Gusakov | Lido:And, for example, without custom ceilings, without any, like, feasible option here to

Dima Gusakov | Lido: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,

Dima Gusakov | Lido: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.

Dima Gusakov | Lido: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,

Dima Gusakov | Lido: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

Dima Gusakov | Lido: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.

stokes:Yeah, Anders.

Anders Elowsson:Yeah, so I think we are in broad agreement that we should have this, sort of,

Anders Elowsson:User, tunable, ceiling.

Anders Elowsson:So… so I wouldn't, I wouldn't say that, there's any disagreement there, and we can, sort of, for this discussion.

Anders Elowsson:assume that perhaps we will try to achieve that for H star, but my point is that

Anders Elowsson: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…

Anders Elowsson:When we have two options, then, for, for, for,

Anders Elowsson: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,

Anders Elowsson: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

Anders Elowsson: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

Anders Elowsson:Hi.

Anders Elowsson:this, yeah.

Anders Elowsson:I fear that we will delay finality… fast finality by not trying to, sort of, be a bit more…

Anders Elowsson:Yeah.

Anders Elowsson:forceful on this issue, which will be a big degradation for Ethereum.

stokes:Bunner to go.

Enrico Del Fante (tbenr):I just want to say that I was resonating to Dima's last comment, saying that

Enrico Del Fante (tbenr):we should make new things, improve, instead of adding… forcing people to move via penalties. It's just features.

Enrico Del Fante (tbenr):That needs to be improved to make everything better on the other side. A part of that, maybe I'm not…

Enrico Del Fante (tbenr):fully, grasping the reason why 02

Enrico Del Fante (tbenr):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

Enrico Del Fante (tbenr):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.

Anders Elowsson:Oh, I'm sorry, did I… did I interrupt you?

Enrico Del Fante (tbenr):No, no, it's fair, if you can elaborate on that, it will be definitely helpful.

Enrico Del Fante (tbenr):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.

Anders Elowsson:I just don't think that it will be enough. So that's… that's why… why I…

Anders Elowsson: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…

Anders Elowsson: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

Anders Elowsson:in this fast finality design, that the consensus team is working on.

Anders Elowsson: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.

Anders Elowsson: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 (tbenr):It means that it requires a lower cup.

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

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 (tbenr):Yeah, but if 02 now has a kind of a limit in which it starts withdrawal, withdrawing,

Enrico Del Fante (tbenr):Let's say, -oh, more than… 266. It means that

Enrico Del Fante (tbenr):Yeah, we are still in this range where we might not have enough

Enrico Del Fante (tbenr):Enough consolidation, because 266 actually represents just 4 validators.

Enrico Del Fante (tbenr):Not more, so…

Anders Elowsson:Yeah, yeah, that's true.

Anders Elowsson: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.

Anders Elowsson: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.

stokes:Okay, let's jump back to the scoping discussion, but yeah, hopefully that was helpful.

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

stokes:So, I would propose we… DFI 8062.

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

stokes:Pressure to go to 02.

stokes:So, anyone disagree with, DFI?

stokes:Of 8062.

stokes:For your Amsterdam.

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

stokes:Yeah, this seems to be…

Anders Elowsson:They're of concern.

stokes:So, I think we move ahead with DFI.

Dima Gusakov | Lido: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

Dima Gusakov | Lido: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.

Dima Gusakov | Lido:a few more blocks there to increase our chances to maximum. I'm just not super comfortable with saying that

Dima Gusakov | Lido: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.

Dima Gusakov | Lido: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…

Anders Elowsson: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.

Anders Elowsson:But yeah, if everyone disagrees, then of course, I'm not gonna… Object.

stokes:Okay, so yeah, let's move ahead then with the DFI of AD62 for Glemsterdam.

stokes:And, yeah, from here, again, there's… Different designs to pursue.

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

stokes:Okay.

stokes:So, let me see the list here. We touched on all of these…

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

stokes:8045 is this EIP that excludes slash validators from proposing. Pretty straightforward, it's in the name.

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

stokes:Because there are just many fewer blocks.

stokes:And that's not great.

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

stokes:But, yeah, would anyone like to speak for or against the CIP?

stokes:Notice.

Potuz:Yes, as I mentioned last time,

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

Potuz:And these are the kind of things that we cache.

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

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

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

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.

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

stokes:Yeah.

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

stokes:Sure. Barnabas?

Barnabas: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,

Barnabas:So, I would like to see this change in,

Barnabas:And with the proposal look ahead.

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

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

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

Barnabas: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

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

Potuz: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…

Potuz:Would need to vet that.

stokes:Okay.

stokes:So, pending this concern, which I agree we should look into.

stokes:would people, like, do people generally lean towards including this in Amsterdam?

stokes:Because one thing we could do is CFI it today, and basically just, yeah, have this, like, pending…

stokes:to do.

stokes:To verify this thing.

stokes:And if it turns out that there's an issue, like POTUS is saying, then we would just take it out.

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

Potuz:Even if you're, like, syncing from a branch that you haven't, that you don't have.

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

stokes:Yeah.

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

stokes: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…

stokes:I think in terms of moving forward, we go ahead and CFI, and yeah, do exactly what Putin said.

stokes:Some people… well… look into this more deeply, and yeah, I will…

stokes:at least do what coordination I can to make sure that someone's actually on it, and that we don't drop this.

stokes:So… okay.

stokes:Are we good there?

stokes:Okay.

stokes:I'm curious what other client teams think.

stokes:Because everyone else has been pretty quiet on the issue.

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

stokes:Okay, so yeah, then CFI… Let me get the number right… 8045.

stokes:Okay.

stokes:Then, we just have one more here, and yeah, then we will have made actually a lot of progress today, which is great.

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

stokes:I actually do have a question.

stokes:with the CIP.

stokes: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…

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

Dustin: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

Dustin:in many cases, actually kind of meaningless bounds. If you look at the validator limit, that's just some big number.

Dustin:And it removes those things. But it doesn't restructure them in any other way.

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…

stokes:Like, would it just replace every instance of container in the spec with stable container?

Dustin:It… not every. It's… it's… there's some case-by-case aspect, I believe, but… but it's many.

Dustin: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…

stokes:And… okay, cool. Just to play it back then, in terms of sentiment…

stokes:Yeah, I think client teams, some of them were for, some against. There's also…

stokes:A lot of community support, that's worth calling out.

stokes:Even on the agenda today, Ocean from OBOL said, you know, they support this.

stokes:There were a number of, comments from the last call from different staking pools and things that also were interested in this.

stokes:Some other people are here on the call, and yeah, they're also interested in this.

stokes: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?

stokes: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?

stokes:I'd love to hear from some client teams.

stokes:And also echo here Barnes' comments, you know, how complex is it?

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

stokes:So, yeah, even if, again, the, like, spect is small, I think there are considerations around security here we should take into account.

stokes:So yeah, any client teams want to chime in?

stokes:Kingitas stay here for Lighthouse. They were originally against it, but now they're more open, given the Miva Fossil to Heka.

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

saulius:As seems the consensus is still that we need to ship the hard forks as soon as possible, or essentially fast.

saulius:We think that it's, it's a bit too big feature to, to put that into, into Glamsterdam, so…

saulius: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,

saulius:It's not, glamstaden is not the place to put this.

saulius:Future.

stokes:Okay.

stokes:Other pontofts.

stokes:Enrico here. Tegu in the chat says we're okay with 7688.

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

stokes:Yeah, I… I'm not sure myself.

stokes:Like, what I don't want is to get to a world where…

stokes:you know, this is something like that decision change in Petra, like POTUS mentioned earlier, where…

stokes: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…

stokes:yeah, there's performance implications, as Terrence mentioned in the chat, and then definitely security here.

stokes:Yeah, Barnabas proposes VCFI, and then, yeah, basically we can take it out if it looks like it's too big.

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

stokes:And one thing that would be nice is I think Etan is the champion, and he's not here, which is unfortunate, so…

stokes:If we CFI, that gives, yeah, I guess, more time.

stokes:For him to come make a stronger case.

stokes: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…

stokes:I will reach out to Etan and try to make sure he's at the next call.

stokes:Then we can decide there.

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

stokes:So how about we do that? So…

stokes:Again, I think we made a lot of progress on most of the EIPs.

stokes:we would still have, I believe it's just some question of 8061 versus 8080 on the next call, and then also, 7688.

stokes:And we'll… we'd be… we would be making final decisions on those EIPs on the next call, so…

stokes:Okay, no one seems to have any issue with that.

stokes:Okay, so let's do that, and then just to summarize, yeah, I think people lean towards including 7688.

stokes:And from there, we can move ahead with the fork.

stokes:Okay.

stokes:Barnabas had a question here… oh yeah, SSC and the engine API, yeah.

stokes:Do you want to say something, Barnabas?

stokes:We have a few minutes.

Barnabas: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,

Barnabas:In… in binary, basically.

stokes:Yeah.

stokes:I agree that's something we should do at some point.

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

stokes:So, with Fossil, We will SFI for Hecca Bogota, and DFI for Glamsterdam.

stokes:47688, gonna make a call on the next ACDC.

stokes:And the ask there would be to get a better sense of the total complexity and what's really involved.

stokes:8045, we said we would go ahead and CFI today.

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

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

stokes:Or find some resolution between those two.

stokes:8062, we decided to do DFI for Amsterdam.

stokes:And 8071, we decided to DFI.

stokes:So, I believe what I said was correct. I ally client.

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

lightclient:That wasn't what was agreed upon?

stokes:Mmm, I think it was.

stokes:We said DFI for…

lightclient:Pull all the client teams.

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

lightclient:And I feel like, at minimum, we should ask the client teams verbally if they want to SFI for HECA.

stokes:Okay.

stokes:Prism.

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

Enrico Del Fante (tbenr):we were for it in Glamsterdam, so we are.

Enrico Del Fante (tbenr):break.

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

Enrico Del Fante (tbenr):We were in favor for considering them in fossil in Amsterdam, so we definitely are.

Enrico Del Fante (tbenr):In February.

Enrico Del Fante (tbenr):Let's see if I aim for HECA.

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

Enrico Del Fante (tbenr):Yeah, yeah, for, for HECA, yes.

stokes:Okay.

stokes:Lodestar? Or yeah, Sean unmuted, so, Lighthouse.

sean:So just for me, like, me personally, we haven't talked about this particularly in the lighthouse, but the…

sean:I feel like it should be CFI, not SFI.

sean:I agree with, like, Klein's point that it kind of dilutes SFI, because, like.

sean:Is it, like, are we actually committing that hard to it?

stokes:It seems like we went to today, but… Okay.

stokes:Sure.

sean:Yeah, just personally, yeah.

stokes:Yeah, And… okay, nimbus, I think Dustin had a comment in the chat that he's fine with SFI.

stokes:Lodestar says they're okay with SFI…

lightclient:Nimbus said they're fine CFI-ing.

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

lightclient:Yep.

Dustin:Yep.

stokes:Okay. Grandine, I think that was the last one.

stokes:Solius, are you okay with SFI of fossil and HECA?

saulius:I just wrote on chat.

stokes:Oh, I missed it.

stokes:Well, CFI or SFI? Like, this is the distinction that we need to… Subtle.

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

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

Potuz:Even though it's definitely my personal preference to make sure that Fossil is, it's…

Potuz:Sounds weird, it wasn't my reading of the call?

stokes:Okay.

stokes:Yeah, I thought we all had agreement on this earlier, but…

stokes:Especially if you want EL input, this is something we could take to next week's call.

stokes:I think this does kind of… yeah, we walk back a little bit in terms of scoping progress.

stokes:But… Yeah.

stokes: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…

stokes:Although I think, to be clear, the clients seem to all be okay with CFI.

stokes:modular the points raised around, yeah, individuals versus clients, and then also the EL side of things.

stokes:Did you have a hand on, sorry?

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

Ansgar Dietrichs: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.

Ansgar Dietrichs:Get the Yale takes, and then make a decision in two weeks, I personally think that would be most appropriate, but yeah.

stokes:Okay, that works for me then.

stokes:So…

stokes:Okay, then Fossil, I think we're on the same page now, that, yeah, we need a little further consideration.

stokes:We'll take this to next week's ACD and see what the sentiment is there.

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

stokes:Okay.

stokes:Let's see, we have, like, one minute. There are a few more things…

stokes:to call out, I think, there was an ask for, everyone to start thinking about a name for I-Star.

stokes:And… otherwise, I think we've covered everything.

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

stokes:And I'll leave a summary of these decisions on Discord, and we will continue the conversation on next week's call.

stokes:So, thank you everyone, and I'll see you next time.

Potuz:Goodbye.

Mikhail Kalinin:Bye.

Mikhail Kalinin:Thank you.

Ansgar Dietrichs:I'm wrong.

Fredrik:Thanks.

Chat Logs

stokes:https://github.com/ethereum/pm/issues/1812

Barnabas:https://dora.fusaka-msf-1.ethpandaops.io

Bharath:Replying to "https://dora.fusaka-..." Are we using mev-boost on msf-1?

Chris:Is there any update on the bug for supernodes on mainnet nimbus client (25.11.0)?

Bharath:Replying to "https://dora.fusaka-..." No worries. Would be nice to do it if possible

stokes:https://github.com/ethereum/pm/blob/master/Fusaka/fusaka-mainnet-plan.md

Bharath:Replying to "https://dora.fusaka-..." For upcoming shadow forks

Fireflies.ai Notetaker Gustavo:Gustavo invited Fireflies.ai here to record & take notes. View Security & Privacy info: https://fireflies.ai/policy Type: '/ff leave' - Remove Fireflies View Realtime notes here: https://app.fireflies.ai/live/01KAXWG3E06XF13KNSB78ETCAH?ref=live_chat

Barnabas:ah might have misspoke regarding the versions sorry.

Barnabas:we are running 25.11.0 on msf-1

Barnabas:Nethermind is planning to have a live stream

Barnabas:not sure if there is any other ones

nixo:https://www.youtube.com/watch?v=upns65rH7mQ

alex:some will be flying actually 🙈 . but i trust everyone else will make sure things go smooth 😁

alex:@stokes now a good time to mention the discussion?

Potuz:Is terence here?

stokes:Replying to "@stokes now a good t..." next

Barnabas:Replying to "Is terence here?" delegating tasks already 😂

Potuz:PRs are already open for PRysm

Potuz:need to review them

Stefan Starflinger:Sorry wrong ACD

stokes:Replying to "Sorry wrong ACD" It was helpful!

Justin Traglia:We cancelled the last epbs breakout call due to devconnect. So no updates from me.

Potuz:Stephan is not here?

Barnabas:Replying to "Sorry wrong ACD" at least the EL guys are progressing 😂

Phil Ngo:We’re gonna be joining devnets in likely January, still a work in progress with Lodestar

kingy_sigp:sorry joined slightly late -- lighthouse making steady progress

Ansgar Dietrichs:Replying to "Sorry wrong ACD" EL best L according to many

kingy_sigp:we're looking good for late dec early jan

Ansgar Dietrichs:Replying to "Sorry wrong ACD" Sorry until Tim takes back over I will be tribal

alex:https://t.me/smilingalex

alex:ill add, the contentious views are on all kinds of points, but good to point out. they range from “why is this improvement worth adding” to “this change may centralize the out of protocol builder market more, we don’t want that”

alex:i also wrote a ethresearch opinion post to help give some context on the people which told me about the latter concern: https://ethresear.ch/t/trustless-payments-right-vibe-more-trust/23531

alex:if you have strong feelings on this either way, please come join the discussion.

Barnabas:FOCIL to SFI to Heka

kingy_sigp:sfi focil for heka

Caspar Schwarz-Schilling:SFI

Phil Ngo:SFI is much more of a commitment

Caspar Schwarz-Schilling:It’s literally CFI’ed for Glamsterdam and we’re about to push it into H*. This is precisely what we’re trying to prevent to happen again. (CFI is not a credible commitment)

lightclient:We haven’t scoped heka yet, so not really reasonable to commit to it already

nixo:will there still be a headliner process

nixo:yea that

Barnabas:I think FOCIL should be highest prio, and then scope the rest of the fork based on the assumption that FOCIL is SFI-ed already.

Toni Wahrstätter:Too early for SFI'ing anything for heka.

Dustin:this also creates the rug-pull risk that focil people were so concerned about

lightclient:FOCIL failed make it into glamsterdam. Just follow the process for heka

Łukasz Rozmej:I'm still for FOCIL in Glamsterdam, but it is up to you guys

Ansgar Dietrichs:I don’t personally think SFI is appropriate, purely for process reasons. I think we can formally CFI it for Heka now, with the understanding that we all have conviction already it will be included.

Fredrik:what if something else comes up between now and heka that we need to prioritize? Feels like there are many unknowns

Caspar Schwarz-Schilling:Replying to "I don’t personally t..." Then the discussion goes back to whether it goes into Glamsterdam or not

Barnabas:I think we need to start rethinking our process, as the current process is way to restrictive, which actually slows down potential decision making. Ideally pushing 2 forks a year, we need a process that allows for more pipelining.

Pari:We also bypassed process in the past tbh. e.g: 4844, withdrawals and PeerDAS were all pushed as confirmed (or some variation of SFI) before the previous fork was even shipped.

0x:Replying to "I'm still for FOCI..." It looks like most of the CL teams are willing to delay the fork if necessary. At least that’s what they wrote in their Hackmd or in their stated preferences

Caspar Schwarz-Schilling:the discussion moved on from FOCIL in Glam to exploring options to credibly commit in Heka.

lightclient:Replying to "We also bypassed pro..." If it’s unanimous, we can override. But FOCIL is definitely not a unanimously accepted idea

nixo:Replying to "We also bypassed pro..." is it not?

Potuz:Replying to "We also bypassed pro..." is it not?

lightclient:Replying to "We also bypassed pro..." Definitely not

Ansgar Dietrichs:Tend to agree with Barnabas, but would discuss that async

Pari:Replying to "We also bypassed pro..." Yeah from anything I’ve read, I’ve only seen a when FOCIL and not IF FOCIl

Dustin:was there opposition?

Dustin:to FOCIL

Pari:Replying to "We also bypassed pro..." Almost all client teams have mentioned including FOCIL

Caspar Schwarz-Schilling:Replying to "I don’t personally t..." anything but SFI is clearly not a credible commitment and so we need to go back to discussing FOCIL for Glam or not

lightclient:Replying to "We also bypassed pro..." https://censorship.pics/

Barnabas:Can we at least agree to DFI FOCIL from glammy?

lightclient:Replying to "We also bypassed pro..." Censorship is over

Ansgar Dietrichs:Replying to "was there opposition…" To which part? Glamsterdam? SFI Heka? CFI Heka?

Toni Wahrstätter:Replying to "I don’t personally t..." But why do we need a "credible committment"?

Caspar Schwarz-Schilling:Replying to "Can we at least agre..." that’s dependent on whether we find a credible commitment for Heka though

Dustin:Replying to "was there oppositi..." heka

Toni Wahrstätter:Replying to "I don’t personally t..." If it's still important in 6 month, we just ship it. No early committments needed.

DA | Flashbots:Replying to "We also bypassed pro..." ^iiuc this only measures tornado cash. Builders/relays still “censor”, there just rarely is anything not OFAC compliant

Enrico Del Fante (tbenr):Is because OFAC is shrinking?

Barnabas:previous forks were scheduled 12mo ahead, so scheduling something 12mo out “unrealistic” sounds weird.

lightclient:Guys the process changed march of this year

Barnabas:Replying to "Guys the process cha..." thats like ages ago

lightclient:Replying to "Guys the process cha..." I’ve lived 3 full length lives since then

Łukasz Rozmej:Replying to "I think we need to s..." we need 3 forks a year! :)

Łukasz Rozmej:Replying to "I think we need to s..." Not even a joke

Pari:Replying to "I think we need to s..." Lets first get good at doing 2 🙂 feels like that’s been a big enough lift with tons of resistance

Łukasz Rozmej:Replying to "I think we need to s..." release often - allows to make releases smaller

Pari:SFI-ed EIPs can still be removed, it just implies the burden of proof needs to be much higher than for a CFI-ed EIP right?

lightclient:Part of the point of the process is to put rails up to guide discussion so we don’t spend hours of group discussion time creating new process tools

soispoke:Replying to "SFI-ed EIPs can stil..." yes

Dustin:Replying to "SFI-ed EIPs can st..." more EOF drama

Pari:Replying to "I think we need to s..." Issue is the time we have to wait for ecosystem between testnets/mainnet. There’s ~2-3 months between first release to mainnet. We need to shrink that, but then we push an unrealistic cost on the ecosystem.

Łukasz Rozmej:Replying to "We also bypassed pro..." @lightclient wouldn't call it over, just on halt

lightclient:Replying to "We also bypassed pro..." Even at the absolute worst, 10% of blocks were not censoring

Łukasz Rozmej:Replying to "We also bypassed pro..." give it some elections in some powerful parts of the world and it can change drasticly

lightclient:Replying to "We also bypassed pro..." Ethereum is always censorship resistant

nixo:but we should acknowledge that we need a harder commitment than CFI - can we commit to having an outlined headliner process that prioritizes FOCIL before next call?

lightclient:Can we make a decision on glamsterdam

Barnabas:+1 matt, lets just DFI for glamsterdam, and we can bikeshed whether its CFI or SFI for heka

Ansgar Dietrichs:Replying to "but we should acknow…" Why do we need a harder commitment?

Dustin:one cost of not making a more credible commitment (with respects to Ansgar's point) is the next future "FOCIL" will know they might want to fight harder against DFI-in-n-for-n+1

lightclient:No conditionals 😭

Łukasz Rozmej:Replying to "I think we need to s..." we need leap-frogging hard forks

Barnabas:we have so many other EIPs to discuss.

Ansgar Dietrichs:Replying to "but we should acknow…" Clearly everyone wants it in Heka

Ansgar Dietrichs:Replying to "but we should acknow…" That’s the most credible aspect no matter what

nixo:Replying to "but we should acknow..." because it was CFI’d for Glamsterdam and the champions have indicated that their agreement to move it is conditional on a harder commitment

lightclient:It’s contentious for a reason

Dustin:in glamsterdam

Dustin:not heka

Potuz:Replying to "We also bypassed pro..." @matt > Censorship is over This is really a bad take, there are much more impactful and possibly profitable censorship attacks than censoring TC. We will only find out about them when a rollup is rugged

Katya:We even have metrics for FOCIL 😂

Caspar Schwarz-Schilling:Replying to "It’s contentious for..." what’s contentious except when to ship it?

Łukasz Rozmej:Replying to "We also bypassed pro..." but it needs to be censorship resistant and relevant

nixo:Replying to "but we should acknow..." and not just champions, the majority of client teams and community expressed support for it in Glamsterdam

Barnabas:make the decision Stokes 😂

lightclient:Replying to "It’s contentious for..." Whether we should be doing FOCIL

Potuz:Replying to "We also bypassed pro..." even from a scaling perspective there's more to Focil

lightclient:Replying to "It’s contentious for..." I don’t think we need it

Ansgar Dietrichs:FOCIL was always contentious for Glamsterdam, we never had “everyone agrees it will be in”, independent of process. For Heka we now have “everyone agrees it will be in”. That is what matters.

Caspar Schwarz-Schilling:Replying to "It’s contentious for..." I think that’s mostly you?

Dustin:the whole "but the process" thing is a bit farcical given the effort in this call to undermine the agreements with L2s etc timelinewise before

Ansgar Dietrichs:I still hate SFI, but whatever. Let’s do it

lightclient:Replying to "It’s contentious for..." I don’t think so

nixo:Replying to "It’s contentious for..." who else

lightclient:Replying to "It’s contentious for..." They can come forward if they want

Dustin:it's a new process

nixo:Replying to "It’s contentious for..." are these FOCIL opposers in the room with us right now

Potuz:Replying to "It’s contentious for..." lol

Toni Wahrstätter:Replying to "It’s contentious for..." We don't know if there is something more important in the future. If there is, we should ship that instead of any other eip. It doesn't matter at all how long an eip has been around.

Carl Beekhuizen:Replying to "It’s contentious for..." I’m also not convinced it is the right move (even in heck)

Barnabas:Having a decision so early will enable us to start testing FOCIL asap. This will be great for pipelining

Ansgar Dietrichs:So to be explicit, this doesn’t mean we already decided no (other) CL headliners in Heka, right?

Fredrik:Replying to "It’s contentious for…" Is there any writeup that describes the reason to not do it?

Barnabas:Replying to "So to be explicit, t..." correct

Łukasz Rozmej:Replying to "Having a decision so..." exactly we should be finishing scoping H* and starting I* soon

lightclient:Replying to "It’s contentious for..." https://mevboost.pics/

Barnabas:Replying to "Having a decision so..." agreed.

lightclient:Replying to "It’s contentious for..." 8.2% of blocks are vanilla

lightclient:Replying to "It’s contentious for..." The backbone of CR in ethereum

Barnabas:Replying to "It’s contentious for..." epbs fixes this 😂

terence:the real value is something like 4.7% last time i look at validator regisgration data from ultra sound (only)

terence:Replying to "It’s contentious for..." 8.2% is higher because of min bid

nixo:Replying to "So to be explicit, t..." so it’ll just be a “what can go along with FOCIL” process?

lightclient:Replying to "It’s contentious for..." But if you do min bid, you wouldn’t necessarily be censoring

lightclient:Replying to "It’s contentious for..." Maybe some of those clients build custom censoring logic into their clients for local blocks, but that doesn’t currently exist AFAIK

terence:Replying to "It’s contentious for..." ya but i think min bid is useless against a more impactful and profitable censorship attacks

Toni Wahrstätter:Replying to "It’s contentious for..." If it's just about CR, builders included more sanctioned txs than local builders (relative to total blocks of each category). We should stop pretending that CR is binary and that focil is the only solution.

Potuz:that's beyond my pedigree

Barnabas:what was the reason we got rid of the dynamic churn again?

soispoke:Replying to "It’s contentious for..." CR is not binary, and FOCIL significantly improves inclusion guarantees, I think those points have been discussed ad nauseam

Mikhail Kalinin:in which case/EIP?

Toni Wahrstätter:Replying to "It’s contentious for..." Not on my timeline

Barnabas:Replying to "what was the reason ..." I remember we had the mechanism where the deposit queue was increased based on how many validators we have. Ideally we could just have dynamic churn sizes based on validator sizes. So if we have 1M validators we have bigger churn, and if we have less validators, it goes back down.

soispoke:Replying to "It’s contentious for..." We haven’t discussed these points before?

kingy_sigp:8080 looks good to me, so does potentially 8061, but lighthouse was at devconnect last week so we need a little more time to discuss internally

Mikhail Kalinin:Replying to "what was the reason ..." the motivation to limit activation queue in 8061 is to avoid dealing with issuance

Anders Elowsson:Feels like everyone is in agreement now

Barnabas:Lets CFI 8061 DFI 8071 CFI 8080 ?

Potuz:This is my position as well

Anders Elowsson:Wait with 8061 one call

Anders Elowsson:Or CFI it

Mikhail Kalinin:Replying to "This is my position ..." you wanted to DFI 8061,no?

Greg K | Lido:Just keep the point that spec updates on 8080 could still be proposed?

Potuz:Replying to "This is my position ..." yes, my position is to discuss these next call if people aren't ready

Potuz:Replying to "This is my position ..." but I prefer 8080 alone

Mikhail Kalinin:Replying to "This is my position ..." ah, i see, thought you replied to Barnabas

Potuz:Replying to "This is my position ..." no no, timing sucked, was reasserting Alex's point

Barnabas:Replying to "This is my position ..." When Potuz agrees with Barnabas, everyone should always get sus

Mikhail Kalinin:Replying to "Just keep the point ..." i think there can be a slight change in the spec but nothing substantial

Jihoon:Replying to "It’s contentious for…" I believe I said I think FOCIL is not a silver bullet for CR over our beers last week tho

Greg K | Lido:Suggest to DFI 8062 from Glamsterdam

0x:Replying to "Suggest to DFI 806..." For what i could gather most of the teams agree on this

Potuz:Replying to "It’s contentious for..." > But if you do min bid, you wouldn’t necessarily be censoring There are fairly serious research on the cost of censoring with and without FOCIL... the current picture is kinda irrelevant in the face of an actual censoring attack.

Barnabas:Sounds like this would be overcomplicating the protocol for little benefit imo.

Toni Wahrstätter:Replying to "It’s contentious for..." It's not only about local building. Again, there's an incentive to include tx, the tip, and many builder are happy to include any tx for money. We only get faster(!) inclusion.

Pari:Yeah weren’t custom ceilings looked into during the original Pectra work? And we decided against it due to complexity right?

stokes:Replying to "Yeah weren’t custom ..." Yes but we could add at some future point

Barnabas:Replying to "Sounds like this wou..." PTSD from when we were working on consolidations. We should have just have maxeb without consolidations, and just ship pectra like that 6 mo earlier.

stokes:Replying to "Yeah weren’t custom ..." It was more about pectra itself

Potuz:Replying to "Sounds like this wou..." For once I agree with you Barnabas

nixo:Replying to "Sounds like this wou..." yea, it’s not touching functionality, just convenience. for professional operators, i think predictable rewards can be accomplished by predictably manually withdrawing. for solo stakers, we don’t really need them to consolidate to have a meaningful impact on validator set size, it’s OK if they stay

Toni Wahrstätter:Replying to "It’s contentious for..." Faster inclusion might be a great feature but this should be made clearer. People perceive CR as binary and see focil as solving the problem, which it does not. On-chain enshrined privacy does.

Barnabas:Replying to "Sounds like this wou..." never used my 0.002 ETH partial withdrawal to pay my bills 😄

Potuz:I don't think there's broad agreement at all on that...

Dima Gusakov | Lido:Myself and a few Lido people are currently drafting custom cleanings EIP

Mikhail Kalinin:Replying to "Sounds like this wou..." consolidations were important UX improvement for MaxEB adoption, we could not predict that they would not be that useful eventually

Barnabas:Replying to "Myself and a few Lid..." can you not just make a shell script that makes predicable withdrawals based on current queues?

Dima Gusakov | Lido:Once 0x02 UX is good enough, we can consider implementing a fee for 0x01. But not now

Barnabas:Replying to "Myself and a few Lid..." trigger predictable partial withdrawals based on that?

Dustin:Replying to "Sounds like this w..." in which case maybe they weren't that important?

Greg K | Lido:Also, 8068, which was DFIed, was giving an incentive for 0x02 by making the compounding rate better (with the updated effective balance calculation). So proposal would be that for H* we do: 8068 to have better compbounding for 0x02 validators New EIP to introduce custom ceilings for 0x02 validators.

nixo:Replying to "Myself and a few Lid..." yea seems like it should be within a professional operator’s capability

Dima Gusakov | Lido:Replying to "Myself and a few Lid..." It will still require some transactions

Barnabas:Replying to "Myself and a few Lid..." so?

Barnabas:Replying to "Myself and a few Lid..." gas is cheap

nixo:Replying to "Myself and a few Lid..." so the gas fees are the problem?

Dima Gusakov | Lido:Replying to "Myself and a few Lid..." For pros - maybe. For solos and CSM I don’t feel it is an option. Sorry

nixo:Replying to "Myself and a few Lid..." CSM maybe, but i’ve not heard a ton of grumbling from solo stakers. they can just stay with 0x01

Barnabas:Replying to "Myself and a few Lid..." make it open source, and csm and solos can use the script too 😄

Ladislaus:Hat auf "CSM maybe, but i’ve ..." mit 🤝 reagiert

soispoke:Replying to "It’s contentious for..." I think enshrined onchain privacy should be worked on a lot more too There are tons of nuances there as well, you could also have builders censor all private transactions if they wanted to

Mikhail Kalinin:Replying to "Sounds like this wou..." consolidations were quite important when we were working on the Pectra, there was no signal from anyone that they won’t be that much useful

Potuz:At current values, a validator with the top max EB balance would sweep around USD 1200 every couple of weeks right?

Potuz:so it seems to me that the argument of predictable income only applies to whales

Potuz:and not small home stakers

terence:Replying to "At current values, a..." dont you have one like that?

Barnabas:realistically we don’t care if a home staker consolidates or not. As they probably have 1 or 2 validators at home. Big operators are the real problem.

Potuz:I have a few, had to divide by the number of vals after checking my bank statement

Potuz:yeah but the point is that customizing for less than the max EB seems stupid to me

Dima Gusakov | Lido:Replying to "yeah but the point i..." Why?

Potuz:Replying to "yeah but the point i..." Because of the numbers above

Greg K | Lido:For the finality part, we also need some real numbers on the number of validators targetting and their impact on the finality design. Do we have any draft of the current fst finality solution considered?

Dima Gusakov | Lido:Replying to "yeah but the point i..." The numbers are for the current MAX_EB

Potuz:Replying to "yeah but the point i..." yes

Dima Gusakov | Lido:Replying to "yeah but the point i..." If I can set sweep threshold to say 128 ETH the numbers are radically different

Potuz:We do not need to even impose penalties, we can simply deprecate 0x01 and force exits

Dima Gusakov | Lido:Replying to "We do not need to ev..." lol

Dima Gusakov | Lido:Replying to "We do not need to ev..." What a great idea)

nixo:i agree with anders - there’s very little appetite to experiment and iterate on mainnet with the same features

DA | Flashbots:It just sounds to me like pools are never going to consolidate without a push.

Enrico Del Fante (tbenr):Replying to "We do not need to ev..." I fully agree! 🙂

nixo:Replying to "It just sounds to me..." some of them are working on it, they just need time

Dima Gusakov | Lido:Replying to "It just sounds to me..." If you really want to farce them, than do what @Potuz proposed and force exit all 0x01

Enrico Del Fante (tbenr):Replying to "We do not need to ev..." FastFinality is here, get your eth back and decide what to do 🙂

Mikhail Kalinin:Replying to "For the finality par..." we are able to aggregate 32k signatures in one slot at the moment, and we don’t know if we can do more. But given that number, we should aim 32k validator set size for fast finality. This is naive estimation but gives an idea

Dima Gusakov | Lido:Replying to "It just sounds to me..." And loose the majority of solo stakers

Barnabas:proposer lookahead fixes this no?

Dima Gusakov | Lido:Replying to "It just sounds to me..." Also Lido is working on transitioning the whole 2048 ETH validators in 2026

Toni Wahrstätter:Replying to "It just sounds to me..." The biggest lever is money, always has been

Dustin:Potuz: can the EIP be adjusted to basically ensure that the proposer lookahead is enough?

terence:we are so back

Potuz:Yes Dustin

Potuz:I believe it's safe because of the Lookahead

Potuz:but it needs to be vetted

Dustin:ok

Barnabas:we always assumed that proposal lookahead is a given for this eip

Dustin:+1

Phil Ngo:+1

nflaig:+1

Enrico Del Fante (tbenr):+1

terence:+1

Saulius Grigaitis | Grandine:+1

Barnabas:how complex of a change is 7688?

kingy_sigp:lighthouse were originally against 7688, but that was in the context of including focil. we're more open to inclusion now

Dustin:Diva, Lido, Obol at least

Dustin:It's relatively isolated in SSZ

terence:seucirty and also performance too i think

Dustin:Nimbus is for, obviously

Potuz:We do special case SSZ though

terence:Prysm is for from team stance

Potuz:@etan how long will it take to rebase on top of ePBS?

Potuz:the envelope and the blocks will need to change as well right?

Dustin:@etan probably isn't in this call

Potuz::(

Pari:How large is this feature going to be? Please take into account epbs + bal changes

Justin Traglia:Replying to "@etan how long will ..." There’s a PR for this: https://github.com/ethereum/consensus-specs/pull/4630

Dustin:But can answer, yeah, probably

Dustin:BAL is 100% separate

Dustin:EL, this is CL only

Potuz:Replying to "@etan how long will ..." ah nice, Etan was waiting for thiis discussion to decide on the light client

Enrico Del Fante (tbenr):We are ok with 7688. We have already implemented Stable Containers in a branch. In the assumption that we can reuse some of the effort from that branch

terence:what about APIs that take ssz as input? like builder api

Phil Ngo:It’s low effort for us as it’s mostly a ssz package change

Dustin:Replying to "what about APIs th..." optional, they'd have to kind of opt in to it

Barnabas:Replying to "BAL is 100% separate" 99.8% separate. BAL touches the beacon state

Barnabas:sounds like most teams are for it, so lets CFI, and take a closer look? We can DFI later if its too big

Justin Traglia:I would say now is the time. I support stable containers.

terence:Replying to "what about APIs that..." will have to maintain 2 libs even post fork

Dustin:Replying to "BAL is 100% separa..." right, it's possible it changes to a ProgressiveList or similar

Dustin:Replying to "BAL is 100% separa..." but it's a localized thing

Potuz:Replying to "BAL is 100% separate" I think it's just like any other field in the payload right?

Potuz:Replying to "BAL is 100% separate" it will change the way we merkleize

Dustin:Yeah, I'm trying to proxy for him

Dustin:but he's better

Dustin:Replying to "what about APIs th..." well, or one SSZ library which can support both

Yann Vonlanthen:Replying to "For the finality par..." That’s a good point. We are working on a draft. Exact trade-offs will also depend on how much we can squeeze out of networking. With new p2p improvements on the horizon, potentially things could be better than expected. In any case more consolidation will always be better for fast finality, even more so in a PQ world.

Barnabas:Not really a consensus related question, but we should consider working on making the engine ssz compatible. Maybe this is for a future call, but would like to open this box today, if we get some time in the end.

Potuz:That's the best Trojan horse we needed

Pari:Thats more of an ACDE question tbh

Dustin:Replying to "BAL is 100% separa..." Well, to the extent one might remove the arbitrary lmits in `List`

Pari:They are the ones that have the harder time integrating SSZ, not the CLs

Barnabas:Replying to "Thats more of an ACD..." probably, but the CL has to support it too

Potuz:Replying to "Thats more of an ACD..." for us that change is surely trivial

lightclient:I thought we were going to CFI focil?

Potuz:Replying to "I thought we were go..." DFI you mean?

lightclient:Replying to "I thought we were go..." DFI for glamsterdam, CFI for heka

Dustin:I mean we can and do

Phil Ngo:Stating here that we are ok with SFI

Barnabas:prysm == potuz

Ansgar Dietrichs:I do think it’s a bit problematic to SFI without EL client input tbh

lightclient:Replying to "I do think it’s a bi..." yeah

Barnabas:Replying to "prysm == potuz" its a hive mind anyways

Dustin:Nimbus is fine CFI'ing FOCIL for Heka

lightclient:Replying to "Nimbus is fine CFI'i..." CFI or SFI?

terence:besides clients teams, what about the community?

lightclient:Replying to "Nimbus is fine CFI'i..." We’re asking about SFI

Ansgar Dietrichs:At best it should be a proposal to be confirmed next week on acde

Barnabas:SFI != CFI lmao

Dustin:Replying to "Nimbus is fine CFI..." SFI is fine

Potuz:Replying to "I do think it’s a bi..." I think the biggest issue is that there're teams working on contending

felix (eest):Replying to "prysm == potuz" shout out to ethpandaops for maintaining the hive mind

Toni Wahrstätter:Replying to "I do think it’s a bi..." Agree! Independent of sfi'ing too early

terence:can we revisit this in 2 weeks and have client teams all have a formal decision?

Ansgar Dietrichs:Replying to "I do think it’s a bi…" @Potuz not sure I understand what you mean?

saulius:Grandine is fine with CFI'ing FOCIL for Heka.

Potuz:Replying to "I do think it’s a bi..." this UI sucks

Potuz:Replying to "I do think it’s a bi..." I think it's unfair to 6 seconds

Potuz:Replying to "I do think it’s a bi..." if we do SFI

nixo:Replying to "Grandine is fine wit..." the question is SFI

Marc:I’m happy with SFI, need to double check with rest of nethermind team but generally think they support

Trent:Sounds like this might need to be an async tally bc we’re getting individual perspectives mixed in

Enrico Del Fante (tbenr):Replying to "SFI != CFI lmao" This is a nightmare for Italians, sorry :-)

Toni Wahrstätter:What does this (sfi'ing focil) mean to the headliner selection process for heka on the CL?

Ansgar Dietrichs:Well SFI seems contentious for now, we can just CFI now and then see if we want to fast track SFI over the next few weeks already

Barnabas:This same question came up in previous acdc call

nixo:i volunteer as tribute to poll client teams over the next two weeks and have a definitive proposal for moving forward for CFI or SFI OK sounds like it’s just going to ACDE

lightclient:Everyone is okay with CFI, just make it CFI and we can discuss SFI in the future

Potuz:Replying to "SFI != CFI lmao" lol

Potuz:I think it's fine to determine this on ACDE TBH, everyone involved will be there

lightclient:FOCIL is CFI as of today though right?

Ansgar Dietrichs:Replying to "I think it's fine to…" We are just so swamped there, I will try hard to 5min time box it

Potuz:Replying to "i volunteer as tribu..." you should do the poll anyway

terence:Replying to "FOCIL is CFI as of t..." yes i believe so

nixo:Replying to "i volunteer as tribu..." okay, will do. cuz we can’t just keep repeating the discussion ad infinitum

Dima Gusakov | Lido:Replying to "FOCIL is CFI as of t..." For Heka

Potuz:Replying to "FOCIL is CFI as of t..." yes

Justin Traglia:Bye everyone 👋

Summary

8 highlights · 5 decisions · 3 action itemsExperimental

fork status and schedule

Mainnet Shadow Fork 1 launched with BPO1 (15 max blobs) and BPO2 (21 max blobs); near 100% participation over 24 hours00:04:12
Fusaka mainnet activation in a few days; Nethermind planning livestream00:08:22

client updates

Nimbus 25.11.0 running on MSF-1; 25.11.1 release in progress to fix supernode bug00:05:44
ePBS Prysm PRs passing spec tests, awaiting merge to develop; Teku merging to master00:11:09
Lodestar targeting January for ePBS devnets; Lighthouse making steady progress for late Dec/early Jan00:12:26

testing progress

Block-level access lists: 3 clients passing tests, DevNet launch imminent after Kurtosis testing00:10:09

organizational

Trustless payments discussion flagged for ePBS breakout call December 5th due to community contention00:13:05
FOCIL SFI vs CFI for Heka debate00:34:03

Decisions

EIP-7805 moved to DFI for Glamsterdam; CFI for Heka, SFI discussion to ACDE00:37:07
EIP-8071 moved to DFI; will CFI either 8061 or 8080 next call00:46:10
EIP-8062 moved to DFI for Glamsterdam; debate on impact, timing, UX improvements needed first01:04:14
EIP-8045 moved to CFI; pending verification of proposal lookahead safety01:13:37
7688 (stable containers) deferred to next call; lean towards inclusion pending complexity review01:20:38

Action Items

All client teams: Fill out incident response coordinators in Fusaka mainnet plan00:07:59
Client teams (coordination by stokes): Vet that proposal lookahead works correctly across forks for EIP-804501:12:44
stokes: Reach out to Etan re: EIP-7688 complexity assessment for next call01:20:32

Targets

Fusaka mainnet activation - December 3rd00:08:22
December 5th - ePBS breakout call for trustless payments discussion00:15:16