All Core Devs - Consensus #169

Transcript

Vitalik Buterin: Hello! It's all… it's always annoying when everyone starts off silent, because you can't tell whether or not the audio is broken, but glad it's not.

Nixo: Good morning.

Alex Stokes: That is annoying. Good morning, Nixo. Let's see, let's give people another minute or two, and then we'll get started. People like to stream in around now.

Okay, I feel like this is usually the number of people we wait for before we kick things off, so let's go ahead and get started. Josh, are you helping with the stream?

Josh Davis: You are alive, Alex.

Alex Stokes: Okay, thanks. Hello, everyone. Welcome to ACDC. This is number 169. It is issue 1790 in the P&M repo. I dropped a link to the agenda here. And, yeah, just by way of summary, so… We'll touch on any Fusaka things, yeah, there's a few things there. Then, you know, we're in this process of scoping Amsterdam, so we'll, try to make headway there. As a reminder, yeah, there's a handful of CLEIPs we can touch on today. There's many more ELEIPs, so yeah, it's probably going to take another call or two to get that, you know, work through, final scope there. But yeah, hopefully we can make good progress on the CL side today, and, you know, even pretty much, finalize things. So…

Let's see what we can do. And with that, let's start with Fusaka. So, I think the first thing, we did have BPO2 on Hoodie, I think it was yesterday, or maybe the day before. Yeah, actually it was almost exactly 24 hours ago, so… Pretty cool. Anyone have anything they'd like to share from there, or anything else on the other testnets? From what I saw, BPO2 went pretty well.

kev and pandaops: Yeah, we haven't noticed anything, but the team's also mostly been traveling yesterday, but there was no participation drop or anything funky on the peer-to-peer layer, so seems to have gone well.

Alex Stokes: Okay, great. And have we started spamming blobs at the higher limits now? Alright, hoodie.

kev and pandaops: We should have, but I can check the config.

Alex Stokes: Okay. I'm not saying blog fees are going crazy, which… Is that a good sign? Crazy good. Emma, do you mean, like, they're going up, or they're jumping all over the place?

Ahmad Bitar: They're… they're high. They're pretty high. That's what I meant.

Alex Stokes: Yeah. Okay. Something we can look into. Potus, would you like to mention the attestation issue?

Potuz: Not particularly, but… Okay.

Alex Stokes: Okay. Then I'll reach out after. Anyway, okay, there's some chatter about Hoodie. Anything else, though? Generally, yeah, the test nights have gone really smoothly, and things look pretty good. Okay. If not, then there was a request, and I wasn't quite sure where to put this, here from Holger. So, he points out that BPOs don't have a place to live in terms of, like, EIPs or meta-EIPs. And, you know, maybe to make, make the point, we have the current BPOs tied to the Fusaka Meta EIP. You know, presumably there'll be more BPOs throughout the future. They can go to future Meta-EIPs, but part of the whole strategy with BPOs is that we can have, you know, flexibility to do what's almost, you know, quote, interfork, changes.

And then there, the question is, like, yeah, how do we want to think about these? It's good for documentation, you know, specification, and just, you know, honestly, communication for everyone to understand what's happening. With these changes. So, there's a question around how to think about this. We chatted a bit on, the ETH R&D Discord, and I think we basically got to a place of having, like, some sort of interfork meta-EIP, something like this. I don't know if Holger is on the call today, but in any case, would anyone like to chime in further? Or if you have any, yeah, any thoughts. or strong opinions on how to do this. I think some kind of interfork MIDIP is probably the way to go.

Okay, yeah, there was…

kev and pandaops: The main issue I see with having a new BPO-only EIP is that we would kind of mix Fox and BPOs again. So you would need some logic that says that BPO123 happened after Fusaka, but BPO 456 happened after Glamsterdam, and if you separate the two, then it's kind of hard to know which sequence things get applied in. And this is for the CLs, because they built the state on top of the last fork.

Alex Stokes: No. So, then instead, would you just… Okay, so, like, let's say we have VPOs in between Fisaka and Amsterdam. You think we just put the new VPOs onto Fusaka Meta EIP?

kev and pandaops: That sounds sane to me, or we have some meta-fork tracker that says this is a sequence of all forks that happen.

Alex Stokes: Right. Okay. In any case… There was some discussion on, the Execution Dev channel. Let me just paste this here in case someone wants to go find it. on the ETHRD Discord server, I don't have a link to the message, but it's pretty recent in the stream, so yeah, just go check out the channel, if you want to chime in. And yeah, Dustin, I think, is essentially lessening what Perry said about tying it explicitly to Fusaka, so… Yeah, we'll figure that out before we get to… the next VPOs we want to deploy, and yeah, have it in a way that makes sense for everyone. Thank you, Nixo. There's a link there in the chat. Okay. Anything else on Fusaka?

Otherwise, yeah, mainnet is scheduled to arrive. What is that? Basically, a little over 3 weeks. So, that's super cool. And… Yeah. Anything else? If not, we'll turn to Glamsterdam. Okay. Let me refer to the agenda. Okay, I did want to start with a check-in on APBS, so, you know, like I was saying, a big topic today is going through the rest of the Glencer Damn scope. And selecting non-Hemliner EIPs, for the fork. That being said, we do already have the headliner with EVBS, and yeah, did want to do a quick check-in, if there's any updates people want to surface on the spec, or progress on DevNets.

As far as I understand, we're still pretty early along, with implementation progress, which means, yeah, there's not, like, for example, an EPS, EPBS DevNet Zero yet. But, yeah, there's definitely people working towards one.

kev and pandaops: Can we have at least something that's, like, a local Kurtosis DevNet, or something working with some clients, and a potential deadline associated with that? Because I fear that we wait until January, then we start doing interop, and then we take, like, 6 months to figure out interop, so I'd rather we start that process earlier. Even block-level access lists are not finished by any means, there are plenty of bugs, but Trying to develop… Along with, Interop helps figure out a lot of those bugs earlier.

Alex Stokes: Who knows?

Potuz: workloads. The problem was that we kept, adding things to structures in the CL repo, and that means that we need to wait for new releases to have test vectors so that we can actually pass static tests. But, this seems to be now stable. Teku, as far as I know, is the one… is the client that is closest, to be able to run in Cortosis. They already are forking with the… with the new specification. Prysm is starting to merge. I expect that it's going to go fast now, that we can actually merge into our developed branch, so we hope that in a couple of weeks, we're going to be in a much better position to start testing ourselves, and then running Cortosis with Teku. I don't know about other clients.

The one thing spec-wise that, that I wanted to mention is that we might have some changes, on the engine API, These are minor things, like adding a Boolean here or there, and but it'll be nice to, like, have this talk with EL devs, probably not in ACD, probably ACDT, perhaps. And depending on what happens with the scoping for Glamstadan, we have different options to what we can do on the engine API.

Alex Stokes: notes.

Potuz: Perhaps the major thing that I wanted to mention is that We spoke here on ACD about off-protocol payments, and how builders will, will, like, signal that they are willing to make a bid, to pay on the execution layer, and not go through the trustless mechanism. We, Originally, we were thinking on putting this on the engine, on the builder API, so that it's… there's, no consensus record of what this value was. But, we were convinced that it's better to put it on the execution bid. So, builders will have to actually put this value if they want, and it's going to go in the bid itself, in the signed part of the bid itself.

Alex Stokes: Anyway, thanks for the update. To Perry's point… I mean, I'll just throw this out here. Is it unreasonable to aim for a DevNet in, like, a month from now?

Potuz: I think it's not, it's hopeful.

Alex Stokes: Okay. I can be hopeful. So, yeah, I think then that would maybe help put some bounds on things, even here, like Terrence is saying, like, maybe we don't need the engine API changes you were mentioning in the first subnet, so… I think it might put some… some helpful boundaries on things, just to start the R&D process moving further along. So… Yeah, let's… let's have those rough targets, having, you know. even if it's cobbled together with kurtosis and things, something that, you know, we can start messing with and work towards more of an interop setting, like Perry was saying. you know, around a month from now, mid-month December, and yeah, let's see how that goes. Anything else there on EPVS?

If not, we can turn to the next section. Okay, and before we jump in, I did put this here on purpose, just to drive the point home that, you know. We should be very mindful of how we think about scoping, which is the thing we'll get into next. We do have EBPS as a headliner. It and itself is, like, quite a big EAP, so we should just keep that in mind, and, you know, not add every last EAP, and try to have a reasonable balance here. Ryan.

Ryan Berckmans: Hi, good morning. An EFT member saw a post of mine and suggested that I stop by to call today. I'm here to argue for EPBS being the only, headliner in Glamsterdam, or rather to keep Glamsterdam as scoped down as possible, to ship as fast as possible, to unlock additional blob scaling as fast as possible, and thus for the exclusion of FOCIL from Glamsterdam. My reasoning for this is that Ethereum's L1 plus L2 model is really finally starting to work. BaseChain and world chain L2s are growing extremely quickly. They both have a direct business line of sight to dramatically increase their blob… blob use. And so, the downside risk here is that base chain or world chain may leave blobs for Alt-DA in the worst case.

And… I see the L1 and L2 model as being, just on the cusp of public acceptance. And eventually, the model will be mature… sufficiently mature that any particular L2 leaving blobs won't shake confidence in the underlying model or in Ethereum. But that's really not where we're at now. We're currently in a transitory period of nascent public acceptance of the whole enchilada. And so, I think this would be a really terrible time for some of our top customers to think or act about leaving blobs for AltDA, and Based on their growth trajectories. it seems that months matter, and so I think there is a customer circumstance argument to keep Glamsterdam as small as possible, including the exclusion of FOCIL. Thank you.

Alex Stokes: Okay, thank you. Right, we… I was going to jump in a bit differently, but yeah, thanks for sharing that perspective. Hopefully everyone can just keep it on their minds. Kevin, Panda Ops, I was going to have client teams give, like, a quick overview of their positions before we really get into things, so I don't know if this is a response comment, or…

kev and pandaops: It was a response comment, and just one thing we want to point out, that there's also a couple of peer-to-peer changes in the pipeline, especially over the next, like, half a year, and we've decoupled what how blobs scale from forks themselves. We can do a BPO without shipping lamps to them. But yeah, that being said, yes, better fork cadence and tighter scoping always makes sense.

Alex Stokes: Okay, yeah, that's a good point, thanks. Okay, yeah, as I suspect, things… Might get a little animated as we go. Let's try to follow the agenda, just so there's a bit more sequence here. And… In that case, okay. Let's, Here, let me just do it like this. So, we have these, EIPs here as non-headliners, and, right, we have EPPS as the headliner. Our task today would be to select which other non-headliners we want to go in. We'll see what we can do. If we can't get through them all, or come to our summer of consensus, you know, we can do that over the next call. Timing-wise, just to keep things moving, it would be ideal if we can come to some consensus today. So, yeah, let's try to do that, and everyone just keep that in mind.

I think to get started, I would like to have, the client teams, if they'd want to give, you know, maybe a brief overview of their different positions. Some of them came in over, you know, even the last few hours, so I haven't had time to kind of organize them all. So yeah, I think that might be a nice way to do this. I've read through them, I can give a quick overview from my take. Okay, actually, the tech one just came in here. But yeah, ultimately, they're linked on the agenda here. Maybe… here, let me just go in the order we have. And let's try it that way. So, Taryn's posted here, with Prysm. Would someone from Prysm like to give a short overview of their position?

Terence Tsao: Yeah, since I posted it, so… I guess TLDR is dead. We're in favor of 80457688. For the 8071, we have the homework of just, like, understanding that Shorten the subjective year to 7 days, the numbers are right, the numbers here meaning that the new churn, portioned, so I'm still studying that as well, but I'm sure it's fine, so yes, we will prefer 8061 over 8071, for the reasons I mentioned in the description. But 8062, we're a little divided in a way that, like, not sure, like… which approach is best, and changing consensus code is always a scary thing for these type of things. And 7805 FOCIL, we are neutral, but we do worry about, like, adding complexity.

because EPBS itself is already complicated, such that it will push your grams to then, mandate deadline to potentially end of next year, yeah.

Alex Stokes: Okay, thanks. Let's see… I'll just go by client teams for now, and I think the next one here would be Lighthouse. Would someone from Lighthouse like to give an overview?

kingy_sigp: I, yeah, I can… I can speak.

Alex Stokes: Okay, thanks.

kingy_sigp: So yeah, so… for us, the TLDR is we… we think the timing is… is right for FOCIL, and we don't think the… We don't think the implementation will add too much, overhead, such that we should really panic about being able to deliver, EVBS, but we acknowledge that EPBS is going to be complicated, and big enough on its own that we really have to be careful what else we tag along with it. So our position is basically do FOCIL. Ascend FOCIL at the same time, and everything else, we hold off for hecker. Except that we would like to see some… some way to address the consolidation exit queue workaround, because we don't… we don't think that that's, intended behavior. So either 8071 or 8061, whichever is… is more appropriate. We're preferencing 8071 because it's a one-line change.

But yeah, that's… that's basically where we stand now.

Alex Stokes: Okay. Thanks. Let's see, next we had… There is quite a bit of conversation here. Okay, I think next thing we have, Lodestar. Would someone from Lodestar like to walk through their thoughts?

Lodestar Team: Hey everyone, this is Phil here from the Lodestar team. So, basically, to summarize it, we have a TLDR that we strongly believe that FOCIL should be included. In Glamsterdam, we currently estimate an additional engineering effort of about 2 weeks for our implementation on top of EPBS. So for us, the lift is not very heavy for us to include FOCIL, which is why we believe we can include it. And really, if that's, like, the only thing, we would be pretty happy. But we do have some other positions on some other EIPs, which I'll quickly skim through. We feel, that 7688 has been stagnated for quite a while, and, would be nice to get in. Also in terms of the perspective of… we have… also have customers that are looking to get that in as well.

And 8045 is a nice, simple fix as well, so we would be okay with that. In regards to the remainder of the things, we have a different… opinions here about this, but we are very well aware that we want to ship as soon as possible, so we've also just decided to, potentially think of those maintenance EIPs more for an H-star fork. And I don't see anybody here that is nodding their head and no, so I think, what I said here represents our view at Lodestar.

Alex Stokes: Okay, thanks. Nimbus. I was stumbling from Nimbus here that I would like to give an overview.

Dustin Brody: Yes. Yeah. Sure, so… Broadly, so we… we support, 7688 as… as well. I mean, this is… And… for, essentially, the reasons that have been… have been described, I would note, that Diva, Wido, I mean, various of the large staking entities have shown up here, and in fact, Diva posted in that, in the thread, noting that this directly, benefits them. So, that's 7688. We also support 8045, this is… From our perspective, a fairly simple, straightforward bug fix in the spec. Yep. we… Support 8070, 81, Which, the reasoning there, essentially being that you have the consolidations that was, I mean, it's simply not an intended path.

the moment I start seeing people, for example, I mean, and here I'm speaking, I guess, personally, because I can always speak to my reactions on this, but… but, in… in ETH R&D, sort of talking about, well, let's have switch paths, like, depending on which, is the consolidation path right now faster than the regular exit path to me. I'm sorry, but that is crazy. That is crazy. No. So, we have to just cut that off, from my perspective. So… things which lead to that kind of discussion, so… Anyway. We, Nimbus overall, FOCIL, this is a key point, I think, that I think can be one of the bigger discussions. I am broadly aligned, I mean, so I have to say, I,

I've read some of the others, but broadly aligned with the idea that we support FOCIL in principle. It's good, it's the future of Ethereum, great. However, The… it should… it's… implementation complexity should not be underestimated, and it's not only implementation complexity, but testing complexity. And one point I want to highlight here is that both EPBS and FOCIL add sidecars, separate network sidecars. Now, it took months to stabilize this for Deneb, that was ancient history now, but it took a long… but even then, we've had issues pop up around, in the columns in Fugu, and what the gossip validation rules, and we are… gaps in them. These are… not simple. Net worth sidecars are never simple. So, and adding two of them in one fork is significant. They may both be worthwhile, but… yeah.

What don't we support? We don't support 8061, which, weakens network security. We don't support 8062. Which is… the intu… the intuition is there, from the EIP proposer, but it's… it's a… it… Comes across as a bit of, ad hoc tweak. That's not otherwise well justified. So, kind of, I suppose, low risk, but also low reward on that one. We're not strongly against. Alright.

Alex Stokes: Okay, thanks. That was a nice overview. Okay, Teku. I actually haven't had time to look at this, because I think it just came right at the start of the call. But would someone from TechU, like, to walk us through?

Enrico Del Fante: Yeah, we just posted it, so let's start with the FOCIL, We think that… we acknowledge the fact that the FOCIL introduced Fair amount to complexity, and will probably slow down, the fork. But we also see, that this is really the time to consider it and, try to accumulate the timeline, accordingly, and, and, Try our best to… to put it in. So we are in favor of it. The other one, which we are in favor, is AT45. Simply because it's… pretty… a tiny change that makes sense to… to fix. And, we, have a low… low support for progressive containers, just because it's been…

There for a long time, even if the, We have an implementation for stable containers, but we haven't looked into What needs to be updated for implementing progressive containers, so it will be a little bit of work for us to be evaluated, but if the community wants that, maybe we can consider this. And we are also mildly, considering, AD. 61, the churn limit. Definitely because the… the user experience Should be improved, for sure. And we are kind of natural on the other ones, We don't have strong opinions, for… for the… 72 and 68, for instance, which… Are very tied to, fast finality things.

And we don't have a… proper… Idea of the… The timelines, and how quickly these things do… needs to be done. That's us.

Alex Stokes: Oh yeah, thanks. And then, Salius here with Grandine has chimed in. Salius, I see you here on the call. Would you like to speak to your comment?

Saulius Grigaitis: Yeah, the short, comment. So, so we really like, this, short cycles of, hot works, and because, now, we, we are quite far from EPBS DevNet Zero, we would come with maybe not very popular opinion that cut everything and just leave EPBS, Because that will be the fastest way to ship EPBS, which, as I said, it's a bit… even DevNets now are a bit far away. So that's our opinion.

Alex Stokes: Alright, thank you. And let me make one more pass over the agenda. So, those were the client teams here, and then otherwise. There were a number of other comments. again, yeah, let me just go in order. So, first up I see here, the Stakers Union, they basically are here strongly supporting, FOCIL. There's a comment on the agenda if you'd like to see more about that. Next up, Caspar here from the rig team gave the rigs, the rig team's view on this. again, yeah, let me just mention that, and then I'll give any of these people a chance to briefly speak once I've gone through the agenda. So, again, call out here to the rig view.

There's quite a bit of back and forth here on these different staking EIPs that we've been touching on. We'll probably get into that later in the call. And next, we have, Diva here, one of these, staking pools that was mentioned. Again, they're saying yes to 7688. This SEZ change helps, yeah, basically all of the staking pool constructions that are, you know, in any sense decentralized, just because the reason about consensus on-chain. And, yeah, Betty AP's good for that. Let me see what else is here. Okay, I think that was more or less it, in terms of views for scoping. Would any one of the people I just mentioned that are here like to say something briefly about their view, or how they're thinking about the scope?

Okay, then we'll leave that there. And… yeah, so Sophia has a comment here, which brings us to… what I think, you know, it sounds like this is, you know, one of the big questions that we need to decide, so… It sounds like there's, you know, some support for FOCIL, maybe some teams lean against. And I think, again, this comes down to thinking about scoping, and the fork, and how we went to actually pull this off. So… Yeah, would anyone like to present any views to, FOCIL itself? I would have a suggestion myself for how to move forward, but yeah, maybe first we'll hear different, Either arguments, or… yeah, comments supporting or not supporting FOCIL and Amsterdam. And maybe before we jump into things.

Even if we say no to FOCIL today, that doesn't mean it can't go into a later fork. So we're not saying no to the entire idea or the EIP. Facebook?

soispoke: Yeah, thanks. I mean, yeah, my comment was gonna be mainly about this, because I've seen your post, and I think there was an opinion that was shared also by some other people that, you know, we can… like, GF5 also, but then maybe include it in HTAR. And my take is that we… I don't really think, like. anyone can rely on statements about the next fork. Like, for me, it's really obvious that a lot more unpredictable information will come in, over the next year, and it's just, like, impossible to say how things will turn out, and… or whether, like, FOCIL can be included in the H-star fork. Yeah, I think, you know, I think in your post, you also say there is no social risk for FOCIL, like, I actually disagree, but more importantly, I just think, basically, we don't know, so we…

Yeah, I wanted to make a comment about that. And to me, like, in some ways, like, saying, no, we'll DFI for still now, but, we can include it in the next poll feels like… sometimes, like, a way to just, like, DFI for Sol without, like, causing too much discontent amongst, like, the community and core devs that have been pushing for this, so… I did want to mention that, because I don't want it to be the case. I don't want to be like, yeah, sure, we'll include it next forth, and we all know, like, we have no idea whether it will be included, but… and sort of, like, use it as a pretext to just, like, push it back further.

And… yeah, I think, if I understand correctly, like, the main pushback against FOCIL has been around… fork cadence and fork scope, and complexity, which are all, like, valid arguments. And I know we are, like, in this sort of new meta, that prioritizes, like, 6-month forks above, like, everything else, including… I guess including, like, shipping features that drastically improves, like, some of the protocol's resilience and properties. I… I feel like, in the end, it's pretty straightforward, like, either we do things for cadence, it's basically, like, the most important thing we should optimize for, including Yeah, and that is just, like, basically more important than shipping protocol upgrades that preserve some of the core properties and values Ethereum stands for.

or we decide to, yeah, basically SFI both FOCIL and other EIPs we consider crucial for the future of the protocol, and we accept that this may delay the fall by a few months. But what we shouldn't do, basically, is, like, make statements about HSTAR to justify DeFi Infosool, or any other AIP, basically. So, yeah, that was my feedback.

Alex Stokes: Okay, thanks. And maybe just for context, yeah, so I do think one path forward here, given, you know, all the considerations and the mixed support that we have today, is just say yes, like, FOCIL is very important. At the same time, there just isn't room for it right now in Clampsterdam, and the proposal then would be to basically, you know, only have EPBS and a small number of other of these CLEIPs. in Gloucester Dam, and essentially move FOCIL then to Hecca. I think, you know, the biggest pushback to that is saying, hey, like, so I spoke with Zane, essentially, like, it's really hard to make commitments about multiple forks. I hear that. I also think, you know, a lot of us here will be the ones determining this, and so if we just all agree to it, I don't see…

what the issue would be, but… In any case, we can keep talking about this. Barnabe.

Barnabe Monnot: Yeah, hi. Well, I wanted to point out two things. The first thing is that the cost of delaying the fork, by, let's say, 4 months, adding proceed to the scope is not just, like, 4 months delay, it's also losing out on the massive benefit that we're getting from the other features that Glamsterdam is supposed to ship. For these extra 4 months. I think Ryan made the point earlier that, yeah, there's a time component that I think is pretty, pretty cool here. The second thing I would want to point out is that some of our top researchers, some of our top testing people, some of our top Ops and deployment teams are all thinking that this is just…

impossible complexity to manage. Not impossible, of course, but just compounding and explosive complexity, and that it's a mistake to add it to the scope, and I think this signal also needs to be heard.

Alex Stokes: Yeah, good point. I do think our top priority here should be the security of the protocol, and again, just adding more to the scope does increase the risk of a hard fork. Every EIP adds risk. So I do think on, you know, in that framing, we should lean towards less rather than more. What's her?

Lodestar Team: Yeah, so we, we also feel strongly in, in concert with both what Barnaby was saying and what with, Thomas was saying, is that… There is an importance to the cadence and being able to ship and deliver and realize these features, and the complexity is high, but the pressure in order to basically force things into the current fork Because of that risk that was spoken about of, like, is it a… is it a secret DFI, is real. And we've seen it happen a number of times in the past. And this is where I think the idea of we should really start thinking about N plus 1 and N plus 2. Like, we, you know, planning as far as your nose is out in front of you is great for some things, but this is, the increasing complexity of being able to

Not only schedule, development effort and being able to do research planning from a client team perspective, but also from a research perspective. So being able to say that, you know, we are going to push it to the next fork, and if there is firm guarantees, like, there is no things that change that, other than, literally, the research says it doesn't break. You know, that… that is a great way in order to create a more predictable cadence, which I think would benefit not only the development effort, but the predictability For those in the industry and the market in order to understand what, what features are on the horizon.

Alex Stokes: Kevin Pendops.

kev and pandaops: Yeah, I think we also want to preface with, we really like FOCIL as an EIP, and we definitely intend and want to ship it, and we are more than happy to help with whatever that requires. Our main, issue is that we don't want to repeat the same mistakes we did with Pectra. We over-scoped, and then we decided to Split stuff up later, way too late, and it led to an insanely long fork that also felt way riskier, because we made changes mid-flight. One of my biggest fears with FOCIL, as well as EPBS, is that they change a lot of the same parts of the system. Which means you cannot often make a change to EPBS without thinking about how this affects everything with FOCIL.

Same problem exists with, networking. Like Dustin said, same problem exists with testing. We can't test anything in isolation. One of the benefits of sequencing forks such that we change one part of Ethereum once at a time, is that you can be quite sure that the changes are tested. It's how we're also doing Fusaka. we're not doing any other networking changes. We could have shipped blob scaling along with Fusaka, but we decided to de-risk it by doing BPOs after. That gave us a lot more confidence on it. I think for that reason, I would… prefer if we are doing FOCIL as a fork after. And I do agree that it's hard to give commitments on what the fork after looks. However, we have done this at least twice in the past. We committed to withdrawals before the merge was shipped. We've committed to Pierdas before Pectra was shipped.

So, I don't think that we… we do have some counter examples, of course, with EOF and Worker, but we also have pro examples. We can sometimes commit to a feature, not just the immediate fork, but two forks out. I also think that if we want predictable cadence and timelines, we're not going to be able to finish a fork and only then start preparing what the next fork is going to be. We're going to have to do some amount of pipelining, which means you can start with medium confidence that FOCIL will be in, not, not in Glamsterdam, but in Hitstar, and unless there's contradictory evidence presented over the next year, that that is what happens, but the point of the next few months is to find those contradictory evidence, right?

So yeah, I think our case is that if we want to keep testing Scoped, if you want to have, faster timelines, if you want to actually have parallel forks, we should try to keep scope as small as possible.

Alex Stokes: Guess what?

Caspar Schwarz-Schilling: Yeah, so I think, also kind of echoing some things that were said in the chat, but I think one of the main worries about FOCIL not being included in Glamsterdam is that it will suffer a similar kind of conversation in Hecca and the next fog. like, in particular, shorter slots in FOCIL, both being CL changes, and then the worry being that, For similar arguments regarding, fork cadence and, and kind of… complexity that it would then be dropped again. And so I guess one question here is how, like, why do we think it will be different, and how can we kind of, is there, like, a serious attempt that the governance process can make to for, like, a credible commitment, for FOCIL being prioritized in HECA.

Over other changes, if necessary. And yeah, so I guess, I think. that is a key kind of question for… or worry about FOCIL in Amsterdam or not.

Lodestar Team: And I think this is exactly what I'm talking about, planning out further than the single fork, is that we all know 6-second slots is a priority, and we all know it's gonna be something that's gonna be important, and before we make the decision on whether FOSIL is now or next fork. Like, being able to say what is the priority of the 6 seconds loss versus FOCIL is important. Because that will eventually be coming up in the next fork, and being able to advocate every single fork just beats down the person who is the advocate for an EIP. Like, there needs to be some surety for the person, just like… just like POTUS has been pushing for years on EPBS.

it's a grind. And just like, Virkle was pushed on by Guillaume for years, it's a grind. And this is the part of that surety of looking out at a roadmap style with a couple forks ahead, with surety. Like, we will do this in two forks, and there is no delay of that. Short of a security bug, like, to me, this is a critically important piece to creating the longevity to the dev process that we all would like to see for Ethereum.

Alex Stokes: Metallic.

Vitalik Buterin: Yeah, hello guys. Yeah, I think, one thing that's just important to keep in mind that I think now, quite a few people have, kind of hinted at, right, is that, Ethereum is, not just a technical system, it's, Also a social system. And so, if, we have goals, that we, care about. We, need to continually make them clear to… I mean, our community and even ourselves, not just by, yeah, but by speaking, but also by taking action, right? And, I think, like, to me, that would be the, like, that's one of the stronger cases for… Either, like, making some type of commitment to FOCIL, which, I think, you know, there was, a good point made, right, which is, that, it's, like, it could happen in,

in the next fork, or it ha- it happened… it being top priority, and I think, I would say, yeah, explicitly above 6 seconds in priority in the, in the fork… in the fork after that, right? Because, there is, like, I think there is, An actual risk that's, basically, you know, if the community perceives us as continually, delaying certain kinds of things, but, But then prioritizing efficiency upgrades, then that's, like, a pattern that will perpetuate itself, and so I think it's, like, it's good to think about, you know, how, Like… Basically, yeah, even… Just for the… for… for that reason alone, making sure we have at least some density of, changes happening that are directed, toward goals like,

Censorship resistance and decentralization, and, you know, being able to say things like, okay, you know, we've done, Scale-related life related things for the last three. And, we need to go in the… in some different direction for this one, right? So, like, my view is, that, like, we… we need to… be willing to make commitments, that, last, not that… that go further out than one fork, and that at the same time are not absolute, but that are also… also meaningful. And, And this is, like, the… yeah, like, I don't think there's, in any one particular format, that's the, only way of, of doing it, but I think we do need to have an answer for people who will, ask, well, like, basically, yeah, you know, like, when,

If there's strong agreement that something is, is valuable, then when is it getting included?

Alex Stokes: Yeah, that's helpful context, thanks. Sophia.

Sophia Gold: Yeah, I want to give a ZK EVM perspective. This is my opinion, not a team opinion. So, at the same time, I would like to see EPBS as soon as possible, because we need the, pipelining… the attestation pipelining. to launch an optional, ZKEA tester client. But also, I would be concerned if, a FOCIL is delayed past, the H fork. And the reason is that I see FOCIL as actually part of our scaling roadmap. I think that, you know, we need it for censorship resistance by the time we are setting the gas limit based on proving benchmarks, rather than execution benchmarks with the current validator hardware. Because, you know, I think with multiple proofs that we need for security, I don't see the possibility of,

building… generating all those proofs with, like, a single GPU, so it will change that… that landscape. And, my most optimistic timeline of that happening would be mid-2027. Again, that's… I think that's quite optimistic, but, if you… factor that… project out, factor that in, and the possibility of fork delays, I would be concerned if FOCIL… that that FOCIL would could possibly block that if it's bunked out of the HFERG. So, I am skept… I am sympathetic to people who are skeptical of, commitments that go out beyond, the next work, but, I think it would be ideal if we found a way to do that more credibly, by pipelining the work and setting, some types of deadlines for it, while people were working on Glamsterdam.

Alex Stokes: Okay, thanks. Any other… Present comments? Okay, so let me try to play this all back. it sounds like people, I think, mostly are okay with… doing something like FOCIL and HECA. If we have a way to credibly commit to it. And this, yeah, keeps cluster temps small, means we can get it out the door sooner, means we can get to ECA sooner, means we can get to FOCIL sooner. there is also this point of, like, thinking about HECA and, like, how we'd actually make that commitment, because then, you know, we get to, okay, do we do 6 seconds less, do we do a FOCIL? I think given the overwhelming support for it today, you know, it seems like that would be the case, that we would do FOCIL. I really don't see what would change, in Hecca.

So, that's what I would propose as the path forward on this one. Then the question is, how do we credibly commit to it? I'm open to ideas. one would even be going ahead and SFI FOCIL for HECA. The meta-EIP. Is on the way. So we could just do that. We could do something lighter weight. We could say, you know, even just essentially have the message from this call today, hey, poor devs, you know, unilaterally support FOCIL and HECA. I assume unilaterally. It sounds like it's unilateral? But in any case, basically say, hey, this is definitely happening. And, ultimately, people just take us at our word. And the reason they can do that is because, yeah, you know, I think…

The sentiment today, the people today, will still be here for the most part. After Amsterdam, we can have the same views, we'll bring this into Hecca, and again, I would be very surprised if we have this commitment today and don't get too FOCIL in Hecca.

Lodestar Team: I think the part that we stand is that it's not so much you say it's hard to say we would, it's a commitment. And that's the part that I think if we could get there. Is great.

Alex Stokes: Right. So, yeah, do you have any thoughts then? Like, should we SFI? Mixer here on the comment, basically taking another… yeah, either trying to touch on this during next week's ACD, or just go to next ACDC. And find the right way to do this.

Lodestar Team: I mean.

Alex Stokes: Okay, what's happening?

Lodestar Team: it doesn't feel out of bounds to say it's SFI'd, it's the headliner, next one, and… to build those… those chops of being able to do cadence, like, quick cadence, because it gives the client teams a surety of… and I think part of the thing with ePBS is that Because it took us… and granted, it's a maturation of the process, so it's not to discount the process, but… if we had that SFI guarantee sooner, it gives more credence and more weight to it, and then as a… as a person trying to schedule resources to work on these things, it gives more weight to, we need to actually start focusing and driving this. And being able to do that SFI for H,

also brings forth that same, that same importance and that same weight to make sure age is ready when we really want to, and I think that will help to drive the cadence to a shorter. time frame, and I think it will also build more of a… of an organizational commitment to being able to ship faster in smaller chunks.

Alex Stokes: Boris?

Potuz: So, I am one of the ones that want to see FOCIL in. I consider it much more important than 6-second slots. However, I don't think we can SFI this for the H fork at all. Because otherwise, we would want to have the discussion of what is the headliner, and we would really want to have the people involved that are advocating for 6-second slots, and have that discussion for the headliner of the aged pork. Now, which sounds already another Pandora's box. I am perfectly fine if we do a strong… if we find, as Nixa said, one way of making it so that it's actually a credible commitment to CFI it. Sfi it is kind of crazy, unless we have that, discussion right now about 6-second slots.

kev and pandaops: Maybe to build on that, maybe the other way of looking at it is that if we decide to SFI FOCIL for Headstar, then that is something that the 6-second slots crowd has to deal with at the, fork scoping process for Headstar. As in, we enter the fork scoping process, assuming 6-second slots is SFI'd… sorry, FOCIL is SFI'd, and any consideration would take FOCIL as… at higher priority than anything else.

Alex Stokes: Yeah, so I spoke.

soispoke: Yeah, I feel… I mean, I understand, like, the sort of, like, worry about, like, not having a headliner process for HECA or something like this, because you wouldn't have discussions, but, like, the fact is, like. You know, discussions around FOCIL have, like, happened already. like, a lot, and we've asked feedback from the community many times, and they've expressed it in, like, many, many different ways, on It Magicians, on Twitter, or, like, doing the tier list, and, like, all of this has happened, not only for the headliner process, now for the you know, PFI'd EIPs, like, I think, like, yeah, in a way, you can't, like, ask the people to just, like, come in every year, advocate for the same thing again and again, like, it doesn't really feel fair either.

Alex Stokes: Kevin Penhops, was your hand slow?

kev and pandaops: Sorry, that was a mistake.

Alex Stokes: Okay, okay. I don'.

Lodestar Team: I do think that's a really good point, is that that's the part of, like, re-advocating, re-advocating, re-advocating. If there's a decision made, it's easy. You know, you say that it's SFI'd, and if we can also do 6-second slots. It's awesome, but that becomes the same discussion we had today for Fosel. It's like, we think EPBS is the headliner, or it is the headliner. Can we fit Fosel in? Well, maybe not, so we can push it back to the next one, but then… well, can we fit in 6-second slots? Maybe not. We could put it to the next one. And with that kind of a process where we're doing longer-term thinking of how many forks out, and sticking to it, is the part that I think is the piece that was missing before, is that you had to re-advocate, re-advocate. You now can start even to think about even shorter than 6 months, and I know that's very aggressive.

and ambitious, but if you're working on very small chunks in parallel, it's much easier to plan for team resources and do the actual development to maintain an even faster cadence than I think we even appreciate today.

Alex Stokes: Okay, thanks. So, there are a number of comments in the chat around, yeah, basically not, like, coming up with some way to do this on this call, which I think is fair. Then in terms of moving forward, I think what we should do is take all this contact for FOCIL. I think this is an interesting direction to explore of how we would, you know, find the best way to credibly commit to FOCIL and HECA. I think, yeah, we should probably just go ahead and do that on the next ACDC, so that would give everyone 2 weeks to think a bit, see how this sits. You know, there's a couple different options. I can propose some things.

That could look like, you know. That could look like putting it as SFI'd on the meta-EIP that kind of sidesteps the headliner process, as some other people pointed out in the chat, which I think is fair. It could be something like a PR that's not merged that basically does SFI for FOCIL for HECA. it could look like something else. So, there are some options here. And… yeah, I think that'd be a nice way forward. That also lets us move to the other EIPs that we should touch on today with the time we have left, which I think, yeah, is, like, about 30 minutes. So… Does that sound good to everyone? So, essentially, yeah. keep all this context in mind for FOCIL. Let's try to find a way to think about how to get it into ECA.

we'll sort that out two weeks from today on the next ACDC, and then we'll move forward with the other EIPs today. Okay, then let's do that. Then in that case, let's turn to the other EIPs. Sorry, I saw this comment here from Kingi for delaying FOCIL… Okay. And I guess the other thing is, you know. team should, or they may want to revisit some of their views today, if we do move FOCIL to HECA. So, yeah, I think in any case. We'll need another call to get to the final sales scope for Amsterdam. Yeah, Casper's basically just following up on this. So, I think we can still make progress on the other IPs, I think there were just some general questions about them.

So we could touch on those today. Yeah, again, we can think more about it and do this, because I agree. What it implies, then, is maybe a client team needs to have, like, two versions, basically, which maybe is more work than they want to do. I'm not sure. But in any case, let's get into the other EIPs. So yeah, again, thank you everyone. As you can see, there are many considerations here. FOCIL, and what it sort of really stands for is very important to Ethereum. But there's a lot of things to fit together here. So, let's look at the other EIPs, and… Yeah, I'm not sure how we want to go about this. again, because these kind of came in late, I haven't had a time… I haven't had time to get a clear view of exactly where people stand.

Maybe we'll sort of go in parallel to the EL, where they're trying to come to consensus on some kind of EFI set. And it seems like there's the least support for something like 8068. I don't know if anyone would like to speak to that EAP. I could also frame it as support for 8068. This is the one that changes the effective balances line a bit. And I believe the intent is to make it, essentially. Have, like, a more even playing ground between 01 and 02 validators. I think it also ties into some of these other EIPs. So, yeah, Anders.

Anders Elowsson: Yeah, I can just say that, yeah, exactly as you said. So… so that was what it does, but if it's too complex, there's also this, Yeah, so there's an interaction, essentially, between 8068 and 8062, so we're… Yep. Thinking about if we can sort of, Compensate for the, you know, the lower… the lower yield that you get on a… compounding validators if you have a lower balance, because you lose out on that 0.75 ETH that you're not getting any return on investment on. By instead raising the fee on 8062, So we don't do 80-68, but we have 80-62, which is a slightly stronger fee. So, and I can also flag that there's… there's in 8268, there's an alternative specification where we, just remove this way for people to partially withdraw down to

Right now, you can partially withdraw down to 32.75 ETH, but still getting 33 ETH of, effective balance, so you can get, like, a high return on your investment by keeping your stake very low. On a compounding validator, so there's this option to just do that as well. But anyway, I see that the complexity of 8068, it seems like there's, like. To do the whole thing where you change the, you know, the affected balance bands, it seems like it might be off the… Yeah, out of scope, as it seems. I don't know. I'm not sure about how people feel about it.

Alex Stokes: Agree. Let's see, was it POTUS and then Greg?

Potuz: Yeah, so I've learned something when speccing EPBS, and it's to talk to the teams that are going to be affected, and even though they're always… they might never change their mind. In this particular case, I suspect, and I strongly suspect, that it doesn't matter which of the two we implement, we're not going to see much effect on consolidations until much later. This is… the reason why we aren't seeing consolidations on holds It's because it comes at a cost. It comes at a big cost. They need to change on-chain contracts, they need to audit these contracts, they take… that takes time. Perhaps even, like, pressure from the community would be more effective than having these CIPs that would just punish books.

both of these CIPs would punish them in a way. One with complexity for us, the other one with actual, like, money, like, charging them. And I see that the benefits is going to be very minor, because I don't expect them to change their contract to audit the contracts and do this just faster, because we just shipped the CIPs.

Anders Elowsson: So you… can I just chime in? So you're saying that you think that all these, you know, node operators living on 32-it validators will consolidate, even without some some small… small incentive or not, because when I hear arguments, I hear that some argue against it because they do not want to consolidate, and they never want to consolidate. So that's something I would like to understand.

Potuz: Homestakers did consolidate quickly. pools didn't, and I strongly suspect that once we see, CSM, for example, supporting X02 validators, we are going to start seeing more. I, myself, would start validating again If that happens. So I suspect that we just need support from pools, and if there's no support from pools, then, well, it's harder to see consolidations.

Alex Stokes: Greg, do you have a comment?

Greg K | Lido: Yeah, so from, later side, I think that, this, adding a fee, like, 862, is not fair, because it's, kind of penalizing type 1 validators, and, like, if the incentive is to just. If the goal is to just incentivize consolidating to 002, then, the way to do it is to provide incentives for that. So, like, improved effective balance calculation, like 8068 is much more effective, in my opinion. And yeah, from the LIDAR side, LiDAR is working towards having all permissioned operators, like, in 2026, consolidating to 002 anyway, so this is, like, none… even if none of those EIPs come, like, there's committed in, user consolidations. on 90%, perhaps, of the stake, and the remaining 10% is, like, the goal is the 10% to go to the CSM, to the permissionless, trustless staking. And for this one, we need 001 validators.

So we think that, it's unfair having a penalty, because, you know, we have this fixed bond requirement, we provide this very cheap Very low barrier to entry, for also stakeholders. And, yeah, like, adding some cost for those 01 validators. Just does not seem fair. And in general, like, the protocol, might… we might end up in a protocol, like, having, like, say, 90% of validators having consolidated, but for the remaining 10% that, for, let's say, necessity, or for any preference, they want to use 01, that should not be penalized, in our opinion. So we kind of… we don't support, AT62, and if there, if we… we believe, like, if there is some incentive needed to be added, it will be AT68.

Alex Stokes: Okay. Yeah, thanks for the, input. So… Okay, I think we can at least, in terms of making progress through the scoping discussion. it seems like we can go ahead and DFI 8068, and again, I think we'll need another call here, so that maybe, you know, there's things to work through in other EIPs that kind of accomplish some of the same goals. But I think we can at least do that today, so… I suppose this is a chance for final comments. Otherwise, let's at least leave today with DFI 8068.

Anders Elowsson: Yeah, just a small comment, just so that people are aware about this gaming incentive that you have when you can withdraw down to 32.75 ETH, which can be addressed separately in a… but if people are aware of it, and they don't think it's a concern, then we can deify it, I guess.

Alex Stokes: Agree. So, let's go ahead and do that. And we touched on 8062, Yeah, I don't know if there's more to say here. I would probably suggest for now, just in terms of time, that we just take the input from today, and we can keep thinking about it, and we will make a decision on the next call. Let's try to go through these other… staking EIPs, that touch the staking mechanics. So we have 8061 and 8071. So, 8061, this is the IP that, touches various turn limits. 8071, this is preventing consolidations as withdrawals, which, patches this, essentially consequence of Petra. So… Yeah, sure. Kev, Pandops?

kev and pandaops: Hey guys, it's Barnabas. I would really like to actually end the discussion on all the EIPs today and make a decision about everything, including we just made the decision on full sale to basically push it to the next fork, so based on this, I think we could actually… either DFI or SFI, all the remaining CLIPs in today's call.

Potuz: Please know…

Alex Stokes: Yeah, I agree, Barnabas, with the spirit, I think, especially given that you know, this FOCIL, the way we want to handle FOCIL, is possibly somewhat novel. I think at least one more call is justified. Okay. Any comments on AD61 or 8071? .

Francesco D'Amato: Yeah, I mean, I can just say…

Alex Stokes: work soon. Oh, sure.

Francesco D'Amato: Maybe, yeah, just, about 8061, one thing is, like, I… I think I presented it maybe 2 weeks ago, and one thing that has changed, I don't know if people have seen, but it's that now the activation, limit stays, so there was this concern that people brought up about the… basically, state growth and all those, like, issues kind of getting worse as we increase the activation churn, so I've decided to not, have this be… this discussion be part of the AP, so I just decided to keep the cap there. And then another thing is that it introduces this mechanism of, basically, churn sharing between the exit and consolidation queue. And in a way, this makes it also,

basically, like, it makes it so that either we should do this or a 71. Like, if we do this, it doesn't make sense to do, 71, because we already basically solved the problem. So, yeah, just that. Obviously, like, 71 is a much, much simpler EIP, but it's also trying to do much less. It's trying just to address this specific kind of issue with the consolidation logic, whereas here, there's all these other things going on that I think we already discussed last time, and I don't know if it's worth now going into again.

Alex Stokes: I think we're okay about it. But yeah, that was helpful context. So… Right, I would be curious then to hear from client teams if they'd had a chance to look at 8061. And enough depth to get a sense of, yeah, like, because it sounds like 8061… would be superior to 8071, but the concern then would be, you know, it's a much bigger EIP, or at least big enough. Do client teams agree with this assessment that 8061 is big enough to have some reservations? Potus?

Potuz: So, I would first try to make sure that we want to fix this issue. If we do, then we can argue between these two. If we don't, then we don't need to. I personally believe that we need to fix it, and I believe that 8071 is the wrong way of fixing it, because it's the worst case for everyone. The people that are using this system will stop using this system, because it's unfair, but they're going to start, like, increasing the churn on the actual exit queue, so the people that are being hurt are being unfairly treated by the current system will be even in a worse situation after we put 8071. And, And on top of that, we're not using the churn of consolidations when there aren't consolidations to actually do something useful, which is exits. So, definitely, to me, it sounds like 8061 is the right way of fixing this. The complexity is much higher.

But it's not that much higher. I mean, we're already, like, Looking into EPBS? The problem we see with AD61 is that it would be nice to have a formal proof, or some formal treatment about, like, the week's subjectivity period and these kind of concerns.

Alex Stokes: Francesco?

Francesco D'Amato: Yeah, so, I mean, one point is, like, there's a lot of stuff going on in 61 that has nothing to do with fixing the problem that 71 addresses, so… if we're specifically just talking about that problem, we could also just do the thing that 61 does of the churn sharing and forget everything else about 61, which reduces the complexity a lot. And then we can have the rest of the discussion around the churn limits and increasing and so on, and weak subjectivity, like, separately from all of this. Like, I could split it into two EIPs, or it could replace 71, I don't know, just to, like, simplify this discussion and not kind of conflate the two things.

And then on the weak subjectivity point, I also, like, I saw this on the issue, and I asked a question, but let me ask it now as well. What I didn't quite understand is, like, is the question about this analysis On what the impact on the week's subjectivity period is, or on, like. Which week's subjectivity period we should be choosing for what reasons, and so on.

Potuz: Yeah, it's rather the second one. I think that the EIP has the correct, Treatment of what is the…

Alex Stokes: And just to remind everyone, Francisco, I think with the EAP right now, it gets us down to something like 6 days of exhibitivity.

Francesco D'Amato: 7 days.

Alex Stokes: 7 News? Okay. Okay, so, like, a week. Which does mean there are other places where we have 7-day windows like this.

Francesco D'Amato: And of course, the numbers are, like, I think someone… in some client teams post, there was a concern that the numbers are fixed without having discussed, and of course, I mean, the numbers are… I just put some numbers which look reasonable to me, to get to the… to this one-week number, but, like, we could… we could change it, it could be 10 days, I don't know. Of course, we can start from the, the other side of deciding, like, what is an acceptable weak substitutivity period, and then decide the numbers based on that. So don't treat those as fixed, necessarily. But I don't know how to answer his question of, like, what is a reasonable weak subjectivity period, like…

I'm not sure exactly, like, how to get to this answer.

Alex Stokes: Okay. Okay, I think that gives us some paths forward on 8061 and 8071. It sounds like there's generally support from everyone to do something here, it's just figuring out what the right something is. And… okay. Then, let's turn to 8045. This is the EIP that would exclude slash validators from the proposer sequence. Yeah, so I think where this really comes up… has been on DevNets or testnets, and it seems like a nice quality-of-life thing, mainly for us in the room. But then the question is, you know, do we need it on mainnet? Will it, like, really substantially improve things on mainnets? Again, I haven't had time to get a good pulse of the differing client opinions.

I think some people were forced, some people were more neutral. In terms of, you know, so I guess one way to think about this is if we do want to keep the scope as tight as possible, then we'd lean towards the FI, but then, yeah, I'd want to open the floor for people to argue against that. Potus?

Potuz: I just have one little grudge with DCIP, and… And it's the fact… I haven't really audited our code, but it's the fact that today, when we are going to propose to check who the proposer is, you can grab any state that has the same shuffling and the same active validators as the one that was used to compute the proposers. But DCIP changes this, because you now need to also have the same slash validators, and those can change, intra-epoch. So I think this… this isn't straightforward, as one would really think. It's one of those CIPs, like what happens in Electra, that you see just a one-liner, and then you think it's a one-liner, it might not be. But after the look-ahead in Fusaka, it might be a really minor complaint, so it's not a strong complaint that I have, but I want people to be aware of this change.

Alex Stokes: Okay. Wouldn't you also know from the same state that if a validator was slashed or not? So it seems like that's fine, right?

Potuz: No, because you need it to be… you need to be… you need to have the slash validators at the time that the look-ahead was computed, which is different than your head state. So, for example, today, when I want to check, who the proposer is, I can just grab a head state. And that would still be the case, after DCIP, because of the look-ahead. But if you, for some reason, need to recompute the proposers, for whatever reason, because you're syncing something from fork, then, we… today, we can grab any state on that fork. It doesn't need to be exactly the one of the epoch transition. If we have at handy one recent state from that fork, we can just use it. We can just grab it from a cache and use it, because we can prove that it has the same shuffling and the same active validators, because those only change on input transitions.

But, if we add the CIP, this is going to be impossible. Yep.

Alex Stokes: Okay, and the claim is that it's that much worse? Like, it's actually… it would actually be an issue here?

Potuz: Performance or something. No, I think that it's minor.

Alex Stokes: Okay. Okay. That's a good call, then.

kev and pandaops: Is it still a minor issue with the proposal look-ahead?

Potuz: Yeah, because of the proposal look-ahead, in most cases, it's going to be a very minor issue. In most cases, you can always use the head state.

Alex Stokes: There was another good comment here with calling out that if there was ever a mass slashing event on mainnet, you know, the same reasons we want this on testnets, let's say, would apply here. So… Yeah, again, it is actually a pretty small change, something we can test very easily, and yeah, would be good to have. So yeah, again, as it looks like, I think we're gonna need another call to get through all of this. Let's just take that as context for now. And I'll just comment, yeah, seems like… people lean towards including it in Glamstra. Okay, let's see, I think then the last thing here, and we just have, yeah, should have enough time to get through this, would be 7688.

This is adding stable containers, as it's featured as a ZSpec. And, yeah, the name is good. It keeps things stable, and the things here are these generalized indices. This, you know, has to deal with how we make proofs and reason about CL data structures. Again, this is a very nice quality of life improvement, for people using that part of the spec and the protocol. And yeah, there, again, there's strong support from the NEMBUS team, I remember, and also many community people here have come to speak to us. At the same time, as it was called out by someone, you know, it's kind of been in a holding period for a while, just because the question is, like, yeah, it's nice to have

Is it gonna move the needle that much? This is a debate we can have. And, yeah, would anyone like to add some comments, on this one? One question I would have is, if we move forward with this in Glenster Dam, would client teams feel like they need to re-audit their SSD codebases? That's, at least for me, the thing that gives me some pause here, just because… You know, that's… That's a much heavier process than just, say, a spec change. Okay. Came in here in the chat, says it's nice to have. But nice to have is not necessary to have. Greg?

Greg K | Lido: Yeah, for Lato side, this AIP is quite important, because it reduces a lot of extra work of the engineering team, has in every upgrade. So, yeah, there was also a post of, Dmitry in the PR of the previous, ACD call, but, yeah, it's, it will be quite important for Lido if this EIP gets in, because, currently, it needs hard fork. If there are changes in this localization, this is a lot of extra work for the engineering team. So I will post also here the link of the previous methods.

Alex Stokes: Okay. Anyone think we should defer 7688? Again, I don't have all the client team opinions handy. But I do recall there was, yeah, mixed support. Okay, then in that case, I think we move ahead as follows, so… Yeah, the intent was to get through as much of this today as we could. there's a lot to cover, so, you know, that is what it is. We also do… do have time. We should settle Glenstrom scope in November, but that means we have at least one more call on the CL side to discuss this. I also think, given FOCIL and all the considerations there, it does make sense to take another call, so let's do that.

So, just to be clear, we will make final… CFI, DFI decisions on the CLEAPs on the next call, so two weeks from today. So, I think, again, with this context today, this helps people refine their client views, and let's, yeah, keep doing that. Let's get to final versions by the next ACDC. And the big thing in parallel will be sorting out, how to make this credible commitment to FOCIL. Please, if someone has, you know, an idea here, feel free to propose. I will also propose some things, and… I might even try to grab some time on next ACD, so next week's ACDE, just to touch on this, if there's 5 minutes or so, if we need to sort through any proposals,

That have been made, just to see what makes sense. Otherwise, we'll need to, find the best option two weeks from today. And… Assuming we do that, then we'll have a path towards FOCIL and H-star. We'll go ahead and pick some number of these other EIPs for Amsterdam. One thing we can't say that we did today was, DFI 8068. for Amsterdam, so that's some good progress. And then otherwise, yeah, we'll keep moving things forward on the next call. Francesco?

Francesco D'Amato: Yeah, just quickly wanted to ask, there's, some support in the chat for splitting this, like, churn-sharing thing as an alternative to 71, into its separate VIP. I'd just like to have, like, an official confirmation that if I do that, that would be considered fine, even if it wasn't PFI'd by the deadline, because otherwise I'm not gonna do it.

Alex Stokes: It seems fine to me. I don't know. Does anyone have an issue? It was kind of just an evolution of 61. And or 71. Like… I, I think…

Francesco D'Amato: It's like.

Alex Stokes: You know, pardon.

Francesco D'Amato: of 7061 right now, basically. Right.

Alex Stokes: Right. I mean, the way that I see this is the deadline was more just to fix, like, possible scope. You know, like, what we don't want is someone to come in today, or next week, being like, hey, I have this whole new EIP we should think about. Whereas this is just, you know, a refinement of things that, you know, we're already talking about, so seems perfectly fine to me. I wanted… okay, maybe I'll just do this with my voice. Jihoon here asked in the chat, do we put all candidates on the table and discuss their headliner for H-star or just FOCIL? So… well, okay, I was about to say the opposite, Sophia. I think… So yeah, I mean, this is one option, is we do actually just start discussing H-star headliners.

I'm not sure if we would necessarily want to do that, but it's an option. I would personally start to think about ways just to credibly commit to FOCIL and H-star. Via, you know, whatever process mechanism makes sense. We did touch on this earlier in the call that, yeah, maybe we should go ahead and have the conversation if we want to think about FOCILs, 6-second slots, and these things. I can try to reach out to some of the 6-second slot authors of the EIP, and yeah, try to fill it out. It might be a little tricky to get the right people in, you know, prepared two weeks from now to have that conversation, but it's an option.

So yeah, I can be in touch with everyone, and we'll find the right path forward here. Okay, we're out of time. Thank you, everyone. There's a lot to get through, but I think we've made some good progress today. And… yeah, I'll see you all around. Also, DevConnect's coming up. I don't know if you will be there, some of you will, I think some of you won't, but yeah, it should be very fun, so… See you there, if you can make it, and if not, see you next time on ACD. Goodbye.

Potuz: Bye-bye.

Carl Beekhuizen: Thanks, Paul.

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